ISO/IEC 23915:2005

INTERNATIONAL ISO/IEC
STANDARD 23915
First edition
2005-11-01
Information technology —
Telecommunications and information
exchange between systems — Corporate
Telecommunication Networks —
Signalling Interworking between QSIG
and SIP — Call Diversion
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 —
Déviation d'appel
Reference number
©
ISO/IEC 2005
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

Contents Page
Foreword .v
Introduction.vi
1 Scope.1
2 Normative references.1
3 Terms and definitions .2
3.1 External definitions .2
3.2 Other definitions.3
3.2.1 Call diversion .3
3.2.2 Call forwarding busy (CFB).3
3.2.3 Call forwarding no reply (CFNR).3
3.2.4 Call forwarding unconditional (CFU).3
3.2.5 Corporate telecommunication Network (CN).3
3.2.6 Entity A.3
3.2.7 Entity B.3
3.2.8 Entity C.3
3.2.9 Gateway.3
3.2.10 IP network.3
3.2.11 Leg A.3
3.2.12 Leg B.3
3.2.13 Leg C.4
3.2.14 Private Integrated Services Network (PISN) .4
3.2.15 Private Integrated services Network eXchange (PINX) .4
3.2.16 Rerouting entity.4
3.2.17 User A.4
3.2.18 User B.4
3.2.19 User C.4
4 Abbreviations and acronyms .4
5 Background and architecture for SIP-QSIG interworking.5
6 Call diversion .5
7 Call diversion in QSIG.6
8 Call diversion in SIP.7
9 Diversion interworking.7
9.1 Scenarios for diversion interworking.7
9.2 Mapping of numbers, names and URIs.8
9.3 Derivation of QSIG diversion reasons.8
9.3.1 Scenario A1.9
9.3.2 Scenario B1.9
9.3.3 Scenario C2.9
9.4 Derivation of SIP response codes (scenarios A2 and C1) .9
9.5 Mapping the QSIG diversion counter.10
9.6 Privacy considerations.10
9.7 Interworking for scenario A1.10
9.7.1 Transmitting a SIP INVITE request.10
9.7.2 Receipt of a SIP 1xx or 2xx response.11
9.7.3 Receipt of a SIP 4xx, 5xx or 6xx response.11
9.8 Interworking for scenario A2.11
9.8.1 Receipt of a SIP INVITE request.12
© ISO/IEC 2005 – All rights reserved iii

9.8.2 Receipt of a QSIG divertingLegInformation1 invoke APDU . 12
9.8.3 Receipt of a QSIG divertingLegInformation3 invoke APDU . 12
9.8.4 Transmitting a SIP response in which History-Info is allowed . 12
9.9 Interworking for scenario B1. 13
9.9.1 Receipt of a SIP 3xx response. 13
9.9.2 Receipt of a QSIG DISCONNECT or FACILITY message containing a callRerouteing return
result APDU. 14
9.9.3 Receipt of a QSIG FACILITY message containing a callRerouteing return error APDU. 14
9.9.4 Receipt of a QSIG FACILITY message containing a cfnrDivertedLegFailed invoke APDU . 14
9.10 Interworking for scenario B2. 15
9.10.1 Receipt of a QSIG FACILITY message containing a CallRerouteing invoke APDU. 15
9.11 Interworking for scenario C1. 15
9.11.1 Receipt of a QSIG SETUP message containing a divertingLegInformation2 invoke APDU . 15
9.11.2 Transmitting a QSIG CONNECT message. 16
9.12 Interworking for scenario C2. 16
9.12.1 Transmitting a QSIG SETUP message . 16
9.12.2 Receipt of a QSIG message containing a divertingLegInformation3 invoke APDU . 17
9.12.3 Sending History-Info in a response . 17
10 Example message sequences. 17
10.1 Scenario A1. 18
10.1.1 Successful call – history information in 200 response. 18
10.1.2 Successful call – history information in provisional response . 19
10.1.3 Failed call. 20
10.2 Scenario A2. 21
10.2.1 Successful call – CFU or CFB . 21
10.2.2 Successful call – CFNR. 22
10.3 Scenario B1. 23
10.3.1 Successful diversion – CFU or CFB . 23
10.3.2 Successful diversion – CFNR. 24
10.3.3 Failure – callRerouting.err received. 25
10.3.4 Failure – No answer following CFNR. 26
10.4 Scenario B2. 27
10.5 Scenario C1. 28
10.6 Scenario C2. 29
10.7 Scenario A1 followed by B1. 30
10.8 Scenario A2 followed by scenario B2. 31
10.9 Scenario C1 followed by scenario A1. 32
10.10 Scenario C2 followed by scenario A2. 33
10.11 Scenario C1 followed by scenario B1. 34
10.12 Scenario C2 followed by scenario B2. 35
11 Security considerations . 35
iv © ISO/IEC 2005 – 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 23915 was prepared by Ecma International (as ECMA-360) 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 2005 – 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 specifies interworking between the Session Initiation Protocol (SIP) and
QSIG within corporate telecommunication networks (also known as enterprise networks) for calls that
undergo diversion. 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. QSIG is a signalling protocol for creating, modifying and terminating circuit-
switched calls, in particular telephone calls, within Private Integrated Services Networks (PISNs). QSIG
is specified in a number of Standards and published also as ISO/IEC International Standards.
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.
vi © ISO/IEC 2005 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 23915:2005(E)

