ETSI TS 102 027-2-2006 Methods for Testing and Specification (MTS) Conformance Test Specification for SIP (IETF RFC 3261) Part 2 Test Suite Structure and Test Purposes (TSS&TP) (V4.pdf

1、 ETSI TS 102 027-2 V4.1.1 (2006-07)Technical Specification Methods for Testing and Specification (MTS);Conformance Test Specification for SIP (IETF RFC 3261);Part 2: Test Suite Structure and Test Purposes (TSS Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“,

2、which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http:/webapp.etsi.org/IPR/home.asp). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs

3、 not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword This Technical Specification (TS) has been produced by ETSI Technical Committee Methods for Testing and Specification (MTS). The present documen

4、t is part 2 of a multi-part deliverable covering Conformance Test Specification for SIP (IETF RFC 3261), as identified below: Part 1: “Protocol Implementation Conformance Statement (PICS) proforma“; Part 2: “Test Suite Structure and Test Purposes (TSS Part 3: “Abstract Test Suite (ATS) and partial P

5、rotocol Implementation eXtra Information for Testing (PIXIT) proforma“. ETSI ETSI TS 102 027-2 V4.1.1 (2006-07) 6 1 Scope The present document provides a Test Suite Structure and Test Purposes (TSS&TP) for the Session Initiation Protocol (SIP) implementation in compliance with the relevant requireme

6、nts specified in RFC 3261 1. The present document is a new release of TS 102 027-2 (V3.1.1). 2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document. References are either specific (identified by date of publication

7、 and/or edition number or version number) or non-specific. For a specific reference, subsequent revisions do not apply. For a non-specific reference, the latest version applies. Referenced documents which are not found to be publicly available in the expected location might be found at http:/docbox.

8、etsi.org/Reference. 1 IETF RFC 3261: “SIP: Session Initiation Protocol“. 2 ISO/IEC 9646-1: “Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 1: General concepts“. 3 ISO/IEC 9646-2: “Information technology - Open Systems Interconnection - Co

9、nformance testing methodology and framework - Part 2: Abstract Test Suite specification“. 4 ISO/IEC 9646-3: “Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 3: The Tree and Tabular Combined Notation“. 5 ISO/IEC 9646: (all parts): “Informat

10、ion technology - Open Systems Interconnection - Conformance testing methodology and framework“. 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the terms and definitions given in RFC 3261 1, ISO/IEC 9646-1 2, ISO/IEC 9646-2 3, ISO/IEC 9646-3 4 and the follow

11、ing apply: callee: SIP entity that is requested to participate to a session by receiving an INVITE message caller: SIP entity that initiates a session by sending an INVITE message dialog: identifier defined as the combination of the remote address, local address, and Call-ID inopportune: test group

12、that handles invalid signalling exchanges of messages, which are properly structured and correctly encoded Invalid (I): test group that handles valid signalling exchanges of messages, which are either not properly structured or incorrectly encoded ETSI ETSI TS 102 027-2 V4.1.1 (2006-07) 7 Test Purpo

13、se (TP): non-formal high-level description of a test, mainly using text NOTE: This test description can be used as the basis for a formal test specification (e.g. Abstract Test Suite in TTCN). See ISO/IEC 9646 5. Valid (V): test group that handles valid signalling exchanges of messages, which are pr

14、operly structured and correctly encoded 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: ATS Abstract Test Suite CE Call Establishment CR Call Release I Invalid IUT Implementation Under Test MG MessaGing O inOpportuneOE Originating Endpoint PICS Protocol

15、 Implementation Conformance Statement PIXIT Protocol Implementation eXtra Information for Testing PR PRoxy RD ReDirect server RG ReGistration RR RegistraR RT RegistranT SIP Session Initiation Protocol SM Session Modification TE Terminating Endpoint TP Test Purpose TR TRansport TSS Test Suite Structu

16、re UA User Agent V Valid 4 Test Suite Structure (TSS) 4.1 Introduction 4.1.1 SIP Entities Test Purposes have been written for SIP entities according to the RFC 3261 1. Four kinds of entities are considered successively as IUT: User Agent behaving as client or Server. Registrar. Proxy (outbound and s

17、imple proxy). Redirect server. ETSI ETSI TS 102 027-2 V4.1.1 (2006-07) 8 A: caller interface B: callee interface OUTBOUND PROXY RegistrarRegistrarPROXYUser Agent Client/Server A User Agent Client/Server B REDIRECT SERVER Figure 1: SIP protocol entities 4.1.2 General assumptions Test purposes have be

18、en written for behaviours requested with “MUST“ or that appear as obvious in present form. Several proxy servers may forward the requests, but the test purposes are written from the point of view of one SIP entity only. The client can be either a user agent client or the client portion of a proxy se

19、rver. SDP has been considered as the method used to describe the session, but no test purposes have been written to check the SDP content itself as it is out of scope. Proxy, redirect server, registrar and UA shall support both UDP and TCP as transport layer. SIP entities are considered in the prese

20、nt document to be addressed with SIP-URLs, except for test purposes that validate the IUTs behaviour upon reception of non SIP-URLs. The verb “ignore“ in test purpose means that the IUT does not react with an error message and does not take into account the element to be ignored. When this element i

21、s an undefined Header field, according to RFC 3261, section 10 1, proxy shall not remove or modify it. The adjective “unknown“ means in the test purpose not defined in the standard RFC 3261 1 while “non-understood“ means unknown from the point of view of the IUT. The mandatory header fields like CAL

22、L-ID, Cseq, From, To and Via are supposed to be present in all messages as Max-Forwards in Request message without stressing this requirement in each test purpose (see sections 8.1.1 and 8.2.6 of RFC 3261 1). 4.1.3 System under test In SIP, a client can either sends its request directly to the Reque

23、st-URI or to its outbound proxy. It can also ask for SIP URL to a redirect server before sending its request. Test purpose will apply depending of the current tested configuration. Three kinds of session have been considered in the present document: Call using a proxy. Direct call with no proxy. Cal

24、l using a redirect server. ETSI ETSI TS 102 027-2 V4.1.1 (2006-07) 9 4.2 Overview of the Test Suite Structure The Test Suite Structures is based on SIP entities and assumptions as described in clause 4.1.2. Figure 2 shows the Test Suite Structure (TSS). Last Sub groups may be subdivided in three sub

25、groups: Valid behaviour (V), Invalid behaviour (I), InOpportune behaviour (O). Test Suite Main Functionalities Role Functionalities subgroups Test group Registrant V Registration Registrar V-I-O Call establishment V-Timers Call release V-I-Timers Originating Endpoint Session Modification V Call esta

26、blishment V-I-Timers Call release V-I-Timers Terminating Endpoint Session Modification V-I Request V-I Message processing Response V Client V-Timers Proxy Transaction Server V-Timers Call establishment V Call Control Redirect server Call release V Originating Endpoint Asking for capabilities Termina

27、ting Endpoint Responding for capabilities Querying for capabilities Proxy Responding for capabilities Registrant V-I Registrar V-I Originating Endpoint V-I Terminating Endpoint V-I Proxy V-I SIP Messaging Redirect Server V-I Figure 2: TSS for SIP ETSI ETSI TS 102 027-2 V4.1.1 (2006-07) 105 Test Purp

28、oses (TP) 5.1 Introduction 5.1.1 TP naming convention Table 1: TP identifier naming convention scheme Identifier: _ SIP Registration (RG), Call Control (CC), Querying for capabilities (QC), Messaging (MG) = Registrant (RT), Registrar (RR) Originating Endpoint (OE), Terminating Endpoint (TE), Proxy (

29、PR), Redirect (RD) (optional) Call Establishment (CE), Call Release (CR), Session modification (SM), Message Processing (MP) Transaction (TR), Asking for capabilities (AC), Responding for capabilities (RC). (optional) Request (RQ), Response (RS), Client (CL), Server (SE) Valid Behaviour (V), Invalid

30、 Behaviour (I), Inopportune Behaviour (O) = sequential number (001-999) 5.1.2 State Definitions during a call For more clarity and consistency, states defined in figures 5 to 8 in RFC 3261 1, have been reused in the wording of test purposes. 5.1.3 TP structure Each test purpose is decomposed in seve

31、n keywords. The TPId gives a unique identifier to each test purpose. “Status“ specifies, when a test purpose is optional, the selection condition according to RFC 3261 1 PICS document. It specifies also when is set to “Recommended“ that the requirement appears in RFC 3261 1 with a “SHOULD“ statement

32、. The group status applies to all test purposes belonging to this group. When no status is specified, mandatory shall be assumed. “Ref.“ outlines the references in RFC 3261 1 used to create the test purpose. “Purpose“ describes the objective of the test. ETSI ETSI TS 102 027-2 V4.1.1 (2006-07) 115.2

33、 Test Purposes for Registration 5.2.1 Registrant Group selection: Registration being listed as an option, the test purpose is applicable if the SUT is declared as supporting periodic registration and can behave as User Agent. Status: PICS: A.1/1 and A.2/1 5.2.1.1 Valid Behaviour TPId: SIP_RG_RT_V_00

34、1 Status: Mandatory Ref: RFC 3261 1 section 10.2. Purpose: Ensure that the IUT, in order to be registered, sends a REGISTER request to its registrar, without user name in the Request-URI and with a SIP-URI as request-URI. TPId: SIP_RG_RT_V_002 Status: Mandatory Ref: RFC 3261 1 section 10.3. Purpose:

35、 Ensure that the IUT having sent a REGISTER request is able to receive a Success (200 OK) response containing its current registration list in the Contact header and an expires parameter in the header. TPId: SIP_RG_RT_V_003 Status: PICS: A.3/1.1 Ref: RFC 3261 1 section 10.2.6. Purpose: Ensure that t

36、he IUT, in order to be registered, sends a REGISTER request to its pre-configured registrar address and without username. TPId: SIP_RG_RT_V_004 Status: PICS: A.3/1.2 Ref: RFC 3261 1 section 10.2.6. Purpose: Ensure that the IUT, in order to be registered, sends a REGISTER request to host part of addr

37、ess of record as the Request-URI and without username. TPId: SIP_RG_RT_V_005 Status: PICS: A.3/1.3 Ref: RFC 3261 1 section 10.2.6. Purpose: Ensure that the IUT, in order to be registered, sends a REGISTER request to the well-known “all SIP servers“ multicast address ““ (224.0.1.75) and without usern

38、ame. ETSI ETSI TS 102 027-2 V4.1.1 (2006-07) 12TPId: SIP_RG_RT_V_006 Status: Void TPId: SIP_RG_RT_V_007 Status: PICS: A.8/1 Ref: RFC 3261 1 sections 8.1.3.5 and 22.2. Purpose: Ensure that the IUT having sent a REGISTER request, on receipt of an Unauthorized (401 Unauthorized) response including a WW

39、W-Authenticate header, repeats its REGISTER request with an Authorization header and with an incremented Cseq value. TPId: SIP_RG_RT_V_008 Status: Mandatory Ref: RFC 3261 1 section 10.2. Purpose: Ensure that the IUT, in order to be registered, sends a REGISTER request to its registrar, with a addres

40、s-of record in the To header of type SIP URI. TPId: SIP_RG_RT_V_009 Status: Mandatory Ref: RFC 3261 1 section 10.2. Purpose: Ensure that the IUT, in order to be registered, sends a REGISTER request to its registrar, with the same URI in the From and the To header. TPId: SIP_RG_RT_V_010 Status: Manda

41、tory Ref: RFC 3261 1 section 10.2. Purpose: Ensure that the IUT, having sent a REGISTER request to which no final response was received, does not send a new registration before expiration of the initial request. TPId: SIP_RG_RT_V_011 Status: Mandatory AND PICS: A.3/4 Ref: RFC 3261 1 section 10.2. Pu

42、rpose: Ensure that the IUT having sent a REGISTER request, will increment the CSeq value by one in the next new REGISTER request with the same Call-ID. TPId: SIP_RG_RT_V_012 Status: Recommended AND PICS: A.3/4 Ref: RFC 3261 1 section 10.2.4. Purpose: Ensure that the IUT, already registered, sends at

43、 least one REGISTER request, during the shortest lifetime indicated in the Expires parameter of Contact addresses of the Success (200 OK) response it has received, using the same Call-ID as in the previous REGISTER request. ETSI ETSI TS 102 027-2 V4.1.1 (2006-07) 13TPId: SIP_RG_RT_V_013 Status: Reco

44、mmended AND PICS: A.3/3 Ref: RFC 3261 1 section 10.2.2. Purpose: Ensure that the IUT, in order to remove an existing binding sends a REGISTER request, with Expires parameter set to zero in the Contact headers or an Expires header set to 0 when Contact field is set to “*“. TPId: SIP_RG_RT_V_014 Statu

45、s: PICS: A.3/5 Ref: RFC 3261 1 section 10.2.1. Purpose: Ensure that the IUT, in order to get its registered contacts, sends a REGISTER request to its registrar without Contact header. TPId: SIP_RG_RT_V_015 Status: PICS: A.3/6 Ref: RFC 3261 1 section 10.2.1.1. Purpose: Ensure that the IUT, in order t

46、o suggest an expiration interval for its binding, sends a REGISTER request to its registrar with either an Expires header field or “expires“ Contact header parameter. TPId: SIP_RG_RT_V_016 Status: PICS: A.3/7 Ref: RFC 3261 1 section 10.2.1.2. Purpose: Ensure that the IUT, in order to order its bindi

47、ngs, to indicate a relative preference for the list in the Contact header field value, sends a REGISTER request to its registrar with “q“ Contact header parameter. TPId: SIP_RG_RT_V_017 Status: PICS: A.3/8 Ref: RFC 3261 1 section 10.2.5. Purpose: Ensure that the IUT having sent a REGISTER request is

48、 able to receive a Success (200 OK) response containing a Date header field. TPId: SIP_RG_RT_V_018 Status: PICS: A.8/1 Ref: RFC 3261 1 sections 8.1.3.5 and 22.2. Purpose: Ensure that the IUT having sent a REGISTER request, on receipt of an Unauthorized (401 Unauthorized) response including a WWW-Aut

49、henticate header, repeats its REGISTER request with an Authorization header including proper values for username, realm nonce, digest-uri and response HTTP parameters. ETSI ETSI TS 102 027-2 V4.1.1 (2006-07) 14TPId: SIP_RG_RT_V_019 Status: PICS: A.8/1 Ref: RFC 3261 1 sections 8.1.3.5 and 22.2. Purpose: Ensure that the IUT having sent a REGISTER message, on receipt of a Proxy Authentication Required (407 Proxy Authentication Required) response including a Proxy-Authenticate