ETSI TS 102 027-3-2008 Methods for Testing and Specification (MTS) Conformance Test Specification for SIP (IETF RFC 3261) Part 3 Abstract Test Suite (ATS) and partial Protocol Impl.pdf

《ETSI TS 102 027-3-2008 Methods for Testing and Specification (MTS) Conformance Test Specification for SIP (IETF RFC 3261) Part 3 Abstract Test Suite (ATS) and partial Protocol Impl.pdf》由会员分享，可在线阅读，更多相关《ETSI TS 102 027-3-2008 Methods for Testing and Specification (MTS) Conformance Test Specification for SIP (IETF RFC 3261) Part 3 Abstract Test Suite (ATS) and partial Protocol Impl.pdf（40页珍藏版）》请在麦多课文档分享上搜索。

1、 ETSI TS 102 027-3 V4.2.5 (2008-01)Technical Specification Methods for Testing and Specification (MTS);Conformance Test Specification for SIP (IETF RFC 3261);Part 3: Abstract Test Suite (ATS) and partial ProtocolImplementation eXtra Information for Testing (PIXIT) proformafloppy3 ETSI ETSI TS 102 02

2、7-3 V4.2.5 (2008-01) 2 Reference RTS/MTS-0097-33 Keywords TTCN, ATS, IP, PIXIT, SIP, conformance, testing, VoIP ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregi

3、stre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice Individual copies of the present document can be downloaded from: http:/www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in content

4、s between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document

5、may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at http:/portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http:/portal.etsi.org/c

6、haircor/ETSI_support.asp Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2008. All rights reserved. DECTTM, PLUGTESTSTM, UMTST

7、M, TIPHONTM, the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. ETSI ETSI TS 102 027-3 V4.2.5 (2008-01) 3 Contents Intellectual Property

8、 Rights5 Foreword.5 1 Scope 6 2 References 6 2.1 Normative references .6 3 Definitions and abbreviations.7 3.1 Definitions7 3.2 Abbreviations .7 4 Abstract Test Method (ATM).8 4.1 Network architecture 8 4.2 Protocol architecture.8 4.3 Test System architecture 9 4.3.1 Structure9 4.3.2 Encoding/Decodi

9、ng System requirements 9 4.3.2.1 Decoding requirements .10 4.3.2.2 Encoding requirements10 4.3.3 Logging conventions.10 5 Untestable Test Purposes (TP) .10 6 ATS conventions11 6.1 Naming conventions.11 6.1.1 Type definitions 11 6.1.1.1 General11 6.1.1.2 PDU Type Definition 11 6.1.2 Template definiti

10、on.11 6.1.3 Constant declarations12 6.1.4 Enumeration declarations .12 6.1.5 Module parameter declarations.12 6.1.6 Variable declarations and formal parameters12 6.1.7 Function declarations12 6.1.8 Test Case declarations 12 6.1.8.1 General12 6.1.8.2 Test Case (TC) identifier.13 6.1.9 Timer declarati

11、ons 13 6.1.10 Group names.14 6.2 Implementation conventions 14 6.2.1 Type definitions 14 6.2.1.1 Messages .14 6.2.1.1.1 Request messages 14 6.2.1.1.2 Response messages14 6.2.1.1.3 Raw messages15 6.2.1.2 Headers .15 6.2.2 Constant definitions 17 6.2.2.1 Constants.17 6.2.2.2 External Constants 17 6.2.

12、3 Module Parameters .17 6.2.4 Template definitions .17 6.2.5 Dynamic part 17 7 PCTR conformance 17 8 PIXIT conformance18 9 ATS Conformance18 ETSI ETSI TS 102 027-3 V4.2.5 (2008-01) 4 Annex A (normative): Abstract Test Suite (ATS) .19 A.1 The ATS in TTCN-3 core (text) format .19 Annex B (normative):

13、Partial PIXIT proforma 20 B.1 Identification summary.20 B.2 ATS summary 20 B.3 Test laboratory20 B.4 Client identification21 B.5 SUT 21 B.6 Protocol layer information21 B.6.1 Protocol identification 21 B.6.2 IUT information .22 Annex C (normative): PCTR proforma .25 C.1 Identification summary.25 C.1