Information technology — Telecommunications and information
exchange between systems — Corporate Telecommunication
Networks — Signalling Interworking between QSIG and SIP —
Call Diversion
1 Scope
This document specifies signalling interworking between "QSIG" and the Session Initiation Protocol (SIP) in

support of call diversion 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. Diversion services are specified in [4] and the QSIG
signalling protocol in support of these services is specified in [5]. In particular, this signalling protocol signals
information about call diversion to the users involved.
SIP is an application layer protocol for establishing, terminating and modifying multimedia sessions. It is
typically carried over IP [8], [10]. Telephone calls are considered as a type of multimedia session where just
audio is exchanged. SIP is defined in [11]. An extension to SIP provides history information [14] that can be
used to signal information about the retargeting of a request, in particular a call establishment request, as it is
routed through a network.
This document specifies signalling interworking for call diversion during the establishment of calls between a
PISN employing QSIG and a corporate IP network employing SIP. It covers both the impact on SIP of call
diversion in the QSIG network and the impact on QSIG of request retargeting in the SIP network. Signalling
interworking for call diversion operates on top of signalling interworking for basic calls, which is specified in [6].
Call diversion interworking between a PISN employing QSIG and a public IP network employing SIP is outside
the scope of this specification. However, the functionality specified in this specification is in principle
applicable to such a scenario when deployed in conjunction with other relevant functionality (e.g., number
translation, security functions, etc.).
This specification is applicable to any interworking unit that can act as a gateway 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).
© ISO/IEC 2005 – All rights reserved 1

[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).
[3] International Standard ISO/IEC 13868 "Information technology -- Telecommunications and information
exchange between systems -- Private Integrated Services Network -- Inter-exchange signalling protocol --
Name identification supplementary services" (also published by Ecma as Standard ECMA-164).
[4] International Standard ISO/IEC 13872 "Information technology -- Telecommunications and information
exchange between systems -- Private Integrated Services Network -- Specification, functional model and
information flows -- Call Diversion supplementary services" (also published by Ecma as Standard ECMA-173).
[5] International Standard ISO/IEC 13873 "Information technology -- Telecommunications and information
exchange between systems -- Private Integrated Services Network -- Inter-exchange signalling protocol -- Call
Diversion supplementary services" (also published by Ecma as Standard ECMA-174).
[6] 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).
[7] Ecma Technical Report TR/86, "Corporate Telecommunication Networks – User Identification in a
SIP/QSIG Environment".
[8] J. Postel, "Internet Protocol", RFC 791.
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119.
[10] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)", RFC 2460.
[11] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation protocol", RFC 3261.
[12] J. Peterson, "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323.
[13] H. Schulzrinne, D. Oran, G. Camarillo, "The Reason Header field for the Session Initiation Protocol (SIP)",
RFC 3326.
[14] M. Barnes "An Extension to the Session Initiation Protocol for Request History Information", draft-ietf-
sipping-history-info-03 (work in progress).
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 [9] and indicate requirement levels for compliant implementations.
For the purposes of this specification, the following definitions apply.
3.1  External definitions
The definitions in [1] and [11] apply as appropriate.
2 © ISO/IEC 2005 – All rights reserved

