ISO/IEC 17343:2004

INTERNATIONAL ISO/IEC
STANDARD 17343
First edition
2004-02-15
Information technology —
Telecommunications and information
exchange between systems — Corporate
telecommunication networks —
Signalling interworking between QSIG
and SIP — Basic services
Technologies de l'information — Télécommunications et échange
d'information entre systèmes — Réseaux de télécommunications
d'entreprise — Signalisation d'interfonctionnement entre QSIG et SIP —
Services de base
Reference number
©
ISO/IEC 2004
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.

©  ISO/IEC 2004
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 2004 – All rights reserved

Contents Page
Foreword. v
Introduction . vi
1 Scope. 1
2 Conformance. 1
3 Normative references. 1
4 Definitions. 2
4.1 External definitions. 2
4.2 Other definitions. 3
5 Acronyms. 3
6 Background and architecture . 3
7 General requirements. 6
8 Message mapping requirements . 6
8.1 Message validation and handling of protocol errors . 6
8.2 Call establishment from QSIG to SIP . 7
8.2.1 Call establishment from QSIG to SIP using enbloc procedures. 7
8.2.2 Call establishment from QSIG to SIP using overlap procedures. 9
8.3 Call Establishment from SIP to QSIG. 12
8.3.1 Receipt of SIP INVITE request for a new call . 12
8.3.2 Receipt of QSIG CALL PROCEEDING message . 12
8.3.3 Receipt of QSIG PROGRESS message. 13
8.3.4 Receipt of QSIG ALERTING message. 13
8.3.5 Inclusion of SDP information in a SIP 18x provisional response . 13
8.3.6 Receipt of QSIG CONNECT message . 14
8.3.7 Receipt of SIP PRACK request . 14
8.3.8 Receipt of SIP ACK request . 14
8.3.9 Receipt of a SIP INVITE request for a call already being established . 15
8.4 Call clearing and call failure . 15
8.4.1 Receipt of a QSIG DISCONNECT, RELEASE or RELEASE COMPLETE message . 15
8.4.2 Receipt of a SIP BYE request. 16
8.4.3 Receipt of a SIP CANCEL request. 17
8.4.4 Receipt of a SIP 4xx - 6xx response. 17
8.4.5 Gateway-initiated call clearing . 18
8.5 Request to change media characteristics. 18
9 Number mapping. 18
9.1 Mapping from QSIG to SIP . 19
9.1.1 Using information from the QSIG Called party number information element . 19
9.1.2 Using information from the QSIG Calling party number information element. 19
9.1.3 Using information from the QSIG Connected number information element . 20
9.2 Mapping from SIP to QSIG . 20
9.2.1 Generating the QSIG Called party number information element . 21
9.2.2 Generating the QSIG Calling party number information element. 21
9.2.3 Generating the QSIG Connected number information element . 21
10 Requirements for support of basic services. 22
10.1 Derivation of QSIG Bearer capability information element . 22
10.2 Derivation of media type in SDP. 22
Annex A (normative) Implementation Conformance Statement (ICS) proforma . 23
A.1 Introduction. 23
© ISO/IEC 2004 – All rights reserved iii

A.1.1 Purpose of an ICS proforma.23
A.2 Instructions for completing the ICS proforma .23
A.2.1 General structure of the ICS proforma.23
A.2.2 Additional Information.24
A.2.3 Exception Information.24
A.2.4 Further indications of the ICS proforma tables.24
A.3 Identification of the implementation.25
A.3.1 Implementation identification.25
A.3.2 Specification for which this ICS applies .25
A.4 General requirements.26
A.5 Call establishment from QSIG to SIP using en bloc procedures .26
A.6 Call establishment from QSIG to SIP using overlap procedures in QSIG network and en
bloc procedures in SIP network.27
A.7 Call establishment from QSIG to SIP using overlap procedures in QSIG network and in
SIP network.28
A.8 Call establishment from SIP to QSIG .29
A.9 Call clearing and call failure.30
A.10 Other requirements.31
Annex B (informative) Example message sequences.32
B.1 Introduction.32
B.2 Message sequences for call establishment from QSIG to SIP .32
B.3 Message sequences for call establishment from SIP to QSIG .37
B.4 Message sequence for call clearing from QSIG to SIP .41
B.5 Message sequence for call clearing from SIP to QSIG.43
Annex C (informative) Security considerations.46

