ISO/IEC 23916:2005

INTERNATIONAL ISO/IEC
STANDARD 23916
First edition
2005-11-01


Information technology —
Telecommunications and information
exchange between systems — Corporate
Telecommunication Networks —
Signalling Interworking between QSIG
and SIP — Call Transfer
Technologies de l'information — Télécommunications et échange
d'information entre systèmes — Réseaux de télécommunications
d'entreprise — Interaction de signalisation entre QSIG et SIP —
Transfert d'appel




Reference number
ISO/IEC 23916:2005(E)
©
ISO/IEC 2005

---------------------- Page: 1 ----------------------
ISO/IEC 23916:2005(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.


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

---------------------- Page: 2 ----------------------
ISO/IEC 23916:2005(E)

Contents Page
Foreword .v
Introduction.vi
1 Scope.1
2 Normative references.1
3 Terminology.2
4 Definitions.3
4.1 External definitions .3
4.2 Other definitions.3
4.2.1 User A .3
4.2.2 User B .3
4.2.3 User C .3
4.2.4 Call transfer.3
4.2.5 Single step call transfer.4
4.2.6 Call transfer by join.4
4.2.7 Call transfer by rerouteing .4
4.2.8 Corporate telecommunication Network (CN).4
4.2.9 IP network.4
4.2.10 Private Integrated Services Network (PISN) .4
4.2.11 Private Integrated services Network eXchange (PINX) .4
5 Abbreviations and acronyms .4
6 Background and architecture .5
7 Procedures.5
7.1 Call transfers in QSIG .5
7.2 Call transfer in SIP.6
7.3 Scope of the interworking functions.6
7.3.1 QSIG side.6
7.3.2 SIP side.6
7.3.3 Discussion over transfer interworking functions .6
7.4 Mapping of numbers and URIs .9
7.5 UAC Processing .10
7.5.1 Receipt of a FACILITY message with callTransferComplete invoke APDU .10
7.5.2 Receipt of a FACILITY message with callTransferUpdate invoke APDU.10
7.5.3 Receipt of a FACILITY message with ssctInitiate invoke APDU.10
7.5.4 Receipt of a SETUP message with ssctSetup invoke APDU .11
7.5.5 Receipt of a FACILITY message with subaddressTransfer invoke APDU.12
7.6 UAS Processing.12
7.6.1 Receipt of a SIP REFER request .12
7.6.2 Receipt of a SIP INVITE request.17
7.6.3 Receipt of a SIP request with revised identity .18
8 Example message sequences.19
8.1 Call transfer by join where User B and C are SIP participants.19
8.2 Call transfer where User A is a SIP participant .20
8.3 Call transfer where User A is a SIP participant and where two gateways are used.21
8.4 Call transfer where User A and User B are SIP participants.22
8.5 Single step call transfer where User B is a SIP participant .23
8.6 Unsuccessful Single step call transfer where User A and User C are SIP participants .24
8.7 Single step call transfer where User A and User B are SIP participants.25
9 Security considerations . 25
© ISO/IEC 2005 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO/IEC 23916:2005(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 23916 was prepared by Ecma International (as ECMA 361) 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.

iv © ISO/IEC 2005 – All rights reserved

---------------------- Page: 4 ----------------------
ISO/IEC 23916:2005(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.
This International Standard specifies call transfer interworking between the Session Initiation Protocol
(SIP) and QSIG within corporate telecommunication networks (also known as enterprise networks). SIP
is an Internet application-layer control (signalling) protocol for creating, modifying, and terminating
sessions with one or more participants. These sessions include, in particular, telephone calls.
This International Standard is based upon the practical experience of 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.
© ISO/IEC 2005 – All rights reserved v

---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO/IEC 23916:2005(E)

Information technology — Telecommunications and information
exchange between systems — Corporate Telecommunication
Networks — Signalling Interworking between QSIG and SIP —
Call Transfer

1 Scope
This International Standard specifies call transfer interworking between the Session Initiation Protocol (SIP)
and “QSIG” within corporate telecommunication networks (CN), also known as enterprise networks.
"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. Transfer services are specified in [3], [6] and the
QSIG signalling protocol in support of these services is specified in [4], [7]. In particular, this signalling protocol
signals information about call transfer to the users who are involved.
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.
SIP is an application layer protocol for establishing, terminating and modifying multimedia sessions. It is
typically carried over IP. Telephone calls are considered as a type of multimedia session where just audio is
exchanged. SIP is defined in [10].
As the support of telephony within corporate networks evolves from circuit-switched technology to Internet
technology, the two technologies will co-exist in many networks for a period, perhaps several years. Therefore
there is a need to be able to establish, modify, terminate and transfer sessions involving participants in the
SIP network and participants in the QSIG network. Such calls are supported by gateways that perform
interworking between SIP and QSIG.
This specification specifies SIP-QSIG signalling interworking for transfer services between a PISN employing
QSIG and a corporate IP network employing SIP.
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.
[1] International Standard 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] International Standard 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).
© ISO/IEC 2005 – All rights reserved 1

---------------------- Page: 6 ----------------------
ISO/IEC 23916:2005(E)
[3] International Standard ISO/IEC 13865 "Information technology -- Telecommunications and information
exchange between systems -- Private Integrated Services Network -- Specification, functional model and
information flows -- Call Transfer supplementary service" (also published by Ecma as Standard ECMA-177).
[4] International Standard ISO/IEC 13869 "Information technology -- Telecommunications and information
exchange between systems -- Private Integrated Services Network -- Inter-exchange signalling protocol -- Call
Transfer supplementary service" (also published by Ecma as Standard ECMA-178).
[5] International Standard 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).
[6] International Standard ISO/IEC 19459 "Information technology -- Telecommunications and information
exchange between systems -- Private Integrated Services Network -- Specification, functional model and
information flows -- Single Step Call Transfer Supplementary Service" (also published by Ecma as Standard
ECMA-299).
[7] International Standard ISO/IEC 19460 "Information technology -- Telecommunications and information
exchange between systems -- Private Integrated Services Network -- Inter-exchange signalling protocol --
Single Step Call Transfer supplementary service" (also published by Ecma as Standard ECMA-300).
[8] Ecma Technical Report TR/86, "Corporate Telecommunication Networks – User Identification in a
SIP/QSIG Environment".
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119.
[10] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation protocol", RFC 3261.
[11] J. Peterson, "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323.
[12] R. Sparks, "The Session Initiation Protocol (SIP) REFER Method", RFC 3515.
[13] R. Mahy, B. Biggs, R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891.
[14] R. Sparks, "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892.
[15] R. Sparks, A. Johnston, "Session Initiation Protocol Call Control - Transfer", draft-ietf-sipping-cc-transfer-
02 (work in progress).
3 Terminology
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 [9] and indicate requirement levels for compliant SIP implementations.
In the interests of keeping the normative text and the diagrams as simple as possible, the QSIG messages in
this document implicitly follow QSIG signalling rules of [1] and [2]. For instance, sending a QSIG
DISCONNECT message on a call where a QSIG DISCONNECT has already been sent is implicitly forbidden
and therefore not mentioned as such in this document.
The figures in this document are provided as examples. They are not normative. In the interests of keeping
the diagrams simple, some SIP messages (ACK, PRACK, final responses to BYE and NOTIFY) are not
shown.
The following notation is used for call transfer information within QSIG messages:
 xxx.inv - invoke application protocol data unit (APDU) of operation xxx.
