Network Working Group Minakshi Anand Internet-Draft Srimanta Purohit Aricent Expires: February 3, 2008 August 2007 Session Initiation Protocol (SIP) Compliance Test Specification for IP Multimedia Subsystem (IMS) Networks By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on February 3, 2008 Abstract This test specification validates Session Initiation Protocol (SIP) compliance for use as the session establishment protocol in IP Multimedia Subsystem (IMS). The document focuses on the SIP method, header and parameter parsing, as per the requirements in an IMS network. The requirements for test specification development have been derived from the 3GPP R5 Requirements on SIP [18] and P-Header Extensions to SIP for 3GPP [17]. Minakshi & Srimanta [Page 1] Internet Draft SIP-IMS Compliance Test Plan August 2007 Table of Contents ---------------------------------------------------------------------- 1. Introduction ....................................................4 1.1 General Assumptions ........................................4 2. Test Setup and Reference Call Flows .............................5 2.1 Test Environment ...........................................5 2.2 Call Flows .................................................6 3. Test Scenarios .................................................10 3.1 Privacy Mechanism .........................................11 3.1.1 Privacy Header Cases ...............................11 3.1.2 Generic Cases ......................................20 3.2 Asserted Identity Mechanisms within Trusted Networks ......21 3.2.1 P-Asserted-Identity Header Cases ...................22 3.2.2 P-Preferred-Identity Header Cases ..................28 3.3 Reliability of Provisional Responses in SIP ...............34 3.3.1 PRACK Support Cases ................................34 3.4 Private Header Extensions to SIP for 3GPP .................49 3.4.1 P-Called-Party-Id Header Cases .....................49 3.4.2 P-Visited-Network-ID Header Cases ..................55 3.4.3 P-Charging-Function-Addresses Header Cases .........63 3.4.4 P-Charging-Vector Header Cases .....................71 3.4.5 P-Access-Network-Info Header Cases .................81 3.4.6 P-Associated-URI Header Cases ......................92 3.5 SIP Event Package for Registration ........................99 3.5.1 SUBSCRIBE/NOTIFY Cases .............................99 3.5.2 NOTIFY Xml Parsing Cases ..........................105 3.6 UPDATE Support in SIP ....................................138 3.6.1 UPDATE Cases ......................................138 3.7 Resource Management Integration and SIP ..................143 3.7.1 Current-Status Sdp Cases ..........................143 3.7.2 Confirm-Status Sdp Cases ..........................153 3.7.3 Desired-Status Sdp Cases ..........................164 3.7.4 Generic Cases .....................................199 3.8 Caller Preferences for SIP ...............................211 3.8.1 Request-Disposition Header Cases ..................211 3.8.2 Feature-Param Cases ...............................225 3.8.3 Accept-Contact and Reject-Contact Header Cases ....244 3.9 SIP Extension For Registering Non-Adjacent Contacts ......258 3.9.1 Path Header .......................................258 3.10 SIP REFER Method .........................................265 3.10.1 Generic Cases .....................................265 3.11 INVITE with Replaces .....................................275 3.11.1 Replaces Header Cases .............................275 3.12 Service Route Discovery During Registration ..............283 3.12.1 Service-Route Header Cases ........................283 3.13 SIP Event Notification ...................................287 3.13.1 SUBSCRIBE/NOTIFY Parsing Cases ....................287 3.13.2 Event and Allow-Event Parsing Cases ...............304 3.13.3 Subscription-State Header Cases ...................311 Minakshi & Srimanta [Page 2] Internet Draft SIP-IMS Compliance Test Plan August 2007 3.14 SIP Extension for Instant Messaging ......................323 3.14.1 Message Requests ..................................323 3.15 Authentication and Authorization Header Changes ..........330 3.15.1 Authorization Header Cases ........................330 3.15.2 www-Authenticate Header ...........................332 4. Security Considerations .......................................333 5. References ....................................................333 5.1 Normative References .....................................333 5.2 Informative References ...................................334 6. Acknowledgments ...............................................335 7. Applicable Nodes ..............................................337 --------------------------------------------------------------------- Minakshi & Srimanta [Page 3] Internet Draft SIP-IMS Compliance Test Plan August 2007 1. Introduction 3GPP has identified SIP as the session establishment protocol for the IMS networks. This specification is a collection of test cases focussed on the validation of modifications and (or) additions to SIP method, header and parameter for IMS compliance, of an existing SIP Compliant [1] node. 1.1 General Assumptions The Test Cases Description is based on a number of assumptions and these should be taken into consideration for a better understanding of the document. The Test Cases validate the implementation under test (IUT) for SIP Extensions and changes, as identified by the RFC 3GPP R5 Requirements on SIP [18] for the usage of SIP protocol suite in IMS networks. The IUT is already tested for compliance to RFC 3261 [1] and the test cases in scope validate the compliance over and above RFC 3261 [1]. The focus of the document is on validation of the "syntax and applicability" of the header (or parameter) in different messages for IMS networks. To ensure system sanity, test steps mention normal call establishment and release for successful scenarios. This is based on the assumption that all other headers and message exchanges are valid and as per the referenced call flow. Complete call flows are not in scope of the document. Each test case has an "Applicable Methods" sub-heading. This sub-heading implies that in addition to the method used in test case description for validations; the header (or parameter) in focus, is also applicable in the listed methods under the sub-heading. So, for complete conformance testing, the header (or parameter) should be validated with these methods as well. To further extend the validations, additional allowed parameter values may be used. For certain invalid ( or error) scenarios the expected behavior depends on the implementation of the node under test. So, for these cases the test case result would need to be adapted as per the implementation. The document is focused on testing the node (IUT) compliance for IMS networks. The cases need to be filtered as per the role and the deployment of the IUT in the network. Section 7 illustrates the different Test Groups applicable for testing of S-CSCF, P-CSCF and AS. The test cases can be extended to include more invalid and deployment specific scenarios for different IMS nodes. Minakshi & Srimanta [Page 4] Internet Draft SIP-IMS Compliance Test Plan August 2007 2. Test Setup and Reference Call Flows The Call-flows depicted below provide the reference flows for the execution of test scenarios.3GPP Technical Specifications 23.228 [19], 24.228 [20] and 24.229 [14], respectively describe IMS, IMS session flows and the usage of SIP by the various IMS nodes. So, a reading of these specifications would help to derive the test cases for specific IMS node testing and detailed understanding. 2.1 Test Environment +-------+ +-------+ |///////| Mw | | |P-CSCF |------------------|I-CSCF | |///////| | | +-------+ +-------+ \ / \ Mw /Mw \ / \ / \+-------+/ |///////| |S-CSCF | |///////| / +-------+\ / \ / ISC \Mw / \ +-------+ \+-------+ |///////| | | | AS | |x-CSCF | |///////| | | +-------+ +-------+ Test Configuration (P-CSCF, S-CSCF, AS represent the IUT) Minakshi & Srimanta [Page 5] Internet Draft SIP-IMS Compliance Test Plan August 2007 +-------+ +-------+ +-------+ | | | | | | | PEER |---------------| IUT |---------------| PEER | | | UDP/TCP | | UDP/TCP | | +-------+ +-------+ +-------+ Simulated Test Setup The peer node refers to a simulated node in the IMS network. The SIP protocol suite is used over UDP/TCP for test case verifications. Depending on the test scenario, single or more peers may be required and the interface with each is over UDP/TCP. 2.2 Call Flows Note that in Call Flow 1 and 2, either Node1 or Node2 can be treated as IUT depending on the specific test scenario. Node1 Node2 | | | REGISTER F1 | |------------------------------>| | 401 Unauthorized F2 | |<------------------------------| | REGISTER F3 | |------------------------------>| | 200 OK F4 | |<------------------------------| | | Call Flow 1 Minakshi & Srimanta [Page 6] Internet Draft SIP-IMS Compliance Test Plan August 2007 Node1 Node2 | | | SUBSCRIBE F1 | |------------------------------>| | 200(OK) F2 | |<------------------------------| | NOTIFY F3 | |<------------------------------| | 200 OK F4 | |------------------------------>| | Call Flow 2 Peer IUT Peer | | | | | | | INVITE F1 | | |------------------------------>| | | 100 (Trying) F2 | | |<------------------------------| INVITE F3 | | |---------------------------->| | | 100 (Trying) F4 | | |<----------------------------| | | | | | 183(Session Progress) F5 | | 183(Session Progress) F6 |<----------------------------| |<------------------------------| | | | | | PRACK F7 | | |------------------------------>| PRACK F8 | | |---------------------------->| | | | | | 200(OK) F9 | | 200(OK) F10 |<----------------------------| |<------------------------------| | | | | | UPDATE F11 | | |------------------------------>| UPDATE F12 | | |---------------------------->| | | | | | 200(OK) F13 | | 200(OK) F14 |<----------------------------| |<------------------------------| | | | 180(Ringing) F15 | Minakshi & Srimanta [Page 7] Internet Draft SIP-IMS Compliance Test Plan August 2007 Peer IUT Peer | 180(Ringing) F16 |<----------------------------| |<------------------------------| | | | | | PRACK F17 | | |------------------------------>| | | | PRACK F18 | | |---------------------------->| | | | | | 200(OK) F19 | | 200(OK) F20 |<----------------------------| |<------------------------------| | | | 200(OK) F21 | | 200(OK) F22 |<----------------------------| |<------------------------------| | | | | | ACK F23 | | |------------------------------>| | | | ACK F24 | | |---------------------------->| | Both Way RTP Media | |<===========================================================>| | | | | BYE F25 | | |------------------------------>| | | | BYE F26 | | |---------------------------->| | | | | | 200(OK) F27 | | |<----------------------------| | 200(OK) F28 | | |<------------------------------| | Call Flow 3 Minakshi & Srimanta [Page 8] Internet Draft SIP-IMS Compliance Test Plan August 2007 Peer1 IUT Peer2 Peer3 | | | | | | | | | INVITE F1 | | | |--------------------->| | | | 100 (Trying) F2 | | | |<---------------------| INVITE F3 | | | |---------------------->| | | | 100 (Trying) F4 | | | |<----------------------| | | | | | | | 183 F5 | | | 183 F6 |<----------------------| | |<---------------------| | | | | | | | PRACK F7 | | | |--------------------->| PRACK F8 | | | |---------------------->| | | | | | | | 200(OK) F9 | | | 200(OK) F10 |<----------------------| | |<---------------------| | | | | | | | UPDATE F11 | | | |--------------------->| UPDATE F12 | | | |---------------------->| | | | | | | | 200(OK) F13 | | | 200(OK) F14 |<----------------------| | |<---------------------| | | | | 180 F15 | | | 180 F16 |<----------------------| | |<---------------------| | | | | | | | PRACK F17 | | | |--------------------->| | | | | PRACK F18 | | | |---------------------->| | | | | | | | 200(OK) F19 | | | 200(OK) F20 |<----------------------| | |<---------------------| | | | | 200(OK) F21 | | | 200(OK) F22 |<----------------------| | |<---------------------| | | | | | | | ACK F23 | | | |--------------------->| | | | | ACK F24 | | Minakshi & Srimanta [Page 9] Internet Draft SIP-IMS Compliance Test Plan August 2007 | |---------------------->| | | Both Way RTP Media | | |<============================================>| | | | | | | | REFER F25 | | | REFER F26 |<----------------------| | |<---------------------| | | | | | | | 202 F27 | | | |--------------------->| 202 F28 | | | |---------------------->| | | NOTIFY F29 | | | |--------------------->| NOTIFY F30 | | | |---------------------->| | | | | | | | 200(OK) F31 | | | 200(OK) F32 |<----------------------| | |<---------------------| | | | INVITE 33 | | | |--------------------->| | | | 100 (Trying)F34 | INVITE 35 | | |<---------------------|-------------------------------------->| | | 100 (Trying) F36 | | | |<--------------------------------------| | NOTIFY F37 | | | |--------------------->| NOTIFY F38 | | | |---------------------->| | | | | | | | 200(OK) F39 | | | 200(OK) F40 |<----------------------| | |<---------------------| | | | | BYE F41 | | | BYE F42 |<----------------------| | |<---------------------| | | | | | | | 200 OK F43 | | | |--------------------->| | | | | 200 OK F44 | | | |---------------------->| | Call Flow 4 3. Test Scenarios For clarity and better understanding, the test scenarios have been grouped on the basis of the headers and(or) parameters, identified for SIP compliance to IMS networks. To validate that the parsing was successful or not, the IUT must provide traces and logs giving relevant information. The peer node must have the capability to Minakshi & Srimanta [Page 10] Internet Draft SIP-IMS Compliance Test Plan August 2007 send messages with compact form of header field. Also, it must be possible to simulate inopportune scenarios from the peer and send SIP methods, headers, and parameters with invalid syntax. 3.1 Privacy Mechanism The SIP privacy mechanism provides guidelines for construction of messages, by use of specific headers and header values, in requests and responses to withhold the SIP identity of originator (or recipient). 3.1.1 Privacy Header Cases --------------------------------------------------------------------- 3.1.1.1 Priv_Hdr_V_01 : Privacy header with a single priv-value Test Objective : To verify that the IUT successfully parses the Privacy header with priv-value set as none Reference : RFC3323, Section 4.2 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PRACK, INFO, UPDATE, MESSAGE Pre-Requirement : IUT Supports Privacy Mechanism for SIP [4] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with priv-value set as none Privacy: none b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.1.1.2 Priv_Hdr_V_02 : Privacy header with value as session Test Objective : To validate Privacy header parsing when value is set to session Reference : RFC3323, Section 4.2 Applicable Messages : ACK, BYE, INVITE, CANCEL, OPTIONS, REGISTER, NOTIFY, PRACK, INFO, UPDATE, MESSAGE Minakshi & Srimanta [Page 11] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Privacy Mechanism for SIP [4] User is registered at IUT. Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with priv-value set as session Privacy: session b) Verify that the SUBSCRIBE is successfully parsed at the IUT and 200(OK) response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.1.1.3 Priv_Hdr_V_03 : Priv-value as user in Privacy header Test Objective : Validate parsing of the Privacy header value set as user Reference : RFC3323, Section 4.2 Applicable Messages : ACK, BYE, INVITE, CANCEL, SUBSCRIBE, REGISTER, NOTIFY, PRACK, INFO, UPDATE, MESSAGE Pre-Requirement : IUT Supports Privacy Mechanism for SIP [4] Test Description : a) Send an OPTIONS request from the peer towards the IUT with priv-value set as user Privacy: user b) Verify that the OPTIONS is successfully parsed at the IUT and successful response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.1.1.4 Priv_Hdr_V_04 : Privacy header with header as priv-value Test Objective : To verify the parsing of Privacy header with value set as header Reference : RFC3323, Section 4.2 Applicable Messages : ACK, BYE, INVITE, CANCEL, SUBSCRIBE, REGISTER, NOTIFY, PRACK, INFO, UPDATE, OPTIONS Pre-Requirement : IUT Supports Privacy Mechanism for SIP [4] Minakshi & Srimanta [Page 12] Internet Draft SIP-IMS Compliance Test Plan August 2007 User is registered at IUT. Test Description : a) Send a MESSAGE request from the peer towards the IUT with priv-value set as header Privacy: header b) Verify that the MESSAGE is successfully parsed at the IUT and successful response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.1.1.5 Priv_Hdr_V_05 : Privacy header with value as id Test Objective : Check that the Privacy header with value id is successfully parsed at the IUT Reference : RFC3323, Section 4.2 Applicable Messages : ACK, BYE, MESSAGE, CANCEL, SUBSCRIBE, REGISTER, NOTIFY, PRACK, INFO, UPDATE, OPTIONS Pre-Requirement : IUT Supports Privacy Mechanism for SIP [4] User is registered at IUT Test Description : a) Send a INVITE request from the peer towards the IUT with priv-value set as id Privacy: id b) Verify that the INVITE is successfully parsed at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.1.1.6 Priv_Hdr_V_06 : Two priv-values in Privacy header Test Objective : Validate the parsing of Privacy header consisting of two priv-values Reference : RFC3323, Section 4.2 Applicable Messages : ACK, BYE, MESSAGE, CANCEL, SUBSCRIBE, REGISTER, NOTIFY, PRACK, INFO, UPDATE, OPTIONS Minakshi & Srimanta [Page 13] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Privacy Mechanism for SIP [4] User is registered at IUT. Test Description : a) Send a INVITE request from the peer towards the IUT with priv-value set as : Privacy: session; header b) Verify that the INVITE is successfully parsed at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.1.1.7 Priv_Hdr_V_07 : Multiple priv-values in Privacy header Test Objective : To verify that the IUT successfully parses the Privacy header with multiple priv-values Reference : RFC3323, Section 4.2 Applicable Messages : ACK, BYE, SUBSCRIBE, CANCEL, OPTIONS, REGISTER, NOTIFY, PRACK, INFO, UPDATE, MESSAGE Pre-Requirement : IUT Supports Privacy Mechanism for SIP [4] User is registered at IUT. Test Description : a) Send a INVITE request from the peer towards the IUT with priv-value set as : Privacy: header;id;user b) Verify that the INVITE is successfully parsed at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.1.1.8 Priv_Hdr_V_08 : Privacy Header with critical as priv-value for session Test Objective : Verify that the Privacy header is successfully parsed on receipt of priv-value as critical for session Reference : RFC3323, Section 4.2 Minakshi & Srimanta [Page 14] Internet Draft SIP-IMS Compliance Test Plan August 2007 Applicable Messages : ACK, BYE, INVITE, CANCEL, OPTIONS, REGISTER, NOTIFY, PRACK, INFO, UPDATE, MESSAGE Pre-Requirement : IUT Supports Privacy Mechanism for SIP [4] Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with priv-value set as : Privacy: session;critical b) Verify that the SUBSCRIBE is successfully parsed at the IUT and 200(OK) response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.1.1.9 Priv_Hdr_V_09 : Critical as one of the priv-values in Privacy header Test Objective : Validate the parsing of privacy header containing critical with header, id and user priv-values Reference : RFC3323, Section 4.2 Applicable Messages : ACK, BYE, INVITE, CANCEL, OPTIONS, REGISTER, NOTIFY, PRACK, INFO, UPDATE, MESSAGE Pre-Requirement : IUT Supports Privacy Mechanism for SIP [4] User is registered at IUT. Test Description : a) Send a INFO request from the peer towards the IUT with priv-value set as : Privacy: header;id;user;critical b) Verify that the INFO is successfully parsed at the IUT and successful response returned to the peer --------------------------------------------------------------------- --------------------------------------------------------------------- 3.1.1.10 Priv_Hdr_V_10 : Proxy-Require header with option-tag as privacy Test Objective : Check the parsing of INVITE request consisting of a Privacy header and the Proxy-Require header containing the option-tag "privacy" Reference : RFC3323, Section 4.3 Minakshi & Srimanta [Page 15] Internet Draft SIP-IMS Compliance Test Plan August 2007 Applicable Messages : ACK, BYE, INVITE, CANCEL, OPTIONS, REGISTER, NOTIFY, PRACK, INFO, UPDATE, MESSAGE Pre-Requirement : IUT Supports Privacy Mechanism for SIP [4] User is registered at IUT. Test Description : a) Send a INVITE request from the peer towards the IUT with Privacy and Proxy-Require header set as : Privacy: id;critical Proxy-Require: privacy b) Verify that the INVITE is successfully parsed at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.1.1.11 Priv_Hdr_I_11 : Error response on receipt of Privacy header with only "critical" as the priv value Test Objective : Check that IUT returns an error response on receipt of Privacy header with only "critical" as the priv value Reference : RFC3323, Section 4.2 Applicable Messages : ACK, BYE, INVITE, CANCEL, OPTIONS, SUBSCRIBE, NOTIFY, PRACK, INFO, UPDATE, MESSAGE Pre-Requirement : IUT Supports Privacy Mechanism for SIP [4] Test Description : a) Send a REGISTER request from the peer towards the IUT with Privacy header set as : Privacy: critical b) Verify that the REGISTER parsing fails and IUT generates an error response. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.1.1.12 Priv_Hdr_I_12 : Error response on receipt of Privacy header with same priv-value more than once Minakshi & Srimanta [Page 16] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective : To verify that on receipt of a Privacy header with same priv-value repeated, an error response is returned Reference : RFC3323, Section 4.2 Applicable Messages : ACK, BYE, INVITE, REGISTER, OPTIONS, INFO, NOTIFY, PRACK, SUBSCRIBE, UPDATE, MESSAGE Pre-Requirement : IUT Supports Privacy Mechanism for SIP [4] A valid INVITE is received from the peer and provisional response for the same has been sent by IUT. That is, steps F1 to F6 of Call Flow 3 have been executed. Test Description : a) Send a CANCEL request from the peer towards the IUT with Privacy header set as : Privacy: user;header;user b) Verify that the CANCEL parsing fails and IUT generates an error response for CANCEL. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.1.1.13 Priv_Hdr_I_13 : Error response on receipt of Privacy header with any other priv-value together with none Test Objective : To verify that the IUT sends an error response towards the peer on receipt of Privacy header with more than one priv-values, one of them being none Reference : RFC3323, Section 4.2 Applicable Messages : ACK, CANCEL, INVITE, REGISTER, OPTIONS, INFO, NOTIFY, PRACK, SUBSCRIBE, UPDATE, MESSAGE Pre-Requirement : IUT Supports Privacy Mechanism for SIP [4] A SIP dialog is established between the IUT and the peer. That is, steps F1 to F24 of Call Flow 3 have been executed. Test Description : a) Send a BYE request from the peer towards the IUT with Privacy header set as : Privacy: none;header Minakshi & Srimanta [Page 17] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that the Privacy header parsing fails at the IUT and error is returned to peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.1.1.14 Priv_Hdr_I_14 : Unrecognized token in priv-value of Privacy Header Test Objective : Validate the IUT behavior when Privacy-header is received with unrecognized token(value not defined by the RFC) Reference : RFC3323, Section 4.2 Applicable Messages : ACK, CANCEL, INVITE, REGISTER, OPTIONS, INFO, NOTIFY, PRACK, SUBSCRIBE, UPDATE, MESSAGE Pre-Requirement : IUT Supports Privacy Mechanism for SIP. A SIP dialog is established between the IUT and the peer. That is, steps F1 to F24 of Call Flow 3 have been executed. Test Description : a) Send a BYE request from the peer towards the IUT with Privacy header set as : Privacy: dialog b) Verify that the Privacy header parsing fails at the IUT. c) Depending on the implementation, the IUT either discards the header or returns an error response. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.1.1.15 Priv_Hdr_I_15 : Multiple Privacy headers Test Objective : Validate the IUT behavior when INVITE request is received with more than one instance of the Privacy Header Reference : RFC3323, Section 4.2 Applicable Messages : ACK, BYE, SUBSCRIBE, CANCEL, OPTIONS, REGISTER, NOTIFY, PRACK, INFO, UPDATE, MESSAGE Pre-Requirement : IUT Supports Privacy Mechanism for SIP [4] User is registered at IUT. Test Description : a) Send a INVITE request from the peer towards the IUT with priv-value set as : Minakshi & Srimanta [Page 18] Internet Draft SIP-IMS Compliance Test Plan August 2007 Privacy: header Privacy: user b) Validate that the IUT, depending on the implementation, either discards the header or returns an error response. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.1.1.16 Priv_Hdr_I_16 : Empty Privacy Header Test Objective : To verify that the IUT discards the header or responds with an error on receipt of an empty Privacy Header Reference : RFC3323, Section 4.2 Applicable Messages : ACK, BYE, INVITE, CANCEL, OPTIONS, SUBSCRIBE, NOTIFY, PRACK, INFO, UPDATE, MESSAGE Pre-Requirement : IUT Supports Privacy Mechanism for SIP [4] Test Description : a) Send a REGISTER request from the peer towards the IUT with Privacy header set as : Privacy: b) Validate that the IUT, depending on the implementation, either discards the header or returns an error response. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.1.1.17 Priv_Hdr_I_17 : "critical" not specified as last value of the multiple valued Privacy header Test Objective : To validate the IUT behavior when it receives multi valued Privacy header with critical specified in the middle Reference : RFC3323, Section 4.2 Applicable Messages : ACK, BYE, INVITE, CANCEL, OPTIONS, SUBSCRIBE, NOTIFY, PRACK, INFO, UPDATE, MESSAGE Pre-Requirement : IUT Supports Privacy Mechanism for SIP [4] Test Description : a) Send a REGISTER request from the peer towards the IUT with Privacy header set as : Minakshi & Srimanta [Page 19] Internet Draft SIP-IMS Compliance Test Plan August 2007 Privacy: header;id;critical;user b) Validate that the IUT, depending on the implementation, either discards the header or returns an error response. --------------------------------------------------------------------- 3.1.2 Generic Cases --------------------------------------------------------------------- 3.1.2.1 Priv_Gen_V_01 : From Header with Display name as "Anonymous" Test Objective : To verify that the IUT successfully parses the >From header when the display name is set to "Anonymous" Reference : RFC3323, Section 4.1.1.1 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PRACK, INFO, UPDATE, MESSAGE Pre-Requirement : IUT Supports Privacy Mechanism for SIP [4] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with >From header as follows: From: "Anonymous" ;tag=1928301774 b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.1.2.2 Priv_Gen_V_02 : Contact Header set as a hostname only Test Objective : To validate the parsing of Contact header at the IUT when it contains only a hostname Reference : RFC3323, Section 4.1.1.2 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PRACK, INFO, UPDATE, MESSAGE Pre-Requirement : IUT Supports Privacy Mechanism for SIP [4] User is registered at IUT. Minakshi & Srimanta [Page 20] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send an INVITE request from the peer towards the IUT with Contact header as follows: Contact: sip:anonymous-sip.com b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.1.2.3 Priv_Gen_V_03 : Hostname value as "anonymous.invalid" in >From Header Test Objective : To validate that hostname value set as "anonymous.invalid" in From Header is successfully parsed at the IUT Reference : RFC3323, Section 4.1.1.3 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PRACK, INFO, UPDATE, MESSAGE Pre-Requirement : IUT Supports Privacy Mechanism for SIP [4] User is registered at IUT. Test Description : a) Send an INVITE request from the peer towards the IUT with Contact header as follows: From: "Anonymous" ;tag=1928301774 b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- 3.2 Asserted Identity Mechanisms within Trusted Networks The trusted SIP servers in a network, use the Asserted Identity Mechanisms to asservate the authenticated identities of end-user (or end system). These also aid in application of existing privacy mechanisms by conveying the user-requested privacy to the network. Minakshi & Srimanta [Page 21] Internet Draft SIP-IMS Compliance Test Plan August 2007 3.2.1 P-Asserted-Identity Header Cases --------------------------------------------------------------------- 3.2.1.1 Asstd_Hdr_V_01 : P-Asserted-Identity header with a single sip URI Test Objective : To verify the parsing of P-Asserted-Identity header containing a single sip URI. Reference : RFC3325, Section 9.1 Applicable Messages : BYE, OPTIONS, SUBSCRIBE, NOTIFY, REFER Pre-Requirement : IUT Supports Private Extensions to SIP for Asserted Identity [16] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Asserted-Identity Header as : P-Asserted-Identity: "Foo Example" b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.2.1.2 Asstd_Hdr_V_02 : P-Asserted-Identity header with a single tel URI Test Objective : Check that a tel uri in the P-Asserted-Identity header is successfully parsed at the IUT Reference : RFC3325, Section 9.1 Applicable Messages : BYE, OPTIONS, INVITE, NOTIFY, REFER Pre-Requirement : IUT Supports Private Extensions to SIP for Asserted Identity [16] User is registered. Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with P-Asserted-Identity Header as : P-Asserted-Identity: Minakshi & Srimanta [Page 22] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that the SUBSCRIBE is successfully parsed at the IUT and 200(OK) response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.2.1.3 Asstd_Hdr_V_03 : P-Asserted-Identity header with sip and tel URIs(one each) Test Objective : Validate that the IUT successfully parses the P-Asserted-Identity header consisting of a sip and a tel uri Reference : RFC3325, Section 9.1 Applicable Messages : BYE, SUBSCRIBE, INVITE, NOTIFY, REFER Pre-Requirement : IUT Supports Private Extensions to SIP for Asserted Identity [16] User is registered. Test Description : a) Send an OPTIONS request from the peer towards the IUT with P-Asserted-Identity Header as : P-Asserted-Identity: , b) Verify that the OPTIONS is successfully parsed at the IUT and successful response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.2.1.4 Asstd_Hdr_V_04 : P-Asserted-Identity header with sips and tel URIs(one each) Test Objective : To verify the parsing of P-Asserted-Identity header consisting of a sips and a tel uri Reference : RFC3325, Section 9.1 Applicable Messages : OPTIONS, SUBSCRIBE, INVITE, NOTIFY, REFER Pre-Requirement : IUT Supports Private Extensions to SIP for Asserted Identity [16] A SIP dialog is established between the IUT and the peer. That is, steps F1 to F24 of Call Flow 3 have been executed. Test Description : Minakshi & Srimanta [Page 23] Internet Draft SIP-IMS Compliance Test Plan August 2007 a) Send a BYE request from the peer towards the IUT with P-Asserted-Identity Header as : P-Asserted-Identity: , sips:foo@example.com b) Verify that the BYE is successfully parsed at the IUT and Call is released as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.2.1.5 Asstd_Hdr_V_05 : Multiple P-Asserted-Identity Headers Test Objective : To verify the successful parsing of multiple P-Asserted-Identity headers at the IUT Reference : RFC3325, Section 9.1 Applicable Messages : BYE, SUBSCRIBE, OPTIONS, NOTIFY, REFER Pre-Requirement : IUT Supports Private Extensions to SIP for Asserted Identity [16] User is registered. Test Description : a) Send a INVITE request from the peer towards the IUT with P-Asserted-Identity Headers as : P-Asserted-Identity: P-Asserted-Identity: b) Verify that the INVITE is successfully parsed at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.2.1.6 Asstd_Hdr_I_06 : Error response on receipt of more than two P-AssertedID-values Test Objective : Verify that an error response is returned on receipt of more than two P-AssertedID-values Reference : RFC3325, Section 9.1 Applicable Messages : BYE, SUBSCRIBE, OPTIONS, NOTIFY, REFER Pre-Requirement : IUT Supports Private Extensions to SIP for Asserted Identity [16] User is registered. Minakshi & Srimanta [Page 24] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a INVITE request from the peer towards the IUT with P-Asserted-Identity Headers as : P-Asserted-Identity: , , sip:alice@example.com b) Verify that the INVITE parsing fails and IUT generates an error response. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.2.1.7 Asstd_Hdr_I_07 : Error Response on receipt of two P-AssertedID-values with sip uri scheme Test Objective : To check that the IUT returns an error when P-Asserted-Identity header is received with two sip URIs Reference : RFC3325, Section 9.1 Applicable Messages : BYE, SUBSCRIBE, OPTIONS, NOTIFY, REFER Pre-Requirement : IUT Supports Private Extensions to SIP for Asserted Identity [16] User is registered. Test Description : a) Send a INVITE request from the peer towards the IUT with P-Asserted-Identity Headers as : P-Asserted-Identity: , b) Verify that the INVITE parsing fails and IUT generates an error response. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.2.1.8 Asstd_Hdr_I_08 : Error Response on receipt of two P-AssertedID-values with tel uri scheme Test Objective : To verify that an error is returned when P-Asserted-Identity header is received with two tel URIs Reference : RFC3325, Section 9.1 Applicable Messages : BYE, OPTIONS, INVITE, NOTIFY, REFER Pre-Requirement : Minakshi & Srimanta [Page 25] Internet Draft SIP-IMS Compliance Test Plan August 2007 IUT Supports Private Extensions to SIP for Asserted Identity [16] User is registered. Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with P-Asserted-Identity Header as : P-Asserted-Identity: , b) Verify that the SUBSCRIBE parsing fails and IUT returns an error response to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.2.1.9 Asstd_Hdr_I_09 : Error Response on receipt of two P-AssertedID-values with sips uri scheme Test Objective : IUT returns an error when P-Asserted-Identity header is received with two sips URIs Reference : RFC3325, Section 9.1 Applicable Messages : BYE, SUBSCRIBE, INVITE, NOTIFY, REFER Pre-Requirement : IUT Supports Private Extensions to SIP for Asserted Identity [16] User is registered. Test Description : a) Send an OPTIONS request from the peer towards the IUT with P-Asserted-Identity Header as : P-Asserted-Identity: sips:foo@example.com, sips:alice@example.com b) Check that the OPTIONS parsing fails and IUT returns an error response to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.2.1.10 Asstd_Hdr_I_10 : Error Response on receipt of a sip and sips URI(one each) in P-Asserted-Identity Header Test Objective : Check that the IUT responds with an error when it receives P-Asserted-Identity Header containing a sip and a sips URI Reference : RFC3325, Section 9.1 Applicable Messages : BYE, SUBSCRIBE, OPTIONS, NOTIFY, REFER Minakshi & Srimanta [Page 26] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Private Extensions to SIP for Asserted Identity [16] User is registered. Test Description : a) Send a INVITE request from the peer towards the IUT with P-Asserted-Identity Headers as : P-Asserted-Identity: , b) Verify that the INVITE parsing fails and IUT generates an error response. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.2.1.11 Asstd_Hdr_I_11 : Empty P-Asserted-Identity Header Test Objective : Validate the IUT behavior on receipt of an empty P-Asserted-Identity header Reference : RFC3325, Section 9.1 Applicable Messages : BYE, OPTIONS, INVITE, NOTIFY, REFER Pre-Requirement : IUT Supports Private Extensions to SIP for Asserted Identity [16] User is registered. Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with P-Asserted-Identity Header as : P-Asserted-Identity: b) Verify that the SUBSCRIBE parsing fails and depending on the implementation, IUT either discards or returns an error response. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.2.1.12 Asstd_Hdr_I_12 : Error Response on receipt of two P-Asserted-Identity Headers one with sip and other with sips uri Test Objective : Check that the IUT responds with an error when it receives two P-Asserted-Identity Headers one containing a sip and other containing a sips URI. Reference : RFC3325, Section 9.1 Applicable Messages : BYE, SUBSCRIBE, OPTIONS, NOTIFY, REFER Minakshi & Srimanta [Page 27] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Private Extensions to SIP for Asserted Identity [16] User is registered. Test Description : a) Send a INVITE request from the peer towards the IUT with P-Asserted-Identity Headers as : P-Asserted-Identity: P-Asserted-Identity: b) Verify that the INVITE parsing fails and IUT generates an error response. --------------------------------------------------------------------- 3.2.2 P-Preferred-Identity Header Cases --------------------------------------------------------------------- 3.2.2.1 Pref_Hdr_V_01 : P-Preferred-Identity header with a single sip URI Test Objective : To verify the parsing of P-Preferred-Identity header containing a single sip URI Reference : RFC3325, Section 9.2 Applicable Messages : BYE, OPTIONS, SUBSCRIBE, NOTIFY, REFER Pre-Requirement : IUT Supports Private Extensions to SIP for Asserted Identity [16] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Preferred-Identity Header as : P-Preferred-Identity: "Foo Example" b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.2.2.2 Pref_Hdr_V_02 : P-Preferred-Identity header with a single tel URI Minakshi & Srimanta [Page 28] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective : Check that a tel uri in the P-Preferred-Identity header is successfully parsed at the IUT Reference : RFC3325, Section 9.2 Applicable Messages : BYE, OPTIONS, INVITE, NOTIFY, REFER Pre-Requirement : IUT Supports Private Extensions to SIP for Asserted Identity [16] User is registered. Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with P-Preferred-Identity Header as : P-Preferred-Identity: b) Verify that the SUBSCRIBE is successfully parsed at the IUT and 200(OK) response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.2.2.3 Pref_Hdr_V_03 : P-Preferred-Identity header with sip and tel URIs(one each) Test Objective : Validate that the IUT successfully parses the P-Preferred-Identity header consisting of a sip and a tel uri Reference : RFC3325, Section 9.2 Applicable Messages : BYE, SUBSCRIBE, INVITE, NOTIFY, REFER Pre-Requirement : IUT Supports Private Extensions to SIP for Asserted Identity [16] User is registered. Test Description : a) Send an OPTIONS request from the peer towards the IUT with P-Preferred-Identity Header as : P-Preferred-Identity: , b) Verify that the OPTIONS is successfully parsed at the IUT and successful response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.2.2.4 Pref_Hdr_V_04 : P-Preferred-Identity header with sips and tel URIs(one each) Minakshi & Srimanta [Page 29] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective : To verify the parsing of P-Preferred-Identity header consisting of a sips and a tel uri Reference : RFC3325, Section 9.2 Applicable Messages : OPTIONS, SUBSCRIBE, INVITE, NOTIFY, REFER Pre-Requirement : IUT Supports Private Extensions to SIP for Asserted Identity [16] A SIP dialog is established between the IUT and the peer. That is, steps F1 to F24 of Call Flow 3 have been executed. Test Description : a) Send a BYE request from the peer towards the IUT with P-Preferred-Identity Header as : P-Preferred-Identity: , sips:foo@example.com b) Verify that the BYE is successfully parsed at the IUT and Call is released as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.2.2.5 Pref_Hdr_V_05 : Multiple P-Preferred-Identity Headers Test Objective : To verify the successful parsing of multiple P-Preferred-Identity headers at the IUT Reference : RFC3325, Section 9.2 Applicable Messages : BYE, SUBSCRIBE, OPTIONS, NOTIFY, REFER Pre-Requirement : IUT Supports Private Extensions to SIP for Asserted Identity [16] User is registered. Test Description : a) Send a INVITE request from the peer towards the IUT with P-Preferred-Identity Headers as : P-Preferred-Identity: P-Preferred-Identity: b) Verify that the INVITE is successfully parsed at the IUT and c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- Minakshi & Srimanta [Page 30] Internet Draft SIP-IMS Compliance Test Plan August 2007 3.2.2.6 Pref_Hdr_I_06 : Error response on receipt of more than two P-AssertedID-values Test Objective : Verify that an error response is returned on receipt of more than two P-AssertedID-values Reference : RFC3325, Section 9.2 Applicable Messages : BYE, SUBSCRIBE, OPTIONS, NOTIFY, REFER Pre-Requirement : IUT Supports Private Extensions to SIP for Asserted Identity [16] User is registered. Test Description : a) Send a INVITE request from the peer towards the IUT with P-Preferred-Identity Headers as : P-Preferred-Identity: , , sip:alice@example.com b) Verify that the INVITE parsing fails and IUT generates an error response. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.2.2.7 Pref_Hdr_I_07 : Error Response on receipt of two P-Preferred-Identity values with sip uri scheme Test Objective : To check that the IUT returns an error when P-Preferred-Identity header is received with two sip URIs Reference : RFC3325, Section 9.2 Applicable Messages : BYE, SUBSCRIBE, OPTIONS, NOTIFY, REFER Pre-Requirement : IUT Supports Private Extensions to SIP for Asserted Identity [16] User is registered. Test Description : a) Send a INVITE request from the peer towards the IUT with P-Preferred-Identity Headers as : P-Preferred-Identity: , Minakshi & Srimanta [Page 31] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that the INVITE parsing fails and IUT generates an error response. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.2.2.8 Pref_Hdr_I_08 : Error Response on receipt of two P-Preferred-Identity values with tel uri scheme Test Objective : To verify that an error is returned when P-Preferred-Identity header is received with two tel URIs Reference : RFC3325, Section 9.2 Applicable Messages : BYE, OPTIONS, INVITE, NOTIFY, REFER Pre-Requirement : IUT Supports Private Extensions to SIP for Asserted Identity [16] User is registered. Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with P-Preferred-Identity Header as : P-Preferred-Identity: , b) Verify that the SUBSCRIBE parsing fails and IUT returns an error response to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.2.2.9 Pref_Hdr_I_09 : Error Response on receipt of two P-Preferred-Identity with sips uri scheme Test Objective : IUT returns an error when P-Preferred-Identity header is received with two sips URIs Reference : RFC3325, Section 9.2 Applicable Messages : BYE, SUBSCRIBE, INVITE, NOTIFY, REFER Pre-Requirement : IUT Supports Private Extensions to SIP for Asserted Identity [16] User is registered. Test Description : a) Send an OPTIONS request from the peer towards the IUT with P-Preferred-Identity Header as : P-Preferred-Identity: sips:foo@example.com, sips:alice@example.com Minakshi & Srimanta [Page 32] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Check that the OPTIONS parsing fails and IUT returns an error response to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.2.2.10 Pref_Hdr_I_10 : Error Response on receipt of a sip and sips URI(one each) in P-Preferred-Identity Header Test Objective : Check that the IUT responds with an error when it receives P-Preferred-Identity Header containing a sip and a sips URI Reference : RFC3325, Section 9.2 Applicable Messages : BYE, SUBSCRIBE, OPTIONS, NOTIFY, REFER Pre-Requirement : IUT Supports Private Extensions to SIP for Asserted Identity [16] User is registered. Test Description : a) Send a INVITE request from the peer towards the IUT with P-Preferred-Identity Headers as : P-Preferred-Identity: , b) Verify that the INVITE parsing fails and IUT generates an error response. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.2.2.11 Pref_Hdr_I_11 : Empty P-Preferred-Identity Header Test Objective : Validate the IUT behavior on receipt of an empty P-Preferred-Identity header Reference : RFC3325, Section 9.2 Applicable Messages : BYE, OPTIONS, INVITE, NOTIFY, REFER Pre-Requirement : IUT Supports Private Extensions to SIP for Asserted Identity [16] User is registered. Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with P-Preferred-Identity Header as : Minakshi & Srimanta [Page 33] Internet Draft SIP-IMS Compliance Test Plan August 2007 P-Preferred-Identity: b) Verify that the SUBSCRIBE parsing fails and depending on the implementation, IUT either discards or returns an error response. --------------------------------------------------------------------- 3.3 Reliability of Provisional Responses in SIP In some network scenarios (like interoperability with PSTN), it is desired to have reliability of provisional responses as well. So, a new method, PRACK, headers - RSeq and RAck, and option tag 100rel have been introduced to cater to the same. 3.3.1 PRACK Support Cases --------------------------------------------------------------------- 3.3.1.1 PRACK_Supp_V_01 : Require header with option tag "100rel" Test Objective : To verify the Require header parsing with option tag "100rel" Reference : RFC3262, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Reliability of Provisional Responses in SIP [2] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Require Header as : Require: 100rel b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.3.1.2 PRACK_Supp_V_02 : Supported header with option tag "100rel" Test Objective : To verify the Supported header parsing with option tag "100rel" Reference : RFC3262, Section 3 Minakshi & Srimanta [Page 34] Internet Draft SIP-IMS Compliance Test Plan August 2007 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Reliability of Provisional Responses in SIP [2] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Supported Header as : Supported: 100rel b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.3.1.3 PRACK_Supp_V_03 : Receipt of 420(Bad Extension) response to INVITE and Unsupported Header containing tag "100rel" Test Objective : To verify that the IUT successfully parses 420 (Bad Extension) response with Unsupported Header containing tag "100rel Reference : RFC3262, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Reliability of Provisional Responses in SIP [2] User is registered. Step F1 to F3 of Call Flow 3 is executed Test Description : a) Send 420(Bad Extension) response to INVITE from the peer with Unsupported Header as : Unsupported: 100rel b) Verify that the response is successfully parsed at the IUT and it forwards the response to originating party. c) The Call state information is released at IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- Minakshi & Srimanta [Page 35] Internet Draft SIP-IMS Compliance Test Plan August 2007 3.3.1.4 PRACK_Supp_V_04 : 183 response with option tag "100rel" and valid RSeq Header Test Objective : Validate the parsing of 183 provisional response with a valid Rseq header and require header containing "100rel" Reference : RFC3262, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Reliability of Provisional Responses in SIP [2] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send an 183 provisional response from the peer towards the IUT with Require and RSeq Headers as : Require: 100rel RSeq: 9021 b) Verify that the 183 response is successfully parsed at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.3.1.5 PRACK_Supp_V_05 : 180 response with option tag "100rel" and valid RSeq Header Test Objective : To check that the 180 response containing 100rel in require header and a valid RSeq is successfully parsed at the IUT. Reference : RFC3262, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Reliability of Provisional Responses in SIP [2] User is registered. Steps F1 to F14 of Call Flow 3 have been executed. RSeq Header in 183 response was 9021. Test Description : a) Send an 180 provisional response from the peer towards the IUT with Require and RSeq Headers as : Minakshi & Srimanta [Page 36] Internet Draft SIP-IMS Compliance Test Plan August 2007 Require: 100rel RSeq: 9022 b) Verify that the 180 response is successfully parsed at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.3.1.6 PRACK_Supp_V_06 : 181 response with option tag "100rel" and valid RSeq Header Test Objective : Verify that 181 response with a Require header (100rel) and a valid Rseq is parsed successfully at the IUT. Reference : RFC3262, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Reliability of Provisional Responses in SIP [2] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 181 provisional response from the peer towards the IUT with Require and RSeq Headers as : Require: 100rel RSeq: 10 b) Verify that the 181 response is successfully parsed at the IUT. c) After successful PRACK and 200 (OK for PRACK) exchange, validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.3.1.7 PRACK_Supp_V_07 : PRACK in the Allowed header list in 183 provisional response Test Objective : Check the parsing of 183 response consisting of Allowed Header with PRACK as one of the methods. Reference : RFC3262, Section 3 Applicable Messages : Not Applicable Minakshi & Srimanta [Page 37] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Reliability of Provisional Responses in SIP [2] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send an 183 provisional response from the peer towards the IUT with Allow Header as : Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE b) Verify that the 183 response is successfully parsed at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.3.1.8 PRACK_Supp_V_08 : 180 response with PRACK in the Allowed Header list Test Objective : To check the Successful parsing of Allowed Header with PRACK in 180 response to an INVITE request. Reference : RFC3262, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Reliability of Provisional Responses in SIP [2] User is registered. Steps F1 to F14 of Call Flow 3 have been executed. Test Description : a) Send an 180 provisional response from the peer towards the IUT with Allow Header as : Allow: PRACK,INVITE, ACK, CANCEL, BYE b) Verify that the 180 response is successfully parsed at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.3.1.9 PRACK_Supp_V_09 : 181 response with PRACK in the Allowed Header list Minakshi & Srimanta [Page 38] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective : To check the Successful parsing of Allowed Header with PRACK in 181 response to an INVITE request. Reference : RFC3262, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Reliability of Provisional Responses in SIP [2] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 181 provisional response from the peer towards the IUT with Require and RSeq Headers as : Allow: PRACK,INVITE, ACK, CANCEL, BYE b) Verify that the 181 response is successfully parsed at the IUT. c) After successful PRACK and 200 (OK for PRACK) exchange, validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.3.1.10 PRACK_Supp_V_10 : RSeq Header Parsing with minimum allowed value Test Objective : Verify that RSeq Header with value 1 is successfully parsed at the IUT. Reference : RFC3262, Section 3 Applicable Messages : INVITE Pre-Requirement : IUT Supports Reliability of Provisional Responses in SIP [2] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send an 183 provisional response from the peer towards the IUT with RSeq Header as : RSeq: 1 b) Verify that the 183 response is successfully parsed at the IUT. Minakshi & Srimanta [Page 39] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.3.1.11 PRACK_Supp_V_11 : RSeq Header with a valid allowed value Test Objective : Verify that RSeq Header with a valid allowed value is successfully parsed at the IUT. Reference : RFC3262, Section 3 Applicable Messages : INVITE Pre-Requirement : IUT Supports Reliability of Provisional Responses in SIP [2] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send an 183 provisional response from the peer towards the IUT with RSeq Header as : RSeq: 729596 b) Verify that the 183 response is successfully parsed at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.3.1.12 PRACK_Supp_V_12 : RSeq Header with a max allowed value Test Objective : Verify that RSeq Header with maximum allowed value is successfully parsed at the IUT. Reference : RFC3262, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Reliability of Provisional Responses in SIP [2] User is registered. Steps F1 to F14 of Call Flow 3 have been executed. Test Description : Minakshi & Srimanta [Page 40] Internet Draft SIP-IMS Compliance Test Plan August 2007 a) Send an 180 provisional response from the peer towards the IUT with Allow Header as : RSeq: 4294967295 b) Verify that the 180 response is successfully parsed at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.3.1.13 PRACK_Supp_V_13 : PRACK with a body Test Objective : Verify the parsing of PRACK received with a body Reference : RFC3262, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Reliability of Provisional Responses in SIP [2] User is registered. Steps F1 to F6 of Call Flow 3 have been executed. Test Description : a) Send a PRACK with Content-Length header greater than zero and valid body, towards the IUT corresponding to the 183 provisional response. b) Verify that the PRACK is successfully parsed at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.3.1.14 PRACK_Supp_V_14 : Receipt of PRACK without a body Test Objective : To check that PRACK received without a body is successfully parsed at the IUT. Reference : RFC3262, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Reliability of Provisional Responses in SIP [2] User is registered. Steps F1 to F6 of Call Flow 3 have been executed. Test Description : Minakshi & Srimanta [Page 41] Internet Draft SIP-IMS Compliance Test Plan August 2007 a) Send a PRACK with Content-Length header as zero, towards the IUT corresponding to the 183 provisional response. b) Verify that the PRACK is successfully parsed at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.3.1.15 PRACK_Supp_V_15 : RAck Header with valid syntax Test Objective : To verify that the RAck header with expected value (two numbers and INVITE) is successfully parsed at the IUT. Reference : RFC3262, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Reliability of Provisional Responses in SIP [2] User is registered. Steps F1 to F6 of Call Flow 3 have been executed. The 183 response has RSeq and CSeq header values as "31" and "15 INVITE", respectively. Test Description : a) Send a PRACK corresponding to the 183 provisional response towards the IUT with RAck header as: RAck: 31 15 INVITE b) Verify that the PRACK is successfully parsed at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.3.1.16 PRACK_Supp_I_16 : 100 Trying with RSeq Header Test Objective : Validate the IUT behavior when a 100 Trying is received with RSeq header. Reference : RFC3262, Section 3 Applicable Messages : Not Applicable Minakshi & Srimanta [Page 42] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Reliability of Provisional Responses in SIP [2] User is registered. Steps F1 to F3 of Call flow 3 have been executed. Test Description : a) Send a 100 Trying with a valid RSeq header towards the IUT b) Verify that the RSeq header is discarded by IUT c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.3.1.17 PRACK_Supp_I_17 : Provisional response with a RSeq header and without "100rel" option tag in the require header Test Objective : Check the IUT behavior when a provisional response is received with a Rseq header but without the "100rel" tag in the Require header. Reference : RFC3262, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Reliability of Provisional Responses in SIP [2] User is registered. Steps F1 to F4 of Call flow 3 have been executed. INVITE with Supported header as "100rel" is received in step F1. Test Description : a) From the peer, send a 183 response with a valid RSeq header but without the "100rel" option-tag in Require header. b) Validate that the IUT returns an error response to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.3.1.18 PRACK_Supp_I_18 : Provisional response with require header as 100rel and missing Rseq header Test Objective : Check the IUT behavior when a provisional response is received with 100rel tag in the Require header but a missing RSeq header. Reference : RFC3262, Section 3 Minakshi & Srimanta [Page 43] Internet Draft SIP-IMS Compliance Test Plan August 2007 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Reliability of Provisional Responses in SIP [2] User is registered. Steps F1 to F4 of Call flow 3 have been executed. INVITE with Supported header as "100rel" is received in step F1. Test Description : a) From the peer, send a 183 response with Require header containing the option-tag "100rel" but missing RSeq header in the response. b) Validate that the IUT returns an error response to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.3.1.19 PRACK_Supp_I_19 : First provisional response with RSeq value greater than 2^31-1 Test Objective : To verify that the IUT returns an error when it receives the first provisional response with Rseq header value greater than 2^31-1 Reference : RFC3262, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Reliability of Provisional Responses in SIP [2] User is registered. Steps F1 to F4 of Call flow 3 have been executed. Test Description : a) From the peer, send a 183 response with RSeq header value as : RSeq: 2147483648 b) Validate that the IUT returns an error response to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.3.1.20 PRACK_Supp_I_20 : RSeq value greater than maximum allowed Test Objective : To verify that the IUT returns an error when it receives the a provisional response with Rseq header value greater than 2^32-1 Reference : RFC3262, Section 3 Minakshi & Srimanta [Page 44] Internet Draft SIP-IMS Compliance Test Plan August 2007 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Reliability of Provisional Responses in SIP [2] User is registered. Steps F1 to F14 of Call flow 3 have been executed. Test Description : a) From the peer, send a 180 response with RSeq header value as : RSeq: 4294967296 b) Validate that the IUT returns an error response to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.3.1.21 PRACK_Supp_I_21 : RSeq Header with non-numeric value Test Objective : To verify that the IUT returns an error when it receives non-numeric value for the RSeq header. Reference : RFC3262, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Reliability of Provisional Responses in SIP [2] User is registered. Steps F1 to F4 of Call flow 3 have been executed. INVITE with Supported header as "100rel" is received in step F1. Test Description : a) From the peer, send a 183 response with RSeq header value as : RSeq: 4INVITE2 b) Validate that the IUT returns an error response to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.3.1.22 PRACK_Supp_I_22 : RAck Header with a single number and a tag Test Objective : To verify that the IUT returns an error when it receives RAck header with a single number and a tag. Reference : RFC3262, Section 3 Applicable Messages : Not Applicable Minakshi & Srimanta [Page 45] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Reliability of Provisional Responses in SIP [2] User is registered. Steps F1 to F6 of Call Flow 3 have been executed. The 183 response has RSeq and CSeq header values as "31" and "15 INVITE", respectively. Test Description : a) Send a PRACK corresponding to the 183 provisional response towards the IUT with RAck header as: RAck: 31 INVITE b) Validate that the IUT returns an error response to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.3.1.23 PRACK_Supp_I_23 : RAck Header with invalid syntax Test Objective : Check the IUT behavior when RACK header is received with the two numbers and method in incorrect sequence. Reference : RFC3262, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Reliability of Provisional Responses in SIP [2] User is registered. Steps F1 to F6 of Call Flow 3 have been executed. The 183 response has RSeq and CSeq header values as "31" and "15 INVITE", respectively. Test Description : a) Send a PRACK corresponding to the 183 provisional response towards the IUT with RAck header as: RAck: 15 INVITE 31 b) Validate that the IUT returns an error response to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.3.1.24 PRACK_Supp_I_24 : OPTIONS with "100rel" in Require header Test Objective : To verify that the IUT responds with error when it receives an OPTIONS request with "100rel" in the Require header. Reference : RFC3262, Section 4 Minakshi & Srimanta [Page 46] Internet Draft SIP-IMS Compliance Test Plan August 2007 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Reliability of Provisional Responses in SIP [2] User is registered. Test Description : a) Send an OPTIONS request from the peer towards the IUT with Require Header as : Require: 100rel b) Validate that the IUT returns an 400 (Bad Request) to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.3.1.25 PRACK_Supp_I_25 : Require Header with option tag 100rel in UPDATE request Test Objective : To check that the IUT responds with error on receipt of Require header with tag "100rel" in UPDATE request. Reference : RFC3262, Section 4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Reliability of Provisional Responses in SIP [2] User is registered. Steps F1 to F10 of Call Flow 3 have been executed. Test Description : a) Send an UPDATE request from the peer towards the IUT with Require Header as : Require: 100rel b) Validate that the IUT returns a 400 (Bad Request) to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.3.1.26 PRACK_Supp_V_26 : RAck Header corresponding to Provisional response with maximum allowed value in RSeq header Test Objective : To verify that the RAck header corresponding to Provisional response, with maximum allowed value in RSeq header, is successfully parsed at the IUT. Reference : RFC3262, Section 3 Minakshi & Srimanta [Page 47] Internet Draft SIP-IMS Compliance Test Plan August 2007 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Reliability of Provisional Responses in SIP [2] User is registered. Steps F1 to F14 of Call Flow 3 have been executed. The 180 response has RSeq and CSeq header values as "4294967296" and "15 INVITE", respectively. Test Description : a) Send a PRACK corresponding to the 180 provisional response towards the IUT with RAck header as: RAck: 4294967296 15 INVITE b) Verify that the PRACK is successfully parsed at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.3.1.27 PRACK_Supp_V_27 : RAck Header corresponding to an INVITE request with maximum allowed value in CSeq header Test Objective : To verify that the RAck header corresponding to an INVITE request, with maximum allowed value in CSeq header, is successfully parsed at the IUT. Reference : RFC3262, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Reliability of Provisional Responses in SIP [2] User is registered. Steps F1 to F14 of Call Flow 3 have been executed. The 180 response has RSeq and CSeq header values as "2" and "2147483647 INVITE", respectively. Test Description : a) Send a PRACK corresponding to the 180 provisional response towards the IUT with RAck header as: RAck: 2 2147483647 INVITE b) Verify that the PRACK is successfully parsed at the IUT. Minakshi & Srimanta [Page 48] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.3.1.28 PRACK_Supp_I_28 : RAck Header with invalid value for the second number (for the one corresponding to CSeq Header) Test Objective : To validate the IUT behavior when it receives RAck Header with invalid value for the second number (for the one corresponding to CSeq Header). Reference : RFC3262, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Reliability of Provisional Responses in SIP [2] User is registered. Steps F1 to F14 of Call Flow 3 have been executed. The 180 response has RSeq and CSeq header values as "2" and "2147483647 INVITE", respectively. Test Description : a) Send a PRACK corresponding to the 180 provisional response towards the IUT with RAck header as: RAck: 2 2147483648 INVITE b) Verify that the PRACK parsing fails at the IUT. c) Depending on the implementation, either PRACK is discarded or and error response is returned to the peer. --------------------------------------------------------------------- 3.4 Private Header Extensions to SIP for 3GPP For SIP applicability in 3GPP networks, the protocol is extended to introduce a set of private headers. These headers help in meeting the additional functionality required by SIP, for use as the session establishment protocol in IMS. 3.4.1 P-Called-Party-Id Header Cases --------------------------------------------------------------------- 3.4.1.1 PCld_Pty_Hdr_V_01 : P-Called-Party-Id header containing only a name-addr(without a display name) Minakshi & Srimanta [Page 49] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective : To verify that the IUT successfully parses the P-Called-Party-Id header comprising of only a sip name-addr. Reference : RFC3455, Section 5.2 Applicable Messages : OPTIONS, SUBSCRIBE, MESSAGE, REFER Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Called-Party-Id Header as : P-Called-Party-ID: b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.1.2 PCld_Pty_Hdr_V_02 : P-Called-Party-Id header containing only a sips name-addr(without a display name) Test Objective : To validate P-Called-Party-Id header parsing when name-addr is set to sips uri and does not contain display name. Reference : RFC3455, Section 5.2 Applicable Messages : OPTIONS, INVITE, MESSAGE, REFER Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with P-Called-Party-Id Header as : P-Called-Party-Id: Minakshi & Srimanta [Page 50] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that the SUBSCRIBE is successfully parsed at the IUT and 200(OK) response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.1.3 PCld_Pty_Hdr_V_03 : P-Called-Party-Id header containing only a name-addr of type tel and no display name Test Objective : To verify the parsing of P-Called-Party-Id header with name-addr set as a tel uri. Reference : RFC3455, Section 5.2 Applicable Messages : SUBSCRIBE, INVITE, MESSAGE, REFER Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] Test Description : a) Send an OPTIONS request from the peer towards the IUT with P-Called-Party-Id Header as : P-Called-Party-Id: b) Verify that the OPTIONS is successfully parsed at the IUT and successful response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.1.4 PCld_Pty_Hdr_V_04 : P-Called-Party-Id header containing only a name-addr(with a display name) Test Objective : Check that the P-Called-Party-Id header with name-addr of type sip along with a display name is successfully parsed at the IUT. Reference : RFC3455, Section 5.2 Applicable Messages : OPTIONS, INVITE, SUBSCRIBE, REFER Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : Minakshi & Srimanta [Page 51] Internet Draft SIP-IMS Compliance Test Plan August 2007 a) Send a MESSAGE request from the peer towards the IUT with P-Called-Party-Id Header as : P-Called-Party-Id: foo b) Verify that the MESSAGE is successfully parsed at the IUT and 200(OK) response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.1.5 PCld_Pty_Hdr_V_05 : P-Called-Party-Id header comprising of a sips name-addr (with display) Test Objective : Validate the parsing of P-Called-Party-Id header containing display name for a name-addr of type sips. Reference : RFC3455, Section 5.2 Applicable Messages : OPTIONS, SUBSCRIBE, MESSAGE, REFER Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Called-Party-Id Header as : P-Called-Party-ID: "foo Exp" b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.1.6 PCld_Pty_Hdr_V_06 : P-Called-Party-Id with name-addr and a generic-param Test Objective : Verify the successful parsing of P-Called-Party-Id header containing a name-addr and a generic-param Reference : RFC3455, Section 5.2 Applicable Messages : OPTIONS, SUBSCRIBE, MESSAGE, REFER Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Minakshi & Srimanta [Page 52] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send an INVITE request from the peer towards the IUT with P-Called-Party-Id Header containing a name-addr and a generic-param. b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.1.7 PCld_Pty_Hdr_I_07 : P-Called-Party-Id with multiple name-addrs Test Objective : To check that an error response is returned by the IUT on receipt of P-Called-Party-Id with multiple name-addr Reference : RFC3455, Section 5.2 Applicable Messages : OPTIONS, SUBSCRIBE, MESSAGE, REFER Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Called-Party-Id Header containing multiple name-addrs. b) Validate that the INVITE parsing fails at IUT and 400 (Bad Request) response is returned to the peer --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.1.8 PCld_Pty_Hdr_I_08 : Multiple P-Called-Party-Id Headers Test Objective : To verify that the IUT responds with an error on receipt of multiple P-Called-Party-Id headers. Reference : RFC3455, Section 5.2 Applicable Messages : OPTIONS, SUBSCRIBE, MESSAGE, REFER Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : Minakshi & Srimanta [Page 53] Internet Draft SIP-IMS Compliance Test Plan August 2007 a) Send an INVITE request from the peer towards the IUT containing multiple P-Called-Party-Id Headers. b) Validate that the INVITE parsing fails at IUT and 400 (Bad Request) response is returned to the peer --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.1.9 PCld_Pty_Hdr_I_09 : Empty P-Called-Party-Id Header Test Objective : Validate the IUT behavior on receipt of an empty P-Called-Party-Id Header Reference : RFC3455, Section 5.2 Applicable Messages : OPTIONS, SUBSCRIBE, MESSAGE, REFER Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT containing empty P-Called-Party-Id Headers. b) Validate that the INVITE parsing fails at IUT and 400 (Bad Request) response is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.1.10 PCld_Pty_Hdr_I_10 : REGISTER Request with a P-Called-Party-Id Header Test Objective : To verify that the IUT returns an Error on receipt of P-Called-Party-Id Header in a REGISTER request. Reference : RFC3455, Section 5.7 Applicable Messages : PRACK, INFO, CANCEL, UPDATE, BYE, ACK, NOTIFY Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] Test Description : a) Send a REGISTER request from the peer towards the IUT containing a valid P-Called-Party-Id Header. b) Validate that the REGISTER parsing fails at IUT. Minakshi & Srimanta [Page 54] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Depending on the implementation, the IUT either discards the header or returns 400 (Bad Request) response to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.1.11 PCld_Pty_Hdr_V_11 : P-Called-Party-Id with name-addr and more than one generic-param Test Objective : Verify the successful parsing of P-Called-Party-Id header containing a name-addr and multiple generic-params Reference : RFC3455, Section 5.2 Applicable Messages : OPTIONS, SUBSCRIBE, MESSAGE, REFER Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Called-Party-Id Header containing a name-addr and multiple generic-params. b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- 3.4.2 P-Visited-Network-ID Header Cases --------------------------------------------------------------------- 3.4.2.1 PVstd_Nw_Hdr_V_01 : P-Visited-Network-Id Header with a single quoted String Test Objective : To verify that the IUT successfully parses the P-Visited-Network-Id header containing a single quoted String. Reference : RFC3455, Section 5.3 Applicable Messages : OPTIONS, SUBSCRIBE, MESSAGE, REFER, INVITE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] Test Description : Minakshi & Srimanta [Page 55] Internet Draft SIP-IMS Compliance Test Plan August 2007 a) Send a REGISTER request from the peer towards the IUT with P-Visited-Network-ID Header as : P-Visited-Network-ID: "Visited Network Number 1" b) Verify that the REGISTER is parsed successfully at the IUT. c) Validate the further execution per Call Flow 1. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.2.2 PVstd_Nw_Hdr_V_02 : P-Visited-Network-Id Header with a single token Test Objective : To validate P-Visited-Network-Id header parsing when it comprises of a token. Reference : RFC3455, Section 5.3 Applicable Messages : OPTIONS, INVITE, MESSAGE, REFER, REGISTER Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with P-Visited-Network-ID Header as : P-Visited-Network-ID: other.net b) Verify that the SUBSCRIBE is successfully parsed at the IUT and 200(OK) response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.2.3 PVstd_Nw_Hdr_V_03 : P-Visited-Network-Id Header with a vnetwork-spec containing a quoted String and a generic-param Test Objective : Verify the successful parsing of P-Visited-Network-Id header with a vnetwork-spec comprising a quoted Ringing and a generic param. Reference : RFC3455, Section 5.3 Applicable Messages : SUBSCRIBE, INVITE, MESSAGE, REFER, REGISTER Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] Minakshi & Srimanta [Page 56] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send an OPTIONS request from the peer towards the IUT with P-Visited-Network-ID Header as : P-Visited-Network-ID: "Network 1" ; other.net=1 b) Verify that the OPTIONS is successfully parsed at the IUT and successful response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.2.4 PVstd_Nw_Hdr_V_04 : P-Visited-Network-Id Header with a vnetwork-spec containing a token and a generic-param Test Objective : To verify that the IUT successfully parses the P-Visited-Network-Id header with a vnetwork-spec comprising a token and a generic-param. Reference : RFC3455, Section 5.3 Applicable Messages : OPTIONS, INVITE, SUBSCRIBE, REFER, REGISTER Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send a MESSAGE request from the peer towards the IUT with P-Visited-Network-ID Header as : P-Visited-Network-ID: Private ; network=A.1 b) Verify that the MESSAGE is successfully parsed at the IUT and 200(OK) response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.2.5 PVstd_Nw_Hdr_V_05 : P-Visited-Network-Id Header with multiple quoted strings Test Objective : To verify the parsing of P-Visited-Network-Id header with multiple quoted strings. Reference : RFC3455, Section 5.3 Applicable Messages : OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER Pre-Requirement : Minakshi & Srimanta [Page 57] Internet Draft SIP-IMS Compliance Test Plan August 2007 IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Visited-Network-ID Header as : P-Visited-Network-ID: "Network 1", "Network 90", "Private Network 4" b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.2.6 PVstd_Nw_Hdr_V_06 : P-Visited-Network-Id Header with multiple tokens Test Objective : To verify the parsing of P-Visited-Network-Id header with multiple tokens. Reference : RFC3455, Section 5.3 Applicable Messages : OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Visited-Network-ID Header as : P-Visited-Network-ID: example.com, foo's, invalid b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.2.7 PVstd_Nw_Hdr_V_07 : P-Visited-Network-Id header containing a token and a quoted String Test Objective : Validate the parsing of P-Visited-Network-Id header containing two vnetwork-spec elements of type token and quoted Ringing. Minakshi & Srimanta [Page 58] Internet Draft SIP-IMS Compliance Test Plan August 2007 Reference : RFC3455, Section 5.3 Applicable Messages : OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Visited-Network-ID Header as : P-Visited-Network-ID: example.com, "Private Network" b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.2.8 PVstd_Nw_Hdr_V_08 : P-Visited-Network-Id header containing a token plus generic-param and a quoted String Test Objective : To verify that the IUT successfully parses the P-Visited-Network-Id header containing a token plus a generic-param and a quoted String. Reference : RFC3455, Section 5.3 Applicable Messages : OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Visited-Network-ID Header as : P-Visited-Network-ID: example.com ; network=2, "Private Network" b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- Minakshi & Srimanta [Page 59] Internet Draft SIP-IMS Compliance Test Plan August 2007 3.4.2.9 PVstd_Nw_Hdr_V_09 : P-Visited-Network-Id header containing a token and a quoted String plus generic-param Test Objective : Check the P-Visited-Network-Id header parsing comprising of a token and a quoted String plus generic param. Reference : RFC3455, Section 5.3 Applicable Messages : OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Visited-Network-ID Header as : P-Visited-Network-ID: example.com, "Private Network" ; network=2 b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.2.10 PVstd_Nw_Hdr_V_10 : P-Visited-Network-Id Header with multiple vnetwork-specs Test Objective : Validate the P-Visited-Network-Id parsing comprising of multiple vnetwork-spec elements of type quoted String and tokens with some containing generic-param and some without the generic-param. Reference : RFC3455, Section 5.3 Applicable Messages : OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with four vnetwork-spec elements of type quoted String and tokens with some containing generic-param and some without the generic-param b) Verify that the INVITE is parsed successfully at the IUT. Minakshi & Srimanta [Page 60] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.2.11 PVstd_Nw_Hdr_V_11 : P-Visited-Network-Id Header with a vnetwork-spec element containing multiple generic-param Test Objective : To verify that a vnetwork-spec element containing multiple generic-params in the P-Visited-Network-Id header is parsed successfully. Reference : RFC3455, Section 5.3 Applicable Messages : OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Visited-Network-ID Header as : P-Visited-Network-ID: example.com;network=2;owner=foo;alive=yes b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.2.12 PVstd_Nw_Hdr_V_12 : Multiple P-Visited-Network-Id Header Test Objective : To verify the parsing at IUT when it receives multiple P-Visited-Network-Id headers. Reference : RFC3455, Section 5.3 Applicable Messages : OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : Minakshi & Srimanta [Page 61] Internet Draft SIP-IMS Compliance Test Plan August 2007 a) Send an INVITE request from the peer towards the IUT with P-Visited-Network-ID Header as : P-Visited-Network-ID: "Private Network" P-Visited-Network-ID: example.com b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.2.13 PVstd_Nw_Hdr_I_13 : Empty P-Visited-Network-Id Header Test Objective : Validate the IUT behavior on receipt of an empty P-Visited-Network-Id Header Reference : RFC3455, Section 5.3 Applicable Messages : OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Visited-Network-ID Header as : P-Visited-Network-ID: b) Validate that the INVITE parsing fails at IUT and 400 (Bad Request) response is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.2.14 PVstd_Nw_Hdr_I_14 : P-Visited-Network-Id with invalid Syntax Test Objective : To check that the IUT responds with an error when it receives vnetwork-spec element with more than one token/quoted Ringing in P-Visited-Network-Id Header Reference : RFC3455, Section 5.3 Applicable Messages : OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Minakshi & Srimanta [Page 62] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send an INVITE request from the peer towards the IUT with P-Visited-Network-ID Header as : P-Visited-Network-ID: other.net;example.com;"Private Network" b) Validate that the INVITE parsing fails at IUT and 400 (Bad Request) response is returned to the peer. --------------------------------------------------------------------- 3.4.3 P-Charging-Function-Addresses Header Cases --------------------------------------------------------------------- 3.4.3.1 PChg_Addr_V_01 : Single charge-addr-params of type ccf Test Objective : To verify that the IUT successfully parses the P-Charging-Function-Addresses header comprising of a single charge-addr-params of type ccf. Reference : RFC3455, Section 5.5 Applicable Messages : BYE, OPTIONS, SUBSCRIBE, MESSAGE, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] Test Description : a) Send a REGISTER request from the peer towards the IUT with P-Charging-Function-Addresses Header as : P-Charging-Function-Addresses: ccf=[2001:db8::c88:d77:e66] b) Verify that the REGISTER is parsed successfully at the IUT. c) Validate the further execution per Call Flow 1. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.3.2 PChg_Addr_V_02 : Single charge-addr-params of type ecf Test Objective : To verify that the IUT successfully parses the P-Charging-Function-Addresses header comprising of a single charge-addr-params of type ecf. Reference : RFC3455, Section 5.5 Applicable Messages : BYE, OPTIONS, REGISTER, MESSAGE, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Minakshi & Srimanta [Page 63] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with P-Charging-Function-Addresses Header as : P-Charging-Function-Addresses: ecf=[2001:db8::c88:d77:e66] b) Verify that the SUBSCRIBE is successfully parsed at the IUT and 200(OK) response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.3.3 PChg_Addr_V_03 : Single charge-addr-params of type generic-param Test Objective : Verify the successful parsing of P-Charging-Function-Addresses header with a charge-addr-params comprising of a generic-param. Reference : RFC3455, Section 5.5 Applicable Messages : BYE, SUBSCRIBE, REGISTER, MESSAGE, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17]. tcf is defined as charge-addr-params in IUT. Test Description : a) Send an OPTIONS request from the peer towards the IUT with P-Charging-Function-Addresses Header as : P-Charging-Function-Addresses: tcf=[2001:db8::c88:d77:e66] b) Verify that the OPTIONS is successfully parsed at the IUT and successful response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.3.4 PChg_Addr_V_04 : Two charge-addr-params of type ccf Test Objective : To verify that the IUT successfully parses the P-Charging-Function-Addresses header with two charge-addr-params of type ccf. Reference : RFC3455, Section 5.5 Minakshi & Srimanta [Page 64] Internet Draft SIP-IMS Compliance Test Plan August 2007 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send a MESSAGE request from the peer towards the IUT with P-Charging-Function-Addresses Header as : P-Charging-Function-Addresses: ccf=[2001:db8::c88:d77:e66]; ccf=[2001:db8::b44:c33:d22] b) Verify that the MESSAGE is successfully parsed at the IUT and 200(OK) response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.3.5 PChg_Addr_V_05 : Two charge-addr-params of type ecf Test Objective : To verify that the IUT successfully parses the P-Charging-Function-Addresses header with two charge-addr-params of type ecf. Reference : RFC3455, Section 5.5 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, MESAGE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Charging-Function-Addresses Header as : P-Charging-Function-Addresses: ecf=[2001:db8::c88:d77:e66]; ecf=[2001:db8::b44:c33:d22] b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- Minakshi & Srimanta [Page 65] Internet Draft SIP-IMS Compliance Test Plan August 2007 3.4.3.6 PChg_Addr_V_06 : Two charge-addr-params of type generic-param Test Objective : To verify that the IUT successfully parses the P-Charging-Function-Addresses header with two charge-addr-params of type generic-param. Reference : RFC3455, Section 5.5 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. tcf is defined as charge-addr-params in IUT. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Charging-Function-Addresses Header as : P-Charging-Function-Addresses: tcf=[2001:db8::c88:d77:e66]; tcf=[2001:db8::c77:d66:e55] b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.3.7 PChg_Addr_V_07 : Multiple charge-addr-params of same type Test Objective : To verify that the IUT successfully parses the P-Charging-Function-Addresses header with multiple charge-addr-params, all of same type. Reference : RFC3455, Section 5.5 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Charging-Function-Addresses Header as : Minakshi & Srimanta [Page 66] Internet Draft SIP-IMS Compliance Test Plan August 2007 P-Charging-Function-Addresses: ecf=[2001:db8::c88:d77:e66]; ecf=[2001:db8::b44:c33:d22]; ecf=[2001:db8::b66:c55:d22] b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.3.8 PChg_Addr_V_08 : Multiple charge-addr-params of different types Test Objective : To verify that the IUT successfully parses the P-Charging-Function-Addresses header with multiple charge-addr-params, all of same type. Reference : RFC3455, Section 5.5 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Steps F1 to F20 of Call Flow 3 have been executed. Test Description : a) Send a 200 (OK) from the peer towards the IUT with P-Charging-Function-Addresses Header as : P-Charging-Function-Addresses: ecf=[2001:db8::c88:d77:e66]; ccf=[2001:db8::b44:c33:d22]; ccf=[2001:db8::b66:c55:d22] b) Verify that the 200 (OK) is successfully parsed at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.3.09 PChg_Addr_V_09 : Charge-addr-params with gen value equal to a host Test Objective : To check that the charge-addr-param with gen-value as host is successfully parsed at the IUT. Reference : RFC3455, Section 5.5 Minakshi & Srimanta [Page 67] Internet Draft SIP-IMS Compliance Test Plan August 2007 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Charging-Function-Addresses Header as : P-Charging-Function-Addresses: ecf=pi.example.com b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.3.10 PChg_Addr_V_10 : Charge-addr-params with gen value equal to a token Test Objective : To check that the charge-addr-param with gen-value as token is successfully parsed at the IUT. Reference : RFC3455, Section 5.5 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. internal1 is defined in IUT. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Charging-Function-Addresses Header as : P-Charging-Function-Addresses: ecf=internal1 b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- Minakshi & Srimanta [Page 68] Internet Draft SIP-IMS Compliance Test Plan August 2007 3.4.3.11 PChg_Addr_V_11 : Charge-addr-params with gen value equal to a quoted String Test Objective : To check that the charge-addr-param with gen-value as quoted String is successfully parsed at the IUT. Reference : RFC3455, Section 5.5 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Charging-Function-Addresses Header as : P-Charging-Function-Addresses: ecf="internal charging function" b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.3.12 PChg_Addr_I_12 : P-Charging-Function-Addresses Header with missing value for ccf Test Objective : To verify that the IUT returns an error on receipt of P-Charging-Function-Addresses Header with missing value for ccf. Reference : RFC3455, Section 5.5 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Charging-Function-Addresses Header as : P-Charging-Function-Addresses: ccf; ecf=[2001:db8::c88:d77:e66] Minakshi & Srimanta [Page 69] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that the INVITE parsing fails and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.3.13 PChg_Addr_I_13 : P-Charging-Function-Addresses Header with comma as separator between charge-addr-params Test Objective : To verify that the IUT returns an error on receipt of P-Charging-Function-Addresses Header with comma as separator between charge-addr-params. Reference : RFC3455, Section 5.5 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Charging-Function-Addresses Header as : P-Charging-Function-Addresses: ccf=[2001:db8::b66:c44:d21], ecf=[2001:db8::c88:d77:e66] b) Verify that the INVITE parsing fails and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.3.14 PChg_Addr_I_14 : Empty P-Charging-Function-Addresses Header Test Objective : Validate the IUT behavior on receipt of empty P-Charging-Function-Addresses Header. Reference : RFC34455, Section 5.5 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : Minakshi & Srimanta [Page 70] Internet Draft SIP-IMS Compliance Test Plan August 2007 a) Send an INVITE request from the peer towards the IUT with P-Charging-Function-Addresses Header as : P-Charging-Function-Addresses: b) Verify that the IUT discards the header and proceeds with Call establishment as per Call Flow 3. --------------------------------------------------------------------- 3.4.4 P-Charging-Vector Header Cases --------------------------------------------------------------------- 3.4.4.1 PChg_Vect_V_01 : Icid of type quoted String Test Objective : Verify the successful parsing of P-Charging-Vector header with a icid-value comprising of a quoted String. Reference : RFC3455, Section 5.6 Applicable Messages : BYE, OPTIONS, SUBSCRIBE, MESSAGE, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] Test Description : a) Send a REGISTER request from the peer towards the IUT with P-Charging-Vector Header as : P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbH551024" b) Verify that the REGISTER is parsed successfully at the IUT. c) Validate the further execution per Call Flow 1. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.4.2 PChg_Vect_V_02 : Icid of type token Test Objective : To verify that the IUT successfully parses the P-Charging-Vector header containing a single icid-value of type token. Reference : RFC3455, Section 5.6 Applicable Messages : BYE, OPTIONS, REGISTER, MESSAGE, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] Minakshi & Srimanta [Page 71] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with P-Charging-Vector Header as : P-Charging-Vector: icid-value=AyretyU0 b) Verify that the SUBSCRIBE is successfully parsed at the IUT and 200(OK) response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.4.3 PChg_Vect_V_03 : Icid of type host Test Objective : To validate P-Charging-Vector header parsing when it comprises of single icid-value of type host. Reference : RFC3455, Section 5.6 Applicable Messages : BYE, SUBSCRIBE, REGISTER, MESSAGE, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17]. tcf is defined as charge-addr-params in IUT. Test Description : a) Send an OPTIONS request from the peer towards the IUT with P-Charging-Vector Header as : P-Charging-Vector: icid-value=p1.example.com b) Verify that the OPTIONS is successfully parsed at the IUT and successful response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.4.4 PChg_Vect_V_04 : P-Charging-Vector header with icid-value and a charge-param=orig-ioi Test Objective : To verify that the IUT successfully parses the P-Charging-Vector header with icid-value and a charge-param=orig-ioi. Reference : RFC3455, Section 5.6 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Minakshi & Srimanta [Page 72] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send a MESSAGE request from the peer towards the IUT with P-Charging-Vector Header as : P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5t"; orig-ioi=example.com b) Verify that the MESSAGE is successfully parsed at the IUT and 200(OK) response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.4.5 PChg_Vect_V_05 : P-Charging-Vector header containing a charge-param=term-ioi Test Objective : Validate the parsing of P-Charging-Vector header containing a charge-param=term-ioi along with the icid-value. Reference : RFC3455, Section 5.6 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, MESAGE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Charging-Vector Header as : P-Charging-Vector: icid-value=2001:db8::b66:c55:d22; term-ioi=example.com b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.4.6 PChg_Vect_V_06 : P-Charging-Vector header containing an icid-value and a charge-param=generated-at Minakshi & Srimanta [Page 73] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective : Check that the P-Charging-Vector header containing an icid-value and a charge-param=icid-generated-at is successfully parsed at the IUT. Reference : RFC3455, Section 5.6 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Charging-Vector Header as : P-Charging-Vector: icid-value=retyU0dm+6O2; icid-generated-at=p1.example.com b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.4.7 PChg_Vect_V_07 : P-Charging-Vector header containing charge-param of type generic-param Test Objective : Verify the parsing of the P-Charging-Vector header comprising of an icid-value and a charge-param=generic param at the IUT. Reference : RFC3455, Section 5.6 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. validity is defined as a charge-param in IUT. Test Description : Minakshi & Srimanta [Page 74] Internet Draft SIP-IMS Compliance Test Plan August 2007 a) Send an INVITE request from the peer towards the IUT with P-Charging-Vector Header as : P-Charging-Vector: icid-value=retyU0dm+6O2; validity=6000 b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.4.8 PChg_Vect_V_08 : P-Charging-Vector header with icid-value, orig-ioi, icid-generated-at, term-ioi parameters Test Objective : Validate the parsing of P-Charging-Vector header comprising of icid-value, orig-ioi, icid-generated-at, term-ioi parameter Reference : RFC3455, Section 5.6 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. validity is defined as a charge-param in IUT. Steps F1 to F20 of Call Flow 3 have been executed. Test Description : a) Send a 200 (OK) from the peer towards the IUT with P-Charging-Vector Header as : P-Charging-Vector: icid-value=retyU0dm+6O2; validity=6000; icid-generated-at=p1.example.com; orig-ioi=example.com; term-ioi=example1.com b) Verify that the 200 (OK) is successfully parsed at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.4.9 PChg_Vect_V_09 : Orig-ioi parameter with gen value equal to quoted String Minakshi & Srimanta [Page 75] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective : To verify that the IUT successfully parses the P-Charging-Vector header with orig-ioi set to a quoted String. Reference : RFC3455, Section 5.6 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Charging-Vector Header as : P-Charging-Vector: icid-value=2001:db8::b66:c55:d22; orig-ioi="internal network" b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.4.10 PChg_Vect_V_10 : Term-ioi parameter with gen value equal to token Test Objective : Check that the term-ioi parameter with value set as a token is successfully parsed in P-Charging-Vector header. Reference : RFC3455, Section 5.6 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Charging-Vector Header as : P-Charging-Vector: icid-value=2001:db8::b66:c55:d22; term-ioi=Network1 b) Verify that the INVITE is parsed successfully at the IUT. Minakshi & Srimanta [Page 76] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.4.11 PChg_Vect_I_11 : Multiple P-Charging-Vector Headers Test Objective : Validate the IUT behavior when it receives multiple P-Charging-Vector Headers. Reference : RFC3455, Sections 4.6 and 5.6 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Charging-Vector Header as : P-Charging-Vector: icid-value=2001:db8::b66:c55:d22; term-ioi=NW1 P-Charging-Vector: icid-value=2001:db8::b66:c44:d22; orig-ioi=NW2 b) Verify that the INVITE parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.4.12 PChg_Vect_V_12 : Empty P-Charging-Vector Header Test Objective : Validate the IUT behavior when it receives empty P-Charging-Vector Header. Reference : RFC3455, Section 5.6 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : Minakshi & Srimanta [Page 77] Internet Draft SIP-IMS Compliance Test Plan August 2007 a) Send an INVITE request from the peer towards the IUT with P-Charging-Vector Header as : P-Charging-Vector: b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.4.13 PChg_Vect_I_13 : Multiple icid values Test Objective : To verify that error is returned by the IUT on receipt of P-Charging-Vector header with multiple icid values. Reference : RFC3455, Section 5.6 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Charging-Vector Header as : P-Charging-Vector: icid-value=retyU0dm+6O2; icid-value="unique strg" ; orig-ioi=example.com; b) Verify that the INVITE parsing fails and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.4.14 PChg_Vect_V_14 : Multiple orig-ioi parameters Test Objective : Check the parsing of P-Charging-Vector header containing an icid-value and multiple instance of charge-params of type orig-ioi. Reference : RFC3455, Section 5.6 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : Minakshi & Srimanta [Page 78] Internet Draft SIP-IMS Compliance Test Plan August 2007 IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Charging-Vector Header as : P-Charging-Vector: icid-value=retyU0dm+6O2; orig-ioi=example2.com; orig-ioi=example.com; b) Verify that the INVITE parsing fails and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.4.15 PChg_Vect_I_15 : Multiple term-ioi parameters Test Objective : To validate P-Charging-Vector header parsing comprising of an icid-value and multiple instance of charge-params of type term-ioi. Reference : RFC3455, Section 5.6 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Charging-Vector Header as : P-Charging-Vector: icid-value=retyU0dm+6O2; term-ioi=example2.com; orig-ioi=example.com; term-ioi=example3.com b) Verify that the INVITE parsing fails and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.4.16 PChg_Vect_V_16 : Multiple generic parameters Test Objective :To verify that the IUT successfully parses the P-Charging-Vector header with multiple generic-params. Reference : RFC3455, Section 5.6 Minakshi & Srimanta [Page 79] Internet Draft SIP-IMS Compliance Test Plan August 2007 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. validity and scope are defined as charge-params in IUT Test Description : a) Send an INVITE request from the peer towards the IUT with P-Charging-Vector Header as : P-Charging-Vector: icid-value=retyU0dm+6O2; term-ioi=example2.com; orig-ioi=example.com; validity=60000; scope=local b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.4.17 PChg_Vect_I_17 : P-Charging-Vector header without icid-value Test Objective : To verify that IUT responds with an error when it receives P-Charging-Vector header without the icid-value. Reference : RFC3455, Section 5.6 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Charging-Vector Header as : P-Charging-Vector: term-ioi=example2.com; orig-ioi=example.com; icid-generated-at=p1.example.com b) Verify that the INVITE parsing fails and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.4.18 PChg_Vect_I_18 : Charge-Param with invalid syntax Minakshi & Srimanta [Page 80] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective : To verify that IUT responds with an error when it receives icid-generated-at param with invalid format. Reference : RFC3455, Section 5.6 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Charging-Vector Header as : P-Charging-Vector: icid-value=retyU0dm+6O2; term-ioi=example2.com; orig-ioi=example.com; icid-generated-at="Internal NW1" b) Verify that the INVITE parsing fails and error is returned to the peer. --------------------------------------------------------------------- 3.4.5 P-Access-Network-Info Header Cases --------------------------------------------------------------------- 3.4.5.1 PAccs_NW_Hdr_V_01 : P-Access-Network-Info containing only an access-type parameter Test Objective : To verify that the IUT successfully parses the P-Access-Network-Info header containing only the access-type parameter (set as IEEE802.11a). Reference : RFC3455, Section 5.4 Applicable Messages : BYE, OPTIONS, SUBSCRIBE, MESSAGE, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] Test Description : a) Send a REGISTER request from the peer towards the IUT with P-Access-Network-Info Header as : P-Access-Network-Info: IEEE802.11a b) Verify that the REGISTER is parsed successfully at the IUT. Minakshi & Srimanta [Page 81] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the further execution per Call Flow 1. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.5.2 PAccs_NW_Hdr_V_02 : P-Access-Network-Info header with access-type as 3GPP-GERAN Test Objective : Verify the successful parsing of P-Access-Network-Info header with access-type as 3GPP-GERAN. Reference : RFC3455, Section 5.4 Applicable Messages : BYE, OPTIONS, REGISTER, MESSAGE, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with P-Access-Network-Info Header as : P-Access-Network-Info: 3GPP-GERAN b) Verify that the SUBSCRIBE is successfully parsed at the IUT and 200(OK) response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.5.3 PAccs_NW_Hdr_V_03 : Access-Type as IEEE-802.11b Test Objective : To verify that the IUT successfully parses the P-Access-Network-Info header with access-type=IEEE-802.11b. Reference : RFC3455, Section 5.4 Applicable Messages : BYE, SUBSCRIBE, REGISTER, MESSAGE, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17]. tcf is defined as charge-addr-params in IUT. Test Description : a) Send an OPTIONS request from the peer towards the IUT with P-Access-Network-Info Header as : P-Access-Network-Info: IEEE-802.11b Minakshi & Srimanta [Page 82] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that the OPTIONS is successfully parsed at the IUT and successful response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.5.4 PAccs_NW_Hdr_V_04 : Access-Type as 3GPP-UTRAN-TDD Test Objective : To verify that the IUT successfully parses the P-Access-Network-Info header with access-type=3GPP-UTRAN-TDD. Reference : RFC3455, Section 5.4 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send a MESSAGE request from the peer towards the IUT with P-Access-Network-Info Header as : P-Access-Network-Info: 3GPP-UTRAN-TDD b) Verify that the MESSAGE is successfully parsed at the IUT and 200(OK) response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.5.5 PAccs_NW_Hdr_V_05 : Access-Type as 3GPP-UTRAN-FDD Test Objective : To verify that the IUT successfully parses the P-Access-Network-Info header with access-type=3GPP-UTRAN-FDD. Reference : RFC3455, Section 5.4 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, MESAGE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Access-Network-Info Header as : P-Access-Network-Info: 3GPP-UTRAN-FDD Minakshi & Srimanta [Page 83] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.5.6 PAccs_NW_Hdr_V_06 : Access-Type as 3GPP-CDMA2000 Test Objective : To verify that the IUT successfully parses the P-Access-Network-Info header with access-type=3GPP-CDMA2000. Reference : RFC3455, Section 5.4 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Access-Network-Info Header as : P-Access-Network-Info: 3GPP-CDMA2000 b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.5.7 PAccs_NW_Hdr_V_07 : Access-Type as Token Test Objective : To verify that the IUT successfully parses the P-Access-Network-Info header with access-type is set to a token. Reference : RFC3455, Section 5.4 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. EXP-CDMA5000 is defined as access-type token in IUT. Test Description : Minakshi & Srimanta [Page 84] Internet Draft SIP-IMS Compliance Test Plan August 2007 a) Send an INVITE request from the peer towards the IUT with P-Access-Network-Info Header as : P-Access-Network-Info: EXP-CDMA5000 b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.5.8 PAccs_NW_Hdr_V_08 : P-Access-Network-Info header with a single instance of access-info Test Objective : To verify that the IUT successfully parses the P-Access-Network-Info header with access-info as a token. Reference : RFC3455, Section 5.4 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Access-Network-Info Header as : P-Access-Network-Info: 3GPP-CDMA2000; NW-234151D0 b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.5.9 PAccs_NW_Hdr_V_09 : Access-Info as cgi-3gpp Test Objective : To validate access-info parsing in P-Access-Network-Info header when it is set to type cgi-3gpp. Reference : RFC3455, Section 5.4 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Minakshi & Srimanta [Page 85] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Access-Network-Info Header as : P-Access-Network-Info: 3GPP-GERAN; cgi-3gpp=234151D0FC b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.5.10 PAccs_NW_Hdr_V_10 : Access-Info as a quoted String Test Objective : To verify that the IUT successfully parses the P-Access-Network-Info header with access-info as a quoted String. Reference : RFC3455, Section 5.4 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Access-Network-Info Header as : P-Access-Network-Info: 3GPP-GERAN; "NW1 234151D0FC" b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.5.11 PAccs_NW_Hdr_V_11 : Access-Info as a Host Test Objective : Check that the P-Access-Network-Info header with access-info of type host is successfully parsed at the IUT. Minakshi & Srimanta [Page 86] Internet Draft SIP-IMS Compliance Test Plan August 2007 Reference : RFC3455, Section 5.4 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Access-Network-Info Header as : P-Access-Network-Info: 3GPP-GERAN; example.com b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.5.12 PAccs_NW_Hdr_V_12 : Access-Info of type utran-cell-id-3gpp Test Objective : Verify the successful parsing of P-Access-Network-Info header with access-info of type utran-cell-id-3gpp. Reference : RFC3455, Section 5.4 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Access-Network-Info Header as : P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=231D0FCE11 b) Verify that the INVITE is parsed successfully at the IUT. Minakshi & Srimanta [Page 87] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.5.13 PAccs_NW_Hdr_V_13 : Access-type parameter with multiple instances of access-info Test Objective : Validate the successful parsing of P-Access-Network-Info header with multiple instances of access-info param for a given access-type. Reference : RFC3455, Section 5.4 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Access-Network-Info Header as : P-Access-Network-Info: 3GPP-GERAN; cgi-3gpp=234151D0FC; "Nw1 65348W1"; example.com b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.5.14 PAccs_NW_Hdr_I_14 : Access-type set to 3GPP-GERAN and access-info as utran-cell-id-3gpp Test Objective : Validate the IUT behavior when P-Access-Network-Info header with the access-type set to 3GPP-GERAN and access-info as utran-cell-id-3gpp is received. Reference :3GPP TS 24.229, Section B.3.4.1 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Minakshi & Srimanta [Page 88] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send an INVITE request from the peer towards the IUT with P-Access-Network-Info Header as : P-Access-Network-Info: 3GPP-GERAN; utran-cell-id-3gpp=234151D0FC b) Verify that the INVITE parsing fails and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.5.15 PAccs_NW_Hdr_V_15 : Access-type set to 3GPP-UTRAN-FDD and access-info as utran-cell-id-3gpp Test Objective : To verify successful parsing of access-type set to 3GPP-UTRAN-FDD and access-info as utran-cell-id-3gpp. Reference : 3GPP TS 24.229, Section B.3.4.1 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Access-Network-Info Header as : P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FC b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.5.16 PAccs_NW_Hdr_V_16 : Access-type set to 3GPP-UTRAN-TDD and access-info as utran-cell-id-3gpp Test Objective : To verify successful parsing of access-type set to 3GPP-UTRAN-FDD and access-info as utran-cell-id-3gpp. Reference :3GPP TS 24.229, Section B.3.4.1 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Minakshi & Srimanta [Page 89] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Access-Network-Info Header as : P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FC b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.5.17 PAccs_NW_Hdr_V_17 : Access-type set to 3GPP-CDMA2000 and access-info as utran-cell-id-3gpp Test Objective : To verify successful parsing of access-type set to 3GPP-UTRAN-FDD and access-info as utran-cell-id-3gpp. Reference :3GPP TS 24.229, Section B.3.4.1 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Access-Network-Info Header as : P-Access-Network-Info: 3GPP-CDMA2000; utran-cell-id-3gpp=234151D0FC b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.5.18 PAccs_NW_Hdr_I_18 : Empty P-Access-Network-Info header Test Objective : Validate the IUT behavior when an empty P-Access-Network-Info header is received. Minakshi & Srimanta [Page 90] Internet Draft SIP-IMS Compliance Test Plan August 2007 Reference : RFC3455, Section 5.4 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Access-Network-Info Header as : P-Access-Network-Info: b) Verify that the INVITE parsing fails and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.5.19 PAccs_NW_Hdr_I_19 : Multiple P-Access-Network-Info headers Test Objective : Check that an error response is returned on receipt of multiple P-Access-Network-Info headers. Reference : RFC3455, Section 5.4 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Access-Network-Info Header as : P-Access-Network-Info: 3GPP-CDMA2000; utran-cell-id-3gpp=234151D0FC P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FC b) Verify that the INVITE parsing fails and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.5.20 PAccs_NW_Hdr_I_20 : P-Access-Network-Info header with invalid syntax Minakshi & Srimanta [Page 91] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective : To verify that the IUT responds with an error on receipt of P-Access-Network-Info header with more than one access-type. Reference : RFC3455, Section 5.4 Applicable Messages : BYE, SUBSCRIBE, REGISTER, OPTIONS, REFER, INVITE, NOTIFY, PRACK, INFO, UPDATE Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with P-Access-Network-Info Header as : P-Access-Network-Info: 3GPP-CDMA2000; 3GPP-CDMA2000; utran-cell-id-3gpp=234151D0FC b) Verify that the INVITE parsing fails and error is returned to the peer. --------------------------------------------------------------------- 3.4.6 P-Associated-URI Header Cases --------------------------------------------------------------------- 3.4.6.1 PAsso_URI_Hdr_V_01 : P-Associated-URI with a single address name Test Objective : To verify that the IUT successfully parses the P-Associated-URI header containing a single address name. Reference : RFC3455, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17]. Steps F1 to F3 of Call Flow 1 have been executed. REGISTER was initiated by the IUT. Test Description : a) Send a 200 (OK) response from the peer towards the IUT containing P-Associated-URI Header as : P-Associated-URI: Minakshi & Srimanta [Page 92] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Validate that the response is successfully parsed at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.6.2 PAsso_URI_Hdr_V_02 : P-Associated-URI with multiple sip/sips URIs Test Objective : To validate P-Associated-URI header parsing consisting of multiple sip/sips uri. Reference : RFC3455, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17]. Steps F1 to F3 of Call Flow 1 have been executed. REGISTER was initiated by the IUT. Test Description : a) Send a 200 (OK) response from the peer towards the IUT containing P-Associated-URI Header as : P-Associated-URI: , , b) Validate that the response is parsed successfully at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.6.3 PAsso_URI_Hdr_V_03 : P-Associated-URI with sip and tel URIs Test Objective : To verify the parsing of P-Associated-URI header comprising of sip and tel ur1. Reference : RFC3455, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17]. Steps F1 to F3 of Call Flow 1 have been executed. REGISTER was initiated by the IUT. Test Description : Minakshi & Srimanta [Page 93] Internet Draft SIP-IMS Compliance Test Plan August 2007 a) Send a 200 (OK) response from the peer towards the IUT containing P-Associated-URI Header as : P-Associated-URI: , , b) Validate that the response is parsed successfully at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.6.4 PAsso_URI_Hdr_V_04 : P-Associated-URI with URI containing display name Test Objective : Validate parsing of P-Associated-URI with a uri containing display-name as well. Reference : RFC3455, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17]. Steps F1 to F3 of Call Flow 1 have been executed. REGISTER was initiated by the IUT. Test Description : a) Send a 200 (OK) response from the peer towards the IUT containing P-Associated-URI Header as : P-Associated-URI: Alice b) Validate that the response is parsed successfully at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.6.5 PAsso_URI_Hdr_V_05 : P-Associated-URI with multiple URIs some containing display name and some not Test Objective : Check that P-Associated-URI header with multiple URIs, some with and some without the display name. Reference : RFC3455, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17]. Steps F1 to F3 of Call Flow 1 have been executed. REGISTER was initiated by the IUT. Minakshi & Srimanta [Page 94] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a 200 (OK) response from the peer towards the IUT containing P-Associated-URI Header as : P-Associated-URI: Alice , , "Bob Drew" , Joe b) Validate that the response is parsed successfully at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.6.6 PAsso_URI_Hdr_V_06 : P-Associated-URI with URI containing generic-param Test Objective : To verify that the IUT successfully parses the P-Associated-URI header containing generic-param. Reference : RFC3455, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17]. Steps F1 to F3 of Call Flow 1 have been executed. REGISTER was initiated by the IUT. Test Description : a) Send a 200 (OK) response from the peer towards the IUT containing P-Associated-URI Header as : P-Associated-URI: Alice ;expires=3600 b) Validate that the response is parsed successfully at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.6.7 PAsso_URI_Hdr_V_07 : P-Associated-URI with URI containing more than one generic-params Test Objective : Verify that the P-Associated-URI header containing multiple generic-params is successfully parsed. Reference : RFC3455, Section 5.1 Applicable Messages : Not Applicable Minakshi & Srimanta [Page 95] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17]. Steps F1 to F3 of Call Flow 1 have been executed. REGISTER was initiated by the IUT. Test Description : a) Send a 200 (OK) response from the peer towards the IUT containing P-Associated-URI Header as : P-Associated-URI: ;security=off;expires=68000 b) Validate that the response is parsed successfully at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.6.8 PAsso_URI_Hdr_V_08 : Empty P-Associated Header Test Objective : To verify successful parsing of empty P-Associated-URI header. Reference : RFC3455, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17]. Steps F1 to F3 of Call Flow 1 have been executed. REGISTER was initiated by the IUT. Test Description : a) Send a 200 (OK) response from the peer towards the IUT containing P-Associated-URI Header as : P-Associated-URI: b) Validate that the response is parsed successfully at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.6.9 PAsso_URI_Hdr_I_09 : P-Associated URI with invalid syntax Test Objective : Check the behavior when the address name in P-Associated-URI is received without the <>. Reference : RFC3455, Section 5.2 Applicable Messages : Not Applicable Minakshi & Srimanta [Page 96] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17]. Steps F1 to F3 of Call Flow 1 have been executed. REGISTER was initiated by the IUT. Test Description : a) Send a 200 (OK) response from the peer towards the IUT containing P-Associated-URI Header as : P-Associated-URI: Alice sip:+1-212-555-1111@home1.net;user=phone b) Validate that the response parsing fails at the IUT and it is discarded. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.6.10 PAsso_URI_Hdr_V_10 : Multiple P-Associated-URI Headers Test Objective : Validate the IUT behavior on receipt of multiple P-Associated-URI Headers. Reference : RFC3455, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17]. Steps F1 to F3 of Call Flow 1 have been executed. REGISTER was initiated by the IUT. Test Description : a) Send a 200 (OK) response from the peer towards the IUT containing P-Associated-URI Header as : P-Associated-URI: P-Associated-URI: b) Validate that the response is parsed successfully at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.6.11 PAsso_URI_Hdr_I_11 : P-Associated-URI Header in 200 (OK) response to INVITE Test Objective : Validate the IUT behavior on receipt of P-Associated-URI Header in 200 (OK) response to INVITE. Reference : RFC3455, Section 4.1 Minakshi & Srimanta [Page 97] Internet Draft SIP-IMS Compliance Test Plan August 2007 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17]. Steps F1 to F18 of Call Flow 3 have been executed. Test Description : a) Send a 200 (OK) response from the peer towards the IUT containing P-Associated-URI Header as : P-Associated-URI: b) Validate that the IUT discards the header while processing the response. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.4.6.12 PAsso_URI_Hdr_V_12 : Multiple p-assoc-uri-spec,some with generic-param and some without Test Objective : Validate parsing of P-Associated-URI with multiple p-assoc-uri-spec,some with generic-param and some without. Reference : RFC3455, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Private Header Extensions to SIP for 3GPP [17]. Steps F1 to F3 of Call Flow 1 have been executed. REGISTER was initiated by the IUT. Test Description : a) Send a 200 (OK) response from the peer towards the IUT containing P-Associated-URI Header as : P-Associated-URI: Alice ;expires=3600, , "Bob Drew" , Joe ;security=on b) Validate that the response is parsed successfully at the IUT. --------------------------------------------------------------------- Minakshi & Srimanta [Page 98] Internet Draft SIP-IMS Compliance Test Plan August 2007 3.5 SIP Event Package for Registration Since the Registration states are dynamic in nature, a new event package has been introduced to define the Registration state details. This provides a mechanism for a user-agent to request and receive the notifications regarding Registration state. 3.5.1 SUBSCRIBE/NOTIFY Cases --------------------------------------------------------------------- 3.5.1.1 Reg_SUBS_NTFY_V_01 : SUBSCRIBE message without a body Test Objective : To verify that the IUT successfully parses a SUBSCRIBE message without a body. Reference : RFC3680, Section 4.3 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. User is registered. Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT without any body. b) Verify that the SUBSCRIBE is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE procedure execution as per Call Flow 2. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.1.2 Reg_SUBS_NTFY_V_02 : SUBSCRIBE message with a body Test Objective : To verify that the IUT successfully parses a SUBSCRIBE message containing a body. Reference : RFC3680, Section 4.3 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. User is registered. Minakshi & Srimanta [Page 99] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with body. b) Verify that the SUBSCRIBE is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE procedure execution as per Call Flow 2. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.1.3 Reg_SUBS_NTFY_V_03 : SUBSCRIBE message with Event header as "reg" Test Objective : Verify the successful parsing of Event header as reg in a SUBSCRIBE message. Reference : RFC3680, Section 4.1 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. User is registered. Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with Event Header as : Event: reg b) Verify that the SUBSCRIBE is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE procedure execution as per Call Flow 2. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.1.4 Reg_SUBS_NTFY_V_04 : NOTIFY with Event header as "reg" Test Objective : Check that the IUT successfully parses the Event header set to reg in NOTIFY message Reference : RFC3680, Section 4.1 Applicable Messages : Not Applicable Minakshi & Srimanta [Page 100] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with Event Header as : Event: reg b) Verify that the NOTIFY is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.1.5 Reg_SUBS_NTFY_V_05 : SUBSCRIBE without Accept header Test Objective : Validate the parsing of a SUBSCRIBE message without an Accept header. Reference : RFC3680, Section 4.5 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. User is registered. Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT without the Accept Header. b) Verify that the SUBSCRIBE is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE procedure execution as per Call Flow 2 . d)Check that "application/reginfo+xml" is taken as the default value for Accept header for NOTIFY generation. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.1.6 Reg_SUBS_NTFY_V_06 : SUBSCRIBE with Accept header as "application/reginfo+xml" Minakshi & Srimanta [Page 101] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective : Check that the Accept header as "application/reginfo+xml" in a SUBSCRIBE message is successfully parsed at the IUT. Reference : RFC3680, Section 4.5 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. User is registered. Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with the Accept Header as : Accept: application/reginfo+xml b) Verify that the SUBSCRIBE is parsed successfully at the IUT. c) Validate the normal SUBSCRIBE procedure execution as per Call Flow 2 . --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.1.7 Reg_SUBS_NTFY_V_07 : Multi-valued Accept header Test Objective : To verify that the IUT successfully parses multi-valued Accept header with one of them being "application/reginfo+xml". Reference : RFC3680, Section 4.5 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. User is registered. Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with the Accept Header as : Accept: application/pidf+xml, application/reginfo+xml b) Verify that the SUBSCRIBE is parsed successfully at the IUT. Minakshi & Srimanta [Page 102] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal SUBSCRIBE procedure execution as per Call Flow 2 . --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.1.8 Reg_SUBS_NTFY_V_08 : Content-Type header as "application/reginfo+xml" Test Objective : Check that NOTIFY with the Content-type header as "application/reginfo+xml" is successfully parsed at the IUT. Reference : RFC3680, Section 4.5 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with Content-Type Header as : Content-Type: application/reginfo+xml b) Verify that the NOTIFY is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.1.9 Reg_SUBS_NTFY_I_09 : Event header as "reg" but "application/reginfo+xml" not listed in the Accept header Test Objective : To validate the IUT behavior when "application/reginfo+xml" is not present in the Accept Header values and the Event header mentions "reg". Reference : RFC3680, Section 4.5 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. User is registered. Minakshi & Srimanta [Page 103] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with the Event and Accept Headers as : Event: reg Accept: application/pidf+xml b) Verify that the SUBSCRIBE parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.1.10 Reg_SUBS_NTFY_V_10 : No Expires header in SUBSCRIBE Test Objective : Validate that the IUT successfully parses the SUBSCRIBE request without an Expires header. Reference : RFC3680, Section 4.4 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. User is registered. Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT without the Expires Header b) Verify that the SUBSCRIBE is parsed successfully at the IUT. c) Validate the normal SUBSCRIBE procedure execution as per Call Flow 2 . d) Check that the default value taken by IUT for expires is 3761 seconds. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.1.11 Reg_SUBS_NTFY_V_11 : Expires with value 600000 in SUBSCRIBE Test Objective : To verify the parsing of Expires header with value 600000 in SUBSCRIBE. Reference : RFC3680, Section 4.4 Applicable Messages : Not Applicable Minakshi & Srimanta [Page 104] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. User is registered. Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with the Expires Header as : Expires: 600000 b) Verify that the SUBSCRIBE is parsed successfully at the IUT. c) Validate the normal SUBSCRIBE procedure execution as per Call Flow 2 . --------------------------------------------------------------------- 3.5.2 NOTIFY Xml Parsing Cases --------------------------------------------------------------------- 3.5.2.1 Reg_Xml_V_01 : NOTIFY xml body with version=1.0 Test Objective : Check that the successful parsing of version set as 1.0 in xml body of NOTIFY. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with xml version as : b) Verify that the version is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.2 Reg_Xml_I_02 : NOTIFY xml body with invalid version Minakshi & Srimanta [Page 105] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective : Verify that an error is returned when xml body with version other than 1.0 is received in a NOTIFY message. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with xml version as : b) Verify that the version parsing fails at the IUT. c) Validate that error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.3 Reg_Xml_V_03 : Reginfo xml namespace Test Objective : Validate that the IUT successfully parses Reginfo xml namespace received as "urn:ietf:params:xml:ns:reginfo" in NOTIFY. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with xml namespace as : xmlns="urn:ietf:params:xml:ns:reginfo" b) Verify that the namespace is successfully parsed at the IUT. Minakshi & Srimanta [Page 106] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.4 Reg_Xml_I_04 : Reginfo xml namespace with invalid syntax Test Objective : To verify that IUT responds with an error when it receives Reginfo xml namespace without the opening quotes. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with xml namespace as : xmlns=urn:ietf:params:xml:ns:reginfo" b) Verify that the namespace parsing fails at the IUT. c) Validate that error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.5 Reg_Xml_V_05 : Reginfo element with version zero Test Objective : Verify successful parsing of version="0" in the reginfo element. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Minakshi & Srimanta [Page 107] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a NOTIFY from the peer towards the IUT with reginfo element version as zero : version="0" b) Verify that the reginfo version is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.6 Reg_Xml_V_06 : Reginfo element with version one Test Objective : Check that the IUT successfully parses version value set as 1 in the reginfo element. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. Steps F1 to F4 of Call Flow 2 have been executed. Test Description : a) Send a NOTIFY from the peer towards the IUT with reginfo element version as one : version="1" b) Verify that the reginfo version is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.7 Reg_Xml_V_07 : Reginfo element with version hundred Test Objective : Check that the IUT successfully parses version value set as 100 in the reginfo element. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Minakshi & Srimanta [Page 108] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. Steps F1 to F4 of Call Flow 2 have been executed. Test Description : a) Send a NOTIFY from the peer towards the IUT with reginfo element version as zero : version="100" b) Verify that the reginfo version is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.8 Reg_Xml_V_08 : Reginfo element with max allowed value Test Objective : Validation of parsing of max allowed value(2^32-1) of the version subelement in a reginfo element. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. Steps F1 to F4 of Call Flow 2 have been executed. Test Description : a) Send a NOTIFY from the peer towards the IUT with reginfo element version as zero : version="4294967295" b) Verify that the reginfo version is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.9 Reg_Xml_V_09 : State attribute as "full" Test Objective : Check that the IUT successfully parses the state attribute set to full in reginfo element of the xml body. Reference : RFC3680, Section 5.1 Minakshi & Srimanta [Page 109] Internet Draft SIP-IMS Compliance Test Plan August 2007 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with state attribute as full : b) Verify that the state-attribute is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.10 Reg_Xml_V_10 : State attribute as "partial" Test Objective : Check that the IUT successfully parses the state attribute set to partial in reginfo element of the xml body. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with state attribute as partial : b) Verify that the state-attribute is successfully parsed at the IUT. Minakshi & Srimanta [Page 110] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.11 Reg_Xml_I_11 : State attribute as "complete" Test Objective : Validate the IUT behavior when it receives state-attribute in reginfo element as "complete". Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with state attribute as complete : b) Verify that the state-attribute parsing fails at the IUT. c) Validate that error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.12 Reg_Xml_I_12 : Missing State attribute in the reginfo element Test Objective : Validate the IUT behavior on receipt of missing state attribute in the reginfo element. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : Minakshi & Srimanta [Page 111] Internet Draft SIP-IMS Compliance Test Plan August 2007 a) Send a NOTIFY from the peer towards the IUT with reginfo element as : b) Verify that the reginfo parsing fails at the IUT. c) Validate that error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.13 Reg_Xml_I_13 : Missing version in the reginfo element Test Objective : Validate the IUT behavior on receipt of missing version attribute in the reginfo element. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with reginfo element as : b) Verify that the reginfo parsing fails at the IUT. c) Validate that error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.14 Reg_Xml_I_14 : Reginfo element without namespace Test Objective : Validate the IUT behavior when reginfo without the namespace is received. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Minakshi & Srimanta [Page 112] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with reginfo element as : b) Verify that the reginfo parsing fails at the IUT. c) Validate that error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.15 Reg_Xml_V_15 : Single registration sub-element Test Objective : To verify that the IUT successfully parses the registration information comprising of a single sub-element. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with Registration element as : sip:user@pc887.example.com b) Verify that the Registration element is successfully parsed at the IUT. Minakshi & Srimanta [Page 113] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.16 Reg_Xml_V_16 : Multiple registration sub-elements Test Objective : To verify that the IUT successfully parses the registration information comprising of Multiple registration sub-elements Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with Registration element as : sip:user@pc887.example.com sip:user2@pc768.example.com b) Verify that the Registration element is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- Minakshi & Srimanta [Page 114] Internet Draft SIP-IMS Compliance Test Plan August 2007 3.5.2.17 Reg_Xml_I_17 : Registration information without any registration sub-element Test Objective : Validate the IUT behavior when registration information without any sub-element is received. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with Registration element as : b) Verify that the Registration element is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.18 Reg_Xml_V_18 : Registration element with single contact address Test Objective : To verify the parsing of registration element with a single contact address. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Minakshi & Srimanta [Page 115] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a NOTIFY from the peer towards the IUT with Registration element as : sip:user@pc887.example.com b) Verify that the Registration element is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.19 Reg_Xml_V_19 : Registration element with multiple contact addresses Test Objective : To verify the parsing of registration element with multiple contact addresses. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with Registration element as : Minakshi & Srimanta [Page 116] Internet Draft SIP-IMS Compliance Test Plan August 2007 sip:user@pc887.example.com sip:user@pc768.example.com sip:user@pc1.example.com b) Verify that the Registration element is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.20 Reg_Xml_I_20 : Two registration elements with same id Test Objective : Verify that the IUT returns an error response on receipt of two registration elements with same id. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with body as : sip:user@pc887.example.com Minakshi & Srimanta [Page 117] Internet Draft SIP-IMS Compliance Test Plan August 2007 sip:user2@pc768.example.com b) Verify that the NOTIFY body parsing fails at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.21 Reg_Xml_I_21 : Missing id attribute in the registration element Test Objective : Validate the IUT behavior on receipt of missing id attribute in the registration element. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with body as : sip:user@pc887.example.com b) Verify that the NOTIFY body parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- Minakshi & Srimanta [Page 11] Internet Draft SIP-IMS Compliance Test Plan August 2007 3.5.2.22 Reg_Xml_I_22 : Missing id attribute in the registration element Test Objective : Validate the IUT behavior on receipt of missing id attribute in the registration element. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with body as : sip:user@pc887.example.com b) Verify that the NOTIFY body parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.23 Reg_Xml_I_23 : Missing state-attribute in the registration element Test Objective : Validate the IUT behavior when registration element is received without the state attribute. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. Minakshi & Srimanta [Page 119] Internet Draft SIP-IMS Compliance Test Plan August 2007 IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with body as : sip:user@pc887.example.com b) Verify that the NOTIFY body parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.24 Reg_Xml_I_24 : Mandatory aor attribute missing Test Objective : Validate the IUT behavior when registration element without the aor is received. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with body as : Minakshi & Srimanta [Page 120] Internet Draft SIP-IMS Compliance Test Plan August 2007 sip:user@pc887.example.com b) Verify that the NOTIFY body parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.25 Reg_Xml_V_25 : Registration state attribute set as active Test Objective : To verify that the IUT successfully parses the registration state attribute set as active. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with Registration state attribute as : b) Verify that the Registration element is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.26 Reg_Xml_V_26 : Registration state attribute set as init Test Objective : Check that the registration state attribute as init is parsed successfully at the IUT. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. Minakshi & Srimanta [Page 121] Internet Draft SIP-IMS Compliance Test Plan August 2007 IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with Registration state attribute as : b) Verify that the Registration element is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.27 Reg_Xml_V_27 : Registration state attribute set as terminated Test Objective : Check that the registration state attribute as terminated is parsed successfully at the IUT. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with Registration state attribute as : b) Verify that the Registration element is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.28 Reg_Xml_V_28 : Contact element containing only a URI Test Objective : To verify contact element parsing when it comprises of only the mandatory element(a URI). Minakshi & Srimanta [Page 122] Internet Draft SIP-IMS Compliance Test Plan August 2007 Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with contact element as : sip:user@pc887.example.com b) Verify that the contact element is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.29 Reg_Xml_V_29 : Contact element containing display-name Test Objective : Validate that the IUT successfully parses the contact element when it consists of the URI and a display-name. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with contact element as : sip:user@pc887.example.com Bob Minakshi & Srimanta [Page 123] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that the contact element is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.30 Reg_Xml_V_30 : Contact element containing display-name and an unknown-param elements Test Objective : To check the parsing of contact element when it comprises of all the allowed elements, that is, a URI, display name and an unknown-param element. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with contact element as : sip:user@pc887.example.com Bob audio b) Verify that the contact element is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.31 Reg_Xml_V_31 : Contact element containing only the mandatory attributes Test Objective : Verify that the IUT successfully at parses the contact element when it contains only the mandatory attributes, that is, id, state and event. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Minakshi & Srimanta [Page 124] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with contact element as : sip:user@pc887.example.com Bob audio b) Verify that the contact element is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.32 Reg_Xml_V_32 : Contact element containing only the mandatory attributes Test Objective : Verify that the IUT successfully at parses the contact element when it contains only the mandatory attributes, that is, id, state and event. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with contact element as : sip:user@pc887.example.com Bob audio Minakshi & Srimanta [Page 125] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that the contact element is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.33 Reg_Xml_V_33 : Contact element with event attribute as "registered" Test Objective :To verify event attribute parsing with value set to "registered" in the contact element. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with event attribute in contact element as : b) Verify that the event attribute is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.34 Reg_Xml_V_34 : Contact element with event attribute as "created" Test Objective :To verify event attribute parsing with value set to "created" in the contact element. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Minakshi & Srimanta [Page 126] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a NOTIFY from the peer towards the IUT with event attribute in contact element as : b) Verify that the event attribute is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.35 Reg_Xml_V_35 : Contact element with event attribute as "refreshed" Test Objective :To verify event attribute parsing with value set to "refreshed" in the contact element. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with event attribute in contact element as : b) Verify that the event attribute is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.36 Reg_Xml_V_36 : Contact element with event attribute as "shortened" and state attribute as "active" Test Objective :To verify event attribute parsing with value set to "shortened" and state attribute as "active" in the contact element. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Minakshi & Srimanta [Page 127] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with event attribute in contact element as : b) Verify that the event attribute is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.37 Reg_Xml_V_37 : Contact element with event attribute as "expired" Test Objective :To verify event attribute parsing with value set to "expired" in the contact element. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with event attribute in contact element as : b) Verify that the event attribute is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.38 Reg_Xml_V_38 : Contact element with event attribute as "deactivated" Minakshi & Srimanta [Page 128] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective :To verify event attribute parsing with value set to "deactivated" in the contact element. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with event attribute in contact element as : b) Verify that the event attribute is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.39 Reg_Xml_V_39 : Contact element with event attribute as "probation" Test Objective :To verify event attribute parsing with value set to "probation" in the contact element. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with event attribute in contact element as : b) Verify that the event attribute is successfully parsed at the IUT. Minakshi & Srimanta [Page 129] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.40 Reg_Xml_V_40 : Contact element with event attribute as "unregistered" Test Objective :To verify event attribute parsing with value set to "unregistered" in the contact element. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with event attribute in contact element as : b) Verify that the event attribute is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.41 Reg_Xml_V_41 : Contact element with event attribute as "rejected" and state attribute as "terminated" Test Objective :To verify event attribute parsing with value set to "rejected" and state attribute as "terminated" in the contact element. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : Minakshi & Srimanta [Page 130] Internet Draft SIP-IMS Compliance Test Plan August 2007 a) Send a NOTIFY from the peer towards the IUT with event attribute in contact element as : b) Verify that the event attribute is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.42 Reg_Xml_I_42 : Contact element with state attribute set to an undefined value Test Objective : Verify that the IUT returns an error response on receipt of state attribute with an not-defined value(expired) in the contact element. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with event attribute in contact element as : b) Verify that the event attribute parsing fails at the IUT and error response is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.43 Reg_Xml_I_43 : Contact element with non-numeric id value Test Objective : Validate the IUT behavior on receipt of non-numeric id attribute in the contact element. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Minakshi & Srimanta [Page 131] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with event attribute in contact element as : b) Verify that the event attribute parsing fails at the IUT and error response is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.44 Reg_Xml_I_44 : Contact element with event-attribute set to undefined value Test Objective : Validate the IUT behavior when contact element is received with the event attribute set to an undefined value(init). Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with event attribute in contact element as : b) Verify that the event attribute parsing fails at the IUT and error response is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.45 Reg_Xml_V_45 : Contact element with expires attribute Test Objective : Validate that the IUT successfully parses the contact element when expires attribute is present along with the event attribute set as shortened and state attribute as active. Minakshi & Srimanta [Page 132] Internet Draft SIP-IMS Compliance Test Plan August 2007 Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with event attribute in contact element as : b) Verify that the event attribute is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.46 Reg_Xml_V_46 : Contact element with event attribute as refreshed and expires attribute Test Objective : To check the parsing of contact element when it comprises of state attribute as active, event attribute as refreshed and expires attribute. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with event attribute in contact element as : b) Verify that the event attribute is successfully parsed at the IUT. Minakshi & Srimanta [Page 133] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.47 Reg_Xml_I_47 : Expires attribute when the state is "terminated Test Objective : Validate the IUT behavior on receipt of expires attribute and the state attribute = terminated in the contact element. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with body as : b) Verify that the NOTIFY body parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.48 Reg_Xml_I_48 : Shortened event attribute without the expires attribute Test Objective : Verify that the IUT returns an error response on receipt of shortened as event attribute and missing expires attribute in the contact element. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Minakshi & Srimanta [Page 134] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a NOTIFY from the peer towards the IUT with body as : b) Verify that the NOTIFY body parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.49 Reg_Xml_V_49 : Presence of Retry-after attribute when the event attribute as probation Test Objective : To check the successful parsing of contact element when it comprises of event attribute as probation and a retry-after attribute. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with event attribute in contact element as : b) Verify that the event attribute is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.50 Reg_Xml_I_50 : Missing Retry-after attribute in contact element and the event attribute as probation Test Objective : To verify that error is returned by the IUT on event attribute as probation and no retry-after attribute in the contact element. Reference : RFC3680, Section 5.1 Minakshi & Srimanta [Page 135] Internet Draft SIP-IMS Compliance Test Plan August 2007 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with body as : b) Verify that the NOTIFY body parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.51 Reg_Xml_I_51 : Missing Retry-after attribute in contact element and the state as active Test Objective : Validate the IUT behavior on receipt of contact element containing retry-after attribute along with the state attribute set to active. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with body as : b) Verify that the NOTIFY body parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.52 Reg_Xml_V_52 : Contact element containing duration-registered Minakshi & Srimanta [Page 136] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective : To check the parsing of contact element when it comprises of optional element duration-registered along with the mandatory attribute. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with contact element as : b) Verify that the contact element is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.53 Reg_Xml_V_53 : Contact element containing CSeq and q attributes Test Objective : To verify that the IUT successfully parses the optional attributes- Cseq and q in the contact element. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with contact element as : Minakshi & Srimanta [Page 137] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that the contact element is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.5.2.54 Reg_Xml_I_54 : Contact element with invalid syntax Test Objective : Verify that the IUT responds with an error when it receives the contact element with missing closing > for uri attribute. Reference : RFC3680, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports SIP Event Package for Registration [9]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with event attribute in contact element as : sip:user@pc887.example.com b) Verify that the NOTIFY body parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- 3.6 UPDATE Support in SIP UPDATE is a new method introduced for updating of session parameters during Call establishment, that is, early-dialog as well as after Call establishment. 3.6.1 UPDATE Cases --------------------------------------------------------------------- 3.6.1.1 UPD_Supp_V_01 : INVITE request with UPDATE in the Allow header Test Objective : To verify the parsing of INVITE request with UPDATE as one of the methods in the Allow header. Minakshi & Srimanta [Page 138] Internet Draft SIP-IMS Compliance Test Plan August 2007 Reference : RFC3311, Section 4 Applicable Messages : INVITE Pre-Requirement : IUT Supports the UPDATE Method [8] User is registered. Test Description : a) Send a INVITE request from the peer towards the IUT with Allow Header as : Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE b) Verify that the INVITE is successfully parsed at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.6.1.2 UPD_Supp_V_02 : Provisional Response with UPDATE in the Allow header Test Objective : To validate the parsing of provisional response (with sdp) containing UPDATE in the Allow header. Reference : RFC3311, Section 4 Applicable Messages : INVITE Pre-Requirement : IUT Supports the UPDATE Method [8] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 183 (Session Progress) from the peer towards the IUT with Allow Header as : Allow: UPDATE, ACK, CANCEL, BYE, PRACK b) Verify that the 183 response is successfully parsed at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- Minakshi & Srimanta [Page 139] Internet Draft SIP-IMS Compliance Test Plan August 2007 3.6.1.3 UPD_Supp_V_03 : 200 OK response to INVITE containing UPDATE in the Allow header Test Objective : To validate that 200 OK response to INVITE containing UPDATE in the Allow header is parsed successfully at the IUT. Reference : RFC3311, Section 4 Applicable Messages : INVITE Pre-Requirement : IUT Supports the UPDATE Method [8] User is registered. Steps F1 to F20 of Call Flow 3 have been executed. Test Description : a) Send a 200 (OK) from the peer towards the IUT with Allow Header as : Allow: UPDATE, INVITE, ACK, CANCEL, BYE b) Verify that the 200 response is successfully parsed at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.6.1.4 UPD_Supp_V_04 : UPDATE with only the mandatory headers Test Objective : To verify that the IUT successfully parses a UPDATE containing only the mandatory headers as specified in RFC 3311 [8]. Reference : RFC3311, Section 8 Applicable Messages : UPDATE Pre-Requirement : IUT Supports the UPDATE Method [8] User is registered. Steps F1 to F10 of Call Flow 3 have been executed. Test Description : a) Send a UPDATE Request from the peer with all mandatory headers as per RFC 3311 [8]. b) Verify that the UPDATE is successfully parsed at the IUT. Minakshi & Srimanta [Page 140] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.6.1.5 UPD_Supp_V_05 : UPDATE with mandatory and some optional headers Test Objective : To verify that the IUT successfully parses a UPDATE containing the mandatory headers and some optional (Supported, Date) as specified in RFC 3311 [8]. Reference : RFC3311, Section 8 Applicable Messages : UPDATE Pre-Requirement : IUT Supports the UPDATE Method [8] User is registered. Steps F1 to F10 of Call Flow 3 have been executed. Test Description : a) Send a UPDATE Request from the peer with all mandatory headers and some optional headers (say, Supported and Date). b) Verify that the UPDATE is successfully parsed at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.6.1.6 UPD_Supp_I_06 : UPDATE with missing mandatory header Test Objective : To verify that the IUT successfully parses a UPDATE with missing Mandatory ( say CSeq) header. Reference : RFC3311, Section 8 Applicable Messages : UPDATE Pre-Requirement : IUT Supports the UPDATE Method [8] User is registered. Steps F1 to F10 of Call Flow 3 have been executed. Test Description : a) Send a UPDATE Request from the peer with all mandatory headers as per RFC 3311 [8], except the CSeq Header. Minakshi & Srimanta [Page 141] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that the UPDATE parsing fails at the IUT. c) Validate that an error response is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.6.1.7 UPD_Supp_I_07 : UPDATE with header that is not allowed Test Objective : To verify that the IUT discards the header (say Subject) that is not allowed in UPDATE but is received from the peer. Reference : RFC3311, Section 8 Applicable Messages : UPDATE Pre-Requirement : IUT Supports the UPDATE Method [8] User is registered. Steps F1 to F10 of Call Flow 3 have been executed. Test Description : a) Send a UPDATE Request from the peer with Subject header along with all the mandatory headers as per RFC 3311 [8]. b) Verify that the UPDATE is successfully parsed at the IUT and the Subject header is discarded. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.6.1.8 UPD_Supp_I_08 : UPDATE received outside a dialog Test Objective : To verify that the IUT discards the UPDATE request received oustide a dialog. Reference : RFC3311, Section 8 Applicable Messages : UPDATE Pre-Requirement : IUT Supports the UPDATE Method [8] User is registered. Test Description : a) Send a UPDATE Request from the peer with valid headers as per RFC 3311 [8]. Minakshi & Srimanta [Page 142] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that the UPDATE is discarded at the IUT. --------------------------------------------------------------------- 3.7 Resource Management Integration and SIP Integration of resource management provides a generic framework for preconditions. This helps in ensuring quality of service by requiring participants to reserve the resources before continuing with session establishment. 3.7.1 Current-Status Sdp Cases --------------------------------------------------------------------- 3.7.1.1 Curr_Sdp_V_01 : Current-status sdp as qos, local, none Test Objective : To verify the parsing of Current-status sdp parameter with following tag values : precondition-type as qos status-type as local direction tag as none Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with current-status sdp as : a=curr:qos local none b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.1.2 Curr_Sdp_V_02 : Current-status sdp as qos, remote, none Test Objective : To verify the parsing of Current-status sdp parameter with following tag values : precondition-type as qos status-type as remote direction tag as none Minakshi & Srimanta [Page 143] Internet Draft SIP-IMS Compliance Test Plan August 2007 Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 183 response from the peer towards the IUT with current-status sdp as : a=curr:qos remote none b) Verify that the response is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.1.3 Curr_Sdp_V_03 : Current-status sdp as qos, e2e, none Test Objective : To verify the parsing of Current-status sdp parameter with following tag values : precondition-type as qos status-type as e2e direction tag as none Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F6 of Call Flow 3 have been executed. Test Description : a) Send a PRACK from the peer towards the IUT with current-status sdp as : a=curr:qos e2e none b) Verify that the PRACK is parsed successfully at the IUT. Minakshi & Srimanta [Page 144] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.1.4 Curr_Sdp_V_04 : Current-status sdp as qos, local, send Test Objective : To verify the parsing of Current-status sdp parameter with following tag values : precondition-type as qos status-type as local direction tag as send Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F10 of Call Flow 3 have been executed. Test Description : a) Send an UPDATE from the peer towards the IUT with current-status sdp as : a=curr:qos local send b) Verify that the UPDATE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.1.5 Curr_Sdp_V_05 : Current-status sdp as qos, remote, send Test Objective : To verify the parsing of Current-status sdp parameter with following tag values : precondition-type as qos status-type as remote direction tag as send Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Minakshi & Srimanta [Page 145] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F20 of Call Flow 3 have been executed. Test Description : a) Send 200 (OK) response from the peer towards the IUT with current-status sdp as : a=curr:qos remote send b) Verify that 200 (OK) is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.1.6 Curr_Sdp_V_06 : Current-status sdp as qos, e2e, send Test Objective : To verify the parsing of Current-status sdp parameter with following tag values : precondition-type as qos status-type as e2e direction tag as send Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with current-status sdp as : a=curr:qos e2e send b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.1.7 Curr_Sdp_V_07 : Current-status sdp as qos, local, recv Minakshi & Srimanta [Page 146] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective : To verify the parsing of Current-status sdp parameter with following tag values : precondition-type as qos status-type as local direction tag as recv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 183 response from the peer towards the IUT with current-status sdp as : a=curr:qos local recv b) Verify that the response is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.1.8 Curr_Sdp_V_08 : Current-status sdp as qos, remote, recv Test Objective : To verify the parsing of Current-status sdp parameter with following tag values : precondition-type as qos status-type as remote direction tag as recv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F6 of Call Flow 3 have been executed. Test Description : a) Send a PRACK from the peer towards the IUT with current-status sdp as : Minakshi & Srimanta [Page 147] Internet Draft SIP-IMS Compliance Test Plan August 2007 a=curr:qos remote recv b) Verify that the PRACK is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.1.9 Curr_Sdp_V_09 : Current-status sdp as qos, e2e, recv Test Objective : To verify the parsing of Current-status sdp parameter with following tag values : precondition-type as qos status-type as e2e direction tag as recv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F10 of Call Flow 3 have been executed. Test Description : a) Send an UPDATE from the peer towards the IUT with current-status sdp as : a=curr:qos e2e recv b) Verify that the UPDATE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.1.10 Curr_Sdp_V_10 : Current-status sdp as qos, local, sendrecv Test Objective : To verify the parsing of Current-status sdp parameter with following tag values : precondition-type as qos status-type as local direction tag as sendrecv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Minakshi & Srimanta [Page 148] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F20 of Call Flow 3 have been executed. Test Description : a) Send 200 (OK) response from the peer towards the IUT with current-status sdp as : a=curr:qos local sendrecv b) Verify that 200 (OK) is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.1.11 Curr_Sdp_V_11 : Current-status sdp as qos, remote, sendrecv Test Objective : To verify the parsing of Current-status sdp parameter with following tag values : precondition-type as qos status-type as remote direction tag as sendrecv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F20 of Call Flow 3 have been executed. Test Description : a) Send 200 (OK) response from the peer towards the IUT with current-status sdp as : a=curr:qos remote sendrecv b) Verify that 200 (OK) is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.1.12 Curr_Sdp_V_12 : Current-status sdp as qos, e2e, sendrecv Minakshi & Srimanta [Page 149] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective : To verify the parsing of Current-status sdp parameter with following tag values : precondition-type as qos status-type as e2e direction tag as sendrecv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F20 of Call Flow 3 have been executed. Test Description : a) Send 200 (OK) response from the peer towards the IUT with current-status sdp as : a=curr:qos e2e sendrecv b) Verify that 200 (OK) is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.1.13 Curr_Sdp_V_13 : Current-status sdp as token, e2e, sendrecv Test Objective : To verify the parsing of Current-status sdp parameter with following tag values : precondition-type as token status-type as e2e direction tag as sendrecv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. IUT supports "conn" as a pre-condition tag Test Description : a) Send an INVITE request from the peer towards the IUT with current-status sdp as : Minakshi & Srimanta [Page 150] Internet Draft SIP-IMS Compliance Test Plan August 2007 a=curr:conn e2e sendrecv b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.1.14 Curr_Sdp_I_14 : Current-status sdp with strength-tag Test Objective : To validate that the IUT discards the current-status sdp received as : precondition-type as qos strength-tag as optional status-type as remote direction tag as none Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 183 response from the peer towards the IUT with current status sdp as : a=curr:qos optional remote none b) Verify that the sdp parsing fails at the IUT and the sdp is discarded. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.1.15 Curr_Sdp_I_15 : Current-status sdp without a direction tag Test Objective : To validate that the IUT returns an error on receipt of the current-status sdp as : precondition-type as token status-type as e2e Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, PRACK, UPDATE Minakshi & Srimanta [Page 151] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. IUT supports "conn" as a pre-condition tag Test Description : a) Send an INVITE request from the peer towards the IUT with current-status sdp as : a=curr:conn e2e b) Verify that the sdp parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.1.16 Curr_Sdp_I_16 : Current-status sdp as qos, eTOe, send Test Objective : To validate the IUT behavior on receipt of Current-status sdp parameter with following tag values : precondition-type as qos status-type as eTOe direction tag as send Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with current-status sdp as : a=curr:qos eTOe send b) Verify that the sdp parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.1.17 Curr_Sdp_I_17 : Current-status sdp as qos, recv, local Test Objective : To validate the IUT behavior on receipt of Current-status with tag values in incorrect sequence. Reference : RFC3312, Section 4 Minakshi & Srimanta [Page 152] Internet Draft SIP-IMS Compliance Test Plan August 2007 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 183 response from the peer towards the IUT with current-status sdp as : a=curr:qos recv local b) Verify that the sdp parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.1.18 Curr_Sdp_I_18 : Current-status sdp with semi used as a separator between different tag values Test Objective : To validate the IUT behavior on receipt of Current-status sdp with semi used as a separator between different tag values. Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 183 response from the peer towards the IUT with current-status sdp as : a=curr:qos;local;recv b) Verify that the sdp parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- 3.7.2 Confirm-Status Sdp Cases --------------------------------------------------------------------- 3.7.2.1 Conf_Sdp_V_01 : Confirm-Status sdp as qos, remote, none Minakshi & Srimanta [Page 153] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective : To verify the parsing of Confirm-Status sdp parameter with following tag values : precondition-type as qos status-type as remote direction tag as none Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 183 response from the peer towards the IUT with Confirm-Status sdp as : a=conf:qos remote none b) Verify that the response is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.2.2 Conf_Sdp_V_02 : Confirm-Status sdp as qos, local, none Test Objective : To verify the parsing of Confirm-Status sdp parameter with following tag values : precondition-type as qos status-type as local direction tag as none Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F20 of Call Flow 3 have been executed. Test Description : a) Send 200 (OK) response from the peer towards the IUT with Confirm-Status sdp as : Minakshi & Srimanta [Page 154] Internet Draft SIP-IMS Compliance Test Plan August 2007 a=conf:qos local none b) Verify that 200 (OK) is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.2.3 Conf_Sdp_V_03 : Confirm-Status sdp as qos, e2e, none Test Objective : To verify the parsing of Confirm-Status sdp parameter with following tag values : precondition-type as qos status-type as e2e direction tag as none Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 183 response from the peer towards the IUT with Confirm-Status sdp as : a=conf:qos e2e none b) Verify that the response is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.2.4 Conf_Sdp_V_04 : Confirm-Status sdp as qos, local, send Test Objective : To verify the parsing of Confirm-Status sdp parameter with following tag values : precondition-type as qos status-type as local direction tag as send Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Minakshi & Srimanta [Page 155] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F20 of Call Flow 3 have been executed. Test Description : a) Send 200 (OK) response from the peer towards the IUT with Confirm-Status sdp as : a=conf:qos local send b) Verify that 200 (OK) is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.2.5 Conf_Sdp_V_05 : Confirm-Status sdp as qos, remote, send Test Objective : To verify the parsing of Confirm-Status sdp parameter with following tag values : precondition-type as qos status-type as remote direction tag as send Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 183 response from the peer towards the IUT with Confirm-Status sdp as : a=conf:qos remote send b) Verify that the response is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- Minakshi & Srimanta [Page 156] Internet Draft SIP-IMS Compliance Test Plan August 2007 3.7.2.6 Conf_Sdp_V_06 : Confirm-Status sdp as qos, e2e, send Test Objective : To verify the parsing of Confirm-Status sdp parameter with following tag values : precondition-type as qos status-type as e2e direction tag as send Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F20 of Call Flow 3 have been executed. Test Description : a) Send 200 (OK) response from the peer towards the IUT with Confirm-Status sdp as : a=conf:qos e2e send b) Verify that 200 (OK) is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.2.7 Conf_Sdp_V_07 : Confirm-Status sdp as qos, local, recv Test Objective : To verify the parsing of Confirm-Status sdp parameter with following tag values : precondition-type as qos status-type as local direction tag as recv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Minakshi & Srimanta [Page 157] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a 183 response from the peer towards the IUT with Confirm-Status sdp as : a=conf:qos local recv b) Verify that the response is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.2.8 Conf_Sdp_V_08 : Confirm-Status sdp as qos, remote, recv Test Objective : To verify the parsing of Confirm-Status sdp parameter with following tag values : precondition-type as qos status-type as remote direction tag as recv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F20 of Call Flow 3 have been executed. Test Description : a) Send 200 (OK) response from the peer towards the IUT with Confirm-Status sdp as : a=conf:qos remote recv b) Verify that 200 (OK) is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.2.9 Conf_Sdp_V_09 : Confirm-Status sdp as qos, e2e, recv Test Objective : To verify the parsing of Confirm-Status sdp parameter with following tag values : precondition-type as qos Minakshi & Srimanta [Page 158] Internet Draft SIP-IMS Compliance Test Plan August 2007 status-type as e2e direction tag as recv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 183 response from the peer towards the IUT with Confirm-Status sdp as : a=conf:qos e2e recv b) Verify that the response is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.2.10 Conf_Sdp_V_10 : Confirm-Status sdp as qos, local, sendrecv Test Objective : To verify the parsing of Confirm-Status sdp parameter with following tag values : precondition-type as qos status-type as local direction tag as sendrecv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F20 of Call Flow 3 have been executed. Test Description : a) Send 200 (OK) response from the peer towards the IUT with Confirm-Status sdp as : a=conf:qos local sendrecv b) Verify that 200 (OK) is parsed successfully at the IUT. Minakshi & Srimanta [Page 159] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.2.11 Conf_Sdp_V_11 : Confirm-Status sdp as qos, remote, sendrecv Test Objective : To verify the parsing of Confirm-Status sdp parameter with following tag values : precondition-type as qos status-type as remote direction tag as sendrecv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 183 response from the peer towards the IUT with Confirm-Status sdp as : a=conf:qos remote sendrecv b) Verify that the response is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.2.12 Conf_Sdp_V_12 : Confirm-Status sdp as qos, e2e, sendrecv Test Objective : To verify the parsing of Confirm-Status sdp parameter with following tag values : precondition-type as qos status-type as e2e direction tag as sendrecv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] Minakshi & Srimanta [Page 160] Internet Draft SIP-IMS Compliance Test Plan August 2007 User is registered. Steps F1 to F20 of Call Flow 3 have been executed. Test Description : a) Send 200 (OK) response from the peer towards the IUT with Confirm-Status sdp as : a=conf:qos e2e sendrecv b) Verify that 200 (OK) is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.2.13 Conf_Sdp_V_13 : Confirm-Status sdp as token, e2e, sendrecv Test Objective : To verify the parsing of Confirm-Status sdp parameter with following tag values : precondition-type as token status-type as e2e direction tag as sendrecv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. IUT supports "conn" as precondition token Test Description : a) Send a 183 response from the peer towards the IUT with Confirm-Status sdp as : a=conf:conn e2ee sendrecv b) Verify that the response is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- Minakshi & Srimanta [Page 161] Internet Draft SIP-IMS Compliance Test Plan August 2007 3.7.2.14 Conf_Sdp_I_14 : strength-tag parameter in Confirm-status sdp Test Objective : To validate that the IUT discards the confirm-status sdp received with a strength tag. Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F20 of Call Flow 3 have been executed. Test Description : a) Send 200 (OK) response from the peer towards the IUT with Confirm-Status sdp as : a=conf:qos none e2e sendrecv b) Verify that 200 (OK) sdp parsing fails at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.2.15 Conf_Sdp_I_15 : Confirm-status sdp without a direction tag Test Objective : To verify the parsing of Confirm-Status sdp parameter with following tag values : precondition-type as qos status-type as e2e Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 183 response from the peer towards the IUT with Confirm-Status sdp as : a=conf:qos e2e Minakshi & Srimanta [Page 162] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that 183 sdp parsing fails at the IUT and the sdp is discarded. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.2.16 Conf_Sdp_I_16 : Confirm-status sdp as qos, eTOe, send Test Objective : To validate the IUT behavior on receipt of Confirm-status sdp parameter with following tag values : precondition-type as qos status-type as eTOe direction tag as send Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Confirm-status sdp as : a=conf:qos eTOe send b) Verify that the sdp parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.1.17 Conf_Sdp_I_17 : Confirm-status sdp as qos, recv, local Test Objective : To validate the IUT behavior on receipt of Confirm-status with tag values in incorrect sequence. Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 183 response from the peer towards the IUT with Confirm-status sdp as : Minakshi & Srimanta [Page 163] Internet Draft SIP-IMS Compliance Test Plan August 2007 a=Conf:qos recv local b) Verify that the sdp parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.1.18 Conf_Sdp_I_18 : Confirm-status sdp with semi used as a separator between different tag values Test Objective : To validate the IUT behavior on receipt of Confirm-status sdp with semi used as a separator between different tag values. Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 183 response from the peer towards the IUT with Confirm-status sdp as : a=Conf:qos;local;recv b) Verify that the sdp parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- 3.7.3 Desired-Status Sdp Cases --------------------------------------------------------------------- 3.7.3.1 Des_Sdp_V_01 : Desired-Status sdp as qos, none, local, none Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as none status-type as local direction tag as none Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, PRACK, UPDATE Minakshi & Srimanta [Page 164] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Desired-Status sdp as : a=des:qos none local none b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.2 Des_Sdp_V_02 : Desired-Status sdp as qos, none, remote, none Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as none status-type as remote direction tag as none Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 183 response from the peer towards the IUT with Desired-Status sdp as : a=des:qos none remote none b) Verify that the response is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.3 Des_Sdp_V_03 : Desired-Status sdp as qos, none, e2e, none Minakshi & Srimanta [Page 165] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as none status-type as e2e direction tag as none Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F6 of Call Flow 3 have been executed. Test Description : a) Send a PRACK from the peer towards the IUT with Desired-Status sdp as : a=des:qos none e2e none b) Verify that the PRACK is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.4 Des_Sdp_V_04 : Desired-Status sdp as qos, none, local, send Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as none status-type as local direction tag as send Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F10 of Call Flow 3 have been executed. Minakshi & Srimanta [Page 166] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send an UPDATE from the peer towards the IUT with Desired-Status sdp as : a=des:qos none local send b) Verify that the UPDATE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.5 Des_Sdp_V_05 : Desired-Status sdp as qos, mandatory, local, send Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as mandatory status-type as local direction tag as send Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F20 of Call Flow 3 have been executed. Test Description : a) Send 200 (OK) response from the peer towards the IUT with Desired-Status sdp as : a=des:qos mandatory local send b) Verify that 200 (OK) is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.6 Des_Sdp_V_06 : Desired-Status sdp as qos, optional, local, send Minakshi & Srimanta [Page 167] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as optional status-type as local direction tag as send Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Desired-Status sdp as : a=des:qos optional local send b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.7 Des_Sdp_V_07 : Desired-Status sdp as qos, failure, local, send Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as failure status-type as local direction tag as send Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : Minakshi & Srimanta [Page 168] Internet Draft SIP-IMS Compliance Test Plan August 2007 a) Send a 580 response from the peer towards the IUT with Desired-Status sdp as : a=des:qos failure local send b) Verify that the response is parsed successfully at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.8 Des_Sdp_V_08 : Desired-Status sdp as qos, unknown, local, send Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as unknown status-type as local direction tag as send Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 580 response from the peer towards the IUT with Desired-Status sdp as : a=des:qos unknown local send b) Verify that the response is parsed successfully at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.9 Des_Sdp_V_09 : Desired-Status sdp as qos, none, remote, send Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as none status-type as remote direction tag as send Reference : RFC3312, Section 4 Minakshi & Srimanta [Page 169] Internet Draft SIP-IMS Compliance Test Plan August 2007 Applicable Messages : BYE, CANCEL, INVITE, PRACK Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F10 of Call Flow 3 have been executed. Test Description : a) Send an UPDATE from the peer towards the IUT with Desired-Status sdp as : a=des:qos none remote send b) Verify that the UPDATE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.10 Des_Sdp_V_10 : Desired-Status sdp as qos, mandatory, remote, send Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as mandatory status-type as remote direction tag as send Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F20 of Call Flow 3 have been executed. Test Description : a) Send 200 (OK) response from the peer towards the IUT with Desired-Status sdp as : a=des:qos mandatory remote send b) Verify that 200 (OK) is parsed successfully at the IUT. Minakshi & Srimanta [Page 170] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.11 Des_Sdp_V_11 : Desired-Status sdp as qos, optional, remote, send Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as optional status-type as remote direction tag as send Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Desired-Status sdp as : a=des:qos optional remote send b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.12 Des_Sdp_V_12 : Desired-Status sdp as qos, failure, remote, send Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as failure status-type as remote direction tag as send Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Minakshi & Srimanta [Page 171] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 580 response from the peer towards the IUT with Desired-Status sdp as : a=des:qos failure remote send b) Verify that the response is parsed successfully at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.13 Des_Sdp_V_13 : Desired-Status sdp as qos, unknown, remote, send Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as unknown status-type as remote direction tag as send Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F6 of Call Flow 3 have been executed. Test Description : a) Send a PRACK from the peer towards the IUT with Desired-Status sdp as : a=des:qos unknown remote send b) Verify that the PRACK is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.14 Des_Sdp_V_14 : Desired-Status sdp as qos, none, e2e, send Minakshi & Srimanta [Page 172] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as none status-type as e2e direction tag as send Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F10 of Call Flow 3 have been executed. Test Description : a) Send an UPDATE from the peer towards the IUT with Desired-Status sdp as : a=des:qos none e2e send b) Verify that the UPDATE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.15 Des_Sdp_V_15 : Desired-Status sdp as qos, mandatory, e2e, send Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as mandatory status-type as e2e direction tag as none Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F20 of Call Flow 3 have been executed. Test Description : Minakshi & Srimanta [Page 173] Internet Draft SIP-IMS Compliance Test Plan August 2007 a) Send 200 (OK) response from the peer towards the IUT with Desired-Status sdp as : a=des:qos mandatory e2e send b) Verify that 200 (OK) is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.16 Des_Sdp_V_16 : Desired-Status sdp as qos, optional, e2e, send Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as optional status-type as e2e direction tag as send Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Desired-Status sdp as : a=des:qos optional e2e send b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.17 Des_Sdp_V_17 : Desired-Status sdp as qos, failure, e2e, send Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos Minakshi & Srimanta [Page 174] Internet Draft SIP-IMS Compliance Test Plan August 2007 strength-tag as failure status-type as e2e direction tag as send Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 580 response from the peer towards the IUT with Desired-Status sdp as : a=des:qos failure e2e send b) Verify that the response is parsed successfully at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.18 Des_Sdp_V_18 : Desired-Status sdp as qos, unknown, e2e, send Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as unknown status-type as e2e direction tag as send Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F6 of Call Flow 3 have been executed. Test Description : a) Send a PRACK from the peer towards the IUT with Desired-Status sdp as : a=des:qos unknown e2e send b) Verify that the PRACK is parsed successfully at the IUT. Minakshi & Srimanta [Page 175] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.19 Des_Sdp_V_19 : Desired-Status sdp as qos, none, local, recv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as none status-type as local direction tag as recv Reference : RFC3312, Section 4.2 Applicable Messages : BYE, CANCEL, INVITE, PRACK Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F10 of Call Flow 3 have been executed. Test Description : a) Send an UPDATE from the peer towards the IUT with Desired-Status sdp as : a=des:qos none local recv b) Verify that the UPDATE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.20 Des_Sdp_V_20 : Desired-Status sdp as qos, mandatory, local, recv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as mandatory status-type as local direction tag as recv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Minakshi & Srimanta [Page 176] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F20 of Call Flow 3 have been executed. Test Description : a) Send 200 (OK) response from the peer towards the IUT with Desired-Status sdp as : a=des:qos mandatory local recv b) Verify that 200 (OK) is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.21 Des_Sdp_V_21 : Desired-Status sdp as qos, optional, local, recv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as optional status-type as local direction tag as recv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Desired-Status sdp as : a=des:qos optional local recv b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- Minakshi & Srimanta [Page 177] Internet Draft SIP-IMS Compliance Test Plan August 2007 3.7.3.22 Des_Sdp_V_22 : Desired-Status sdp as qos, failure, local, recv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as failure status-type as local direction tag as recv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 580 response from the peer towards the IUT with Desired-Status sdp as : a=des:qos failure local recv b) Verify that the response is parsed successfully at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.23 Des_Sdp_V_23 : Desired-Status sdp as qos, unknown, local, recv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as unknown status-type as local direction tag as recv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F6 of Call Flow 3 have been executed. Test Description : Minakshi & Srimanta [Page 178] Internet Draft SIP-IMS Compliance Test Plan August 2007 a) Send a PRACK from the peer towards the IUT with Desired-Status sdp as : a=des:qos unknown local recv b) Verify that the PRACK is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.24 Des_Sdp_V_24 : Desired-Status sdp as qos, none, remote, recv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as none status-type as remote direction tag as recv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F10 of Call Flow 3 have been executed. Test Description : a) Send an UPDATE from the peer towards the IUT with Desired-Status sdp as : a=des:qos none remote recv b) Verify that the UPDATE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.25 Des_Sdp_V_25 : Desired-Status sdp as qos, mandatory, remote, recv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos Minakshi & Srimanta [Page 179] Internet Draft SIP-IMS Compliance Test Plan August 2007 strength-tag as mandatory status-type as remote direction tag as recv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F20 of Call Flow 3 have been executed. Test Description : a) Send 200 (OK) response from the peer towards the IUT with Desired-Status sdp as : a=des:qos mandatory remote recv b) Verify that 200 (OK) is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.26 Des_Sdp_V_26 : Desired-Status sdp as qos, optional, remote, recv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as optional status-type as remote direction tag as recv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Desired-Status sdp as : a=des:qos optional remote recv Minakshi & Srimanta [Page 180] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.27 Des_Sdp_V_27 : Desired-Status sdp as qos, failure, remote, recv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as failure status-type as remote direction tag as recv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 580 response from the peer towards the IUT with Desired-Status sdp as : a=des:qos failure remote recv b) Verify that the response is parsed successfully at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.28 Des_Sdp_V_28 : Desired-Status sdp as qos, unknown, remote, recv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as unknown status-type as remote direction tag as recv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Minakshi & Srimanta [Page 181] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F6 of Call Flow 3 have been executed. Test Description : a) Send a PRACK from the peer towards the IUT with Desired-Status sdp as : a=des:qos unknown remote recv b) Verify that the PRACK is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.29 Des_Sdp_V_29 : Desired-Status sdp as qos, none, e2e, recv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as none status-type as e2e direction tag as recv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F10 of Call Flow 3 have been executed. Test Description : a) Send an UPDATE from the peer towards the IUT with Desired-Status sdp as : a=des:qos none e2e recv b) Verify that the UPDATE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- Minakshi & Srimanta [Page 182] Internet Draft SIP-IMS Compliance Test Plan August 2007 3.7.3.30 Des_Sdp_V_30 : Desired-Status sdp as qos, mandatory, e2e, recv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as mandatory status-type as e2e direction tag as none Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F20 of Call Flow 3 have been executed. Test Description : a) Send 200 (OK) response from the peer towards the IUT with Desired-Status sdp as : a=des:qos mandatory e2e recv b) Verify that 200 (OK) is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.31 Des_Sdp_V_31 : Desired-Status sdp as qos, optional, e2e, recv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as optional status-type as e2e direction tag as recv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Minakshi & Srimanta [Page 183] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send an INVITE request from the peer towards the IUT with Desired-Status sdp as : a=des:qos optional e2e recv b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.32 Des_Sdp_V_32 : Desired-Status sdp as qos, failure, e2e, recv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as failure status-type as e2e direction tag as recv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 580 response from the peer towards the IUT with Desired-Status sdp as : a=des:qos failure e2e recv b) Verify that the response is parsed successfully at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.33 Des_Sdp_V_33 : Desired-Status sdp as qos, unknown, e2e, recv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos Minakshi & Srimanta [Page 184] Internet Draft SIP-IMS Compliance Test Plan August 2007 strength-tag as unknown status-type as e2e direction tag as recv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F6 of Call Flow 3 have been executed. Test Description : a) Send a PRACK from the peer towards the IUT with Desired-Status sdp as : a=des:qos unknown e2e recv b) Verify that the PRACK is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.34 Des_Sdp_V_34 : Desired-Status sdp as qos, none, local, sendrecv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as none status-type as local direction tag as sendrecv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F10 of Call Flow 3 have been executed. Test Description : a) Send an UPDATE from the peer towards the IUT with Desired-Status sdp as : Minakshi & Srimanta [Page 185] Internet Draft SIP-IMS Compliance Test Plan August 2007 a=des:qos none local sendrecv b) Verify that the UPDATE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.35 Des_Sdp_V_35 : Desired-Status sdp as qos, mandatory, local, sendrecv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as mandatory status-type as local direction tag as sendrecv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F20 of Call Flow 3 have been executed. Test Description : a) Send 200 (OK) response from the peer towards the IUT with Desired-Status sdp as : a=des:qos mandatory local sendrecv b) Verify that 200 (OK) is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.36 Des_Sdp_V_36 : Desired-Status sdp as qos, optional, local, sendrecv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as optional status-type as local direction tag as sendrecv Minakshi & Srimanta [Page 186] Internet Draft SIP-IMS Compliance Test Plan August 2007 Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Desired-Status sdp as : a=des:qos optional local sendrecv b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.37 Des_Sdp_V_37 : Desired-Status sdp as qos, failure, local, sendrecv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as failure status-type as local direction tag as sendrecv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 580 response from the peer towards the IUT with Desired-Status sdp as : a=des:qos failure local sendrecv Minakshi & Srimanta [Page 187] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that the response is parsed successfully at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.38 Des_Sdp_V_38 : Desired-Status sdp as qos, unknown, local, sendrecv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as unknown status-type as local direction tag as sendrecv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F6 of Call Flow 3 have been executed. Test Description : a) Send a PRACK from the peer towards the IUT with Desired-Status sdp as : a=des:qos unknown local sendrecv b) Verify that the PRACK is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.39 Des_Sdp_V_39 : Desired-Status sdp as qos, none, remote, sendrecv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as none status-type as remote direction tag as sendrecv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK Minakshi & Srimanta [Page 188] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F10 of Call Flow 3 have been executed. Test Description : a) Send an UPDATE from the peer towards the IUT with Desired-Status sdp as : a=des:qos none remote sendrecv b) Verify that the UPDATE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.40 Des_Sdp_V_40 : Desired-Status sdp as qos, mandatory, remote, sendrecv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as mandatory status-type as remote direction tag as sendrecv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F20 of Call Flow 3 have been executed. Test Description : a) Send 200 (OK) response from the peer towards the IUT with Desired-Status sdp as : a=des:qos mandatory remote sendrecv b) Verify that 200 (OK) is parsed successfully at the IUT. Minakshi & Srimanta [Page 189] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.41 Des_Sdp_V_41 : Desired-Status sdp as qos, optional, remote, sendrecv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as optional status-type as remote direction tag as sendrecv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Desired-Status sdp as : a=des:qos optional remote sendrecv b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.42 Des_Sdp_V_42 : Desired-Status sdp as qos, failure, remote, sendrecv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as failure status-type as remote direction tag as sendrecv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Minakshi & Srimanta [Page 190] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 580 response from the peer towards the IUT with Desired-Status sdp as : a=des:qos failure remote sendrecv b) Verify that the response is parsed successfully at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.43 Des_Sdp_V_43 : Desired-Status sdp as qos, unknown, remote, sendrecv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as unknown status-type as remote direction tag as sendrecv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F6 of Call Flow 3 have been executed. Test Description : a) Send a PRACK from the peer towards the IUT with Desired-Status sdp as : a=des:qos unknown remote sendrecv b) Verify that the PRACK is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- Minakshi & Srimanta [Page 191] Internet Draft SIP-IMS Compliance Test Plan August 2007 3.7.3.44 Des_Sdp_V_44 : Desired-Status sdp as qos, none, e2e, sendrecv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as none status-type as e2e direction tag as sendrecv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F10 of Call Flow 3 have been executed. Test Description : a) Send an UPDATE from the peer towards the IUT with Desired-Status sdp as : a=des:qos none e2e sendrecv b) Verify that the UPDATE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.45 Des_Sdp_V_45 : Desired-Status sdp as qos, mandatory, e2e, sendrecv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as mandatory status-type as e2e direction tag as none Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F20 of Call Flow 3 have been executed. Minakshi & Srimanta [Page 192] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send 200 (OK) response from the peer towards the IUT with Desired-Status sdp as : a=des:qos mandatory e2e sendrecv b) Verify that 200 (OK) is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.46 Des_Sdp_V_46 : Desired-Status sdp as qos, optional, e2e, sendrecv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as optional status-type as e2e direction tag as sendrecv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Desired-Status sdp as : a=des:qos optional e2e sendrecv b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- Minakshi & Srimanta [Page 193] Internet Draft SIP-IMS Compliance Test Plan August 2007 3.7.3.47 Des_Sdp_V_47 : Desired-Status sdp as qos, failure, e2e, sendrecv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as failure status-type as e2e direction tag as sendrecv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 580 response from the peer towards the IUT with Desired-Status sdp as : a=des:qos failure e2e sendrecv b) Verify that the response is parsed successfully at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.48 Des_Sdp_V_48 : Desired-Status sdp as qos, unknown, e2e, sendrecv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as qos strength-tag as unknown status-type as e2e direction tag as sendrecv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F6 of Call Flow 3 have been executed. Minakshi & Srimanta [Page 194] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a PRACK from the peer towards the IUT with Desired-Status sdp as : a=des:qos unknown e2e sendrecv b) Verify that the PRACK is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.49 Des_Sdp_V_49 : Desired-Status sdp as token, none, e2e, sendrecv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as token strength-tag as none status-type as e2e direction tag as sendrecv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F10 of Call Flow 3 have been executed. "conn" is defined as a precondition token in the IUT. Test Description : a) Send an UPDATE from the peer towards the IUT with Desired-Status sdp as : a=des:conn none e2e sendrecv b) Verify that the UPDATE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.50 Des_Sdp_V_50 : Desired-Status sdp as token, mandatory, e2e, sendrecv Minakshi & Srimanta [Page 195] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as token strength-tag as mandatory status-type as e2e direction tag as none Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F20 of Call Flow 3 have been executed. "conn" is defined as a precondition token in the IUT. Test Description : a) Send 200 (OK) response from the peer towards the IUT with Desired-Status sdp as : a=des:conn mandatory e2e sendrecv b) Verify that 200 (OK) is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.51 Des_Sdp_V_51 : Desired-Status sdp as token, optional, e2e, sendrecv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as token strength-tag as optional status-type as e2e direction tag as sendrecv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. "conn" is defined as a precondition token in the IUT. Test Description : Minakshi & Srimanta [Page 196] Internet Draft SIP-IMS Compliance Test Plan August 2007 a) Send an INVITE request from the peer towards the IUT with Desired-Status sdp as : a=des:conn optional e2e sendrecv b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.52 Des_Sdp_V_52 : Desired-Status sdp as token, failure, e2e, sendrecv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as token strength-tag as failure status-type as e2e direction tag as sendrecv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. "conn" is defined as a precondition token in the IUT. Test Description : a) Send a 580 response from the peer towards the IUT with Desired-Status sdp as : a=des:conn failure e2e sendrecv b) Verify that the response is parsed successfully at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.53 Des_Sdp_V_53 : Desired-Status sdp as token, unknown, e2e, sendrecv Test Objective : To verify the parsing of Desired-Status sdp parameter with following tag values : precondition-type as token strength-tag as unknown Minakshi & Srimanta [Page 197] Internet Draft SIP-IMS Compliance Test Plan August 2007 status-type as e2e direction tag as sendrecv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F6 of Call Flow 3 have been executed. "conn" is defined as a precondition token in the IUT. Test Description : a) Send a PRACK from the peer towards the IUT with Desired-Status sdp as : a=des:conn unknown e2e sendrecv b) Verify that the PRACK is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.54 Des_Sdp_I_54 : Desired-status sdp without the strength-tag Test Objective : To validate that the IUT discards the desired-status sdp received as : precondition-type as qos status-type as remote direction tag as none Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, INVITE, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 183 response from the peer towards the IUT with desired-status sdp as : a=des:qos remote none Minakshi & Srimanta [Page 198] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that the sdp parsing fails at the IUT and the sdp is discarded. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.3.55 Des_Sdp_I_55 : Desired-status sdp with undefined value of the strength-tag Test Objective : To validate that the IUT returns an error on receipt of the desired-status sdp as : precondition-type as qos strength-tag as sendrecv status-type as e2e direction tag as sendrecv Reference : RFC3312, Section 4 Applicable Messages : BYE, CANCEL, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with desired-status sdp as : a=des:qos sendrecv e2e sendrecv b) Verify that the INVITE is parsed successfully at the IUT. b) Verify that the sdp parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- 3.7.4 Generic Cases --------------------------------------------------------------------- 3.7.4.1 Gen_Res_Mgmt_I_01 : Two Desired-status sdp lines with the strength-tag as mandatory and status-type as remote Test Objective : To verify IUT behavior of parsing of the sdp when it comprises of two lines of desired status parameter one with direction tag as send and other as recv, both having strength tag as optional and status-type as remote. Reference : RFC3312, Section 5.1.1 Applicable Messages : BYE, CANCEL, PRACK, UPDATE Minakshi & Srimanta [Page 199] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with desired-status sdp as : a=des:qos mandatory remote send a=des:qos mandatory remote recv b) Verify that the sdp parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.4.2 Gen_Res_Mgmt_I_02 : Two Desired-status sdp lines with the strength-tag as optional and status-type as e2e Test Objective : Validate the IUT behavior when it receives two lines of desired status parameter one with direction tag as send and other as recv, both having strength tag as mandatory and status-type as e2e. Reference : RFC3312, Section 5.1.1 Applicable Messages : BYE, CANCEL, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with desired-status sdp as : a=des:qos optional e2e send a=des:qos optional e2e recv b) Verify that the sdp parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.4.3 Gen_Res_Mgmt_V_03 : Two Desired-status sdp lines with the strength-tag as unknown and status-type as local Minakshi & Srimanta [Page 200] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective : Validate the IUT behavior when it receives two lines of desired status parameter one with direction tag as send and other as recv, both having strength tag as unknown and status-type as local. Reference : RFC3312, Section 5.1.1 Applicable Messages : BYE, CANCEL, INVITE, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F6 of Call Flow 3 have been executed. Test Description : a) Send a PRACK from the peer towards the IUT with Desired-Status sdp as : a=des:qos unknown local send a=des:qos unknown local recv b) Verify that the PRACK is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.4.4 Gen_Res_Mgmt_V_04 : 580 Precondition Failure response to INVITE Test Objective : Validate that the IUT successfully parses the 580 Precondition Failure response to an INVITE request. Reference : RFC3312, Section 8 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 580 response from the peer towards the IUT with Desired-Status sdp as : a=des:qos failure remote send Minakshi & Srimanta [Page 201] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that the response is parsed successfully at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.4.5 Gen_Res_Mgmt_V_05 : 580 Precondition Failure to an UPDATE request Test Objective : To check the parsing of 580 Precondition Failure response to an UPDATE request. Reference : RFC3312, Section 8 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F12 of Call Flow 3 have been executed. Test Description : a) Send a 580 Precondition Failure response from the peer towards the IUT with desired-status sdp as : m=audio 20000 RTP/AVP 0 a=des:qos failure remote send b) Verify that the response is parsed successfully at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.4.6 Gen_Res_Mgmt_I_06 : BYE indicating Precondition Failure Test Objective : To validate the IUT behavior when it receives BYE indicating precondition failure with number of m lines greater than that received in the previous sdp. Reference : RFC3312, Section 8 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F22 of Call Flow 3 have been executed. Test Description : a) Send a BYE from the peer towards the IUT with desired-status sdp, indicating precondition failure, having m lines greater than that received in earlier sdp. Minakshi & Srimanta [Page 202] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that the BYE sdp parsing fails at the IUT. c) Call is released. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.4.7 Gen_Res_Mgmt_V_07 : Number of m lines less than in previous sdp Test Objective : To validate the IUT behavior when it receives 580 Precondition Failure response with number of m lines less than that in the last sdp sent towards the peer. Reference : RFC3312, Section 8 Applicable Messages : BYE, UPDATE, CANCEL, INVITE, PRACK Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F12 of Call Flow 3 have been executed. Test Description : a) Send a 580 response from the peer towards the IUT with desired-status sdp having m lines, less than received in earlier sdp. b) Verify that the 580 parsing fails at the IUT. c) Call is released. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.4.8 Gen_Res_Mgmt_I_08 : CANCEL indicating Precondition Failure Test Objective : To validate the IUT behavior when it receives CANCEL indicating precondition failure with number of m not equal to (less/greater) than that received in the previous sdp. Reference : RFC3312, Section 8 Applicable Messages : BYE, UPDATE, INVITE, PRACK Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F6 of Call Flow 3 have been executed. Minakshi & Srimanta [Page 203] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a CANCEL from the peer towards the IUT with desired-status sdp having m lines less than received in earlier sdp. b) Verify that the CANCEL parsing fails at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.4.9 Gen_Res_Mgmt_V_09 : Media Stream Port of Rejected precondition Test Objective : To verify that the IUT successfully parses port value of zero of the precondition that triggered the failure of a desired-status sdp parameter. Reference : RFC3312, Section 8 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F6 of Call Flow 3 have been executed. Test Description : a) Send a CANCEL from the peer towards the IUT with desired-status sdp having m and a lines as : m=audio 20000 RTP/AVP 0 a=des:qos failure e2e send b) Verify that the CANCEL is successfully parsed at the IUT and the Call is released. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.4.10 Gen_Res_Mgmt_V_10 : INVITE with Require header as precondition Test Objective : To verify the parsing of Require header in an INVITE Request with option tag "precondition". Reference : RFC3312, Section 11 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Minakshi & Srimanta [Page 204] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send an INVITE request from the peer towards the IUT with Require header as : Require: precondition b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.4.11 Gen_Res_Mgmt_V_11 : Require header as "precondition" in response Test Objective : Validate that the provisional response with a Require header set as precondition is successfully parsed at the IUT. Reference : RFC3312, Section 11 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Steps F1 to F4 of Call Flow 3 have been executed. Test Description : a) Send a 183 response from the peer towards the IUT with Require header as : Require: precondition b) Verify that the response is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.4.12 Gen_Res_Mgmt_V_12 : Supported header with tag as precondition Test Objective : To verify the parsing of Supported header in an INVITE Request with option tag "precondition". Reference : RFC3312, Section 11 Minakshi & Srimanta [Page 205] Internet Draft SIP-IMS Compliance Test Plan August 2007 Applicable Messages : BYE, CANCEL, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Supported header as : Supported: precondition b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.4.13 Gen_Res_Mgmt_V_13 : OPTIONS response with tag as precondition Test Objective : Validate that OPTIONS response with a Supported header set as "precondition" is successfully parsed at the IUT. Reference : RFC3312, Section 11 Applicable Messages : BYE, CANCEL, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. OPTIONS Request is sent from IUT towards the peer. Test Description : a) Send the response to OPTIONS from the peer with Supported header as : Supported: precondition b) Verify that the OPTIONS is parsed successfully at the IUT and 200 response is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- Minakshi & Srimanta [Page 206] Internet Draft SIP-IMS Compliance Test Plan August 2007 3.7.4.14 Gen_Res_Mgmt_V_14 : INVITE with Require, Supported and Allow header as required for the precondition support Test Objective : To verify successful parsing of an INVITE request with precondition in Require header and Allow header containing the UPDATE and Supported header containing the 100rel tag. Reference : RFC3312, Section 11 Applicable Messages : BYE, CANCEL, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Supported, Require and Allow headers as : Require: precondition Supported: 100rel Allow: CANCEL, UPDATE, PRACK, BYE, INFO, OPTIONS b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.4.15 Gen_Res_Mgmt_V_15 : Offer Request with Require and Allow headers as required for the precondition support Test Objective : To verify that the IUT successfully parses an offer request with Require header containing option tags as precondition, 100rel and Allow header containing UPDATE as one of the method. Reference : RFC3312, Section 11 Applicable Messages : BYE, CANCEL, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Supported, Require and Allow headers as : Minakshi & Srimanta [Page 207] Internet Draft SIP-IMS Compliance Test Plan August 2007 Require: 100rel, precondition Allow: CANCEL, UPDATE, PRACK, BYE, INFO, OPTIONS b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.4.16 Gen_Res_Mgmt_I_16 : Mandatory strength tag in local sdp but no indication of precondition support Test Objective : To check that the IUT returns an error on receipt of mandatory strength tag in desired status local sdp but no Require/Supported flag for precondition. Reference : RFC3312, Section 11 Applicable Messages : BYE, CANCEL, PRACK, UPDATE Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with desired-status sdp as : a=des:qos mandatory local sendrecv and no precondition tag in either supported or require headers. b) Verify that the INVITE parsing fails at the IUT. c) Error response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.4.17 Gen_Res_Mgmt_I_17 : Require header with precondition but no support of PRACK Test Objective : Verify that the IUT responds with an error when it receives precondition in the require header but without 100rel tag in supported/require header. Reference : RFC3312, Section 11 Applicable Messages : Not Applicable Minakshi & Srimanta [Page 208] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Require header as : Require: precondition and no 100rel option tag in either supported or require header. b) Verify that the INVITE parsing fails at the IUT. c) Error response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.4.18 Gen_Res_Mgmt_I_18 : Require header with precondition but UPDATE not listed in Allow Header Test Objective : To verify that an error response is returned on receipt of precondition in the require header but UPDATE not listed in the Allow header. Reference : RFC3312, Section 11 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Require and Allow headers as : Require: precondition, 100rel Allow: BYE, CANCEL, PRACK, INVITE, INFO, OPTIONS b) Verify that the INVITE parsing fails at the IUT. c) Error response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.4.19 Gen_Res_Mgmt_I_19 : Mandatory strength tag in remote sdp but no indication of precondition support Minakshi & Srimanta [Page 209] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective : To check that the IUT returns an error on receipt of mandatory strength tag in desired status remote sdp but no Require/Supported flag for precondition. Reference : RFC3312, Section 11 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with desired-status sdp as : a=des:qos mandatory remote sendrecv and no precondition tag in either supported or require headers. b) Verify that the INVITE parsing fails at the IUT. c) Error response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.7.4.20 Gen_Res_Mgmt_I_20 : Optional strength tag in remote sdp but no indication of precondition support Test Objective : To check that the IUT returns an error on receipt of optional/none strength tag in desired status remote sdp but no Supported flag for precondition. Reference : RFC3312, Section 11 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Integration of Resource Management with SIP [10] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with desired-status sdp as : a=des:qos optional remote sendrecv and no precondition tag in either supported or require headers. Minakshi & Srimanta [Page 210] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that the INVITE parsing fails at the IUT. c) Error response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8 Caller Preferences for SIP Accept-Contact, Reject-Contact, and Request-Disposition headers have been introduced in the SIP protocol suite to enable the Caller to convey its preferences in terms of the request routing and handling at intermediaries. 3.8.1 Request-Disposition Header Cases --------------------------------------------------------------------- 3.8.1.1 Req_Disp_Hdr_V_01 : Proxy-Require Header field with value "pref" Test Objective : To verify parsing of Proxy-Require header with option tag as "pref". Reference : RFC3841, Section 5 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] User is registered with single contact. Test Description : a) Send an INVITE request from the peer towards the IUT with Proxy-Require Header as : Proxy-Require: pref b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.1.2 Req_Disp_Hdr_V_02 : 420(Bad Extension) response to INVITE Test Objective : To check that the IUT successfully parses Unsupported header with tag "pref" received in 420 Bad Extension response. Minakshi & Srimanta [Page 211] Internet Draft SIP-IMS Compliance Test Plan August 2007 Reference : RFC3841, Section 5 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Caller Preferences for SIP [12] User is registered with single contact. Steps F1 to F3 of Call Flow 3 have been executed. Test Description : a) Send a 420 response to INVITE from the peer with Unsupported Header as : Unsupported: pref b) Verify that the response is successfully parsed at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.1.3 Req_Disp_Hdr_V_03 : Directive set as proxy Test Objective : To validate the parsing of Request-Disposition header with a single directive set to proxy. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, INVITE, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] Test Description : a) Send an OPTIONS request from the peer towards the IUT with Request-Disposition Header as : Request-Disposition: proxy b) Verify that the OPTIONS is successfully parsed at the IUT and successful response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.1.4 Req_Disp_Hdr_V_04 : Directive set as redirect Test Objective : Verify the successful parsing of Request-Disposition header with Proxy-directive as redirect. Reference : RFC3841, Section 10 Minakshi & Srimanta [Page 212] Internet Draft SIP-IMS Compliance Test Plan August 2007 Applicable Messages : ACK, BYE, CANCEL, INVITE, SUBSCRIBE, OPTIONS, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] User is registered with single contact. Test Description : a) Send a MESSAGE request from the peer towards the IUT with Request-Disposition Header as : d: redirect b) Verify that the MESSAGE is successfully parsed at the IUT and 200(OK) response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.1.5 Req_Disp_Hdr_V_05 : Directive set as cancel Test Objective : To verify that the IUT successfully parses the Request-Disposition header with value as cancel. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, MESSAGE, SUBSCRIBE, OPTIONS, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] User is registered with single contact. Test Description : a) Send an INVITE request from the peer towards the IUT with Request-Disposition Header as : Request-Disposition: cancel b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.1.6 Req_Disp_Hdr_V_06 : Directive set as no-cancel Test Objective : Validate the parsing of Request-Disposition header containing a cancel-directive value set to no-cancel. Minakshi & Srimanta [Page 213] Internet Draft SIP-IMS Compliance Test Plan August 2007 Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, MESSAGE, SUBSCRIBE, OPTIONS, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] User is registered with single contact. Test Description : a) Send an INVITE request from the peer towards the IUT with Request-Disposition Header as : d: no-cancel b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.1.7 Req_Disp_Hdr_V_07 : Directive set as fork Test Objective : Check that the fork-directive with value fork in the Request-Disposition header is successfully parsed at the IUT. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, MESSAGE, SUBSCRIBE, OPTIONS, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] User is registered with single contact. Test Description : a) Send an INVITE request from the peer towards the IUT with Request-Disposition Header as : Request-Disposition: fork b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- Minakshi & Srimanta [Page 214] Internet Draft SIP-IMS Compliance Test Plan August 2007 3.8.1.8 Req_Disp_Hdr_V_08 : Directive set as no-fork Test Objective : Verify the successful parsing of Request-Disposition header containing fork-directive with value no-fork. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, MESSAGE, SUBSCRIBE, OPTIONS, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] User is registered with single contact. Test Description : a) Send an INVITE request from the peer towards the IUT with Request-Disposition Header as : d: no-fork b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.1.9 Req_Disp_Hdr_V_09 : Directive set as no-recurse Test Objective : To validate the parsing of recurse-directive in Request-Disposition header with value set to no-recurse. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, MESSAGE, SUBSCRIBE, OPTIONS, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] User is registered with single contact. Test Description : a) Send an INVITE request from the peer towards the IUT with Request-Disposition Header as : Request-Disposition: no-recurse b) Verify that the INVITE is parsed successfully at the IUT. Minakshi & Srimanta [Page 215] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.1.10 Req_Disp_Hdr_V_10 : Directive set as recurse Test Objective : Verify the successful parsing of Request-Disposition header with recurse-directive as recurse. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, MESSAGE, SUBSCRIBE, OPTIONS, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] User is registered with single contact. Test Description : a) Send an INVITE request from the peer towards the IUT with Request-Disposition Header as : d: recurse b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.1.11 Req_Disp_Hdr_V_11 : Directive set as sequential Test Objective : Check that the parallel-directive with value sequential in the Request-Disposition header is successfully parsed at the IUT. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, MESSAGE, SUBSCRIBE, OPTIONS, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] User is registered with single contact. Minakshi & Srimanta [Page 216] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send an INVITE request from the peer towards the IUT with Request-Disposition Header as : Request-Disposition: sequential b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.1.12 Req_Disp_Hdr_V_12 : Directive set as parallel Test Objective : To validate the parsing of parallel-directive in Request-Disposition header with value set to parallel. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, MESSAGE, SUBSCRIBE, OPTIONS, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] User is registered with single contact. Test Description : a) Send an INVITE request from the peer towards the IUT with Request-Disposition Header as : d: parallel b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.1.13 Req_Disp_Hdr_V_13 : Directive set as queue Test Objective : To verify that the IUT successfully parses the Request-Disposition header with value as queue. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, MESSAGE, SUBSCRIBE, OPTIONS, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Minakshi & Srimanta [Page 217] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Caller Preferences for SIP [12] User is registered with single contact. Test Description : a) Send an INVITE request from the peer towards the IUT with Request-Disposition Header as : Request-Disposition: queue b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.1.14 Req_Disp_Hdr_V_14 : Directive set as no-queue Test Objective : Validate the parsing of Request-Disposition header containing a queue-directive value set to no-queue. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, MESSAGE, SUBSCRIBE, OPTIONS, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] User is registered with single contact. Test Description : a) Send an INVITE request from the peer towards the IUT with Request-Disposition Header as : d: no-queue b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- Minakshi & Srimanta [Page 218] Internet Draft SIP-IMS Compliance Test Plan August 2007 3.8.1.15 Req_Disp_Hdr_V_15 : Request-Disposition header with two directives Test Objective : To verify that the IUT successfully parses the Request-Disposition header containing two directives. (Eg: proxy, parallel). Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, MESSAGE, SUBSCRIBE, OPTIONS, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] User is registered with single contact. Test Description : a) Send an INVITE request from the peer towards the IUT with Request-Disposition Header as : d: proxy, parallel b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.1.16 Req_Disp_Hdr_V_16 : Request-Disposition header with multiple directives Test Objective : To verify the successful parsing of multiple (four) directives in the Request-Disposition header. (Eg: proxy, recurse, parallel, no-queue). Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, MESSAGE, SUBSCRIBE, OPTIONS, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] User is registered with single contact. Test Description : a) Send an INVITE request from the peer towards the IUT with Request-Disposition Header as : Minakshi & Srimanta [Page 219] Internet Draft SIP-IMS Compliance Test Plan August 2007 Request-Disposition: proxy, recurse, parallel, no-queue b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.1.17 Req_Disp_Hdr_I_17 : Incompatible preference directives - redirect and no-recurse Test Objective : To verify the IUT successfully parses the Request-Disposition header when it receives incompatible preference directives no-recurse and redirect. Reference : RFC3841, Section 9.1 Applicable Messages : ACK, BYE, CANCEL, MESSAGE, SUBSCRIBE, OPTIONS, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] User is registered with single contact. Test Description : a) Send an INVITE request from the peer towards the IUT with Request-Disposition Header as : Request-Disposition: no-recurse, redirect b) Verify that the no-recurse directive is ignored by the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.1.18 Req_Disp_Hdr_I_18 : Incompatible preference directives - redirect and fork Test Objective : To verify the IUT successfully parses the Request-Disposition header when it receives incompatible preference directives fork and redirect. Reference : RFC3841, Section 9.1 Applicable Messages : ACK, BYE, CANCEL, MESSAGE, SUBSCRIBE, OPTIONS, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Minakshi & Srimanta [Page 220] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Caller Preferences for SIP [12] User is registered with single contact. Test Description : a) Send an INVITE request from the peer towards the IUT with Request-Disposition Header as : d: fork, redirect b) Verify that the fork directive is ignored by the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.1.19 Req_Disp_Hdr_I_19 : Incompatible preference directives - redirect and recurse Test Objective : To verify the IUT successfully parses the Request-Disposition header when it receives incompatible preference directives recurse and redirect. Reference : RFC3841, Section 9.1 Applicable Messages : ACK, BYE, CANCEL, MESSAGE, SUBSCRIBE, OPTIONS, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] User is registered with single contact. Test Description : a) Send an INVITE request from the peer towards the IUT with Request-Disposition Header as : Request-Disposition: recurse, redirect b) Verify that the recurse directive is ignored by the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.1.20 Req_Disp_Hdr_I_20 : Incompatible preference directives - redirect and no-fork Minakshi & Srimanta [Page 221] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective : To verify the IUT successfully parses the Request-Disposition header when it receives incompatible preference directives no-fork and redirect. Reference : RFC3841, Section 9.1 Applicable Messages : ACK, BYE, CANCEL, MESSAGE, SUBSCRIBE, OPTIONS, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] User is registered with single contact. Test Description : a) Send an INVITE request from the peer towards the IUT with Request-Disposition Header as : d: no-fork, redirect b) Verify that the no-fork directive is ignored by the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.1.21 Req_Disp_Hdr_I_21 : Incompatible preference directives - redirect and parallel Test Objective : To verify the IUT successfully parses the Request-Disposition header when it receives incompatible preference directives parallel and redirect. Reference : RFC3841, Section 9.1 Applicable Messages : ACK, BYE, CANCEL, MESSAGE, SUBSCRIBE, OPTIONS, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] User is registered with single contact. Test Description : a) Send an INVITE request from the peer towards the IUT with Request-Disposition Header as : Request-Disposition: parallel, redirect b) Verify that the parallel directive is ignored by the IUT. Minakshi & Srimanta [Page 222] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.1.22 Req_Disp_Hdr_I_22 : Incompatible preference directives - redirect and sequential Test Objective : To verify the IUT successfully parses the Request-Disposition header when it receives incompatible preference directives sequential and redirect. Reference : RFC3841, Section 9.1 Applicable Messages : ACK, BYE, CANCEL, MESSAGE, SUBSCRIBE, OPTIONS, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] User is registered with single contact. Test Description : a) Send an INVITE request from the peer towards the IUT with Request-Disposition Header as : d: redirect, sequential b) Verify that the sequential directive is ignored by the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.1.23 Req_Disp_Hdr_V_23 : 182 "Request Queued" response Test Objective : To verify the successful parsing of "182 Request Queued" response to an INVITE request. Reference : RFC3841, Section 9.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports Caller Preferences for SIP [12] User is registered with single contact. Steps F1 to F4 of Call Flow 3 have been executed. Minakshi & Srimanta [Page 223] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a 182 Request Queued response from the peer. b) Verify that the response is successfully parsed at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.1.24 Req_Disp_Hdr_I_24 : Request-Disposition header with two directives of same type Test Objective : To validate that an error response is returned by the IUT when it receives a Request-Disposition header with two directives of same type. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, MESSAGE, SUBSCRIBE, OPTIONS, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] User is registered with single contact. Test Description : a) Send an INVITE request from the peer towards the IUT with Request-Disposition Header as : d: redirect, proxy b) Verify that the header parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.1.25 Req_Disp_Hdr_I_25 : Unknown directive in the Request-Disposition Header Test Objective : To check that the ITU responds with an error on receipt of unknown directive in the Request-Disposition Header. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, MESSAGE, SUBSCRIBE, OPTIONS, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Minakshi & Srimanta [Page 224] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Caller Preferences for SIP [12] User is registered with single contact. Test Description : a) Send an INVITE request from the peer towards the IUT with Request-Disposition Header as : d: defer b) Verify that the header parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.1.26 Req_Disp_Hdr_I_26 : Request-Disposition Header with invalid syntax Test Objective : To verify that ITU returns an error when it receives Request-Disposition header with multiple directives separated by semi-colon instead of comma. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, MESSAGE, SUBSCRIBE, OPTIONS, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] User is registered with single contact. Test Description : a) Send an INVITE request from the peer towards the IUT with Request-Disposition Header as : d: proxy ;recurse; parallel b) Verify that the header parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- 3.8.2 Feature-Param Cases --------------------------------------------------------------------- 3.8.2.1 Fea_Para_V_01 : Feature-param of type audio Test Objective : To verify the parsing of feature-param when the enc-feature-tag is set to audio. Minakshi & Srimanta [Page 225] Internet Draft SIP-IMS Compliance Test Plan August 2007 Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Contact Header as : Contact: ;audio b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.2 Fea_Para_V_02 : Feature-param of type video Test Objective : To verify the parsing of feature-param when the enc-feature-tag is set to video. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Steps F1 to F22 of Call Flow 3 have been executed. Test Description : a) Send ACK to 200 (OK) response from the peer Contact Header as : Contact: ;video b) Verify that the ACK is successfully parsed at the IUT. Minakshi & Srimanta [Page 226] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.3 Fea_Para_V_03 : Feature-param of type automata Test Objective : To verify the parsing of feature-param when the enc-feature-tag is set to automata. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] Test Description : a) Send a REGISTER request from the peer towards the IUT with Contact Header as : Contact: ;automata b) Verify that the OPTIONS is successfully parsed at the IUT and successful response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.4 Fea_Para_V_04 : Feature-param of type class Test Objective : To verify the parsing of feature-param when the enc-feature-tag is set to class. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send a MESSAGE request from the peer towards the IUT with Accept-Contact Header as : Minakshi & Srimanta [Page 227] Internet Draft SIP-IMS Compliance Test Plan August 2007 Accept-Contact: *;class="business" b) Verify that the MESSAGE is successfully parsed at the IUT and 200(OK) response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.5 Fea_Para_V_05 : Feature-param of type duplex Test Objective : To verify the parsing of feature-param when the enc-feature-tag is set to duplex. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Contact Header as : Contact: ;duplex="receive-only" b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.6 Fea_Para_V_06 : Feature-param of type data Test Objective : To verify the parsing of feature-param when the enc-feature-tag is set to data. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Steps F1 to F22 of Call Flow 3 have been executed. Minakshi & Srimanta [Page 228] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send ACK to 200 (OK) response from the peer Contact Header as : Contact: ;data b) Verify that the ACK is successfully parsed at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.7 Fea_Para_V_07 : Feature-param of type control Test Objective : To verify the parsing of feature-param when the enc-feature-tag is set to control. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] Test Description : a) Send a REGISTER request from the peer towards the IUT with Contact Header as : Contact: ;control b) Verify that the OPTIONS is successfully parsed at the IUT and successful response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.8 Fea_Para_V_08 : Feature-param of type mobility Test Objective : To verify the parsing of feature-param when the enc-feature-tag is set to mobility. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Minakshi & Srimanta [Page 229] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send a MESSAGE request from the peer towards the IUT with Accept-Contact Header as : Accept-Contact: ;mobility="fixed" b) Verify that the MESSAGE is successfully parsed at the IUT and 200(OK) response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.9 Fea_Para_V_09 : Feature-param of type description Test Objective : To verify the parsing of feature-param when the enc-feature-tag is set to description. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Contact Header as : Contact: ;description="" b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.10 Fea_Para_V_10 : Feature-param of type methods Test Objective : To verify the parsing of feature-param when the enc-feature-tag is set to methods. Minakshi & Srimanta [Page 230] Internet Draft SIP-IMS Compliance Test Plan August 2007 Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] Test Description : a) Send a REGISTER request from the peer towards the IUT with Contact Header as : Contact: ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" b) Verify that the REGISTER is parsed successfully at the IUT. c) Validate the normal REGISTER procedure execution as per Flow 1. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.11 Fea_Para_V_11 : Feature-param of type priority Test Objective : To verify the parsing of feature-param when the enc-feature-tag is set to priority. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Reject-Contact Header as : Reject-Contact: *;priority="10" b) Verify that the INVITE is parsed successfully at the IUT. Minakshi & Srimanta [Page 231] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.12 Fea_Para_V_12 : Feature-param of type schemes Test Objective : To verify the parsing of feature-param when the enc-feature-tag is set to schemes. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Accept-Contact Header as : Accept-Contact: *;schemes="sip,sips" b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.13 Fea_Para_V_13 : Feature-param of type language Test Objective : To verify the parsing of feature-param when the enc-feature-tag is set to language. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] Minakshi & Srimanta [Page 232] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a REGISTER request from the peer towards the IUT with Contact Header as : Contact: ;language="en,de" b) Verify that the REGISTER is parsed successfully at the IUT. c) Validate the normal REGISTER procedure execution as per Flow 1. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.14 Fea_Para_V_14 : Feature-param of type events Test Objective : To verify the parsing of feature-param when the enc-feature-tag is set to events. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Accept-Contact Header as : Accept-Contact:*;events="presence,message-summary" b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.15 Fea_Para_V_15 : Feature-param of type application Test Objective : To verify the parsing of feature-param when the enc-feature-tag is set to application. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Minakshi & Srimanta [Page 233] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Contact Header as : Contact: ;application b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.16 Fea_Para_V_16 : Feature-param of type actor Test Objective : To verify the parsing of feature-param when the enc-feature-tag is set to actor. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] Test Description : a) Send a REGISTER request from the peer towards the IUT with Contact Header as : Contact: ;actor="msg-taker" b) Verify that the REGISTER is parsed successfully at the IUT. c) Validate the normal REGISTER procedure execution as per Flow 1. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.17 Fea_Para_V_17 : Feature-param of type text Test Objective : To verify the parsing of feature-param when the enc-feature-tag is set to text. Minakshi & Srimanta [Page 234] Internet Draft SIP-IMS Compliance Test Plan August 2007 Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] Test Description : a) Send a REGISTER request from the peer towards the IUT with Contact Header as : Contact: ;text b) Verify that the REGISTER is parsed successfully at the IUT. c) Validate the normal REGISTER procedure execution as per Flow 1. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.18 Fea_Para_V_18 : Feature-param of type isfocus Test Objective : To verify the parsing of feature-param when the enc-feature-tag is set to isfocus. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered at the IUT. Steps F1 to F21 of Call Flow 3 have been executed Test Description : a) Send a 200 (OK) from the peer towards the IUT with Contact Header as : Contact: ;isfocus b) Verify that the 200 (OK) is parsed successfully at the IUT. Minakshi & Srimanta [Page 235] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.19 Fea_Para_V_19 : Feature-param of other-type as +rangeparam Test Objective : To verify the parsing of feature-param when the enc-feature-tag is set to other-tag. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, INVITE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered at the IUT. Steps F1 to F10 of Call Flow 3 have been executed Test Description : a) Send an UPDATE from the peer towards the IUT with Contact Header as : Contact: ;+rangeparam="#-4:+5.125" b) Verify that the UPDATE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.20 Fea_Para_V_20 : Feature-param of other-type as +duration Test Objective : To verify the parsing of feature-param when the enc-feature-tag is set to other-tag. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, UPDATE, INVITE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered at the IUT. Steps F1 to F16 of Call Flow 3 have been executed Minakshi & Srimanta [Page 236] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a PRACK from the peer towards the IUT with Contact Header as : Contact: ;+duration="seconds" b) Verify that the UPDATE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.21 Fea_Para_V_21 : Feature-param with Ringing-value Test Objective : Check that the IUT successfully parses the feature-param containing a Ringing-value. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Contact Header as : Contact: ;duplex="full" b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.22 Fea_Para_V_22 : Feature-param with tag-value-list Test Objective : Check that the IUT successfully parses the feature-param containing a tag-value list. Reference : RFC3840, Section 9 Minakshi & Srimanta [Page 237] Internet Draft SIP-IMS Compliance Test Plan August 2007 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with feature-param in Accept-Contact header as a tag-value list. b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.23 Fea_Para_V_23 : Feature-param with a single boolean tag-value Test Objective : To check Feature-param parsing in the feature param containing a single boolean tag value. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with feature-param in Contact header as a boolean tag-value. b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- Minakshi & Srimanta [Page 238] Internet Draft SIP-IMS Compliance Test Plan August 2007 3.8.2.24 Fea_Para_V_24 : Feature-param with a single numeric tag-value Test Objective : To check Feature-param parsing in the feature param containing a single numeric tag value. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with feature-param in Reject-Contact header as a numeric tag-value. b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.25 Fea_Para_V_25 : Feature-param with a single tag-value of type token-nobang Test Objective : To check Feature-param parsing in the feature param containing a single tag value of type token-nobang. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with feature-param in Reject-Contact header as a token-nobang tag-value. b) Verify that the INVITE is parsed successfully at the IUT. Minakshi & Srimanta [Page 239] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.26 Fea_Para_V_26 : Feature-param with multiple tag-values of numeric type Test Objective : To validate the parsing of feature-param with the tag-value list consisting of multiple numeric values. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with feature-param with the tag-value list consisting of multiple numeric values. b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.27 Fea_Para_V_27 : Feature-param with multiple boolean values Test Objective : To verify that the IUT successfully parses the tag-value-list in the feature param consisting of multiple boolean values. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : Minakshi & Srimanta [Page 240] Internet Draft SIP-IMS Compliance Test Plan August 2007 a) Send an INVITE request from the peer towards the IUT with feature-param with the tag-value list consisting of multiple boolean values. b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.28 Fea_Para_V_28 : Feature-param with multiple token-nobang Test Objective : To verify that the IUT successfully parses the tag-value-list in the feature param consisting of multiple token-nobang values. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with feature-param with the tag-value list consisting of multiple token-nobang values. b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.29 Fea_Para_V_29 : Tag-value-list consisting of a multiple tag values of different type Test Objective : To verify the parsing of feature-param containing a single value each of type numeric,token-nobang and boolean. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Minakshi & Srimanta [Page 241] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with feature-param containing a single value each of type numeric, token-nobang and boolean. b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.30 Fea_Para_V_30 : Multiple tag values of mixed type with some types repeated Test Objective : To verify that the IUT successfully parses the tag-value-list consisting of a multiple tag values of mixed type (either boolean, numeric or token-nobang) with some types repeated. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with feature-param consisting of a multiple tag values of mixed type (either boolean, numeric or token-nobang) with some types repeated. Contact: ;audio;video ;mobility="fixed";events="!presence,message-summary" ;language="en,de";description="" b) Verify that the INVITE is parsed successfully at the IUT. Minakshi & Srimanta [Page 242] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.31 Fea_Para_V_31 : Tag-value with negation Test Objective : To verify the parsing of a tag-value with negation in feature param. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with negation in feature-param Contact: ;events="!presence" b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.32 Fea_Para_I_32 : Feature-param with invalid syntax Test Objective : To verify the IUT behavior when it receives other-tags param without the preceding"+" in the feature param. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Minakshi & Srimanta [Page 243] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send an INVITE request from the peer towards the IUT with Contact header as : Contact: ;duration="6000" b) Verify that the duration feature-param parsing fails and is ignored while processing the INVITE request at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.2.33 Fea_Para_I_33 : Feature param with more than one feature tag Test Objective : To validate the IUT behavior when it receives a feature-param with two instances of the enc-feature-tag. Reference : RFC3840, Section 9 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, REGISTER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Accept-Contact header as : Accept-Contact: ;duplex;class="personal" b) Verify that the Accept-Contact header parsing fails and is ignored while processing the INVITE request at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- 3.8.3 Accept-Contact and Reject-Contact Header Cases --------------------------------------------------------------------- 3.8.3.1 Acc_Rej_Hdr_V_01 : Ac-value of type feature-param Test Objective : To verify the parsing of accept-contact header with a single of type feature-param. Minakshi & Srimanta [Page 244] Internet Draft SIP-IMS Compliance Test Plan August 2007 Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Accept-Contact Header as : Accept-Contact: *;video b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.3.2 Acc_Rej_Hdr_V_02 : Ac-value of type generic-param Test Objective : To verify the parsing of accept-contact header with a single of type generic-param. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. expires is defined as an ac-param at the IUT Steps F1 to F6 of Call Flow 3 have been executed. Test Description : a) Send PRACK from the peer with Accept-Contact Header as : Accept-Contact: *;expires="600000" b) Verify that the PRACK is successfully parsed at the IUT. Minakshi & Srimanta [Page 245] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.3.3 Acc_Rej_Hdr_V_03 : Accept-Contact header with multiple ac-values Test Objective : To check that the IUT successfully parses Accept-contact header containing multiple ac-values. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, INVITE, SUBSCRIBE, MESSAGE, REFER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] Test Description : a) Send a MESSAGE request from the peer towards the IUT with Accept-Contact Header as : a: *;audio, *;video, *;msg-taker="actor" b) Verify that the MESSAGE is successfully parsed at the IUT and 200(OK) response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.3.4 Acc_Rej_Hdr_V_04 : Rc-value of type feature-param Test Objective : To verify the parsing of Reject-Contact header with a single of type feature-param. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Reject-Contact Header as : Minakshi & Srimanta [Page 246] Internet Draft SIP-IMS Compliance Test Plan August 2007 Reject-Contact: *;video b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.3.5 Acc_Rej_Hdr_V_05 : Rc-value of type generic-param Test Objective : To verify the parsing of Reject-Contact header with a single of type generic-param. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, MESSAGE, REFER, INVITE, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. expires is defined as an rc-param at the IUT Steps F1 to F6 of Call Flow 3 have been executed. Test Description : a) Send PRACK from the peer with Reject-Contact Header as : Reject-Contact: *;expires="600000" b) Verify that the PRACK is successfully parsed at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.3.6 Acc_Rej_Hdr_V_06 : Reject-Contact header with multiple rc-values Test Objective : To check that the IUT successfully parses Reject-Contact header containing multiple ac-values. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, INVITE, SUBSCRIBE, REFER, PRACK, UPDATE, NOTIFY, INFO, OPTIONS Minakshi & Srimanta [Page 247] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] Test Description : a) Send a MESSAGE request from the peer towards the IUT with Reject-Contact Header as : a: *;audio, *;video, *;msg-taker="actor" b) Verify that the MESSAGE is successfully parsed at the IUT and 200(OK) response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.3.7 Acc_Rej_Hdr_V_07 : Ac-value containing two generic-params Test Objective : To check that the IUT successfully parses Accept-Contact header containing two generic-params in a single ac-value. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, MESSAGE, REFER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] expires is defined as an ac-param at the IUT. User is registered. Test Description : a) Send SUBSCRIBE from the peer with Accept-Contact Header as : Accept-Contact: *;expires="600000";q=2.0 b) Verify that the SUBSCRIBE is successfully parsed at the IUT. c) Validate the SUBSCRIBE procedure execution as per Call Flow 2. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.3.8 Acc_Rej_Hdr_V_08 : Ac-value containing two feature-params Test Objective : To check that the IUT successfully parses Accept-Contact header containing two feature-params in a single ac-value. Minakshi & Srimanta [Page 248] Internet Draft SIP-IMS Compliance Test Plan August 2007 Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, MESSAGE, REFER, PRACK, SUBSCRIBE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Steps F1 to F10 of Call Flow 3 have been executed. Test Description : a) Send UPDATE from the peer with Accept-Contact Header as : a: *;methods="BYE";class="business" b) Verify that the UPDATE is successfully parsed at the IUT. c) Validate the normal execution as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.3.9 Acc_Rej_Hdr_V_09 : Rc-value containing two generic-params Test Objective : To check that the IUT successfully parses Reject-Contact header containing two generic-params in a single rc-value. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, MESSAGE, REFER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] expires is defined as an rc-param at the IUT User is registered. Test Description : a) Send SUBSCRIBE from the peer with Reject-Contact Header as : Reject-Contact: *;expires="600000";q=2.0 b) Verify that the SUBSCRIBE is successfully parsed at the IUT. Minakshi & Srimanta [Page 249] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the SUBSCRIBE procedure execution as per Call Flow 2. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.3.10 Acc_Rej_Hdr_V_10 : Rc-value containing two feature-params Test Objective : To check that the IUT successfully parses Reject-Contact header containing two feature-params in a single rc-value. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, MESSAGE, REFER, PRACK, SUBSCRIBE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Steps F1 to F10 of Call Flow 3 have been executed. Test Description : a) Send UPDATE from the peer with Reject-Contact Header as : j: *;methods="BYE";class="business" b) Verify that the UPDATE is successfully parsed at the IUT. c) Validate the normal execution as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.3.11 Acc_Rej_Hdr_V_11 : Single ac-value containing a req-param and a generic-param Test Objective : To check that the IUT successfully parses Accept-contact header containing generic-param & req-param. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, MESSAGE, REFER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Minakshi & Srimanta [Page 250] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send an INVITE request from the peer towards the IUT with Accept-Contact Header as : Accept-Contact: *;q=1.0;require b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.3.12 Acc_Rej_Hdr_V_12 : Single ac-value containing a feature-param and a generic-param Test Objective : To check that the IUT successfully parses Accept-contact header containing a generic-param and a feature-param. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, MESSAGE, REFER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Accept-Contact Header as : Accept-Contact: *;audio;q=1.0 b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.3.13 Acc_Rej_Hdr_V_13 : Single ac-value containing a feature-param and a req-param Test Objective : To check that the IUT successfully parses Accept-contact header containing a req-param and a feature-param. Reference : RFC3841, Section 10 Minakshi & Srimanta [Page 251] Internet Draft SIP-IMS Compliance Test Plan August 2007 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, MESSAGE, REFER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Accept-Contact Header as : a: *;video;require b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.3.14 Acc_Rej_Hdr_V_14 : Single ac-value containing a feature-param and an explicit-param Test Objective : To check that the IUT successfully parses Accept-contact header containing an explicit-param and a feature-param. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, MESSAGE, REFER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Accept-Contact Header as : a: *;video;explicit b) Verify that the INVITE is parsed successfully at the IUT. Minakshi & Srimanta [Page 252] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.3.15 Acc_Rej_Hdr_V_15 : Single ac-value containing a generic-param and an explicit-param Test Objective : To check that the IUT successfully parses Accept-contact header containing an explicit-param and a generic-param. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, MESSAGE, REFER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. multimedia is defined as an ac-param at the IUT Test Description : a) Send an INVITE request from the peer towards the IUT with Accept-Contact Header as : a: *;multimedia="FALSE";explicit b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.3.16 Acc_Rej_Hdr_V_16 : Single ac-value containing both a req-param as well as an explicit-param Test Objective : Validate the successful parsing of ac-value consisting of both the reg and explicit param. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, MESSAGE, REFER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] Minakshi & Srimanta [Page 253] Internet Draft SIP-IMS Compliance Test Plan August 2007 IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Accept-Contact Header as : a: *;audio;require;explicit b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.3.17 Acc_Rej_Hdr_V_17 : Single rc-value containing a feature-param and a generic-param Test Objective : To check that the IUT successfully parses Reject-contact header containing a generic-param and a feature-param. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, MESSAGE, REFER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Reject-Contact Header as : Reject-Contact: *;audio;q=1.0 b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.3.18 Acc_Rej_Hdr_I_18 : Multiple ac-values separated by semi-colon Minakshi & Srimanta [Page 254] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective : To verify that IUT returns an error when it receives accept-contact header with multiple ac-values separated by semi-colon instead of comma. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, MESSAGE, REFER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Accept-Contact Header as : a: *;audio;*;video;explicit b) Verify that the Accept-Contact header parsing fails at the IUT. c) Validate that the IUT returns an error to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.3.19 Acc_Rej_Hdr_I_19 : Accept-Contact Header with two req-params Test Objective : To verify that IUT returns an error when it receives accept-contact header with two req-params. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, MESSAGE, REFER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Accept-Contact Header as : a: *;methods="BYE";require;class="business";require;q=1.0 b) Verify that the Accept-Contact header parsing fails at the IUT. Minakshi & Srimanta [Page 255] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate that the IUT returns an error to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.3.20 Acc_Rej_Hdr_I_20 : Accept-Contact Header with two explicit-params Test Objective : To verify that IUT returns an error when it receives accept-contact header with two explicit params. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, MESSAGE, REFER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Accept-Contact Header as : a: *;methods="BYE";explicit;class="business";explicit;q=1.0 b) Verify that the Accept-Contact header parsing fails at the IUT. c) Validate that the IUT returns an error to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.3.21 Acc_Rej_Hdr_I_21 : Multiple rc-values separated by semi-colon Test Objective : To verify that IUT returns an error when it receives reject-contact header with multiple rc-values separated by semi-colon instead of comma. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, MESSAGE, REFER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : Minakshi & Srimanta [Page 256] Internet Draft SIP-IMS Compliance Test Plan August 2007 a) Send an INVITE request from the peer towards the IUT with Reject-Contact Header as : j: *;audio;*;video;class=business b) Verify that the Reject-Contact header parsing fails at the IUT. c) Validate that the IUT returns an error to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.3.22 Acc_Rej_Hdr_I_22 : Rc-value containing a feature-param and a req-param Test Objective : To check Reject-contact header parsing fails when it contains a req-param and a feature-param. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, MESSAGE, REFER, PRACK, UPDATE, NOTIFY, INFO Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Reject-Contact Header as : j: *;video;require b) Verify that the Reject-Contact header parsing fails at the IUT. c) Validate that the IUT returns an error to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.8.3.23 Acc_Rej_Hdr_I_23 : Rc-value containing a feature-param and an explicit-param Test Objective : To check Reject-contact header parsing fails at the IUT when it contains an explicit-param and a feature-param. Reference : RFC3841, Section 10 Applicable Messages : ACK, BYE, CANCEL, OPTIONS, MESSAGE, REFER, PRACK, UPDATE, NOTIFY, INFO Minakshi & Srimanta [Page 257] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports Caller Preferences for SIP [12] IUT Supports SIP Capabilities [13] User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Accept-Contact Header as : j: *;video;explicit b) Verify that the Reject-Contact header parsing fails at the IUT. c) Validate that the IUT returns an error to the peer. --------------------------------------------------------------------- 3.9 SIP Extension For Registering Non-Adjacent Contacts The Path Header provides a mechanism to discover intermediate proxies during SIP Registration. These proxies must be traversed for any request from the user's home network to the registered contact. 3.9.1 Path Header Cases --------------------------------------------------------------------- 3.9.1.1 Path_Hdr_V_01 : Supported header with option tag "path" Test Objective : To verify parsing of Supported Header with option-tag "path". Reference : RFC3327, Section 5.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Path Extension Header Field [3] Test Description : a) Send a REGISTER request from the peer towards the IUT with Supported Header as : Supported: path b) Verify that the REGISTER is parsed successfully at the IUT. Minakshi & Srimanta [Page 258] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal REGISTER procedure execution as per Call Flow 1. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.9.1.2 Path_Hdr_V_02 : Require header with option tag "path" Test Objective : To verify that the IUT successfully parses Require Header with "path" as the option-tag. Reference : RFC3327, Section 5.2 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Path Extension Header Field [3] Test Description : a) Send a REGISTER request from the peer towards the IUT with Require Header as : Require: path b) Verify that the REGISTER is parsed successfully at the IUT. c) Validate the normal REGISTER procedure execution as per Call Flow 1. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.9.1.3 Path_Hdr_V_03 : Path Header with a single path value Test Objective : To verify the successful parsing of the Path header containing a single name-addr parameter with a rr-parameter. Reference : RFC3327, Section 4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Path Extension Header Field [3] Test Description : a) Send a REGISTER request from the peer towards the IUT with Path Header as : Path: b) Verify that the REGISTER is parsed successfully at the IUT. Minakshi & Srimanta [Page 259] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal REGISTER procedure execution as per Call Flow 1. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.9.1.4 Path_Hdr_V_04 : Path Header with a two path values Test Objective : To verify the parsing of Path header when it contains two path-values. Reference : RFC3327, Section 4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Path Extension Header Field [3] Test Description : a) Send a REGISTER request from the peer towards the IUT with Path Header as : Path: , b) Verify that the REGISTER is parsed successfully at the IUT. c) Validate the normal REGISTER procedure execution as per Call Flow 1. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.9.1.5 Path_Hdr_V_05 : Path Header with multiple path values Test Objective : To verify the successful parsing of multiple path-values in the Path header(Check for 4 values). Reference : RFC3327, Section 4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Path Extension Header Field [3] Test Description : a) Send a REGISTER request from the peer towards the IUT with Path Header as : Path: ,, , Minakshi & Srimanta [Page 260] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that the REGISTER is parsed successfully at the IUT. c) Validate the normal REGISTER procedure execution as per Call Flow 1. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.9.1.6 Path_Hdr_V_06 : Multiple Path headers Test Objective : To validate the IUT behavior when it receives multiple instances of Path headers in the received REGISTER message. Reference : RFC3327, Section 4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Path Extension Header Field [3] Test Description : a) Send a REGISTER request from the peer towards the IUT with Path Headers as : Path: Path: Path: b) Verify that the REGISTER is parsed successfully at the IUT. c) Validate the normal REGISTER procedure execution as per Call Flow 1. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.9.1.7 Path_Hdr_I_07 : Path header without the lr parameter Test Objective : To verify that the IUT responds with error when it receives a Path header without the lr parameter. Reference : RFC3327, Section 4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Path Extension Header Field [3] Minakshi & Srimanta [Page 261] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a REGISTER request from the peer towards the IUT with Path Header as : Path: b) Verify that the REGISTER parsing fails at the IUT. c) Validate that the IUT returns 400 (Bad Request) response to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.9.1.8 Path_Hdr_I_08 : Empty Path header Test Objective : To verify the IUT behavior on receipt of an empty Path header. Reference : RFC3327, Section 4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Path Extension Header Field [3] Test Description : a) Send a REGISTER request from the peer towards the IUT with Path Header as : Path: b) Validate that the IUT discards the header while REGISTER processing. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.9.1.9 Path_Hdr_I_09 : Receipt of REGISTER request with a path header and without the path option-tag in Supported header Test Objective : Verify that an error response is returned on receipt of a REGISTER request with a Path header but missing "path" option tag in the Supported header. Reference : RFC3327, Section 5.2 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Path Extension Header Field [3] Minakshi & Srimanta [Page 262] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a REGISTER request from the peer towards the IUT with a valid Path header but no "path" option-tag in the Supported or Require Header. b) Validate that the IUT returns 400 (Bad Request) response to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.9.1.10 Path_Hdr_I_10 : Path header with invalid syntax Test Objective : To verify the IUT behavior when it receives a Path header with missing <>. Reference : RFC3327, Section 4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Path Extension Header Field [3] Test Description : a) Send a REGISTER request from the peer towards the IUT with Path Header as : Path: sip:p1.example.com;lr b) Validate that the IUT returns 400 (Bad Request) response to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.9.1.11 Path_Hdr_I_11 : INVITE Request with Path header Test Objective : To validate the IUT behavior when it receives INVITE request with a Path header. Reference : RFC3327, Section 4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Path Extension Header Field [3] User is registered. Minakshi & Srimanta [Page 263] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send an INVITE request from the peer towards the IUT with a Path Header as : Path: b) Validate that the IUT discards the header and proceeds with normal processing as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.9.1.12 Path_Hdr_V_12 : 421 response to REGISTER for support of Path extension Test Objective : Verify that the IUT successfully parses 421 response to REGISTER for support of Path extension required by Proxy. Reference : RFC3327, Section 4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Path Extension Header Field [3] REGISTER request is sent by the IUT towards the peer. Test Description : a) Send a 421 "Extension Required" response from the peer with Require header as path. b) Validate that the response is successfully parsed at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.9.1.13 Path_Hdr_V_13 : 420 Bad extension response to REGISTER Test Objective : To check that the IUT successfully parses 420 response to REGISTER containing the Unsupported header with option tag "path. Reference : RFC3327, Section 4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Path Extension Header Field [3] REGISTER request is sent by the IUT towards the peer. Test Description : Minakshi & Srimanta [Page 264] Internet Draft SIP-IMS Compliance Test Plan August 2007 a) Send a 421 "Bad Extension" response from the peer with Unsupported header as path. b) Validate that the response is successfully parsed at the IUT. --------------------------------------------------------------------- 3.10 SIP REFER Method The REFER method is used to refer the recipient of a request to a specified resource and be notified of the result. This method is used to enable services like Call Transfer. 3.10.1 Generic Cases --------------------------------------------------------------------- 3.10.1.1 Refer_V_01 : REFER request with a single contact header Test Objective : Verify the REFER request parsing containing a single contact header. Reference : RFC3515, Section 2 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP REFER Method [15]. Steps F1 to F24 of Call Flow 4 have been executed. Session is established between Peer1 and Peer2. Test Description : a) Send a valid REFER request from Peer2 towards the IUT with a single contact header. b) Verify that the REFER is successfully parsed at the IUT. c) Validate the normal execution as per Call Flow 4. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.10.1.2 Refer_I_02 : REFER request with multiple contact headers Test Objective : To check that an error response is returned when the IUT receives a REFER request with more than one contact header. Reference : RFC3515, Section 2 Applicable Messages : Not Applicable Minakshi & Srimanta [Page 265] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT supports SIP REFER Method [15]. Steps F1 to F24 of Call 4 have been executed. Session is established between Peer1 and Peer2. Test Description : a) Send a REFER request from Peer2 towards the IUT with two contact headers. b) Verify that the REFER parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.10.1.3 Refer_V_03 : REFER request without a body Test Objective : To validate that the IUT successfully parses a REFER request received without any body. Reference : RFC3515, Section 2.3 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP REFER Method [15]. Steps F1 to F24 of Call 4 have been executed. Session is established between Peer1 and Peer2. Test Description : a) Send a valid REFER request from Peer2 towards the IUT without any body. b) Verify that the REFER is successfully parsed at the IUT. c) Validate the normal execution as per Call Flow 4. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.10.1.4 Refer_V_04 : REFER request with a body Test Objective : To verify successful parsing of REFER request containing a body. Reference : RFC3515, Section 2.3 Applicable Messages : Not Applicable Minakshi & Srimanta [Page 266] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT supports SIP REFER Method [15]. Steps F1 to F24 of Call 4 have been executed. Session is established between Peer1 and Peer2. Test Description : a) Send a valid REFER request from Peer2 towards the IUT with a body. b) Verify that the REFER body is successfully parsed (according to the Content-Type) at the IUT. c) Validate the normal execution as per Call Flow 4. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.10.1.5 Refer_V_05 : Refer-To header as name-addr Test Objective : Validate the parsing of Refer-To header set as a name-addr. Reference : RFC3515, Section 2.1 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP REFER Method [15]. Steps F1 to F24 of Call 4 have been executed. Session is established between Peer1 and Peer2. Test Description : a) Send a valid REFER request from Peer2 towards the IUT with Refer-To header as : Refer-To: b) Verify that the REFER is successfully parsed at the IUT. c) Validate the normal execution as per Call Flow 4. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.10.1.6 Refer_V_06 : Refer-To header as addr-spec Test Objective : To verify that the IUT successfully parses a Refer-To header set as an addr-spec. Reference : RFC3515, Section 2.1 Minakshi & Srimanta [Page 267] Internet Draft SIP-IMS Compliance Test Plan August 2007 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP REFER Method [15]. Steps F1 to F24 of Call 4 have been executed. Session is established between Peer1 and Peer2. Test Description : a) Send a valid REFER request from Peer2 towards the IUT with Refer-To header as : Refer-To: sip:alice@example.com b) Verify that the REFER is successfully parsed at the IUT. c) Validate the normal execution as per Call Flow 4. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.10.1.7 Refer_I_07 : REFER request with multiple name-addr/addr-specs Test Objective : To check that an error response is sent on receipt of Refer-To header with multiple instances of name-addr/addr-specs. Reference : RFC3515, Section 2.1 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP REFER Method [15]. Steps F1 to F24 of Call 4 have been executed. Session is established between Peer1 and Peer2. Test Description : a) Send a REFER request from Peer2 towards the IUT with Refer-To header as : Refer-To: sip:alice@example.com;sip:bob@example.com b) Verify that the REFER parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.10.1.8 Refer_V_08 : Refer-To header with a single generic-param Test Objective : To verify that the IUT successfully parses a Refer-To header containing a name-addr/addr-spec and a single generic-param. Minakshi & Srimanta [Page 268] Internet Draft SIP-IMS Compliance Test Plan August 2007 Reference : RFC3515, Section 2.1 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP REFER Method [15]. Steps F1 to F24 of Call 4 have been executed. Session is established between Peer1 and Peer2. Test Description : a) Send a valid REFER request from Peer2 towards the IUT with Refer-To header as : r: b) Verify that the REFER is successfully parsed at the IUT. c) Validate the normal execution as per Call Flow 4. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.10.1.9 Refer_V_09 : Multiple generic-params in Refer-To header Test Objective : To verify that the IUT successfully parses a Refer-To header containing a name-addr/addr-spec and a single generic-param. Reference : RFC3515, Section 2.1 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP REFER Method [15]. Steps F1 to F24 of Call 4 have been executed. Session is established between Peer1 and Peer2. Test Description : a) Send a valid REFER request from Peer2 towards the IUT with Refer-To header as : Refer-To: b) Verify that the REFER is successfully parsed at the IUT. c) Validate the normal execution as per Call Flow 4. --------------------------------------------------------------------- --------------------------------------------------------------------- Minakshi & Srimanta [Page 269] Internet Draft SIP-IMS Compliance Test Plan August 2007 3.10.1.10 Refer_V_10 : Http url as a Refer-to header Test Objective : Verify that the IUT successfully parses the Refer-To header received as http url. Reference : RFC3515, Section 2.1 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP REFER Method [15]. Steps F1 to F24 of Call 4 have been executed. Session is established between Peer1 and Peer2. Test Description : a) Send a valid REFER request from Peer2 towards the IUT with Refer-To header as : r: http://www.ietf.org b) Verify that the REFER is successfully parsed at the IUT. c) Validate the normal execution as per Call Flow 4. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.10.1.11 Refer_I_11 : Multiple Refer-To headers Test Objective : To validate that the IUT responds with an error when it receives a REFER request with multiple Refer-To headers. Reference : RFC3515, Section 2.4.1 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP REFER Method [15]. Steps F1 to F24 of Call 4 have been executed. Session is established between Peer1 and Peer2. Test Description : a) Send a REFER request from Peer2 towards the IUT with Refer-To header as : Refer-To: sip:alice@example.com;sip:bob@example.com Refer-To: http://www.ietf.org Minakshi & Srimanta [Page 270] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that the REFER parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.10.1.12 Refer_I_12 : Empty Refer-To header Test Objective : To validate the IUT behavior when it receives a REFER request with empty Refer-To header. Reference : RFC3515, Section 2.4.1 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP REFER Method [15]. Steps F1 to F24 of Call 4 have been executed. Session is established between Peer1 and Peer2. Test Description : a) Send a REFER request from Peer2 towards the IUT with Refer-To header as : Refer-To: b) Verify that the REFER parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.10.1.13 Refer_I_13 :REFER request without a Refer-To header Test Objective : To check that an error response is returned on receipt of a REFER request without Refer-To header. Reference : RFC3515, Section 2.4.2 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP REFER Method [15]. Steps F1 to F24 of Call 4 have been executed. Session is established between Peer1 and Peer2. Test Description : a) Send a REFER request from Peer2 towards the IUT without Refer-To header. Minakshi & Srimanta [Page 271] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that the REFER parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.10.1.14 Refer_V_14 : 100 Trying response to a REFER request Test Objective : To verify that the IUT successfully parses a 100 Trying response received in response to a REFER request. Reference : RFC3515, Section 2.4.2 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP REFER Method [15]. Session is established between Peer1 and Peer2. Steps F1 to F26 of Call 4 have been executed. Test Description : a) Send a 100 (Trying) response from Peer1 in response to the REFER request. b) Verify that the response is successfully parsed at the IUT. c) Validate the normal execution as per Call Flow 4. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.10.1.15 Refer_V_15 : NOTIFY with Event header as "refer" Test Objective : To verify that the IUT successfully parses a NOTIFY containing Event header as "refer". Reference : RFC3515, Section 2.4.4 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP REFER Method [15]. Session is established between Peer1 and Peer2. Steps F1 to F28 of Call 4 have been executed. Test Description : a) Send a NOTIFY from Peer1 with Event header as : Event: refer b) Verify that the NOTIFY is successfully parsed at the IUT. Minakshi & Srimanta [Page 272] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal execution as per Call Flow 4. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.10.1.16 Refer_V_16 : NOTIFY with body of type "message/sipfrag" Test Objective : To check the successful parsing of NOTIFY with body type as "message/sipfrag". Reference : RFC3515, Section 2.4.5 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP REFER Method [15]. Session is established between Peer1 and Peer2. Steps F1 to F28 of Call 4 have been executed. Test Description : a) Send a NOTIFY from Peer1 with Content-Type header as : Content-Type: message/sipfrag b) Verify that the NOTIFY is successfully parsed at the IUT. c) Validate the normal execution as per Call Flow 4. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.10.1.17 Refer_I_17 : SUBSCRIBE Request with event header as "refer" Test Objective : Validate the successful parsing of a SUBSCRIBE Request with event header as "refer". Reference : RFC3515, Section 2.4.4 Applicable Messages : SUBSCRIBE Pre-Requirement : IUT supports SIP REFER Method [15]. Test Description : a) Send a SUBSCRIBE from the peer with Content-Type header as : Event: refer b) Verify that the SUBSCRIBE is successfully parsed at the IUT. Minakshi & Srimanta [Page 273] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the SUBSCRIBE/NOTIFY execution as per Call Flow 2. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.10.1.18 Refer_V_18 : NOTIFY body containing a SIP response status line Test Objective : Validate that the IUT successfully parses a NOTIFY body(in correspondence to a REFER ) containing a SIP response status line. Reference : RFC3515, Section 2.4.5 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP REFER Method [15]. Session is established between Peer1 and Peer2. Steps F1 to F28 of Call 4 have been executed. Test Description : a) Send a NOTIFY from Peer1 with body as : SIP/2.0 100 Trying b) Verify that the NOTIFY is successfully parsed at the IUT. c) Validate the normal execution as per Call Flow 4. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.10.1.19 Refer_I_19 : NOTIFY body with invalid syntax Test Objective : To check that the IUT returns an error on receipt of NOTIFY with body type as "message/sipfrag" but the body does not begin with a SIP response status line. Reference : RFC3515, Section 2.4.5 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP REFER Method [15]. Session is established between Peer1 and Peer2. Steps F1 to F28 of Call 4 have been executed. Minakshi & Srimanta [Page 274] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a NOTIFY from Peer1 with body as : 100 Trying b) Verify that the NOTIFY parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- 3.11 INVITE with Replaces The INVITE request with a Replaces header is used to replace an existing dialog with a new dialog. This is especially useful in peer-to-peer Call control environments and can be used to enable features like "Attended Transfer", "Call Pickup". 3.11.1 Replaces Header Cases --------------------------------------------------------------------- 3.11.1.1 INV_Rep_Hdr_V_01 : INVITE with replaces with Callid, to-tag and from-tag matching an existing dialog Test Objective : To verify that the IUT successfully parses the INVITE received with a Replaces header containing Callid, to-tag and from-tag matching an existing dialog. Reference : RFC3891, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Replaces Header [6] User is registered. A SIP dialog with following parameters is existing in the IUT : Call-ID : 98732@sip.example.com, from-tag=r33th4x0r, to-tag=ff87ff Test Description : a) Send an INVITE request from the peer towards the IUT with Replaces Header as : Replaces: 98732@sip.example.com;to-tag=ff87ff;from-tag=r33th4x0r b) Verify that the INVITE is parsed successfully at the IUT. 200 (OK) is returned to the peer. Minakshi & Srimanta [Page 275] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) On receipt of Ack, the dialog is established and the earlier dialog is terminated. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.11.1.2 INV_Rep_Hdr_I_02 : INVITE with more than one replaces header Test Objective : To validate that the IUT responds with an error on receipt of INVITE Request with more than one replaces header. Reference : RFC3891, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Replaces Header [6] User is registered. A SIP dialog with following parameters is existing in the IUT : Call-ID : 98732@sip.example.com, from-tag=r33th4x0r, to-tag=ff87ff Test Description : a) Send an INVITE request from the peer towards the IUT with Replaces Header as : Replaces: 98732@sip.example.com;to-tag=ff87ff;from-tag=r33th4x0r Replaces: 987@sip.example.com;to-tag=ff7ff;from-tag=33th4r b) Verify that the INVITE parsing fails at the IUT. c) Error response is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.11.1.3 INV_Rep_Hdr_I_03 : OPTIONS with replaces header Test Objective : To validate the IUT behavior when it receives a replaces header in an OPTIONS request. Reference : RFC3891, Section 6.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Replaces Header [6] User is registered. A SIP dialog with following parameters is existing in the IUT : Call-ID : 98732@sip.example.com, from-tag=r33th4x0r, to-tag=ff87ff Minakshi & Srimanta [Page 276] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send an OPTIONS request from the peer towards the IUT with Replaces Header as : Replaces: 98732@sip.example.com;to-tag=ff87ff;from-tag=r33th4x0r b) Verify that the header is discarded in OPTIONS request processing. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.11.1.4 INV_Rep_Hdr_I_04 : Receipt of replaces header in SUBSCRIBE Test Objective : To validate the IUT behavior when it receives a replaces header in an OPTIONS request. Reference : RFC3891, Section 6.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Replaces Header [6] User is registered. A SIP dialog with following parameters is existing in the IUT : Call-ID : 98732@sip.example.com, from-tag=r33th4x0r, to-tag=ff87ff Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with Replaces Header as : Replaces: 98732@sip.example.com;to-tag=ff87ff;from-tag=r33th4x0r b) Verify that the header is discarded in SUBSCRIBE request processing. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.11.1.5 INV_Rep_Hdr_V_05 : INVITE request with replaces and referred-by headers Test Objective : To verify the successful parsing of an INVITE request containing a replaces and a referred-by header. Reference : RFC3891, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Replaces Header [6] Minakshi & Srimanta [Page 277] Internet Draft SIP-IMS Compliance Test Plan August 2007 User is registered. A SIP dialog with following parameters is existing in the IUT : Call-ID : 98732@sip.example.com, from-tag=r33th4x0r, to-tag=ff87ff Test Description : a) Send an INVITE request from the peer towards the IUT with Replaces and Referred-By headers as : Replaces: 98732@sip.example.com;to-tag=ff87ff;from-tag=r33th4x0r Referred-By: b) Verify that the INVITE is parsed successfully at the IUT. 200 (OK) is returned to the peer. c) On receipt of Ack, the dialog is established and the earlier dialog is terminated. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.11.1.6 INV_Rep_Hdr_V_06 : Replaces header with from-tag as zero Test Objective : To verify successful parsing of replaces header with from-tag as zero. Reference : RFC3891, Section 6.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Replaces Header [6] User is registered. A SIP dialog with following parameters is existing in the IUT : Call-ID : 98732@sip.example.com, from-tag=r33th4x0r, to-tag=ff87ff Test Description : a) Send an INVITE request from the peer towards the IUT with Replaces Header as : Replaces: 98732@sip.example.com;to-tag=ff87ff;from-tag=0 b) Verify that the INVITE is parsed successfully at the IUT. 200 (OK) is returned to the peer. c) On receipt of Ack, the dialog is established and the earlier dialog is terminated. --------------------------------------------------------------------- --------------------------------------------------------------------- Minakshi & Srimanta [Page 278] Internet Draft SIP-IMS Compliance Test Plan August 2007 3.11.1.7 INV_Rep_Hdr_V_07 : Replaces header with from-tag set as zero Test Objective : To check that the IUT successfully parses the replaces header with a missing from-tag. Reference : RFC3891, Section 6.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Replaces Header [6] User is registered. A SIP dialog with following parameters is existing in the IUT : Call-ID : 98732@sip.example.com, from-tag=r33th4x0r, to-tag=ff87ff Test Description : a) Send an INVITE request from the peer towards the IUT with Replaces Header containing from-tag as zero. b) Verify that the INVITE is parsed successfully at the IUT. 200 (OK) is returned to the peer. c) On receipt of Ack, the dialog is established and the earlier dialog is terminated. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.11.1.8 INV_Rep_Hdr_V_08 : Replaces header with to-tag as zero Test Objective : To validate the parsing of replaces header with missing to-tag. Reference : RFC3891, Section 6.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Replaces Header [6] User is registered. A SIP dialog with following parameters is existing in the IUT : Call-ID : 98732@sip.example.com, from-tag=r33th4x0r, to-tag=ff87ff Test Description : a) Send an INVITE request from the peer towards the IUT with Replaces Header containing to-tag as zero. b) Verify that the INVITE is parsed successfully at the IUT. 200 (OK) is returned to the peer. Minakshi & Srimanta [Page 279] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) On receipt of Ack, the dialog is established and the earlier dialog is terminated. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.11.1.9 INV_Rep_Hdr_V_09 : INVITE request with early-flag Test Objective : To verify successful parsing of a replaces header with early-flag. Reference : RFC3891, Section 6.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Replaces Header [6] User is registered. A SIP dialog with following parameters is existing in the IUT : Call-ID : 98732@sip.example.com, from-tag=r33th4x0r, to-tag=ff87ff Test Description : a) Send an INVITE request from the peer towards the IUT with Replaces Header as : Replaces: 98732@sip.example.com;to-tag=ff87ff;from-tag=r33th4x0r; early-only b) Verify that the INVITE is parsed successfully at the IUT. 200 (OK) is returned to the peer. c) On receipt of Ack, the dialog is established and the earlier dialog is terminated. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.11.1.10 INV_Rep_Hdr_V_10 : Replaces header with a Call-id, to-tag, from-tag, early-flag and generic param Test Objective : To verify that the IUT successfully parses a replaces header containing Call-id and single instance each of all kind of defined replaces-param(to-tag,from-tag,early-flag and generic-param). Reference : RFC3891, Section 6.1 Applicable Messages : Not Applicable Minakshi & Srimanta [Page 280] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports SIP Replaces Header [6] User is registered. A SIP dialog with following parameters is existing in the IUT : Call-ID : 98732@sip.example.com, from-tag=r33th4x0r, to-tag=ff87ff dialog is defined as a replaces-param in IUT. Test Description : a) Send an INVITE request from the peer towards the IUT with Replaces Header as : Replaces: 98732@sip.example.com;to-tag=ff87ff;from-tag=r33th4x0r; early-only;dialog-type=early-only b) Verify that the INVITE is parsed successfully at the IUT. 200 (OK) is returned to the peer. c) On receipt of Ack, the dialog is established and the earlier dialog is terminated. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.11.1.11 INV_Rep_Hdr_I_11 : Replaces header with more than one to-tag Test Objective : To check that an error response is returned on receipt of replaces header with more than one to-tag. Reference : RFC3891, Section 6.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Replaces Header [6] User is registered. A SIP dialog with following parameters is existing in the IUT : Call-ID : 98732@sip.example.com, from-tag=r33th4x0r, to-tag=ff87ff Test Description : a) Send an INVITE request from the peer towards the IUT with Replaces Header as : Replaces: 98732@sip.example.com;to-tag=ff87ff;from-tag=r33th4x0r; early-only;to-tag=ff88ff b) Verify that the replaces header parsing fails and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- Minakshi & Srimanta [Page 281] Internet Draft SIP-IMS Compliance Test Plan August 2007 3.11.1.12 INV_Rep_Hdr_I_12 : Replaces header with more than one from-tag Test Objective : To check that an error response is returned on receipt of replaces header with more than one from-tag. Reference : RFC3891, Section 6.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Replaces Header [6] User is registered. A SIP dialog with following parameters is existing in the IUT : Call-ID : 98732@sip.example.com, from-tag=r33th4x0r, to-tag=ff87ff Test Description : a) Send an INVITE request from the peer towards the IUT with Replaces Header as : Replaces: 98732@sip.example.com;to-tag=ff87ff;from-tag=r33th4x0r; early-only;from-tag=ff88ff b) Verify that the replaces header parsing fails and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.11.1.13 INV_Rep_Hdr_I_13 : Replaces header with unrecognized token Test Objective : To validate the IUT behavior when it receives a replaces header with unrecognized token. Reference : RFC3891, Section 6.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Replaces Header [6] User is registered. A SIP dialog with following parameters is existing in the IUT : Call-ID : 98732@sip.example.com, from-tag=r33th4x0r, to-tag=ff87ff Test Description : a) Send an INVITE request from the peer towards the IUT with Replaces Header as : Replaces: 98732@sip.example.com;to-tag=ff87ff;from-tag=r33th4x0r; confirm-only Minakshi & Srimanta [Page 282] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that the replaces header parsing fails and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.11.1.14 INV_Rep_Hdr_V_14 : Supported header with option tag as "replaces" Test Objective : To verify the parsing of Supported header in an INVITE Request with option tag "replaces". Reference : RFC3891, Section 6.2 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Replaces Header [6] User is registered. A SIP dialog with following parameters is existing in the IUT : Call-ID : 98732@sip.example.com, from-tag=r33th4x0r, to-tag=ff87ff Test Description : a) Send an INVITE request from the peer towards the IUT with Supported Header as : Supported: replaces, 100rel b) Verify that the INVITE is parsed successfully at the IUT. c) Validate normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.11.1.15 INV_Rep_Hdr_V_15 : Require header with option tag as "replaces" Test Objective : To verify the parsing of Require header in an INVITE Request with option tag "replaces". Reference : RFC3891, Section 6.2 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Replaces Header [6] User is registered. A SIP dialog with following parameters is existing in the IUT : Call-ID : 98732@sip.example.com, from-tag=r33th4x0r, to-tag=ff87ff Minakshi & Srimanta [Page 283] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send an INVITE request from the peer towards the IUT with Supported Header as : Require: replaces b) Verify that the INVITE is parsed successfully at the IUT. c) Validate normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- 3.12 Service Route Discovery During Registration The 3GPP network dynamically assigns a home service proxy to each address-of-record (AOR). This information is returned in the Service-Route header in REGISTER response. This new header field indicates a "preloaded route" that the UA may wish to use if requesting services from the proxy network associated with the registrar generating the response. 3.12.1 Service-Route Header Cases --------------------------------------------------------------------- 3.12.1.1 Serv_Rout_V_01 : Service-Route header with a single sr-value (name-addr) Test Objective : To verify successful parsing of Service-Route header with a single sr-value (name-addr). Reference : RFC3608, Section 5 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP Extension For Service Route Discovery [11]. Steps F1 to F3 of Call Flow 1 have been executed. IUT has initiated the REGISTER request. Test Description : a) Send a 200 (OK) response from the peer with service-route header as : Service-Route: b) Verify that the 200 (OK) is successfully parsed at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- Minakshi & Srimanta [Page 284] Internet Draft SIP-IMS Compliance Test Plan August 2007 3.12.1.2 Serv_Rout_V_02 : Service-Route header with a multiple sr-values (name-addr) Test Objective : To verify parsing of Service-Route header with multiple sr-values. Reference : RFC3608, Section 5 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP Extension For Service Route Discovery [11]. Steps F1 to F3 of Call Flow 1 have been executed. IUT has initiated the REGISTER request. Test Description : a) Send a 200 (OK) response from the peer with service-route header as : Service-Route: , b) Verify that the 200 (OK) is successfully parsed at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.12.1.3 Serv_Rout_V_03 : Multiple Service-Route headers Test Objective : To validate the IUT behavior when it receives multiple Service-Route Headers in response to REGISTER Request. Reference : RFC3608, Section 5 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP Extension For Service Route Discovery [11]. Steps F1 to F3 of Call Flow 1 have been executed. IUT has initiated the REGISTER request. Test Description : a) Send a 200 (OK) response from the peer with service-route header as : Service-Route: Service-Route: Minakshi & Srimanta [Page 285] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that the 200 (OK) is successfully parsed at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.12.1.4 Serv_Rout_I_04 : Service route header without the lr parameter Test Objective : To check that the IUT responds with an error when it receives Service-Route Header without the lr parameter. Reference : RFC3608, Section 5 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP Extension For Service Route Discovery [11]. Steps F1 to F3 of Call Flow 1 have been executed. IUT has initiated the REGISTER request. Test Description : a) Send a 200 (OK) response from the peer with service-route header as : Service-Route: b) Verify that the service route header parsing fails at the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.12.1.5 Serv_Rout_I_05 : Service route header in an INVITE request Test Objective : To validate the IUT responds behavior when it receives an INVITE with Service-Route header. Reference : RFC3608, Section 5 Applicable Messages : BYE, CANCEL, OPTIONS, PRACK, UPDATE Pre-Requirement : IUT supports SIP Extension For Service Route Discovery [11]. Test Description : a) Send a INVITE request from the peer with service-route header as : Service-Route: Minakshi & Srimanta [Page 286] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that the IUT discards the Service Route header and continues with INVITE processing. --------------------------------------------------------------------- 3.13 SIP Event Notification The SIP Event Notification extension provides an extensible framework by which SIP nodes can request asynchronous notification from remote nodes indicating that certain events have occurred. 3.13.1 SUBSCRIBE/NOTIFY Parsing Cases --------------------------------------------------------------------- 3.13.1.1 SUBS_NTFY_V_01 : SUBSCRIBE with only the mandatory headers Test Objective : To verify that the IUT successfully parses a SUBSCRIBE containing only the mandatory headers as specified in RFC 3261 [1] and RFC 3265 [5] Reference : RFC3265, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. User is registered at IUT. Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with all the mandatory headers in valid formats as specified in RFC 3261 [1] and RFC 3265 [5]. b) Verify that the SUBSCRIBE is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE procedure execution as per Call Flow 2. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.2 SUBS_NTFY_I_02 : SUBSCRIBE without Event Header Test Objective : To verify that the IUT responds with an error on receipt of SUBSCRIBE without an Event header. Reference : RFC3265, Section 3 Applicable Messages : Not Applicable Minakshi & Srimanta [Page 287] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. User is registered at IUT. Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with missing Event Header. b) Verify that the SUBSCRIBE parsing fails at the IUT. c) Validate that an error response is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.3 SUBS_NTFY_I_03 : SUBSCRIBE with missing Max-Forwards Header Test Objective : To validate the IUT behavior when it receives a SUBSCRIBE request without the Max-Forwards header Reference : RFC3265, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. User is registered at IUT. Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with missing Max-Forwards Header. b) Verify that the SUBSCRIBE parsing fails at the IUT. c) Validate that an error response is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.4 SUBS_NTFY_I_04 : SUBSCRIBE without Contact Header Test Objective : To validate the IUT behavior when it receives a SUBSCRIBE request with missing Contact header Reference : RFC3265, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. User is registered at IUT. Minakshi & Srimanta [Page 288] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with missing Contact Header. b) Verify that the SUBSCRIBE parsing fails at the IUT. c) Validate that an error response is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.5 SUBS_NTFY_V_05 : Receipt of 401 (Unauthorized) response to SUBSCRIBE Test Objective : To verify that the IUT successfully parses 401 (Unauthorized) response received for authentication of user for the subscription. Reference : RFC3265, Section 3.13.6 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. User is registered at IUT. IUT has forwarded a SUBSCRIBE Request to the peer. Test Description : a) Send a 401 (Unauthorized) response from the peer. b) Verify that the 401 message is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY execution as per Call Flow 2. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.6 SUBS_NTFY_V_06 : Receipt of 407 (Proxy Authentication Required)response to SUBSCRIBE Test Objective : To validate the IUT behavior when 407 is received for authentication of user for the subscription. Reference : RFC3265, Section 3.13.6 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. User is registered at IUT. IUT has forwarded a SUBSCRIBE Request to the peer. Minakshi & Srimanta [Page 289] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a 407 response from the peer for authentication of the subscription request. b) Verify that the IUT discards the 407 response to SUBSCRIBE. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.7 SUBS_NTFY_V_07 : NOTIFY with only the mandatory headers Test Objective : To verify that the IUT successfully parses a NOTIFY containing only the mandatory headers as specified in RFC 3261 [1] and RFC 3265 [5] Reference : RFC3265, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with all the mandatory headers in valid formats as specified in RFC 3261 [1] and RFC 3265 [5]. b) Verify that the NOTIFY is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.8 SUBS_NTFY_I_08 : NOTIFY without the From Header Test Objective : To validate the IUT behavior when it receives a NOTIFY request with missing From header. Reference : RFC3265, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Minakshi & Srimanta [Page 290] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a NOTIFY from the peer towards the IUT without the From header. b) Verify that the NOTIFY parsing fails at the IUT. c) Validate that an error response is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.9 SUBS_NTFY_I_09 : NOTIFY with missing CSeq Header Test Objective : To verify that an error response is returned on receipt of a NOTIFY request without the CSeq header. Reference : RFC3265, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with missing CSeq header. b) Verify that the NOTIFY parsing fails at the IUT. c) Validate that an error response is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.10 SUBS_NTFY_I_10 : NOTIFY with missing Subscription-State Header Test Objective : To check that an error response is returned on receipt of NOTIFY without the Subscription-State header. Reference : RFC3265, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Minakshi & Srimanta [Page 291] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a NOTIFY from the peer towards the IUT with missing Subscription-State header. b) Verify that the NOTIFY parsing fails at the IUT. c) Validate that an error response is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.11 SUBS_NTFY_V_11 : NOTIFY with event header package not matching that of corresponding SUBSCRIBE Test Objective : To validate the IUT behavior on receipt of NOTIFY with event header package not matching to that of corresponding SUBSCRIBE. Reference : RFC3265, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with Event header not as the one received in SUBSCRIBE b) Verify that the NOTIFY parsing fails at the IUT. c) Validate that an error response is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.12 SUBS_NTFY_V_12 : SUBSCRIBE with Expires header as zero Test Objective : Verify that the IUT successfully parses a SUBSCRIBE request with Expires Header set to zero. Reference : RFC3265, Section 3.13.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. User is registered at IUT. Call Flow 2 has been executed to subscribe to event notification. Minakshi & Srimanta [Page 292] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a SUBSCRIBE request with Expires header as zero from the peer towards the IUT for an existing subscription. b) Verify that the SUBSCRIBE is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE procedure execution as per Call Flow 2.This is to terminate the subscription. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.13 SUBS_NTFY_V_13 : SUBSCRIBE with Expires in Contact header as zero Test Objective : Verify that the IUT successfully parses a SUBSCRIBE Request with Expires set to zero in the contact header. Reference : RFC3265, Section 3.13.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. User is registered at IUT. Call Flow 2 has been executed to subscribe to event notification. Test Description : a) Send a SUBSCRIBE request with expires in Contact header as zero from the peer towards the IUT for an existing subscription. b) Verify that the SUBSCRIBE is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE procedure execution as per Call Flow 2.This is to terminate the subscription. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.14 SUBS_NTFY_I_14 : Receipt of more than one event header in a SUBSCRIBE request Test Objective : To check that the IUT responds with an error on receipt of SUBSCRIBE with more than one Event header. Reference : RFC3265, Section 3.13.2 Applicable Messages : NOTIFY Minakshi & Srimanta [Page 293] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. User is registered at IUT. Test Description : a) Send a SUBSCRIBE request with two Event headers towards the IUT. Event: reg Event: refer b) Verify that the SUBSCRIBE parsing fails at the IUT. c) Validate that 400 Bad Request response to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.15 SUBS_NTFY_I_15 : Event header with unrecognized token Test Objective : To validate the IUT behavior when it receives Event header with unregistered token. Reference : RFC3265, Section 3.13.2 Applicable Messages : NOTIFY Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. User is registered at IUT. Test Description : a) Send a SUBSCRIBE request with two Event headers towards the IUT. Event: dialog b) Verify that the SUBSCRIBE parsing fails at the IUT. c) Validate that 489 Bad Event response to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.16 SUBS_NTFY_V_16 : 200 response with Expires header value same as that sent in SUBSCRIBE Test Objective : To verify that the IUT successfully parses a 200 OK response to SUBSCRIBE with Expires header value same as that sent in SUBSCRIBE. Minakshi & Srimanta [Page 294] Internet Draft SIP-IMS Compliance Test Plan August 2007 Reference : RFC3265, Section 3.13.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. User is registered at IUT. IUT has forwarded a SUBSCRIBE Request to the peer with Expires header set to 3600. Test Description : a) Send a 200 OK message from the peer in response to a subscribe request received from IUT. The expires header in 200 OK is as : Expires: 3600 b) Verify that the 200 OK is successfully parsed at the IUT. c) Validate normal execution as per Call Flow 2(with roles of peer and IUT reversed). --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.17 SUBS_NTFY_V_17 : 200 response with Expires header value less than that sent in SUBSCRIBE Test Objective : To verify that the IUT successfully parses a 200 OK response to SUBSCRIBE with Expires header value less than that sent in SUBSCRIBE. Reference : RFC3265, Section 3.13.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. User is registered at IUT. IUT has forwarded a SUBSCRIBE Request to the peer with Expires header set to 3600.Min-Expires configured in IUT is 90 seconds. Test Description : a) Send a 200 OK message from the peer in response to a subscribe request received from IUT. The expires header in 200 OK is as : Expires: 1800 b) Verify that the 200 OK is successfully parsed at the IUT. Minakshi & Srimanta [Page 295] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate normal execution as per Call Flow 2(with roles of peer and IUT reversed). --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.18 SUBS_NTFY_I_18 : 200 response with Expires header value greater than that sent in SUBSCRIBE Test Objective : To verify that the 200 response with Expires header value greater than that sent in SUBSCRIBE is discarded by the IUT. Reference : RFC3265, Section 3.13.1 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. User is registered at IUT. IUT has forwarded a SUBSCRIBE Request to the peer with Expires header set to 3600. Test Description : a) Send a 200 OK message from the peer in response to a subscribe request received from IUT. The expires header in 200 OK is as : Expires: 4800 b) Verify that the 200 OK parsing fails at the IUT and it is discarded. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.19 SUBS_NTFY_V_19 : SUBSCRIBE message with Event header as "presence" Test Objective : Verify the successful parsing of Event header as presence in a SUBSCRIBE message. Reference : RFC3856, Section 6 Applicable Messages : Not Applicable Pre-Requirement : IUT supports SIP Specific Event Notification [5]. IUT supports the Presence Event Package [6]. User is registered at IUT. Minakshi & Srimanta [Page 296] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a SUBSCRIBE request with presence in the Event header : o: presence b) Verify that the SUBSCRIBE is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE procedure execution as per Call Flow 2. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.20 SUBS_NTFY_V_20 : NOTIFY with Event header as "presence" Test Objective : Check that the IUT successfully parses the Event header set to presence in NOTIFY message. Reference : RFC3856, Section 6 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports the Presence Event Package [6]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with Event header as : Event: presence b) Verify that the NOTIFY is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.21 SUBS_NTFY_V_21 : SUBSCRIBE with Accept header as "application/pidf+xml" Test Objective : Check that the Accept header as "application/pidf+xml" in a SUBSCRIBE message is successfully parsed at the IUT. Reference : RFC3856, Section 6 Applicable Messages : Not Applicable Minakshi & Srimanta [Page 297] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports the Presence Event Package [6]. User is registered at IUT. Test Description : a) Send a SUBSCRIBE request with presence in the Accept header as : Accept: application/pidf+xml b) Verify that the SUBSCRIBE is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE procedure execution as per Call Flow 2. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.22 SUBS_NTFY_V_22 : SUBSCRIBE with more than one value in Accept header and one of them as "application/pidf+xml" Test Objective : To verify that the IUT successfully parses multi-valued Accept header with one of them being "application/pidf+xml". Reference : RFC3856, Section 6 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports the Presence Event Package [6]. User is registered at IUT. Test Description : a) Send a SUBSCRIBE request with presence in the Accept header as : Accept: application/reginfo+xml,application/pidf+xml b) Verify that the SUBSCRIBE is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE procedure execution as per Call Flow 2. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.23 SUBS_NTFY_V_23 : NOTIFY with the Content-Type header as "application/pidf+xml" Minakshi & Srimanta [Page 298] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective : Check that NOTIFY with the Content-type header as "application/pidf+xml" is successfully parsed at the IUT. Reference : RFC3856, Section 6 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports the Presence Event Package [6]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with Content-Type header as : Content-Type: application/pidf+xml b) Verify that the NOTIFY is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.24 SUBS_NTFY_I_24 : SUBSCRIBE with Event header as presence and without application/pidf+xml in the Accept header Test Objective : To validate the IUT behavior when "application/pidf+xml" is not present in the Accept Header values and the Event header mentions "presence". Reference : RFC3856, Section 6 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports the Presence Event Package [6]. User is registered at IUT. Test Description : a) Send a SUBSCRIBE request with presence in the Accept header as : Accept: application/reginfo+xml b) Verify that the SUBSCRIBE is successfully parsed at the IUT. Minakshi & Srimanta [Page 299] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal SUBSCRIBE procedure execution as per Call Flow 2. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.25 SUBS_NTFY_V_25 : SUBSCRIBE request with pres URI Test Objective : To verify that the IUT successfully parses pres URI in the Request-URI field of a SUBSCRIBE Request. Reference : RFC3856, Section 6 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT supports the Presence Event Package [6]. User is registered at IUT. Test Description : a) Send a SUBSCRIBE request with Request-URI as : SUBSCRIBE pres:fred@example.com SIP/2.0 b) Verify that the SUBSCRIBE is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE procedure execution as per Call Flow 2. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.26 SUBS_NTFY_V_26 : Receipt of 481 response to a SUBSCRIBE Request Test Objective : To verify that the IUT successfully parses "481 Subscription does not exist" response to a SUBSCRIBE Request. Reference : RFC3265, Section 3.13.4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. User is registered at IUT. IUT has forwarded a SUBSCRIBE Request to the peer. Test Description : a) Send a "481 Subscription does not exist" response from the peer in response to a subscribe request received from IUT. Minakshi & Srimanta [Page 300] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that the 481 response is successfully parsed at the IUT. c) ACK for the 481 response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.27 SUBS_NTFY_V_27 : "202 Accepted" response to a SUBSCRIBE Test Objective : To verify that the IUT successfully parses "202 Accepted" response to a SUBSCRIBE Request. Reference : RFC3265, Section 3.13.4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. User is registered at IUT. IUT has forwarded a SUBSCRIBE Request to the peer. Test Description : a) Send a "202 Accepted" message from the peer in response to a SUBSCRIBE request received from IUT. b) Verify that the 202 response is successfully parsed at the IUT. c) Validate the SUBSCRIBE/NOTIFY procedure execution as per RFC 3265 [5]. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.28 SUBS_NTFY_V_28 : "489 Bad Event" response Test Objective : To verify the parsing of new response code "489 Bad Event" at the IUT. Reference : RFC3265, Section 3.13.6 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. User is registered at IUT. IUT has forwarded a SUBSCRIBE Request to the peer. Event header in SUBSCRIBE is set as "session". Test Description : a) Send a "489 Bad Event" message from the peer in response to a SUBSCRIBE request. Minakshi & Srimanta [Page 301] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that the 489 response is successfully parsed at the IUT. c) ACK for the 489 response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.29 SUBS_NTFY_I_29 : "489 Bad Event" response without the Allow-Events Header Test Objective : To verify that the parsing of "489 Bad Event" without Allow-Events header fails at the IUT. Reference : RFC3265, Section 3.13.6 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. User is registered at IUT. IUT has forwarded a SUBSCRIBE Request to the peer. Event header in SUBSCRIBE is set as "session". Test Description : a) Send a "489 Bad Event" message without the Allow-Events header from the peer in response to a SUBSCRIBE request. b) Verify that the 489 response parsing fails at the IUT. c) The 489 response is discarded by the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.30 SUBS_NTFY_V_30 : "423 Subscription Too Brief" response Test Objective : To verify the parsing of "423 Subscription Too Brief" response with the Min-Expires Header at the IUT. Reference : RFC3265, Section 3.13.6 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. User is registered at IUT. IUT has forwarded a SUBSCRIBE Request to the peer. The Expires header is set to 60. Minakshi & Srimanta [Page 302] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a "423 Subscription Too Brief" message from the peer in response to a SUBSCRIBE request with Min Expires header as : Min-Expires: 3600 b) Verify that the 423 response is successfully parsed at the IUT. c) ACK for the 423 response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.31 SUBS_NTFY_V_31 : 6xx error response to SUBSCRIBE Test Objective : To check the parsing of 6xx error response to SUBSCRIBE at the IUT. Reference : RFC3265, Section 3.13.6 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. User is registered at IUT. IUT has forwarded a SUBSCRIBE Request to the peer. Test Description : a) Send a 600 error response from the peer. b) Verify that the 600 response is successfully parsed at the IUT. c) ACK for the 600 response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.32 SUBS_NTFY_V_32 : 200 OK response without an expires header Test Objective : To verify that the IUT discards a 200 OK to SUBSCRIBE without an Expires header. Reference : RFC3265, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. User is registered at IUT. IUT has forwarded a SUBSCRIBE Request to the peer. Minakshi & Srimanta [Page 303] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a 200 (OK) response from the peer, without the expires header. b) Verify that the 200 response parsing fails at the IUT and is discarded. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.1.33 SUBS_NTFY_I_33 : NOTIFY with body type not matching that of corresponding SUBSCRIBE Test Objective : To validate the IUT behavior on receipt of NOTIFY with body type not matching to that of corresponding SUBSCRIBE. Reference : RFC3265, Section 3 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. The Content-Type header is set as "application/pidf+xml" in SUBSCRIBE Test Description : a) Send a NOTIFY from the peer towards the IUT with Content-Type header as "application/sdp" b) Verify that the NOTIFY parsing fails at the IUT. c) Validate that an error response is returned to the peer. --------------------------------------------------------------------- 3.13.2 Event and Allow-Event Parsing Cases --------------------------------------------------------------------- 3.13.2.1 Event_Hdr_V_01 : Event Header with Event type as "reg" Test Objective : To verify the Event header parsing with event-type as "reg". Reference : RFC3265, Section 7.4 Applicable Messages : NOTIFY Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. User is registered at IUT. Minakshi & Srimanta [Page 304] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with Event header as : o: reg b) Verify that the SUBSCRIBE is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE procedure execution as per Call Flow 2. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.2.2 Event_Hdr_V_02 : Event-type "refer" in the Event Header Test Objective : To validate successful parsing of event-type "refer" in the Event Header. Reference : RFC3265, Section 7.4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with Event header as : Event: refer b) Verify that the NOTIFY is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.2.3 Event_Hdr_V_03 : Event Header with single event-param of type generic-param Test Objective : To verify Event header parsing containing a single event-param of type generic-param. Reference : RFC3265, Section 7.4 Applicable Messages : NOTIFY Minakshi & Srimanta [Page 305] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. User is registered at IUT. Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with Event header as : o: reg;example.com b) Verify that the SUBSCRIBE is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE procedure execution as per Call Flow 2. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.2.4 Event_Hdr_V_04 : Event-param of type id in the Event Header Test Objective : To verify Event header parsing containing a single event-param of type "id. Reference : RFC3265, Section 7.4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with Event header as : Event: refer;id=5 b) Verify that the NOTIFY is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.2.5 Event_Hdr_V_05 : Event header with more than one event-params Test Objective : To verify that the IUT successfully parses the Event header with more than one event-param. Reference : RFC3265, Section 7.4 Minakshi & Srimanta [Page 306] Internet Draft SIP-IMS Compliance Test Plan August 2007 Applicable Messages : NOTIFY Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. User is registered at IUT. Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with Event header as : o: reg;example.com;id=1 b) Verify that the SUBSCRIBE is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE procedure execution as per Call Flow 2. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.2.6 Event_Hdr_I_06 : Event header with unknown event type Test Objective : To validate the IUT behavior when it receives Event header with unregistered event-type Reference : RFC3265, Section 7.4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with event header as : Event: unkown b) Verify that the NOTIFY parsing fails at the IUT. c) Validate that an 489 error response is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.2.7 Event_Hdr_V_07 : Allow-Events Header with Event-type as "reg" Test Objective : To verify the Allow-Events header parsing with event-type as "reg" Minakshi & Srimanta [Page 307] Internet Draft SIP-IMS Compliance Test Plan August 2007 Reference : RFC3325, Section 7.4 Applicable Messages : ACK, BYE, OPTIONS, REGISTER, SUBSCRIBE, NOTIFY Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. User is registered. Test Description : a) Send an INVITE request from the peer towards the IUT with Allow-Events header as : Allow-Events: reg b) Verify that the INVITE is parsed successfully at the IUT. c) Validate the normal Call establishment and release as per Call Flow 3. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.2.8 Event_Hdr_V_08 : Allow-Events Header with Event-type as "refer" Test Objective : To validate successful parsing of event-type "refer" in the Allow-Events header. Reference : RFC3265, Section 7.4 Applicable Messages : ACK, BYE, OPTIONS, REGISTER, INVITE, NOTIFY Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. User is registered. Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with Allow-Events header as : u: refer b) Verify that the SUBSCRIBE is successfully parsed at the IUT and 200(OK) response is sent to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.2.9 Event_Hdr_V_09 : Allow-Events Header with single event-param of type generic-param Minakshi & Srimanta [Page 308] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective : To verify Allow-Events header parsing containing a single event-param of type generic-param. Reference : RFC3265, Section 7.4 Applicable Messages : ACK, BYE, OPTIONS, REGISTER, INVITE, NOTIFY Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. User is registered at IUT. Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with Allow-Events header as : u: reg;example.com b) Verify that the SUBSCRIBE is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE procedure execution as per Call Flow 2. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.2.10 Event_Hdr_V_10 : Event-param of type id in the Allow-Events Header Test Objective : To verify Allow-Events header parsing containing a single event-param of type "id. Reference : RFC3265, Section 7.4 Applicable Messages : ACK, BYE, OPTIONS, REGISTER, INVITE, SUBSCRIBE Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with Allow-Events header as : Allow-Events: refer;id=5 b) Verify that the NOTIFY is successfully parsed at the IUT. Minakshi & Srimanta [Page 309] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.2.11 Event_Hdr_V_11 : Allow-Events header with more than one event-params Test Objective : To verify that the IUT successfully parses the Allow-Events header with more than one event-param. Reference : RFC3265, Section 7.4 Applicable Messages : ACK, BYE, OPTIONS, REGISTER, INVITE, NOTIFY Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. User is registered at IUT. Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with Allow-Events header as : u: reg;example.com;id=1 b) Verify that the SUBSCRIBE is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE procedure execution as per Call Flow 2. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.2.12 Event_Hdr_I_12 : Allow-Events header with unknown event type Test Objective : To validate the IUT behavior when it receives Allow-Events header with unregistered event-type Reference : RFC3265, Section 7.4 Applicable Messages : ACK, BYE, OPTIONS, REGISTER, INVITE, SUBSCRIBE Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Minakshi & Srimanta [Page 310] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a NOTIFY from the peer towards the IUT with Allow-Events header as : Allow-Events: unkown b) Verify that the NOTIFY parsing fails at the IUT. c) Validate that an 489 error response is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.2.13 Event_Hdr_1_13 : Event Header with more than one id param Test Objective : Validate the IUT behavior when it receives an Event header with more than one id param. Reference : RFC3265, Section 7.4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. Test Description : a) Send a SUBSCRIBE request from the peer towards the IUT with Event header as : o: reg;id=6;id=89 b) Verify that the SUBSCRIBE parsing fails at the IUT and error is returned to the peer. --------------------------------------------------------------------- 3.13.3 Subscription-State Header Cases --------------------------------------------------------------------- 3.13.3.1 Subs_Hdr_V_01 : Subscription-State header with the substate-value=active Test Objective : To verify that the IUT successfully parses the Subscription-State header with the substate-value set as active. Reference : RFC3265, Section 7.4 Applicable Messages : Not Applicable Minakshi & Srimanta [Page 311] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with Subscription-State as : Subscription-State: active b) Verify that the NOTIFY is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.3.2 Subs_Hdr_V_02 : Substate-value as pending in Subscription-State header of a NOTIFY message Test Objective : Validate the parsing of Subscription-State header containing substate-value=pending. Reference : RFC3265, Section 7.4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 202 (Accepted) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with Subscription-State as : Subscription-State: pending b) Verify that the NOTIFY is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.3.3 Subs_Hdr_V_03 : Substate-value as terminated in Subscription-State header of a NOTIFY message Test Objective : Check that the Subscription-State header containing substate-value=terminated is successfully parsed at the IUT. Minakshi & Srimanta [Page 312] Internet Draft SIP-IMS Compliance Test Plan August 2007 Reference : RFC3265, Section 7.4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with Subscription-State as : Subscription-State: terminated b) Verify that the NOTIFY is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.3.4 Subs_Hdr_V_04 : Substate-value as a token in Subscription-State header of a NOTIFY message Test Objective : To verify that the IUT successfully parses the Subscription-State header with the substate-value set as a token. Reference : RFC3265, Section 7.4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Stand-by is defined as extension-substate for substate-value at IUT Test Description : a) Send a NOTIFY from the peer towards the IUT with Subscription-State as : Subscription-State: stand-by b) Verify that the NOTIFY is successfully parsed at the IUT. Minakshi & Srimanta [Page 313] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.3.5 Subs_Hdr_V_05 : Subscription-State header with substate-value and a single subexp-param set to "reason" Test Objective : Validate the parsing of sub-exp param set to reason in Subscription-State header. Reference : RFC3265, Section 7.4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with Subscription-State as : Subscription-State: terminated;reason=timeout b) Verify that the NOTIFY is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.3.6 Subs_Hdr_V_06 : Subexp-param set to "expires" in substate-value of a Subscription-State header Test Objective : Check that the Subscription-State header containing subexp-param=expires is successfully parsed at the IUT. Reference : RFC3265, Section 7.4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Minakshi & Srimanta [Page 314] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a NOTIFY from the peer towards the IUT with Subscription-State as : Subscription-State: active;expires=500 b) Verify that the NOTIFY is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.3.7 Subs_Hdr_V_07 : Subscription-State header with substate-value and a single subexp-param set to "retry-after" Test Objective : To verify that the IUT successfully parses the Subscription-State header with the subexp-param set as "retry-after". Reference : RFC3265, Section 7.4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with Subscription-State as : Subscription-State: terminated;retry-after=100 b) Verify that the NOTIFY is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.3.8 Subs_Hdr_V_08 : Subscription-State header with substate-value and a single subexp-param set as a generic param Test Objective : To check the parsing of Subscription-State header with substate-value and a single subexp-param(set to generic-param). Reference : RFC3265, Section 7.4 Applicable Messages : Not Applicable Minakshi & Srimanta [Page 315] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. wait-interval is defined as a subexp-param at IUT. Test Description : a) Send a NOTIFY from the peer towards the IUT with Subscription-State as : Subscription-State: pending;wait-interval=200 b) Verify that the NOTIFY is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.3.9 Subs_Hdr_V_09 : Subscription State header with substate-value and more than one subexp-params Test Objective : To verify Subscription-State header parsing with substate-value and two subexp-params. Reference : RFC3265, Section 7.4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with Subscription-State as : Subscription-State: terminated;reason=probation;retry-after=100 b) Verify that the NOTIFY is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.3.10 Subs_Hdr_V_10 : Subscription-State header with three subexp-params Minakshi & Srimanta [Page 316] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective : To verify that the IUT successfully parses the Subscription-State header with three subexp-params. Reference : RFC3265, Section 7.4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. wait-interval is defined as a subexp-param at IUT. Test Description : a) Send a NOTIFY from the peer towards the IUT with Subscription-State as : Subscription-State: terminated;reason=giveup;retry-after=100; wait-interval=50 b) Verify that the NOTIFY is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.3.11 Subs_Hdr_I_11 : Error response on receipt of more than one substate-value in the Subscription-State header Test Objective : Check that the IUT responds with error on receipt of more than one substate-value in Subscription-State Header. Reference : RFC3265, Section 7.4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with Subscription-State header as : Subscription-State: pending,terminated;retry-after=100 b) Verify that the NOTIFY parsing fails at the IUT. Minakshi & Srimanta [Page 317] Internet Draft SIP-IMS Compliance Test Plan August 2007 c) Validate that an error response is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.3.12 Subs_Hdr_V_12 : Event-reason-value sub field as moresource Test Objective : Check that the Subscription-State header containing event-reason-value=moresource is successfully parsed at the IUT. Reference : RFC3265, Section 7.4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with Subscription-State as : Subscription-State: terminated;reason=moresource b) Verify that the NOTIFY is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.3.13 Subs_Hdr_V_13 : Event-reason-value sub field as giveup Test Objective : Validate the parsing of Subscription-State header containing event-reason-value=giveup at the IUT. Reference : RFC3265, Section 7.4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with Subscription-State as : Subscription-State: terminated;reason=giveup Minakshi & Srimanta [Page 318] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that the NOTIFY is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.3.14 Subs_Hdr_V_14 : Event-reason-value sub field as timeout Test Objective : To verify that the IUT successfully parses the Subscription-State header with the event-reason-value=timeout. Reference : RFC3265, Section 7.4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with Subscription-State as : Subscription-State: terminated;reason=timeout b) Verify that the NOTIFY is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.3.15 Subs_Hdr_V_15 : Event-reason-value sub field as rejected Test Objective : Check that the Subscription-State header containing event-reason-value=rejected is successfully parsed at the IUT. Reference : RFC3265, Section 7.4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Minakshi & Srimanta [Page 319] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a NOTIFY from the peer towards the IUT with Subscription-State as : Subscription-State: terminated;reason=rejected b) Verify that the NOTIFY is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.3.16 Subs_Hdr_V_16 : Event-reason-value sub field as probation Test Objective : Validate the parsing of Subscription-State header containing event-reason-value=probation. Reference : RFC3265, Section 7.4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with Subscription-State as : Subscription-State: terminated;reason=probation b) Verify that the NOTIFY is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.3.17 Subs_Hdr_V_17 : Event-reason-value sub field as probation Test Objective : To verify that the IUT successfully parses the Subscription-State header with the event-reason-value=deactivated. Reference : RFC3265, Section 7.4 Applicable Messages : Not Applicable Minakshi & Srimanta [Page 320] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with Subscription-State as : Subscription-State: terminated;reason=deactivated b) Verify that the NOTIFY is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.3.18 Subs_Hdr_V_18 : Event-reason-value sub field as event-reason-extension Test Objective : Check that the Subscription-State header containing event-reason-value set to "event-reason-extension" is successfully parsed at the IUT. Reference : RFC3265, Section 7.4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. not-allowed is defined as a event-reason-value at the IUT. Test Description : a) Send a NOTIFY from the peer towards the IUT with Subscription-State as : Subscription-State: terminated;reason=not-allowed b) Verify that the NOTIFY is successfully parsed at the IUT. c) Validate the normal SUBSCRIBE/NOTIFY procedure execution. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.3.19 Subs_Hdr_I_19 : Multiple Subscription-State headers Minakshi & Srimanta [Page 321] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective : To validate the IUT behavior when it receives multiple Subscription-State headers. Reference : RFC3265, Section 7.4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with two Subscription-State headers. b) Verify that the NOTIFY parsing fails at the IUT. c) Validate that an error response is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.3.20 Subs_Hdr_I_20 : Empty Subscription-State header Test Objective : To validate the IUT behavior on receipt of empty Subscription-State header. Reference : RFC3265, Section 7.4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with empty Subscription-State header. b) Verify that the NOTIFY parsing fails at the IUT. c) Validate that an error response is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.13.3.21 Subs_Hdr_I_21 : Subscription-State header with an invalid syntax Minakshi & Srimanta [Page 322] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Objective : To check that the IUT responds with error when it receives subexp-params separated from each other by a comma instead of semicolon. Reference : RFC3265, Section 7.4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Specific Event Notification [5]. IUT has forwarded a SUBSCRIBE Request to the peer and its 200 (OK) response is received. Test Description : a) Send a NOTIFY from the peer towards the IUT with Subscription-State header as : Subscription-State: terminated,retry-after=100,reason=giveup b) Verify that the NOTIFY parsing fails at the IUT. c) Validate that an error response is returned to the peer. --------------------------------------------------------------------- 3.14 SIP Extension for Instant Messaging The extension allows the transfer of messages between users in real-time. MESSAGE requests don't create a dialog and carry the carry the content in form of MIME body parts. 3.14.1 Message Requests Cases --------------------------------------------------------------------- 3.14.1.1 Msg_V_01 : MESSAGE with body as plain/text Test Objective : To check the parsing of a MESSAGE with a body of type plain/text. Reference : RFC3428, Section 4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Extension For IM [7] User is registered. Minakshi & Srimanta [Page 323] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a MESSAGE request from the peer towards the IUT with body of type plain/text. Content-Type: text/plain b) Verify that the MESSAGE is parsed successfully at the IUT and 200 (OK) is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.14.1.2 Msg_V_02 : MESSAGE with body as message/cpim Test Objective : To check the parsing of a MESSAGE with a body of type message/cpim. Reference : RFC3428, Section 4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Extension For IM [7] User is registered. Test Description : a) Send a MESSAGE request from the peer towards the IUT with body of type message/cpim. Content-Type: message/cpim b) Verify that the MESSAGE is parsed successfully at the IUT and 200 (OK) is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.14.1.3 Msg_V_03 : MESSAGE without the Contact header Test Objective : To verify that the IUT successfully at parses MESSAGE request without the Contact header. Reference : RFC3428, Section 4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Extension For IM [7] User is registered. Minakshi & Srimanta [Page 324] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a MESSAGE request from the peer towards the IUT without the Contact header. b) Verify that the MESSAGE is parsed successfully at the IUT and 200 (OK) is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.14.1.4 Msg_I_04 : MESSAGE with a Contact header Test Objective : To validate the IUT behavior when it receives a Contact header in MESSAGE request. Reference : RFC3428, Section 4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Extension For IM [7] User is registered. Test Description : a) Send a MESSAGE request from the peer towards the IUT containing a Contact header. b) Verify that the Contact header is not processed at the IUT. c) MESSAGE request is parsed successfully at the IUT and 200 (OK) is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.14.1.5 Msg_V_05 : MESSAGE with Expires and Date Header Test Objective : To verify successful parsing of MESSAGE request containing a Expires and Date header. Reference : RFC3428, Section 4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Extension For IM [7] User is registered. Minakshi & Srimanta [Page 325] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a MESSAGE request from the peer towards the IUT containing Date and Expires headers. b) MESSAGE request is parsed successfully at the IUT and 200 (OK) is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.14.1.6 Msg_V_06 : im URI in Request URI of MESSAGE Test Objective : Check the parsing of received MESSAGE with Request URI as an im URI. Reference : RFC3428, Section 5 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Extension For IM [7] User is registered. Test Description : a) Send a MESSAGE request from the peer towards the IUT containing Request-URI of type im : MESSAGE im:user@example.com SIP/2.0 b) MESSAGE request is parsed successfully at the IUT and 200 (OK) is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.14.1.7 Msg_V_07 : sip URI in Request URI of MESSAGE Test Objective : Check the parsing of received MESSAGE with Request URI as a sip URI. Reference : RFC3428, Section 5 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Extension For IM [7] User is registered. Minakshi & Srimanta [Page 326] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a MESSAGE request from the peer towards the IUT containing Request-URI of type im : MESSAGE sip:user@example.com SIP/2.0 b) MESSAGE request is parsed successfully at the IUT and 200 (OK) is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.14.1.8 Msg_V_08 : sips URI in Request URI of MESSAGE Test Objective : Check the parsing of received MESSAGE with Request URI as a sips URI. Reference : RFC3428, Section 5 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Extension For IM [7] User is registered. Test Description : a) Send a MESSAGE request from the peer towards the IUT containing Request-URI of type im : MESSAGE sips:user@example.com SIP/2.0 b) MESSAGE request is parsed successfully at the IUT and 200 (OK) is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.14.1.9 Msg_V_09 : im URI in From and To headers of MESSAGE request Test Objective : Validate the parsing of MESSAGE received with From and To header containing URI of type im. Reference : RFC3428, Section 5 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Extension For IM [7] User is registered. Minakshi & Srimanta [Page 327] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a MESSAGE request from the peer towards the IUT containing >From and To headers of type im : From: To: b) MESSAGE request is parsed successfully at the IUT and 200 (OK) is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.14.1.10 Msg_I_10 : im URI in Route header of MESSAGE request Test Objective : Validate the IUT behavior when it receives a Route header with im URI in MESSAGE request. Reference : RFC3428, Section 5 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Extension For IM [7] User is registered. Test Description : a) Send a MESSAGE request from the peer towards the IUT containing Route of type im : Route: b) MESSAGE request parsing fails and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.14.1.11 Msg_I_11 : im URI in Route header of MESSAGE request Test Objective : Validate the IUT behavior when it receives a Record-Route header with im URI in MESSAGE request. Reference : RFC3428, Section 5 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Extension For IM [7] User is registered. Minakshi & Srimanta [Page 328] Internet Draft SIP-IMS Compliance Test Plan August 2007 Test Description : a) Send a MESSAGE request from the peer towards the IUT containing Record-Route of type im : Record-Route: b) MESSAGE request parsing fails and error is returned to the peer. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.14.1.12 Msg_I_12 : 2xx response (with body) to MESSAGE request Test Objective : Validate the IUT behavior when it receives a 2xx response to MESSAGE with a body. Reference : RFC3428, Section 7 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Extension For IM [7] User is registered. MESSAGE Request is sent to the peer. Test Description : a) Send a 200 (OK) response from the peer containing a body. b) Validate that the body is discarded by the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.14.1.13 Msg_I_13 : Contact header in 2xx response to MESSAGE request Test Objective : Validate the IUT behavior when it receives a 2xx response to MESSAGE with a Contact header. Reference : RFC3428, Section 7 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Extension For IM [7] User is registered. MESSAGE Request is sent to the peer. Test Description : a) Send a 200 (OK) response from the peer containing a Contact header. Minakshi & Srimanta [Page 329] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Validate that the header is discarded by the IUT. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.14.1.14 Msg_V_14 : Receipt of MESSAGE associated with an existing session Test Objective : To verify that the IUT successfully parses a MESSAGE received with a dialog. Reference : RFC3428, Section 4 Applicable Messages : Not Applicable Pre-Requirement : IUT Supports SIP Extension For IM [7] User is registered. A dialog exists between the peer and the IUT. Test Description : a) Send a MESSAGE request from the peer towards the IUT within an existing dialog. b) Verify that the MESSAGE is parsed successfully at the IUT and 200 (OK) is returned to the peer. --------------------------------------------------------------------- 3.15 Authentication and Authorization Header Changes For support of Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) mechanisms, new auth params, ik, ck and integrity-protected have been introduced in www-Authenticate and Authorization headers, respectively. 3.15.1 Authorization Header Cases --------------------------------------------------------------------- 3.15.1.1 Auth_V_01 : Authorization header with integrity-protected as yes Test Objective : To check the successful parsing of the auth-param field as integrity-protected with value "yes" in Authorization header of a REGISTER request. Reference : 24.229 Section 7.2A.2 Applicable Messages : Not Applicable Minakshi & Srimanta [Page 330] Internet Draft SIP-IMS Compliance Test Plan August 2007 Pre-Requirement : IUT supports AKA Authentication Scheme [11]. Test Description : a) Send a REGISTER request from the peer towards the IUT with Authorization header as : Authorization: Digest username="user1_private@example.com", realm="registrar.example.com", nonce=base64(RAND + AUTN + server specific data), algorithm=AKAv1-MD5, uri="sip:registar.example.com", response="0a1b04c89e54f09ab45e84d30e29f83a", integrity-protected="yes" b) Verify that the REGISTER is successfully parsed at the IUT. c) Validate the normal REGISTER procedure execution as per Call Flow 1. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.15.1.2 Auth_V_02 : Authorization header with integrity-protected as no Test Objective : To verify that the IUT successfully parses auth-param field as integrity-protected with value "no" in Authorization header of a REGISTER request. Reference : 24.229 Section 7.2A.2 Applicable Messages : Not Applicable Pre-Requirement : IUT supports AKA Authentication Scheme [11]. Test Description : a) Send a REGISTER request from the peer towards the IUT with Authorization header as : Authorization: Digest username="user1_private@example1.net", realm="registrar.example1.net", nonce="", uri="sip:registrar.example1.net", response="", integrity-protected="no" b) Verify that the REGISTER is successfully parsed at the IUT. c) Validate the normal REGISTER procedure execution as per Call Flow 1. --------------------------------------------------------------------- Minakshi & Srimanta [Page 331] Internet Draft SIP-IMS Compliance Test Plan August 2007 3.15.2 www-Authenticate Header Cases --------------------------------------------------------------------- 3.15.2.1 Auth_V_01 : www-Authenticate header with ik Test Objective : To validate that the IUT successfully parses the auth-param set as an "ik" in 401 response to register, in the www-Authenticate header. Reference : 24.229 Section 7.2A.1 Applicable Messages : Not Applicable Pre-Requirement : IUT supports AKA Authentication Scheme [11]. Test Description : a) Send a REGISTER request from the peer towards the IUT with auth-param ik in www-Authenticate header as : ik="00112233445566778899aabbccddeeff" (example value for ik) b) Verify that the REGISTER is successfully parsed at the IUT. c) Validate the normal REGISTER procedure execution as per Call Flow 1. --------------------------------------------------------------------- --------------------------------------------------------------------- 3.15.2.2 Auth_V_02 : www-Authenticate header with ck Test Objective : To validate that the IUT successfully parses the auth-param set as an "ck" in 401 response to register, in the www-Authenticate header. Reference : 24.229 Section 7.2A.1 Applicable Messages : Not Applicable Pre-Requirement : IUT supports AKA Authentication Scheme [11]. Test Description : a) Send a REGISTER request from the peer towards the IUT with auth-param ck in www-Authenticate header as : ck="ffeeddccbbaa11223344556677889900" (example value for ck) Minakshi & Srimanta [Page 332] Internet Draft SIP-IMS Compliance Test Plan August 2007 b) Verify that the REGISTER is successfully parsed at the IUT. c) Validate the normal REGISTER procedure execution as per Call Flow 1. --------------------------------------------------------------------- 4. Security Considerations The document is a Test Specification for protocol compliance to SIP Extensions, as per the 3GPP requirements, for a node in IMS network. Therefore, the security considerations as mentioned in the normative references, apply to this document as well. 5. References 5.1 Normative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in the Session Initiation Protocol (SIP)", RFC 3262, June 2002. [3] Willis, D., and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002. [4] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. [5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [6] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) Replaces Header", RFC 3891, September 2004. [7] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. Minakshi & Srimanta [Page 333] Internet Draft SIP-IMS Compliance Test Plan August 2007 [8] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, September 2002. [9] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004. [10] Camarillo, G., Marshall, W., Rosenberg, J., "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, June 2002. [11] Willis, D., and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration", RFC 3608, October 2003. [12] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004. [13] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004. [14] 3GPP, "TS 24.229: IP Multimedia Subsystem (IMS) (Stage 3) - Release 6", . [15] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. 5.2 Informative References [16] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. [17] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)", RFC 3455, January 2003. [18] Garcia-Martin, M., "Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP)", RFC 4083, May 2005. [19] 3GPP, "TS 23.228: IP Multimedia Subsystem (IMS) (Stage 2) - Release 6", . [20] 3GPP, "TS 24.228: Signaling flows for the IP Multimedia Call control based on SIP and SDP", . Minakshi & Srimanta [Page 334] Internet Draft SIP-IMS Compliance Test Plan August 2007 6. Acknowledgments The authors would like to thank Gayatri Singla, Siddhartha Pant, Dhiraj Malhotra, Vikas Bhola, Tauseef Hasan, Premanshu Mangla, Rajiv Pathak, AshaJyothi Kollaparthy for their insightful comments and suggestions. Author's Address Minakshi Anand ARICENT Electronic City, Plot 17, Sector 18 Gurgaon - 122015, Haryana India Email: minakshi.anand@aricent.com Srimanta Purohit ARICENT 4th Floor, Gamma Block, Sigma SoftTech Park 7 Whitefield Main Road Bangalore - 560066, Karnataka India Email: srimanta.purohit@aricent.com Minakshi & Srimanta [Page 335] Internet Draft SIP-IMS Compliance Test Plan August 2007 7. Applicable Nodes Section Applicable Nodes 3.1.1 Privacy Header P-CSCF, S-CSCF, AS 3.1.2 Privacy Mechanism - Generic P-CSCF, S-CSCF, AS 3.2.1 P-Asserted-Identity Header P-CSCF, S-CSCF, AS 3.2.2 P-Preferred-Identity Header P-CSCF 3.3.1 PRACK Support P-CSCF, S-CSCF, AS 3.4.1 P-Called-Party-Id Header P-CSCF, S-CSCF, AS 3.4.2 P-Visited-Network-ID Header S-CSCF, AS 3.4.3 P-Charging-Function-Addresses Header S-CSCF, AS 3.4.4 P-Charging-Vector Header P-CSCF, S-CSCF, AS 3.4.5 P-Access-Network-Info Header P-CSCF, S-CSCF, AS 3.4.6 P-Associated-URI Header P-CSCF 3.5.1 SUBSCRIBE/NOTIFY - REG Event Package P-CSCF, S-CSCF, AS 3.5.2 NOTIFY Xml Parsing P-CSCF 3.6.1 UPDATE Cases P-CSCF, S-CSCF, AS 3.7.1 Current-Status Sdp S-CSCF, AS 3.7.2 Confirm-Status Sdp S-CSCF, AS 3.7.3 Desired-Status Sdp S-CSCF, AS 3.7.4 Resource Management - Generic S-CSCF, AS 3.8.1 Request-Disposition Header S-CSCF, AS 3.8.2 Feature-Param P-CSCF, S-CSCF, AS 3.8.3 Accept-Contact and Reject-Contact Header P-CSCF, S-CSCF, AS 3.9.1 Path Header P-CSCF, S-CSCF, AS 3.10.1 SIP REFER - Generic P-CSCF, S-CSCF, AS 3.11.1 Replaces Header P-CSCF, S-CSCF, AS 3.12.1 Service-Route Header P-CSCF 3.13.1 SUBSCRIBE/NOTIFY Parsing P-CSCF, S-CSCF, AS 3.13.2 Event and Allow-Event Parsing P-CSCF, S-CSCF, AS 3.13.3 Subscription-State Header P-CSCF, S-CSCF, AS 3.14.1 Message Requests S-CSCF, AS 3.15.1 Authorization Header S-CSCF, AS 3.15.2 www-Authenticate Header P-CSCF Minakshi & Srimanta [Page 336] Internet Draft SIP-IMS Compliance Test Plan August 2007 Disclaimer of validity: The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. IANA Considerations This document has no actions for IANA. Minakshi & Srimanta [Page 337] Internet Draft SIP-IMS Compliance Test Plan August 2007 Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This Internet-Draft will expire on February 3, 2008 Minakshi & Srimanta [Page 338]