14、.1 Protocol conformance test report25 C.1.2 IUT identification.25 C.1.3 Testing environment.26 C.1.4 Limits and reservation26 C.1.5 Comments.26 C.2 IUT Conformance status 27 C.3 Static conformance summary .27 C.4 Dynamic conformance summary27 C.5 Static conformance review report.27 C.6 Test campaign

15、 report28 C.7 Void38 C.8 Observations.38 Annex D (informative): Bibliography.39 History 40 ETSI ETSI TS 102 027-3 V4.2.5 (2008-01) 5 Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essent

16、ial IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: “Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“, which is available from the ETSI Secretariat. Latest updates

17、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 not referenced in ETSI SR 000 314 (or the updates on the ETS

18、I 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 document is part 3 of a multi-part deliverable covering Conformance

19、Test Specification for SIP (IETF RFC 3261 1), 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 Protocol Implementation eXtra Information for Testing (PIXIT

20、) proforma“. ETSI ETSI TS 102 027-3 V4.2.5 (2008-01) 6 1 Scope The present document specifies the Abstract Test Suite (ATS) for the Session Initiation Protocol (SIP) as defined in RFC 3261 1. The objective of the present document is to provide a basis for conformance tests for SIP equipment giving a

21、 high probability of inter-operability between different manufacturers SIP equipments. Annex A provides the TTCN-3 part of the ATS. Annex B provides the Partial Protocol Implementation Extra Information for Testing (PIXIT) Proforma of the ATS. Annex C provides the Protocol Conformance Test Report (P

22、CTR) Proforma of the ATS. 2 References References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For a specific reference, subsequent revisions do not apply. Non-specific reference may be made only to a complete document or a part the

23、reof and only in the following cases: - if it is accepted that it will be possible to use all future changes of the referenced document for the purposes of the referring document; - for informative references. Referenced documents which are not found to be publicly available in the expected location

24、 might be found at http:/docbox.etsi.org/Reference. For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the reference shou

25、ld, as far as possible, remain valid for the expected life of the document. The reference shall include the method of access to the referenced document and the full network address, with the same punctuation and use of upper case and lower case letters. NOTE: While any hyperlinks included in this cl

26、ause were valid at the time of publication ETSI cannot guarantee their long term validity. 2.1 Normative references The following referenced documents are indispensable for the application of the present document. For dated references, only the edition cited applies. For non-specific references, the

27、 latest edition of the referenced document (including any amendments) applies. 1 IETF RFC 3261: “SIP: Session Initiation Protocol“. 2 ETSI ES 201 873-1: “Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 1: TTCN-3 Core Language“. 3 ETSI ES 201 873-5:

28、“Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 5: TTCN-3 Runtime Interface (TRI)“. 4 ISO/IEC 9646-4: “Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 4: Test realization“. ETSI ETSI TS 1

29、02 027-3 V4.2.5 (2008-01) 7 5 ISO/IEC 9646-5: “Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 5: Requirements on test laboratories and clients for the conformance assessment process“. 6 ISO/IEC 9646-6: “Information technology - Open Syste

30、ms Interconnection - Conformance testing methodology and framework - Part 6: Protocol profile test specification“. 7 IETF RFC 2224: “NFS URL Scheme“. 8 ETSI TS 102 027-2: “Methods for Testing and Specification (MTS); Conformance Test Specification for SIP (IETF RFC 3261); Part 2: Test Suite Structur

31、e and Test Purposes (TSS “ that are used to separate encoded values. LWS linear white spaces as defined in RFC 3261 1. Parameter name name of header parameters as defined in RFC 3261 1. ETSI ETSI TS 102 027-3 V4.2.5 (2008-01) 10Parameter value the value of a parameter as defined in RFC 3261 1. Undef

32、ined method an undefined method is a method other than: “INVITE“, “ACK“, “OPTIONS“, “BYE“, “CANCEL“ and “REGISTER“. Undefined header an undefined header is a header other than general-header, entity-header, request-header and response header as defined in RFC 3261 1. Unexpected header an unexpected

33、header is a header, which shall not be present in a specific request message. This definition complies to the definition of NOT APPLICABLE in RFC 3261 1, section 20 for request messages. 4.3.2.1 Decoding requirements TTCN-3 fields should not contain syntactic delimiters like white space, semicolon,

34、equal characters etc. in fully decoded fields. Instead the information provided by a parser shall be used to build the decoded message in TTCN-3. Decoded messages shall use the TTCN-3 enumeration types where ever appropriate, e.g. for the method and the header field name. For charstring fields the f

35、ollowing decoding rules shall be applied by the EDS: 1) Subsequent LWS shall compress to a single space character “ “. 2) Decoded parameter names shall use only lower case letters. 3) Parameter values containing an integer value shall be decoded to a TTCN-3 integer value where a TTCN-3 integer type

