Voice over IP Consortium

Size: px
Start display at page:

Download "Voice over IP Consortium"

Transcription

1 Voice over IP Consortium Version 1.6 Last Updated: August 20, Technology Drive, Suite 2 University of New Hampshire Durham, NH Research Computing Center Phone: Fax: TTwww.iol.unh.edu 2010 University of New Hampshire

2 Modification Report The University of New Hampshire Version Date Editor(s) Comments 1.6 August 20, 2010 James Swan Removed test cases 2.6, 2.7, 6.4, and Added test cases 9.2, 9.3, and 9.4. Removed reference to RFC4475. Modified observable results to state a 489 response must be returned. Fixed minor editorial issues. 1.3 August 16, 2006 Allen Latham Added tests , Formatting Repaired 1.2 July 18, 2006 Niels Widger Modified tests 9 and 12 in group 2, 4-6 in group 16, and removed test 6 in group March 24, 2006 Bryan Pellegrino Added tests for UPDATE messages, RFC January 19, 2006 Lincoln Lavoie Final review of version January 17, 2006 James Swan Added test cases to group January 13, 2006 Lincoln Lavoie Updated formatting and reviewed document 0.4 December 7, 2005 James Unger INFO, SUBSCRIBE, NOTIFY, REFER 0.3 November 30, 2005 James Swan 0.2 October 10, 2005 Lincoln Lavoie Updated formatting 0.1 July 10, 2005 James Unger Tests added 0.01 June 10, 2005 James Unger Initial draft created Updated formatting and added tests for RFC

3 Acknowledgments The University of New Hampshire The University of New Hampshire would like to acknowledge the efforts of the following individuals in the development of this test suite. Jeremy devries Allen Latham Lincoln Lavoie Bryan Pellegrino James Swan James Unger Niels Widger University of New Hampshire University of New Hampshire University of New Hampshire University of New Hampshire University of New Hampshire University of New Hampshire University of New Hampshire 3

4 Table of Contents The University of New Hampshire Modification Report... 2 Acknowledgments... 3 Table of Contents... 4 Introduction... 7 References... 8 Terms: Definitions and Abbreviations... 9 Abbreviations Test Setups Test Setup 1: General Test Setup Test Setup 2: Setup for Three Party Interaction Group 1: Core Message Formatting Test # 1.1: Correct Formatting of Request Line in INVITE Requests Test # 1.2: Correct Formatting of Status Line in Response Messages Test # 1.3: Verify Correct Header Field Formatting Test # 1.4: Verify Inclusion of Necessary Header Field Test # 1.5: Ability to Process Compact Header Fields Test # 1.6: Verify inclusion and correctness of Content-Type header Group 2: Core UAC Behavior Test # 2.1: UAC Call-ID Creation Test # 2.2: CSeq Generation Test # 2.3: Max-Forwards Test # 2.4: Inclusion of Appropriate Via Header Test # 2.5: Inclusion of Appropriate Contact Header Test # 2.6 General Expire Header Test # 2.7 Timestamp Header Test # 2.8: UAC Inserted Supported and Require Headers Test # 2.9: Correct Handling of Multiple Via Headers Test # 2.10: Correct Handling of 300 (Redirect) Responses Test # 2.11: Correct Handling of 413 Request Entity Too Large Response Test # 2.12: Correct Handling of 415 Unsupported Media Type Response Test # 2.13: Correct Handling of 420 Bad Extension Response Test # 2.14: Correct Handling of 416 Unsupported URI Scheme Response Group 3: Core UAS Behavior Test # 3.1: 100 Provisional Responses to INVITES Test # 3.2: 200 Responses Test # 3.3: Behavior When an Unsupported Request is Received Test # 3.4: UAS Header Inspection Test # 3.5: Reception of Invalid Request-URI Test # 3.6: Require Header Processing Test # 3.7: Require Header Processing in CANCEL Request Test # 3.8: Provisional Responses on Non INVITE Requests

5 Test # 3.9: Handling of Header Fields in Responses Group 4: CANCEL Request Test # 4.1: Generation of CANCEL Requests Test # 4.2: CANCEL Request Without Provisional Responses Test # 4.3: CANCEL Response When Referring to Incorrect Call Test # 4.4: Generation of 487 Response Group 5: REGISTER Requests Test # 5.1: Generation of REGISTER Request Test # 5.2: Removal of Bindings Test # 5.3: Refreshing Bindings Group 6: OPTIONS Request Test # 6.1: Generation of OPTIONS Request Test # 6.2: OPTIONS Request to SIP Proxy Server Test # 6.3: Response to OPTIONS Request Group 7: INVITE Requests Test # 7.1: Sending Session Offer in INVITE Requests Test # 7.2: Sending Session Offer in 200 Response Messages Test # 7.3: Receiving Session Offer in 200 Response Messages Test # 7.4: Generation of ACK Requests Test # 7.5: Reception of Non 200 Terminating Responses Test # 7.6: Unacceptable SDP Offer Received in INVITE Test # 7.7: Timeout of ACK requests on INVITE Test # 7.8: Reception of INVITE Within a Dialog (re-invite) Test # 7.9: Reception of re-invite Before Response Group 8: BYE Requests Test # 8.1: Generation of BYE Requests Test # 8.2: Reception of BYE Requests Test # 8.3: Reception of BYE Requests Outside of a Dialog Test # 8.4: Correct Termination of Sessions Group 9: ACK Requests Test # 9.1: Correct Generation of ACK Requests for 2xx Final Responses Test # 9.2: Reception of ACK Requests for 2xx Final Responses Test # 9.3: Correct Generation of ACK Requests for non-2xx Final Responses Test # 9.4: Reception of ACK Requests for non-2xx Final Responses Group 10: Tags Test # 10.1: Correct Tag Parameter in Request Outside of a Dialog Test # 10.2: Correct Tag Parameter in Response Group 11: INFO Request Test # 11.1: Verification of Final Response After Receiving an INFO Request Test # 11.2: Response to INFO Request Outside of a Session Test # 11.3: Support of Response Code Test # 11.4: Correct Generation of INFO Request Test # 11.5: Cancellation of INFO Request Group 12: The SIP Join Header

6 Test # 12.1: Correct Handling of INVITE with Join Header Test # 12.2: Correct Generation of INVITE with Join Header Test # 12.3: Response to INVITE Requests with Multiple Join Headers Test # 12.4: Response to Join Headers not within an INVITE Request Test # 12.5: INVITE with Join Header with no Match Group 13: Reliable Provisional Responses Test # 13.1: Correct Generation of Reliable Provisional Response Messages Test # 13.2: Correct Behavior For Unmatched PRACK Request Test # 13.3: Correct Generation of PRACK Request Group 14: Event Notification Test # 14.1: Correct Generation of SUBSCRIBE Request Test # 14.2: Refreshing Subscriptions Test # 14.3: Removing a Subscription Test # 14.4: Reception and Processing of a SUBSCRIBE Request Test # 14.5: Reception of an Unsupported Event Package Test # 14.6: Correct Generation of a NOTIFY Request Test # 14.7: Reception of a NOTIFY Request Test # 14.8: Reception of a NOTIFY Request With an Invalid Event Header Group 15: The REFER Method Test # 15.1: Generation of a REFER Request Test # 15.2: Reception of a REFER Request Group 16: Session Description Protocol Test # 16.1: Correct Formatting of SDP Offer Test # 16.2: Generation of Correct SDP Answer Test # 16.3: Generation of Rejected SDP Answer Test # 16.4: SDP Offer Containing Send Only Request Test # 16.5: SDP Offer Containing Receive Only Request Test # 16.6: SDP Offer Request No Media Group 17: The UPDATE Method Test # 17.1: Correct Handling of Consecutive UPDATE Requests Test # 17.2: UPDATE Requests and the Allow Header Field Test # 17.3: Sending UPDATE Requests before Session Establishment Test # 17.4: Handling UPDATE Requests while unanswered Offers still exist Test # 17.5: Correct Response Generation of Session Changes with UPDATE Test # 17.6: Correct Handling of Session Changes with UPDATE Test # 17.7: Unacceptable Session Description in UPDATE Request Test # 17.8: Correct Handling of UPDATE with a non-2xx final response Test # 17.9: Termination of Dialog with UPDATE and non-2xx Final Responses Test # 17.10: Correct Handling of a 491 response to UPDATE

7 Introduction The University of New Hampshire Overview The University of New Hampshire s (UNH-IOL) is an institution designed to improve the interoperability of standards based products by providing an environment where a product can be tested against other implementations of a standard. This suite of tests has been developed to help implementers evaluate the conformance of their SIP Endpoint Implementations. The success metrics of these tests are based on the standards referenced in this document. Successful completion of all tests contained in this suite does not guarantee that the tested device will operate with other devices. However, these tests provide a reasonable level of confidence that the Device Under Test will function well in most multivendor environments. Organization of Tests: Each test contains an identification section that describes the test and provides cross-reference information. The discussion section covers background information and specifies why the test is to be performed. Tests are grouped in order to reduce setup time in the lab environment. Each test contains the following information: Test Number The Test Number associated with each test follows a simple grouping structure. Listed first is the Test Group Number followed by the test's number within the group. This allows for the addition of future tests to the appropriate groups of the test suite without requiring the renumbering of the subsequent tests. Purpose The purpose is a brief statement outlining what the test attempts to achieve. This also includes background information on why one needs to perform such a test to show that the device complies with the standard. References The references section lists standards and other documentation that might be helpful in understanding and evaluating the test and results. Resource Requirements The requirements section specifies the hardware, and test equipment that will be needed to perform the test. The items contained in this section are special test devices or other facilities, which may not be available on all devices. Last Modification This specifies the date of the last modification to this test. Test Layout The setup section describes the configuration of the test environment. Small changes in the configuration should be included in the test procedure. Discussion The discussion section is optional. It is a general discussion of the test and relevant section of the specification, including any assumptions made in the design or implementation of the test as well as known limitations. Procedure The procedure section of the test description contains the step-by-step instructions for carrying out the test. It provides a cookbook approach to testing, and may be interspersed with observable results. Test Metrics The test metrics section lists the necessary parameters for success in a given test. When multiple values are possible for a specific event, this section provides a short discussion on how to interpret them. The tests are structured so that failure of one test metric will result in a failure for the entire test, or a request to refer to comments. Possible Problems This section contains a description of known issues with the test procedure, which may affect test results in certain situations. 7

