ETSI TR 102 026 V1.1.1 (2002-01)

Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON); Study of the use of TTCN-3 for SIP and for OSP test specifications

DTR/TIPHON-06019

Harmonizacija telekomunikacij in internetnega protokola prek omrežij (TIPHON) - Študija uporabe TTCN-3 za preskušalne specifikacije za SIP in OSP

General Information

• Status: Published
• Publication Date: 29-Jan-2002
• Technical Committee: TIPHON 6 - TIPHON Verification, demonstration and implementation matters
• Current Stage: 12 - Completion
• Due Date: 16-Jan-2002
• Completion Date: 30-Jan-2002
• Ref Project: SIST-TP TR 102 026 V1.1.1:2004 - Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON); Study of the use of TTCN-3 for SIP and for OSP test specifications

Standards Content (Sample)

SLOVENSKI STANDARD
SIST-TP TR 102 026 V1.1.1:2004
01-april-2004
Harmonizacija telekomunikacij in internetnega protokola prek omrežij (TIPHON) -
Študija uporabe TTCN-3 za preskušalne specifikacije za SIP in OSP
Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON);
Study of the use of TTCN-3 for SIP and for OSP test specifications
Ta slovenski standard je istoveten z: TR 102 026 Version 1.1.1
ICS:
33.020 Telekomunikacije na splošno Telecommunications in
general
SIST-TP TR 102 026 V1.1.1:2004 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------

SIST-TP TR 102 026 V1.1.1:2004

---------------------- Page: 2 ----------------------

SIST-TP TR 102 026 V1.1.1:2004

ETSI TR 102 026 V1.1.1 (2002-01)
Technical Report


Telecommunications and Internet Protocol
Harmonization Over Networks (TIPHON);
Study of the use of TTCN-3 for SIP
and for OSP test specifications

---------------------- Page: 3 ----------------------

SIST-TP TR 102 026 V1.1.1:2004
 2 ETSI TR 102 026 V1.1.1 (2002-01)



Reference
DTR/TIPHON-06019
Keywords
VoIP, interoperability, IP, testing, TTCN
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

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:
[e-mail]
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 2002.
All rights reserved.

ETSI

---------------------- Page: 4 ----------------------

SIST-TP TR 102 026 V1.1.1:2004
 3 ETSI TR 102 026 V1.1.1 (2002-01)
Contents
Intellectual Property Rights.5
Foreword.5
1 Scope.6
2 References.6
3 Abbreviations.6
4 Background.7
5 Suitability of TTCN-3 for SIP testing .8
5.1 Architectural considerations for testing SIP.8
5.2 Expressing SIP dynamic behaviour in TTCN-3 .9
5.3 Expressing SIP messages in TTCN-3.10
5.3.1 SIP headers.12
5.3.1.1 Parameterization.12
5.3.1.2 Wildcards.13
5.3.1.3 Using modified templates.13
5.3.2 TTCN-3 regular expressions.14
5.3.2.1 Simple patterns.14
5.3.2.2 More complex patterns.14
5.3.2.2.1 Set expression.15
5.3.2.2.2 Reference expression.15
5.3.2.2.3 Match expression n times .15
5.3.2.3 Using regular expressions with SIP .15
6 Suitability of TTCN-3 for OSP testing.16
6.1 Architectural considerations for testing OSP .16
6.1.1 Normal OSP message exchange .16
6.1.2 Token carriage.17
6.2 Expressing OSP dynamic behaviour in TTCN-3.17
6.3 Expressing OSP messages in TTCN-3 .18
6.3.1 AuthorizationRequest.18
6.3.1.1 XML declaration.18
6.3.1.2 TTCN3 type.18
6.3.1.3 TTCN3 template.19
6.3.2 Parameterization.20
6.3.3 Wildcards.20
7 Practical experience of using TTCN-3.21
8 Availability of tools.21
9 Maintenance of the TTCN-3 standard.21
10 Training.22
Annex A: Suggested style guidelines.23
A.1 Introduction.23
A.2 The rule and its two corollaries .23
A.3 Some guidelines.24
A.3.1 Module organization.24
A.3.2 Comments.27
A.3.3 Type definitions.28
A.3.3.1 Basic types.28
A.3.3.2 Structured types.29
A.3.3.2.1 Enumerations.29
ETSI

