ETSI TS 102 345 V1.3.1 (2008-10)

Corporate telecommunication Networks (CN); Tunnelling of QSIG over SIP

RTS/ECMA-00351

General Information

• Status: Published
• Publication Date: 05-Oct-2008
• Technical Committee: Ecma - Standardizing information and communications systems
• Current Stage: 12 - Completion
• Due Date: 04-Sep-2008
• Completion Date: 06-Oct-2008

Standards Content (Sample)

ETSI TS 102 345 V1.3.1 (2008-10)
Technical Specification


Corporate telecommunication Networks (CN);
Tunnelling of QSIG over SIP

---------------------- Page: 1 ----------------------
2 ETSI TS 102 345 V1.3.1 (2008-10)




Reference
RTS/ECMA-00351
Keywords
IP, PISN, QSIG, signalling
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, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/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.

TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
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

---------------------- Page: 2 ----------------------
3 ETSI TS 102 345 V1.3.1 (2008-10)

Contents
Intellectual Property Rights . 5
Foreword . 5
Introduction . 5
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 7
3.1 External definitions . 7
3.2 Other definitions . 7
3.2.1 Corporate telecommunication Network (CN) . 7
3.2.2 Egress gateway . 7
3.2.3 Gateway . 7
3.2.4 Ingress gateway . 7
3.2.5 IP network . 7
3.2.6 Media stream . 7
3.2.7 Private Integrated Services Network (PISN) . 8
3.2.8 Private Integrated services Network eXchange (PINX) . 8
4 Abbreviations and acronyms . 8
5 Background and architecture . 8
5.1 Architecture . 8
5.2 Basic operation . 9
5.3 QSIG connectionless transport . 10
5.4 Late availability of SDP parameters at the egress gateway . 10
6 Procedures . 10
6.1 General . 10
6.2 Encapsulation of QSIG messages in SIP messages . 10
6.3 QSIG SETUP message handling at an ingress gateway . 11
6.3.1 Sending a SIP INVITE request . 11
6.3.2 Receipt of responses to the INVITE request . 11
6.4 QSIG SETUP message handling at an egress gateway . 12
6.4.1 Receiving a SIP INVITE request . 12
6.4.2 Rejecting a QSIG message in an INVITE request . 13
6.5 Subsequent QSIG messages . 13
6.6 Terminating the SIP dialog . 13
6.7 QSIG connectionless message handling at an ingress gateway . 13
6.7.1 Sending a SIP INVITE request . 14
6.7.2 Receipt of responses to the INVITE request . 14
6.8 QSIG connectionless message handling at an egress gateway . 14
7 Example message sequences . 15
7.1 Call establishment . 15
7.2 Call clearing . 16
7.3 QSIG connectionless message . 17
7.4 Call establishment with port=0 in first SDP answer . 17
7.5 Backwards compatibility with early editions . 19
8 Security considerations. 21
Annex A (informative): Changes from early editions . 22
A.1 Motivation for changes in payload renegotiation procedures . 22
A.2 Late availability of SDP parameters at the egress gateway . 22
A.3 Compatibility with gateways that support early editions of this standard . 23
ETSI

---------------------- Page: 3 ----------------------
4 ETSI TS 102 345 V1.3.1 (2008-10)

History . 24

ETSI