8 References [1] Internet Engineering Task Force (IETF). Request for Comments (RFC) 3261: Session Initiation Protocol (SIP), June [2] Internet Engineering Task Force (IETF). Request for Comments (RFC) 2327: Session Description Protocol (SDP), April [3] Internet Engineering Task Force (IETF). Request for Comments (RFC) 3666: Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows, December [4] Internet Engineering Task Force (IETF). Request for Comments (RFC) 2976: The SIP INFO Method, October [5] Internet Engineering Task Force (IETF). Request for Comments (RFC) 3911: The Session Initiation Protocol (SIP) Join Header, October [6] Internet Engineering Task Force (IETF). Request for Comments (RFC) 3262: Reliability of Provisional Responses in Session Initiation Protocol (SIP), June [7] Internet Engineering Task Force (IETF). Request for Comments (RFC) 3265: Session Initiation Protocol (SIP)-Specific Event Notification, June [8] Internet Engineering Task Force (IETF). Request for Comments (RFC) 3515: The Session Initiation Protocol (SIP) Refer Method, April [9] Internet Engineering Task Force (IETF). Request for Comments (RFC) 3264: An Offer/Answer Model Session Description Protocol, June [10] Internet Engineering Task Force (IETF). Request for Comments (RFC) 3311: The Session Initiation Protocol (SIP) UPDATE Method, September

9 Terms: Definitions and Abbreviations Definitions Callee Caller Dialog Message Method Request Response Session SIP Transaction UA (User Agent) UAC (User Agent Client) UAS (User Agent Server) URI (Universal Resource Indicator) The endpoint at which the call is received. The endpoint at which the call process is started. A dialog is a peer-to-peer SIP relationship between two UAs that persists for some time. A dialog is established by SIP messages, such as a 2xx response to an INVITE request. A dialog is identified by a call identifier, local tag, and a remote tag. Data sent between SIP elements as part of the protocol. SIP messages are either requests or responses. The method is the primary function that a request is meant to invoke on a server. The method is carried in the request message itself. Example methods are INVITE and BYE. A SIP message sent from a client to a server, for the purpose of invoking a particular operation. A SIP message sent from a server to a client, for indicating the status of a request sent from the client to the server. From the SDP specification: "A multimedia session is a set of multimedia senders and receivers and the data streams flowing from senders to receivers. A multimedia conference is an example of a multimedia session." (RFC 2327 [1]) (A session as defined for SDP can comprise one or more RTP sessions.) As defined, a callee can be invited several times, by different calls, to the same session. If SDP is used, a session is defined by the concatenation of the SDP user name, session id, network type, address type, and address elements in the origin field. A SIP transaction occurs between a client and a server and comprises all messages from the first request sent from the client to the server up to a final (non-1xx) response sent from the server to the client. If the request is INVITE and the final response is a non-2xx, the transaction also includes an ACK to the response. The ACK for a 2xx response to an INVITE request is a separate transaction. A logical entity that can act as both a user agent client and user agent server A user agent client is a logical entity that creates a new request, and then uses the client transaction state machinery to send it. The role of UAC lasts only for the duration of that transaction. In other words, if a piece of software initiates a request, it acts as a UAC for the duration of that transaction. If it receives a request later, it assumes the role of a user agent server for the processing of that transaction. A user agent server is a logical entity that generates a response to a SIP request. The response accepts, rejects, or redirects the request. This role lasts only for the duration of that transaction. In other words, if a piece of software responds to a request, it acts as a UAS for the duration of that transaction. If it generates a request later, it assumes the role of a user agent client for the processing of that transaction. Generally, a formatted string which provides information on how to access a particular resource. A SIP URI is in the form: sip:username@network-address.com and is the primary method of locating users on the Internet. 9

10 Abbreviations LAN RTP SDP SIP UDP URI VLAN WAN The University of New Hampshire Local Area Network Real Time Protocol Session Description Protocol Session Initiation Protocol User Datagram Protocol Uniform Resource Identifier Virtual LAN Wide Area Network 10

11 Test Setups The University of New Hampshire Test Setup 1: General Test Setup Unless specified within a particular test, all tests in this test suite use the same physical network configuration, network topology and device configuration. The DUT, within the context of this test suite, is an implementation of a SIP endpoint device conformant to RFC Given the narrow scope of this test suite, there are only two primary components required for each test. The first is the Device Under Test (DUT); the second is a programmatically configured SIP user agent (SIP Endpoint) capable of fine-tuning the contents of SIP elements such a headers, requests, transactions and dialogs. Configuration Settings Parameter SIP Endpoint DUT SIP URI sip:ep@sftf-endpoint sip:dut@dut-endpoint Proxy Server None None Registrar None None IP Address Transport UDP UDP Port

12 Test Setup 2: Setup for Three Party Interaction The University of New Hampshire This purpose of this test setup is for tests involving three parties. The tests using this setup are optional tests and are not required in order to pass our. These optional tests address extensions to the SIP protocol that are not required to be supported in order to be considered compliant with the SIP protocol. The DUT, within the context of this test suite, is an implementation of a SIP endpoint device conformant to RFC This test suite does not assess or validate registrar functionality, proxy server functionality or redirect functionality. In the tests using this setup there are three primary components required for each test. The first is the Device Under Test (DUT); the second and third are programmatically configured SIP user agents (SIP Endpoints) capable of fine tuning the contents of SIP elements such a headers, requests, transactions and dialogs. Configuration Settings Parameter SIP Endpoint 1 SIP Endpoint 2 DUT SIP URI sip:ep1@sftf-endpoint sip:ep2@sftf-endpoint sip:dut@dut-endpoint Proxy Server None None None Registrar None None None IP Address Transport UDP UDP UDP Port

13 Group 1: Core Message Formatting Scope: The following tests focus on the core message and formatting elements of SIP. This includes header formatting, Request-URI and response status lines. Overview: This group of tests represents core message requirements. While these tests do not cover any testing of state machines or contextual behaviors, they do verify that a UA can parse and generate well formed SIP messages. 13

14 Test # 1.1: Correct Formatting of Request Line in INVITE Requests Purpose: This test verifies the correct formatting of the Request line in SIP INVITE requests. [1] Section 7.1 (RFC 3261) Last Modification: October 10, 2005 This test verifies the correct formatting of SIP Request lines. SIP Request lines must contain a defined SIP Method (eg, REGISTER, INVITE, ACK, CANCEL) followed by the Request-URI and SIP-Version string (eg SIP/2.0). At the end of the string, CR/LF characters must be inserted. 1. Send INVITE request from DUT to the SIP Endpoint. 2. Respond with a "603 Deny" from the SIP Endpoint. 1. Verify that the INVITE request was sent to the SIP Endpoint. 2. Ensure that the Request line is identical to: "INVITE sip:ep@sftf-endpoint SIP/2.0 [CRLF]" A reason phrase may be inserted between the "SIP/2.0" and the [CRLF]. This would not cause the test to fail. 14

15 Test # 1.2: Correct Formatting of Status Line in Response Messages Purpose: This test verifies correct formatting of the status line in SIP response messages. [1] Section 7.2 (RFC 3261) Last Modification: October 10, 2005 This test verifies that the status line, in response messages, is structured in accordance to RFC The status line must contain a SIP Version string, a status code, and CR/LF line endings. The status line may also contain a human readable descriptive string, which provides a textual justification of the status code. 1. Send an OPTIONS request from the SIP Endpoint to the DUT. 2. Wait for a response from the DUT. 1. Verify that the DUT responded with a "200 OK" response message. 2. Ensure that the status line in the SIP response message is identical to: "SIP/ OK [CRLF]" Possible Problems A reason phrase may be inserted between the "200 OK" and the [CRLF]. This would not cause the test to fail. 15

16 Test # 1.3: Verify Correct Header Field Formatting Purpose: This test verifies the text formatting of SIP header fields. [1] Section 7.3 (RFC 3261) Last Modification: October 10, 2005 Header fields provide all of the programmatic state and routing information necessary for SIP to function, and thus the must be correct formatting. SIP uses a format identical to HTTP with respect to header fields; simply, key value pairs separated by a colon and ending with a new-line character. 1. Send an OPTIONS request from the SIP Endpoint to the DUT. 2. Wait for a response from the DUT. 1. Verify the correctness of the header fields returned in the response message. 2. Ensure that the status line in the SIP response message is identical to: "SIP/ OK [CRLF]" A reason phrase may be inserted between the "200 OK" and the [CRLF]. This would not cause the test to fail. 16

17 Test # 1.4: Verify Inclusion of Necessary Header Field Purpose: This test verifies that the DUT includes the necessary, core, header fields. [1] Section (RFC 3261) Resource Requirements Last Modification: October 10, 2005 Although the majority of SIP header fields are optional and serve informational purposes, some header fields are necessary. For SIP messages to be meaningful and routed correctly to all elements in a SIP session, certain header fields are required. This test verifies that the core header fields are included in OPTIONS responses. 1. Send an OPTIONS request to DUT from the SIP Endpoint. 2. Wait for a response message from the DUT. 1. Verify that a properly formatted "200 OK" Response message was received. 2. Verify the existence of the following headers in the SIP response message: To, From, CSeq, Call-ID, and Via. None 17

18 Test # 1.5: Ability to Process Compact Header Fields Purpose: This test verifies that the DUT is capable of receiving and processing header fields in their compact form. [1] Section (RFC 3261) Last Modification: October 10, 2005 All user agent implementations must be able to parse compact header fields. The compact header fields serve the same function as typical header fields, but are composed in a more compact form. The aim of this test is to ensure that the DUT can receive an OPTIONS request in which all headers designed in their compact form. For example, the 'Via' header becomes simply 'v'. 1. Send an OPTIONS request to the DUT formatted such that all headers are in compact form. 2. Wait for a response from the DUT. 1. Verify that the DUT responded with a "200 OK" response message. None 18

