SIST-TS TS 102 027-1 V2.1.1:2004
(Main)Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON); Technology Compliance Specification; Draft IETF SIP RFC 3261; Part 1: Test Suite Structure and Test Purposes (TSS&TP) specification
Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON); Technology Compliance Specification; Draft IETF SIP RFC 3261; Part 1: Test Suite Structure and Test Purposes (TSS&TP) specification
Design of Test Suite Structure and implementation of Test Purposes for conformance testing of an draft IETF SIP RFC 3261 protocol implementation.
Harmonizacija telekomunikacij in internetnega protokola prek omrežij (TIPHON) - Specifikacija tehnološke ustreznosti - Osnutek IETF SIP RFC 3261 - 1. del: Specifikacija zgradbe preskušalnega niza in namenov preskušanja (TSS&TP)
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
01-april-2004
Harmonizacija telekomunikacij in internetnega protokola prek omrežij (TIPHON) -
Specifikacija tehnološke ustreznosti - Osnutek IETF SIP RFC 3261 - 1. del:
Specifikacija zgradbe preskušalnega niza in namenov preskušanja (TSS&TP)
Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON);
Technology Compliance Specification; Draft IETF SIP RFC 3261; Part 1: Test Suite
Structure and Test Purposes (TSS&TP) specification
Ta slovenski standard je istoveten z: TS 102 027-1 Version 2.1.1
ICS:
33.020 Telekomunikacije na splošno Telecommunications in
general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
Technical Specification
Telecommunications and Internet Protocol
Harmonization Over Networks (TIPHON)
Technology Compliance Specification;
Draft IETF SIP RFC3261;
Part 1: Test Suite Structure and
Test Purposes (TSS&TP) specification
2 ETSI TS 102 027-1 V2.1.1 (2003-10)
Reference
RTS/TIPHON-06021-1[2]
Keywords
IP, SIP, telephony, testing, TSS&TP, 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 enregistrée à la
Sous-Préfecture 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 contents 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 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, send your comment to:
editor@etsi.org
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 2003.
All rights reserved.
TM TM TM
DECT , PLUGTESTS and UMTS are Trade Marks of ETSI registered for the benefit of its Members.
TM
TIPHON and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI
3 ETSI TS 102 027-1 V2.1.1 (2003-10)
Contents
Intellectual Property Rights.5
Foreword.5
1 Scope .6
2 References .6
3 Definitions and abbreviations.6
3.1 Definitions.6
3.2 Abbreviations .7
4 Test Suite Structure (TSS).7
4.1 Introduction .7
4.1.1 SIP Entities .7
4.1.2 General assumptions.8
4.1.3 System under test.9
4.2 Overview of the Test Suite Structure (TSS).9
5 Test Purposes (TP) .11
5.1 Introduction .11
5.1.1 TP naming convention.11
5.1.2 State Definitions during a call.11
5.1.3 TP structure.11
5.2 Test Purposes for Registration.12
5.2.1 Registrant.12
5.2.1.1 Valid Behaviour .12
5.2.2 Registrar.14
5.2.2.1 Valid Behaviour .14
5.2.2.2 Invalid Behaviour.18
5.2.2.3 Inopportune Behaviour.18
5.3 Test Purposes for Call Control .19
5.3.1 Originating Endpoint .19
5.3.1.1 Call establishment .19
5.3.1.1.1 Valid Behaviour.19
5.3.1.1.2 Timers.28
5.3.1.2 Call release.30
5.3.1.2.1 Valid Behaviour.30
5.3.1.2.2 Invalid Behaviour .33
5.3.1.2.3 Timers.33
5.3.1.3 Session modification .35
5.3.1.3.1 Valid Behaviour.35
5.3.2 Terminating Endpoint .35
5.3.2.1 Call establishment .35
5.3.2.1.1 Valid Behaviour.35
5.3.2.1.2 Invalid Behaviour .42
5.3.2.1.3 Timers.42
5.3.2.2 Call release.44
5.3.2.2.1 Valid Behaviour.44
5.3.2.2.2 Invalid Behaviour .48
5.3.2.2.3 Timers.49
5.3.2.3 Session modification .49
5.3.2.3.1 Valid Behaviour.49
5.3.2.3.2 Invalid Behaviour .50
5.3.3 Proxy.50
5.3.3.1 Message processing.50
5.3.3.1.1 Request .50
5.3.3.1.2 Response.63
5.3.3.1.2.1 Valid Behaviour.63
ETSI
4 ETSI TS 102 027-1 V2.1.1 (2003-10)
5.3.3.2 Transaction.74
5.3.3.2.1 Client .74
5.3.3.2.2 Server .79
5.3.4 Redirect Server .86
5.3.4.1 Call establishment .86
5.3.4.1.1 Valid Behaviour.86
5.3.4.2 Call release.88
5.3.4.2.1 Valid Behaviour.88
5.4 Test Purposes for Messaging.88
5.4.1 Registrant.88
5.4.1.1 Valid Behaviour .88
5.4.1.2 Invalid Behaviour.90
5.4.2 Registrar.90
5.4.2.1 Valid Behaviour .91
5.4.2.2 Invalid Behaviour.93
5.4.3 Originating Endpoint .94
5.4.3.1 Valid Behaviour .94
5.4.3.2 Invalid Behaviour.97
5.4.4 Terminating Endpoint .99
5.4.4.1 Valid Behaviour .99
5.4.4.2 Invalid Behaviour.101
5.4.5 Proxy.103
5.4.5.1 Valid Behaviour .103
5.4.5.2 Invalid Behaviour.106
5.4.6 Redirect server .107
5.4.6.1 Valid Behaviour .107
5.4.6.2 Invalid Behaviour.110
History .112
ETSI
5 ETSI TS 102 027-1 V2.1.1 (2003-10)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential 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 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 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 Project Telecommunications and Internet Protocol
Harmonization Over Networks (TIPHON).
The present document is part 1 of a multi-part deliverable covering Telecommunications and Internet Protocol
Harmonization Over Networks (TIPHON); Conformance Testing for TIPHON Release 3; TIPHON profile for Session
Initiation Protocol (SIP), as identified below:
Part 1: "Test Suite Structure and Test Purposes (TSS&TP) specification";
Part 2: "Abstract Test Suite (ATS) and partial Protocol Implementation eXtra Information for Testing (PIXIT)
proforma specification".
ETSI
6 ETSI TS 102 027-1 V2.1.1 (2003-10)
1 Scope
The present document proposes a Test Suite Structure and Test Purposes (TSS&TP) for the SIP protocol as described in
RFC 3261, "Session Initiation Protocol" issued in June 2002.
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 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.etsi.org/Reference.
[1] IETF RFC 3261: "SIP: Session Initiation Protocol".
[2] IETF RFC 2327: "SDP: Session Description Protocol".
[3] ISO/IEC 9646-1: "Information technology - Open Systems Interconnection - Conformance testing
methodology and framework - Part 1: General concepts".
[4] ISO/IEC 9646-2: "Information technology - Open Systems Interconnection - Conformance testing
methodology and framework - Part 2: Abstract Test Suite specification".
[5] ISO/IEC 9646-3: "Information technology - Open Systems Interconnection - Conformance testing
methodology and framework - Part 3: The Tree and Tabular Combined Notation".
[6] ETSI ETS 300 406: "Methods for Testing and Specification (MTS); Protocol and profile
conformance testing specifications; Standardization methodology".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
• terms defined in RFC 3261 [1];
• terms defined in ISO/IEC 9646-1, -2 and -3 ([3], [4] and [5]).
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 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
7 ETSI TS 102 027-1 V2.1.1 (2003-10)
Test Purpose (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.
Valid (V): test group that handles valid signalling exchanges of messages, which are properly 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 Inopportune
OE Originating Endpoint
PIXIT Protocol Implementation eXtra Information for Testing
PR Proxy
RD ReDirect Server
RG Registration
RR RegistraR
RT RegistranT
SM Session Modification
TE Terminating Endpoint
TP Test Purpose
TSS Test Suite Structure
UA User Agent
UAC User Agent Client
UAS User Agent Server
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].
Three kinds of entities are considered successively as IUT:
• User Agent behaving as client or Server.
• Proxy (outbound and simple proxy).
• Redirect Server.
ETSI
8 ETSI TS 102 027-1 V2.1.1 (2003-10)
OUTBOUND
User Agent User Agent
PROXY
….
Client/Server Client/Server
PROXY
…
A B
Registrar
REDIRECT SERVER
A: caller
Registrar B: callee
Figure 1: SIP protocol entities
4.1.2 General assumptions
Test Purposes have been written for behaviours requested with "MUST" and conditional "SHOULD" as recommended
test.
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 server.
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 the scope of the present document.
Proxy, redirect server and registrar shall support both UDP and TCP as transport layer while UA shall support at least
UDP.
SIP entities are considered in the present document to be addressed with SIP-URIs, except for test purposes that validate
the IUT's behaviour upon reception of non SIP-URIs.The features listed below are not covered by the present document.
Reasons are described along with their description:
• ICMP Handling:
- RFC 3261 [1] states that host, network, port, parameter or protocol errors SHOULD be treated as a 4xx
response (Client-Server), which SHOULD therefore cause the server to cease retransmitting the
response. Others (source quench ICMP messages and TTL exceeds) SHOULD be ignored.
• Timers T1, T2 (14.3.1 [1]):
- RFC 3261 [1] states that retransmission of requests other than INVITE and ACK SHOULD be
implemented when a SIP client is using an unreliable protocol (UDP).
• OPTION (8 [1]):
- RFC 3261 [1] states that the OPTION method MUST be supported, but MAY be answered. Therefore,
there is no guarantee that the IUT will respond to an option message. A Test Purpose is then not
applicable.
ETSI
9 ETSI TS 102 027-1 V2.1.1 (2003-10)
• 380 (Alternative Service) message:
- RFC 3261 [1] states that this message indicates, for an unsuccessful call, that Alternative services are
possible. But, the alternative services are described in the message body content, which is not considered.
• TLS:
- Encrypted transport TLS cannot run over UDP that is the default transport used in the following test.
Additionally TLS is optional for UA.
• SIPS URI:
- As TLS is not covered, the SIPS URIs are not covered too.
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 is an undefined Header field, according to 10 [1], proxy shall not
remove or modify it.
The adjective "unknown" means in the test purpose not defined in the standard [1] while "non-understood" means
unknown from the point of view of the IUT.
The mandatory headers like Call-ID, CSeq, From, To, Via are supposed to be present in all messages as Max-Forwards
in Request message without stressing those requirements in each test purpose (see clauses 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 Request-URI or to its outbound proxy. It can also ask for
SIP-URI to a redirect server before sending its request. Test purpose will apply depending of the current tested
configuration.
Three kinds of session have been consider in the present document:
• Call using a proxy.
• Direct call with no proxy.
• Call using a redirect server.
4.2 Overview of the Test Suite Structure (TSS)
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 subgroups: Valid behaviour (V), Invalid behaviour (I), Inopportune
behaviour (O).
ETSI
10 ETSI TS 102 027-1 V2.1.1 (2003-10)
Test Suite Main Functionalities Role Functionalities subgroups Test group
SIP Registration Registrant V
Registrar V-I-O
Call Control Originating Endpoint Call establishment V-Timers
Call release V-I-Timers
Session Modification V
Terminating Endpoint Call establishment V-I-Timers
Call release V-I-Timers
Session Modification V-I
Proxy Message processing Request V-I
Response V
Transaction Client V-Timers
Server V-Timers
Redirect server Call establishment V
Call release V
Messaging Registrant V-I
Registrar V-I
Originating Endpoint V-I
Terminating Endpoint V-I
Proxy V-I
Redirect Server V-I
Figure 2: TSS for SIP
ETSI
11 ETSI TS 102 027-1 V2.1.1 (2003-10)
5 Test Purposes (TP)
5.1 Introduction
5.1.1 TP naming convention
Table 1: TP identifier naming convention scheme
Identifier: _
SIP
Messaging (MG).
Registrant (RT), Registrar (RR)
Originating Endpoint (OE), Terminating Endpoint (TE),
Proxy (PR), Redirect (RD).
(optional) Call Establishment (CE), Call Release(CR),
Session modification (SM), Message processing
(MP),
Transaction (TR).
(optional) Request (RQ), Response(RS), Client(CL), Server(SE)
Valid Behaviour (V), Invalid Behaviour (I),
Inopportune Behaviour (O), Timers (TI).
sequential number (001-999).
5.1.2 State Definitions during a call
For more clarity and consistency, states defined in figures 5 and 7 in [1], have been reused in the wording of test
purposes.
5.1.3 TP structure
Each test purpose is decomposed in seven keyword.
• "TPId" gives a unique identifier to each test purpose.
• "Status" specifies whether the test purpose or the group is mandatory or optional according to in
RFC 3261 [1]. The group status applies to all test purposes belonging to this group.
• "Ref." outlines the references in RFC 3261 [1] used to create the test purpose.
• "Purpose" describes the objective of the test.
ETSI
12 ETSI TS 102 027-1 V2.1.1 (2003-10)
5.2 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: Optional
5.2.1.1 Valid Behaviour
TPId: SIP_RG_RT_V_001
Status: Mandatory
Ref: 10.2 [1]
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: 10.3 [1]
Purpose: 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: Optional
Ref: 10.2.6 [1]
Purpose: Ensure that the IUT, in order to be registered, sends a REGISTER request to the its pre-configured
registrar address and without username.
TPId: SIP_RG_RT_V_004
Status: Optional
Ref: 10.2.6 [1]
Purpose: Ensure that the IUT, in order to be registered, sends a REGISTER request to host part of address
of record as the Request-URI and without username.
TPId: SIP_RG_RT_V_005
Status: Optional
Ref: 10.2.6 1
Purpose: Ensure that the IUT, in order to be registered, sends a REGISTER request to the well-known "all
SIP servers" multicast address "sip.mcast.net" (224.0.1.75) and without username.
ETSI
13 ETSI TS 102 027-1 V2.1.1 (2003-10)
TPId: SIP_RG_RT_V_006
Status: Mandatory
Ref: 10.2.4 [1]
Purpose: Ensure that the IUT, already registered, sends at least one REGISTER request, during the shortest
lifetime indicated in the Contact parameters of the Success (200 OK) response it has received.
TPId: SIP_RG_RT_V_007
Status: Recommended
Ref: 8.1.3.5 [1], 22.2 [1]
Purpose: Ensure that the IUT having sent a REGISTER message, on receipt of an Unauthorized (401
Unauthorized) response including a WWW-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: 10.2 [1]
Purpose: Ensure that the IUT, in order to be registered, sends a REGISTER request to its registrar, with a
address-of record in the To header of type SIP URI.
TPId: SIP_RG_RT_V_009
Status: Mandatory
Ref: 10.2 [1]
Purpose: Ensure that the IUT, in order to be registered, sends a REGISTER request to its registrar, wit the
same URI in the From and the To header.
TPId: SIP_RG_RT_V_010
Status: Mandatory
Ref: 10.2 [1]
Purpose: Ensure that the IUT having sent a REGISTER request, does not send a new registration before the
REGISTER request has timed out in case of no final response is received.
TPId: SIP_RG_RT_V_011
Status: Mandatory
Ref: 10.2 [1]
Purpose: 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.
ETSI
14 ETSI TS 102 027-1 V2.1.1 (2003-10)
TPId: SIP_RG_RT_V_012
Status: Recommended
Ref: 10.2.4 [1]
Purpose: Ensure that the IUT, already registered, sends at least one REGISTER request, during the shortest
lifetime indicated in the Contact parameters of the Success (200 OK) response it has received,
using the same Call-ID as in the previous REGISTER request.
TPId: SIP_RG_RT_V_013
Status: Recommended
Ref: 10.2.2 [1]
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 "*".
5.2.2 Registrar
GroupSelection: IUT is a proxy or a redirect server entity
5.2.2.1 Valid Behaviour
TPId: SIP_RG_RR_V_001
Status: Mandatory
Ref: 10.3 [1]
Purpose: Ensure that the IUT on receipt of a REGISTER and without user name in the Request-URI, sends
a Success (200 OK) response, containing all current bindings listed in the Contact header, with the
expires parameter for each Contact value.
TPId: SIP_RG_RR_V_002
Status: Mandatory
Ref: 10.3 [1]
Purpose: Ensure that the IUT on receipt of a REGISTER request including multiple Contact header sends a
Success (200 OK) response, and adds these addresses to the current bindings list.
TPId: SIP_RG_RR_V_003
Status: Mandatory
Ref: 10.2 [1], 10.3 [1]
Purpose: Ensure that the IUT on receipt of a successive REGISTER with the same Call-ID but with
different Contact header answers successively each of them with a Success (200 OK) response,
and adds these addresses to the current bindings list.
ETSI
15 ETSI TS 102 027-1 V2.1.1 (2003-10)
TPId: SIP_RG_RR_V_004
Status: Optional
Ref: 10.2 [1], 10.3 [1]
Purpose: Ensure that the IUT on receipt of a REGISTER request including a From header addressing a
different entity than that addressed by the To header (third party registration), sends a Success
(200 OK) response.
TPId: SIP_RG_RR_V_005
Status: Mandatory
Ref: 10.2 [1], 10.3 [1]
Purpose: Ensure that the IUT on receipt of periodic REGISTER request with the same Call-ID and Contact
header, and with an increasing CSeq number answers each of them with a Success (200 OK)
response.
TPId: SIP_RG_RR_V_006
Status: Mandatory
Ref: 10.3 [1], 10.2 [1]
Purpose: Ensure that the IUT when the UA is already registered, on receipt of REGISTER request without
Contact header, sends a Success (200 OK) response including the expiration time of the
registration in an expires parameter in theContact header.
TPId: SIP_RG_RR_V_007
Status: Mandatory
Ref: 10.3 [1], 10.2 [1]
Purpose: Ensure that the IUT on receipt of a REGISTER request including an Expires header, sends a
Success (200 OK) response.
TPId: SIP_RG_RR_V_008
Status: Mandatory
Ref: 10.3 [1], 10.2 [1]
Purpose: Ensure that the IUT on receipt of a REGISTER request including an Expires parameter in the
Contact header, sends a Success (200 OK) response.
TPId: SIP_RG_RR_V_009
Status: Mandatory
Ref: 10.3 [1], 20.10 [1]
Purpose: Ensure that the IUT on receipt of a REGISTER request including a Contact header without display
name, sends a Success (200 OK) response.
ETSI
16 ETSI TS 102 027-1 V2.1.1 (2003-10)
TPId: SIP_RG_RR_V_010
Status: Mandatory
Ref: 10.3 [1]
Purpose: Ensure that the IUT when a binding already registered, on receipt of a REGISTER request
including a Contact header set to * and an Expires header set to zero, and Call-ID is the same as
the stored Call-ID value and CSeq is greater than the stored CSeq value of that binding, removes
that binding and sends a Success (200 OK) response.
TPId: SIP_RG_RR_V_011
Status: Mandatory
Ref: 10.3 [1]
Purpose: Ensure that the IUT when a binding already registered, on receipt of a REGISTER request
including a Contact header set to * and an Expires header set to zero, and Call-ID is different from
the stored Call-ID value of that binding, removes that binding and sends a Success (200 OK)
response.
TPId: SIP_RG_RR_V_012
Status: Mandatory
Ref: 10.3 [1]
Purpose: Ensure that the IUT when a binding already registered, on receipt of a REGISTER request
including a Contact header set to an address which is not in the bindings list, and the received
expiration time other than zero, and Call-ID is different from the stored Call-ID value of that
binding, adds that binding to the list and sends a Success (200 OK) response.
TPId: SIP_RG_RR_V_013
Status: Mandatory
Ref: 10.3 [1]
Purpose: Ensure that the IUT when a binding already registered, on receipt of a REGISTER request
including a Contact header set to an address which is in the bindings list with a Call-ID different
from the value stored for that binding, and an expiration time other than zero, sends a Success (200
OK) response.
TPId: SIP_RG_RR_V_014
Status: Mandatory
Ref: 10.3 [1]
Purpose: Ensure that the IUT when a binding already registered, on receipt of a REGISTER request
including a Contact header set to an address which is in the bindings list with a Call-ID different
from the value stored for that binding, and an expiration time set to zero, deletes that binding and
sends a Success (200 OK) response.
ETSI
17 ETSI TS 102 027-1 V2.1.1 (2003-10)
TPId: SIP_RG_RR_V_015
Status: Mandatory
Ref: 10.3 [1]
Purpose: Ensure that the IUT when a binding already registered, on receipt of a REGISTER request
including a Contact header set to an address which is in the bindings list with the same Call-ID as
the value stored for that binding, CSeq is greater than the stored CSeq value of that binding, and an
expiration time other than zero, sends a Success (200 OK) response.
TPId: SIP_RG_RR_V_016
Status: Mandatory
Ref: 10.3 [1]
Purpose: Ensure that the IUT when a binding already registered, on receipt of a REGISTER request
including a Contact header set to an address which is in the bindings list with the same Call-ID as
the value stored for that binding, CSeq is greater than the stored CSeq value of that binding, and an
expiration time equal to zero, deletes that binding and sends a Success (200 OK) response.
TPId: SIP_RG_RR_V_017
Status: Mandatory
Ref: 10.3 [1]
Purpose: Ensure that the IUT when a call is currently established, on receipt of a REGISTER request, sends
a Success (200 OK) response.
TPId: SIP_RG_RR_V_018
Status: Recommended
Ref: 10.3 [1] item 3 and 22.2 [1]
Purpose: Ensure that the IUT on receipt of a REGISTER request not including an Authorization header
field, sends an Unauthorized (401 Unauthorized) response, containing a WWW-Authenticate
header.
TPId: SIP_RG_RR_V_019
Status: Recommended
Ref: 10.3 [1] item 4
Purpose: Ensure that the IUT on receipt of a REGISTER request, but the authenticated user not authorized
to modify this address-of record, sends a Forbidden (403 Forbidden) response.
ETSI
18 ETSI TS 102 027-1 V2.1.1 (2003-10)
5.2.2.2 Invalid Behaviour
TPId: SIP_RG_RR_I_001
Status: Mandatory
Ref: 10.3 [1]
Purpose: Ensure that the IUT on receipt of a REGISTER request including a To header from which the
extracted address-of-record is not valid for the domain in the Request-URI, sends a Request
Failure (404 Not Found) response.
TPId: SIP_RG_RR_I_002
Status: Mandatory
Ref: 10.3 [1] , 19.1.1 [1]
Purpose: Ensure that the IUT on receipt of a REGISTER request including a user name in the SIP URI as
the Request-URI, sends a Success (200 OK) response.
TPId: SIP_RG_RR_I_003
Status: Mandatory
Ref: 10.3 [1]
Purpose: Ensure that the IUT on receipt of a REGISTER request including a Contact header set to "*"
together with an additional Contact header, sends a Client error (400 Bad Request) response.
TPId: SIP_RG_RR_I_004
Status: Mandatory
Ref: 10.3 [1]
Purpose: Ensure that the IUT on receipt of a REGISTER request including a Contact header set to "*", and
an Expires header with an expiration time set to other than zero, sends a Client error (400 Bad
Request) response.
5.2.2.3 Inopportune Behaviour
TPId: SIP_RG_RR_O_001
Status: Mandatory
Ref: 10.3 [1]
Purpose: Ensure that the IUT when a binding already registered, on receipt of a REGISTER request
including a Contact header set to * and an Expires header set to zero, and Call-ID is the same as
the stored Call-ID value and CSeq is equal to the stored CSeq value of that binding, does not
remove that binding and sends a Success (200 OK) response.
ETSI
19 ETSI TS 102 027-1 V2.1.1 (2003-10)
TPId: SIP_RG_RR_O_002
Status: Mandatory
Ref: 10.3 [1]
Purpose: Ensure that the IUT when a binding already registered, on receipt of a REGISTER request
including a Contact header set to an address which is in the bindings list with the same Call-ID as
the value stored for that binding, CSeq is equal to the stored CSeq value of that binding, and an
expiration time other than zero, sends a Server Failure (500 Server Error) response.
TPId: SIP_RG_RR_O_003
Status: Mandatory
Ref: 10.3 [1]
Purpose: Ensure that the IUT when a binding already registered, on receipt of a REGISTER request
including a Contact header set to an address which is in the bindings list with the same Call-ID as
the value stored for that binding, CSeq is equal to the stored CSeq value of that binding, and an
expiration time equal to zero, does not remove that binding and sends a Server Failure (500 Server
Error) response.
5.3 Test Purposes for Call Control
Ref: 1.4.4 [1]
5.3.1 Originating Endpoint
Group Selection: IUT can behave as User Agent client.
5.3.1.1 Call establishment
5.3.1.1.1 Valid Behaviour
TPId: SIP_CC_OE_CE_V_001
Status: Mandatory
Ref: 8.1.1 [1]
Purpose: Ensure that the IUT, to establish a call sends an INVITE request including at least To, From,
CSeq, Call-ID, Max-Forwards, Contact and Via headers.
TPId: SIP_CC_OE_CE_V_002
Status: Recommended
Ref: 8.1.1 [1]
Purpose: Ensure that the IUT, to establish a call sends an INVITE request with a Request-URI set to the
same URI value of the To header.
ETSI
20 ETSI TS 102 027-1 V2.1.1 (2003-10)
TPId: SIP_CC_OE_CE_V_003
Status: Mandatory
Ref: 8.1.1.2 [1]
Purpose: Ensure that the IUT, to establish a call sends an INVITE request including a To header set to an
address of the callee and without TAG parameter.
TPId: SIP_CC_OE_CE_V_004
Status: Mandatory
Ref: 8.1.1.3 [1]
Purpose: Ensure that the IUT, to establish a call sends an INVITE request including a From header with a
TAG parameter.
TPId: SIP_CC_OE_CE_V_005
Status: Mandatory
Ref: 8.1.1.5 [1]
Purpose: Ensure that the IUT, to establish a call sends an INVITE request including a CSeq header with a
method that matches "INVITE".
TPId: SIP_CC_OE_CE_V_006
Status: Recommended
Ref: 8.1.1.6 [1]
Purpose: Ensure that the IUT, to establish a call sends an INVITE request including a Max-Forward header
set to 70.
TPId: SIP_CC_OE_CE_V_007
Status: Mandatory
Ref: 8.1.1.7 [1]
Purpose: Ensure that the IUT, to establish a call sends an INVITE request including a Via header with a
protocol name set to SIP, a protocol version set to 2.0 and a branch parameter set to a value
beginning with "z9hG4bK".
TPId: SIP_CC_OE_CE_V_008
Status: Recommended
Ref: 13.2.1 [1]
Purpose: Ensure that the IUT, to establish a call sends an INVITE request including Allow and Supported
headers.
ETSI
21 ETSI TS 102 027-1 V2.1.1 (2003-10)
TPId: SIP_CC_OE_CE_V_009
Status: Mandatory
Ref: 8. 8.1.3.2 [1], 13.2.2.1 [1], figure 5 [1]
Purpose: Ensure that the IUT when an INVITE client transaction is in the Calling state, on receipt of a
Trying (100 Trying) response enters in the Proceeding state.
TPId: SIP_CC_OE_CE_V_010
Status: Mandatory
Ref: 8.1.3.2 [1], 13.2.2.11, figure 5 [1]
Purpose: Ensure that the IUT when an INVITE client transaction is in the Calling state, on receipt of a
Session Progress (183 Session Progress) response enters in the Proceeding state.
TPId: SIP_CC_OE_CE_V_011
Status: Mandatory
Ref: 8.1.3.2 [1], 13.2.2.1 [1], figure 5 [1]
Purpose: Ensure that the IUT when an INVITE client transaction is in the Calling state, on receipt of a
Unknown (199 Unknown) response enters in the Proceeding state.
TPId: SIP_CC_OE_CE_V_012
Status: Mandatory
Ref: 8.1.3.2 [1], 13.2.2.1 [1], figure 5 [1]
Purpose: Ensure that the IUT when an INVITE client transaction is in th
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...