3.2  Other definitions
3.2.1
Call diversion
the act of retargeting a call during call establishment by changing the user identity that is used as the basis for
routing to the destination.
3.2.2
Call forwarding busy (CFB)
call diversion invoked because the targeted user is busy.
3.2.3
Call forwarding no reply (CFNR)
call diversion invoked because the targeted user fails to reply within a certain time.
3.2.4
Call forwarding unconditional (CFU)
call diversion invoked for reasons other than those leading to CFB or CFNR.
3.2.5
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.
3.2.6
Entity A
the entity that provides information about diversion to user A.
3.2.7
Entity B
the entity that invokes diversion for a call targeted at user B.
3.2.8
Entity C
the entity that provides information about diversion to user C.
3.2.9
Gateway
an entity that performs interworking between a PISN using QSIG and an IP network using SIP.
3.2.10
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.11
Leg A
the call segment between entity A and the rerouting entity for a call that undergoes diversion.
3.2.12
Leg B
the call segment between the rerouting entity and entity B for a call that undergoes diversion.
© ISO/IEC 2005 – All rights reserved 3

3.2.13
Leg C
the call segment between the rerouting entity and entity C for a call that undergoes diversion.
3.2.14
Private Integrated Services Network (PISN)
a CN or part of a CN that employs circuit-switched technology.
3.2.15
Private Integrated services Network eXchange (PINX)
a PISN nodal entity comprising switching and call handling functions and supporting QSIG signalling in
accordance with [1].
3.2.16
Rerouting entity
the entity that performs call rerouting on request from entity B and that provides information about diversion to
entity A and entity C.
3.2.17
User A
the calling user of a call that undergoes diversion.
3.2.18
User B
the user on behalf of which call diversion is invoked for an incoming call to that user.
3.2.19
User C
the user to which a call is diverted.
4 Abbreviations and acronyms
APDU Application Protocol Data Unit
CFB Call forwarding busy
CFNR Call forwarding no reply
CFU Call forwarding unconditional
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
UAS User Agent Server
URI Universal Resource Identifier
4 © ISO/IEC 2005 – All rights reserved

5 Background and architecture for SIP-QSIG interworking
The background and architecture of [6] applies. In addition, the interworking function in the protocol model
handles interworking for call diversion services. This involves interworking between the QSIG call diversion
protocol specified in [5] and SIP, including the use of SIP request history information as specified in [14].
6 Call diversion
Call diversion, as specified in QSIG and for the purposes of this document, is the act of retargeting a call
during call establishment by changing the user identity that is used as the basis for routing to the destination.
This can be viewed as being a change of destination user, although in some cases two identities can belong
to the same user, e.g., a home number and office number. The three users involved are known as user A (the
calling user A), user B (the called user or diverting user) and user C (the diverted-to user).
Reasons for invoking diversion are various and can depend on factors such as the state of the line serving
user B, the time of day and the type or identity of user A. It could also be as a result of action by user B in
response to the arrival of a call (sometimes known as call deflection). A diversion can occur immediately, i.e.
without alerting user B, or after a period of alerting without reply. With the exception of call deflection,
diversion requirements must be pre-configured into some equipment acting on behalf of user B, e.g., a
telephone, a PINX or a SIP proxy. This could be achieved, for example, by rules-based scripting.
It is often useful or even important that the users involved in a diverted call (user A and user C) are informed
of the diversion. This can be particularly important for automata, e.g., for a call diverted to a voice mail system
it might be important to indicate to the system that the call has been diverted from user B. However, privacy
considerations can sometimes lead to the suppression of this information.
The general model for a call that undergoes diversion is shown in Figure 1. Entity B is the entity that invokes
diversion, based on configuration or, in the case of call deflection, on request from user B. The rerouting entity
performs call rerouting on instruction from entity B and provides information about the diversion to entity A and
entity C. Entity A and entity C handle diversion on behalf of users A and C respectively by providing
information about diversion.
(1)
(2)
legleg BB
entityentity BB
legA
reroutingrerouting
entityA
entityentity
legleg CC
(4)
entityentity CC
(3)
E04-0001-A
Figure 1 – Logical model for diversion in a QSIG network
From this model it can be seen that there are three call legs:
 leg A between entity A and the rerouting entity (null if these two entities are collocated);
 leg B between entity B and the rerouting entity (null if these two entities are collocated);
 leg C between entity C and the rerouting PINX (null if these two entities are collocated).