19 Test # 1.6: Verify inclusion and correctness of Content-Type header Purpose: This test ensures the DUT includes a correct Content-Type header field. [1] Section (RFC 3261) Last Modification: October 10, 2005 SIP messages, like HTTP, can carry a data payload in their body, the most common data payload being an SDP (Session Description Protocol) type, though binary or MIME (Multipurpose Internet Mail Extension) types may be included. Given the flexibility of SIP, it is important that user agents accurately describe the type of data payloads that they are providing. 1. Issue an INVITE request from the DUT to the SIP Endpoint. 2. Respond with a "603 Decline" message to close the transaction. 1. Verify that the Content-Type header field was present in the headers of the INVITE message. 2. Ensure that the Content-Type header field correctly describes the message body. None 19

20 Group 2: Core UAC Behavior The University of New Hampshire Scope: Tests within this group focus on the behavior of the DUT when acting as a UAC. Overview: The following tests assess how the DUT behaves when acting as a UAC. These tests are method independent and do not specifically test any of the SIP methods defined in the standard. The objective is to test base SIP requirements when generating any type of request message. 20

21 Test # 2.1: UAC Call-ID Creation Purpose: This test verifies that the DUT, when acting as a UAC, correctly generates a Call-ID identifier outside of a SIP dialog. [1] Section (RFC 3261) Last Modification: October 10, 2005 The Call-ID header field is instrumental in identifying a SIP dialog and providing state information for proxy servers. The only requirement for the Call-ID header field is that it be globally unique, though this is difficult to test with confidence. Therefore, this test uses a heuristic approach to determine that a given Call-ID is globally unique. 1. Issue an INVITE request from the DUT to the SIP Endpoint. 2. Respond with an error response "603" from the SIP Endpoint. 3. Issue a second INVITE request from the DUT to the SIP Endpoint. 4. Respond with an error response "603" from the SIP Endpoint. 1. Ensure that the Call-ID Header field is present in each of the INVITE messages. 2. Ensure that the Call-ID number in each INVITE message is completely unique. None 21

22 Test # 2.2: CSeq Generation The University of New Hampshire Purpose: This test verifies that when issuing a new request the DUT creates an appropriate CSeq header field. [1] Section (RFC 3261) Last Modification: October 10, 2005 The CSeq header identifies and orders transactions within SIP communication. The CSeq header consists of two distinct components: an integer number less than 2**31 and an identifier referring to a SIP request method. CSeq requirements change when inside a SIP dialog, however, that is outside the scope of this test. 1. Issue an INVITE request from the DUT to the SIP Endpoint 2. Respond with a "603 Decline" message to the DUT to terminate the transaction. 1. Verify that the CSeq field is present in the INVITE message from the DUT. 2. Verify that the contents of the CSeq fields consists of two elements, an integer that is less than 2**31 and a Request method, joined by a single space. 3. Verify that the Request method referenced in the CSeq field is INVITE. None 22

23 Test # 2.3: Max-Forwards The University of New Hampshire Purpose: This test verifies that a UAC originating a Request includes an appropriate Max-Forwards header field. [1] Section (RFC 3261) Last Modification: October 10, 2005 The Max-Forwards header field ensures that SIP proxy routing loops do not occur in complicated configurations. It is recommended that the value of the Max-Forwards header be set at 70. The only requirement for this test is that the value is not less than Issue an INVITE request from the DUT to the SIP Endpoint 2. Respond with a "603 Decline" message to the DUT to terminate the transaction. 1. Verify that the Max-Forwards header is present in the INVITE request message. 2. The Max-Forwards value should be set to 70. If it does not have a value of 70 ensure that it is an integer value not below 70. Possible Problems None 23

24 Test # 2.4: Inclusion of Appropriate Via Header Purpose: This test verifies the correctness of the Via inserted by a UAC when making a Request. [1] Section (RFC 3261) Last Modification: October 10, 2005 The Via header is critical to the correct functioning of the SIP protocol. Along with describing the lower level transport and network address information, the Via header provides necessary state information for SIP transactions. This test verifies that all components in the Via header of an INVITE request are compliant. 1. Issue an INVITE request from the DUT to the SIP Endpoint. 2. Respond with a "603 Decline" message to the DUT to terminate the transaction. 1. Verify that the Via header is present in the INVITE request message. 2. Ensure that the Via header is formatted properly. The Via header must contain "SIP/2.0/UDP", where UDP is the transport layer. UDP could also be TCP if TCP has been configured. The next element must be the source IP address and port separated by a colon. Following a semicolon, a branch parameter must be present. 3. The branch parameter must be globally unique and start with the characters "z9hg4bk". None 24

25 Test # 2.5: Inclusion of Appropriate Contact Header Purpose: This test verifies that the DUT, when acting as a UAC, includes an appropriate Contact header. [1] Section (RFC 3261) Last Modification: October 10, 2005 The Contact header field describes the SIP or SIPS URI that the originating UA can be contacted at. This is used both in a request establishing a dialog, registrations and redirects. The Contact header must be present in INVITE messages and be globally unique and accessible. 1. Issue an INVITE request from the DUT to the SIP Endpoint 2. Cancel the session from the SIP Endpoint. 1. Verify that the Contact header is present in the INVITE request message. 2. Verify that the Contact header's content is set to a valid and unique SIP or SIPS URI. None 25

26 Test # 2.6 General Expire Header Purpose: This test verifies that when issuing a new request the DUT sends an Expire header [1] Section (RFC 3261) [11] Section (RFC 4475) Last Modification: August 16, 2006 An Expire header is used to control the validity of a request particularly invites. When an invite is sent an Expire header can be created with a set amount of time. When the header is created a timer is started. When the timer reaches the same time as the Expire header value, the UAC creates a cancel message for the particular invite. 1. Issue an INVITE request from the DUT to the SIP Endpoint. 2. Terminate the Connection. 1. Verify that the INVITE request contained a valid expire header. This test is governed by a MAY or a SHOULD instead of a MUST and is therefore not necessary for complete conformance. 26

27 Test # 2.7 Timestamp Header The University of New Hampshire Purpose: This test verifies that when issuing a new request or forwarding an existing request the DUT creates a valid timestamp value. [1] Section (RFC 3261) [11] Section (RFC 4475) Last Modification: August 16, 2006 A timestamp value is updated when a proxy or registry server forwards a message. This is used to mark the time of the forwarding so the time in between registries can be recorded. Test Layouts Setup 1. Issue an INVITE request from the DUT to the SIP Endpoint. 2. Terminate the Connection. 1. Verify that the INVITE request contained a valid, updated timestamp header. This test is governed by a MAY or a SHOULD instead of a MUST and is therefore not necessary for complete conformance. 27

28 Test # 2.8: UAC Inserted Supported and Require Headers Purpose: This test verifies the correctness and proper use of the Supported and Require headers in an INVITE request. [1] Section (RFC 3261) Last Modification: October 10, 2005 In order to deal with extensions and behaviors defined outside the scope of RFC 3261, the Supported and Require headers provide mechanisms that allow the negotiation of extended features. Certain safeguards are built into the RFC to ensure basic interoperability between devices that may implement proprietary extensions. 1. Issue an INVITE request from the DUT to the SIP Endpoint 2. Respond with a "603 Deny" message from the SIP Endpoint to the DUT. 1. If a Supported header field is present, ensure that the options listed are RFCs and not proprietary extensions. 2. If a Required header field is present, ensure that the options listed are RFCs and not proprietary extensions. None 28

29 Test # 2.9: Correct Handling of Multiple Via Headers Purpose: This test verifies that the DUT handles multiple Via headers correctly. [1] Section (RFC 3261) Last Modification: October 10, 2005 Via headers are inserted and deleted as SIP proxy elements route messages between one another. If a UAC receives a SIP response message, which has multiple Via headers, this implies that the message is either corrupt or intended to be sent to another proxy server. In this case, it is recommended that the response message be discarded. 1. Configure the SIP Endpoint to respond with a duplicate Via header. 2. Issue an INVITE request from the DUT to the SIP Endpoint. 3. Respond with a "200 OK" message that contains an extra, incorrect Via header. 1. Ensure that the DUT discards the message with multiple Via headers. None 29

30 Test # 2.10: Correct Handling of 300 (Redirect) Responses Purpose: This test verifies that the DUT acts accordingly after receiving a 300 (Redirect) response. [1] Section (RFC 3261) (EP1) SIP Redirect Server Last Modification: October 10, 2005 Redirection is a key component behavior of the SIP protocol. In some network infrastructures it may make sense to have dedicated redirect servers, which hold no programmatic state but only serve to help SIP clients locate their destination. Upon receiving a redirect response message, the UAC client should send a new INVITE to the SIP URI in the Contact header of the response. 1. Configure the SIP Redirect server to redirect sip:redir@sip-redirect to sip:ep1@sip-endpoint 2. Issue an INVITE request from the DUT to sip:redir@sip-redirect 3. Wait for an INVITE request sent from the DUT to the SIP Endpoint. 4. Respond with a "3xx Redirected" error response to the DUT's INVITE request. 1. Verify that a new INVITE request was sent to sip:ep1@sip-endpoint as a result of receiving a 3xx redirect message. 2. Verify that the new INVITE request's Request-URI is identical to the Contact field of the UAS's 3xx redirect message. 3. Ensure that a new branch id was generated by the DUT. The device may not be able to send a re-invite, which would not result in a failure of this test. 30

31 Test # 2.11: Correct Handling of 413 Request Entity Too Large Response Purpose: This test verifies that the DUT acts accordingly after receiving a 413 response code. [1] Section (RFC 3261) (EP1) SIP Redirect Server Last Modification: July 18, 2006 It is possible that a UAS could receive a SIP body, which is larger than it is willing to accept. In this case, the UAS will respond with a 413 Request Entity Too Large error response. It is the responsibility of the UAC to retransmit the request with an appropriately sized SIP body or omitting the SIP body (if appropriate). 1. Configure the DUT to send a SIP SDP body of arbitrary size. 2. Configure the SIP Endpoint to respond with a 413 response code. 3. Send an INVITE request from the DUT to the SIP Endpoint. 1. Verify that the INVITE request transmitted from the DUT to the SIP Endpoint contained a SIP body. 2. Verify that the UAS responded with a 413 response message. 3. Verify that the DUT issued a new INVITE request with a smaller body. 4. Ensure that the newly issued INVITE request contains the same Call-ID, To and From headers as the first INVITE request. 5. Ensure that the newly issued INVITE request increments the CSeq header. None 31