iv © ISO/IEC 2004 – All rights reserved

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 17343 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 6, Telecommunications and information exchange between systems.
ISO/IEC 17343 was prepared by ECMA (as ECMA-339) 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.

© ISO/IEC 2004 – All rights reserved v

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.
This International Standard defines the signalling protocol interworking for basic services between a Private
Integrated Services Network (PISN) and a packet-based private telecommunications network based on the
Internet Protocol (IP). It is further assumed that the protocol for the PISN part is QSIG and that the protocol for
the IP-based network is SIP.
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 JTC1, ITU-T, ETSI and other
international and national standardization bodies. It represents a pragmatic and widely based consensus.

vi © ISO/IEC 2004 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 17343:2004(E)

Information technology — Telecommunications and information
exchange between systems — Corporate telecommunication
networks — Signalling interworking between QSIG and SIP —
Basic services
1 Scope
This International Standard specifies signalling interworking between “QSIG” and the Session Initiation
Protocol (SIP) in support of basic services within a corporate telecommunication network (CN).
“QSIG” is a signalling protocol that operates between Private Integrated Services 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 other Standards, in particular ISO/IEC 11572 (call
control in support of basic services), ISO/IEC 11582 (generic functional protocol for the support of
supplementary services) and a number of Standards specifying individual supplementary services.
SIP is an application layer protocol for establishing, terminating and modifying multimedia sessions. It is
typically carried over the Internet Protocol (IP) (IETF RFC 791 and IETF RFC 2460). Telephone calls are
considered as a type of multimedia session where just audio is exchanged. SIP is defined in IETF RFC 3261.
This International Standard specifies signalling interworking for basic services that provide a bi-directional
transfer capability for speech, DTMF, facsimile and modem media between a PISN employing QSIG and a
corporate IP network employing SIP. Call-related and call-independent signalling in support of supplementary
services is outside the scope of this International Standard, but support for certain supplementary services
(e.g., call transfer, call diversion) could be the subject of future work.
Interworking between QSIG and SIP permits a call originating at a user of a PISN to terminate at a user of a
corporate IP network, or a call originating at a user of a corporate IP network to terminate at a user of a PISN.
Interworking between a PISN employing QSIG and 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., number
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.
A brief assessment of security considerations in the IP network resulting from the interworking specified in this
International Standard is given in annex C.
2 Conformance
In order to conform to this International Standard, a gateway shall satisfy the requirements identified in the
Implementation Conformance Statement (ICS) proforma in annex A.
3 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 2004 – All rights reserved 1

ISO/IEC 11571:1998, Information technology — Telecommunications and information exchange between
systems — Private Integrated Services Networks — Addressing
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 11579-1:1994, Information technology — Telecommunications and information exchange between
systems — Private Integrated Services Network — Part 1: Reference configuration for PISN Exchanges
(PINX)
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
ISO/IEC 21409:2001, Information technology — Telecommunications and information exchange between
systems — Corporate telecommunication networks — Signalling interworking between QSIG and H.323 —
Generic functional protocol for the support of supplementary services
ITU-T Rec. E.164:1997, The International Public Telecommunication Numbering Plan
IETF RFC 768, "User Datagram Protocol"; J. Postel
IETF RFC 791, "Internet Protocol"; J. Postel
IETF RFC 793, "Transmission Control Protocol"; J. Postel
IETF RFC 2046, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types"; N. Freed/
N. Borenstein
IETF RFC 2246, "The TLS protocol version 1.0", T. Dierks, C. Allen
IETF RFC 2327, "SDP: Session Description Protocol"; M. Handley/V. Jacobson
IETF RFC 2460, "Internet Protocol, Version 6 (IPv6)”; S. Deering, R. Hinden
IETF RFC 2960, "Stream Control Transmission Protocol"; R. Stewart et al.
IETF RFC 3261, "SIP: Session Initiation Protocol"; M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg
IETF RFC 3262, "Reliability of Provisional Responses in SIP"; J. Rosenberg /H. Schulzrinne
IETF RFC 3264, "An Offer/Answer Model with SDP"; J. Rosenberg /H. Schulzrinne
IETF RFC 3323, “A Privacy Mechanism for the Session Initiation Protocol (SIP)”; J. Peterson
IETF RFC 3325, “Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within
Trusted Networks”; C. Jennings, J. Peterson, M. Watson
4 Definitions
For the purposes of this International Standard, the following definitions apply.
4.1 External definitions
This International Standard uses the following terms defined in other documents:
• Call (ISO/IEC 21409)
• Corporate telecommunication network (CN) (ISO/IEC 21409)
2 © ISO/IEC 2004 – All rights reserved