© ISO/IEC 2005 – All rights reserved 5

Diversion signalling on leg A provides information about diversion to entity A, which can use it to provide
information to user A. Diversion signalling on leg B instructs the rerouting entity to carry out rerouting.
Diversion signalling on leg C provides information about diversion to entity C, which can use it to provide
information to user C.
Figure 1 also illustrates the basic dynamic behaviour:
1. Call establishment from user A as far as entity B.
2. Rerouting request from entity B to the rerouting entity.
3. Rerouted call establishment from the rerouting entity to entity C accompanied by information about the
diversion.
4. Information about the diversion from the rerouting entity to entity A.
Diversions can be chained. In this case the rerouted call from the rerouting entity reaches another entity B.
The same or a different rerouting entity then reroutes the call towards the new user C.
7 Call diversion in QSIG
Call diversion in QSIG is the act of retargeting a call during call establishment by changing the called party
number, which is the user identity used as the basis for routing to the destination. Call diversion in QSIG
follows the model described above. Entity A is located in user A’s PINX (PINX A), entity B is located in user
B’s PINX (PINX B) and entity C is located in user C’s PINX (PINX C). The rerouting entity is located either at
user B’s PINX (diversion by forward switching) or at user A’s PINX (diversion by rerouting).
Because of potential interactions with other supplementary services, the signalling for which passes
transparently through intermediate (Transit) PINXs, the rerouting PINX is constrained to be either PINX B or
PINX A. The former case is known as diversion by forward switching, and is analogous to SIP retargeting by a
proxy. The latter case is known as diversion by rerouting and is analogous to SIP retargeting by redirection.
For the purposes of QSIG, diversions are classified into one of the following types:
 call forwarding no reply (CFNR) (forwarding as a result of no user reply after alerting user B for a certain
time);
 call forwarding busy (CFB) (forwarding as a result of user B’s device being busy); and
 call forwarding unconditional (CFU) (forwarding for reasons other than no reply or busy).
NOTE CFU is not necessarily entirely unconditional, since it can depend on other factors, e.g., time of day.
In common with other supplementary services, QSIG signalling for diversion is based on [2] and comprises
the following remote operations:
 callRerouting – this confirmed operation is applicable to leg B and provides a means for PINX B to
request the rerouting PINX to reroute a call to user C.
 cfnrDivertedLegFailed – this unconfirmed operation is applicable to leg B and indicates failure to establish
call leg C subsequent to accepting a callRerouting operation. cfnrDivertedLegFailed applies only to CFNR
(i.e. to diversions after user B has been alerted) and indicates to PINX B that user B should continue to
be alerted. For other types of diversion leg B is cleared down as soon as the callRerouting operation is
accepted, without waiting to see if the call towards user C can be established.
 divertingLegInformation1 – this unconfirmed operation is applicable to leg A and signals information about
the diversion to PINX A, including any privacy requirement of user B to prevent disclosure of diversion
6 © ISO/IEC 2005 – All rights reserved

information to user A. Note that PINX A can use the information for internal purposes (e.g., call logging)
but is trusted not to disclose private information to user A.
 divertingLegInformation2 – this unconfirmed operation is applicable to leg C and signals information about
the diversion to PINX C.
 divertingLegInformation3 – this unconfirmed operation is applicable to legs A and C and signals privacy