32 Test # 2.12: Correct Handling of 415 Unsupported Media Type Response Purpose: This test verifies that the DUT acts accordingly after receiving a 415 response code. [1] Section (RFC 3261) (EP1) SIP Redirect Server Last Modification: October 10, 2005 If a UAC specifically requires the use of a codec that the UAS does not support, the UAS will respond with a 415 Unsupported Media Type error response message. Included in the response message is an Accept header which specifies supported media types. If possible, the UAC should retransmit the request specifying a codec which is supported by the UAS. 1. Configure the DUT to send an INVITE with an SDP payload, which only includes the GSM codec. 2. Configure the SIP Endpoint to reject all codecs besides G.711 PCMU. 3. Send an INVITE request from the DUT to the SIP Endpoint. 1. Verify that the INVITE response message requires GSM data. 2. Verify that a 415 Unsupported Media response message was sent from the SIP Endpoint. 3. Check if the DUT resends the INVITE request with the G.711 codec in the SDP payload. It is also acceptable for the DUT to issue an ACK request ending the transaction. 4. Ensure that the newly issued INVITE request contains the same Call-ID, To and From headers as the first INVITE request. 5. Ensure that the newly issued INVITE request increments the CSeq header. None 32

33 Test # 2.13: Correct Handling of 420 Bad Extension Response Purpose: This test verifies that the DUT acts accordingly after receiving a 420 response code. [1] Section (RFC 3261) (EP1) SIP Redirect Server Last Modification: October 10, 2005 If a UAC sends an INVITE request containing a required option that the UAS does not support then the UAS must issue a 420 Bad Extension response to the request. According to RFC 3261 the UAC should then reissue the request omitting the option that was not supported. 1. Configure the DUT to send an INVITE with a Require Header field set to a specific option. 2. Configure the SIP Endpoint to reject any INVITE request, which specifies an extension in the Require Header. 3. Send an INVITE request from the DUT to the SIP Endpoint. 1. Verify that the INVITE request from the DUT contains a Require header field with an arbitrary option set. 2. Verify that the SIP Endpoint responds with an appropriate 420 Bad Extension response message. 3. Ensure that the DUT retransmits the INVITE request, omitting the Require option. It is also acceptable for the DUT to issue an ACK request ending the transaction. 4. Ensure that the newly issued INVITE request contains the same Call-ID, To and From headers as the first INVITE request. 5. Ensure that the newly issued INVITE request increments the CSeq header. None 33

34 Test # 2.14: Correct Handling of 416 Unsupported URI Scheme Response Purpose: This test verifies that the DUT acts accordingly after receiving a 416 response code. [1] Section (RFC 3261) (EP1) SIP Redirect Server Last Modification: July 25, 2006 If a UAC issues an INVITE request using a URI Scheme not supported by the UAS then the UAS will respond with a 416 Unsupported URI Scheme response. According to RFC 3261 the UAC should then reissue the request using a SIP URI. 1. Configure the DUT to send an INVITE request with a SIP URI. 2. Send an INVITE request from the DUT to the SIP Endpoint. 3. Configure the SIP Endpoint to respond to the INVITE with a 416 Unsupported URI Scheme response message. 1. Verify that the INVITE request sent from the DUT contains a SIP URI. 2. Verify that the SIP Endpoint responds with a 416 Unsupported URI Scheme response message. 3. Ensure that the DUT reissues the INVITE response with a new SIP URI. 4. Ensure that the newly issued INVITE request contains the same Call-ID, To and From headers as the first INVITE request. 5. Ensure that the newly issued INVITE request increments the CSeq header. None 34

35 Group 3: Core UAS Behavior The University of New Hampshire Scope: The following tests focus on the behavior of the DUT when acting as a UAS. Overview: The following tests assess how the DUT behaves when acting as a UAS. These tests are method independent and do not specifically test any of the SIP methods defined in the standard. The objective is to test base SIP requirements when responding to SIP requests in general. 35

36 Test # 3.1: 100 Provisional Responses to INVITES Purpose: This test verifies that the DUT correctly implements provisional responses. [1] Section (RFC 3261) Last Modification: October 10, 2005 Provisional (1xx) responses establish notification back to the UAC that the request is being fielded. It is only appropriate to issue provisional responses when responding to INVITE requests. If a timestamp header field is present in the INVITE request, then this value must be copied to the response message and incremented accordingly. 1. Send an INVITE from the SIP Endpoint to the DUT. 2. Verify that a provisional response is sent in reply to the original INVITE request. 3. Send a CANCEL request from the SIP Endpoint to terminate the INVITE request. 1. Ensure that a 100 series Trying response is generated from the DUT. 2. Verify that the Timestamp header field is accurate. None 36

37 Test # 3.2: 200 Responses The University of New Hampshire Purpose: This test verifies that the DUT returns an appropriate 200 class final response to an OPTIONS request. [1] Section (RFC 3261) Last Modification: October 10, 2005 The "200 OK" response is a final, positive response. When in response to an INVITE request, the "200 OK" response indicates the establishment of a dialog. Within the context of this test, the "200 OK" response only indicates a final response and not the establishment of a dialog. 1. Send an OPTIONS request from the SIP Endpoint to the DUT. 2. Wait for a "200 OK" response from the DUT. 1. Verify that the DUT responded with a "200 OK" response message. None 37

38 Test # 3.3: Behavior When an Unsupported Request is Received Purpose: This test verifies that the DUT, when acting as a UAS, operates accordingly when receiving a request that is not supported by the DUT. [1] Section (RFC 3261) Last Modification: October 10, 2005 In order to be certain that user agents are able to interoperate with one another, it is necessary to define behaviors that support negotiation of capabilities. If a UAS receives a request that is a valid, non proprietary extension but one which the UAS does not support, then the UAS must respond with a "405 Method Not Allowed". 1. Send a request that the DUT is known not to implement, eg, BOGUSREQUEST 1. Verify that the DUT sends a "405 Method Not Allowed" response to the SIP Endpoint. 2. The DUT must include an Allow header field in the response listing what requests are allowed. The DUT may respond with a message other than "405" 38

39 Test # 3.4: UAS Header Inspection Purpose: Verify that the DUT correctly ignores malformed or unknown headers. [1] Section (RFC 3261) Last Modification: October 10, 2005 A UAS should ignore any header fields, which it does not understand. Extraneous header fields do not necessarily impact interoperability; a UAS should ignore malformed header fields if they are not necessary. 1. Send an OPTIONS request to the DUT including a header "Fake-Header" with the contents "Ignore". 2. Wait for a response from the DUT. 1. Verify that the DUT ignores the invalid header by responding with a "200 OK" response message. The DUT may issue an error response. 39

40 Test # 3.5: Reception of Invalid Request-URI Purpose: This test verifies that the correct response message is generated when the DUT receives a request for a SIP URI that it does not control. [1] Section (RFC 3261) Last Modification: October 10, 2005 The Request-URI identifies the UA, which the request is intended for. If a UAS receives a request containing a Request-URI, which is not located at the UAS, the UAS must respond with a "404 Not Found" error response message. This behavior is consistent across requests, which establish dialogs, and requests that don't. For this test, an OPTIONS request is used to trigger the desired "404 Not Found" response. 1. Send an OPTIONS request to the DUT using the SIP URI: "sip:bogusrequest@dut-endpoint". 2. Wait for a response from the DUT. 1. Verify that the DUT responds with a "404 Not Found" error response. None 40

41 Test # 3.6: Require Header Processing Purpose: This test verifies that the DUT correctly operates when a Require header specifies an extension unsupported by the DUT. [1] Section (RFC 3261) Last Modification: October 10, 2005 Since SIP can support arbitrary extensions, it is important that user agents can determine whether or not their peer can support a given extension. A UAC client is required to include a Require header field if it plans on needing a certain extension. If the UAS, after parsing the Require header, determines that it does not support the desired extension is must send a response to the UAC of "420 Bad Extension." 1. Send an OPTIONS request to the DUT from the SIP Endpoint which includes a Require header option of BOGUSEXTENSION 2. Wait for a response from the DUT. 1. Verify that the DUT responds with a "420 Bad Extension" response. 2. Verify that BOGUSEXTENSION is listed in the Unsupported header field of the error response. The DUT may not issue an error response. 41

42 Test # 3.7: Require Header Processing in CANCEL Request Purpose: This test verifies that the DUT correctly operates when receiving a CANCEL request which contains unsupported options in the Require header. [1] Section (RFC 3261) Last Modification: October 10, 2005 Since SIP can support arbitrary extensions, it is important that user agents can determine whether or not their peer can support a given extension. Unlike the previous test, however, a Require header in a CANCEL request is not conformant to RFC Thus, a UAS receiving a Require header describing an extension it does not support should NOT send a "420 Bad Extension". 1. Send an INVITE request from the SIP Endpoint to the DUT in order to initiate a dialog. 2. Send a CANCEL request to the DUT from the SIP Endpoint which includes a Require header option of BOGUSEXTENSION 1. Verify that the DUT responds with a "200 OK" response, correctly ignoring the BOGUSEXTENSION option. The DUT may respond in the same way as the previous test. 42

43 Test # 3.8: Provisional Responses on Non INVITE Requests Purpose: This test verifies that provisional responses are not sent after receiving a non INVITE request. [1] Section (RFC 3261) Last Modification: October 10, 2005 SIP defines provisional responses as a way to inform the user about the state of the session. Only INVITE request should be answered with provisional responses, if the initial request method is not an INVITE, then the UAS should only send a final response. 1. Send an OPTIONS request from the SIP Endpoint to the DUT. 2. Wait for a return response from the SIP Endpoint. 1. Verify that DUT does not respond with a "100 Trying" response. None 43

