Voice over IP Consortium

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

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 7.10. 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 2.6-2.9, 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 7 1.1 March 24, 2006 Bryan Pellegrino Added tests for UPDATE messages, RFC- 3311. 1.0 January 19, 2006 Lincoln Lavoie Final review of version 1.0 0.6 January 17, 2006 James Swan Added test cases to group 8 0.5 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 3666 2

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

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... 10 Test Setups... 11 Test Setup 1: General Test Setup... 11 Test Setup 2: Setup for Three Party Interaction... 12 Group 1: Core Message Formatting... 13 Test # 1.1: Correct Formatting of Request Line in INVITE Requests... 14 Test # 1.2: Correct Formatting of Status Line in Response Messages... 15 Test # 1.3: Verify Correct Header Field Formatting... 16 Test # 1.4: Verify Inclusion of Necessary Header Field... 17 Test # 1.5: Ability to Process Compact Header Fields... 18 Test # 1.6: Verify inclusion and correctness of Content-Type header... 19 Group 2: Core UAC Behavior... 20 Test # 2.1: UAC Call-ID Creation... 21 Test # 2.2: CSeq Generation... 22 Test # 2.3: Max-Forwards... 23 Test # 2.4: Inclusion of Appropriate Via Header... 24 Test # 2.5: Inclusion of Appropriate Contact Header... 25 Test # 2.6 General Expire Header... 26 Test # 2.7 Timestamp Header... 27 Test # 2.8: UAC Inserted Supported and Require Headers... 28 Test # 2.9: Correct Handling of Multiple Via Headers... 29 Test # 2.10: Correct Handling of 300 (Redirect) Responses... 30 Test # 2.11: Correct Handling of 413 Request Entity Too Large Response... 31 Test # 2.12: Correct Handling of 415 Unsupported Media Type Response... 32 Test # 2.13: Correct Handling of 420 Bad Extension Response... 33 Test # 2.14: Correct Handling of 416 Unsupported URI Scheme Response... 34 Group 3: Core UAS Behavior... 35 Test # 3.1: 100 Provisional Responses to INVITES... 36 Test # 3.2: 200 Responses... 37 Test # 3.3: Behavior When an Unsupported Request is Received... 38 Test # 3.4: UAS Header Inspection... 39 Test # 3.5: Reception of Invalid Request-URI... 40 Test # 3.6: Require Header Processing... 41 Test # 3.7: Require Header Processing in CANCEL Request... 42 Test # 3.8: Provisional Responses on Non INVITE Requests... 43 4

Test # 3.9: Handling of Header Fields in Responses... 44 Group 4: CANCEL Request... 45 Test # 4.1: Generation of CANCEL Requests... 46 Test # 4.2: CANCEL Request Without Provisional Responses... 47 Test # 4.3: CANCEL Response When Referring to Incorrect Call... 48 Test # 4.4: Generation of 487 Response... 49 Group 5: REGISTER Requests... 50 Test # 5.1: Generation of REGISTER Request... 51 Test # 5.2: Removal of Bindings... 52 Test # 5.3: Refreshing Bindings... 53 Group 6: OPTIONS Request... 54 Test # 6.1: Generation of OPTIONS Request... 55 Test # 6.2: OPTIONS Request to SIP Proxy Server... 56 Test # 6.3: Response to OPTIONS Request... 57 Group 7: INVITE Requests... 58 Test # 7.1: Sending Session Offer in INVITE Requests... 59 Test # 7.2: Sending Session Offer in 200 Response Messages... 60 Test # 7.3: Receiving Session Offer in 200 Response Messages... 61 Test # 7.4: Generation of ACK Requests... 62 Test # 7.5: Reception of Non 200 Terminating Responses... 63 Test # 7.6: Unacceptable SDP Offer Received in INVITE... 64 Test # 7.7: Timeout of ACK requests on INVITE... 65 Test # 7.8: Reception of INVITE Within a Dialog (re-invite)... 66 Test # 7.9: Reception of re-invite Before Response... 67 Group 8: BYE Requests... 68 Test # 8.1: Generation of BYE Requests... 69 Test # 8.2: Reception of BYE Requests... 70 Test # 8.3: Reception of BYE Requests Outside of a Dialog... 71 Test # 8.4: Correct Termination of Sessions... 72 Group 9: ACK Requests... 73 Test # 9.1: Correct Generation of ACK Requests for 2xx Final Responses... 74 Test # 9.2: Reception of ACK Requests for 2xx Final Responses... 75 Test # 9.3: Correct Generation of ACK Requests for non-2xx Final Responses... 76 Test # 9.4: Reception of ACK Requests for non-2xx Final Responses... 77 Group 10: Tags... 78 Test # 10.1: Correct Tag Parameter in Request Outside of a Dialog... 79 Test # 10.2: Correct Tag Parameter in Response... 80 Group 11: INFO Request... 81 Test # 11.1: Verification of Final Response After Receiving an INFO Request... 82 Test # 11.2: Response to INFO Request Outside of a Session... 83 Test # 11.3: Support of Response Code 415... 84 Test # 11.4: Correct Generation of INFO Request... 85 Test # 11.5: Cancellation of INFO Request... 86 Group 12: The SIP Join Header... 87 5