---------------------- Page: 4 ----------------------
5 ETSI TS 102 345 V1.3.1 (2008-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 ECMA on behalf of its members and those of the European
Telecommunications Standards Institute (ETSI).
Introduction
The present document is one of a series of Ecma Standards defining the interworking of services and signalling
protocols deployed in corporate telecommunication networks (CNs) (also known as enterprise networks). The series
uses telecommunication concepts as developed by ITU-T and conforms to the framework of International Standards on
Open Systems Interconnection as defined by ISO/IEC.
This particular Standard specifies tunnelling of QSIG over the Session Initiation Protocol (SIP). This enables calls
between "islands" of circuit switched networks that use QSIG signalling to be interconnected by an IP network that uses
SIP signalling without loss of QSIG functionality. The present document facilitates the introduction of enhanced SIP
and SDP functionality that was specified after publication of the early editions of the present document. These
enhancements include payload encryption and mechanisms to negotiate SDP capabilities.
The changes in the present document comprise a mandatory payload renegotiation with reversed direction of the
offer/answer exchange compared with early editions. In order to achieve backward compatibility with early editions an
indicator for the changed signalling procedures is introduced. This indicator is used to dynamically detect if fallback to
signalling procedures compliant to early editions is necessary.
The present document is based upon the practical experience of Ecma member companies and the results of their active
and continuous participation in the work of ISO/IEC JTC1, ITU-T, IETF, ETSI and other international and national
standardization bodies. It represents a pragmatic and widely based consensus.
ETSI

---------------------- Page: 5 ----------------------
6 ETSI TS 102 345 V1.3.1 (2008-10)

1 Scope
The present document specifies tunnelling of "QSIG" over the Session Initiation Protocol (SIP) within a corporate
telecommunication network (CN).
"QSIG" is a signalling protocol that operates between Private Integrated services Network eXchanges (PINX) within a
Private Integrated Services Network (PISN). A PISN provides circuit-switched basic services and supplementary
services to its users. QSIG is specified in Standards, in particular [1] (call control in support of basic services), [2]
(generic functional protocol for the support of supplementary services) and a number of Standards specifying individual
supplementary services.
NOTE: The name QSIG was derived from the fact that it is used for signalling at the Q reference point. The Q
reference point is a point of demarcation between two PINXs [1].
SIP is an application layer protocol for establishing, terminating and modifying multimedia sessions. It is typically
carried over IP [4], [6]. Telephone calls are considered as a type of multimedia session where just audio is exchanged.
SIP is defined in [9].
Often a CN comprises both PISNs employing QSIG and IP networks employing SIP. A call or call independent
signalling can originate at a user connected to a PISN and terminate at a user connected to an IP network or vice versa.
In either case, a gateway provides interworking between QSIG and SIP at the boundary between the PISN and the IP
network. Basic call interworking at a gateway is specified in [3]. Another case is where a call or call independent
signalling originates at a user connected to a PISN, traverses an IP network using SIP, and terminates at a user
connected to another (or another part of the same) PISN. The present document addresses this last case in a way that
preserves all QSIG capabilities across the IP network. It achieves this by tunnelling QSIG messages within SIP requests
and responses in the context of a SIP dialog.
The tunnelling of QSIG through a public IP network employing SIP is outside the scope of the present document.
However, the functionality specified in thhe present document is in principle applicable to such a scenario when
deployed in conjunction with other relevant functionality (e.g. address translation, security functions, etc.)
The present document is applicable to any interworking unit that can act as a gateway between a PISN employing QSIG
and a corporate IP network employing SIP, with QSIG tunnelled within SIP requests and responses.
2 Normative references
[1] ISO/IEC 11572: "Information technology -- Telecommunications and information exchange
between systems -- Private Integrated Services Network -- Circuit mode bearer services --
Inter-exchange signalling procedures and protocol" (also published by Ecma as Standard
ECMA-143).
[2] ISO/IEC 11582: "Information technology -- Telecommunications and information exchange
between systems -- Private Integrated Services Network -- Generic functional protocol for the
support of supplementary services -- Inter-exchange signalling procedures and protocol "
(also published by Ecma as Standard ECMA-165).
[3] ISO/IEC 17343: "Information technology -- Telecommunications and information exchange
between systems -- Corporate telecommunication networks -- Signalling interworking between
QSIG and SIP -- Basic services" (also published by Ecma as Standard ECMA-339).
[4] IETF RFC 791: "Internet Protocol".
[5] IETF RFC 2119: "Key words for use in RFCs to Indicate Requirement Levels".
[6] IETF RFC 2460: "Internet Protocol, Version 6 (IPv6) Specification".
[7] IETF RFC 2976: "The SIP INFO Method".
[8] IETF RFC 3204: "MIME media types for ISUP and QSIG Objects".
[9] IETF RFC 3261: "SIP: Session Initiation Protocol".
ETSI

---------------------- Page: 6 ----------------------
7 ETSI TS 102 345 V1.3.1 (2008-10)

[10] IETF RFC 3264: "An Offer/Answer Model with the Session Description Protocol (SDP)".
[11] IETF RFC 3311: "The Session Initiation Protocol (SIP) UPDATE Method".
[12] IETF RFC 3840: "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)".
NOTE: Available at http://tools.ietf.org/html/rfc3840
3 Terms and definitions
In the present document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in
[5] and indicate requirement levels for compliant SIP implementations.
For the purposes of the present document, the following definitions apply.
3.1 External definitions
The definitions in [1] and [9] apply as appropriate.
3.2 Other definitions
3.2.1 Corporate telecommunication Network (CN)
Sets of privately-owned or carrier-provided equipment that are located at geographically dispersed locations and are
interconnected to provide telecommunication services to a defined group of users.
NOTE: A CN can comprise a PISN, a private IP network (intranet) or a combination of the two.
3.2.2 Egress gateway
A gateway handling a QSIG call or call-independent signalling connection established in the direction IP network to
PISN.
3.2.3 Gateway
An entity that behaves as a QSIG Transit PINX with QSIG carried over a circuit-switched link within a PISN on one
side and QSIG tunnelled over SIP within an IP network on the other side.
3.2.4 Ingress gateway
A gateway handling a QSIG call or call-independent signalling connection established in the direction PISN to IP
network.
3.2.5 IP network
A network, unless otherwise stated a corporate network, offering connectionless packet-mode services based on the
Internet Protocol (IP) as the network layer protocol.
3.2.6 Media stream
Audio or other user information transmitted in UDP packets, typically containing RTP, in a single direction between the
gateway and a peer entity participating in a session established using SIP.
NOTE: Normally a SIP session establishes a pair of media streams, one in each direction.
ETSI