44 Test # 3.9: Handling of Header Fields in Responses Purpose: This test verifies conformant behavior in the handling of the From, Call-ID, CSeq, Via and To headers in responses generated by the DUT. [1] Section (RFC 3261) Last Modification: October 10, 2005 The content and inclusion of header fields in a response message is well defined: From, Call-ID, CSeq and Via headers must be identical. In addition, the To header requires special consideration. If there is no To header tag in the initial request then one must be added; otherwise the To header remains the same. 1. Send an OPTIONS request to the DUT from the SIP Endpoint. Ensure that there is no To header tag in the request. 2. Wait for a response from the DUT. 1. Verify that the From header field in the response is identical to the From header in the request. 2. Verify that the URI in the To header field in the response is identical to the URI in the To header in the request. 3. Ensure that the To header has an appropriate Tag parameter in the response. 4. Verify that the CSeq header field in the response is identical to the CSeq header in the request. 5. Verify that the Call-ID header field in the response is identical to the Call-ID header in the request. 6. Verify that the Via header(s) field in the response is identical to the Via header(s) in the request. 7. Verify that the order of the Via headers is preserved form the request. None 44

45 Group 4: CANCEL Request The University of New Hampshire Scope: The following tests pertain to CANCEL requests; with the DUT acting in UAS and UAC roles. Overview: The following tests verify that the generation of CANCEL requests and the reception of CANCEL requests are conformant to the standard. CANCEL requests can reference any SIP request, which establishes a dialog. However, since RFC 3261 only provides the INVITE method to establish dialogs all CANCEL requests tested are assumed to cancel INVITE requests. 45

46 Test # 4.1: Generation of CANCEL Requests Purpose: This test assesses the correct generation of a CANCEL request when the DUT is acting as a UAC. [1] Section 9.1 (RFC 3261) Last Modification: October 10, 2005 The CANCEL request serves to stop the establishment of a session initiated by an INVITE request. If a UAC places a call and then wishes to cancel the call before it receives a final response from the UAS, a CANCEL request is necessary. CANCEL requests trigger two responses when sent to a UAS: a 487 final response to the original INVITE and a 200 response to the CANCEL itself. 1. Send an INVITE request from the DUT to SIP Endpoint. 2. Send a CANCEL request from the DUT to the SIP Endpoint. 3. Send a "487 Request Terminated" message to the DUT in response to the INVITE. 4. Send a "200 OK" response to the CANCEL request. 1. Ensure that the Request-URI is identical to the issued INVITE request. 2. Ensure that the Call-ID and To fields are identical to the INVITE request. 3. Ensure that the CSeq header field contains the same numerical part as the CSeq header in the INVITE request. The method part must be 'CANCEL' 4. Verify that the Via header in the CANCEL message is identical to the Via header in the INVITE request. 5. Verify that the CANCEL request did not include either a Require or Proxy-Require header field. None 46

47 Test # 4.2: CANCEL Request Without Provisional Responses Purpose: This test ensures that the DUT does not send a CANCEL request when it has not received a "100" provisional response from the UAS. [1] Section 9.1 (RFC 3261) Last Modification: October 10, 2005 CANCEL requests must be sent before a final response has been received from the UAS but they also must be sent after at least one provisional response has been received from the UAS. This is necessary to ensure the correct ordering of the SIP message flow. Since the most common transport for SIP is UDP (User Datagram Protocol), there is a small chance that a CANCEL sent before the reception of a provisional response could result in the CANCEL arriving before the INVITE it cancels. 1. Configure the SIP Endpoint not to send "100" provisional responses. 2. Send an INVITE request from the DUT to SIP Endpoint. 3. Issue the defined command on the DUT, which cancels an INVITE. Note that for this test the CANCEL message should not be sent. 1. Verify that a CANCEL request was not sent. None 47

Department of Computer Science. Burapha University 6 SIP (I)

Department of Computer Science. Burapha University 6 SIP (I) Burapha University ก Department of Computer Science 6 SIP (I) Functionalities of SIP Network elements that might be used in the SIP network Structure of Request and Response SIP messages Other important

More information

SIP Compliance APPENDIX

SIP Compliance APPENDIX APPENDIX E This appendix describes Cisco SIP proxy server (Cisco SPS) compliance with the Internet Engineering Task Force (IETF) definition of Session Initiation Protocol (SIP) as described in the following

More information

Session Initiation Protocol (SIP) Overview

Session Initiation Protocol (SIP) Overview Session Initiation Protocol (SIP) Overview T-110.7100 Applications and Services in Internet 5.10.2010 Jouni Mäenpää NomadicLab, Ericsson Research Contents SIP introduction, history and functionality Key

More information

Compliance with RFC 3261

Compliance with RFC 3261 APPENDIX A Compliance with RFC 3261 This appendix describes how the Cisco Unified IP Phone 7960G and 7940G complies with the IETF definition of SIP as described in RFC 3261. It contains compliance information

More information

Session Initiation Protocol (SIP) Overview

Session Initiation Protocol (SIP) Overview Session Initiation Protocol (SIP) Overview T-110.7100 Applications and Services in Internet 6.10.2009 Jouni Mäenpää NomadicLab, Ericsson Contents SIP introduction, history and functionality Key concepts

More information

SIP System Features. SIP Timer Values. Rules for Configuring the SIP Timers CHAPTER

SIP System Features. SIP Timer Values. Rules for Configuring the SIP Timers CHAPTER CHAPTER 4 Revised: March 24, 2011, This chapter describes features that apply to all SIP system operations. It includes the following topics: SIP Timer Values, page 4-1 SIP Session Timers, page 4-7 Limitations

More information

Session Initiation Protocol (SIP)

Session Initiation Protocol (SIP) Session Initiation Protocol (SIP) Introduction A powerful alternative to H.323 More flexible, simpler Easier to implement Advanced features Better suited to the support of intelligent user devices A part

More information

Overview of SIP. Information About SIP. SIP Capabilities. This chapter provides an overview of the Session Initiation Protocol (SIP).

Overview of SIP. Information About SIP. SIP Capabilities. This chapter provides an overview of the Session Initiation Protocol (SIP). This chapter provides an overview of the Session Initiation Protocol (SIP). Information About SIP, page 1 How SIP Works, page 4 How SIP Works with a Proxy Server, page 5 How SIP Works with a Redirect Server,

More information

Chapter 3: IP Multimedia Subsystems and Application-Level Signaling

Chapter 3: IP Multimedia Subsystems and Application-Level Signaling Chapter 3: IP Multimedia Subsystems and Application-Level Signaling Jyh-Cheng Chen and Tao Zhang IP-Based Next-Generation Wireless Networks Published by John Wiley & Sons, Inc. January 2004 Outline 3.1

More information

Session Initiation Protocol (SIP) Basic Description Guide

Session Initiation Protocol (SIP) Basic Description Guide Session Initiation Protocol (SIP) Basic Description Guide - 1 - Table of Contents: DOCUMENT DESCRIPTION... 4 SECTION 1 NETWORK ELEMENTS... 4 1.1 User Agent... 4 1.2 Proxy server... 4 1.3 Registrar... 4

More information

Tech-invite. RFC 3261's SIP Examples. biloxi.com Registrar. Bob's SIP phone

Tech-invite. RFC 3261's SIP Examples. biloxi.com Registrar. Bob's SIP phone Tech-invite http://www.tech-invite.com RFC 3261's SIP Examples V2.2 November 22, 2005 Registrar Bob's SIP INVITE 100 Trying Proxy INVITE 100 Trying Proxy 200 OK INVITE REGISTER This is a representation,

More information

SIP System Features. SIP Timer Values. Rules for Configuring the SIP Timers CHAPTER

SIP System Features. SIP Timer Values. Rules for Configuring the SIP Timers CHAPTER CHAPTER 4 Revised: October 30, 2012, This chapter describes features that apply to all SIP system operations. It includes the following topics: SIP Timer Values, page 4-1 Limitations on Number of URLs,

More information

3GPP TS V ( )

3GPP TS V ( ) 3GPP TS 24.379 V13.1.1 (2016-06) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Networks and Terminals; Mission Critical Push To Talk (MCPTT) call control;

More information

Information About SIP Compliance with RFC 3261

Information About SIP Compliance with RFC 3261 APPENDIX A Information About SIP Compliance with RFC 3261 This appendix describes how the Cisco SIP IP phone complies with the IETF definition of SIP as described in RFC 3261. It has compliance information

More information

TSIN02 - Internetworking

TSIN02 - Internetworking Lecture 8: SIP and H323 Litterature: 2004 Image Coding Group, Linköpings Universitet Lecture 8: SIP and H323 Goals: After this lecture you should Understand the basics of SIP and it's architecture Understand

More information

SIP System Features. Differentiated Services Codepoint CHAPTER

SIP System Features. Differentiated Services Codepoint CHAPTER CHAPTER 6 Revised: December 30 2007, This chapter describes features that apply to all SIP system operations. It includes the following topics: Differentiated Services Codepoint section on page 6-1 Limitations

More information

Journal of Information, Control and Management Systems, Vol. X, (200X), No.X SIP OVER NAT. Pavel Segeč

Journal of Information, Control and Management Systems, Vol. X, (200X), No.X SIP OVER NAT. Pavel Segeč SIP OVER NAT Pavel Segeč University of Žilina, Faculty of Management Science and Informatics, Slovak Republic e-mail: Pavel.Segec@fri.uniza.sk Abstract Session Initiation Protocol is one of key IP communication

More information

ENSC 833-3: NETWORK PROTOCOLS AND PERFORMANCE. Implement Session Initiation Protocol (SIP) User Agent Prototype

ENSC 833-3: NETWORK PROTOCOLS AND PERFORMANCE. Implement Session Initiation Protocol (SIP) User Agent Prototype ENSC 833-3: NETWORK PROTOCOLS AND PERFORMANCE Final Project Presentation Spring 2001 Implement Session Initiation Protocol (SIP) User Agent Prototype Thomas Pang (ktpang@sfu.ca) Peter Lee (mclee@sfu.ca)

More information

Extensions to Session Initiation Protocol (SIP) and Peer-to-Peer SIP

Extensions to Session Initiation Protocol (SIP) and Peer-to-Peer SIP Extensions to Session Initiation Protocol (SIP) and Peer-to-Peer SIP T-110.7100 Applications and Services in Internet 1.10.2008 Jouni Mäenpää NomadicLab, Ericsson Contents Extending SIP SIP extension negotiation

