ETSI TS 102 027-3 V4.2.5 (2008-01)
2022/8/16
Read ETSI TS 102 027 TS series 系列阅读笔记之:
ETSI TS 102 027-3 V4.2.5 (2008-01)
Methods for Testing and Specification (MTS);
Conformance Test Specification for SIP (IETF RFC 3261);
Part 3: Abstract Test Suite (ATS) and partial Protocol
Implementation eXtra Information for Testing (PIXIT) proforma
看起来就是概括性测试套件测试报告，以及额外实现信息的报告表。
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 high
probability of inter-operability between different manufacturer's 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 (PCTR) Proforma of the ATS.
3.1 Definitions
For the purposes of the present document, the terms and definitions given in RFC 3261 [1], ES 201 873-1 [2] and
ES 201 873-5 [3] apply.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ES 201 873-1 [2], ES 201 873-5 [3], RFC 3261 [1]
and the following apply:
ABNF Augmented BNF (for syntax specification - see RFC 2224 [7])
ATM Abstract Test Method
ATS Abstract Test Suite
BNF Backus Naur Form
CRLF Carriage Return Line Feed
EDS Encoding/Decoding System
ETS Executable Test Suite
IP Internet Protocol
IUT Implementation Under Test
MOT Means Of Testing
MTC Main Test Component
PA Platform Adapter
PCTR Protocol Conformance Test Report
PDU Protocol Data Unit
PICS Protocol Implementation Conformance Statement
PIXIT Protocol Implementation eXtra Information for Testing
PTC Parallel Test Component
SA SUT Adapter
SIP Session Initiation Protocol
SUT System Under Test
TC Test Cases
TCI TTCN-3 Control Interface
TCP Transmission Control Protocol
TE TTCN-3 Executable
TM Test Management
TP Test Purpose
TRI TTCN-3 Runtime Interface
TS Test System
TSS Test Suite Structure
TTCN-3 Testing and Test Control Notation (version 3)
UDP User Datagram Protocol
4 Abstract Test Method (ATM)
This clause describes the ATM used to test Draft IETF SIP RFC as defined in RFC 3261 [1].
4.1 Network architecture
4.2 Protocol architecture
4.3 Test System architecture
6 ATS 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 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.
ATS 命名规范。
6.1 Naming conventions
6.1.1 Type definitions
6.1.2 Template definition
6.1.3 Constant declarations
6.1.4 Enumeration declarations
6.1.5 Module parameter declarations
6.1.6 Variable declarations and formal parameters
6.1.7 Function declarations
6.1.8 Test Case declarations
6.1.8.2 Test Case (TC) identifier
The identifier of the test case is constructed in the same way as for the test purpose described in TS 102 027-2 [8]. The
identifier of a TC is built according to table 1.
Table 1: TP identifier naming convention scheme
Identifier: <protocol>_<main functionality>_<role>_<functionality>_<type>_<nn>
这里说了 test case 的命名方式。
6.1.9 Timer declarations
Two types of timers can be identified:
1) Standardized:
- Those defined in RFC 3261 [1], e.g. T1. They use exactly the same name as in the standard.
As there is a tolerance margin accepted for these timers, three values are needed:
- the maximum value allowed, which will use the suffix "_max";
- the minimum value allowed, which will use the suffix "_min";
- the value actually implemented, with no suffix;
EXAMPLE 1: T1 _max, T1_min, and T1.
标准计时器，即 RFC 3261 里定义的计时器，就用它自己的名字。注意有三个值, 比如 T1_max, T1_min, T1
2) Not standardized:
- Those not defined in the protocol standard, i.e. for execution use, e.g. a timer waiting for a response.
These timers begin with the prefix "T_", followed by a string in lowercase letters.
EXAMPLE 2: T_resp represents a timer for controlling the response time of the IUT.
非标准计时器，用 T_str 的方式命名，比如 T_resp.
6.1.10 Group names
6.2 Implementation conventions
6.2.1 Type definitions
The following clause gives an overview on the mapping of SIP messages and structures as defined in RFC 3261 [1] and
their corresponding TTCN-3 types.
规定了 RFC 3261 SIP message 与 structures, 跟 TTCN-3 types 之间的对应关系。
6.2.1.1 Messages
Distinct types have been defined for SIP request and response messages, as they have a different internal structure.
Messages are defined as a record structure containing three fields, a request/status line field, a header field and a
message body field, and a payload field which contains the whole message as it has been received in its text format. For
syntactic delimiters, like Carriage Return Line Feed (CRLF), colon ":", etc. no extra fields are defined as they are
already removed by the EDS.
6.2.1.1.1 Request messages
For all possible valid requests one generic type has been defined.
EXAMPLE: The generic request message
type record Request {
RequestLine requestLine,
MessageHeader msgHeader,
charstring messageBody optional,
Payload payload optional
}
6.2.1.1.2 Response messages
For all possible valid responses one generic type has been defined.
EXAMPLE: The generic response message
type record Response {
StatusLine statusLine,
MessageHeader msgHeader,
charstring messageBody optional,
这里给出了 request 跟 response message 的 通用类型定义： Request, Response。
6.2.1.1.3 Raw messages
For defining syntactic torture or syntactically invalid messages a distinct type Raw and its type aliases Response_Raw,
Raw_REGISTER_Request, Raw_BYE_Request, Raw_Unknown_Request and Raw_INVITE_Request have been defined.
The Raw type is defined as a charstring. Messages using these types define exactly how the message shall be
transmitted, thus giving the possibility to define the message on a character level.
EXAMPLE: A torture message
type charstring Raw
type Raw Raw_INVITE_Request;
template Raw_INVITE_Request rawMessage_s_1 =
"INVITE sip:joe@foo.com SIP/2.0" & CRLF &
"TO : " & CRLF
" sip:joe@foo.com ;" & TAB & " tag = 1918181833n" & CRLF &
"Via : SIP / 2.0" ;
The Raw type and its aliases have not been used to describe valid receiving templates. Therefore, valid receiving
templates will always use structured messages.
有时候测试时需要定一些无效的消息，可以用 Raw 类型.
6.2.1.2 Headers
The following clause defines the mapping of the header field section of a SIP message as defined in RFC 3261 [1].
For all message one message header type has been defined. These message header type include all possible header
fields that are allowed to be present in the header section of SIP messages according to RFC 3261 [1]. As individual
header fields may appear in any order in a SIP message these header types are defined as sets. Header fields which are
optional in all SIP messages use the optional keyword.
定义了 RFC 3261 里的 header field 部分的对应关系。
EXAMPLE 1: A header structure for an SIP request.
type set MessageHeader { Accept accept optional,
AcceptEncoding acceptEncoding optional,
AcceptLanguage acceptLanguage optional,
AlertInfo alertInfo optional,
Allow allow optional,
AuthenticationInfo authenticationInfo optional,
Authorization authorization optional,
CallId callId optional,
CallInfo callInfo optional,
Contact contact optional,
ContentDisposition contentDisposition optional,
ContentEncoding contentEncoding optional,
ContentLanguage contentLanguage optional,
ContentLength contentLength optional,
ContentType contentType optional,
CSeq cSeq optional,
Date date optional,
ErrorInfo errorInfo optional,
Expires expires optional,
From fromField optional,
InReplyTo inReplyTo optional,
MaxForwards maxForwards optional,
MimeVersion mimeVersion optional,
MinExpires minExpires optional,
Organization organization optional,
Priority priority optional,
ProxyAuthenticate proxyAuthenticate optional,
ProxyAuthorization proxyAuthorization optional,
ProxyRequire proxyRequire optional,
RecordRoute recordRoute optional,
ReplyTo replyTo optional,
Require require optional,
RetryAfter retryAfter optional,
Route route optional,
Server server optional,
Subject subject optional,
Supported supported optional,
Timestamp timestamp optional,
ETSI
16 ETSI TS 102 027-3 V4.2.5 (2008-01)
To toField optional,
Unsupported unsupported optional,
UserAgent userAgent optional,
Via via optional,
Warning warning optional,
WwwAuthenticate wwwAuthenticate optional,
UndefinedHeader_List undefinedHeader_List optional
}
Each header field is substructured into record and consists of at least the field fieldName.
EXAMPLE 2: The Accept header field type:
type record Accept {
FieldName fieldName (ACCEPT_E),
AcceptBody_List acceptArgs optional
}
每一个 header field 又进一步定义为一个 record，包含一个或多个 fieldName, 比如这里的record Accept.
The field name type is an enumeration type that contains an entry for each header field type. All enumerations are
capitalized and suffixed with "_E" to distinguish enumeration values from constants.
EXAMPLE 3: type enumerated FieldName {
TO_E, FROM_E, …
}
FieldName 类型是枚举类型，所有枚举都用大写并以 "_E" 结尾。
Depending on the definition of every particular header field in the ABNF [1] and its relevance to the SIP TP, types for
header field values have been defined and substructured differently. In general, every header field value is at least
structured according to its header field definition in the SIP ABNF.
header field value 类型定义，比如 charstring, integer 等。
后面还有各种定义，有空再细研究之。
6.2.2 Constant definitions
6.2.2.1 Constants
Syntactic delimiters for raw messages, e.g. "<", or "@" have been defined as constants.
EXAMPLE:
type charstring specialchar length (1);
const specialchar AT := "@";
这里是常量的定义方式。
6.2.3 Module Parameters
PICS/PIXIT parameters are defined as TTCN-3 module parameters.
6.2.4 Template definitions
Modifications of templates have been used to allow focusing on the essential parts of a test message. However these
mechanisms have to be checked very carefully as they can be counter intuitive.
7 PCTR conformance
A test laboratory, when requested by a client to produce a PCTR, is required, as specified in ISO/IEC 9646-5 [5], to
produce a PCTR conformant with the PCTR template given in annex B of ISO/IEC 9646-5 [5].
Furthermore, a test laboratory, offering testing for the ATS specification contained in annex C, when requested by a
client to produce a PCTR, is required to produce a PCTR conformant with the PCTR proforma contained in annex A.
测试实验室在测试并出具 PCTR/协议一致性测试报告时，应使用 ISO/IEC 9646-5 [5] 附件 B 的模板，并应遵循附件 A 中的格式。
8 PIXIT conformance
A test realizer, producing an executable test suite for the Abstract Test Suite (ATS) specification contained in annex C,
is required, as specified in ISO/IEC 9646-4 [4], to produce an augmented partial PIXIT proforma conformant with this
partial PIXIT proforma specification.
An augmented partial PIXIT proforma which conforms to this partial PIXIT proforma specification shall, as a
minimum, have contents which are technically equivalent to annex B. The augmented partial PIXIT proforma may
contain additional questions that need to be answered in order to prepare the Means Of Testing (MOT) for a particular
Implementation Under Test (IUT).
A test laboratory, offering testing for the ATS specification contained in annex C, is required, as specified in
ISO/IEC 9646-5 [5], to further augment the augmented partial PIXIT proforma to produce a PIXIT proforma
conformant with this partial PIXIT proforma specification.
A PIXIT proforma which conforms to this partial PIXIT proforma specification shall, as a minimum, have contents
which are technically equivalent to annex B. The PIXIT proforma may contain additional questions that need to be
answered in order to prepare the test laboratory for a particular IUT.
看起来是说了测试协议实现额外信息时要遵循的一些报告规范。
9 ATS Conformance
The test realizer, producing a Means Of Testing (MOT) and Executable Test Suite (ETS) for the present document,
shall comply with the requirements of ISO/IEC 9646-4 [4]. In particular, these concern the realization of an Executable
Test Suite (ETS) based on each ATS. The test realizer shall provide a statement of conformance of the MOT to the
present document.
An ETS which conforms to the present document shall contain test groups and test cases which are technically
equivalent to those contained in the ATS in annex C. All sequences of test events comprising an abstract test case shall
be capable of being realized in the executable test case. Any further checking which the test system might be capable of
performing is outside the scope of the present document and shall not contribute to the verdict assignment for each test
case.
Test laboratories running conformance test services using this ATS shall comply with ISO/IEC 9646-5 [5].
A test laboratory which claims to conform to this ATS specification shall use an MOT which conforms to this ATS.
啥意思？？
Annex A (normative):
Abstract Test Suite (ATS)
A.1 The ATS in TTCN-3 core (text) format
This ATS has been produced using the Testing and Test Control Notation (TTCN) according to ES 201 873-1 [2].
The TTCN-3 core (text) representation corresponding to this ATS is contained in an ASCII files (SIP_Steps.ttcn,
SIP_Messaging.ttcn, SIP_TypesAndConf.ttcn, SIP_Registration.ttcn, SIP_QueryingCapabilities.ttcn,
SIP_Templates.ttcn, SIP_CallControl.ttcn and SIP_MainModule.ttcn contained in archive ts_10202703v040201p0.zip)
which accompanies the present document.
ATS TTCN-3 格式文本，可以在附件里找到。
Where an ETSI Abstract Test Suite (in TTCN-3) is published in both core and tabular format these two forms shall be
considered equivalent. In the event that there appears to be syntactical or semantic differences between the two then the
problem shall be resolved and the erroneous format (whichever it is) shall be corrected.
Annex B (normative):
The PIXIT Proforma is based on ISO/IEC 9646-6 [6]. Any needed additional information can be found in there.
Partial PIXIT proforma
协议额外信息测试表包含下面几个表格：
B.1 Identification summary
B.2 ATS summary
B.3 Test laboratory
B.4 Client identification
B.5 SUT
B.6 Protocol layer information
B.6.1 Protocol identification
B.6.2 IUT information
Annex C (normative):
PCTR proforma
The PCTR proforma is based on ISO/IEC 9646-6 [6]. Any needed additional information can be found in there.
协议一致性测试报告
C.1 Identification summary
C.1.1 Protocol conformance test report
C.1.2 IUT identification
C.1.3 Testing environment
C.1.4 Limits and reservation
Additional information relevant to the technical contents or further use of the test report, or the rights and obligations of
the test laboratory and the client, may be given here. Such information may include restriction on the publication of the
test report.
这里写补充信息。
C.1.5 Comments
Additional comments may be given by either the client or the test laboratory on any of the contents of the PCTR, for
example, to note disagreement between the two parties.
补充建议。
C.2 IUT Conformance status
This IUT has or has not been shown by conformance assessment to be non conforming to the specified protocol
specification.
IUT 一致性判断
C.3 Static conformance summary
The PICS for this IUT is or is not consistent with the static conformance requirements in the specified protocol.
一致性总结？？
C.4 Dynamic conformance summary
The test campaign did or did not reveal errors in the IUT.
测试是否有揭示出问题。
C.5 Static conformance review report
If clause C.3 indicates non-conformance, this clause itemizes the mismatches between the PICS and the static
conformance requirements of the specified protocol specification.
C.6 Test campaign report
Table C.4
一张大表，列出了 TS 102 027-2 里的所有 TPId，及其是否选中，是否测试，判定结果，观察到的额外信息(相当于展开的 Note 或者 Ref.)。
表头如下：
ATS Reference Selected? Run? Verdict Observations (Reference to any observations made in clause C.8)
SIP_RG_RT_V_001
SIP_RG_RT_V_002
...
C.8 Observations
Additional information relevant to the technical content of the PCTR is given here.
这里写关于 PCTR/协议一致性测试报告的技术内容的额外信息。
Read ETSI TS 102 027 TS series 系列阅读笔记之:
ETSI TS 102 027-3 V4.2.5 (2008-01)
Methods for Testing and Specification (MTS);
Conformance Test Specification for SIP (IETF RFC 3261);
Part 3: Abstract Test Suite (ATS) and partial Protocol
Implementation eXtra Information for Testing (PIXIT) proforma
看起来就是概括性测试套件测试报告，以及额外实现信息的报告表。
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 high
probability of inter-operability between different manufacturer's 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 (PCTR) Proforma of the ATS.
3.1 Definitions
For the purposes of the present document, the terms and definitions given in RFC 3261 [1], ES 201 873-1 [2] and
ES 201 873-5 [3] apply.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ES 201 873-1 [2], ES 201 873-5 [3], RFC 3261 [1]
and the following apply:
ABNF Augmented BNF (for syntax specification - see RFC 2224 [7])
ATM Abstract Test Method
ATS Abstract Test Suite
BNF Backus Naur Form
CRLF Carriage Return Line Feed
EDS Encoding/Decoding System
ETS Executable Test Suite
IP Internet Protocol
IUT Implementation Under Test
MOT Means Of Testing
MTC Main Test Component
PA Platform Adapter
PCTR Protocol Conformance Test Report
PDU Protocol Data Unit
PICS Protocol Implementation Conformance Statement
PIXIT Protocol Implementation eXtra Information for Testing
PTC Parallel Test Component
SA SUT Adapter
SIP Session Initiation Protocol
SUT System Under Test
TC Test Cases
TCI TTCN-3 Control Interface
TCP Transmission Control Protocol
TE TTCN-3 Executable
TM Test Management
TP Test Purpose
TRI TTCN-3 Runtime Interface
TS Test System
TSS Test Suite Structure
TTCN-3 Testing and Test Control Notation (version 3)
UDP User Datagram Protocol
4 Abstract Test Method (ATM)
This clause describes the ATM used to test Draft IETF SIP RFC as defined in RFC 3261 [1].
4.1 Network architecture
4.2 Protocol architecture
4.3 Test System architecture
6 ATS 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 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.
ATS 命名规范。
6.1 Naming conventions
6.1.1 Type definitions
6.1.2 Template definition
6.1.3 Constant declarations
6.1.4 Enumeration declarations
6.1.5 Module parameter declarations
6.1.6 Variable declarations and formal parameters
6.1.7 Function declarations
6.1.8 Test Case declarations
6.1.8.2 Test Case (TC) identifier
The identifier of the test case is constructed in the same way as for the test purpose described in TS 102 027-2 [8]. The
identifier of a TC is built according to table 1.
Table 1: TP identifier naming convention scheme
Identifier: <protocol>_<main functionality>_<role>_<functionality>_<type>_<nn>
这里说了 test case 的命名方式。
6.1.9 Timer declarations
Two types of timers can be identified:
1) Standardized:
- Those defined in RFC 3261 [1], e.g. T1. They use exactly the same name as in the standard.
As there is a tolerance margin accepted for these timers, three values are needed:
- the maximum value allowed, which will use the suffix "_max";
- the minimum value allowed, which will use the suffix "_min";
- the value actually implemented, with no suffix;
EXAMPLE 1: T1 _max, T1_min, and T1.
标准计时器，即 RFC 3261 里定义的计时器，就用它自己的名字。注意有三个值, 比如 T1_max, T1_min, T1
2) Not standardized:
- Those not defined in the protocol standard, i.e. for execution use, e.g. a timer waiting for a response.
These timers begin with the prefix "T_", followed by a string in lowercase letters.
EXAMPLE 2: T_resp represents a timer for controlling the response time of the IUT.
非标准计时器，用 T_str 的方式命名，比如 T_resp.
6.1.10 Group names
6.2 Implementation conventions
6.2.1 Type definitions
The following clause gives an overview on the mapping of SIP messages and structures as defined in RFC 3261 [1] and
their corresponding TTCN-3 types.
规定了 RFC 3261 SIP message 与 structures, 跟 TTCN-3 types 之间的对应关系。
6.2.1.1 Messages
Distinct types have been defined for SIP request and response messages, as they have a different internal structure.
Messages are defined as a record structure containing three fields, a request/status line field, a header field and a
message body field, and a payload field which contains the whole message as it has been received in its text format. For
syntactic delimiters, like Carriage Return Line Feed (CRLF), colon ":", etc. no extra fields are defined as they are
already removed by the EDS.
6.2.1.1.1 Request messages
For all possible valid requests one generic type has been defined.
EXAMPLE: The generic request message
type record Request {
RequestLine requestLine,
MessageHeader msgHeader,
charstring messageBody optional,
Payload payload optional
}
6.2.1.1.2 Response messages
For all possible valid responses one generic type has been defined.
EXAMPLE: The generic response message
type record Response {
StatusLine statusLine,
MessageHeader msgHeader,
charstring messageBody optional,
这里给出了 request 跟 response message 的 通用类型定义： Request, Response。
6.2.1.1.3 Raw messages
For defining syntactic torture or syntactically invalid messages a distinct type Raw and its type aliases Response_Raw,
Raw_REGISTER_Request, Raw_BYE_Request, Raw_Unknown_Request and Raw_INVITE_Request have been defined.
The Raw type is defined as a charstring. Messages using these types define exactly how the message shall be
transmitted, thus giving the possibility to define the message on a character level.
EXAMPLE: A torture message
type charstring Raw
type Raw Raw_INVITE_Request;
template Raw_INVITE_Request rawMessage_s_1 =
"INVITE sip:joe@foo.com SIP/2.0" & CRLF &
"TO : " & CRLF
" sip:joe@foo.com ;" & TAB & " tag = 1918181833n" & CRLF &
"Via : SIP / 2.0" ;
The Raw type and its aliases have not been used to describe valid receiving templates. Therefore, valid receiving
templates will always use structured messages.
有时候测试时需要定一些无效的消息，可以用 Raw 类型.
6.2.1.2 Headers
The following clause defines the mapping of the header field section of a SIP message as defined in RFC 3261 [1].
For all message one message header type has been defined. These message header type include all possible header
fields that are allowed to be present in the header section of SIP messages according to RFC 3261 [1]. As individual
header fields may appear in any order in a SIP message these header types are defined as sets. Header fields which are
optional in all SIP messages use the optional keyword.
定义了 RFC 3261 里的 header field 部分的对应关系。
EXAMPLE 1: A header structure for an SIP request.
type set MessageHeader { Accept accept optional,
AcceptEncoding acceptEncoding optional,
AcceptLanguage acceptLanguage optional,
AlertInfo alertInfo optional,
Allow allow optional,
AuthenticationInfo authenticationInfo optional,
Authorization authorization optional,
CallId callId optional,
CallInfo callInfo optional,
Contact contact optional,
ContentDisposition contentDisposition optional,
ContentEncoding contentEncoding optional,
ContentLanguage contentLanguage optional,
ContentLength contentLength optional,
ContentType contentType optional,
CSeq cSeq optional,
Date date optional,
ErrorInfo errorInfo optional,
Expires expires optional,
From fromField optional,
InReplyTo inReplyTo optional,
MaxForwards maxForwards optional,
MimeVersion mimeVersion optional,
MinExpires minExpires optional,
Organization organization optional,
Priority priority optional,
ProxyAuthenticate proxyAuthenticate optional,
ProxyAuthorization proxyAuthorization optional,
ProxyRequire proxyRequire optional,
RecordRoute recordRoute optional,
ReplyTo replyTo optional,
Require require optional,
RetryAfter retryAfter optional,
Route route optional,
Server server optional,
Subject subject optional,
Supported supported optional,
Timestamp timestamp optional,
ETSI
16 ETSI TS 102 027-3 V4.2.5 (2008-01)
To toField optional,
Unsupported unsupported optional,
UserAgent userAgent optional,
Via via optional,
Warning warning optional,
WwwAuthenticate wwwAuthenticate optional,
UndefinedHeader_List undefinedHeader_List optional
}
Each header field is substructured into record and consists of at least the field fieldName.
EXAMPLE 2: The Accept header field type:
type record Accept {
FieldName fieldName (ACCEPT_E),
AcceptBody_List acceptArgs optional
}
每一个 header field 又进一步定义为一个 record，包含一个或多个 fieldName, 比如这里的record Accept.
The field name type is an enumeration type that contains an entry for each header field type. All enumerations are
capitalized and suffixed with "_E" to distinguish enumeration values from constants.
EXAMPLE 3: type enumerated FieldName {
TO_E, FROM_E, …
}
FieldName 类型是枚举类型，所有枚举都用大写并以 "_E" 结尾。
Depending on the definition of every particular header field in the ABNF [1] and its relevance to the SIP TP, types for
header field values have been defined and substructured differently. In general, every header field value is at least
structured according to its header field definition in the SIP ABNF.
header field value 类型定义，比如 charstring, integer 等。
后面还有各种定义，有空再细研究之。
6.2.2 Constant definitions
6.2.2.1 Constants
Syntactic delimiters for raw messages, e.g. "<", or "@" have been defined as constants.
EXAMPLE:
type charstring specialchar length (1);
const specialchar AT := "@";
这里是常量的定义方式。
6.2.3 Module Parameters
PICS/PIXIT parameters are defined as TTCN-3 module parameters.
6.2.4 Template definitions
Modifications of templates have been used to allow focusing on the essential parts of a test message. However these
mechanisms have to be checked very carefully as they can be counter intuitive.
7 PCTR conformance
A test laboratory, when requested by a client to produce a PCTR, is required, as specified in ISO/IEC 9646-5 [5], to
produce a PCTR conformant with the PCTR template given in annex B of ISO/IEC 9646-5 [5].
Furthermore, a test laboratory, offering testing for the ATS specification contained in annex C, when requested by a
client to produce a PCTR, is required to produce a PCTR conformant with the PCTR proforma contained in annex A.
测试实验室在测试并出具 PCTR/协议一致性测试报告时，应使用 ISO/IEC 9646-5 [5] 附件 B 的模板，并应遵循附件 A 中的格式。
8 PIXIT conformance
A test realizer, producing an executable test suite for the Abstract Test Suite (ATS) specification contained in annex C,
is required, as specified in ISO/IEC 9646-4 [4], to produce an augmented partial PIXIT proforma conformant with this
partial PIXIT proforma specification.
An augmented partial PIXIT proforma which conforms to this partial PIXIT proforma specification shall, as a
minimum, have contents which are technically equivalent to annex B. The augmented partial PIXIT proforma may
contain additional questions that need to be answered in order to prepare the Means Of Testing (MOT) for a particular
Implementation Under Test (IUT).
A test laboratory, offering testing for the ATS specification contained in annex C, is required, as specified in
ISO/IEC 9646-5 [5], to further augment the augmented partial PIXIT proforma to produce a PIXIT proforma
conformant with this partial PIXIT proforma specification.
A PIXIT proforma which conforms to this partial PIXIT proforma specification shall, as a minimum, have contents
which are technically equivalent to annex B. The PIXIT proforma may contain additional questions that need to be
answered in order to prepare the test laboratory for a particular IUT.
看起来是说了测试协议实现额外信息时要遵循的一些报告规范。
9 ATS Conformance
The test realizer, producing a Means Of Testing (MOT) and Executable Test Suite (ETS) for the present document,
shall comply with the requirements of ISO/IEC 9646-4 [4]. In particular, these concern the realization of an Executable
Test Suite (ETS) based on each ATS. The test realizer shall provide a statement of conformance of the MOT to the
present document.
An ETS which conforms to the present document shall contain test groups and test cases which are technically
equivalent to those contained in the ATS in annex C. All sequences of test events comprising an abstract test case shall
be capable of being realized in the executable test case. Any further checking which the test system might be capable of
performing is outside the scope of the present document and shall not contribute to the verdict assignment for each test
case.
Test laboratories running conformance test services using this ATS shall comply with ISO/IEC 9646-5 [5].
A test laboratory which claims to conform to this ATS specification shall use an MOT which conforms to this ATS.
啥意思？？
Annex A (normative):
Abstract Test Suite (ATS)
A.1 The ATS in TTCN-3 core (text) format
This ATS has been produced using the Testing and Test Control Notation (TTCN) according to ES 201 873-1 [2].
The TTCN-3 core (text) representation corresponding to this ATS is contained in an ASCII files (SIP_Steps.ttcn,
SIP_Messaging.ttcn, SIP_TypesAndConf.ttcn, SIP_Registration.ttcn, SIP_QueryingCapabilities.ttcn,
SIP_Templates.ttcn, SIP_CallControl.ttcn and SIP_MainModule.ttcn contained in archive ts_10202703v040201p0.zip)
which accompanies the present document.
ATS TTCN-3 格式文本，可以在附件里找到。
Where an ETSI Abstract Test Suite (in TTCN-3) is published in both core and tabular format these two forms shall be
considered equivalent. In the event that there appears to be syntactical or semantic differences between the two then the
problem shall be resolved and the erroneous format (whichever it is) shall be corrected.
Annex B (normative):
The PIXIT Proforma is based on ISO/IEC 9646-6 [6]. Any needed additional information can be found in there.
Partial PIXIT proforma
协议额外信息测试表包含下面几个表格：
B.1 Identification summary
B.2 ATS summary
B.3 Test laboratory
B.4 Client identification
B.5 SUT
B.6 Protocol layer information
B.6.1 Protocol identification
B.6.2 IUT information
Annex C (normative):
PCTR proforma
The PCTR proforma is based on ISO/IEC 9646-6 [6]. Any needed additional information can be found in there.
协议一致性测试报告
C.1 Identification summary
C.1.1 Protocol conformance test report
C.1.2 IUT identification
C.1.3 Testing environment
C.1.4 Limits and reservation
Additional information relevant to the technical contents or further use of the test report, or the rights and obligations of
the test laboratory and the client, may be given here. Such information may include restriction on the publication of the
test report.
这里写补充信息。
C.1.5 Comments
Additional comments may be given by either the client or the test laboratory on any of the contents of the PCTR, for
example, to note disagreement between the two parties.
补充建议。
C.2 IUT Conformance status
This IUT has or has not been shown by conformance assessment to be non conforming to the specified protocol
specification.
IUT 一致性判断
C.3 Static conformance summary
The PICS for this IUT is or is not consistent with the static conformance requirements in the specified protocol.
一致性总结？？
C.4 Dynamic conformance summary
The test campaign did or did not reveal errors in the IUT.
测试是否有揭示出问题。
C.5 Static conformance review report
If clause C.3 indicates non-conformance, this clause itemizes the mismatches between the PICS and the static
conformance requirements of the specified protocol specification.
C.6 Test campaign report
Table C.4
一张大表，列出了 TS 102 027-2 里的所有 TPId，及其是否选中，是否测试，判定结果，观察到的额外信息(相当于展开的 Note 或者 Ref.)。
表头如下：
ATS Reference Selected? Run? Verdict Observations (Reference to any observations made in clause C.8)
SIP_RG_RT_V_001
SIP_RG_RT_V_002
...
C.8 Observations
Additional information relevant to the technical content of the PCTR is given here.
这里写关于 PCTR/协议一致性测试报告的技术内容的额外信息。
浙公网安备 33010602011771号