SIP Interoperability Test Suite...interoperate with other SIP implementations on the key features of SIP outlined in IETF RFC 3261 as well as some widely implemented extensions. Failure

Voice over IP Consortium SIP Interoperability Test Suite

(SIPIO)

Technical Document Revision 3.0

VoIP Consortium 121 Technology Drive, Suite 2 University of New Hampshire Durham, NH 03824 InterOperability Laboratory Phone: +1-603-862-0186 Fax: +1-603-862-4181 http://www.iol.unh.edu

MODIFICATION RECORD Version 3.0 June 20, 2007

• Generalized test suite for testing proxy servers • Added single proxy common test configuration • Added single proxy basic session tests • Added single and multiple proxy authentication tests • Added test for reliable delivery of provisional responses • Added session modification test • Added capability querying test • Added redirection test • Updated device references • Added Bryan Pellegrino to Acknowledgements

Version 2.0.7 January 24, 2007 • Changed EP1 references to UA1. • Changed title to SIP Interoperability Test Suite for User Agents.

Version 2.0.6 January 23, 2007 • Removed dropped packet test cases.

Version 2.0.5 January 12, 2007 • Added tests 2.1, 2.2, 2.3, and 2.4. • Added SDP terms to Terms and Definitions table. • Added Common Test Setup 2.

Version 2.0.4 January 5, 2007 • Removed NE1 from common test setup. • Changed “cause the DUT to…” to be more specific.

Version 2.0.3 January 2, 2007 • Combined tests 3.3, 3.4, and 3.7 into 3.2. • Common test setup created.

Version 2.0.2 December 22, 2006 • All test group titles changed. • Security test group created. • Combined tests 1.1, 1.2, and 1.3 into test 1.1. • Combined tests 2.1, 2.2, 2.3, and 2.4 into test 2.1. • Combined tests 3.1, 3.2 into test 3.1.

Version 2.0.1 December 18, 2006 • Last modified section removed. • Resource Requirements section removed. • Modified all tests to use the common test setup.

Version 2.0 August 31, 2006 • Initial creation of new document.

Version 1.0 January 26, 2005 • Updated.

Version 0.9 January 25, 2005 • Updated and added copyright.

Version 0.5 January 8, 2005 • Updated Draft.

Version 0.1 December 1, 2004 • Initial Draft.

VoIP Consortium 1 SIP Interoperability Test Suite

(SIPIO)

ACKNOWLEDGMENTS The University of New Hampshire InterOperability Laboratory would like to acknowledge the efforts of the following individuals in the development of this test suite. Gerard Goubert University of New Hampshire Lincoln Lavoie University of New Hampshire Nate Milliken University of New Hampshire Bryan Pellegrino University of New Hampshire James Swan University of New Hampshire James Unger University of New Hampshire Timothy Winters University of New Hampshire


(SIPIO)

INTRODUCTION