Test # 12.1: Correct Handling of INVITE with Join Header... 88 Test # 12.2: Correct Generation of INVITE with Join Header... 89 Test # 12.3: Response to INVITE Requests with Multiple Join Headers... 90 Test # 12.4: Response to Join Headers not within an INVITE Request... 91 Test # 12.5: INVITE with Join Header with no Match... 92 Group 13: Reliable Provisional Responses... 93 Test # 13.1: Correct Generation of Reliable Provisional Response Messages... 94 Test # 13.2: Correct Behavior For Unmatched PRACK Request... 95 Test # 13.3: Correct Generation of PRACK Request... 96 Group 14: Event Notification... 97 Test # 14.1: Correct Generation of SUBSCRIBE Request... 98 Test # 14.2: Refreshing Subscriptions... 99 Test # 14.3: Removing a Subscription... 100 Test # 14.4: Reception and Processing of a SUBSCRIBE Request... 101 Test # 14.5: Reception of an Unsupported Event Package... 102 Test # 14.6: Correct Generation of a NOTIFY Request.... 103 Test # 14.7: Reception of a NOTIFY Request... 104 Test # 14.8: Reception of a NOTIFY Request With an Invalid Event Header... 105 Group 15: The REFER Method... 106 Test # 15.1: Generation of a REFER Request... 107 Test # 15.2: Reception of a REFER Request... 108 Group 16: Session Description Protocol... 109 Test # 16.1: Correct Formatting of SDP Offer... 110 Test # 16.2: Generation of Correct SDP Answer... 111 Test # 16.3: Generation of Rejected SDP Answer... 112 Test # 16.4: SDP Offer Containing Send Only Request... 113 Test # 16.5: SDP Offer Containing Receive Only Request... 114 Test # 16.6: SDP Offer Request No Media... 115 Group 17: The UPDATE Method... 116 Test # 17.1: Correct Handling of Consecutive UPDATE Requests... 117 Test # 17.2: UPDATE Requests and the Allow Header Field... 118 Test # 17.3: Sending UPDATE Requests before Session Establishment... 119 Test # 17.4: Handling UPDATE Requests while unanswered Offers still exist... 120 Test # 17.5: Correct Response Generation of Session Changes with UPDATE... 121 Test # 17.6: Correct Handling of Session Changes with UPDATE... 122 Test # 17.7: Unacceptable Session Description in UPDATE Request... 123 Test # 17.8: Correct Handling of UPDATE with a non-2xx final response... 124 Test # 17.9: Termination of Dialog with UPDATE and non-2xx Final Responses... 125 Test # 17.10: Correct Handling of a 491 response to UPDATE... 126 6

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

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

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

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

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 3261. 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 10.10.42.9 10.10.42.18 Transport UDP UDP Port 5060 5060 11

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 3261. 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 10.10.42.9 10.10.42.10 10.10.42.18 Transport UDP UDP UDP Port 5060 5060 5060 12

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

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

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 3261. 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/2.0 200 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

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/2.0 200 OK [CRLF]" A reason phrase may be inserted between the "200 OK" and the [CRLF]. This would not cause the test to fail. 16

Test # 1.4: Verify Inclusion of Necessary Header Field Purpose: This test verifies that the DUT includes the necessary, core, header fields. [1] Section 8.2.6.2 (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

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 7.3.3 (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

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 7.4.1 (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

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

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 8.1.1.4 (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

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 8.1.1.5 (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

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 8.1.1.6 (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 70. 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 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

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 8.1.1.7 (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

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 8.1.1.8 (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

Test # 2.6 General Expire Header Purpose: This test verifies that when issuing a new request the DUT sends an Expire header [1] Section 13.2.1 (RFC 3261) [11] Section 3.1.2.4 (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

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 8.2.6.1 (RFC 3261) [11] Section 3.1.2.4 (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

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 8.1.1.9 (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

Test # 2.9: Correct Handling of Multiple Via Headers Purpose: This test verifies that the DUT handles multiple Via headers correctly. [1] Section 8.1.3.3 (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

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 8.1.3.4 (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

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 8.1.3.5 (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

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 8.1.3.5 (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

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 8.1.3.5 (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

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 8.1.3.5 (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

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

Test # 3.1: 100 Provisional Responses to INVITES Purpose: This test verifies that the DUT correctly implements provisional responses. [1] Section 8.2.6.1 (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

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 8.2.6 (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

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 8.2.2.1 (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

Test # 3.4: UAS Header Inspection Purpose: Verify that the DUT correctly ignores malformed or unknown headers. [1] Section 8.2.2 (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

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 8.2.2.1 (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

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 8.2.2.3 (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

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 8.2.2.3 (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 3261. 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

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 8.2.6.1 (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

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 8.2.6.2 (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

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

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

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