• Private Integrated Services Network (PISN) (ISO/IEC 21409)
• Private Integrated services Network eXchange (PINX) (ISO/IEC 11579-1)
Additionally the definitions in ISO/IEC 11572 and IETF RFC 3261 apply as appropriate.
4.2 Other definitions
4.2.1
Gateway
An entity that performs interworking between a PISN using QSIG and an IP network using SIP.
4.2.2
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.
4.2.3
Media stream
Audio or other user information transmitted in UDP packets 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.
5 Acronyms
DNS Domain Name Service
IP Internet Protocol
PINX Private Integrated services Network eXchange
PISN Private Integrated Services Network
RTP Real-time Transport Protocol
SCTP Stream Control Transmission Protocol
SDP Session Description Protocol
SIP Session Initiation Protocol
TCP Transmission Control Protocol
TLS Transport Layer Security
TU Transaction User
UA User Agent
UAC User Agent Client
UAS User Agent Server
UDP User Datagram Protocol
6 Background and architecture
During the 1980s, corporate voice telecommunications adopted technology similar in principle to Integrated
Services Digital Networks (ISDN). Digital circuit switches, commonly known as Private Branch eXchanges
(PBX) or more formally as Private Integrated services Network eXchanges (PINX) have been interconnected
by digital transmission systems to form Private Integrated Services Networks (PISN). These digital
transmission systems carry voice or other payload in fixed rate channels, typically 64 Kbit/s, and signalling in a
separate channel. A technique known as common channel signalling is employed, whereby a single signalling
channel potentially controls a number of payload channels or bearer channels. A typical arrangement is a
© ISO/IEC 2004 – All rights reserved 3

point-to-point transmission facility at T1 or E1 rate providing a 64 Kbit/s signalling channel and 24 or 30 bearer
channels respectively. Other arrangements are possible and have been deployed, including the use of
multiple transmission facilities for a signalling channel and its logically associated bearer channels. Also
arrangements involving bearer channels at sub-64 Kbit/s have been deployed, where voice payload requires
the use of codecs that perform compression.
QSIG is the internationally-standardized message-based signalling protocol for use in networks as described
above. It runs in a signalling channel between two PINXs and controls calls on a number of logically
associated bearer channels between the same two PINXs. The signalling channel and its logically associated
bearer channels are collectively known as an inter-PINX link. QSIG is independent of the type of transmission
capabilities over which the signalling channel and bearer channels are provided. QSIG is also independent of
the transport protocol used to transport QSIG messages reliably over the signalling channel.
QSIG provides a means for establishing and clearing calls that originate and terminate on different PINXs. A
call can be routed over a single inter-PINX link connecting the originating and terminating PINX, or over
several inter-PINX links in series with switching at intermediate PINXs known as transit PINXs. A call can
originate or terminate in another network, in which case it enters or leaves the PISN environment through a
gateway PINX. Parties are identified by numbers, in accordance with either ITU-T recommendation E.164 or a
private numbering plan. This basic call capability is specified in ISO/IEC 11572. In addition to basic call
capability, QSIG specifies a number of further capabilities supporting the use of supplementary services in
PISNs.
More recently corporate telecommunications networks have started to exploit IP in various ways. One way is
to migrate part of the network to IP using SIP. This might, for example, be a new branch office with a SIP
proxy and SIP endpoints instead of a PINX. Alternatively, SIP equipment might be used to replace an existing
PINX or PINXs. The new SIP environment needs to interwork with the QSIG-based PISN in order to support
calls originating in one environment and terminating in the other. Interworking is achieved through a gateway.
Another way of migrating is to use a SIP network to interconnect two parts of a PISN and encapsulate QSIG
signalling in SIP messages for calls between the two parts of the PISN. This is outside the scope of this
specification but could be the subject of future work.
This International Standard specifies signalling protocol interworking aspects of a gateway between a PISN
employing QSIG signalling and an IP network employing SIP signalling. The gateway appears as a PINX to
other PINXs in the PISN. The gateway appears as a SIP endpoint to other SIP entities in the IP network.