Overview The University of New Hampshire’s InterOperability Laboratory (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 interoperability test suite has been developed to help implementers verify that their products interoperate with other SIP implementations on the key features of SIP outlined in IETF RFC 3261 as well as some widely implemented extensions. Failure to properly interoperate can lead to serious issues when deployed in a multi-vendor environment. Successful completion of all tests in this test suite does not guarantee that the device under test is compliant with the appropriate specification or that it will interoperate in all environments or scenarios. However, successful completion of these tests should provide a reasonable level of confidence that the device under test will function well in most multi-vendor environments.

Abbreviations and Acronyms

DNS Domain Name System DUT Device Under Test FQDN Fully Qualified Domain Name PS1 Proxy Server 1 PS2 Proxy Server 2 RTP Real-time Transport Protocol SDP Session Description Protocol SIP Session Initiation Protocol UA User Agent UA1 User Agent 1 UA2 User Agent 2 UA3 User Agent 3 UAC User Agent Client UAS User Agent Server VoIP Consortium 3 SIP Interoperability Test Suite

(SIPIO)

Terms and Definitions Address-of-Record (AOR)

A SIP or SIPS URI pointing to a domain with a location service, which can map the URI to another URI where the user might be available. Typically, the location service is populated through registrations. An AOR is frequently thought of as the “public address” of the user.

Answerer An agent which receives a session description from another agent describing aspects of desired media communication, and then responds to that with its own session description.

Call An informal term that refers to some communication between peers, generally set up for the purposes of a multimedia conversation

Dialog 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 call identifier, local tag, and a remote tag identify a dialog. A dialog was formerly known as a call leg in RFC2543.

Final Response A response that terminates a SIP transaction, as opposed to a provisional response that does not. All 2xx, 3xx, 4xx, 5xx and 6xx responses are final.

Header Field A header field is a component of the SIP message header. A header field can appear as one or more header field rows. Header field rows consist of a header field name and zero or more header field values. Multiple header field values on a given header field row are separated by commas. Some header fields can only have a single header field value, and as a result, always appear as a single header field row.

Initiator, Calling Party, Caller

The party initiating a session (and dialog) with an INVITE request. A caller retains this role from the time that it sends the initial INVITE that established a dialog until the termination of that dialog.

Invitation An INVITE request. Invitee, Invited User, Called Party, Callee

The party that receives an INVITE request for the purpose of establishing a new session. A callee retains this role from the time it receives the INVITE until the termination of the dialog established by the request.

Multimedia Stream A single media instance, e.g., an audio stream or a video stream as well as a single whiteboard or shared application group. In SDP, a media stream is described by an “m=” line and its associated attributes.

Offerer An agent that generates a session description in order to create or modify a session.

Outbound Proxy A proxy that receives requests from a client, even though it may not be the server resolved by the Request-URI. Typically, a UA is manually configured with an outbound proxy, or can learn about one though auto-configuration protocols.

Provisional Response A response used by the server to indicate progress, but that does not terminate a SIP transaction. 1xx responses are provisional, other responses are considered final.


(SIPIO)

Proxy Server An intermediate entity that acts as both a server and a client for the purposes of making requests on behalf of other clients. A proxy server primarily plays the role of routing, which means its job is to ensure that a request is sent to another entity “closer” to the targeted user. Proxies are also useful for enforcing policy (for example, making sure a user is allowed to make a call). A proxy interprets, and, if necessary, rewrites specific parts of a request message before forwarding it.

Registrar A server that accepts REGISTER requests and places the information it receives in those requests into the location service for the domain it handles.

Request A SIP message sent from a client to a server, for the purpose of invoking a particular operation.

Response A SIP message sent from a server to a client, for indicating the status of a request sent from the client to the server.

Session 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. 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 original field.

Timer A The INVITE request retransmission interval when using the UDP transport layer. Initially this timer is set to the T1 timer interval (500ms default).


(SIPIO)

TEST ORGANIZATION This document organizes tests by Section based on related test methodology or goals. Each group begins with a brief set of comments pertaining to all tests within that group. This is followed by a series of description blocks; each block describes a single test. The format of the description block is as follows: Test Label: The test label and title comprise the first line of the test block. The test label is

composed by concatenating the short test suite name, the section number, the group number, and the test number within the group. These elements are separated by periods. The Test Number is the section, group and test number, also separated by periods.

Purpose: The Purpose is a short statement describing what the test attempts to achieve. It is usually phrased as a simple assertion of the feature or capability to be tested.

References: The References section lists cross-references to the specifications and documentation that might be helpful in understanding and evaluating the test and results.

Node Requirements:

The Node Requirements section is a short description of the features necessary of a particular node in the testing process.

Discussion: The Discussion 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.

Test Setup: The Test Setup section describes the configuration of all devices prior to the start of the test. Different parts of the procedure may involve configuration steps that deviate from what is given in the test setup. If a value is not provided for a protocol parameter, then the protocol’s default is used for that parameter.

Procedure: This section of the test description contains the step-by-step instructions for carrying out the test. These steps include such things as enabling interfaces, unplugging devices from the network, or sending packets from a test station. The test procedure also cues the tester to make observations, which are interpreted in accordance with the observable results given for that test part.

Observable Results:

This section lists observable results that can be examined by the tester to verify that the RUT is operating properly. When multiple observable results are possible, this section provides a short discussion on how to interpret them. The determination of a pass or fail for each test is usually based on how the RUT’s behavior compares to the results described in this section.

Possible Problems: This section contains a description of known issues with the test procedure, which may affect test results in certain situations.


(SIPIO)

REFERENCES The following documents are referenced in this text: [SIP-SPEC] Internet Engineering Task Force (IETF). Request for Comments (RFC) 3261: “Session

Initiation Protocol (SIP),” June 2002. [SIP-PRACK] Internet Engineering Task Force (IETF). Request for Comments (RFC) 3262:

“Reliability of Provisional Responses in the Session Initiation Protocol (SIP),” June 2002.

[SIP-LOC] Internet Engineering Task Force (IETF). Request for Comments (RFC) 3263: “Session

Initiation Protocol (SIP): Locating SIP Servers,” June 2002. [SDP-OA] Internet Engineering Task Force (IETF). Request for Comments (RFC) 3264: “An

Offer/Answer Model with the Session Description Protocol (SDP),” June 2002. [SIP-BCFE] Internet Engineering Task Force (IETF). Request for Comments (RFC) 3665: “Session

Initiation Protocol (SIP) Basic Call Flow Examples,” December 2003. [SDP-SPEC] Internet Engineering Task Force (IETF). Request for Comments (RFC) 4566: “Session

Description Protocol (SDP),” July 2006. [SIP-SERV] Internet Engineering Task Force (IETF). Internet-Draft draft-ietf-sipping-service-

examples-12: “Session Initiation Protocol Service Examples,” January 23, 2007.


(SIPIO)

TABLE OF CONTENTS ACKNOWLEDGMENTS............................................................................................................... 2

INTRODUCTION.......................................................................................................................... 3 OVERVIEW ................................................................................................................................................................................... 3 ABBREVIATIONS AND ACRONYMS................................................................................................................................................ 3 TERMS AND DEFINITIONS............................................................................................................................................................. 4

TEST ORGANIZATION ............................................................................................................... 6

REFERENCES .............................................................................................................................. 7

TABLE OF CONTENTS............................................................................................................... 8

General Node Requirements........................................................................................................ 10

Common Test Setup 1 .................................................................................................................. 11



Group 1: Point to Point................................................................................................................ 16 TEST SIPIO.1.1: INITIATING A SESSION ................................................................................................................................... 17 TEST SIPIO.1.2: SESSION PROGRESS........................................................................................................................................ 18 TEST SIPIO.1.3: ACCEPTING AN INVITATION TO A SESSION .................................................................................................... 19 TEST SIPIO.1.4: RELIABLE DELIVERY OF FINAL RESPONSES.................................................................................................. 20 TEST SIPIO.1.5: ESTABLISHING AND TERMINATING A SESSION .............................................................................................. 21 TEST SIPIO.1.6: MODIFYING AN EXISTING SESSION................................................................................................................ 23 TEST SIPIO.1.7: CANCELLATION OF SESSION INITIATION....................................................................................................... 26 TEST SIPIO.1.8: QUERYING FOR CAPABILITIES....................................................................................................................... 27 TEST SIPIO.1.9: BUSY HERE RESPONSE STATUS ..................................................................................................................... 29 TEST SIPIO.1.10: REJECTING A SESSION OFFER ..................................................................................................................... 30 TEST SIPIO.1.11: RELIABLE DELIVERY OF PROVISIONAL RESPONSES.................................................................................... 32 TEST SIPIO.1.12: REDIRECTION RESPONSE PROCESSING ....................................................................................................... 34 TEST SIPIO.1.13: COMPACT HEADER FIELD NAMES............................................................................................................... 36

Group 2: Single Proxy Server...................................................................................................... 38 TEST SIPIO.2.1: UNAUTHENTICATED ADDITION OF REGISTRATION BINDINGS....................................................................... 39 TEST SIPIO.2.2: AUTHENTICATED ADDITION OF REGISTRATION BINDINGS ........................................................................... 41 TEST SIPIO.2.3: REFRESHING REGISTRATION BINDINGS ........................................................................................................ 43 TEST SIPIO.2.4: ACCEPTANCE OF REGISTRAR EXPIRATION INTERVAL .................................................................................. 45 TEST SIPIO.2.5: REMOVAL OF REGISTRATION BINDINGS ....................................................................................................... 46 TEST SIPIO.2.6: REGISTRATION USING COMPACT HEADER FIELD NAMES............................................................................. 47 TEST SIPIO.2.7: INITIATING A SESSION THROUGH ONE PROXY ............................................................................................... 49


(SIPIO)

TEST SIPIO.2.8: SESSION PROGRESS THROUGH ONE PROXY ................................................................................................... 51 TEST SIPIO.2.9: ACCEPTING AN INVITATION TO A SESSION THROUGH ONE PROXY................................................................ 52 TEST SIPIO.2.10: RELIABLE DELIVERY OF FINAL RESPONSES THROUGH ONE PROXY ........................................................... 53 TEST SIPIO.2.11: ESTABLISH AND TERMINATE SESSION THROUGH ONE PROXY..................................................................... 54 TEST SIPIO.2.12: SESSION ESTABLISHMENT WITH PROXY AUTHENTICATION........................................................................ 57 TEST SIPIO.2.13: MODIFYING AN EXISTING SESSION THROUGH ONE PROXY ........................ERROR! BOOKMARK NOT DEFINED. TEST SIPIO.2.14: CANCELLATION WITH A SINGLE PROXY...................................................................................................... 63 TEST SIPIO.2.15: QUERYING FOR CAPABILITIES THROUGH ONE PROXY ................................................................................ 65 TEST SIPIO.2.16: BUSY RESPONSE THROUGH ONE PROXY ...................................................................................................... 67 TEST SIPIO.2.17: COMPACT HEADERS THROUGH ONE PROXY ............................................................................................... 69 TEST SIPIO.2.18: FORKING PROXY.......................................................................................................................................... 72

Group 3: SIP Trapezoid............................................................................................................... 74 TEST SIPIO.3.1: ESTABLISH AND TERMINATE A SESSION THROUGH TWO PROXIES ................................................................ 75 TEST SIPIO.3.2: SESSION ESTABLISHMENT WITH MULTIPLE PROXY AUTHENTICATION........................................................ 78 TEST SIPIO.3.3: CANCELLATION WITH MULTIPLE PROXIES ................................................................................................... 80 TEST SIPIO.3.4: MODIFYING AN EXISTING SESSION THROUGH TWO PROXIES.......................ERROR! BOOKMARK NOT DEFINED.


(SIPIO)

General Node Requirements

• SIP User Agent o Ability to configure a registrar server. o Ability to configure an outgoing proxy server. o Support for DNS A-Record Resolution.

• Note: Many tests contained in this document can be run using IPv4 addresses. • SIP Server

o Ability to accept anonymous registrations. o Ability to perform digest authentication for user agent registration. o Ability to authenticate incoming and outgoing requests. o Support for DNS A-Record Resolution.

• Note: Many tests contained in this document can be run using IPv4 addresses. VoIP Consortium 10 SIP Interoperability Test Suite

(SIPIO)

Common Test Setup 1

DNS

UA2

UA3

ManagedSwitch

UA1

Common Configuration Parameters for UA1 o No registration. o FQDN is “ua1.ioltest.net” o SIP URI is “sip:[email protected]”

Common Configuration Parameters for UA2

o No registration. o FQDN is “ua2.ioltest.net” o SIP URI is “sip:[email protected]”


o No registration. o FQDN is “ua3.ioltest.net” o SIP URI is “sip:[email protected]”


(SIPIO)

Common Test Setup 2

PS1

DNS

UA1

UA3

ManagedSwitch

UA2


o Request registration expiration of 3600 seconds o Register to PS1’s FQDN o Use PS1’s FQDN as the outgoing proxy server o FQDN is “ua1.ioltest.net” o AOR is “sip:[email protected]” o Authentication user name is “ua1” o Authentication password is “ua1”






(SIPIO)

Common Configuration Parameters for PS1

o Require authenticated registration o FQDN is “ps1.ioltest.net” o Record routing is enabled.


(SIPIO)

Common Test Setup 3

PS1 PS2

DNS

UA2

UA3

ManagedSwitch

UA1




o Request registration expiration of 3600 seconds o Register to TS2’s FQDN o Use TS2’s FQDN as the outgoing proxy server o FQDN is “ua2.ioltest.net” o AOR is “sip:[email protected]” o Authentication user name is “ua2” o Authentication password is “ua2”


o Request registration expiration of 3600 seconds o Register to TS2’s FQDN o Use TS2’s FQDN as the outgoing proxy server o FQDN is “ua3ioltest.net” o AOR is “sip:[email protected]”


(SIPIO)

o Authentication user name is “ua3” o Authentication password is “ua3”

om on Configuration Parameters for PS1

om on Configuration Parameters for PS2

C mo Require authenticated registration o FQDN is “ps1.ioltest.net” o Record routing is enabled.

C mo Require authenticated registration o FQDN is “ps2.ioltest.net” o Record routing is enabled.


(SIPIO)

Group 1: Point to Point Scope: Tests in this group verify that the target devices are able to engage in SIP established multimedia sessions directly with another device in a point-to-point manner. This group of tests only apply to User Agent implementations. Overview: Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. SIP often makes use of elements called proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies, and provide features to users. However, this group of tests verifies the ability of a SIP endpoint implementation to communicate directly with another without using proxy servers.


(SIPIO)

Test SIPIO.1.1: Initiating a Session Purpose: This test verifies that a UAC can successfully begin initiation of a session directly with a UAS. References:

• [SIP-SPEC] – Section 13.1 • [SIP-SPEC] – Section 8.1.1.2 • [SIP-BCFE] – Section 3.1 • [SDP-SPEC] – Section 1

Node Requirements: See General Node Requirements. Discussion: When a user agent client desires to initiate a session (for example, audio, video, or a game), it formulates an INVITE request. The INVITE request asks a server to establish a session. This request may be forwarded by proxies, eventually arriving at one or more UAS that can potentially accept the invitation. The To header field first and foremost specifies the desired "logical" recipient of the request, or the address-of-record of the user or resource that is the target of this request. This may or may not be the ultimate recipient of the request. The To header field may contain a SIP or SIPS URI, but it may also make use of other URI schemes when appropriate. All SIP implementations must support the SIP URI scheme. Test Setup:

Common Test Setup 1 Procedure: Part A: Callee SIP URI contains IPv4 address.

1. UA1 calls UA2 using the IPv4 address of UA2 as the host part. 2. Observe traffic on all networks.

Part B: Callee SIP URI contains FQDN. 3. UA1 calls UA2. 4. Observe traffic on all networks.

Observable Results:

• Part A Step 2: UA1 must transmit an INVITE request to UA2 and the host part of the Request URI must be the IPv4 address of UA2. UA1 must include an SDP offer in the body of the request.

• Part B Step 4: UA1 must transmit an INVITE request to UA2 and the host part of the Request URI must be the FQDN of UA2. UA1 must include an SDP offer in the body of the request.

Possible Problems:

• None


(SIPIO)

Test SIPIO.1.2: Session Progress Purpose: This test verifies that a UAS can successfully handle provisional responses indicating session progress. References:

• [SIP-SPEC] – Section 13.3.1.1 • [SIP-SPEC] – Section 21.1.2 • [SIP-BCFE] – Section 3.1

Node Requirements: See General Node Requirements. Discussion: When a user agent client desires to initiate a session (for example, audio, video, or a game), it formulates an INVITE request to send to the UAS. User agent servers will frequently need to query the user about whether to accept the invitation. If the UAS is not able to answer the invitation immediately, it can choose to indicate some kind of progress to the UAC (for example, an indication that a phone is ringing). This is accomplished with a provisional response between 101 and 199. A UAS may send as many provisional responses as it likes. However, these will not be delivered reliably. The 180 Ringing response indicates that the UA receiving the INVITE is trying to alert the user. This response may be used to initiate local ringback. Test Setup:

Common Test Setup 1 Procedure: Part A: UA1 indicates session progress

1. UA2 calls UA1. 2. UA2 sends an INVITE request to UA1. 3. Observe traffic on all networks.

Observable Results:

• Part A Step 3: UA1 must transmit a non-100 provisional response to the INVITE request from UA2.

Possible Problems:

• None


(SIPIO)

Test SIPIO.1.3: Accepting an Invitation to a Session Purpose: This test verifies that a UAS can successfully accept an invitation to a session. References:

• [SIP-SPEC] – Section 13.1 • [SIP-BCFE] – Section 3.1

Node Requirements: See General Node Requirements. Discussion: After possibly receiving one or more provisional responses, the UAC will get one or more 2xx responses or one non-2xx final response. A 2xx response to an INVITE establishes a session, and it also creates a dialog between the UA that issued the INVITE and the UA that generated the 2xx response.

Test Setup:

Common Test Setup 1 Procedure:

Part A: UA1 accepts session.

1. UA2 calls UA1. 2. UA1 answers the call. 3. Observe traffic on all networks.

Observable Results:

• Part A Step 3: UA1 must transmit a 2xx final response to the INVITE request from UA2 and should indicate the acceptance of the session to the user.

Possible Problems:

• None


(SIPIO)

Test SIPIO.1.4: Reliable Delivery of Final Responses Purpose: This test verifies that a UAC can indicate to a UAS the reliable delivery of a final response received for an INVITE request. References:

• [SIP-SPEC] – Section 13.2.2.4 • [SIP-BCFE] – Section 3.1

Node Requirements: See General Node Requirements. Discussion: Because of the protracted amount of time it can take to receive final responses to INVITE, the reliability mechanisms for INVITE transactions differ from those of other requests. Once it receives a final response, the UAC needs to transmit an ACK for every final response it receives. The sequence number of the CSeq header field must be the same as the INVITE being acknowledged, but the CSeq method must be ACK. Test Setup:

Common Test Setup 1 Procedure: Part A: UA1 indicates reliable delivery of final response.

1. UA1 calls UA2. 2. UA2 answers the call. 3. UA2 transmits a 200 OK response to the INVITE request from UA1. 4. Observe traffic on all networks.

Observable Results:

• Part A Step 4: UA1 must transmit an ACK request to UA2. The Cseq number must be the same as that in the INVITE request being acknowledged.

Possible Problems:

• None


(SIPIO)

Test SIPIO.1.5: Establishing and Terminating a Session Purpose: This test verifies that a user agent can successfully establish and terminate a multimedia session with another UA directly. References:

• [SIP-SPEC] – Section 13 • [SIP-SPEC] – Section 15 • [SIP-BCFE] – Section 3.1

Node Requirements: See General Node Requirements. Discussion: When a session is initiated with an INVITE, each 1xx or 2xx response from a distinct UAS creates a dialog, and if that response completes the offer/answer exchange, it also creates a session. As a result, each session is "associated" with a single dialog - the one which resulted in its creation. The BYE request is used to terminate a specific session or attempted session. In this case, the specific session is the one with the peer UA on the other side of the dialog. When a BYE is received on a dialog, any session associated with that dialog should terminate. Test Setup:

Common Test Setup 1 Procedure: Part A: UA1 calls and terminates.

1. UA1 calls UA2. 2. UA2 answers the call. 3. Observe traffic on all networks. 4. Put UA1 back on the hook. 5. Observe traffic on all networks. 6. UA2 transmits a 200 OK response to the BYE request from UA1. 7. Observe traffic on all networks.

Part B: UA1 calls and UA2 terminates. 8. UA1 calls UA2. 9. UA2 answers the call. 10. Observe traffic on all networks 11. Put UA2 back on the hook. 12. UA2 transmits a BYE request to UA1. 13. Observe traffic on all networks.

Part C: UA2 calls and UA1 terminates. 14. UA2 calls UA1. 15. UA1 answers the call. 16. Observe traffic on all networks. 17. Put UA1 back on the hook. 18. Observe traffic on all networks. 19. UA2 transmits a 200 OK response to the BYE request from UA1.


(SIPIO)

20. Observe traffic on all networks. Part D: UA2 calls and terminates.

21. UA2 calls UA1. 22. UA1 answers the call. 23. Observe traffic on all networks. 24. Put the UA2 back on the hook. 25. UA2 transmits a BYE request to UA1. 26. Observe traffic on all networks.

Observable Results:

• Part A Step 3: Multimedia traffic must be flowing in both directions. Step 5: UA1 must transmit a BYE request to UA2. Step 7: Multimedia traffic must not be flowing in either direction.

• Part B Step 10: Multimedia traffic must be flowing in both directions. Step 13: UA1 must transmit a 200 OK response to the BYE request from UA2 and multimedia traffic must not be flowing in either direction.

• Part C Step 16: Multimedia traffic must be flowing in both directions. Step 18: UA1 must transmit a BYE request to UA2. Step 20: Multimedia traffic must not be flowing in either direction.

• Part D Step 23: Multimedia traffic must be flowing in both directions. Step 26: UA1 must transmit a 200 OK response to the BYE request from UA2 and multimedia traffic must not be flowing in either direction.

Possible Problems:

• There may not be an audio codec supported by both UA1 and UA2.


(SIPIO)

Test SIPIO.1.6: Modifying an Existing Session Purpose: This test verifies that a SIP UA can successfully modify and accept modifications to a session that has already been established. References:

• [SIP-SPEC] – Section 14 • [SIP-BCFE] – Section 3.7 • [SIP-OA] – Section 8.4

Node Requirements: See General Node Requirements. Discussion: A successful INVITE request establishes both a dialog between two user agents and a session using the offer-answer model. Modifying the actual session can involve changing addresses or ports, adding a media stream, deleting a media stream, and so on. This is accomplished by sending a new INVITE request within the same dialog that established the session. An INVITE request sent within an existing dialog is known as a re-INVITE. Either the caller or callee can modify an existing session. Test Setup:

Common Test Setup 1 Procedure: Part A: UA1 calls and modifies session.

1. UA1 calls UA2. 2. UA2 answers the call. 3. Observe traffic on all networks. 4. UA1 modifies the session with UA2. 5. Observe traffic on all networks. 6. UA2 transmits a final response to the re-INVITE request from UA1. 7. Observe traffic on all networks. 8. UA1 reverts the session to its initially negotiated session parameters. 9. Observe traffic on all networks. 10. UA2 transmits a final response to the re-INVITE request from UA1. 11. Observe traffic on all networks. 12. UA1 terminates the call with UA2. 13. Observe traffic on all networks.

Part B: UA1 calls and UA2 modifies session. 14. UA1 calls UA2. 15. UA2 answers the call. 16. Observe traffic on all networks. 17. UA2 transmits a re-INVITE request to UA1 that modifies the session parameters. 18. Observe traffic on all networks. 19. UA2 transmits an ACK request to UA1. 20. UA2 transmits a re-INVITE request to UA1 containing the session parameters that were

negotiated initially. VoIP Consortium 23 SIP Interoperability Test Suite

(SIPIO)

21. Observe traffic on all networks. 22. UA2 transmits an ACK request to UA1. 23. UA1 terminates the call with UA2. 24. Observe traffic on all networks.

Part C: UA2 calls and UA1 modifies session. 25. UA2 calls UA1. 26. UA1 answers the call. 27. Observe traffic on all networks. 28. UA1 modifies the session with UA2. 29. Observe traffic on all networks. 30. UA2 transmits a final response to the re-INVITE request from UA1. 31. Observe traffic on all networks. 32. UA1 reverts the session to its initially negotiated session parameters. 33. Observe traffic on all networks. 34. UA2 transmits a final response to the re-INVITE request from UA1. 35. Observe traffic on all networks. 36. UA1 terminates the call with UA2. 37. Observe traffic on all networks.

Part D: UA2 calls and modifies session. 38. UA2 calls UA1. 39. UA1 answers the call. 40. Observe traffic on all networks. 41. UA2 transmits a re-INVITE request to UA1 that modifies the session parameters. 42. Observe traffic on all networks. 43. UA2 transmits an ACK request to UA1. 44. UA2 transmits a re-INVITE request to UA1 containing the session parameters that were

negotiated initially. 45. Observe traffic on all networks. 46. UA2 transmits an ACK request to UA1. 47. UA2 terminates the call with UA1. 48. UA2 transmits a BYE request to UA1. 49. Observe traffic on all networks.

Observable Results:

• Part A Step 3: Multimedia traffic must be flowing in both directions. Step 5: UA1 must transmit a re-INVITE request to UA2 that modifies the session parameters. Step 7: UA1 must transmit an ACK request to UA2. Step 9: UA1 must transmit a re-INVITE request containing the session parameters that were negotiated initially. Step 11: UA1 must transmit an ACK request to UA2. Step 13: UA1 must transmit a BYE request to UA2.

• Part B Step 16: Multimedia traffic must be flowing in both directions. Step 18: UA1 must transmit a final response to the re-INIVTE request from UA2. Step 21: UA1 must transmit a final response to the re-INIVTE request from UA2. Step 24: UA1 must transmit a BYE request to UA2.

• Part C


(SIPIO)

Step 27: Multimedia traffic must be flowing in both directions. Step 29: UA1 must transmit a re-INVITE request to UA2 that modifies the session parameters. Step 31: UA1 must transmit an ACK request to UA2. Step 33: UA1 must transmit a re-INVITE request containing the session parameters that were negotiated initially. Step 35: UA1 must transmit an ACK request to UA2. Step 37: UA1 must transmit a BYE request to UA2

• Part D Step 40: Multimedia traffic must be flowing in both directions. Step 42: UA1 must transmit a final response to the re-INIVTE request from UA2. Step 45: UA1 must transmit a final response to the re-INIVTE request from UA2. Step 49: UA1 must transmit a 200 OK response to the BYE request from UA2.

Possible Problems:

• There may not be an audio codec supported by both UA1 and UA2. • The user agents may use the UPDATE method in place of the re-INVITE request to modify

session parameters.


(SIPIO)

Test SIPIO.1.7: Cancellation of Session Initiation Purpose: This test verifies that a SIP UA can successfully cancel the initiation of a multimedia session directly with another user agent. References:

• [SIP-SPEC] – Section 9 Node Requirements: See General Node Requirements. Discussion: The CANCEL request, as the name implies, is used to cancel a previous request sent by a client. Specifically, it asks the UAS to cease processing the request and to generate an error response to that request. CANCEL is best for INVITE requests, which can take a long time to generate a response. In that usage, a UAS that receives a CANCEL request for an INVITE, but has not yet sent a final response, would "stop ringing", and then respond to the INVITE with a specific error response (a 487). Test Setup:


Part A: UA1 initiates call.

1. UA1 calls UA2. 2. Put UA1 back on the hook. 3. Observe traffic on all networks. 4. UA2 transmits a 200 OK response to the CANCEL request from UA1. 5. UA2 transmits a 487 Request Terminated response to the INVITE request from UA1. 6. Observe traffic on all networks.

Part B: UA2 initiates call. 7. UA2 calls UA1. 8. Put the UA2 back on the hook. 9. UA2 transmits a CANCEL request to UA1. 10. Observe traffic on all networks.

Observable Results:

• Part A Step 3: UA1 must transmit a CANCEL request to UA2. Step 6: UA1 must transmit an ACK request to UA2.

• Part B Step 10: UA1 must transmit a 200 OK response to the CANCEL request from UA2. UA1 must also transmit a 487 Request Terminated response to the INVITE from UA2.

Possible Problems:

• None VoIP Consortium 26 SIP Interoperability Test Suite

(SIPIO)

Test SIPIO.1.8: Querying for Capabilities Purpose: This test verifies that a SIP UA can successfully respond to a query of its capabilities. References:

• [SIP-SPEC] – Section 11 Node Requirements: See General Node Requirements. Discussion: The SIP method OPTIONS allows a UA to query another UA or a proxy server as to its capabilities. This allows a client to discover information about the supported methods, content types, extensions, codecs, etc. without "ringing" the other party. For example, before a client inserts a Require header field into an INVITE listing an option that it is not certain the destination UAS supports, the client can query the destination UAS with an OPTIONS to see if this option is returned in a Supported header field. All UAs must support the OPTIONS method. The response code chosen for the response must be the same that would have been chosen had the request been an INVITE. That is, a 200 (OK) would be returned if the UAS is ready to accept a call, a 486 (Busy Here) would be returned if the UAS is busy, etc. This allows an OPTIONS request to be used to determine the basic state of a UAS, which can be an indication of whether the UAS will accept an INVITE request. Allow, Accept, Accept-Encoding, Accept-Language, and Supported header fields should be present in a 200 (OK) response to an OPTIONS request. Test Setup:

Common Test Setup 1 Procedure: Part A: UA2 queries UA1 for its capabilities when not busy.

1. Ensure that UA1 is not involved in any sessions. 2. UA2 sends UA1 an OPTIONS request. 3. Observe traffic on all networks.

Part B: UA2 queries UA1 for its capabilities when busy. 4. UA1 is busy. 5. UA2 sends UA1 an OPTIONS request. 6. Observe traffic on all networks.

Observable Results:

• Part A Step 3: UA1 must transmit a 200 OK response to the OPTIONS request from UA2 listing its capabilities.

• Part A Step 6: UA1 must transmit a 486 Busy Here response to the OPTIONS request from UA2 listing its capabilities.

Possible Problems: VoIP Consortium 27 SIP Interoperability Test Suite

(SIPIO)

• UA1 and or UA2 may not have the ability to send an OPTIONS request.


(SIPIO)

Test SIPIO.1.9: Busy Here Response Status Purpose: This test verifies that a SIP UA properly handles a 486 Busy Here response code as well as being able to respond with this status code when busy. References:

• [SIP-SPEC] – Section 21.4.24 • [SIP-BCFE] – Section 3.9

Node Requirements: See General Node Requirements. Discussion: The 486 Busy Here response code indicates that the callee's end system was contacted successfully, but the callee is currently not willing or able to take additional calls at this end system. The response may indicate a better time to call in the Retry-After header field. The user could also be available elsewhere, such as through a voice mail service. Test Setup:

Common Test Setup 1 Procedure: Part A: UA2 responds with 486 Busy Here response code

1. UA2 is busy. 2. UA1 calls UA2. 3. Observe traffic on all networks. 4. UA2 sends a 486 Busy Here response to the INVITE request from UA1. 5. Observe traffic on all networks.

Part B: UA1 responds with 486 Busy Here response code 6. UA1 is busy. 7. UA2 calls UA1. 8. Observe traffic on all networks.

Observable Results:

• Part A Step 3: UA1 must transmit an INVITE request to UA2. Step 5: UA1 must transmit an ACK request to UA2.

• Part B Step 8: UA1 must transmit a 486 Busy Here response to the INVITE request from UA2.

Possible Problems:

• Many SIP UAs will not return a 486 response, as they have multiple line and other features.


(SIPIO)

Test SIPIO.1.10: Rejecting a Session Offer Purpose: This test verifies that a SIP UA properly handles the rejection of a session offer. References:

• [SIP-SPEC] – Section 13.3.1.3 • [SIP-SPEC] – Section 21.4.26

Node Requirements: See General Node Requirements. Discussion: A UAS rejecting an offer contained in an INVITE should return a 488 (Not Acceptable Here) response. Such a response should include a Warning header field value explaining why the offer was rejected. The 488 Not Acceptable Here response has the same meaning as 606 (Not Acceptable), but only applies to the specific resource addressed by the Request-URI and the request may succeed elsewhere. A message body containing a description of media capabilities may be present in the response, which is formatted according to the Accept header field in the INVITE (or application/sdp if not present), the same as a message body in a 200 (OK) response to an OPTIONS request. Test Setup:

Common Test Setup 1 Procedure: Part A: UA2 responds with 488 Not Acceptable Here response code

1. Configure UA1 and UA2 such that the intersection of supported codecs is the empty set. 2. UA1 calls UA2. 3. Observe traffic on all networks. 4. UA2 sends a 488 Not Acceptable Here response to the INVITE request from UA1. 5. Observe traffic on all networks.

Part B: UA1 responds with 488 Not Acceptable Here response code 6. UA2 calls UA1. 7. UA2 sends an INVITE request to UA1 containing a session description containing codecs not

supported. 8. Observe traffic on all networks.

Observable Results:

• Part A Step 3: UA1 must transmit an INVITE request to UA2. Step 5: UA1 must transmit an ACK request to UA2.

• Part B Step 8: UA1 must transmit a 488 Not Acceptable Here response to the INVITE request from UA2.


(SIPIO)

• It may not be possible to configure either UA2 or UA1 such that the intersection of supported codecs for each device is the empty set.


(SIPIO)

Test SIPIO.1.11: Reliable Delivery of Provisional Responses Purpose: This test verifies that a SIP UA can successfully complete a call requiring the reliable delivery of provisional responses. References:

• [SIP-PRACK] – Section 1 Node Requirements: See General Node Requirements. Discussion: Provisional responses provide information on the progress of the request processing, but are not sent reliably in RFC 3261. It was later observed that reliability was important in several cases, including interoperability scenarios with the PSTN. Therefore, an optional capability was needed to support reliable transmission of provisional responses. The reliability mechanism works by mirroring the reliability mechanisms for 2xx final responses to INVITE. Those requests are transmitted periodically by the Transaction User (TU) until a separate transaction, ACK, is received that indicates reception of the 2xx by the UAC. The reliability for the 2xx responses to INVITE and ACK messages are end-to-end. In order to achieve reliability for provisional responses, we do nearly the same thing. Reliable provisional responses are retransmitted by the TU with an exponential backoff. Those retransmissions cease when a PRACK message is received. The PRACK request plays the same role as ACK, but for provisional responses. There is an important difference, however. PRACK is a normal SIP message, like BYE. As such, its own reliability is ensured hop-by-hop through each stateful proxy. Also like BYE, but unlike ACK, PRACK has its own response. If this were not the case, the PRACK message could not traverse proxy servers compliant to RFC 2543. Test Setup:

Common Test Setup 1 Procedure: Part A: UA1 Calls UA2 requiring reliable provisional responses.

1. Configure UA1 to require sending provisional responses reliably. 2. UA1 calls UA2 requiring reliable provisional responses. 3. Observe traffic on all networks. 4. UA2 transmits a non-100 provisional response to the INVITE request from UA1. 5. Observe traffic on all networks. 6. UA2 answers the call. 7. Observe traffic on all networks. 8. Put UA1 back on the hook. 9. Observe traffic on all networks

Part B: UA2 calls UA1 requiring reliable provisional responses. 10. Configure UA2 to require sending provisional responses reliably. 11. UA2 calls UA1 requiring reliable provisional responses. 12. Observe traffic on all networks. 13. UA2 transmits a PRACK request to indicate reliable delivery of the non-100 provisional response

sent by UA1. VoIP Consortium 32 SIP Interoperability Test Suite

(SIPIO)

14. Observe traffic on all networks. 15. UA1 answers the call. 16. Observe traffic on all networks. 17. Put UA2 back on the hook. 18. Observe traffic on all networks.

Observable Results:

• Part A Step 3: UA1 must transmit an INVITE request listing 100rel in the Require header field. Step 5: UA1 must transmit a PRACK request to UA2 indicating the reliable delivery of the non-100 provisional response sent by UA2. Step 7: Multimedia traffic must be flowing in both directions. Step 9: Multimedia traffic must not be flowing in either direction.

• Part B Step 12: UA1 must transmit a non-100 provisional response listing 100rel in the Require header field. Step 14: UA1 must transmit a 200 OK response to the PRACK request from UA2. Step 16: Multimedia traffic must be flowing in both directions. Step 18: Multimedia traffic must not be flowing in either direction.

Possible Problems:

• UA1 and or UA2 may not have the capability to require 100rel or more generally may not support this extension.


(SIPIO)

Test SIPIO.1.12: Redirection Response Processing Purpose: This test verifies that a SIP UA can successfully handle reception and transmission of redirection responses. References:

• [SIP-SPEC] – Section 21.3 • [SIP-SPEC] – Section 8.1.3.4

Node Requirements: See General Node Requirements. Discussion: Redirection 3xx responses give information about the user's new location, or about alternative services that might be able to satisfy the call. Upon receipt of a redirection response, clients should use the URI(s) in the Contact header field to formulate one or more new requests based on the redirected request. A client starts with an initial target set containing exactly one URI, the Request-URI of the original request. If a client wishes to formulate new requests based on a 3xx class response to that request, it places the URIs to try into the target set. Any new request may receive 3xx responses themselves containing the original URI as a contact. Two locations can be configured to redirect to each other. Placing any given URI in the target set only once prevents infinite redirection loops. Requests to the URIs may be generated serially or in parallel. If contacting an address in the list results in a failure, the element moves to the next address in the list, until the list is exhausted. If the list is exhausted, then the request has failed. Test Setup:

Common Test Setup 1 Procedure: Part A: UA1 redirects UA2 to UA3’s SIP URI.

1. Configure UA1 to redirect incoming calls to UA3’s SIP URI. 2. UA2 calls UA1. 3. Observe traffic on all networks.

Part B: UA1 calls UA2 and is redirected to UA3 to complete the call. 4. Configure UA2 to redirect incoming calls to UA3’s SIP URI. 5. UA1 calls UA2. 6. Observe traffic on all networks. 7. UA2 transmits a 3xx response to the INVITE request from UA1 with a Contact header field

containing UA3’s SIP URI. 8. Observe traffic on all networks. 9. Answer the call at UA3. 10. Observe traffic on all networks. 11. Put UA1 back on the hook. 12. Observe traffic on all networks.

Observable Results: VoIP Consortium 34 SIP Interoperability Test Suite

(SIPIO)

• Part A Step 3: UA1 must transmit a 3xx response to the INVITE request from UA2 with a Contact header field containing UA3’s AOR.

• Part B Step 6: UA1 must transmit an INVITE request to UA2. Step 8: UA1 must transmit a new INVITE request to UA3. Step 10: Multimedia traffic must be flowing in both directions between UA1 and UA3. Step 12: Multimedia traffic must not be flowing in either direction between UA1 and UA3.

Possible Problems:

• UA2 and or UA1 may not support the capability of redirecting incoming requests. • UA1 may not issue new requests when a redirection response is received.


(SIPIO)

Test SIPIO.1.13: Compact Header Field Names Purpose: This test verifies that a SIP UA has the ability to establish and terminate a session when sending or receiving compact header field names directly with another UA. References:

• [SIP-SPEC] – Section 7.3.3 Node Requirements: See General Node Requirements. Discussion: SIP provides a mechanism to represent common header field names in an abbreviated form. This may be useful when messages would otherwise become too large to be carried on the transport available to it (exceeding the maximum transmission unit (MTU) when using UDP, for example). A compact form may be substituted for the longer form of a header field name at any time without changing the semantics of the message. A header field name may appear in both long and short forms within the same message. Implementations must accept both the long and short forms of each header name. Test Setup:

Common Test Setup 1 Procedure: Part A: UA1 calls UA2 using compact header field names

1. Configure UA1 to use compact header field names. 2. UA1 calls UA2. 3. Observe traffic on all networks. 4. UA2 answers the call. 5. Observe traffic on all networks. 6. Put UA1 back on the hook. 7. Observe traffic on all networks.

Part B: UA2 calls UA1 using compact header field names 8. Configure UA2 to use compact header field names. 9. UA2 calls UA1. 10. Observe traffic on all networks. 11. UA1 answers the call. 12. Observe traffic on all networks. 13. Put the UA2 back on the hook. 14. Observe traffic on all networks.

Observable Results:

• Part A Step 3: UA1 must transmit an INVITE request using some compact header field names. Step 5: Multimedia traffic must be flowing in both directions.


(SIPIO)

Step 7: UA1 must transmit a BYE request using some compact header field names and multimedia traffic must not be flowing in either direction.

• Part B Step 10: UA1 must transmit a 1xx response to the INVITE request from UA2. Step 12: UA1 must transmit a 2xx final response to the INVITE request from UA2 and multimedia traffic must be flowing in both directions. Step 14: UA1 must transmit a 200 OK response to the BYE request from UA2 and multimedia traffic must not be flowing in either direction.

Possible Problems:

• UA1 and or UA2 may not have the capability to send compact header field names.


(SIPIO)

Group 2: Single Proxy Server Scope: Tests in this group verify that target devices are able to engage in SIP registration and multimedia session while employing a single proxy/registrar server. Overview:

SIP proxies are elements that route SIP requests to user agent servers and SIP responses to user agent clients. A request may traverse several proxies on its way to a UAS. Each will make routing decisions, modifying the request before forwarding it to the next element. Responses will route through the same set of proxies traversed by the request in the reverse order.

SIP also offers a discovery capability. If a user wants to initiate a session with another user, SIP must discover the current host(s) at which the destination user is reachable. This discovery process is frequently accomplished by SIP network elements such as proxy servers and redirect servers which are responsible for receiving a request, determining where to transmit it based on knowledge of the location of the user, and then sending it there. Registration creates bindings in a location service for a particular domain that associates an address-of-record URI with one or more contact addresses. Thus, when a proxy for that domain receives a request whose Request-URI matches the address-of-record, the proxy will forward the request to the contact addresses registered to that address-of-record. Registration entails sending a REGISTER request to a special type of UAS known as a registrar. A registrar acts as the front end to the location service for a domain, reading and writing mappings based on the contents of REGISTER requests. A proxy server that is responsible for routing requests for that domain then typically consults this location service.


(SIPIO)

Test SIPIO.2.1: Unauthenticated Addition of Registration Bindings Purpose: This test verifies that a SIP UA can successfully add registration bindings to a SIP registrar without using authentication. References:

• [SIP-SPEC] – Section 10.2.1 Node Requirements: See General Node Requirements. Discussion: REGISTER requests add, remove, and query bindings. A REGISTER request can add a new binding between an address-of-record and one or more contact addresses. Adding bindings requires that the REGISTER request sent to a registrar includes the contact address(es) to which SIP requests for the address-of-record should be forwarded. The address-of-record is included in the To header field of the REGISTER request. The Contact header field values of the request typically consist of SIP or SIPS URIs that identify particular SIP endpoints, but they may use any URI scheme. The 2xx response to the REGISTER request will contain, in a Contact header field, a complete list of bindings that have been registered for this address-of-record at this registrar. Test Setup:

Common Test Setup 2; UA1 is not registered at the start of this test. Procedure: Part A: Registrar URI contains PS1’s IP address.

1. Configure PS1 to allow unauthenticated registration. 2. Configure UA1 to register using PS1’s IP address as the host part. 3. Activate UA1. 4. Observe traffic on all networks.

Part B: Registrar URI contains PS1’s FQDN. 5. Configure PS1 to allow unauthenticated registration. 6. Activate UA1. 7. Observe traffic on all networks.

Observable Results:

• Part A Step 4: UA1 must transmit a REGISTER request to PS1 containing a Contact header field with a valid SIP URI for contacting UA1. PS1 must transmit a 200 OK response to the REGISTER from UA1 containing the new registration binding to UA1.

• Part B Step 7: UA1 must transmit a REGISTER request to PS1. The Contact header field must contain the new registration binding. PS1 must transmit a 200 OK response to the REGISTER request from UA1 containing the new registration binding.


(SIPIO)

• PS1 may not support unauthenticated registration.


(SIPIO)

Test SIPIO.2.2: Authenticated Addition of Registration Bindings Purpose: This test verifies that a SIP UA can successfully add registration bindings to a SIP registrar that requires authentication. References:

• [SIP-SPEC] – Section 10.3 • [SIP-SPEC] – Section 22

Node Requirements: See General Node Requirements. Discussion: A registrar should authenticate a UAC attempting to register. In SIP, a UAS uses the 401 (Unauthorized) response to challenge the identity of a UAC. Additionally, registrars and redirect servers may make use of 401 (Unauthorized) responses for authentication. The WWW-Authenticate response-header field must be included in 401 (Unauthorized) response messages. The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the realm. When the originating UAC receives the 401 (Unauthorized), it should, if it is able, re-originate the request with the proper credentials. Once credentials have been located, any UA that wishes to authenticate itself with a UAS or registrar -- usually, but not necessarily, after receiving a 401 (Unauthorized) response – may do so by including an Authorization header field with the request. The Authorization field value consists of credentials containing the authentication information of the UA for the realm of the resource being requested as well as parameters required in support of authentication and replay protection. When a UAC resubmits a request with its credentials after receiving a 401 (Unauthorized) or 407 (Proxy Authentication Required) response, it must increment the CSeq header field value as it would normally when sending an updated request. Test Setup:

Common Test Setup 2; UA1 is not registered at the start of this test. Procedure: Part A: UA1’s Registrar Configured as PS1’s IP address.

1. Configure UA1 to register using PS1’s IP address as the host part. 2. Activate UA1. 3. Observe traffic on all networks.

Part B: UA1’s Registrar Configured as PS1’s FQDN. 4. Activate UA1. 5. Observe traffic on all networks.

Part C: Credential Mismatch. 6. Configure UA1 to register using an incorrect username and password. 7. Activate UA1. 8. Observe traffic on all networks..

Observable Results:

• Part A VoIP Consortium 41 SIP Interoperability Test Suite

(SIPIO)

Step 3: UA1 must transmit a REGISTER request to PS1 containing a Contact header field with a valid SIP URI for contacting UA1. PS1 must send a 401 Unauthorized response to the REGISTER request from UA1 containing a WWW-Authenticate header field. UA1 must resubmit the REGISTER request to PS1 adding an Authorization header field with the proper credentials and the numeric value in the CSeq header must be incremented. PS1 must transmit a 200 OK response to the new REGISTER request from UA1 with the new binding for UA1.

• Part B Step 5: UA1 must transmit a REGISTER request to PS1 containing a Contact header field with a valid SIP URI for contacting UA1. PS1 must send a 401 Unauthorized response to the REGISTER request from UA1 containing a WWW-Authenticate header field. UA1 must resubmit the REGISTER request to PS1 adding an Authorization header field with the proper credentials and the numeric value in the CSeq header must be incremented. PS1 must transmit a 200 OK response to the REGISTER request from UA1 with the new binding for UA1.

• Part C Step 8: UA1 must transmit a REGISTER request to PS1 containing a Contact header field with a valid SIP URI for contacting UA1. PS1 must send a 401 Unauthorized response to the REGISTER request from UA1 containing a WWW-Authenticate header field. UA1 must resubmit the REGISTER request to PS1 adding an Authorization header field with the incorrect credentials calculated from the invalid username and password. The numeric value in the CSeq header must be incremented. PS1 must transmit a 401 Unauthorized response to the new REGISER from UA1.

Possible Problems:

• None


(SIPIO)

Test SIPIO.2.3: Refreshing Registration Bindings Purpose: This test verifies that a SIP UA can successfully update a previous registration before it expires. References:

• [SIP-SPEC] – Section 10.2.4 Node Requirements: See General Node Requirements. Discussion: Each UA is responsible for refreshing the bindings that it has previously established. The 200 (OK) response from the registrar contains a list of Contact fields enumerating all current bindings. The UA compares each contact address to see if it created the contact address. If so, it updates the expiration time interval according to the expires parameter or, if absent, the Expires header field value. The UA then issues a REGISTER request for each of its bindings before the expiration interval has elapsed. Test Setup:

Common Test Setup 2; UA1 is not registered at the start of this test. Procedure: Part A: Refresh unauthenticated registration.

1. Configure PS1 to accept unauthenticated registrations. 2. Activate UA1. 3. Wait 60 seconds. 4. Observe traffic on all networks.

Part B: Refresh authenticated registration 5. Activate UA1. 6. Wait 60 seconds. 7. Observe traffic on all networks.

Part C: Registration Timeout 8. Activate UA1. 9. Observe traffic on all links and networks. 10. Disconnect UA1. 11. Wait 60 seconds. 12. UA2 calls UA1. 13. UA2 transmits an INVITE request for UA1 to PS1. 14. Observe traffic on all networks.

Observable Results:

• Part A Step 4: UA1 must transmit a REGISTER request to PS1 with a Contact header field updating the registration binding. PS1 must transmit a 200 OK response to the REGISTER request from UA1 with a Contact header field containing the updated registration binding.


(SIPIO)

• Part B Step 7: UA1 must transmit a REGISTER request to PS1 with a Contact header field containing the updated registration binding and an Authorization header field containing the credentials used in the initial registration. PS1 must transmit a 200 OK response to the REGISTER request from UA1 with a Contact header field containing the registration binding updated by UA1.

• Part C Step 9: UA1 must transmit a REGISTER request to PS1 containing a Contact header field with a valid SIP URI for contacting UA1. PS1 must send a 401 Unauthorized response to the REGISTER request from UA1 containing a WWW-Authenticate header field. UA1 must resubmit the REGISTER request to PS1 adding an Authorization header field with the proper credentials and the numeric value in the CSeq header must be incremented. PS1 must transmit a 200 OK response to the REGISTER request from UA1 with the new binding for UA1. Step 14: PS1 must transmit a 480 Temporarily Unavailable response to the INVITE request from UA2.

Possible Problems:

• None


(SIPIO)

Test SIPIO.2.4: Acceptance of Registrar Expiration Interval Purpose: This test verifies that a SIP UA accepts the registration expiration interval given by the registrar in the 200 OK response. References:

• [SIP-SPEC] – Section 10.2.4 • [SIP-SPEC] – Section 10.3

Node Requirements: See General Node Requirements. Discussion: The registrar may choose an expiration less than the requested expiration interval. Allowing the registrar to set the registration interval protects it against excessively frequent registration refreshes while limiting the state that it needs to maintain and decreasing the likelihood of registrations going stale. The UA compares each contact address in the registration response to see if it created the contact address, using comparison rules in Section 19.1.4 of RFC 3261. If so, it updates the expiration time interval according to the expires parameter or, if absent, the Expires field value. The UA then issues a REGISTER request for each of its bindings before the expiration interval has elapsed. Test Setup:

Common Test Setup 2; UA1 is not registered at the start of this test. Procedure: Part A: Registrar sets registration expiration interval to 30 seconds.

1. Configure PS1 to set the expiration interval for registrations to 30 seconds. 2. Activate SIP Endpoint. 3. Observe traffic on all networks. 4. Wait 30 seconds. 5. Observe traffic on all networks.

Observable Results:

• Part A Step 3: UA1 must transmit a REGISTER request to PS1. PS1 must transmit a 200 OK response to the REGISTER request from UA1 indicating a registration expiration interval of 30 seconds. Step 5: UA1 must transmit a REGISTER request to PS1 before the expiration interval indicated in the 200 OK response has elapsed. PS1 must transmit a 200 OK response to the REGISTER request that contains the updated contact binding.

Possible Problems:

• It may not be possible to configure the registrar with a particular expiration interval for registrations.


(SIPIO)

Test SIPIO.2.5: Removal of Registration Bindings Purpose: This test verifies that a SIP UA can properly remove registration bindings that it has added to a registrar. References:

• [SIP-SPEC] – Section 10.2.2 Node Requirements: See General Node Requirements. Discussion: Registrations are soft state and expire unless refreshed, but can also be explicitly removed. A client can attempt to influence the expiration interval selected by the registrar. A UA requests the immediate removal of a binding by specifying an expiration interval of "0" for that contact address in a REGISTER request. UAs should support this mechanism so that bindings can be removed before their expiration interval has passed. Test Setup:

Common Test Setup 2; UA1 is not registered at the start of this test. Procedure: Part A: UA1 removes registration binding.

1. Activate UA1. 2. Observe traffic on all networks. 3. UA1 sends a REGISTER request with the expiration interval for the contact binding set to 0. 4. Observe traffic on all networks.

Observable Results:

• Part A Step 2: UA1 must transmit a REGISTER request to PS1 to add the initial registration binding. PS1 must transmit a 200 OK response to the REGISTER request from UA1 that contains the new registration binding. Step 4: UA1 must transmit a REGISTER request to PS1. This request must indicate the removal of the registration bindings created previously by UA1. PS1 must transmit a 200 OK response to the REGISTER request from UA1 that does not contain the removed binding.

Possible Problems:

• It may not be possible to configure the registrar with a particular expiration value for registrations.


(SIPIO)

Test SIPIO.2.6: Registration using Compact Header Field Names Purpose: This test verifies that a SIP UA has the ability to register using compact header field names. References:


Common Test Setup 2; UA1 is not registered at the start of this test. Procedure: Part A: UA1 registers to PS1 using compact header field names

1. Configure PS1 to allow unauthenticated registrations. 2. Configure UA1 to use compact header field names. 3. Activate UA1. 4. Observe traffic on all networks.

Part B: UA1 updates registration using compact header field names 5. Configure PS1 to allow unauthenticated registrations. 6. Configure UA1 to use compact header field names. 7. Activate UA1. 8. Wait 60 seconds. 9. Observe traffic on all networks.

Observable Results:

• Part A Step 3: UA1 must transmit a REGISTER request to PS1 using some compact header field names. PS1 must transmit a 200 OK response to the REGISTER from UA1 with a contact header field containing the new registration binding.

• Part B Step 9: UA1 must transmit a REGISTER request to PS1 containing some compact header field names to PS1 before the expiration time has elapsed. PS1 must transmit a 200 OK response to the REGISTER request from UA1 with a contact header field containing the updated registration binding.


(SIPIO)

Possible Problems:

• UA1 may not support sending compact header field names.


(SIPIO)

Test SIPIO.2.7: Initiating a Session through one Proxy Purpose: This test verifies that a UAC can successfully begin initiation of a session with a UAS through a single proxy server. References:

• [SIP-SPEC] – Section 13.1 • [SIP-SPEC] – Section 8.1.1.2 • [SIP-BCFE] – Section 3.2 • [SDP-SPEC] – Section 1

Node Requirements: See General Node Requirements. Discussion: When a user agent client desires to initiate a session (for example, audio, video, or a game), it formulates an INVITE request. The INVITE request asks a server to establish a session. This request may be forwarded by proxies, eventually arriving at one or more UAS that can potentially accept the invitation. The To header field first and foremost specifies the desired "logical" recipient of the request, or the address-of-record of the user or resource that is the target of this request. This may or may not be the ultimate recipient of the request. The To header field may contain a SIP or SIPS URI, but it may also make use of other URI schemes when appropriate. All SIP implementations must support the SIP URI scheme. Test Setup:

Common Test Setup 2 Procedure: Part A: Callee SIP URI contains IPv4 address.

1. UA1 calls UA2 using the IPv4 address of PS1 as the host part. 2. Observe traffic on all networks.

Part B: Callee SIP URI contains FQDN. 3. UA1 calls UA2 using the FQDN of PS1 as the host part. 4. Observe traffic on all networks.

Observable Results:

• Part A Step 2: UA1 must transmit an INVITE request to PS1 and the host part of the Request URI must be the IPv4 address of PS1. UA1 must include an SDP offer in the body of the request. PS1 must forward the INVITE request to UA2.

• Part B Step 4: UA1 must transmit an INVITE request to PS1 and the host part of the Request URI must be the FQDN of PS1. UA1 must include an SDP offer in the body of the request. PS1 must forward the INVITE request to UA2.

Possible Problems:

VoIP Consortium 49 SIP Interoperability Test Suite (SIPIO)

• UA1 may expect the session offer to be in the final response from the UAS.


(SIPIO)

Test SIPIO.2.8: Session Progress through one Proxy Purpose: This test verifies that a UAS can successfully handle provisional responses indicating session progress when traversing a single proxy server. References:

• [SIP-SPEC] – Section 13.3.1.1 • [SIP-SPEC] – Section 21.1.2 • [SIP-BCFE] – Section 3.2

Node Requirements: See General Node Requirements. Discussion: When a user agent client desires to initiate a session (for example, audio, video, or a game), it formulates an INVITE request to send to the UAS. User agent servers will frequently need to query the user about whether to accept the invitation. If the UAS is not able to answer the invitation immediately, it can choose to indicate some kind of progress to the UAC (for example, an indication that a phone is ringing). This is accomplished with a provisional response between 101 and 199. A UAS may send as many provisional responses as it likes. However, these will not be delivered reliably. The 180 Ringing response indicates that the UA receiving the INVITE is trying to alert the user. This response may be used to initiate local ringback. Test Setup:

Common Test Setup 2 Procedure: Part A: UA1 indicates session progress

1. UA2 calls UA1. 2. UA2 sends an INVITE request to PS1. 3. Observe traffic on all networks.

Observable Results:

• Part A Step 3: PS1 must forward the INVITE request to UA1. UA1 must transmit a non-100 provisional response to the INVITE request from UA1. PS1 must forward the provisional response to UA2.

Possible Problems:

• None


(SIPIO)

Test SIPIO.2.9: Accepting an Invitation to a Session through one Proxy Purpose: This test verifies that a UAS can successfully accept an invitation to a session when traversing a single proxy server. References:

• [SIP-SPEC] – Section 13.1 • [SIP-BCFE] – Section 3.2

Node Requirements: See General Node Requirements. Discussion: After possibly receiving one or more provisional responses, the UAC will get one or more 2xx responses or one non-2xx final response. A 2xx response to an INVITE establishes a session, and it also creates a dialog between the UA that issued the INVITE and the UA that generated the 2xx response.

Test Setup:


Part A: UA1 accepts session.

1. UA2 calls UA1. 2. UA1 answers the call. 3. Observe traffic on all networks.

Observable Results:

• Part A Step 3: UA1 must transmit a 2xx final response to the INVITE request from UA1 and should indicate the acceptance of the session to the user. UA1 must include an SDP answer in the body of the response. PS1 must forward the final response to UA2.

Possible Problems:

• The 2xx may contain a session answer instead of an offer if the INVITE request sent by UA1 did not contain an offer.


(SIPIO)

Test SIPIO.2.10: Reliable Delivery of Final Responses through one Proxy Purpose: This test verifies that a UAC can indicate to a UAS the reliable delivery of a final response received for an INVITE request when traversing a single proxy server. References:


Node Requirements: See General Node Requirements. Discussion: Because of the protracted amount of time it can take to receive final responses to INVITE, the reliability mechanisms for INVITE transactions differ from those of other requests. Once it receives a final response, the UAC needs to transmit an ACK for every final response it receives. The sequence number of the CSeq header field must be the same as the INVITE being acknowledged, but the CSeq method must be ACK. Test Setup:

Common Test Setup 2 Procedure: Part A: Record routing enabled on PS1.

1. UA1 calls UA2. 2. UA2 answers the call. 3. UA2 transmits a 200 OK response to the INVITE request from UA1. 4. Observe traffic on all networks.

Part B: Record routing disabled on PS1. 5. Disable record routing on PS1. 6. UA1 calls UA2. 7. UA2 answers the call. 8. UA2 transmits a 200 OK response to the INVITE request from UA1. 9. Observe traffic on all networks.

Observable Results:

• Part A Step 4: PS1 must forward the 200 OK response to UA1. UA1 must transmit an ACK request to PS1. PS1 must forward the ACK request to UA2.

• Part B Step 9: PS1 must forward the 200 OK response to UA1. UA1 must transmit an ACK request to UA2.

Possible Problems:

• A node may not support reliable provisional responses. VoIP Consortium 53 SIP Interoperability Test Suite

(SIPIO)

Test SIPIO.2.11: Establish and Terminate Session through one Proxy Purpose: This test verifies that a SIP UA can successfully establish and terminate a multimedia session when employing a single proxy network architecture. References:



Common Test Setup 2 Procedure: Part A: UA1 calls UA2 with record routing disabled on PS1.

1. Disable record routing on PS1. 2. UA1 calls UA2. 3. Observe traffic on all networks. 4. UA2 transmits a 180 ringing response to the INVITE request from UA1. 5. Observe traffic on all networks. 6. UA2 answers the call. 7. UA2 transmits a 200 OK response to the INVITE request from UA1. 8. Observe traffic on all networks. 9. UA1 terminates the call. 10. Observe traffic on all networks. 11. UA2 transmits a 200 OK response to the BYE request from UA1. 12. Observe traffic on all networks.

Part B: UA2 calls UA1 with record routing disabled on PS1. 13. Disable record routing on PS1. 14. UA2 calls UA1. 15. UA2 transmits an INVITE request to PS1. 16. Observe traffic on all networks. 17. UA1 answers the call. 18. Observe traffic on all networks. 19. UA2 transmits an ACK request to UA1. 20. Observe traffic on all networks. 21. UA1 terminates the call.


(SIPIO)

22. Observe traffic on all networks. 23. UA2 transmits a 200 OK response to the BYE request from UA1. 24. Observe traffic on all networks.

Part C: UA1 calls UA2 with record routing enabled on PS1. 25. UA1 calls UA2. 26. Observe traffic on all networks. 27. UA2 transmits a 180 ringing response to the INVITE request from UA1. 28. Observe traffic on all networks. 29. UA2 answers the call. 30. UA2 transmits a 200 OK response to the INVITE request from UA1. 31. Observe traffic on all networks. 32. UA1 terminates the call. 33. Observe traffic on all networks. 34. UA2 transmits a 200 OK response to the BYE request from UA1. 35. Observe traffic on all networks.

Part D: UA2 calls UA1 with record routing enabled on PS1. 36. UA2 calls UA1. 37. UA2 transmits an INVITE request to PS1. 38. Observe traffic on all networks. 39. UA1 answers the call. 40. Observe traffic on all networks. 41. UA2 transmits an ACK request to PS1. 42. Observe traffic on all networks. 43. UA1 terminates the call. 44. Observe traffic on all networks. 45. UA2 transmits a 200 OK response to the BYE request from UA1. 46. Observe traffic on all networks.

Observable Results:

• Part A Step 3: UA1 must transmit an INVITE request to PS1. PS1 must forward the INVITE request to UA2. Step 5: PS1 must forward the 180 Ringing response to UA1. Step 8: PS1 must forward the 200 OK to UA1. UA1 must transmit an ACK request to UA2. Multimedia traffic must be flowing in both directions between UA1 and UA2. Step 10: UA1 must transmit a BYE request to UA2. Step 12: Multimedia traffic must not be flowing in either direction between UA1 and UA2.

• Part B Step 16: PS1 must forward the INVITE request to UA1. UA1 must transmit a 180 Ringing response to the INVITE request from UA1. PS1 must forward the 180 Ringing response to UA2. Step 18: UA1 must transmit a 200 OK response to the INVITE from UA2. PS1 must forward the 200 OK response to UA2. Step 20: Multimedia traffic must be flowing in both directions between UA1 and UA2. Step 22: UA1 must transmit a BYE request to UA2. Step 24: Multimedia traffic must not be flowing in either direction between UA1 and UA2.

• Part C


(SIPIO)

Step 26: UA1 must transmit an INVITE request to PS1. PS1 must forward the INVITE request to UA2. Step 28: PS1 must forward the 180 Ringing response to UA1. Step 31: PS1 must forward the 200 OK to UA1. UA1 must transmit an ACK request to PS1. PS1 must forward the ACK request to UA2. Multimedia traffic must be flowing in both directions between UA1 and UA2. Step 33: UA1 must transmit a BYE request to PS1. PS1 must forward the BYE request to UA2. Step 35: PS1 must forward the 200 OK response to UA1. Multimedia traffic must not be flowing in either direction between UA1 and UA2.

• Part D Step 38: PS1 must forward the INVITE request to UA1. UA1 must transmit a 180 Ringing response to the INVITE request from UA2. PS1 must forward the 180 Ringing response to UA2. Step 40: UA1 must transmit a 200 OK response to the INVITE request from UA2. PS1 must forward the 200 OK response to UA2. Step 42: PS1 must forward the ACK request to UA1. Multimedia traffic must be flowing in both directions between UA1 and UA2. Step 44: UA1 must transmit a BYE request to PS1. PS1 must forward the BYE request to UA2. Step 46: PS1 must forward the 200 OK response to UA1. Multimedia traffic must not be flowing in either direction between UA1 and UA2.

Possible Problems:

• PS1 may not support disabling record routing.


(SIPIO)

Test SIPIO.2.12: Session Establishment with Proxy Authentication Purpose: This test verifies that a SIP UA can successfully establish and terminate a multimedia session when a proxy server in the request path requires authentication. References:


Node Requirements: See General Node Requirements. Discussion: A common scenario involves a proxy server that requires authentication before forwarding requests. A user wishes to make a call to a user in the proxy domain. The calling user has valid credentials within the domain. Since the initial INVITE does not contain the Authorization credentials the proxy requires, a 407 Proxy Authorization response is sent containing the challenge information. A new INVITE is then sent containing the correct credentials and the call proceeds. The proxy server inserts a Record-Route header into the INVITE message to ensure that it is present in all subsequent message exchanges. Test Setup:

Common Test Setup 2 Procedure: Part A: UA1 calls UA2.

1. Configure PS1 to require authentication for requests originating from UA1. 2. UA1 calls UA2. 3. Observe traffic on all networks. 4. UA2 transmits a 180 Ringing response to the INVITE request from UA1. 5. Observe traffic on all networks. 6. UA2 answers the call. 7. UA2 transmits a 200 OK response to the INVITE request from UA1. 8. Observe traffic on all networks. 9. UA1 terminates the call. 10. Observe traffic on all networks. 11. UA2 transmits a 200 OK response to the BYE request from UA1. 12. Observe traffic on all networks.

Observable Results:

• Part A Step 3: UA1 must transmit an INVITE request to PS1. PS1 must transmit a 407 Proxy Authorization Required response to the INVITE request from UA1. UA1 must transmit a new INVITE request with the correct credentials for PS1. PS1 must forward the INVITE request to UA2. Step 5: PS1 must forward the 180 Ringing response to UA1.


(SIPIO)

Step 8: PS1 must forward the 200 OK response to UA1. UA1 must transmit an ACK request to PS1. PS1 must forward the ACK request to UA2. Multimedia traffic must be flowing in both directions between UA1 and UA2. Step 10: UA1 must transmit a BYE request to PS1. PS1 must forward the BYE request to UA2. Step 12: PS1 must forward the 200 OK response to UA1. Multimedia traffic must not be flowing in either direction between UA1 and UA2.

Possible Problems:

• None


(SIPIO)

Test SIPIO.2.13: Modifying an Existing Session through one Proxy Purpose: This test verifies that a SIP UA can successfully modify and accept modifications to a session that has already been established when employing a single proxy server. References:




1. UA1 calls UA2. 2. UA2 answers the call. 3. Observe traffic on all networks. 4. UA1 modifies the session with UA2. 5. Observe traffic on all networks. 6. UA2 transmits a final response to the re-INVITE request from UA1. 7. Observe traffic on all networks. 8. UA1 reverts the session to its initially negotiated session parameters. 9. Observe traffic on all networks. 10. UA2 transmits a final response to the re-INVITE request from UA1. 11. Observe traffic on all networks. 12. UA1 terminates the call with UA2. 13. Observe traffic on all networks.

Part B: UA1 calls and UA2 modifies session. 14. UA1 calls UA2. 15. UA2 answers the call. 16. Observe traffic on all networks. 17. UA2 transmits a re-INVITE request to UA1 that modifies the session parameters. 18. Observe traffic on all networks. 19. UA2 transmits an ACK request to PS1. 20. Observe traffic on all networks.


(SIPIO)

21. UA2 transmits a re-INVITE request to UA1 containing the session parameters that were negotiated initially.

22. Observe traffic on all networks. 23. UA2 transmits an ACK request to UA1. 24. UA1 terminates the call with UA2. 25. Observe traffic on all networks.

Part C: UA2 calls and UA1 modifies session. 26. UA2 calls UA1. 27. UA1 answers the call. 28. Observe traffic on all networks. 29. UA1 modifies the session with UA2. 30. Observe traffic on all networks. 31. UA2 transmits a final response to the re-INVITE request from UA1. 32. Observe traffic on all networks. 33. UA1 reverts the session to its initially negotiated session parameters. 34. Observe traffic on all networks. 35. UA2 transmits a final response to the re-INVITE request from UA1. 36. Observe traffic on all networks. 37. UA1 terminates the call with UA2. 38. Observe traffic on all networks.

Part D: UA2 calls and modifies session. 39. UA2 calls UA1. 40. UA1 answers the call. 41. Observe traffic on all networks. 42. UA2 transmits a re-INVITE request to UA1 that modifies the session parameters. 43. Observe traffic on all networks. 44. UA2 transmits an ACK request to UA1. 45. Observe traffic on all networks. 46. UA2 transmits a re-INVITE request to UA1 containing the session parameters that were

negotiated initially. 47. Observe traffic on all networks. 48. UA2 transmits an ACK request to UA1. 49. Observe traffic on all networks. 50. UA2 terminates the call with UA1. 51. UA2 transmits a BYE request to UA1. 52. Observe traffic on all networks.

Part E: UA1 calls and modifies session with record routing disabled on PS1. 53. Disable record routing on PS1. 54. UA1 calls UA2. 55. UA2 answers the call. 56. Observe traffic on all networks. 57. UA1 modifies the session with UA2. 58. Observe traffic on all networks. 59. UA2 transmits a final response to the re-INVITE request from UA1. 60. Observe traffic on all networks. 61. UA1 reverts the session to its initially negotiated session parameters. 62. Observe traffic on all networks. 63. UA2 transmits a final response to the re-INVITE request from UA1. 64. Observe traffic on all networks.


(SIPIO)

65. UA1 terminates the call with UA2. 66. Observe traffic on all networks.

Observable Results:

• Part A Step 3: Multimedia traffic must be flowing in both directions. Step 5: UA1 must transmit a re-INVITE request to PS1 that modifies the session parameters. PS1 must forward the re-INVITE request to UA2. Step 7: PS1 must forward the final response to UA1. UA1 must transmit an ACK request to PS1. PS1 must forward the ACK request to UA2. Step 9: UA1 must transmit a re-INVITE request containing the session parameters that were negotiated initially. PS1 must forward the re-INVITE request to UA2. Step 11: PS1 must forward the final response to UA1. UA1 must transmit an ACK request to PS1. PS1 must forward the ACK request to UA2. Step 13: UA1 must transmit a BYE request to PS1. PS1 must forward the BYE request to UA2.

• Part B Step 16: Multimedia traffic must be flowing in both directions. Step 18: PS1 must forward the re-INVITE request to UA1. UA1 must transmit a final response to the re-INIVTE request from UA2. PS1 must forward the final response to UA2. Step 20: PS1 must forwards the ACK request to UA1. Step 22: PS1 must forward the re-INVITE request to UA1. UA1 must transmit a final response to the re-INIVTE request from UA2. PS1 must forward the final response to UA2. Step 24: UA1 must transmit a BYE request to PS1. PS1 must forward the BYE request to UA2.

• Part C Step 28: Multimedia traffic must be flowing in both directions. Step 30: UA1 must transmit a re-INVITE request to PS1 that modifies the session parameters. PS1 must forward the re-INVITE request to UA2. Step 32: PS1 must forward the final response to UA1. UA1 must transmit an ACK request to PS1. PS1 must forward the ACK request to UA2. Step 34: UA1 must transmit a re-INVITE request containing the session parameters that were negotiated initially. PS1 must forward the re-INVITE request to UA2. Step 36: PS1 must forward the final response to UA1. UA1 must transmit an ACK request to PS1. PS1 must forward the ACK request to UA2. Step 37: UA1 must transmit a BYE request to PS1. PS1 must forward the BYE request to UA2.

• Part D Step 41: Multimedia traffic must be flowing in both directions. Step 43: PS1 must forward the re-INVITE request to UA1. UA1 must transmit a final response to the re-INIVTE request from UA2. PS1 must forward the final response to UA2. Step 45: PS1 must forward the ACK request to UA1. Step 47: PS1 must forward the re-INVITE request to UA1. UA1 must transmit a final response to the re-INIVTE request from UA2. PS1 must forward the final response to UA2. Step 49: PS1 must forward the ACK request to UA1. Step 49: UA1 must transmit a 200 OK response to the BYE request from UA2. PS1 must forward the 200 OK response to UA2.

• Part E


(SIPIO)

Step 56: Multimedia traffic must be flowing in both directions. Step 58: UA1 must transmit a re-INVITE request to UA2. Step 60: UA1 must transmit an ACK request to UA2. Step 62: UA1 must transmit a re-INVITE request containing the session parameters that were negotiated initially. Step 64: UA1 must transmit an ACK request to UA2. Step 66: UA1 must transmit a BYE request to UA2.

Possible Problems:


session parameters.


(SIPIO)

Test SIPIO.2.14: Cancellation with a Single Proxy Purpose: This test verifies that a SIP UA can successfully cancel the initiation of a multimedia session with another user agent utilizing a single proxy server. References:

• [SIP-SPEC] – Section 9 • [SIP-BCFE] – Section 3.8

Node Requirements: See General Node Requirements. Discussion: The CANCEL request, as the name implies, is used to cancel a previous request sent by a client. Specifically, it asks the UAS to cease processing the request and to generate an error response to that request. CANCEL is best for INVITE requests, which can take a long time to generate a response. In that usage, a UAS that receives a CANCEL request for an INVITE, but has not yet sent a final response, would "stop ringing", and then respond to the INVITE with a specific error response (a 487). Test Setup:



1. UA1 calls UA2. 2. Put UA1 back on the hook. 3. Observe traffic on all networks. 4. UA2 transmits a 200 OK to the CANCEL request from PS1. 5. UA2 transmits a 487 Request Terminated response to the INVITE request from UA1. 6. Observe traffic on all networks.

Part B: UA2 initiates call. 7. UA2 calls UA1. 8. Put the UA2 back on the hook. 9. UA2 transmits a CANCEL request to PS1. 10. Observe traffic on all networks.

Observable Results:

• Part A Step 3: UA1 must transmit a CANCEL request to PS1. PS1 must transmit a 200 OK response to the CANCEL request from UA1. PS1 must transmit a CANCEL request to UA2. Step 6: PS1 must transmit an ACK request to UA2. PS1 must forward the 487 response to UA1. UA1 must transmit an ACK request to PS1.

• Part B Step 10: PS1 must transmit a 200 OK response to the CANCEL request from UA2. PS1 must transmit a CANCEL request to UA1. UA1 must transmit a 200 OK to the CANCEL request from PS1. UA1 must transmit a 487 Request Terminated response to the INVITE


(SIPIO)

request from UA2. PS1 must transmit an ACK request to UA1. PS1 must forward the 487 response to UA2.

Possible Problems:

• None


(SIPIO)

Test SIPIO.2.15: Querying for Capabilities through one Proxy Purpose: This test verifies that a SIP UA can successfully respond to a query of its capabilities when traversing a single proxy server. References:

• [SIP-SPEC] – Section 11 Node Requirements: See General Node Requirements. Discussion: The SIP method OPTIONS allows a UA to query another UA or a proxy server as to its capabilities. This allows a client to discover information about the supported methods, content types, extensions, codecs, etc. without "ringing" the other party. For example, before a client inserts a Require header field into an INVITE listing an option that it is not certain the destination UAS supports, the client can query the destination UAS with an OPTIONS to see if this option is returned in a Supported header field. All UAs must support the OPTIONS method. The response code chosen for the response must be the same that would have been chosen had the request been an INVITE. That is, a 200 (OK) would be returned if the UAS is ready to accept a call, a 486 (Busy Here) would be returned if the UAS is busy, etc. This allows an OPTIONS request to be used to determine the basic state of a UAS, which can be an indication of whether the UAS will accept an INVITE request. Allow, Accept, Accept-Encoding, Accept-Language, and Supported header fields should be present in a 200 (OK) response to an OPTIONS request. Test Setup:

Common Test Setup 2 Procedure: Part A: UA2 queries UA1 for its capabilities when not busy.

1. Ensure that UA1 is not involved in any sessions. 2. UA2 transmits an OPTIONS request to PS1. 3. Observe traffic on all networks.

Part B: UA2 queries UA1 for its capabilities when busy. 4. UA2 is busy. 5. UA2 transmits an OPTIONS request to PS1. 6. Observe traffic on all networks.

Observable Results:

• Part A Step 3: PS1 must forward the OPTIONS request to UA1. UA1 must transmit a 200 OK response to the OPTIONS request from UA2 listing its capabilities. PS1 must forward the 200 OK response to UA2.

• Part B


(SIPIO)

Step 6: PS1 must forward the OPTIONS request to UA1. UA1 must transmit a 486 Busy Here response to the OPTIONS request from UA2 listing its capabilities. PS1 must forward the 486 response to UA1.

Possible Problems:

• UA2 may not have the ability to send an OPTIONS request.


(SIPIO)

Test SIPIO.2.16: Busy Response through one Proxy Purpose: This test verifies that a SIP UA properly handles a 486 Busy Here response code as well as being able to respond with this status code when busy and messages traverse a single proxy server. References:

• [SIP-SPEC] – Section 21.4.24 • [SIP-BCFE] – Section 3.9

Node Requirements: See General Node Requirements. Discussion: The 486 Busy Here response code indicates that the callee's end system was contacted successfully, but the callee is currently not willing or able to take additional calls at this end system. The response may indicate a better time to call in the Retry-After header field. The user could also be available elsewhere, such as through a voice mail service. Test Setup:

Common Test Setup 2 Procedure: Part A: UA2 responds with 486 Busy Here response code

1. UA2 is busy. 2. UA1 calls UA2. 3. Observe traffic on all networks. 4. UA2 sends a 486 Busy Here response to the INVITE request from UA1. 5. Observe traffic on all networks.

Part B: UA1 responds with 486 Busy Here response code 6. UA2 is busy. 7. UA2 calls UA1. 8. UA2 transmits an INVITE request to PS1. 9. Observe traffic on all networks.

Observable Results:

• Part A Step 3: UA1 must transmit an INVITE request to PS1. PS1 must forward the INVITE request to UA2. Step 5: PS1 must transmit an ACK request to UA2. PS1 must forward the 486 response to UA1. UA1 must transmit an ACK request to PS1.

• Part B Step 9: PS1 must forward the INVITE request to UA1. UA1 must forward the 486 Busy Here response to the INVITE request from UA2. PS1 must transmit an ACK request to UA1. PS1 must transmit a 486 response to UA2.


(SIPIO)

• Many SIP UAs will not return a 486 response, as they have multiple line and other features.


(SIPIO)

Test SIPIO.2.17: Compact Headers Through one Proxy Purpose: This test verifies that a SIP UA has the ability to establish and terminate a session when sending or receiving compact header field names when traversing a single proxy server. References:


Common Test Setup 2 Procedure: Part A: UA1 sends compact headers with record routing disabled on PS1.

1. Disable record routing on PS1. 2. Configure UA1 to use compact header field names. 3. UA1 calls UA2. 4. Observe traffic on all networks. 5. UA2 transmits a 180 Ringing response to the INVITE request from UA1. 6. Observe traffic on all networks. 7. UA2 answers the call. 8. UA2 transmits a 200 OK response to the INVITE request from UA1. 9. Observe traffic on all networks. 10. Put UA1 back on the hook. 11. UA2 transmits a 200 OK response to the BYE request from UA1. 12. Observe traffic on all networks.

Part B: UA2 sends compact headers with record routing disabled on PS1. 13. Disable record routing on PS1. 14. Configure UA2 to use compact header field names. 15. UA2 calls UA1. 16. UA2 transmits an INVITE request to PS1. 17. Observe traffic on all networks. 18. UA1 answers the call. 19. Observe traffic on all networks. 20. UA2 transmits an ACK request to UA1. 21. Observe traffic on all networks.


(SIPIO)

22. Put the UA2 back on the hook. 23. UA2 transmits a BYE request to UA1. 24. Observe traffic on all networks.

Part C: UA1 sends compact headers with record routing enabled on PS1. 25. Configure UA1 to use compact header field names. 26. UA1 calls UA2. 27. Observe traffic on all networks. 28. UA2 transmits a 180 Ringing response to the INVITE request from UA1. 29. Observe traffic on all networks. 30. UA2 answers the call. 31. UA2 transmits a 200 OK response to the INVITE request from UA1. 32. Observe traffic on all networks. 33. Put UA1 back on the hook. 34. UA2 transmits a 200 OK response to the BYE request from UA1. 35. Observe traffic on all networks.

Part D: UA2 sends compact headers with record routing enabled on PS1. 36. Configure UA2 to use compact header field names. 37. UA2 calls UA1. 38. UA2 transmits an INVITE request to PS1. 39. Observe traffic on all networks. 40. UA1 answers the call. 41. Observe traffic on all networks. 42. UA2 transmits an ACK request to PS1. 43. Observe traffic on all networks. 44. Put the UA2 back on the hook. 45. UA2 transmits a BYE request to PS1. 46. Observe traffic on all networks.

Observable Results:

• Part A Step 4: UA1 must transmit an INVITE request using some compact header field names to PS1 and PS1 must forward the INVITE request to UA2. Step 6: PS1 must forward the 180 Ringing response to UA1. Step 9: PS1 must forward the 200 OK response to UA1 and UA1 must transmit an ACK request to UA1. Multimedia traffic must be flowing in both directions. Step 12: UA1 must transmit a BYE request to UA2 and multimedia traffic must not be flowing in either direction.

• Part B Step 17: PS1 must forward the INVITE request to UA1. UA1 must transmit a 1xx response to the INVITE request from UA2. PS1 must forward the 1xx response to UA2. Step 19: UA1 must transmit a 2xx final response to the INVITE request from UA2. PS1 must forward the 2xx final response to UA2. Step 21: Multimedia traffic must be flowing in both directions. Step 24: UA1 must transmit a 200 OK response to the BYE request from UA2. Multimedia traffic must not be flowing in either direction.

• Part C


(SIPIO)

Step 27: UA1 must transmit an INVITE request using some compact header field names to PS1 and PS1 must forward the INVITE request to UA2. Step 29: PS1 must forward the 180 Ringing response to UA1. Step 32: PS1 must forward the 200 OK response to UA1 and UA1 must transmit an ACK request to PS1. PS1 must forward the ACK request to UA2. Multimedia traffic must be flowing in both directions. Step 35: UA1 must transmit a BYE request to PS1. PS1 must forward the BYE request to UA2. Step 37: Multimedia traffic must not be flowing in either direction.

• Part D Step 39: PS1 must forward the INVITE request to UA1. UA1 must transmit a 1xx response to the INVITE request from UA2. PS1 must forward the 1xx response to UA2. Step 41: UA1 must transmit a 2xx final response to the INVITE request from UA2. PS1 must forward the 2xx final response to UA2. Step 43: PS1 must forward the ACK request to UA1 and multimedia traffic must be flowing in both directions. Step 46: PS1 must forward the BYE request to UA1. UA1 must transmit a 200 OK response to the BYE request from UA2. PS1 must forward the 200 OK response to UA2 and multimedia traffic must not be flowing in either direction.

Possible Problems:

• UA1 and or UA2 may not have the capability to send compact header field names.


(SIPIO)

Test SIPIO.2.18: Forking Proxy Purpose: This test verifies that a SIP UA can successfully establish and terminate a multimedia session when a forking proxy is encountered in the signaling path. References:

• [SIP-SPEC] – Section 16.6 Node Requirements: See General Node Requirements. Discussion: As soon as the target set is non-empty, a proxy MAY begin forwarding the request. A stateful proxy MAY process the set in any order. It MAY process multiple targets serially, allowing each client transaction to complete before starting the next. It MAY start client transactions with every target in parallel. It also MAY arbitrarily divide the set into groups, processing the groups serially and processing the targets in each group in parallel. Test Setup:

Common Test Setup 2 Procedure: Part A: UA2’s AOR forks to contacts for both UA2 and UA3.

1. Enable request forking on PS1. 2. Configure UA3 to register to UA2’s AOR 3. UA1 calls UA2’s AOR. 4. Observe traffic on all networks. 5. UA2 transmits a 180 ringing response to the INVITE request from UA1. 6. UA3 transmits a 180 ringing response to the INVITE request from UA1. 7. Observe traffic on all networks. 8. UA2 answers the call. 9. UA2 transmits a 200 OK response to the INVITE request from UA1. 10. Observe traffic on all networks. 11. UA3 transmits a 200 OK response to the CANCEL request from PS1. 12. UA3 transmits a 487 Request Terminated response to the INVITE request from UA1. 13. Observe traffic on all networks. 14. UA1 terminates the call. 15. Observe traffic on all networks. 16. UA2 transmits a 200 OK response to the BYE request from UA1. 17. Observe traffic on all networks.

Observable Results:

• Part A Step 4: UA1 must transmit an INVITE request to PS1. PS1 must forward the INVITE request to UA2 and UA3. Step 7: PS1 must forward the 180 Ringing responses to UA1.


(SIPIO)

Step 10: PS1 must forward the 200 OK to UA1. PS1 must transmit a CANCEL request to UA3. Step 13: PS1 must transmit an ACK request to UA3. UA1 must transmit an ACK request to PS1. PS1 must forward the ACK request to UA2. Multimedia traffic must be flowing in both directions between UA1 and UA2. Step 15: UA1 must transmit a BYE request to PS1. PS1 must forward the BYE request to UA2. Step 17: PS1 must forward the 200 OK response to UA1. Multimedia traffic must not be flowing in either direction between UA1 and UA2.

Possible Problems:

• None


(SIPIO)

Group 3: SIP Trapezoid Scope: A typical example of a SIP message exchange between two users involves two SIP proxy servers to facilitate session establishment on the behalf of the users. This arrangement is often referred to as the "SIP trapezoid". Overview:


(SIPIO)

Test SIPIO.3.1: Establish and Terminate a Session through two Proxies Purpose: This test verifies that a SIP UA can successfully establish and terminate a multimedia session when employing a “SIP Trapezoid” network architecture. References:



Common Test Setup 3 Procedure: Part A: UA1 calls UA2 with record routing disabled on PS1 and PS2.

1. Disable record routing on PS1 and PS2. 2. UA1 calls UA2. 3. Observe traffic on all networks. 4. PS2 forwards the INVITE request to UA2. 5. UA2 transmits a 180 ringing response to the INVITE request from UA1. 6. PS2 forwards the 180 ringing response to PS1. 7. Observe traffic on all networks. 8. UA2 answers the call. 9. UA2 transmits a 200 OK response to the INVITE request from UA1. 10. PS2 forwards the 200 OK response to PS1. 11. Observe traffic on all networks. 12. UA1 terminates the call. 13. Observe traffic on all networks. 14. UA2 transmits a 200 OK response to the BYE request from UA1. 15. Observe traffic on all networks.

Part B: UA2 calls UA1 with record routing disabled on PS1 and PS2. 16. Disable record routing on PS1 and PS2. 17. UA2 calls UA1. 18. UA2 transmits an INVITE request to PS2. 19. PS2 forwards the INVITE request to PS1. 20. Observe traffic on all networks. 21. PS2 must forward the 180 Ringing response to UA2.


(SIPIO)

22. UA1 answers the call. 23. Observe traffic on all networks. 24. PS2 forwards the 200 OK response to UA2. 25. UA2 transmits an ACK request to UA1. 26. Observe traffic on all networks. 27. UA1 terminates the call. 28. Observe traffic on all networks. 29. UA2 transmits a 200 OK response to the BYE request from UA1. 30. Observe traffic on all networks.

Part C: UA1 calls UA2 with record routing enabled on PS1 and PS2. 31. UA1 calls UA2. 32. Observe traffic on all networks. 33. PS2 forwards the INVITE request to UA2. 34. UA2 transmits a 180 ringing response to the INVITE request from UA1. 35. PS2 forwards the 180 ringing response to PS1. 36. Observe traffic on all networks. 37. UA2 answers the call. 38. UA2 transmits a 200 OK response to the INVITE request from UA1. 39. PS2 forwards the 200 OK response to PS1. 40. Observe traffic on all networks. 41. PS2 forwards the ACK request to UA2. 42. Observe traffic on all networks. 43. UA1 terminates the call. 44. Observe traffic on all networks. 45. PS2 forwards the BYE request to UA2. 46. UA2 transmits a 200 OK response to the BYE request from UA1. 47. PS2 forwards the 200 OK response to PS1. 48. Observe traffic on all networks.

Part D: UA2 calls UA1 with record routing enabled on PS1 and PS2. 49. UA2 calls UA1. 50. UA2 transmits an INVITE request to PS2. 51. PS2 forwards the INVITE request to PS1. 52. Observe traffic on all networks. 53. PS2 must forward the 180 Ringing response to UA2. 54. UA1 answers the call. 55. Observe traffic on all networks. 56. PS2 forwards the 200 OK response to UA2. 57. UA2 transmits an ACK request to PS2. 58. PS2 forwards the ACK request to PS1. 59. Observe traffic on all networks. 60. UA1 terminates the call. 61. Observe traffic on all networks. 62. PS2 forwards the BYE request to UA2. 63. UA2 transmits a 200 OK response to the BYE request from UA1. 64. PS2 forwards the 200 OK response to PS1. 65. Observe traffic on all networks.

Observable Results:


(SIPIO)

• Part A Step 3: UA1 must transmit an INVITE request to PS1. PS1 must forward the INVITE request to PS2. Step 7: PS1 must forward the 180 Ringing response to UA1. Step 11: PS1 must forward the 200 OK to UA1. UA1 must transmit an ACK request to UA2. Multimedia traffic must be flowing in both directions between UA1 and UA2. Step 13: UA1 must transmit a BYE request to UA2. Step 15: Multimedia traffic must not be flowing in either direction between UA1 and UA2.

• Part B Step 20: PS1 must forward the INVITE request to UA1. UA1 must transmit a 180 Ringing response to the INVITE request from UA2. PS1 must forward the 180 Ringing response to PS2. Step 23: UA1 must transmit a 200 OK response to the INVITE request from UA2. PS1 must forward the 200 OK response to PS2. Step 26: Multimedia traffic must be flowing in both directions between UA1 and UA2. Step 28: UA1 must transmit a BYE request to UA2. Step 30: Multimedia traffic must not be flowing in either direction between UA1 and UA2.

• Part C Step 32: UA1 must transmit an INVITE request to PS1. PS1 must forward the INVITE request to PS2. Step 36: PS1 must forward the 180 Ringing response to UA1. Step 40: PS1 must forward the 200 OK to UA1. UA1 must transmit an ACK request to PS1. PS1 must forward the ACK request to PS2. Step 42: Multimedia traffic must be flowing in both directions between UA1 and UA2. Step 44: UA1 must transmit a BYE request to PS1. PS1 must forward the BYE request to PS2. Step 48: PS1 must forward the 200 OK response to UA1. Multimedia traffic must not be flowing in either direction between UA1 and UA2.

• Part D Step 52: PS1 must forward the INVITE request to UA1. UA1 must transmit a 180 Ringing response to the INVITE request from UA2. PS1 must forward the 180 Ringing response to PS2. Step 55: UA1 must transmit a 200 OK response to PS1. PS1 must forward the 200 OK response to PS2. Step 59: PS1 must forward the ACK request to UA1. Multimedia traffic must be flowing in both directions between UA1 and UA2. Step 61: UA1 must transmit a BYE request to PS1. PS1 must forward the BYE request to PS2. Step 65: PS1 must forward the 200 OK response to UA1. Multimedia traffic must not be flowing in either direction between UA1 and UA2.

Possible Problems:

• None


(SIPIO)

Test SIPIO.3.2: Session Establishment with Multiple Proxy Authentication Purpose: This test verifies that a SIP UA can successfully establish and terminate a multimedia session when multiple proxy servers along the request path require authentication. References:


Node Requirements: See General Node Requirements. Discussion: A common scenario involves two proxy servers, call them Proxy 1 and Proxy 2. A user in one domain wishes to make a call to a user in another domain. This user has valid credentials in both domains. Since the initial INVITE does not contain the Authorization credentials Proxy 1 requires, a 407 Proxy Authorization response is sent containing the challenge information. A new INVITE is then sent containing the correct credentials and the call proceeds after Proxy 2 challenges and receives valid credentials. Proxy 1 inserts a Record-Route header into the INVITE message to ensure that it is present in all subsequent message exchanges. Proxy 2 also inserts itself into the Record-Route header. Test Setup:

Common Test Setup 3 Procedure: Part A: UA1 calls UA2.

1. UA1 calls UA2. 2. Observe traffic on all networks. 3. PS2 transmits a 407 response to the INVITE request from UA1. 4. Observe traffic on all networks. 5. PS2 forwards the INVITE request to UA2. 6. UA2 transmits a 180 Ringing response to the INVITE request from UA1. 7. PS2 forwards the 180 Ringing response to PS1. 8. Observe traffic on all networks. 9. UA2 answers the call. 10. UA2 transmits a 200 OK response to the INVITE request from UA1. 11. PS2 forwards the 200 OK response to PS1. 12. Observe traffic on all networks. 13. PS2 forwards the ACK request to UA2. 14. Observe traffic on all networks. 15. UA1 terminates the call. 16. Observe traffic on all networks. 17. PS2 forwards the BYE request to UA2. 18. UA2 transmits a 200 OK response to the BYE request from UA1. 19. PS2 forwards the 200 OK response to PS1. 20. Observe traffic on all networks.


(SIPIO)

Observable Results:

• Part A Step 2: UA1 must transmit an INVITE request to PS1. PS1 must respond with a 407 Proxy Authorization Required response to the INVITE request from UA1. UA1 must transmit a new INVITE request with the correct credentials for PS1. PS1 must forward the INVITE request to PS2. Step 4: PS1 must forward the 407 response to UA1. UA1 must transmit a new request with credentials for both PS1 and PS2 to PS1. PS1 must forward the INVITE request to PS2. Step 8: PS1 must forward the 180 Ringing response to UA1. Step 12: PS1 must forward the 200 OK response to UA1. UA1 must transmit an ACK request to PS1. PS1 must forward the ACK request to PS2. Step 14: Multimedia traffic must be flowing in both directions between UA1 and UA2. Step 16: UA1 must transmit a BYE request to PS1. PS1 must forward the BYE request to PS2. Step 20: PS1 must forward the 200 OK response to UA1. Multimedia traffic must not be flowing in either direction between UA1 and UA2.

Possible Problems:

• None


(SIPIO)

Test SIPIO.3.3: Cancellation with Multiple Proxies Purpose: This test verifies that a SIP UA can successfully cancel the initiation of a multimedia session with another user agent utilizing the “SIP Trapezoid” network architecture. References:

• [SIP-SPEC] – Section 9 • [SIP-BCFE] – Section 3.8

Node Requirements: See General Node Requirements. Discussion: The CANCEL request, as the name implies, is used to cancel a previous request sent by a client. Specifically, it asks the UAS to cease processing the request and to generate an error response to that request. CANCEL is best for INVITE requests, which can take a long time to generate a response. In that usage, a UAS that receives a CANCEL request for an INVITE, but has not yet sent a final response, would "stop ringing", and then respond to the INVITE with a specific error response (a 487). Test Setup:



1. UA1 calls UA2. 2. Put UA1 back on the hook. 3. Observe traffic on all networks. 4. PS2 transmits a 200 OK response to PS1. 5. PS2 forwards the CANCEL request to UA2. 6. UA2 transmits a 200 OK to the CANCEL request from UA1. 7. UA2 transmits a 487 Request Terminated response to the INVITE request from UA1. 8. PS2 transmits an ACK request to UA2. 9. PS2 forwards the 487 response to PS1. 10. Observe traffic on all networks.

Part B: UA2 initiates call. 11. UA2 calls UA1. 12. Put the UA2 back on the hook. 13. UA2 transmits a CANCEL request to PS2. 14. PS2 transmits a 200 OK response to the CANCEL request from UA2. 15. PS2 forwards the CANCEL request to PS1. 16. Observe traffic on all networks.

Observable Results:

• Part A


(SIPIO)

Step 3: UA1 must transmit a CANCEL request to PS1. PS1 must transmit a 200 OK response to the CANCEL request from UA1. PS1 must forward the CANCEL request to PS2. Step 10: PS1 must transmit an ACK request to PS2. PS1 must forward the 487 response to UA1. UA1 must transmit an ACK request to PS1.

• Part B Step 16: PS1 must transmit a 200 OK response to the CANCEL request from UA2. PS1 must forward the CANCEL request to UA1. UA1 must transmit a 200 OK to the CANCEL request from UA2. UA1 must transmit a 487 Request Terminated response to the INVITE request from UA2. PS1 must transmit an ACK request to UA1. PS1 must forward the 487 response to PS2.

Possible Problems:

• None


(SIPIO)

Test SIPIO.3.4: Modifying an Existing Session through two Proxies Purpose: This test verifies that a SIP UA can successfully modify and accept modifications to a session that has already been established when employing the “SIP Trapezoid” network architecture. References:




1. UA1 calls UA2. 2. UA2 answers the call. 3. Observe traffic on all networks. 4. UA1 modifies the session with UA2. 5. Observe traffic on all networks. 6. PS2 forwards the re-INVITE to UA2. 7. UA2 transmits a final response to the re-INVITE request from UA1. 8. PS2 forwards the final response to PS1. 9. Observe traffic on all networks. 10. PS2 forwards the ACK request to UA2. 11. UA1 reverts the session to its initially negotiated session parameters. 12. Observe traffic on all networks. 13. PS2 forwards the re-INVITE request to UA2. 14. UA2 transmits a final response to the re-INVITE request from UA1. 15. PS2 forwards the final response to PS1. 16. Observe traffic on all networks. 17. PS2 forwards the ACK request to UA2. 18. UA1 terminates the call with UA2. 19. Observe traffic on all networks.

Part B: UA1 calls and UA2 modifies session. 20. UA1 calls UA2. 21. UA2 answers the call.


(SIPIO)

22. Observe traffic on all networks. 23. UA2 transmits a re-INVITE request to UA1 that modifies the session parameters. 24. PS2 forwards the re-INVITE request to PS1. 25. Observe traffic on all networks. 26. PS2 forwards the final response to UA2. 27. UA2 transmits an ACK request to PS2. 28. PS2 forwards the ACK request to PS1. 29. Observe traffic on all networks. 30. UA2 transmits a re-INVITE request to UA1 containing the session parameters that were

negotiated initially. 31. PS2 forwards the re-INVITE request to PS1. 32. Observe traffic on all networks. 33. PS2 forwards the final response to UA2. 34. UA2 transmits an ACK request to PS2. 35. PS2 forwards the ACK request to PS1. 36. Observe traffic on all networks. 37. UA1 terminates the call with UA2. 38. Observe traffic on all networks.

Part C: UA2 calls and UA1 modifies session. 39. UA2 calls UA1. 40. UA1 answers the call. 41. Observe traffic on all networks. 42. UA1 modifies the session with UA2. 43. Observe traffic on all networks. 44. PS2 forwards the re-INVITE request to UA2. 45. UA2 transmits a final response to the re-INVITE request from UA1. 46. PS2 forwards the final response to PS1. 47. Observe traffic on all networks. 48. PS2 forwards the ACK request to UA2. 49. UA1 reverts the session to its initially negotiated session parameters. 50. Observe traffic on all networks. 51. PS2 forwards the re-INVITE request to UA2. 52. UA2 transmits a final response to the re-INVITE request from UA1. 53. PS2 forwards the final response to PS1. 54. Observe traffic on all networks. 55. PS2 forwards the ACK request to UA2. 56. UA1 terminates the call with UA2. 57. Observe traffic on all networks.

Part D: UA2 calls and modifies session. 58. UA2 calls UA1. 59. UA1 answers the call. 60. Observe traffic on all networks. 61. UA2 transmits a re-INVITE request to UA1 that modifies the session parameters. 62. PS2 forwards the re-INVITE request to PS1. 63. Observe traffic on all networks. 64. PS2 forwards the final response to UA2. 65. UA2 transmits an ACK request to PS2. 66. PS2 forwards the ACK request to PS1. 67. Observe traffic on all networks.


(SIPIO)

68. UA2 transmits a re-INVITE request to UA1 containing the session parameters that were negotiated initially.

69. PS2 must forward the re-INVITE request to PS1. 70. Observe traffic on all networks. 71. PS2 forwards the final response to UA2. 72. UA2 transmits an ACK request to PS2. 73. PS2 forwards the ACK request to PS1. 74. Observe traffic on all networks. 75. UA2 terminates the call with UA1. 76. UA2 transmits a BYE request to PS2. 77. PS2 must forward the BYE request to PS1. 78. Observe traffic on all networks.

Part E: UA1 calls and modifies session with record routing disabled on both Proxies. 79. Disable record routing on PS1 and PS2. 80. UA1 calls UA2. 81. UA2 answers the call. 82. Observe traffic on all networks. 83. UA1 modifies the session with UA2. 84. Observe traffic on all networks. 85. UA2 transmits a final response to the re-INVITE request from UA1. 86. Observe traffic on all networks. 87. UA1 reverts the session to its initially negotiated session parameters. 88. Observe traffic on all networks. 89. UA2 transmits a final response to the re-INVITE request from UA1. 90. Observe traffic on all networks. 91. UA1 terminates the call with UA2. 92. Observe traffic on all networks.

Observable Results:

• Part A Step 3: Multimedia traffic must be flowing in both directions. Step 5: UA1 must transmit a re-INVITE request to PS1 that modifies the session parameters. PS1 must forward the re-INVITE request to PS2. Step 9: PS1 must forward the final response to UA1. UA1 must transmit an ACK request to PS1. PS1 must forward the ACK request to PS2. Step 12: UA1 must transmit a re-INVITE request containing the session parameters that were negotiated initially. PS1 must forward the re-INVITE request to PS2. Step 16: PS1 must forward the final response to UA1. UA1 must transmit an ACK request to PS1. PS1 must forward the ACK request to PS2. Step 19: UA1 must transmit a BYE request to PS1. PS1 must forward the BYE request to PS2.

• Part B Step 22: Multimedia traffic must be flowing in both directions. Step 25: PS1 must forward the re-INVITE request to UA1. UA1 must transmit a final response to the re-INIVTE request from UA2 to PS1. PS1 must forward the final response to PS2. Step 29: PS1 must forward the ACK request to UA1.


(SIPIO)

Step 32: PS1 must forward the re-INVITE request to UA1. UA1 must transmit a final response to the re-INIVTE request from UA2. PS1 must forward the final response to PS2. Step 36: PS1 forwards the ACK request to UA1. Step 38: UA1 must transmit a BYE request to PS1. PS1 must forward the BYE request to PS2.

• Part C Step 41: Multimedia traffic must be flowing in both directions. Step 43: UA1 must transmit a re-INVITE request to PS1 that modifies the session parameters. PS1 must forward the re-INVITE request to PS2. Step 47: PS1 must forward the final response to UA1. UA1 must transmit an ACK request to PS1. PS1 must forward the ACK request to PS2. Step 50: UA1 must transmit a re-INVITE request containing the session parameters that were negotiated initially. PS1 must forward the re-INVITE request to PS2. Step 54: PS1 must forward the final response to UA1. UA1 must transmit an ACK request to PS1. PS1 must forward the ACK request to PS2. Step 56: UA1 must transmit a BYE request to PS1. PS1 must forward the BYE request to PS2.

• Part D Step 60: Multimedia traffic must be flowing in both directions. Step 63: PS1 must forward the re-INVITE request to UA1. UA1 must transmit a final response to the re-INIVTE request from UA2. PS1 must forward the final response to PS2. Step 67: PS1 must forward the ACK request to UA1. Step 70: PS1 must forward the re-INVITE request to UA1. UA1 must transmit a final response to the re-INIVTE request from UA2. PS1 must forward the final response to PS2. Step 74: PS1 must forward the ACK request to UA1. Step 78: PS1 must forward the BYE request to UA1. UA1 must transmit a 200 OK response to the BYE request from UA2. PS1 must forward the 200 OK response to PS2.

• Part E Step 82: Multimedia traffic must be flowing in both directions. Step 84: UA1 must transmit a re-INVITE request to UA2. Step 86: UA1 must transmit an ACK request to UA2. Step 88: UA1 must transmit a re-INVITE request containing the session parameters that were negotiated initially. Step 90: UA1 must transmit an ACK request to UA2. Step 92: UA1 must transmit a BYE request to UA2.

Possible Problems:


session parameters.


(SIPIO)

Documents

SIP Interoperability Test Suite...interoperate with other SIP implementations on the key features of SIP outlined in IETF RFC 3261 as well as some widely implemented extensions. Failure