---------------------- Page: 5 ----------------------

SIST-TP TR 102 026 V1.1.1:2004
 4 ETSI TR 102 026 V1.1.1 (2002-01)
A.3.3.2.2 Records et al.29
A.3.3.2.3 Variable definitions.29
A.3.4 Function definitions.30
A.3.5 Whitespace.31
A.3.6 Statements.31
A.3.6.1 Simple statements.31
A.3.6.2 Compound statements.31
A.3.7 Naming conventions.32
A.3.8 Beautifiers and formatters .33
A.3.9 Presentation fonts and sheet orientation .33
A.3.10 Alternates, named or not .34
A.3.11 Calls and references to other modules.35
A.3.12 Test case style.35
A.3.13 PICS and PIXIT parameters .37
Annex B: Bibliography.38
History .39

ETSI

---------------------- Page: 6 ----------------------

SIST-TP TR 102 026 V1.1.1:2004
 5 ETSI TR 102 026 V1.1.1 (2002-01)
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 Report (TR) has been produced by ETSI Project Telecommunications and Internet Protocol
Harmonization Over Networks (TIPHON).
ETSI

---------------------- Page: 7 ----------------------

SIST-TP TR 102 026 V1.1.1:2004
 6 ETSI TR 102 026 V1.1.1 (2002-01)
1 Scope
The present document provides an analysis on the suitability of using TTCN-3 as defined in ES 210 873-1 [1] to specify
the test specifications for TIPHON protocols, in particular the TIPHON profile of SIP (Session Initiation Protocol) and
the TIPHON OSP (Open Settlement Protocol). This study is restricted to the use of the TTCN-3 Core Language.
2 References
For the purposes of this Technical Report (TR) the following references apply:
[1] ETSI ES 201 873-1: "Methods for Testing and Specification (MTS); The Tree and Tabular
Combined Notation version 3; Part 1: TTCN-3 Core Language".
[2] ISO/IEC 9646-3: "Information technology - Open Systems Interconnection - Conformance testing
methodology and framework - Part 3: The Tree and Tabular Combined Notation (TTCN)
Edition 2".
[3] ETSI TS 101 321: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON); Open Settlement Protocol (OSP) for Inter-Domain pricing, authorization, and usage
exchange".
[4] ITU-T Recommendation Z.140: "The tree and tabular combined notation version 3 (TTCN-3):
Core language".
3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ASN.1 Abstract Syntax Notation One
ATS Abstract Test Suite
DTD Document Type Definition
IUT Implementation Under Test
MTC Master Test Component
OSP Open Settlement Protocol
(P)ICS (Protocol) Implementation Conformance Statement
(P)IXIT (Protocol) Implementation eXtra Information for Testing
PDU Protocol Data Unit
SIP Session Initiation Protocol
SUT System Under Test
TCP Transfert Control Protocol
TTCN-2 Tree and Tabular Combined Notation version 2
TTCN-3 Testing and Test Control Notation version 3
UDP User Datagram Protocol
XML eXtensible Markup Language
PCO Point of Control and Observation
DE Development Environment
ETSI

---------------------- Page: 8 ----------------------

SIST-TP TR 102 026 V1.1.1:2004
 7 ETSI TR 102 026 V1.1.1 (2002-01)
4 Background
The detailed code for nearly all ETSI (conformance) Abstract Test Suites (ATS) is written in TTCN. There are two
versions of TTCN, version 2 (TTCN-2) as defined in ISO/IEC-9646-3 [2] and the recently published ETSI version 3
ES 201 873-1 [1].
NOTE: Version 1 of TTCN is not now used by ETSI.
Version 2 is oriented towards conformance testing and has been widely applied in testing telecommunications protocols
and services for over 10 years. TTCN-3 is a modernization of TTCN-2. It has been developed to apply to a wide range
of testing applications (i.e. it is not limited to conformance testing) and the syntax of the language has been brought into
line with that of other modern programming languages.
While it is not anticipated that TTCN-2 will immediately replace TTCN-3 (from ETSI's point of view the transition to
TTCN-3 is expected to occur over several years) there are good reasons to consider using TTCN-3 for "new" protocols
such as SIP or OSP.
EP TIPHON is writing test specifications for H.225, H.245, H.248, SIP and OSP. The tests for the first three protocols
are being written in TTCN-2. This is mainly due to timing (the work was started several months prior to the publication
of TTCN-3) and the fact that they are "traditional" protocols (for example H.225 is very close to Q.931). It is also more
likely that, in the short-term, the actual test systems for these protocols will be based on TTCN-2.
However, the nature of SIP and OSP (e.g., text-based, datacom-oriented) makes them an ideal candidate for TTCN-3.
The present document makes an initial analysis on the suitability of using TTCN-3 to for SIP and OSP test
specifications.
ETSI