More information

Overview of the Session Initiation Protocol

Overview of the Session Initiation Protocol CHAPTER 1 This chapter provides an overview of SIP. It includes the following sections: Introduction to SIP, page 1-1 Components of SIP, page 1-2 How SIP Works, page 1-3 SIP Versus H.323, page 1-8 Introduction

More information

INTERFACE SPECIFICATION SIP Trunking. 8x8 SIP Trunking. Interface Specification. Version 2.0

INTERFACE SPECIFICATION SIP Trunking. 8x8 SIP Trunking. Interface Specification. Version 2.0 8x8 Interface Specification Version 2.0 Table of Contents Introduction....3 Feature Set....3 SIP Interface....3 Supported Standards....3 Supported SIP methods....4 Additional Supported SIP Headers...4

More information

SIP Network Overview

SIP Network Overview CHAPTER 1 S Network Overview Revised: October 30, 2012, This guide describes the Session Initiation Protocol (S) signaling features supported in Release 6.0.4 of the Softswitch, and explains how to provision

More information

Voice over IP (VoIP)

Voice over IP (VoIP) Voice over IP (VoIP) David Wang, Ph.D. UT Arlington 1 Purposes of this Lecture To present an overview of Voice over IP To use VoIP as an example To review what we have learned so far To use what we have

More information

ROUTING CONSORTIUM. Routing Information Protocol Version 2 (RIP) Multi-System Interoperability Test Suite. Technical Document. Revision 2.

ROUTING CONSORTIUM. Routing Information Protocol Version 2 (RIP) Multi-System Interoperability Test Suite. Technical Document. Revision 2. ROUTING CONSORTIUM Routing Information Protocol Version 2 (RIP) Multi-System Interoperability Test Suite Technical Document Revision 2.2 121 Technology Drive, Suite 2 Durham, NH 03824 Routing Consortium

More information

Internet Engineering Task Force (IETF) S. McGlashan Hewlett-Packard May Media Control Channel Framework. Abstract

Internet Engineering Task Force (IETF) S. McGlashan Hewlett-Packard May Media Control Channel Framework. Abstract Internet Engineering Task Force (IETF) Request for Comments: 6230 Category: Standards Track ISSN: 2070-1721 C. Boulton NS-Technologies T. Melanchuk Rainwillow S. McGlashan Hewlett-Packard May 2011 Media

More information

University of New Hampshire InterOperability Laboratory Ethernet in the First Mile Consortium

University of New Hampshire InterOperability Laboratory Ethernet in the First Mile Consortium University of New Hampshire InterOperability Laboratory As of July 26, 2004 the Ethernet in the First Mile Clause 57 OAM Conformance Test Suite version 0.4 has been superseded by the release of the Clause

More information

Application Notes for Configuring SIP Trunking between Cincinnati Bell Any Distance evantage and Avaya IP Office Issue 1.0

Application Notes for Configuring SIP Trunking between Cincinnati Bell Any Distance evantage and Avaya IP Office Issue 1.0 Avaya Solution & Interoperability Test Lab Application Notes for Configuring SIP Trunking between Cincinnati Bell Any Distance evantage and Avaya IP Office Issue 1.0 Abstract These Application Notes describe

More information

Request for Comments: 3578 Category: Standards Track dynamicsoft J. Peterson NeuStar L. Ong Ciena August 2003

Request for Comments: 3578 Category: Standards Track dynamicsoft J. Peterson NeuStar L. Ong Ciena August 2003 Network Working Group Request for Comments: 3578 Category: Standards Track G. Camarillo Ericsson A. B. Roach dynamicsoft J. Peterson NeuStar L. Ong Ciena August 2003 Mapping of Integrated Services Digital

More information

Application Scenario 1: Direct Call UA UA

Application Scenario 1: Direct Call UA UA Application Scenario 1: Direct Call UA UA Internet Alice Bob Call signaling Media streams 2009 Jörg Ott 1 tzi.org INVITE sip:bob@foo.bar.com Direct Call bar.com Note: Three-way handshake is performed only

More information

Transporting Voice by Using IP

Transporting Voice by Using IP Transporting Voice by Using IP National Chi Nan University Quincy Wu Email: solomon@ipv6.club.tw 1 Outline Introduction Voice over IP RTP & SIP Conclusion 2 Digital Circuit Technology Developed by telephone

More information

All-IP Core Network Multimedia Domain

All-IP Core Network Multimedia Domain GPP X.S00-00-0 Version.0 Version Date: July 00 0 All-IP Core Network Multimedia Domain IP Multimedia (IMS) session handling; IP Multimedia (IM) Call Model; Stage 0 COPYRIGHT NOTICE GPP and its Organizational

More information

Abstract. Avaya Solution & Interoperability Test Lab

Abstract. Avaya Solution & Interoperability Test Lab Avaya Solution & Interoperability Test Lab Application Notes for Configuring SIP Trunking between Sotel IP Services SIP Edge Advanced SIP Trunking Solution and an Avaya IP Office Telephony Solution Issue

More information

Request for Comments: Category: Standards Track Columbia U. G. Camarillo Ericsson A. Johnston WorldCom J. Peterson Neustar R.

Request for Comments: Category: Standards Track Columbia U. G. Camarillo Ericsson A. Johnston WorldCom J. Peterson Neustar R. Network Working Group J. Rosenberg Request for Comments: 3261 dynamicsoft Obsoletes: 2543 H. Schulzrinne Category: Standards Track Columbia U. G. Camarillo Ericsson A. Johnston WorldCom J. Peterson Neustar

More information

The Session Initiation Protocol

The Session Initiation Protocol The Session Initiation Protocol N. C. State University CSC557 Multimedia Computing and Networking Fall 2001 Lecture # 25 Roadmap for Multimedia Networking 2 1. Introduction why QoS? what are the problems?

More information

N-Squared Software SIP Specialized Resource Platform SIP-SDP-RTP Protocol Conformance Statement. Version 2.3

N-Squared Software SIP Specialized Resource Platform SIP-SDP-RTP Protocol Conformance Statement. Version 2.3 N-Squared Software SIP Specialized Resource Platform SIP-SDP-RTP Protocol Conformance Statement Version 2.3 1 Document Information 1.1 Scope and Purpose This document describes the implementation of the

More information

[MS-TURNBWM]: Traversal using Relay NAT (TURN) Bandwidth Management Extensions

[MS-TURNBWM]: Traversal using Relay NAT (TURN) Bandwidth Management Extensions [MS-TURNBWM]: Traversal using Relay NAT (TURN) Bandwidth Management Extensions Intellectual Property Rights Notice for Open Specifications Documentation Technical Documentation. Microsoft publishes Open

More information

Internet Engineering Task Force. Category: Standards Track November 2001 Expires May 2002 <draft-ietf-sip-events-01.txt>

Internet Engineering Task Force. Category: Standards Track November 2001 Expires May 2002 <draft-ietf-sip-events-01.txt> Internet Engineering Task Force Adam Roach Internet Draft Ericsson Inc. Category: Standards Track November 2001 Expires May 2002 Status of this Memo Abstract SIP-Specific

More information

Internet Engineering Task Force (IETF) Deutsche Telekom D. Alexeitsev TeleFLASH April 2013

Internet Engineering Task Force (IETF) Deutsche Telekom D. Alexeitsev TeleFLASH April 2013 Internet Engineering Task Force (IETF) Request for Comments: 6910 Category: Standards Track ISSN: 2070-1721 D. Worley Ariadne Internet Services, Inc. M. Huelsemann R. Jesske Deutsche Telekom D. Alexeitsev

More information

Multimedia Communication

Multimedia Communication Multimedia Communication Session Description Protocol SDP Session Announcement Protocol SAP Realtime Streaming Protocol RTSP Session Initiation Protocol - SIP Dr. Andreas Kassler Slide 1 SDP Slide 2 SDP

More information

3GPP TS V ( )

3GPP TS V ( ) TS 24.341 V12.6.0 (2014-12) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Support of SMS over IP networks; Stage 3 (Release 12) The

More information

WLAN The Wireless Local Area Network Consortium

WLAN The Wireless Local Area Network Consortium WLAN The Wireless Local Area Network Consortium 802.11 Base AP MAC Layer Test Suite Version 3.5 Technical Document Last Updated: February 18, 2012 Wireless LAN Consortium 121 Technology Drive, Suite 2

More information

3GPP TS V7.2.0 ( )

3GPP TS V7.2.0 ( ) TS 24.341 V7.2.0 (2007-12) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Support of SMS over IP networks; Stage 3 (Release 7) GLOBAL

More information

Category: Informational Ericsson T. Hallin Motorola September 2007

Category: Informational Ericsson T. Hallin Motorola September 2007 Network Working Group Request for Comments: 4964 Category: Informational A. Allen, Ed. Research in Motion (RIM) J. Holm Ericsson T. Hallin Motorola September 2007 The P-Answer-State Header Extension to

More information

3GPP TR V ( )

3GPP TR V ( ) TR 24.930 V10.1.0 (2011-12) Technical Report 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Signalling flows for the session setup in the IP Multimedia core

More information

Request for Comments: 2976 Category: Standards Track October 2000

Request for Comments: 2976 Category: Standards Track October 2000 Network Working Group S. Donovan Request for Comments: 2976 dynamicsoft Category: Standards Track October 2000 Status of this Memo The SIP INFO Method This document specifies an Internet standards track

More information

Telecommunication Services Engineering Lab. Roch H. Glitho

Telecommunication Services Engineering Lab. Roch H. Glitho 1 2 Outline 1. Introduction 2. Core SIP 3. Selected Extensions 3 Introduction: Signaling vs Media Signaling: Session establishment Session tear down Changes to the session Supplementary services Media:

More information

ETSI TS V1.1.1 ( )

ETSI TS V1.1.1 ( ) TS 183 028 V1.1.1 (2006-04) Technical Specification Telecommunications and Internet Converged Services and Protocols for Advanced Networking (TISPAN); Common basic communication procedures; Protocol specification

More information

ROUTING CONSORTIUM TEST SUITE