2 © ISO/IEC 2005 – All rights reserved

---------------------- Page: 7 ----------------------
ISO/IEC 23916:2005(E)
 xxx.res - return result APDU of operation xxx.
 xxx.err - return error APDU of operation xxx.
The following abbreviations are used:
 ctActive stands for callTransferActive.
 ctComplete stands for callTransferComplete.
The drawings use the following conventions:
 D1 and D2 are SIP dialogs. CR1 and CR2 are QSIG call references. By convention, D1 is mapped to
CR1 and D2 to CR2.
 A SIP message is prefixed by (Dx-y), when it belongs to SIP dialog Dx and is part of SIP transaction y.
 The method or response code of the SIP messages is displayed, as well as the name of SIP header fields
that play a role in the interworking functions. Some examples display an "Identity:" information field. It
indicates that the local identity information field should be mapped to a real SIP identity information field
as described in 7.4.
4 Definitions
For the purposes of this specification, the following definitions apply.
4.1  External definitions
The definitions in [1] and [10] apply as appropriate.
4.2  Other definitions
4.2.1
User A
the served user, i.e. the user requesting Call transfer or Single step call transfer.
4.2.2
User B
a user who is in communication with User A and who will be transferred to User C.
NOTE This definitions differs from [3], in order to use similar conventions for QSIG Call transfer and QSIG Single
step call transfer.
4.2.3
User C
the user to whom the call is transferred.
4.2.4
Call transfer
the act of enabling a user (User A) to transform two of that user's calls (at least one of which must be
answered) into a new call between the two other users (User B and User C) in the two calls.
NOTE Call transfer is very similar to the "attended transfer" described in [15].
A Call transfer before answer is a Call transfer that occurs before User C answers the call initiated by User A.
© ISO/IEC 2005 – All rights reserved 3