---------------------- Page: 9 ----------------------

SIST-TP TR 102 026 V1.1.1:2004
 8 ETSI TR 102 026 V1.1.1 (2002-01)
5 Suitability of TTCN-3 for SIP testing
In order to understand the suitability of TTCN-3 for testing SIP it is necessary to consider three main aspects:
• the basic testing architecture, i.e. the location of the test interfaces;
• the expression of dynamic behaviour (i.e. SIP message exchanges);
• the representation of data (i.e. SIP messages).
These aspects are described in clauses 5.1, 5.2 and 5.3 respectively.
5.1 Architectural considerations for testing SIP
Two conceptual SIP test systems are illustrated in figure 1. The TTCN-3 parts of the test system are represented by the
white boxes, which in the present document we refer to as the "TTCN-3 Tester". The light grey box represents
sub-structured parts of the test system. The dark grey boxes indicate the underlying transport layer, either UDP or TCP.

Option 1  Option 2
High level
(intelligent)
processing of the SIP
All processing of
PCO
Initial low - level
SIP messages
messages done
processing o f the SIP
in TTCN -3 messages done in test
system
-3

PCO
TTCN
UDP/TCP  UDP/TCP

Figure 1: Basic test system architecture
TTCN-3 behaviour is executed over test ports, sometimes called PCOs (Points of Control and Observation). For SIP
testing there are basically two options for the placement of the PCO.
• directly over UDP (or TCP);
• higher than UDP (or TCP), i.e. "embedded" in the test system.
In the first option of figure 1 all processing of the SIP messages is expressed in TTCN-3. For received messages this
means that the PCO delivers a SIP message to the TTCN-3 tester as a single text string. The TTCN-3 code must then
(somehow) parse this text string and break it down into data structures on which the TTCN-3 matching mechanisms etc.
can operate. For send messages the reverse occurs i.e. TTCN-3 data structures representing the SIP message are
encoded as a single text string.
It is certainly possible to use TTCN-3 this way but this would probably be inefficient. It would also overload the
TTCN-3 test cases (not to mention the test suite writers) with detail not explicitly relevant to the test purposes.
In the second option, the test system receives a SIP message over the UDP (or TCP) port and does the initial parsing
before passing the structure to the TTCN-3 Tester via the PCO. In its simplest form this parser need only recognize the
basic "outline" of the message with no detailed knowledge of individual headers. This structure would be mapped to the
corresponding TTCN-3 template on a best possible fit basis. The TTCN-3 Tester then operates directly on this data
structure rather than the incoming text string (by pattern matching).
ETSI

---------------------- Page: 10 ----------------------

SIST-TP TR 102 026 V1.1.1:2004
 9 ETSI TR 102 026 V1.1.1 (2002-01)