ROUTING CONSORTIUM TEST SUITE ROUTING CONSORTIUM TEST SUITE Routing Information Protocol (RIP) Over Internet Protocol Version 6 Technical Document Version 2.0 University of New Hampshire 121 Technology Drive, Suite 2 Durham, NH 03824

More information

draft-ietf-sip-info-method-02.txt February 2000 The SIP INFO Method Status of this Memo

draft-ietf-sip-info-method-02.txt February 2000 The SIP INFO Method Status of this Memo HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 07:53:57 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 15 Feb 2000 17:03:00 GMT ETag: "3239a5-465b-38a986c4" Accept-Ranges: bytes Content-Length: 18011 Connection:

More information

ROUTING CONSORTIUM. Virtual Router Redundancy Protocol Operations Test Suite. Technical Document. Revision 2.5

ROUTING CONSORTIUM. Virtual Router Redundancy Protocol Operations Test Suite. Technical Document. Revision 2.5 ROUTING CONSORTIUM Virtual Router Redundancy Protocol Operations Test Suite Technical Document Revision 2.5 University of New Hampshire 121 Technology Drive, Suite 2 Durham, NH 03824 Routing Consortium

More information

ETSI TS V8.2.0 ( ) Technical Specification

ETSI TS V8.2.0 ( ) Technical Specification TS 124 147 V8.2.0 (2009-01) Technical Specification Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; Conferencing using the IP Multimedia (IM)

More information

Application Notes for Configuring SIP Trunking between CenturyLink SIP Trunk (Legacy Qwest) Service and Avaya IP Office R8.0 (16) Issue 1.

Application Notes for Configuring SIP Trunking between CenturyLink SIP Trunk (Legacy Qwest) Service and Avaya IP Office R8.0 (16) Issue 1. Avaya Solution & Interoperability Test Lab Application Notes for Configuring SIP Trunking between CenturyLink SIP Trunk (Legacy Qwest) Service and Avaya IP Office R8.0 (16) Issue 1.0 Abstract These Application

More information

Extensions to SIP and P2PSIP

Extensions to SIP and P2PSIP Extensions to SIP and P2PSIP T-110.7100 Applications and Services in Internet 12.10.2010 Jouni Mäenpää NomadicLab, Ericsson Research Contents Extending SIP Examples of SIP extensions Reliability of provisional

More information

SERIAL ATTACHED SCSI (SAS) CONSORTIUM

SERIAL ATTACHED SCSI (SAS) CONSORTIUM SERIAL ATTACHED SCSI (SAS) CONSORTIUM Clause 6 SAS SPL Link Layer Test Suite Version 1.3 Technical Document Last Updated: 6 September 2011 Serial Attached SCSI Consortium 121 Technology Drive, Suite 2

More information

SERIAL ATTACHED SCSI (SAS) CONSORTIUM

SERIAL ATTACHED SCSI (SAS) CONSORTIUM SERIAL ATTACHED SCSI (SAS) CONSORTIUM Clause 8 SAS SPL Target Error Handling Test Suite Version0.3 Technical Document Last Updated: 6 September 2011 Serial Attached SCSI Consortium 121 Technology Drive,

More information

UNH IOL iscsi CONSORTIUM

UNH IOL iscsi CONSORTIUM UNH IOL iscsi CONSORTIUM CHAP Test Suite for iscsi Initiators Version 3.1 Technical Document Last Updated May 17, 2016 2015 University of New Hampshire InterOperability Laboratory UNH-IOL iscsi Consortium

More information

SIP Access Interface. Interworking Guide. Release 21.0 Document Version 3

SIP Access Interface. Interworking Guide. Release 21.0 Document Version 3 SIP Access Interface Interworking Guide Release 21.0 Document Version 3 9737 Washingtonian Boulevard, Suite 350 Gaithersburg, MD 20878 Tel +1 301.977.9440 WWW.BROADSOFT.COM BroadWorks Guide Copyright Notice

More information

Request for Comments: 3959 Category: Standards Track December 2004

Request for Comments: 3959 Category: Standards Track December 2004 Network Working Group G. Camarillo Request for Comments: 3959 Ericsson Category: Standards Track December 2004 Status of This Memo The Early Session Disposition Type for the Session Initiation Protocol

More information

UNH IOL iscsi CONSORTIUM

UNH IOL iscsi CONSORTIUM UNH IOL iscsi CONSORTIUM Error Recovery Test Suite for iscsi Targets Version 2.1 Technical Document Last modified January 13, 2010 2006-2010 University of New Hampshire UNH-IOL iscsi Consortium 121 Technology

More information

Application Notes for Configuring SIP Trunking between Bandwidth.com SIP Trunking Solution and an Avaya IP Office Telephony Solution Issue 1.

Application Notes for Configuring SIP Trunking between Bandwidth.com SIP Trunking Solution and an Avaya IP Office Telephony Solution Issue 1. Avaya Solution & Interoperability Test Lab Application Notes for Configuring SIP Trunking between Bandwidth.com SIP Trunking Solution and an Avaya IP Office Telephony Solution Issue 1.0 Abstract These

More information

UNH-IOL iscsi CONSORTIUM

UNH-IOL iscsi CONSORTIUM UNH-IOL iscsi CONSORTIUM isns Interoperability Test Suite Version 1.0 Technical Document Last Updated: July 21, 2008 iscsi Consortium 121 Technology Drive, Suite 2 Durham, NH 03824 University of New Hampshire

More information

ROUTING CONSORTIUM. Intermediate System to Intermediate System (IS-IS) Operations Test Suite. Technical Document. Revision 4.6

ROUTING CONSORTIUM. Intermediate System to Intermediate System (IS-IS) Operations Test Suite. Technical Document. Revision 4.6 ROUTING CONSORTIUM Intermediate System to Intermediate System (IS-IS) Operations Test Suite Technical Document Revision 4.6 University of New Hampshire 121 Technology Drive, Suite 2 Durham, NH 03824-3525

More information

The search being performed may take a significant time so a forking proxy must send a 100 Trying response.

The search being performed may take a significant time so a forking proxy must send a 100 Trying response. SIP Response Codes Article Number: 178 Rating: Unrated Last Updated: Wed, Nov 15, 2017 at 2:31 PM SIP Response Codes 1xx Provisional Responses 100 Trying Extended The search being performed may take a

More information

FortiOS Handbook - VoIP Solutions: SIP VERSION 6.0.1

FortiOS Handbook - VoIP Solutions: SIP VERSION 6.0.1 FortiOS Handbook - VoIP Solutions: SIP VERSION 6.0.1 FORTINET DOCUMENT LIBRARY https://docs.fortinet.com FORTINET VIDEO GUIDE https://video.fortinet.com FORTINET KNOWLEDGE BASE http://kb.fortinet.com FORTINET

More information

IWARP Consortium. Network Impairments Test Suite. Technical Document. Revision 0.3

IWARP Consortium. Network Impairments Test Suite. Technical Document. Revision 0.3 IWARP Consortium Technical Document Revision 0.3 iwarp Consortium 121 Technology Drive, Suite 2 Durham, NH 03824 3525 University of New Hampshire Phone: +1 603 862 5083 Fax: +1 603 862 4181 http://www.iol.unh.edu/

More information

Internet Engineering Task Force (IETF) Request for Comments: Acme Packet January 2011

Internet Engineering Task Force (IETF) Request for Comments: Acme Packet January 2011 Internet Engineering Task Force (IETF) Request for Comments: 6086 Obsoletes: 2976 Category: Standards Track ISSN: 2070-1721 C. Holmberg Ericsson E. Burger Georgetown University H. Kaplan Acme Packet January

More information

Application Notes for Configuring SIP Trunking between TelePacific SmartVoice SIP Connect and an Avaya IP Office Telephony Solution 1.

Application Notes for Configuring SIP Trunking between TelePacific SmartVoice SIP Connect and an Avaya IP Office Telephony Solution 1. Avaya Solution & Interoperability Test Lab Application Notes for Configuring SIP Trunking between TelePacific SmartVoice SIP Connect and an Avaya IP Office Telephony Solution 1.0 Abstract These Application

More information

3GPP TR V7.0.0 ( )

3GPP TR V7.0.0 ( ) TR 24.930 V7.0.0 (2006-12) Technical Report 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Signalling flows for the session setup in the IP Multimedia core

More information

SIP Trunk design and deployment in Enterprise UC networks

SIP Trunk design and deployment in Enterprise UC networks SIP Trunk design and deployment in Enterprise UC networks Tony Mulchrone Technical Marketing Engineer Cisco Collaboration Technology Group Objectives of this session a) Provide a quick overview of SIP

More information

Cisco ATA 191 Analog Telephone Adapter Overview

Cisco ATA 191 Analog Telephone Adapter Overview Cisco ATA 191 Analog Telephone Adapter Overview Your Analog Telephone Adapter, page 1 Your Analog Telephone Adapter The ATA 191 analog telephone adapter is a telephony-device-to-ethernet adapter that allows

More information

Abstract. Avaya Solution & Interoperability Test Lab

Abstract. Avaya Solution & Interoperability Test Lab Avaya Solution & Interoperability Test Lab Application Notes for Configuring SIP Trunking between the PAETEC Broadsoft based SIP Trunking Solution and an Avaya IP Office Telephony Solution Issue 1.0 Abstract

More information

University of New Hampshire InterOperability Laboratory Ethernet Consortium

University of New Hampshire InterOperability Laboratory Ethernet Consortium University of New Hampshire Ethernet Consortium As of July 2 nd, 2001 the Ethernet Consortium Clause # 28 Auto Negotiation State Machine Base Page Exchange Conformance Test Suite version 4.0.3 has been

More information

An Efficient NAT Traversal for SIP and Its Associated Media sessions

An Efficient NAT Traversal for SIP and Its Associated Media sessions An Efficient NAT Traversal for SIP and Its Associated Media sessions Yun-Shuai Yu, Ce-Kuen Shieh, *Wen-Shyang Hwang, **Chien-Chan Hsu, **Che-Shiun Ho, **Ji-Feng Chiu Department of Electrical Engineering,

More information

Network Working Group. Expires: April 30, 2002 October 30, The Refer Method draft-ietf-sip-refer-02. Status of this Memo