---------------------- Page: 8 ----------------------
ISO/IEC 23916:2005(E)
4.2.5
Single step call transfer
the act of enabling a served user (User A) to transfer an active call (with User B) to a user (User C) that has
no call established either to User A or to User B. On successful completion of Single step call transfer, User B
and User C can communicate with each other and User A are no longer involved in a call with User B or
User C.
NOTE Single step call transfer is very similar to the "basic transfer" described in [15].
4.2.6
Call transfer by join
the effecting of transfer when User A is a PISN user by joining together the connections of the calls to User B
and User C at User A's PINX.
4.2.7
Call transfer by rerouteing
the effecting of transfer by establishing a new connection to replace all or part of the connections of the calls
to User B and User C.
4.2.8
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 1 A CN can comprise a PISN, a private IP network (intranet) or a combination of the two.
NOTE 2 Also known as enterprise network.
4.2.9
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.10
Private Integrated Services Network (PISN)
a CN or part of a CN that employs circuit-switched technology and QSIG signalling.
4.2.11
Private Integrated services Network eXchange (PINX)
a PISN nodal entity comprising switching and call handling functions and supporting QSIG signalling in
accordance with [1].
5 Abbreviations and acronyms
APDU Application Protocol Data Unit
IP Internet Protocol
PINX Private Integrated services Network eXchange
PISN Private Integrated Services Network
SIP Session Initiation Protocol
UA User Agent
UAC User Agent Client
4 © ISO/IEC 2005 – All rights reserved

---------------------- Page: 9 ----------------------
ISO/IEC 23916:2005(E)
UAS User Agent Server
URI Universal Resource Identifier
6 Background and architecture
The background and architecture of [5] applies. In addition, the interworking function in the protocol model
handles interworking for call transfer services. This involves interworking between the QSIG call transfer
protocol specified in [4], [7] and SIP [10], including the use of the REFER [12] SIP method and Replaces [13]
and Referred-By [14] SIP header fields.
7 Procedures
7.1  Call transfers in QSIG
For the purposes of QSIG, transfers are classified into one of the following types:
 call transfer by join: defined in 4.2.6;
 call transfer by rerouteing: defined in 4.2.7; and
 single step call transfer: defined in 4.2.5.
QSIG Call transfer by rerouteing is out of scope of this document because of its lesser deployment.
QSIG signalling for transfers is based on [2] and comprises the following remote operations:
 ssctInitiate - this confirmed operation is sent by User A's PINX to User B's PINX. It initiates a single step
call transfer. It includes a "rerouteingNumber" of User C. It also includes an optional "transferredAddress"
of User B, an optional "transferringAddress" of User A, and a optional boolean "awaitConnect" that
indicates if the operation return result is expected when the call is connected or when it is alerting User C.
 callTransferActive - this unconfirmed operation is sent to User B. It indicates that answer has taken place
following a Call transfer before answer. It includes a "connectedAddress" that identifies the other User
that answered the transferred call.
 callTransferComplete - this unconfirmed operation is sent to User B and User C. It indicates that a
transfer has been effected. It includes an indication of whether the resulting call is alerting or answered
(referred to later in this document as "callStatus"). It includes a "redirectionNumber" that identifies the
other User in the transferred call.
 ssctSetup - this confirmed operation is sent by User B to User C. It initiates a new call between User B