information from PINX C to PINX A. This privacy information provides the possibility for user C to
suppress the disclosure of its identity to user A. PINX A must take into account both the privacy
information in divertingLegInformation1 and the privacy information in divertingLegInformation3 before
disclosing information to user A.
Chained diversions are supported. PINX A receives a divertingLegInformation1 operation for each diversion,
but often a divertingLegInformation3 operation only for the final diversion (since this information is not
necessarily available until answer). The final PINX C receives a single divertingLegInformation2 operation
containing information about the first and last diversions but not intermediate diversions.
8 Call diversion in SIP
Call diversion is not specified for SIP. However, SIP does have the concept of retargeting an INVITE request.
This occurs at a proxy, instigated either by the proxy itself or on request from a redirect using a 3xx response.
It can also occur at the UAC as a result of a 3xx response from a redirect. Relating this to the model, the
rerouting entity for a SIP diversion is the proxy or UAC that retargets the INVITE request. Entity B is either that
same proxy or UAC or a redirect that issues a 3xx response. A 3xx response therefore has some synergy with
a QSIG callRerouting operation. Entity A is the UAC for the INVITE request and entity C is the UAS of the
retargeted-to user.
Retargeting involves changing the Request-URI within the INVITE request, this field being the basis for routing
the request.
[11] does not provide signalling support for notifying user A’s UA or user C’s UA that retargeting has occurred.
Additional signalling for this purpose is specified in [14]. This allows a retargeting proxy or UAC to insert a
History-Info header into a request when it is forwarded downstream, i.e. on leg C towards entity C. Moreover
entity C reflects the received History-Info header back over leg C and leg A towards entity A. In this way, both
entity A and entity C receive information about the retarget and can provide this information to their respective
users. The History-Info header contains a number of entries, each containing a URI that was a Request-URI
at some stage during the routing of the call.
Chained retargets are supported. Entity A and entity C receive information about multiple retargets carried out
during the routing of the INVITE request.
History information can be of a sensitive nature, and therefore [14] makes provision for keeping it private.
History information subject to privacy must not be passed outside the domain where it originates. Within that
domain, the Privacy header [12] with privacy value "history" [14] is used to indicate that either the entire
history information or a particular entry is subject to privacy and must not be passed outside the domain.
9 Diversion interworking
9.1  Scenarios for diversion interworking
From the descriptions in clauses 7 and 8 it can be seen that both diversion in QSIG and retargeting, along
with the History-Info header, in SIP can be mapped to the call diversion model described in clause 6.
Therefore interworking can be described in terms of this model.
Interworking can occur on leg A, on leg B or on leg C. In either case, the rerouting entity can be in either the
SIP network or the QSIG network. This leads to 6 interworking scenarios.
© ISO/IEC 2005 – All rights reserved 7

 Scenario A1: interworking on leg A, call from QSIG to SIP undergoing retargeting in the SIP network.
Entity A in QSIG network, rerouting entity, entity B and entity C in SIP network.
 Scenario A2: interworking on leg A, call from SIP to QSIG undergoing diversion in the QSIG network.
Entity A in SIP network, rerouting entity, entity B and entity C in QSIG network.
 Scenario B1: interworking on leg B, call from QSIG to SIP where QSIG network performs rerouting in
response to a redirection request from the SIP network. Entity A, entity C and rerouting entity in QSIG
network, entity B in SIP network.
 Scenario B2: interworking on leg B, call from SIP to QSIG where SIP network performs retargeting in
response to a rerouting request from the QSIG network. Entity A, entity C and rerouting entity in SIP
network, entity B in QSIG network.
 Scenario C1: interworking on leg C, call diverted by QSIG network to destination in SIP network. Entity A,
entity B and rerouting entity in QSIG network, entity C in SIP network.
 Scenario C2: interworking on leg C, call retargeted by SIP network to destination in QSIG network. Entity