---------------------- Page: 7 ----------------------
8 ETSI TS 102 345 V1.3.1 (2008-10)

3.2.7 Private Integrated Services Network (PISN)
A CN or part of a CN that employs circuit-switched technology and QSIG signalling.
3.2.8 Private Integrated services Network eXchange (PINX)
A PISN nodal entity comprising switching and call handling functions and supporting QSIG signalling in accordance
with [1].
4 Abbreviations and acronyms
CN Corporate telecommunication Network
IP Internet Protocol
PINX Private Integrated services Network eXchange
PISN Private Integrated Services Network
QSIG Signalling system for the Q reference point
RTP Real-time Transport Protocol
SDP Session Description Protocol
SIP Session Initiation Protocol
TCP Transmission Control Protocol
TLS Transport Layer Security
UA User Agent
UAC User Agent Client
UAS User Agent Server
UDP User Datagram Protocol
URI Universal Resource Identifier
5 Background and architecture
5.1 Architecture
The present document concerns the case of a call or call independent signalling that originates at a user connected to a
PISN employing QSIG, traverses an IP network employing SIP, and terminates at a user connected to another (or
another part of the same) PISN. This can be achieved by employing a gateway at each boundary between a PISN
employing QSIG and an IP network employing SIP, as shown in figure 1.

Figure 1: Call from QSIG via SIP to QSIG
ETSI

---------------------- Page: 8 ----------------------
9 ETSI TS 102 345 V1.3.1 (2008-10)

Each gateway can provide interworking as specified in [3]. This provides a basic call capability. However, [3] only
specifies interworking for QSIG basic call, as specified in [1]. Many of the other capabilities of QSIG (support for
supplementary services and additional network features) as specified in other standards and in vendor-specific
specifications are not covered. Some of these additional capabilities of QSIG are suitable for interworking with SIP and
might be the subject of future Standards or other specifications. Other capabilities of QSIG are unsuitable for
interworking with SIP because corresponding capabilities do not exist in SIP or are achieved in ways that are
incompatible with QSIG. Therefore interworking at a gateway between QSIG and SIP will be limited to those QSIG
capabilities that have sufficiently compatible equivalents in SIP. Each capability requires special implementation in the
gateway, and therefore a typical gateway might provide interworking for only a subset of capabilities for which
interworking is feasible. The result of this is that there will be a loss of capability on a call or call independent signalling
from QSIG to SIP or vice versa. For a case similar to that shown in figure 1 there will likewise be a loss of capability.
This can be compounded if the two gateways are of different types, since only those capabilities common to both
gateways will survive end-to-end. The solution is to tunnel QSIG messages through the IP network within SIP messages
so that no end-to-end QSIG capabilities are lost. One of the two gateways originates a SIP dialog to the other gateway.
SIP messages within the dialog are used to tunnel QSIG messages. Through the use of SDP [10], the dialog also
establishes a session in which media streams carry user information (e.g. speech) between the two QSIG gateways, if
required. The two gateways act as QSIG Transit PINXs, which relay QSIG messages with little or no modification.
In a conventional PISN employing QSIG, two PINXs are connected by means of an inter-PINX link, which comprises a
signalling channel (carrying QSIG messages) and one or more user information channels carrying speech, modem
information or data. With the tunnelling solution, the IP network provides the inter-PINX link between the two
gateways acting as Transit PINXs. The tunnel provided by SIP for QSIG messages acts as the signalling channel and
the media streams act as the user information channels.
The present document covers the case where a single dialog between two gateways is used for a single QSIG call or call
independent signalling connection, as specified in [2]. This means that the dialog is established when the QSIG call or
call independent signalling connection is established and cleared down when the QSIG call or call independent
signalling connection is cleared down.
An enhanced scenario in which a single SIP dialog is maintained long term and used to tunnel a multiplicity of QSIG
calls or call independent signalling connections, with the possibility of multiple QSIG calls or call independent
signalling connections being in progress at any one time, is outside the scope of the present document.
The present document also covers call-independent connectionless transport.
5.2 Basic operation
When a gateway (the ingress gateway) receives a QSIG call or call-independent signalling connection establishment
request (QSIG SETUP message) from the PISN, it needs to generate a SIP INVITE request using a Request-URI that
will route the request to an appropriate egress gateway. The Request-URI must be derived in some way from the
required destination of the QSIG call or call-independent signalling connection (as indicated in the Called party number
information element of the QSIG SETUP message). The Request-URI can explicitly identify the egress gateway or it
can simply identify the required destination. The first case is likely to require some sort of look-up capability in the
ingress gateway, the configuration of which is outside the scope of the present document. For the latter case algorithmic
mapping of the called party number to a Request-URI might be sufficient, but this delegates the task of selecting an
appropriate egress gateway to SIP proxies.
An ingress gateway may determine from the required destination of a call or call-independent signalling connection that
the destination is not reachable via QSIG tunnelling. In this case the QSIG gateway can either route the call or
call-independent signalling connection onwards within the PISN or can route the call or call-independent signalling
connection into the IP network using interworking as specified in [3]. How an ingress gateway determines that the
destination is not reachable via QSIG tunnelling is outside the scope of the present document.
If an ingress gateway maps the QSIG called party number to a Request URI that does not explicitly identify a particular
egress gateway, routing of the INVITE request is left to SIP proxies. A proxy might route the request to a UAS that is
not an egress gateway to QSIG, in which case QSIG tunnelling will not be possible. Allowing the call or
call-independent signalling connection to proceed in this situation is likely to be undesirable, since the ingress gateway
expects to carry out QSIG tunnelling whereas interworking with SIP, as specified in [3], would be more appropriate. To
cater for this situation, a mechanism is defined that causes an INVITE request containing tunnelled QSIG to be rejected
by an egress gateway that does not support this capability.
ETSI