and User C for the purpose of single step call transfer. It includes an optional "transferringAddress" that
indicates who initiated the transfer.
 callTransferUpdate - this optional unconfirmed operation is sent to User B and User C. It provides
information known to the network about the remote party.
 subaddressTransfer - this optional unconfirmed operation is sent to User B or to User C. It informs each
other of the other party's public ISDN subaddress. It includes a "connectedSubaddress" that identifies the
public ISDN subaddress.
© ISO/IEC 2005 – All rights reserved 5

---------------------- Page: 10 ----------------------
ISO/IEC 23916:2005(E)
7.2  Call transfer in SIP
SIP has the concept of requesting a UA to refer (establish a dialog to) a third party [12]. SIP also has the
concept of replacing a dialog by another one [13], and provides a mechanism so that information about the
initiator of the REFER request is sent to the third party [14]. The call transfer document gives examples on
how to support call transfers using these SIP extensions [15].
7.3  Scope of the interworking functions
7.3.1 QSIG side
The interworking functions provided in the following clauses encompass QSIG Call transfer by join and QSIG
Single step call transfer. QSIG Call transfer by rerouteing is out of scope of this document because of its
lesser deployment. The functions take into account that User A, B and C can be in the IP network or in the
PISN.
7.3.2 SIP side
The interworking functions rely on SIP mechanisms. Thus, the interworking functions of this document make
the following assumptions:
 the gateway and the SIP User Agents use globally routable SIP addresses, or use SIP addresses in an
environment where they are routable, or will use other future mechanisms that allow global routing,
 it is RECOMMENDED that the gateway and the SIP User Agents use SIP security mechanisms related to
authentication and confidentiality.
7.3.3 Discussion over transfer interworking functions
This Clause is not normative and aims at giving explanations concerning the implementation choices of this
document.
The QSIG Single step call transfer mechanism is very similar to the "basic transfer" described in [15]. The
QSIG Call transfer is also very similar to the "attended transfer" described in [15]. The latter uses the REFER
method and the Replaces header. Yet, it is not possible to use this mechanism in all the interworking
situations. For instance, if User A in the PISN does not call User B and User C in the SIP network through the
same gateway, there is no opportunity to optimize the signalling path by using the REFER method in the IP
network. Figure 1 gives an example of such a situation where transfer by join has been performed at user A's
PINX. The gateway to user B is unaware that user C is also in the IP network (and even if it were aware, it has
no information for building a Replaces header). Similarly the gateway to user C is unaware that user B is in
the IP network.
6 © ISO/IEC 2005 – All rights reserved

---------------------- Page: 11 ----------------------
ISO/IEC 23916:2005(E)
PISN IP Network
NoNo wayway toto buildbuild
“Replaces:“Replaces: D2”D2”
D1
CR1
Gateway
User A UserUser BB
CR2
D2
Gateway
UserUser CC
E04-0020-A
Figure 1 – Example of a call transfer by join that involves two gateways
Of course, an optimization is possible when only one gateway is used, so that the gateway can send a SIP
REFER request to User B. This optimization is implementation dependant and is out of scope of this
document.
When User A and User B or User C are in the PISN, or when the transfer involves two gateways, updating the
display (name, address, and dialog state of the new remote party) of the SIP User Agents is needed. The
solution is based on the gateway sending an INVITE request for a new dialog and containing a Replaces
header field that matches the existing dialog. At present there is no defined way in SIP to transport an updated
identity within an existing dialog. How the QSIG and SIP fields that indicate identities are derived is described
in 7.4.
Another issue is the lack of SIP mechanism to indicate to User B in the IP network that User C in the PISN is
being alerted. In-band media information (e.g. ringback tone, announcements) may help to inform User B that
the call to User C is not connected yet.
Another issue is that the gateway does not always know whether the new call triggered by a single step call
transfer requested from the PISN must be placed in the IP network or in the PISN. The preferred solution is to
reach User C in the IP network if the address derivation is possible. Upon failure of address derivation or upon
failure of the REFER request, the call is placed in the PISN. Figure 2 illustrates this situation.
© ISO/IEC 2005 – All rights reserved 7

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