A, entity B and rerouting entity in SIP network, entity C in QSIG network.
Call diversion interworking can occur more than once for a given call (chained diversions). The different
instances of interworking can be on the same leg (where a leg passes through two or more gateways) or on
different legs. For example, entity A could be in a QSIG network, the rerouting entity and entity B could be in a
SIP network, and entity C could be in a QSIG network. In this case interworking occurs on leg A (scenario A1)
and on leg C (scenario C2). Each instance of interworking conforms to one of the 6 scenarios listed above. No
new interworking scenario is introduced as a result.
Chained diversions can introduce mixed scenarios whereby a particular gateway plays the role of one
scenario for the one diversion and either the same scenario or a different scenario for the next diversion. For
example, consider a gateway performing a scenario C1 role as the result of diversion in the QSIG network
(rerouting entity in the QSIG network) to a diverted-to user in the SIP network. The gateway can also perform
the role of scenario A1 if a further diversion occurs in the SIP network (rerouting entity in the SIP network).
9.2  Mapping of numbers, names and URIs
Most of the examples shown in clause 10 involve mapping of identifiers, e.g., the identifier representing the
diverted to user or the identifier representing the diverting user. In QSIG users are identified by numbers. In
SIP users are identified by URIs. Mapping of identifiers is described in detail in [7].
In some cases it may not be possible for a gateway to map a SIP URI to a QSIG number or vice versa. If it is
not possible to derive an identifier that is essential for generating a signalling element relating to diversion,
unless otherwise stated the call should be allowed to continue without that signalling element.
In some cases it may be possible to map between a QSIG name, as defined in [3], and a SIP URI (e.g., direct
mapping between the display-name field of a URI and a QSIG name).
9.3  Derivation of QSIG diversion reasons
The History-Info header contains one or more entries, each containing a retargeted-from URI and, as an
optional parameter, a Reason header [13]. The Reason header contains the reason for retargeting. Some of
the scenarios require the derivation of a QSIG element of type DiversionReason (indicating CFU, CFB or
CFNR), and the Reason header, where available, is the most suitable source of information for this. At present
the Reason header can contain either a SIP response code or a Q.850 cause value. Normally, if the Reason
header has originated at a native SIP entity as opposed to a gateway, it will contain a SIP response code.
Neither a SIP response code nor a Q.850 cause value can directly indicate a reason for diversion (CFU, CFB
or CFNR). The Reason header can be extended with reasons from other protocols, so therefore has the
potential to include diversion reasons in the future. In the absence of such an extension to the Reason header,
or if such diversion reasons are not received, SIP response codes in the Reason header will have to suffice
8 © ISO/IEC 2005 – All rights reserved

for deriving a QSIG element of type DiversionReason. There needs to be a default diversion reason value to
cater for cases where the Reason header is omitted or where it contains a reason that does not readily
suggest a particular diversion reason. The particular mapping will depend on the scenario concerned.
9.3.1 Scenario A1
In QSIG, diversion reason CFNR (from the diversionReason element of the divertingLegInformation 1 invoke
APDU) is theoretically meaningful only after ALERTING. Also for the first diversion after ALERTING
theoretically the only meaningful diversion reason is CFNR. However, in practice violating these rules will
probably not cause problems at downstream PINXs.
SIP response codes do not readily distinguish between the three diversion reason values, and therefore taking
account of whether ALERTING has been sent is perhaps beneficial in selecting a more meaningful value.
The following rules SHOULD be applied in the absence of an explicit reason for diversion:
1. If the reason code in the Reason header is 486 (Busy Here) or 600 (Busy Everywhere), map to CFB.
2. Otherwise if ALERTING has previously been sent, map to CFNR.
3. Otherwise map to CFU.
9.3.2 Scenario B1
A diversion reason is required for the rerouteingReason element of the callRerouteing invoke APDU. A
History-Info header is not normally contained in the 3xx response (except to denote previous retargets), and
therefore there is no Reason header and the only source of information is the 3xx response code. The various
3xx response codes do not readily map to diversion reasons.
A possible future extension would be to include a Reason header in a 3xx response to indicate the diversion
reason. In the absence of a Reason header, the following rules SHOULD be applied:
1. If ALERTING has previously been sent, map to CFNR.
2. Otherwise map to CFU.
For populating the originalRerouteingReason element from History-Info header entries received in provisional
responses or in the 3xx response, the rules for scenario A1 (9.3.1) apply.
...