Proxy IP network PISN
PINX
Inter-PINX link
Gateway
PINX
End- End- PINX
point point
Figure 1 — Environment
In addition to the signalling interworking functionality specified in this International Standard, it is assumed that
the gateway also includes the following functionality:
4 © ISO/IEC 2004 – All rights reserved

• one or more physical interfaces on the PISN side supporting one or more inter-PINX links, each link
providing one or more constant bit rate channels for media information and a reliable layer 2 connection
(e.g., over a fixed rate physical channel) for transporting QSIG signalling messages; and
• one or more physical interfaces on the IP network side supporting, through layer 1 and layer 2 protocols,
IP as the network layer protocol and UDP (IETF RFC 768) and TCP (IETF RFC 793) as transport layer
protocols, these being used for the transport of SIP signalling messages and, in the case of UDP, also for
media information;
• optionally the support of TLS (IETF RFC 2246) and/or SCTP (IETF RFC 2960) as additional transport
layer protocols on the IP network side, these being used for the transport of SIP signalling messages; and
• a means of transferring media information in each direction between the PISN and the IP network,
including as a minimum packetization of media information sent to the IP network and de-packetization of
media information received from the IP network.
NOTE IETF RFC 3261 mandates support for both UDP and TCP for the transport of SIP messages and allows
optional support for TLS and/or SCTP for this same purpose.
The protocol model relevant to signalling interworking functionality of a gateway is shown in figure 2.
Interworking
function
SIP QSIG
layer 3
SIP
QSIG
IP network PISN
UDP/TCP/TLS/SCTP
IP
IP network PISN lower
lower layers layers
Figure 2 — Protocol model
In figure 2, the SIP box represents SIP syntax and encoding, the SIP transport layer and the SIP transaction
layer. The Interworking function includes SIP Transaction User (TU) functionality.
The gateway maps received QSIG messages, where appropriate, to SIP messages and vice versa and
maintains an association between a QSIG call and a SIP dialog.
A call from QSIG to SIP is initiated when a QSIG SETUP message arrives at the gateway. The QSIG SETUP
message initiates QSIG call establishment and an initial response message completes negotiation of the
bearer channel to be used for that call. The gateway then sends a SIP INVITE request, having translated the
QSIG called party number to a URI suitable for inclusion in the Request-URI. The SIP INVITE request and the
resulting SIP dialog, if successfully established, are associated with the QSIG call. The SIP 200 OK response
is mapped to a QSIG CONNECT message, signifying answer of the call. During establishment, media streams
established by SIP and SDP are connected to the bearer channel.
A call from SIP to QSIG is initiated when a SIP INVITE request arrives at the gateway. The gateway sends a
QSIG SETUP message to initiate QSIG call establishment, having translated the SIP Request-URI to a
number suitable for use as the QSIG called party number. The resulting QSIG call is associated with the SIP
INVITE request and with the eventual SIP dialog. Receipt of an initial QSIG response message completes
negotiation of the bearer channel to be used, allowing media streams established by SIP and SDP to be
connected to that bearer channel. The QSIG CONNECT message is mapped to a SIP 200 OK response.
Annex B gives examples of typical message sequences that can arise.
© ISO/IEC 2004 – All rights reserved 5