If the tester is to deliver more complex TTCN-3 structures then the underlying parser will need to be correspondingly
complex. As this will effect how a TTCN-3 test case is expressed (i.e. place restrictions on how TTCN-3 is used) it is
important that this functionality is defined by EP TIPHON at an early stage.
In conventional protocol testing (especially when using, say, ASN.1) this sub-layer (shaded light grey in figure 1) is
often referred to as an encoder-decoder. Here, the incoming data is a bit stream which is decoded by the test system and
passed to the TTCN-3 tester in structured form.
Discussions with several tool implementer's indicate that option 2 should be the favoured approach. The present
document therefore recommends that EP TIPHON follow option 2 when writing TTCN-3 test cases for SIP.
5.2 Expressing SIP dynamic behaviour in TTCN-3
SIP has very simple dynamic behaviour. The TTCN-3 communication and timer mechanisms etc. are entirely adequate
to specify the exchange of SIP messages. The present document recommends that TIPHON SIP tests are expressed
using asynchronous communication.
NOTE: Generally, SIP testing would be based on asynchronous message exchanges, however TTCN-3 does have
synchronous communication if it is desired to express the test that way.
A typical piece of SIP behaviour could be:
testcase SIP_RG_RT_V_001() runs on SipComponent system SipInterfaces
// Selection: To be defined
// Status: Mandatory
// SUT: A UA, a proxy, or a redirect server.
// Precondition: None
// Ref: 2.2 [1], 7.1 [1], 10.14 [1]
// Purpose: Ensure that the IUT, in order to be registered, sends a REGISTER request
// t to its proxy (Home server, outbound proxy) with the action field set to "proxy"
// in the Contact header field, without user name in the Request-URI,
// with a Via header field and with a SIP URL as request-URI.
{
 var REG_Request V_REGISTER_Request;
 var ContactAddress_List V_ContactList;
 var GenericParam_List V_GenericParamList;
 var integer i,j, nbelement, nbparam;
 var boolean hasBeenFound:=false;

 sut.action ("Please REGISTER");
 TWait.start(PX_TWAIT);
 alt
 {
  [] SIP1.receive (REGISTER_Request_r_2) from rcv_label -> value V_REGISTER_Request
  {
   TWait.stop;
   // Catch and prepare informations to answer
   iutContact :=
getContactAddr(V_REGISTER_Request.reqHeader.contact.contactBody.contactAddress_List[1]);

   V_CallId := V_REGISTER_Request.reqHeader.callId;
  V_CSeq := V_REGISTER_Request.reqHeader.cSeq;
  V_From := V_REGISTER_Request.reqHeader.fromField;
   V_To := V_REGISTER_Request.reqHeader.toField;
   V_Via := V_REGISTER_Request.reqHeader.via;
   // update sent_label according to received via header field
   getViaReplyAddr(V_Via.viaBody);
   //Add a Tag in the TO field
   V_To.toParams := {{TAG_ID, GetAValueTag()}};

  // Check Contact content
   V_ContactList := V_REGISTER_Request.reqHeader.contact.contactBody.contactAddress_List;
   nbelement := sizeof(V_ContactList);
  for (i:=1;i==nbelement;i:=i+1)
  {
   hasBeenFound:=false;
   // Check that parameters are present in the contact
   if (match(V_ContactList[i], ContactAdress_r_1))
   {
   V_GenericParamList := V_ContactList[i].contactParams;
   nbparam := sizeof(V_GenericParamList);
   j:=1;
   //Check that at least one parameter is set to action="proxy"
ETSI

---------------------- Page: 11 ----------------------

SIST-TP TR 102 026 V1.1.1:2004
 10 ETSI TR 102 026 V1.1.1 (2002-01)
   do
   {
    if (match(V_GenericParamList[j],GenericParam_r_1))
    {
    hasBeenFound:=true;
    }

   // Check that contact does not include a parameter set to action="redirect"
    if (match(V_GenericParamList[j],GenericParam_r_2))
    {
    hasBeenFound:=false;
    j:= nbparam;
    }
    j:=j+1;
   }
   while (j<=nbparam) //end loop on contact parameters
   }

   if(not hasBeenFound)
   {
     verdict.set(fail);
    //Answer with a 409 status message
     SIP1.send (Response_409_s_1(V_CallId, V_CSeq, V_From, V_To,
     V_Via )) to sent_label; stop
   }
  } //end For on Contact list
  verdict.set(pass);
   //Send a 200OK Answer to the UA with an Expire header field set
   //to PX_DELTA_REGISTRATION and the contact list
   SIP1.send (Response_200_s_2(V_CallId, V_CSeq, V_From, V_To,
   V_Via, V_REGISTER_Request.reqHeader.contact,
    PX_DELTA_REGISTRATION )) to sent_label


  }
  [] SIP1.trigger from rcv_label
  {
    all timer.stop;
    verdict.set(fail);
    stop
  }
  [] Twait.timeout {verdict.set(inconc); stop}
 }

} // end testcase SIP_RG_RT_V_001