---------------------- Page: 9 ----------------------
10 ETSI TS 102 345 V1.3.1 (2008-10)

NOTE: Allowing the INVITE request to be routed by proxies either to an egress gateway to QSIG or to some
other UAS without the ability for the ingress gateway to choose in advance is undesirable. It implies that
the ingress gateway maps the QSIG SETUP message to a SIP INVITE request in accordance with both
the present document and [3] simultaneously. Although this may seem feasible superficially,
architecturally it is dangerous because with QSIG tunnelling the ingress gateway should act as a QSIG
Transit PINX whereas with interworking in accordance with [3] it should act as a QSIG Outgoing
Gateway PINX. The ingress gateway will not know for certain which behaviour to adopt until a 200 OK
arrives, and therefore in the meantime it will not know how to handle information relating to certain
QSIG capabilities (supplementary services and additional network features) in the QSIG SETUP
message. It is not clear whether this can be handled safely for all possible QSIG capabilities (including
vendor-specific capabilities). For this reason, the present document and [3] require the ingress gateway to
make a decision between tunnelling and interworking respectively.
5.3 QSIG connectionless transport
When a gateway (the ingress gateway) receives a QSIG connectionless FACILITY message from the PISN, it needs to
generate a SIP INVITE request using a Request-URI that will route the request to an appropriate egress gateway. The
Request-URI must be derived in some way from the required destination of the QSIG FACILITY message (as indicated
in the Called party number information element of the QSIG SETUP message). Techniques similar to those used for
QSIG SETUP messages can be used.
An ingress gateway may determine from the required destination of a QSIG connectionless FACILITY message that the
destination is not reachable via QSIG tunnelling. In this case the QSIG gateway can either route the message onwards
within the PISN or discard the message.
5.4 Late availability of SDP parameters at the egress gateway
In conjunction with certain gateway architectures (e.g. decomposed gateways comprising a separate signalling gateway
and media gateway), valid SDP parameters might not be available to the egress gateway (e.g. the signalling gateway
part of a decomposed gateway) at the time when an SDP answer to the initial SDP offer needs to be sent. In this case the
egress gateway will have to send a dummy SDP answer. The final SDP parameters need to be agreed upon during a
later phase of the QSIG call establishment.
In order to achieve identical signalling procedures between ingress gateway and egress gateway irrespective of the
gateway architecture, the ingress gateway starts SDP re-negotiation immediately after confirmation of the SIP dialog
provided that both gateways support the changed procedures. This mandatory re-negotiation during QSIG call
establishment is redundant in the case of an integrated gateway that can provide valid parameters for an SDP answer at
the time of the first SDP negotiation, but is still employed in the interests of a single solution that works for all gateway
architectures. In the case of decomposed gateways, the solution allows the SDP offer-answer cycle to be conducted
end-to-end between the ingress and egress media gateways, with only minimal intervention by the intermediate
signalling gateways.
6 Procedures
6.1 General
A gateway SHALL behave as a QSIG Transit PINX as specified in [1] and modified as specified below.
6.2 Encapsulation of QSIG messages in SIP messages
When encapsulating a QSIG message inside a SIP message, a gateway SHALL include the QSIG message in a MIME
body of the SIP request or response in accordance with [8] using media type application/QSIG. QSIG segmentation
SHALL NOT apply.
If any other MIME body is to be included (e.g. SDP), the gateway SHALL use multi-part MIME.
ETSI

---------------------- Page: 10 ----------------------
11 ETSI TS 102 345 V1.3.1 (20
...