7 General requirements
In order to conform to this International Standard, a gateway shall support QSIG in accordance with
ISO/IEC 11572 as a gateway and shall support SIP in accordance with IETF RFC 3261 as a UA. In particular
the gateway shall support SIP syntax and encoding, the SIP transport layer and the SIP transaction layer in
accordance with IETF RFC 3261. In addition, the gateway shall support SIP TU behaviour for a UA in
accordance with IETF RFC 3261 except where stated otherwise in this International Standard.
NOTE 1 IETF RFC 3261 mandates that a SIP entity support both UDP and TCP as transport layer protocols for SIP
messages. Other transport layer protocols can also be supported.
The gateway shall also support SIP reliable provisional responses in accordance with IETF RFC 3262 as a
UA.
NOTE 2 IETF RFC 3262 makes provision for recovering from loss of provisional responses (other than 100) to INVITE
requests when using unreliable transport services in the IP network. This is important for ensuring delivery of responses
that map to essential QSIG messages.
The gateway shall support SDP in accordance with IETF RFC 2327 and its use in accordance with the offer /
answer model in IETF RFC 3264.
Clause 9 also specifies optional use of the Privacy header in accordance with IETF RFC 3323 and the
P-Asserted-Identity header in accordance with IETF RFC 3325.
The gateway shall support calls from QSIG to SIP and calls from SIP to QSIG.
SIP methods not defined in IETF RFC 3261, IETF RFC 3262, IETF RFC 3323 or IETF RFC 3325 are outside
the scope of this International Standard but could be the subject of other specifications for interworking with
QSIG, e.g., for interworking in support of supplementary services.
As a result of DNS look-up by the gateway in order to determine where to send a SIP INVITE request, a
number of candidate destinations can be attempted in sequence. The way in which this is handled by the
gateway is outside the scope of this International Standard. However, any behaviour specified in this
International Standard on receipt of a SIP final response should apply only when there are no more candidate
destinations to try.
8 Message mapping requirements
8.1 Message validation and handling of protocol errors
The gateway shall validate received QSIG messages in accordance with the requirements of ISO/IEC 11572
and shall act in accordance with ISO/IEC 11572 on detection of a QSIG protocol error. The requirements of
this clause for acting on a received QSIG message apply only to a received QSIG message that has been
successfully validated and that satisfies one of the following conditions:
• the QSIG message is a SETUP message and indicates a destination in the IP network and a bearer
capability for which the gateway is able to provide interworking; or
• the QSIG message is a message other than SETUP and contains a call reference that identifies an
existing call for which the gateway is providing interworking between QSIG and SIP.
The processing of any valid QSIG message that does not satisfy any of these conditions is outside the scope
of this International Standard.
If segmented QSIG messages are received, the gateway shall await receipt of all segments of a message and
shall validate and act on the complete reassembled message.
The gateway shall validate received SIP messages (requests and responses) in accordance with the
requirements of IETF RFC 3261 and shall act in accordance with IETF RFC 3261 on detection of a SIP
6 © ISO/IEC 2004 – All rights reserved