5.3 Expressing SIP messages in TTCN-3
Currently many SIP test suites specify one single text string for each instance of a message. Changing one element in a
message means that a complete, new message needs to written. The end result is many hundreds of individual SIP
messages. No rationalization. No reuse. Worse still, matches on incoming messages have to be exact, where in practice
a degree of flexibility is often desirable.
The TTCN-3 approach allows to set and match individual elements of data in complex messages. To give a high degree
of controllability and observability. Because SIP messages are text based they have no explicit structure, contrary to
conventional telecommunications protocol. For example:
INVITE sip:[e-mail] SIP/2.1
From: userB
To: userA
CSeq: 1 INVITE
Content-Length: 0

In order to test SIP using TTCN-3 it is necessary to give the messages at least some level of structuring. Highly
structured SIP data will give a good degree of control but will probably lead to a humanly unreadable test suite.
Conversely, little or no structuring will give good readability but very little control. In this clause we present a style of
using TTCN-3 that attempts to achieve controllability while retaining a good degree of readability.
ETSI

---------------------- Page: 12 ----------------------

SIST-TP TR 102 026 V1.1.1:2004
 11 ETSI TR 102 026 V1.1.1 (2002-01)
A SIP message has three basic parts, the Request (or Status) line, the headers and the (optional) message body. The
components of a Request or Status line appear in a given order. In TTCN-3 this can be represented using a record type,
for example:
// SIP Message Request
type record SIP_REQUEST
{ charstring Method  optional, // even mandatory fields are optional
 charstring Request_URI optional, // so that we can specify invalid messages
 charstring SIP_Version optional,
 :
}

Actual messages can be defined using TTCN-3 templates. For example:
template SIP_REQUEST MyRequest :=
{ Method  := "INVITE ",
 Request_URI := "sip:[e-mail] ",
 SIP_Version := "SIP/2.1\r\n" // where \r\n represents %d13%d10 the CR + LF characters
 :
}

Explicit spaces could be included in the structure rather than having them as part of the actual string value
(see clause 5.3.1).
For the sake of this discussion let us assume that SIP headers are text strings terminated by an end of line character
(e.g., CR or LF or CRLF). Generally, SIP messages allow headers to appear in any order. However, for sent messages
(i.e. SIP Requests) the TTCN-3 Tester should specify messages with the SIP headers in a given order. In TTCN-3 this
can be expressed using the record of type.
// Unbounded array of character strings (i.e. headers)
type record of charstring REQUEST_HEADERS;

// Unbounded array of character strings (i.e. body elements)
type record of charstring REQUEST_BODY;

// SIP Message = Request Line + Headers + Body
type record SIP_REQUEST
{ charstring Method  optional, // even mandatory fields are optional
 charstring Request_URI optional, // so that we can specify invalid messages
 charstring SIP_Version optional,
 REQUEST_HEADERS Message_Headers optional,
 REQUEST_BODY Message_Body optional
}

For received messages (i.e. SIP Responses) the TTCN-3 Tester should be prepared to accept messages with the SIP
headers appearing in an arbitrary order. In TTCN-3 this can be expressed using the set of type.
// Unbounded set of character strings (i.e. headers)
type set of charstring RESPONSE_HEADERS;

// Unbounded set of character strings (i.e. body elements)
type set of charstring RESPONSE_BODY;

// SIP Message = Response Line + Headers + Body
type record SIP_RESPONSE
{ charstring  SIP_Version optional, // even mandatory fields are optional
 charstring  Status_Code optional, // so that we can specify invalid messages
 charstring  Reason_Phrase optional,
 RESPONSE_HEADERS Message_Headers optional,
 RESPONSE_BODY Message_Body optional
}

ETSI

---------------------- Page: 13 ----------------------

SIST-TP TR 102 026 V1.1.1:2004
 12 ETSI TR 102 026 V1.1.1 (2002-01)
5.3.1 SIP headers
In its simplest form a SIP header can be represented as a single text string, as descr
...