Network Working Group. Expires: April 30, 2002 October 30, The Refer Method draft-ietf-sip-refer-02. Status of this Memo Network Working Group R. Sparks Internet-Draft dynamicsoft Expires: April 30, 2002 October 30, 2001 Status of this Memo The Refer Method draft-ietf-sip-refer-02 This document is an Internet-Draft and is

More information

DMP 128 Plus C V DMP 128 Plus C V AT

DMP 128 Plus C V DMP 128 Plus C V AT DMP 128 Plus C V DMP 128 Plus C V AT Interactive Intelligence Configuration Guide REVISION: 1.0.1 DATE: MARCH 7 TH 2018 Revision Log Date Version Notes Feb 9 th 2018 1.0 First Release: Applies to Firmware

More information

IMS signalling for multiparty services based on network level multicast

IMS signalling for multiparty services based on network level multicast IMS signalling for multiparty services based on network level multicast Ivan Vidal, Ignacio Soto, Francisco Valera, Jaime Garcia, Arturo Azcorra UniversityCarlosIIIofMadrid Av.Universidad,30 E-28911, Madrid,

More information

SIP Trunk design and deployment in Enterprise UC networks

SIP Trunk design and deployment in Enterprise UC networks SIP Trunk design and deployment in Enterprise UC networks BRKUCC-2006 Tony Mulchrone Technical Marketing Engineer Cisco Collaboration Technology Group Housekeeping We value your feedback- don't forget

More information

IPv6 CONSORTIUM TEST SUITE Address Architecture Conformance Test Specification

IPv6 CONSORTIUM TEST SUITE Address Architecture Conformance Test Specification IPv6 CONSORTIUM TEST SUITE Address Architecture Technical Document Version 2.4 University of New Hampshire 121 Technology Drive, Suite 2 Durham, NH 03824 IPv6 Consortium Phone: +1-603-862-2804 http://www.iol.unh.edu

More information

Request for Comments: 3265 Updates: 2543 June 2002 Category: Standards Track. Session Initiation Protocol (SIP)-Specific Event Notification

Request for Comments: 3265 Updates: 2543 June 2002 Category: Standards Track. Session Initiation Protocol (SIP)-Specific Event Notification Network Working Group A. B. Roach Request for Comments: 3265 dynamicsoft Updates: 2543 June 2002 Category: Standards Track Session Initiation Protocol (SIP)-Specific Event Notification Status of this Memo

More information

Bridge Functions Consortium

Bridge Functions Consortium Bridge Functions Consortium Spanning Tree Protocol Operations Test Suite Version 2.4 Last Updated: 2008-06-23 Bridge Functions Consortium University of New Hampshire www.iol.unh.edu 121 Technology Drive,

More information

Application Notes for Configuring SIP Trunking between McLeodUSA SIP Trunking Solution and an Avaya IP Office Telephony Solution Issue 1.

Application Notes for Configuring SIP Trunking between McLeodUSA SIP Trunking Solution and an Avaya IP Office Telephony Solution Issue 1. Avaya Solution & Interoperability Test Lab Application Notes for Configuring SIP Trunking between McLeodUSA SIP Trunking Solution and an Avaya IP Office Telephony Solution Issue 1.1 Abstract These Application

More information

Application Notes for Configuring Avaya IP Office 8.1 with Etisalat SIP Trunk service Issue 1.0

Application Notes for Configuring Avaya IP Office 8.1 with Etisalat SIP Trunk service Issue 1.0 Avaya Solution & Interoperability Test Lab Application Notes for Configuring Avaya IP Office 8.1 with Etisalat SIP Trunk service Issue 1.0 Abstract These Application Notes describe the procedures for configuring

More information

Session Initiation Protocol (SIP) for PSTN Calls Extensions

Session Initiation Protocol (SIP) for PSTN Calls Extensions [MS-OCPSTN]: Intellectual Property Rights Notice for Open Specifications Documentation Technical Documentation. Microsoft publishes Open Specifications documentation ( this documentation ) for protocols,

More information

[MS-TURNBWM]: Traversal using Relay NAT (TURN) Bandwidth Management Extensions

[MS-TURNBWM]: Traversal using Relay NAT (TURN) Bandwidth Management Extensions [MS-TURNBWM]: Traversal using Relay NAT (TURN) Bandwidth Management Extensions Intellectual Property Rights Notice for Open Specifications Documentation Technical Documentation. Microsoft publishes Open

More information

WLAN The Wireless Local Area Network Consortium

WLAN The Wireless Local Area Network Consortium WLAN The Wireless Local Area Network Consortium WPA Station MAC Layer Test Suite Version 2.5 Technical Document Last Updated: February 18, 2013 Wireless LAN Consortium 121 Technology Drive, Suite 2 Durham,

More information

ETHERNET. Clause 28 Auto-Negotiation State Machine Base Page Exchange Test Suite v5.5. Technical Document. Last Updated: July 22, :11PM

ETHERNET. Clause 28 Auto-Negotiation State Machine Base Page Exchange Test Suite v5.5. Technical Document. Last Updated: July 22, :11PM ETHERNET Clause 28 Auto-Negotiation State Machine Base Page Exchange Test Suite v5.5 Technical Document Last Updated: July 22, 2004 6:11PM Ethernet Consortium 121 Technology Drive, Suite 2 oratory Durham,

More information

Understanding SIP exchanges by experimentation

Understanding SIP exchanges by experimentation Understanding SIP exchanges by experimentation Emin Gabrielyan 2007-04-10 Switzernet Sàrl We analyze a few simple scenarios of SIP message exchanges for a call setup between two SIP phones. We use an SIP

More information

Application Notes for Phonect SIP Trunk Service and Avaya IP Office 7.0 Issue 1.0

Application Notes for Phonect SIP Trunk Service and Avaya IP Office 7.0 Issue 1.0 Avaya Solution & Interoperability Test Lab Application Notes for Phonect SIP Trunk Service and Avaya IP Office 7.0 Issue 1.0 Abstract These Application Notes describe the procedures for configuring Session

More information

Internet Engineering Task Force (IETF) Request for Comments: Category: Standards Track ISSN: September 2015

Internet Engineering Task Force (IETF) Request for Comments: Category: Standards Track ISSN: September 2015 Internet Engineering Task Force (IETF) R. Sparks Request for Comments: 7647 Oracle Updates: 3515 A.B. Roach Category: Standards Track Mozilla ISSN: 2070-1721 September 2015 Abstract Clarifications for

More information

SIP Reliable Provisional Response on CUBE and CUCM Configuration Example

SIP Reliable Provisional Response on CUBE and CUCM Configuration Example SIP Reliable Provisional Response on CUBE and CUCM Configuration Example Document ID: 116086 Contributed by Robin Cai, Cisco TAC Engineer. May 16, 2013 Contents Introduction Prerequisites Requirements

More information

WLAN The Wireless Local Area Network Consortium

WLAN The Wireless Local Area Network Consortium WLAN The Wireless Local Area Network Consortium 802.11 Base Station MAC Layer Test Suite Version 3.2 Technical Document Last Updated: November 25, 2008 Wireless LAN Consortium 121 Technology Drive, Suite

More information

SIP Trunk design and deployment in Enterprise UC networks

SIP Trunk design and deployment in Enterprise UC networks SIP Trunk design and deployment in Enterprise UC networks BRKUCC-2006 Tony Mulchrone Technical Marketing Engineer Cisco Collaboration Technology Group Housekeeping We value your feedback- don't forget

More information

Implementation Profile for Interoperable Bridging Systems Interfaces (Phase 1)

Implementation Profile for Interoperable Bridging Systems Interfaces (Phase 1) NIST/OLES VoIP Roundtable Request For Comments: nnnn Category: Informational Version 1.0 R. Mitchell Twisted Pair Solutions C. Eckel Cisco April 2008 Implementation Profile for Interoperable Bridging Systems

More information

ETHERNET TESTING SERVICES

ETHERNET TESTING SERVICES ETHERNET TESTING SERVICES MAC Merge Frame Preemption for Interspersing Express Traffic Conformance Test Plan Version 1.0 Technical Document Last Updated: June 14, 2017 Ethernet Testing Services 21 Madbury

More information

Media Communications Internet Telephony and Teleconference

Media Communications Internet Telephony and Teleconference Lesson 13 Media Communications Internet Telephony and Teleconference Scenario and Issue of IP Telephony Scenario and Issue of IP Teleconference ITU and IETF Standards for IP Telephony/conf. H.323 Standard

More information

Outline. Goals of work Work since Atlanta Extensions Updates Made Open Issues Ad-hoc meeting & Next Teleconference Links

Outline. Goals of work Work since Atlanta Extensions Updates Made Open Issues Ad-hoc meeting & Next Teleconference Links Update of RTSP draft-ietf-mmusic-rfc2326bis-03.txt Authors: Henning Schulzrinne / Columbia University Robert Lanphier / Real Networks Magnus Westerlund / Ericsson (Presenting) Anup Rao / Cisco Outline

More information

Data Center Bridging Consortium

Data Center Bridging Consortium Data Center Bridging Consortium 802.1Qau Congestion Notification Test Suite Version 1.1 Technical Document Last Updated: April 10, 2012 Data Center Bridging Consortium HTTP://WWW.IOL.UNH.EDU/CONSORTIUMS/DCB

More information

Bridge Functions Consortium

Bridge Functions Consortium Hardware Rate Limiting Feature Verification Test Suite Version 0.1 Last Updated: 2005-09-05 121 Technology Drive, Suite 2 University of New Hampshire Durham, NH 03824 Phone: (603) 862-0090 www.iol.unh.edu

More information

Application Notes for Configuring CenturyLink SIP Trunking with Avaya IP Office Issue 1.0

Application Notes for Configuring CenturyLink SIP Trunking with Avaya IP Office Issue 1.0 Avaya Solution & Interoperability Test Lab Application Notes for Configuring CenturyLink SIP Trunking with Avaya IP Office 6.1 - Issue 1.0 Abstract These Application Notes describe the procedures for configuring

More information

The Session Initiation Protocol

The Session Initiation Protocol The Session Initiation Protocol Report August 2003 2003 Meridea Financial Software Ltd All rights reserved. No part of this document may be copied or otherwise reproduced in any form without prior written

More information