protocol error. Requirements of this clause for acting on a received SIP message apply only to a received
message that has been successfully validated and that satisfies one of the following conditions:
• the SIP message is an INVITE request that contains no tag parameter in the To header field, does not
match an ongoing transaction (i.e., is not a merged request, see 8.2.2.2 of IETF RFC 3261) and indicates
a destination in the PISN for which the gateway is able to provide interworking; or
• the SIP message is a request that relates to an existing dialog representing a call for which the gateway is
providing interworking between QSIG and SIP; or
• the SIP message is a CANCEL request that relates to a received INVITE request for which the gateway is
providing interworking with QSIG but for which the only response sent is informational (1xx), no dialog
having been confirmed; or
• the SIP message is a response to a request sent by the gateway in accordance with this clause.
The processing of any valid SIP message that does not satisfy any of these conditions is outside the scope of
this International Standard.
NOTE These rules mean that an error detected in a received message will not be propagated to the other side of the
gateway. However, there can be an indirect impact on the other side of the gateway, e.g., the initiation of call clearing
procedures.
The gateway shall run QSIG protocol timers as specified in ISO/IEC 11572 and shall act in accordance with
ISO/IEC 11572 if a QSIG protocol timer expires. Any other action on expiry of a QSIG protocol timer is outside
the scope of this International Standard, except that if it results in the clearing of the QSIG call, the gateway
shall also clear the SIP call in accordance with 8.4.5.
The gateway shall run SIP protocol timers as specified in IETF RFC 3261 and shall act in accordance with
IETF RFC 3261 if a SIP protocol timer expires. Any other action on expiry of a SIP protocol timer is outside
the scope of this International Standard, except that if it results in the clearing of the SIP call, the gateway
shall also clear the QSIG call in accordance with 8.4.5.
8.2 Call establishment from QSIG to SIP
8.2.1 Call establishment from QSIG to SIP using enbloc procedures
The following procedures apply when the gateway receives a QSIG SETUP message containing a Sending
Complete information element or the gateway receives a QSIG SETUP message and is able to determine that
the number in the Called party number information element is complete.
NOTE The means by which the gateway determines the number to be complete is an implementation matter. It can
involve knowledge of the numbering plan and/or use of inter-digit timer expiry.
8.2.1.1 Receipt of QSIG SETUP message
On receipt of a QSIG SETUP message containing a number that the gateway determines to be complete in
the Called party number information element, or containing a Sending complete information element and a
number that the gateway cannot determine to be complete, the gateway shall map the QSIG SETUP message
to a SIP INVITE request. The gateway shall also send a QSIG CALL PROCEEDING message.
The gateway shall generate the SIP Request-URI, To and From fields in the SIP INVITE request in
accordance with clause 9. The gateway shall include in the INVITE request a Supported header containing
option tag 100rel, to indicate support for IETF RFC 3262.
The gateway shall include SDP information in the SIP INVITE request as described in clause 10.
© ISO/IEC 2004 – All rights reserved 7

On receipt of a QSIG SETUP message containing a Sending complete information element and a number that
the gateway determines to be incomplete in the Called party number information element, the gateway shall
initiate QSIG call clearing procedures using cause value 28 “invalid number format (address incomplete)”.
If information in the QSIG SETUP message is unsuitable for generating any of the mandatory fields in a SIP
INVITE request (e.g., if a Request-URI cannot be derived from the QSIG Called party number information
element) or for generating SDP information, the gateway shall not issue a SIP INVITE request and shall
initiate QSIG call clearing procedures in accordance with ISO/IEC 11572.
8.2.1.2 Receipt of SIP 100 (Trying) response
A SIP 100 response shall not trigger any QSIG messages. It only serves the purpose of suppressing INVITE
request retransmissions.
8.2.1.3 Receipt of SIP 18x provisional response
The gateway shall map a received SIP 18x response to a QSIG PROGRESS or ALERTING message based
on the following conditions
• If a SIP 180 response is received and no QSIG ALERTING message has been sent, the gateway SHALL
generate a QSIG ALERTING message. The gateway MAY supply ring-back tone on the user information
channel of the inter-PINX link, in which case the gateway SHALL include progress description number 8 in
the QSIG ALERTING message. Otherwise the gateway SHALL NOT include progress description number
8 in the QSIG ALERTING message unless a media stream has been established towards the gateway
and the gateway is aware that in-band information (e.g., ring-back tone) is being transmitted.
• If a SIP 181/182/183 response is received, no QSIG ALERTING message has been sent, no QSIG
PROGRESS message containing progress description number 8 has been sent and a media stream has
been established towards the gateway, the gateway shall generate a QSIG PROGRESS message. The
QSIG PROGRESS message shall contain progress description number 8 in a Progress indicator
information element. The gateway shall also connect the media streams to the corresponding user
information channel of the inter-PINX link.
• If a SIP 181/182/183 response is received, no QSIG ALERTING message has been sent, no QSIG
PROGRESS message containing progress description number 1 or 8 has been sent and no media stream
has been established towards the gateway, the gateway shall generate a QSIG PROGRESS message.
The QSIG PROGRESS message shall contain progress description number 1 in a Progress indicator
information element.
NOTE 1 This will ensure that QSIG timer T310 is stopped if running at the Originating PINX.
NOTE 2 Media streams are established as a result of receiving SDP answer information in a reliable provisional
response and can be modified by means of the SIP UPDATE method (IETF RFC 3311). If a media stream is established
towards the gateway, connecting the media stream to the corresponding user information channel on the inter-PINX link
will allow the caller to hear in-band tones or announcements.
In all other scenarios the gateway shall not map the SIP 18x response to a QSIG message.
If the SIP 18x response contains a Require header with option tag 100rel, the gateway shall send back a SIP
PRACK request in accordance with IETF RFC 3262.
8.2.1.4 Receipt of SIP 2xx response
If the gateway receives a SIP 200 (OK) response as the first SIP 200 response to a SIP INVITE request, the
gateway shall map the SIP 200 (OK) response to a QSIG CONNECT message. The gateway shall also send
a SIP ACK request to acknowledge the 200 (OK) response. The gateway shall not include any SDP
information in the SIP ACK request. If the gateway receives further 200 (OK) responses, it shall respond to
each in accordance with IETF RFC 3261 and shall not generate any further QSIG messages.
8 © ISO/IEC 2004 – All rights reserved

