ISO/IEC 22535:2009

INTERNATIONAL ISO/IEC
STANDARD 22535
Third edition
2009-04-15


Information technology —
Telecommunications and information
exchange between systems — Corporate
telecommunication networks —
Tunnelling of QSIG over SIP
Technologies de l'information — Télécommunications et échange
d'information entre systèmes — Réseaux de télécommunications
d'entreprise — Tunnellisation de QSIG sur SIP




Reference number
ISO/IEC 22535:2009(E)
©
ISO/IEC 2009

---------------------- Page: 1 ----------------------
ISO/IEC 22535:2009(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.


COPYRIGHT PROTECTED DOCUMENT


©  ISO/IEC 2009
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland

ii © ISO/IEC 2009 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/IEC 22535:2009(E)
Contents Page
Foreword. iv
Introduction . v
1 Scope .1
2 Normative references .1
3 Terms and definitions .2
4 Abbreviated terms .3
5 Background and architecture.3
5.1 Architecture.3
5.2 Basic operation.4
5.3 QSIG connectionless transport.5
5.4 Late availability of SDP parameters at the egress gateway .5
6 Procedures .5
6.1 General.5
6.2 Encapsulation of QSIG messages in SIP messages.5
6.3 QSIG SETUP message handling at an ingress gateway.6
6.3.1 Sending a SIP INVITE request .6
6.3.2 Receipt of responses to the INVITE request.6
6.4 QSIG SETUP message handling at an egress gateway.7
6.4.1 Receiving a SIP INVITE request .7
6.4.2 Rejecting a QSIG message in an INVITE request.8
6.5 Subsequent QSIG messages.8
6.6 Terminating the SIP dialog .8
6.7 QSIG connectionless message handling at an ingress gateway .9
6.7.1 Sending a SIP INVITE request .9
6.7.2 Receipt of responses to the INVITE request.9
6.8 QSIG connectionless message handling at an egress gateway.10
7 Example message sequences.10
7.1 Call establishment .10
7.2 Call clearing.11
7.3 QSIG connectionless message .12
7.4 Call establishment with port=0 in first SDP answer.13
7.5 Backwards compatibility with early editions .14
8 Security considerations .16
Annex A (informative) Changes from early editions.17
Bibliography .19

© ISO/IEC 2009 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO/IEC 22535:2009(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 22535 was prepared by Ecma International (as ECMA-355) and was adopted, under a special “fast-
track procedure”, by Joint Technical Committee ISO/IEC JTC 1, Information technology, in parallel with its
approval by national bodies of ISO and IEC.
This third edition cancels and replaces the second edition (ISO/IEC 22535:2006), which has been technically
revised.
iv © ISO/IEC 2009 – All rights reserved

---------------------- Page: 4 ----------------------
ISO/IEC 22535:2009(E)
Introduction
This International Standard is one of a series of 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.
"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 ISO/IEC 11572,
ISO/IEC 11582 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 (ISO/IEC 11572).
SIP is an application layer protocol for establishing, terminating and modifying multimedia sessions. It is
typically carried over IP (RFC 791), (RFC 2460). Telephone calls are considered as a type of multimedia
session where just audio is exchanged. SIP is defined in RFC 3261.
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 ISO/IEC 17343. 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. This
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.
This International 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. This International Standard facilitates
the introduction of enhanced SIP and SDP functionality that was specified after publication of the early
editions of this International Standard. These enhancements include payload encryption and mechanisms to
negotiate SDP capabilities.
The changes in this International Standard 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.
This International Standard 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 JTC 1, ITU-T, IETF, ETSI and other
international and national standardization bodies. It represents a pragmatic and widely based consensus.
© ISO/IEC 2009 – All rights reserved v

---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO/IEC 22535:2009(E)

Information technology — Telecommunications and information
exchange between systems — Corporate telecommunication
networks — Tunnelling of QSIG over SIP
1 Scope
This International Standard specifies tunnelling of "QSIG" over the Session Initiation Protocol (SIP) within a
corporate telecommunication network (CN).
The tunnelling of QSIG through a public IP network employing SIP is outside the scope of this International
Standard. However, the functionality specified in this International Standard is in principle applicable to such a
scenario when deployed in conjunction with other relevant functionality (e.g. address translation, security
functions, etc.).
This International Standard 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
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO/IEC 11572:2000, Information technology — Telecommunications and information exchange between
systems — Private Integrated Services Network — Circuit mode bearer services — Inter-exchange signalling
procedures and protocol
ISO/IEC 11582:2002, 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
RFC 2119, Key words for use in RFCs to Indicate Requirement Levels, BCP 14, S. Bradner, March 1997
RFC 2976, The SIP INFO Method, S. Donovan, October 2000
RFC 3204, MIME media types for ISUP and QSIG Objects, E. Zimmerer et al., December 2001
RFC 3261, SIP: Session Initiation Protocol, J. Rosenberg et al., June 2002
RFC 3264, An Offer/Answer Model with the Session Description Protocol (SDP), J. Rosenberg,
H. Schulzrinne, June 2002
RFC 3840, Indicating User Agent Capabilities in the Session Initiation Protocol (SIP), J. Rosenberg,
H. Schulzrinne, P. Kyzivat, August 2004
© ISO/IEC 2009 – All rights reserved 1

---------------------- Page: 6 ----------------------
ISO/IEC 22535:2009(E)
3 Terms and definitions
In this 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
RFC 2119 and indicate requirement levels for compliant SIP implementations.
For the purposes of this document, the terms and definitions given in ISO/IEC 11572, RFC 3261 and the
following apply.
3.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
egress gateway
gateway handling a QSIG call or call-independent signalling connection established in the direction IP network
to PISN
3.3
gateway
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.4
ingress gateway
gateway handling a QSIG call or call-independent signalling connection established in the direction PISN to IP
network
3.5
IP network
network, unless otherwise stated a corporate network, offering connectionless packet-mode services based
on the Internet Protocol (IP) as the network layer protocol
3.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.
3.7
Private Integrated Services Network
PISN
CN or part of a CN that employs circuit-switched technology and QSIG signalling
3.8
Private Integrated Services Network eXchange
PINX
PISN nodal entity comprising switching and call handling functions and supporting QSIG signalling in
accordance with ISO/IEC 11572
2 © ISO/IEC 2009 – All rights reserved

---------------------- Page: 7 ----------------------
ISO/IEC 22535:2009(E)
4 Abbreviated terms
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
This 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
Each gateway can provide interworking as specified in ISO/IEC 17343. This provides a basic call capability.
However, ISO/IEC 17343 only specifies interworking for QSIG basic call, as specified in ISO/IEC 11572. Many
of the other capabilities of QSIG (support for supplementary services and additional network features) as
© ISO/IEC 2009 – All rights reserved 3

---------------------- Page: 8 ----------------------
ISO/IEC 22535:2009(E)
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 (RFC 3264), 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.
This 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 ISO/IEC 11582. 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 this document.
This 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 this 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 ISO/IEC 17343. How
an ingress gateway determines that the destination is not reachable via QSIG tunnelling is outside the scope
of this 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
ISO/IEC 17343, would be more appropriate. To cater for this situation, a mechanism is defined that causes an
4 © ISO/IEC 2009 – All rights reserved

---------------------- Page: 9 ----------------------
ISO/IEC 22535:2009(E)
INVITE request containing tunnelled QSIG to be rejected by an egress gateway that does not support this
capability.
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 this International Standard and
ISO/IEC 17343 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
ISO/IEC 17343 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, this specification and ISO/IEC 17343 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 ISO/IEC 11572 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 RFC 3204 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.
© ISO/IEC 2009 – All rights reserved 5

---------------------- Page: 10 ----------------------
ISO/IEC 22535:2009(E)
The gateway SHALL include a Content-Disposition header field indicating "signal" and "handling=required" as
a SIP header field (in the case of single-part MIME) or as a MIME header field in the body containing the
QSIG message (in the case of multi-part MIME).
6.3 QSIG SETUP message handling at an ingress gateway
6.3.1 Sending a SIP INVITE request
The ingress gateway, on receipt of a QSIG SETUP message eligible for tunnelling over SIP to an egress
gateway, SHALL build a SIP INVITE request message containing a Request-URI suitable for routing towards
a suitable egress gateway.
NOTE The Request-URI should be derived in some way from the Called party number information in the QSIG
SETUP message. The Request-URI can explicitly identify a particular egress gateway. Alternatively it can identify the final
destination in a way that leaves selection of a suitable egress gateway to SIP proxies.
The From: header field SHOULD contain a URI identifying either the ingress gateway or the calling party
(derived from the QSIG Calling party number information element).
The Contact: header field SHALL include a user agent capability in accordance with RFC 3840 in which URI
parameter +u.ecma-international.org/ecma355/new_sdp_by_ingress is present, indicating support for the
procedures specified by this International Standard. This URI parameter provides a means to achieve
backward compatibility to early editions of this International Standard.
The ingress gateway SHALL encapsulate the QSIG SETUP message in the SIP INVITE request.
The encapsulated QSIG SETUP message MAY differ from the received SETUP mess
...