36、is used for a SIP parameter value. The following decoding rules shall be applied by the EDS to each received message in the following order: 1) In case a request message indicating an undefined method is received by the test system, the message shall not be passed in the TE to the ETS. However the m

37、essage is subject to logging as defined in clause 4.3.3 (“Logging conventions“). 2) In case an undefined header has been received the header field shall be decoded as UndefinedHeader field. RFC 3261 1 allows for multiple header field values of the same kind to either arrive in one or multiple occurr

38、ences of the corresponding header field. The SIP ATS has been written assuming only the first format. Therefore, should the EDS receive multiple header fields of the same kind in a SIP message, e.g. of a Via header field, it shall convert them into the equivalent single header field with multiple va

39、lues. This can be achieved by adding the value of, e.g. the second received Via header field as the last value to the value(s) of the first Via header field. 4.3.2.2 Encoding requirements Encoders shall follow all encoding rules that are defined in RFC 3261 1 when encoding structured values received

40、 from templates. This applies in particular to but it is not restricted to section 7.3.1 of RFC 3261 1. Values of type Raw shall be send to the SUT without any modification. 4.3.3 Logging conventions As the ATS defines on an abstract level the message exchange between TS and SUT the messages encoded

41、 messages send and received shall be logged. The TM entity in the TS shall provide access to this log. 5 Untestable Test Purposes (TP) This clause gives a list of TP, which are not implemented in the ATS due to the chosen ATM or other restrictions: None. ETSI ETSI TS 102 027-3 V4.2.5 (2008-01) 116 A

42、TS conventions The ATS conventions are intended to give a better understanding of the ATS, but they also describe the conventions made for the development of the ATS. These conventions shall be considered during any later maintenance or further development of the ATS. The ATS conventions contain two

43、 clauses, the naming conventions and the implementation conventions. The naming conventions describe the structure of the naming of all ATS elements. The implementation conventions describe the functional structure of the ATS. 6.1 Naming conventions 6.1.1 Type definitions This clause describes the n

44、aming conventions used for structured and unstructured types as well as for the field names of structured types. 6.1.1.1 General Type identifiers use mixed cased with the first letter of each internal word capitalized. EXAMPLE 1: RequestLine Field identifiers use mixed cased with a lowercase first l

45、etter. Internal words start with a capital letter. EXAMPLE 2: requestLine Names of type as well as field identifiers attempt to follow the naming chosen of ABNF elements (if a counterpart exists) as closely as possible. EXAMPLE 3: NameAddr hostName In case type and identifier names should give a hin

46、t on their structure the term describing the structure should be separated with an underscore (“_“) at the end of the name. EXAMPLE 4: CommaParam_List ContactBody_Union 6.1.1.2 PDU Type Definition Names of types used as PDUs follow the general conventions as defined in clause 6.1.1.1. EXAMPLE: Reque

47、st 6.1.2 Template definition Template identifiers consist of the type name, an identifier denoting whether the template is for sending or receiving and a sequential number. EXAMPLE: Request_r_1 denotes a template from type Request that is intended for reception. CommaParam_List_s_25 denotes a templa

48、te from type CommaParam_List that is intended for sending. The sequential number is used only to distinguish between templates for the same type and direction and includes no other information. ETSI ETSI TS 102 027-3 V4.2.5 (2008-01) 126.1.3 Constant declarations Identifiers for either internal or e

49、xternal constants, use only uppercase letters. Internal words are separated by an underscore (“_“). EXAMPLE: SIP_VERSION 6.1.4 Enumeration declarations While identifiers for the enumeration type follow the conventions as defined in clause 6.1.1. “Type definitions“, enumerations elements use only uppercase letters, which are suffixed by “_E“ to distinguish them from constants. Internal words are separated by an underscore character (“_“). EXAMPLE: Enumeration type FieldName Enumeration value FROM_E 6.1.5 Module parameter declarations