Media streams will normally have been established in the IP network in each direction. If so, the gateway shall
connect the media streams to the corresponding user-information channel on the inter-PINX link if it has not
already done so and stop any local ring-back tone.
If the SIP 200 (OK) response is received in response to the SIP PRACK request, the gateway shall not map
this message to any QSIG message.
If the gateway receives a SIP 2xx response other than 200 (OK), the gateway shall send a SIP ACK request.
NOTE A SIP 200 (OK) response can be received later as a result of a forking proxy.
8.2.1.5 Receipt of SIP 3xx response
On receipt of a SIP 3xx response, the gateway shall act in accordance with IETF RFC 3261.
NOTE This will normally result in sending a new SIP INVITE request.
Unless the gateway supports the QSIG Call Diversion Supplementary Service, no QSIG message shall be
sent. The definition of Call Diversion Supplementary Service for QSIG to SIP interworking is beyond the scope
of this International Standard.
8.2.2 Call establishment from QSIG to SIP using overlap procedures
SIP uses en-bloc signalling and it is strongly recommended to avoid using overlap signalling in a SIP
network. A SIP/QSIG gateway dealing with overlap signalling, should perform a conversion from overlap to
en-bloc signalling method using one or more of the following mechanisms:
• timers;
• numbering plan information;
• the presence of a Sending complete information element in a received QSIG INFORMATION message.
If the gateway performs a conversion from overlap to en-bloc signalling in the SIP network then the
procedures defined in 8.2.2.1 shall apply.
However, for some applications it might be impossible to avoid using overlap signalling in the SIP network. In
this case the procedures defined in 8.2.2.2 shall apply.
8.2.2.1 Enbloc signalling in SIP network
8.2.2.1.1 Receipt of QSIG SETUP message
On receipt of a QSIG SETUP message containing no Sending complete information element and a number in
the Called party number information element that the gateway cannot determine to be complete, the gateway
shall send back a QSIG SETUP ACKNOWLEDGE message, start QSIG timer T302 and await further number
digits.
8.2.2.1.2 Receipt of QSIG INFORMATION message
On receipt of each QSIG INFORMATION message containing no Sending complete information element and
containing a number that the gateway cannot determine to be complete, QSIG timer T302 shall be restarted.
When QSIG timer T302 expires or a QSIG INFORMATION message containing a Sending complete
information element is received the gateway shall send a SIP INVITE request as described in 8.2.1.1. The
Request-URI and To fields (see clause 9) shall be generated from the concatenation of information in the
Called party number information element in the received QSIG SETUP and INFORMATION messages. The
gateway shall also send a QSIG CALL PROCEEDING message.
© ISO/IEC 2004 – All rights reserved 9

8.2.2.1.3 Receipt of SIP responses
SIP responses shall be mapped as described in 8.2.1.
8.2.2.
...