Internet DRAFT - draft-rey-sipping-qsig2sip-transfer

draft-rey-sipping-qsig2sip-transfer



SIPPING                                                          JF Rey 
Internet-Draft                                               O Rousseau 
Expires: April 2005                                             Alcatel 
                                                              J. Elwell 
                                                                Siemens 
                                                                        
                                                           October 2004 
    
    
          Interworking between Session Initiation Protocol (SIP) 
                         and QSIG for call transfer  
                draft-rey-sipping-qsig2sip-transfer-01.txt 
    
    
Status of this Memo 
    
    
   By submitting this Internet-Draft, I certify that any applicable 
   patent or other IPR claims of which I am aware have been disclosed, 
   and any of which I become aware will be disclosed, in accordance with 
   RFC 3668. 
    
   This document may not be modified, and derivative works of it may not 
   be created, except to publish it as an RFC and to translate it into 
   languages other than English. 
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups. Note that other 
   groups may also distribute working documents as Internet-Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time. It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress."  
    
   The list of current Internet-Drafts can be accessed at  
        http://www.ietf.org/ietf/1id-abstracts.txt  
   The list of Internet-Draft Shadow Directories can be accessed at  
        http://www.ietf.org/shadow.html.  
    
Copyright Notice 
    
      Copyright (C) The Internet Society (2004). All Rights Reserved. 
    
Abstract 
    
   This document 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 
 
 
Rey et al.                Expires - April 2005                  [Page 1] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
   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 ECMA Standards and published also as ISO/IEC standards. 
    
   This document is a product of the authors' activities in 
   Ecma(www.ecma-international.org) on interoperability of QSIG with IP 
   networks. 
    
    
Table of Contents 
    
   1. Introduction...................................................3 
   2. Conventions used in this document..............................4 
   3. Definitions....................................................5 
   3.1 External definitions..........................................5 
   3.2 Other definitions.............................................5 
   3.2.1 User A......................................................5 
   3.2.2 User B......................................................5 
   3.2.3 User C......................................................5 
   3.2.4 Call transfer...............................................5 
   3.2.5 Single step call transfer...................................6 
   3.2.6 Call transfer by join.......................................6 
   3.2.7 Call transfer by rerouteing.................................6 
   3.2.8 Corporate telecommunication Network (CN)....................6 
   3.2.9 IP network..................................................6 
   3.2.10 Private Integrated Services Network (PISN).................6 
   3.2.11 Private Integrated services Network eXchange (PINX)........6 
   4. Abbreviations and acronyms.....................................7 
   5. Background and architecture for SIP-QSIG interworking..........7 
   6. Call transfers in QSIG.........................................7 
   7. Call transfer in SIP...........................................8 
   8. Transfer interworking..........................................8 
   8.1 Scope of the interworking functions...........................8 
   8.1.1 QSIG side...................................................8 
   8.1.2 SIP side....................................................9 
   8.1.3 Discussion over transfer interworking functions.............9 
   8.2 Mapping of numbers and URIs..................................12 
   8.3 UAC Processing...............................................13 
   8.3.1 Receipt of a FACILITY message with callTransferComplete invoke 
   APDU.............................................................13 
   8.3.2 Receipt of a FACILITY message with callTransferUpdate invoke 
   APDU.............................................................14 
   8.3.3 Receipt of a FACILITY message with ssctInitiate invoke APDU14 
   8.3.4 Receipt of a SETUP message with ssctSetup invoke APDU......15 
   8.3.5 Receipt of a FACILITY message with subaddressTransfer invoke 
   APDU.............................................................16 
 
 
Rey et al.                Expires - April 2005                  [Page 2] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
   8.4 UAS Processing...............................................16 
   8.4.1 Receipt of a SIP REFER request.............................16 
   8.4.1.1 No embedded Replaces header field in the Refer-To URI....16 
   8.4.1.2 Matching embedded Replaces header in the Refer-To URI....18 
   8.4.1.3 Non-matching embedded Replaces header in the Refer-To URI.20 
   8.4.2 Receipt of a SIP INVITE request............................22 
   8.4.2.1 Receipt of an INVITE with no Replaces header.............22 
   8.4.2.2 Receipt of an INVITE with a Replaces header..............23 
   8.4.3 Receipt of a SIP request with revised identity.............23 
   9. Example message sequences.....................................24 
   10. Security Considerations......................................30 
   Normative References.............................................31 
   Informative References...........................................32 
   Authors' Addresses...............................................33 
   Intellectual Property Statement..................................34 
    
    
1. Introduction 
    
   This document specifies signalling interworking between QSIG and the 
   Session Initiation Protocol (SIP) in support of call transfer within 
   a corporate telecommunication network (CN) (also known as enterprise 
   network).  
    
   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 ECMA 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 
   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 IP protocol for establishing, terminating 
   and modifying multimedia sessions. Telephone calls are considered as 
   a type of multimedia session where just audio is exchanged. SIP is 
   defined in [9]. 
    
   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 
 
 
Rey et al.                Expires - April 2005                  [Page 3] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
   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 document specifies SIP-QSIG signalling interworking for transfer 
   services between a PISN employing QSIG and a corporate IP network 
   employing SIP.  
    
    
2. Conventions used in this document 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in RFC-2119 [8] 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.  
   - 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.  


 
 
Rey et al.                Expires - April 2005                  [Page 4] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
   - 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 section 8.2. 
    
    
3. Definitions  
    
   For the purposes of this specification, the following definitions 
   apply.  
    
3.1 External definitions  
    
   The definitions in [1] and [9] apply as appropriate.  
    
3.2 Other definitions 
     
3.2.1 User A 
    
   The served user, i.e. the user requesting Call transfer or Single 
   step call transfer. 
    
3.2.2 User B 
    
   A user who is in communication with User A and who will be 
   transferred to User C. 
    
   NOTE. 
   This definition differs from [3], in order to use similar conventions 
   for QSIG Call transfer and QSIG Single step call transfer. 
    
3.2.3 User C 
    
   The user to whom the call is transferred. 
    
3.2.4 Call transfer 
    
   The act of enabling a user 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 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. 
 
 
Rey et al.                Expires - April 2005                  [Page 5] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
    
3.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 longer be involved in a call with User B or User C. 
    
   Single step call transfer is very similar to the "basic transfer" 
   described in [15]. 
    
3.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. 
    
3.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. 
    
3.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. 
    
3.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.  
    
3.2.10 Private Integrated Services Network (PISN)  
    
   A CN or part of a CN that employs circuit-switched technology and 
   QSIG signalling.  
    
3.2.11 Private Integrated services Network eXchange (PINX)  
    
 
 
Rey et al.                Expires - April 2005                  [Page 6] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
   A PISN nodal entity comprising switching and call handling functions 
   and supporting QSIG signalling in accordance with [1].  
    
    
4. 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  
   UAS   User Agent Server  
   URI   Universal Resource Identifier  
    
    
5. Background and architecture for SIP-QSIG interworking  
    
   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 [9], including 
   the use of the REFER [11] SIP method and Replaces [12] and Referred-
   By [13] SIP header fields.  
    
    
6. Call transfers in QSIG  
    
   For the purposes of QSIG, transfers are classified into one of the  
   following types:  
    
   - call transfer by join: defined in 3.2.6 ;  
   - call transfer by rerouteing: defined in 3.2.7 ; and 
   - single step call transfer: defined in section 3.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. 
 
 
Rey et al.                Expires - April 2005                  [Page 7] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
    
   - 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. 
    
    
7. Call transfer in SIP  
    
   SIP has the concept of requesting a UA to refer (establish a dialog 
   to) a third party [11]. SIP also has the concept of replacing a 
   dialog by another one [12], and provides a mechanism so that 
   information about the initiator of the REFER request is sent to the 
   third party [13]. The call transfer document gives examples on how to 
   support call transfers using these SIP extensions [15]. 
    
    
8. Transfer interworking  
    
8.1 Scope of the interworking functions 
    
8.1.1 QSIG side 
    
   The interworking functions provided in the following sections 
   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. 
 
 
Rey et al.                Expires - April 2005                  [Page 8] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
    
8.1.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.  
    
    
8.1.3 Discussion over transfer interworking functions 
    
   This section 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. 
    














 
 
Rey et al.                Expires - April 2005                  [Page 9] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
            PISN                    IP Network 
                           || 
                           ||   No way to build 
                           ||   |   "Replaces: D2" 
                           ||   v 
      +---------+  CR1 +---------+   D1    +---------+ 
      | User A  |......| gateway |.........| User B  | 
      +---------+      +---------+         +---------+ 
              `.           || 
                `.         || 
                  `.       || 
               CR2  `. +---------+   D2    +---------+ 
                      `| gateway |.........| User C  | 
                       +---------+         +---------+ 
                           || 
                           || 
                           || 
    
      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 section 8.2. 
    
   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. 
    
 
 
Rey et al.                Expires - April 2005                 [Page 10] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
                             +---------+ 
             PISN            | GATEWAY |      IP Network 
                             +---------+ 
              Call Reference CR1  |    Dialog D1 
             <===================>|<====================> 
                                  | 
              (CR1) FACILITY      |  (D1-1)REFER 
              ssctInitiate.inv    |      Refer-To 
              ------------------->|      Referred-By 
                                  |---------------------> 
               The call is placed in the IP network. 
    
                             +---------+ 
             PISN            | GATEWAY |      IP Network 
                             +---------+ 
              Call Reference CR1  |    Dialog D1 
             <===================>|<====================> 
                                  | 
              (CR1) FACILITY      | 
              ssctInitiate.inv    | 
              ------------------->| 
              (CR2) SETUP         | 
              ssctSetup.inv       | 
              <-------------------| 
                 The call is placed in the PISN if the address 
                 derivation fails or if the REFER request fails. 
    
      Figure 2: Example of call-flows on receipt of a ssctInitiate 
      invoke APDU. 
    
   There is also an ambiguity when a SIP REFER requests arrives at a 
   gateway because the gateway might not know if User C (the transfer 
   target) is in the PISN or in the IP network. Therefore the gateway 
   does not know whether to issue an INVITE request or map the REFER 
   request to a QSIG ssctInitiate invoke APDU. If there is an embedded 
   Replaces header field as a parameter of the Refer-To URI in the REFER 
   request, the gateway knows that User C can be reached through the IP 
   network. If there is no Replaces header field, and if the derivation 
   of the Refer-To URI can be done, the gateway sends a QSIG 
   ssctInitiate invoke APDU. If the derivation fails or upon failure of 
   the QSIG ssctInitiate invoke APDU,.a SIP INVITE message is sent 
   accordingly to the REFER request. Figure 3 illustrates this 
   situation. 
    






 
 
Rey et al.                Expires - April 2005                 [Page 11] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
    
                             +---------+ 
              IP Network     | GATEWAY |     PISN 
                             +---------+ 
                Dialog D1           Call Reference CR1 
              <==================>|<====================> 
              (D1-1)REFER         | 
                [no Replaces]     |   (CR1) FACILITY      On receipt 
              ------------------->|    ssctInitiate.inv   of this 
                                  |---------------------> User B calls 
                                  |                       User C 
    
               This call flow occurs if address derivation succeeds. 
    
                             +---------+ 
                  IP Network | GATEWAY |     PISN 
                             +---------+ 
                Dialog D1           Call Reference CR1 
              <==================>|<====================> 
              (D1-1)REFER         | 
                [no Replaces]     | 
              ------------------->|  
              (D2-1)INVITE        |  
              <-------------------|  
    
             This call flow occurs if the previous one fails. 
      Figure 3: Example of call-flows on receipt of a REFER request. 
    
   A Call transfer before answer cannot be implemented with a Replaces 
   header field, because Replaces cannot match an early dialog at the 
   UAS. Therefore "attended transfer" as defined in [15] cannot happen 
   until User C answers the call. That document suggests that 
   "unattended transfer" be used if attended transfer cannot be done. 
    
8.2 Mapping of numbers and URIs  
    
   Most of the interworking functions require the mapping of 
   identifiers, e.g., the identifier User A, User B and User C. In QSIG 
   users are identified by numbers. In SIP users are identified by URIs. 
   Mapping of identifiers is described in detail in [14].  
    
   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 transfer, unless otherwise stated the call should be 
   allowed to continue without that signalling element. In that case, 
   the gateway should use a QSIG indication that the number is not 
   provided for interoperability reasons. 
    
 
 
Rey et al.                Expires - April 2005                 [Page 12] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
   The identity of the remote party must be derived as described in 
   sections 9.1 and 9.2 of [5]. 
    
   Section 10 defines how to proceed in case of privacy or trust issues. 
    
8.3 UAC Processing 
    
8.3.1 Receipt of a FACILITY message with callTransferComplete invoke 
     APDU 
    
   On receipt of a QSIG FACILITY message that contains a 
   callTransferComplete invoke APDU (as a result of transfer by join in 
   the QSIG network), the gateway SHALL send a SIP INVITE request that 
   initiates a new dialog to replace the existing one. The gateway SHALL 
   use the redirectionNumber element of the callTransferComplete invoke 
   APDU to generate identity information in the SIP INVITE request in 
   the same way that a QSIG Calling party number information element is 
   used to generate identity information in a SIP INVITE request when 
   establishing a new call from QSIG to SIP, as specified in [5]. The 
   INVITE request SHALL use a Replaces header [12] to indicate which 
   dialog is replaced. The INVITE request SHOULD use the Referred-By 
   header [13] to indicate the identity of the Referrer and the gateway 
   SHOULD copy the local URI of the replaced dialog into the Referred-By 
   header field. 
    
                             +---------+ 
             PISN            | GATEWAY |      IP Network 
                             +---------+ 
              Call Reference CR1  |    Dialog D1 
             <===================>|<====================> 
                                  | 
              (CR1) FACILITY      |  (D2)INVITE 
              ctComplete.inv      |      Referred-By 
              ------------------->|      Replaces D1 
                                  |---------------------> 
                                  |  (D2) 200 OK 
                                  |<--------------------- 
                                  |  (D1) BYE 
                                  |---------------------> 
    
      Figure 4: Example of message flows on receipt of a FACILITY 
    
   On receipt of an error final response to the INVITE request, no QSIG 
   message is sent. There is no way for the gateway to notify the PINX 
   that the transfer could not be indicated to the user in the SIP 
   network. 
    



 
 
Rey et al.                Expires - April 2005                 [Page 13] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
   If the URI of the identity information field in the SIP request 
   cannot be derived from the QSIG number, the gateway SHALL take no 
   action. 
    
8.3.2 Receipt of a FACILITY message with callTransferUpdate invoke APDU  
    
   On receipt of a QSIG FACILITY message that contains a 
   callTransferUpdate invoke APDU (as a result of the identity of the 
   remote party being updated in the QSIG network), the gateway SHALL 
   look up the optional redirectionNumber. If the information updates 
   the previous settings, the gateway SHALL act as if it received a 
   callTransferComplete invoke APDU (cf. 8.3.1).  
    
8.3.3 Receipt of a FACILITY message with ssctInitiate invoke APDU 
    
   On receipt of a QSIG FACILITY message that contains a ssctInitiate 
   invoke APDU (as a result of a single step call transfer request in 
   the QSIG network), the gateway SHALL send a SIP REFER request inside 
   the current dialog as described in [11]. The URI in the Refer-To 
   header field SHALL be derived from the rerouteingNumber of the 
   ssctInitiate invoke APDU. The REFER request SHOULD use [13] to 
   indicate the identity of the transferor and derive the URI in the 
   Referred-By header field from the transferringAddress of the 
   ssctInitiate invoke APDU.  
    
   On receipt of a SIP NOTIFY request indicating: 
   - a provisional alerting response, the gateway SHOULD send a QSIG 
   FACILITY message that contains a ssctInitiate return result APDU if 
   the awaitConnect boolean value in the invoke APDU is FALSE. 
   - a successful final response, the gateway SHALL send a FACILITY 
   message with the ssctInitiate return result APDU if no ssctInitiate 
   return result or return error APDU has already been sent.  
   - an error final response, the gateway SHALL send a FACILITY message 
   with a ssctInitiate return error APDU, unless a ssctInitiate return 
   result has already been sent. 
    














 
 
Rey et al.                Expires - April 2005                 [Page 14] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
                             +---------+ 
             PISN            | GATEWAY |      IP Network 
                             +---------+ 
              Call Reference CR1  |    Dialog D1 
             <===================>|<====================> 
                                  | 
              (CR1) FACILITY      |  (D1-1)REFER 
              ssctInitiate.inv    |      Refer-To 
              ------------------->|      Referred-By 
                                  |---------------------> 
                                  |  (D1-1)202 ACCEPTED 
                                  |<--------------------- 
              (CR1) FACILITY      |  (D1-2)NOTIFY (200 OK) 
              ssctInitiate.res    |<--------------------- 
              <-------------------| 
              (CR1) RELEASE       | 
              ------------------->|  (D1-3)BYE 
              (CR1) RELEASE CPLT  |---------------------> 
              <-------------------| 
    
      Figure 5: Example of message flows on receipt of a FACILITY 
      message with ssctInitiate invoke APDU 
    
   If the URI in the Refer-To header field cannot be derived, the 
   gateway SHALL send a FACILITY message that contains a ssctInitiate 
   return error APDU.  
    
8.3.4 Receipt of a SETUP message with ssctSetup invoke APDU 
    
   On receipt of a QSIG SETUP message that contains a ssctSetup invoke 
   APDU (as a result of single step call transfer in the QSIG network), 
   the gateway SHALL send a SIP INVITE that initiates a new dialog with 
   the transfer target. The INVITE request SHALL be generated in 
   accordance with [5]. In addition, it SHOULD use [13] to indicate the 
   identity of the transferor and derive the URI in the Referred-By 
   header field from the transferringAddress of the ssctSetup invoke 
   APDU. 
    
   On receipt of responses to the INVITE request, the gateway SHALL act 
   as described in [5]. 
    









 
 
Rey et al.                Expires - April 2005                 [Page 15] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
                             +---------+ 
             PISN            | GATEWAY |      IP Network 
                             +---------+ 
              (CR2) SETUP         | 
              ssctSetup.inv       |  (D2-1)INVITE 
              ------------------->|      Referred-By 
                                  |---------------------> 
                                  |  (D2-1)180 RINGING 
              (CR2) ALERTING      |<--------------------- 
              <-------------------|  (D2-1)200 OK 
              (CR2) CONNECT       |<--------------------- 
              <-------------------| 
    
      Figure 6: Example of message flows on receipt of a SETUP message 
      with ssctSetup invoke APDU 
    
8.3.5 Receipt of a FACILITY message with subaddressTransfer invoke APDU  
    
   On receipt of a QSIG FACILITY message that contains a 
   subaddressTransfer invoke APDU (as a result of the remote party being 
   in the public ISDN and having a subaddress), the gateway MAY derive a 
   SIP or tel URI from the connectedSubaddress and act as if it received 
   a callTransferComplete invoke APDU (see 8.3.1). 
    
8.4 UAS Processing 
    
8.4.1 Receipt of a SIP REFER request 
    
   On receipt of a SIP REFER request that is inside a dialog, the 
   gateway can act in various ways depending on the contents of the 
   Refer-To header field. Only Refer-To URIs with a method=INVITE 
   parameter are in the scope of this document. 
    
   In this section, an embedded Replaces header is a Replaces header 
   field as a parameter of a Refer-To URI. 
    
8.4.1.1 No embedded Replaces header field in the Refer-To URI 
    
   On receipt of a SIP REFER request that is inside a dialog and that 
   has no embedded Replaces header field in the Refer-To URI, the 
   gateway SHALL accept the REFER request.  
    
   If the gateway is able to derive a RerouteingNumber from the Refer-To 
   URI, the gateway SHALL send a QSIG FACILITY message that contains a 
   ssctInitiate invoke APDU. The gateway SHOULD derive the 
   transferringAddress of the ssctInitiate invoke APDU from the 
   Referred-By header field if present. The gateway SHOULD derive the 
   transferredAddress from the identity of the local PISN user in the 


 
 
Rey et al.                Expires - April 2005                 [Page 16] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
   existing dialog. The gateway SHALL include value TRUE in the 
   awaitConnect element. 
    
   On receipt of a QSIG FACILITY message that includes a ssctInitiate 
   return result APDU, the gateway SHALL send a SIP NOTIFY request as 
   described in [11]. The final status in the NOTIFY body is "200 OK".  
    
                                +---------+  
                 IP Network     | GATEWAY |     PISN  
                                +---------+  
                   Dialog D1           Call Reference CR1  
                 <==================>|<====================>  
                 (D1-1)REFER         |  
                   [no Replaces]     |  
                 ------------------->|  
                 (D1-1)202 ACCEPTED  |   (CR1) FACILITY  
                 <-------------------|    ssctInitiate.inv  
                 (D1-2)NOTIFY (100)  |--------------------->  
                 <-------------------|  
                                     |   (CR1) FACILITY  
                                     |    ssctInitiate.res  
                 (D1-3)NOTIFY (200)  |<---------------------  
                 <-------------------|  
                                     |  
    
      Figure 7: Example of message flows on receipt of a SIP REFER 
      request (no Replaces header) 
    
   If the derivation of the rerouteingNumber fails, or upon reception of 
   a QSIG FACILITY message that includes a ssctInitiate return error 
   APDU, the gateway SHALL send a SIP INVITE message as described in 
   [11] and in [12]. The gateway SHALL then comply with [12] and [13] 
   and send SIP NOTIFY messages that indicate the result of the INVITE 
   transaction.  
    
   On receipt of a "180 RINGING" provisional response to the INVITE 
   request, the gateway SHOULD send a QSIG FACILITY message that 
   contains a callTransferComplete invoke APDU with a callStatus of 
   "alerting".  
    
   On receipt of a successful final response to the INVITE request, the 
   gateway SHALL send a QSIG FACILITY message that contains : 
   - a callTransferActive invoke APDU, if a callTransferComplete invoke 
   APDU has already been sent, or 
   - a callTransferComplete invoke APDU with a callStatus of "answered". 
    
   The gateway SHALL derive the redirectionNumber of the 
   callTransferComplete invoke APDU and the connectedAddress of the 
   callTransferActive invoke APDU from the identity information 
 
 
Rey et al.                Expires - April 2005                 [Page 17] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
   representing the called party transported in the responses to the 
   INVITE request, or from the URI in the Refer-To header field if no 
   identity information is available. If the derivation fails, the 
   gateway SHALL signal that numbers and addresses are not available due 
   to interworking issues. 
    
   On receipt of an error final response to the INVITE request and if a 
   callTransferComplete invoke APDU was invoked before, the gateway 
   SHOULD send a FACILITY message that contains a callTransferActive 
   invoke APDU. It indicates that the QSIG call between transferor and 
   transferee is active again. 
    
                                +---------+  
                 IP Network     | GATEWAY |     PISN  
                                +---------+  
                   Dialog D1         | Call Reference CR1  
                 <==================>|<====================>  
                 (D1-1)REFER         |  
                       [No Replaces] | * Refer-To URI       * 
                 ------------------->| * derivation failure *  
                 (D1-1)202 ACCEPTED  |   
                 <-------------------| 
                                     | 
                 (D2-1)INVITE        |  
                 <-------------------|    
                                     |  (CR1) FACILITY   
                 (D2-1) 200 OK       |  CTComplete.inv 
                 ------------------->| callStatus=answered  
                                     |--------------------->   
                                     |  
                 (D1-2) NOTIFY (200) |  
                 <-------------------|  
    
      Figure 8: Example of message flows on receipt of a SIP REFER 
      request (no Replaces header) when address derivation fails 
    
    
8.4.1.2 Matching embedded Replaces header in the Refer-To URI 
    
   On receipt of a SIP REFER request that is inside a dialog and that 
   has an embedded Replaces header field in the Refer-To URI, the 
   gateway SHALL determine whether the Refer-To URI identifies the 
   gateway. If it does not identify the gateway, the gateway SHALL act 
   as described in section 8.4.1.3.  
    
   If the Refer-To URI identifies the gateway, the gateway SHALL accept 
   the REFER request and look up its internal list of SIP dialogs. If 
   one of the dialogs matches the Replaces header field contents as 
   described in [12], the gateway SHALL send a QSIG FACILITY message 
 
 
Rey et al.                Expires - April 2005                 [Page 18] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
   that contains a callTransferComplete invoke APDU with the QSIG call 
   reference that maps to the SIP dialog of the REFER message. The 
   gateway SHALL copy the number of the PISN party of the matched dialog 
   to the redirectionNumber of the callTransferComplete invoke APDU.  
    
   If the matching dialog is: 
   - not established then the callStatus of the callTransferComplete 
   invoke APDU SHALL be "alerting", and the gateway SHALL send a SIP 
   NOTIFY request with a body that indicates the latest provisional 
   response code sent on the matching dialog, 
   - established then the callStatus of the callTransferComplete invoke 
   APDU SHALL be "answered", and the gateway SHALL send a NOTIFY request 
   with a body that indicates "200 OK". 
    
   The gateway SHALL also send a FACILITY message that contains a 
   callTransferComplete invoke APDU with the QSIG call reference that 
   maps the matching SIP dialog. The gateway SHALL derive the 
   redirectionNumber of the callTransferComplete invoke APDU from the 
   number of the PISN party in the dialog to which the REFER request 
   belongs. The gateway SHALL include value ˘answered÷ in the callStatus 
   element. The gateway SHALL join the two QSIG calls together and act 
   as a transit PINX as defined in [1]. 
    
   The gateway MAY then release the two SIP dialogs. 


























 
 
Rey et al.                Expires - April 2005                 [Page 19] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
                             +---------+ 
              IP Network     | GATEWAY |     PISN 
                             +---------+ 
                Dialog D1         | Call Reference CR1 
              <==================>|<====================> 
                Dialog D2         | Call Reference CR2 
              <==================>|<====================> 
              (D1-1)REFER         | 
                    Replaces: D2  | 
              ------------------->| * match * 
              (D1-1)202 ACCEPTED  |   (CR1) FACILITY 
              <-------------------|    ctComplete.inv 
                                  |    callStatus=answered 
              (D1-2)NOTIFY (200)  |---------------------> 
              <-------------------|   (CR2) FACILITY 
                                  |    ctComplete.inv 
                                  |    callStatus=answered 
                                  |---------------------> 
                                  | 
                                  | 
              (D1-3) BYE          | 
              <-------------------| 
              (D2-1) BYE          | 
              <-------------------| 
    
      Figure 9: Example of message flows on receipt of a SIP REFER 
      request (matching Replaces header field) 
    
8.4.1.3 Non-matching embedded Replaces header in the Refer-To URI. 
    
   If the Refer-To URI identifies the gateway but none of the internal 
   list of dialogs matches the Replaces header field contents as 
   described in [12], the gateway SHALL reject the REFER request with a 
   SIP response code of "502 Bad Gateway". 
    
                             +---------+ 
              IP network     | GATEWAY |     PISN 
                             +---------+ 
                Dialog D1         | Call Reference CR1 
              <==================>|<====================> 
              (D1-1)REFER         | 
                   Replaces: D2   | 
              ------------------->| * no match * 
              (D1-1)502 Bad Gateway 
              <-------------------| 
    
      Figure 10: Example of message flows on receipt of a SIP REFER 
      request (rejection on non-matching Replaces header field) 
    
 
 
Rey et al.                Expires - April 2005                 [Page 20] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
   If the Refer-To URI does not identify the gateway, the gateway SHALL 
   accept the REFER request and send a SIP INVITE message as described 
   in [11] and [12]. The gateway SHALL then comply with [11] and [12] 
   and send SIP NOTIFY messages that indicate the result of the INVITE 
   transaction.  
    
   On receipt of a "180 RINGING" provisional response to the INVITE 
   request, the gateway SHOULD send a QSIG FACILITY message that 
   contains a callTransferComplete invoke APDU with a callStatus of 
   "alerting". The FACILITY message SHALL be sent with the QSIG call 
   reference that maps to the SIP dialog of the REFER message. 
    
   On receipt of a successful final response to the INVITE request, the 
   gateway SHALL send a QSIG FACILITY message that contains : 
   - a callTransferActive invoke APDU, if a callTransferComplete invoke 
   APDU has already been sent, or 
   - a callTransferComplete invoke APDU with a callStatus of "answered". 
   The FACILITY message SHALL be sent with the QSIG call reference that 
   maps to the SIP dialog of the REFER message. 
    
   The gateway SHALL derive the redirectionNumber of the 
   callTransferComplete invoke APDU and the connectedAddress of the 
   callTransferActive invoke APDU from the URI in the Refer-To header 
   field or from other identity information representing the SIP called 
   party transported in the responses to the INVITE request. 
    
   On receipt of an error final response to the INVITE request and if a 
   callTransferComplete invoke APDU was invoked before, the gateway 
   SHOULD send a FACILITY message that contains a callTransferActive 
   invoke APDU. It indicates that the QSIG call between transferor and 
   transferee is active again. 
    


















 
 
Rey et al.                Expires - April 2005                 [Page 21] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
                             +---------+ 
              IP Network     | GATEWAY |     PISN 
                             +---------+ 
                Dialog D1         | Call Reference CR1 
              <==================>|<====================> 
              (D1-1)REFER         | 
                    Replaces: D2  | 
              ------------------->| * no match * 
              (D1-1)202 ACCEPTED  | 
              <-------------------| 
              (D1-2)NOTIFY (100)  | 
              <-------------------| 
              (D3-1)INVITE        | 
                   Referred-By    | 
                   Replaces: D2   | 
              <-------------------|   (CR1) FACILITY 
              (D3-1)200 OK        |    ctComplete.inv 
              ------------------->|    callStatus=answered 
              (D1-3)NOTIFY (200)  |---------------------> 
              <-------------------| 
              (D1-4) BYE          | 
              <-------------------| 
                                  | 
    
      Figure 11: Example of message flows on receipt of a SIP REFER 
      request (accept non-matching Replaces header field) 
    
8.4.2 Receipt of a SIP INVITE request 
    
8.4.2.1 Receipt of an INVITE with no Replaces header 
    
   On receipt of a SIP INVITE request that is outside a dialog and that 
   has no Replaces header, the gateway SHALL send a QSIG SETUP message 
   as described in [5]. If the INVITE request includes a Referred-By 
   header field, the QSIG SETUP message SHOULD contain a ssctSetup 
   invoke APDU with a transferringAddress derived from the Referred-By 
   header described in [13]. 
    
                             +---------+ 
              IP Network     | GATEWAY |     PISN 
                             +---------+ 
              (D1-1)INVITE        | 
                   Referred-By    |   (CR1) SETUP 
              ------------------->|    ssctSetup.inv 
                                  |-------------------> 
                                 ... 
    
      Figure 12: Example of message flows on receipt of a SIP INVITE 
      request (no Replaces header) 
 
 
Rey et al.                Expires - April 2005                 [Page 22] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
    
8.4.2.2 Receipt of an INVITE with a Replaces header 
    
   On receipt of a SIP INVITE request that is outside a dialog and that 
   has a matching Replaces header field [12], the gateway SHALL send an 
   QSIG FACILITY message that contains a callTransferComplete invoke 
   APDU. The FACILITY message is sent with the QSIG call reference that 
   maps to the SIP dialog matched against the Replaces header field. The 
   redirectionNumber in the callTransferComplete invoke APDU SHALL be 
   derived from the SIP URI representing the calling party as described 
   in section "9.2.2 Generating the QSIG Calling party number 
   information element" of [5]. 
    
                             +---------+ 
              IP Network     | GATEWAY |     PISN 
                             +---------+ 
                 Dialog D1        | Call Reference CR1 
              <==================>|<==================> 
              (D2-1)INVITE        | 
                   Referred-By    | 
                   Replaces: D1   |   (CR1) FACILITY 
              ------------------->|    ctComplete.inv 
              (D2-1) 200 OK       |-------------------> 
              <-------------------| 
              (D1-1) BYE          | 
              <-------------------| 
    
      Figure 13: Example of message flows on receipt of a SIP INVITE 
      request (matching Replaces header field) 
    
   If the Replaces header field does not match, the gateway SHALL reject 
   the INVITE request as described in [12]. Note that this may happen if 
   two different gateways can be used to reach the QSIG side. 
    
8.4.3 Receipt of a SIP request with revised identity 
    
   On receipt of a SIP request (for instance, UPDATE or INVITE) that is 
   within a dialog and that transports a revised identity, the gateway 
   MAY send a QSIG FACILITY message that contains a callTransferComplete 
   invoke APDU. The FACILITY message is sent with the QSIG call 
   reference that maps to the SIP dialog. The redirectionNumber in the 
   callTransferComplete invoke APDU SHALL be derived from the revised 
   identity. 
    
    
    
    
    
    
 
 
Rey et al.                Expires - April 2005                 [Page 23] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
9. Example message sequences  
    
      B           Gateway           A           Gateway           C 
    (SIP)            1            (QSIG)           2            (SIP) 
      | Dialog D1    | Call Ref CR1 | Call Ref CR2 | Dialog D2    | 
      |<============>|<============>|<============>|<============>| 
    ................................................................. 
    : |              |              :                             | : 
    : |(D3-1)INVITE  |(CR1)FACILITY |(CR2)FACILITY |(D4-1)INVITE  | : 
    : |Replaces:D1   |ctComplete.inv|ctComplete.inv|Replaces:D2   | : 
    : |Referred-By:A |<-------------|------------->|Referred-By:A | : 
    : |Identity:C    |              |              |Identity:B    | : 
    : |<-------------|              |              |<-------------| : 
    : |(D3-1)200 OK  |              |              |(D4-1)200 OK  | : 
    : |------------->|              |              |------------->| : 
    : |(D3-2)ACK     |              |              |(D4-2)ACK     | : 
    : |<-------------|              |              |<-------------| : 
    : | Dialog D3    |              |              | Dialog D4    | : 
    : |<============>|              |              |<============>| : 
    : |(D1-1)BYE     |              |              |(D2-1)BYE     | : 
    : |<-------------|              |              |------------->| : 
    : |(D1-1)200 OK  |                             |(D2-1)200 OK  | : 
    : |------------->|   ...........:...........   |<-------------| : 
    :                    :  8.3.1   :  8.3.1   :                    : 
    :....................:..........:..........:....................: 
    
      Figure 14: Example of Call transfer by Join where User B and User 
      C are SIP participants 
    
   NOTE. 
   If Gateway 1 and Gateway 2 of Figure 14 are the same gateway, some 
   implementation dependant optimization mechanisms using a SIP REFER 
   request may take place.  

















 
 
Rey et al.                Expires - April 2005                 [Page 24] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
      A           Gateway            B                  C 
    (SIP)            1            (QSIG)            (QSIG) 
      |  Dialog D1   | Call Ref CR1 |                  | 
      |<============>|<============>|                  | 
      |  Dialog D2   |              |  Call Ref CR2    | 
      |<============>|<=============^=================>| 
      |              |              |                  | 
    ...................................................... 
    : | (D1-1)REFER  |              |                  | : 
    : | Refer-To:    |              |                  | : 
    : | C;Replaces:D2|              |                  | : 
    : |------------->| *match*      |                  | : 
    : | (D1-1)202    |(CR1)FACILITY |                  | : 
    : |<-------------|ctComplete.inv|                  | : 
    : | (D1-2)NOTIFY |------------->|  (CR2)FACILITY   | : 
    : |       200    |              |  ctComplete.inv  | : 
    : |<-------------|--------------^----------------->| : 
    : | (D1-2)200 OK |              |                  | : 
    : |------------->|              |                  | : 
    : | (D1-3)BYE    |              |                  | : 
    : |<-------------|              |                  | : 
    : | (D1-3)200 OK |              |                  | : 
    : |------------->|              |                  | : 
    : | (D2-1)BYE    |              |                  | : 
    : |<-------------|              |                  | : 
    : | (D2-1)200 OK |              |                  | : 
    : |------------->|              |         ...........: 
    : |              |              |         :  8.4.1.2 : 
    :.........................................:..........: 
      |              |              |                  | 
    
      Figure 15: Example of Call transfer by join where User A is a SIP 
      participant and where one gateway is used. 
    
















 
 
Rey et al.                Expires - April 2005                 [Page 25] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
      B           Gateway           A           Gateway           C 
    (QSIG)           1            (SIP)            2           (QSIG) 
      | Call Ref CR1 | Dialog D1    | Dialog D2    | Call Ref CR2 | 
      |<============>|<============>|<============>|<============>| 
    ................................................................. 
    : |              |              :                             | : 
    : |              |(D1-1)REFER   |              |              | : 
    : |              |Refer-To:     |              |              | : 
    : |              |C;Replaces:D2 |              |              | : 
    : |              |<-------------|              |              | : 
    : |              |(D1-1)202     |              |              | : 
    : |              |------------->|              |              | : 
    : |              |(D1-2)NOTIFY  |              |              | : 
    : |              |      100     |              |              | : 
    : |              |------------->|              |              | : 
    : |              |(D1-2)200 OK  |(D3-1)INVITE  |              | : 
    : |              |<-------------|To:C          |              | : 
    : |              |              |Replaces:D2   |(CR2)FACILITY | : 
    : |              |--------------^------------->|ctComplete.inv| : 
    : |(CR1)FACILITY |              |(D3-1)200 OK  |------------->| : 
    : |ctComplete.inv|<-------------^--------------|              | : 
    : |<-------------|              |(D3-2)ACK     |              | : 
    : |              |--------------^------------->|              | : 
    : |              | Dialog D3    |              |              | : 
    : |              |<=============^=============>|              | : 
    : |              |(D1-3)NOTIFY  |(D2-1)BYE     |              | : 
    : |              |      200     |<-------------|              | : 
    : |              |------------->|(D2-1)200 OK  |              | : 
    : |              |(D1-3)200 OK  |------------->|              | : 
    : |              |<-------------|              |              | : 
    : |              |(D1-4)BYE     |              |              | : 
    : |              |<-------------|              |              | : 
    : |              |(D1-4)200 OK  |              |              | : 
    : |              |------------->|              |              | : 
    :                                                               : 
    :                    ...........:...........                    : 
    :                    :  8.4.1.3 :  8.4.2.2 :                    : 
    :....................:..........:..........:....................: 
    
      Figure 16: Example of Call transfer by join where User A is a SIP 
      participant and where two gateways are used. 









 
 
Rey et al.                Expires - April 2005                 [Page 26] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
     A              B           Gateway               C 
   (SIP)          (SIP)            1               (QSIG) 
     |  Dialog D1   |              |                  | 
     |<============>|              |                  | 
     |              |   Dialog D2  |  Call Ref CR2    | 
     |<=============^=============>|<================>| 
     | (D1-1)REFER  |              |                  | 
     | Refer-To:    |              |                  | 
     | C;Replaces:D2|              |                  | 
     |------------->|              |                  | 
     | (D1-1)202    |              |                  | 
     |<-------------|.................................... 
     | (D1-2)NOTIFY |:             |                  | : 
     |       100    |: (D3-1)INVITE|                  | : 
     |<-------------|:  Replaces:D2|                  | : 
     | (D1-2)200 OK |------------->| *match*          | : 
     |------------->|: (D3-1)200 OK|  (CR2)FACILITY   | : 
     | (D1-3)NOTIFY |<-------------|  ctComplete.inv  | : 
     |       200    |: (D3-2)ACK   |----------------->| : 
     |<-------------|------------->|                  | : 
     | (D1-3)200 OK |:             |                  | : 
     |------------->|:             |                  | : 
     |              |: (D2-1)BYE   |                  | : 
     |--------------^------------->|                  | : 
     |              |: (D2-1)200 OK|                  | : 
     |<-------------^--------------|         ...........: 
     |              |:             |         :  8.4.2.2 : 
     | (D1-4)BYE    |:.......................:..........: 
     |<-------------|              |                  | 
     | (D1-4)200 OK |              |                  | 
     |------------->|              |                  | 
    
      Figure 17: Example of Call transfer by join where User A and User 
      B are SIP participants. 
    















 
 
Rey et al.                Expires - April 2005                 [Page 27] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
      A           Gateway          B            Gateway           C 
    (QSIG)           1            (SIP)            2           (QSIG) 
      | Call Ref CR1 |  Dialog D1   |              |              | 
      |<============>|<============>|              |              | 
    ................................................................. 
    : |              |              :              |              | : 
    : |(CR1)FACILITY |              |              |              | : 
    : |ssctInitiate.inv (D1-1)REFER |              |              | : 
    : |------------->|Refer-To:C    |(D2-1)INVITE  |              | : 
    : |              |Referred-By:A |Referred-By:A |              | : 
    : |              |------------->|Identity:B    |(CR2)SETUP    | : 
    : |              |(D1-1)202     |------------->|ssctSetup.inv | : 
    : |              |<-------------|(D2-1)100     |------------->| : 
    : |              |(D1-2)NOTIFY  |<-------------|(CR2)CALLPROC | : 
    : |              |      100     |              |<-------------| : 
    : |              |<-------------|              |(CR2)ALERTING | : 
    : |              |(D1-2)200 OK  |(D2-1)180     |<-------------| : 
    : |              |------------->|<-------------|(CR2)CONNECT  | : 
    : |              |(D1-3)NOTIFY  |              |ssctSetup.res | : 
    : |              |      180     |(D2-1)200 OK  |<-------------| : 
    : |              |<-------------|<-------------|(CR2)CON. ACK | : 
    : |              |(D1-3)200 OK  |(D2-2)ACK     |------------->| : 
    : |              |------------->|------------->|              | : 
    : |(CR1)FACILITY |(D1-4)NOTIFY  | Dialog D2    | Call Ref CR2 | : 
    : |ssctInitiate  |      200     |<============>|<============>| : 
    : |          .res|<-------------|              |              | : 
    : |<-------------|(D1-4)200 OK  |              |              | : 
    : |              |------------->|              |              | : 
    : |(CR1)         |(D1-5)BYE     |              |              | : 
    : |   DISCONNECT |<-------------|              |              | : 
    : |<-------------|              |              |              | : 
    : |              |              |              |              | : 
    : |              |   ...........:...........                    : 
    :                    :  8.3.3   :  8.4.2.1 :                    : 
    :....................:..........:..........:....................: 
    
      Figure 18: Example of a Single-Step Call transfer where User B is 
      a SIP participant. 
    











 
 
Rey et al.                Expires - April 2005                 [Page 28] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
      A              C           Gateway          B 
     (SIP)         (SIP)            1           (QSIG) 
      | Dialog D1    |              | Call Ref CR1 | 
      |<=============^=============>|<============>| 
      |              |                             | 
    ................................................ 
    : |(D1-1)REFER   |              |              | 
    : |Refer-To:C    |              |              | 
    : |--------------^------------->|* derivation  | 
    : |(D1-1)202     |              | of C URI     | 
    : |<-------------^--------------| fails *      | 
    : |(D1-2)NOTIFY  |              |              | 
    : |      100     |              |              | 
    : |<-------------^--------------|              | 
    : |(D1-2)200 OK  |              |              | 
    : |--------------^------------->|              | 
    : |              |(D2-1)INVITE  |              | 
    : |              | Referred-By:A|              | 
    : |              |<-------------|(CR1)FACILITY | 
    : |(D1-3)NOTIFY  |(D2-1)180     |ctComplete.inv| 
    : |      180     |------------->|callStatus=alerting 
    : |<-------------^--------------|------------->| 
    : |(D1-3)200 OK  |              |              | 
    : |--------------^------------->|              | 
    : |              |(D2-1)408     |              | 
    : |              |------------->|              | 
    : |(D1-4)NOTIFY  |(D2-2)ACK     |(CR1)FACILITY | 
    : |      408     |<-------------|ctActive.inv  | 
    : |<-------------^--------------|------------->| 
    : |(D1-4)200 OK  |              |              | 
    : |--------------^------------->|              | 
    : |              |              |  ............: 
    :                                  :  8.4.1.1  : 
    :..................................:.......... . 
    
      Figure 19: Example of an unsuccessful Single-Step Call transfer 
      where User A and User C are SIP participants. 
    












 
 
Rey et al.                Expires - April 2005                 [Page 29] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
      A              B           Gateway               C 
    (SIP)          (SIP)            1               (QSIG) 
      |  Dialog D1   |              |                  | 
      |<============>|              |                  | 
      |              |              |                  | 
      | (D1-1)REFER  |              |                  | 
      | Refer-To:C   |              |                  | 
      | Referred-By:A|              |                  | 
      |------------->|              |                  | 
      | (D1-1)202    |              |                  | 
      |<-------------|.................................... 
      | (D1-2)NOTIFY |:             |                  | : 
      |       100    |: (D2-1)INVITE|                  | : 
      |<-------------|:Referred-By:A|  (CR1)SETUP      | : 
      | (D1-2)200 OK |------------->|  ssctSetup.inv   | : 
      |------------->|:             |----------------->| : 
      | (D1-3)NOTIFY |:             |  (CR1)ALERTING   | : 
      |       180    |: (D2-1)180   |<-----------------| : 
      |<-------------|<-------------|  (CR1)CONNECT    | : 
      | (D1-3)200 OK |: (D2-1)200 OK|<-----------------| : 
      |------------->|<-------------|  (CR1)CONNECT ACK| : 
      | (D1-4)NOTIFY |: (D2-2)ACK   |----------------->| : 
      |       200    |------------->|                  | : 
      |<-------------|:             |                  | : 
      | (D1-4)200 OK |: Dialog D2   |Call Reference CR2| : 
      |------------->|<============>|<================>| : 
      | (D1-5)BYE    |:                       ...........: 
      |------------->|:                       :  8.4.2.1 : 
      | (D1-5)200 OK |:.......................:..........: 
      |<-------------| 
    
      Figure 20: Example of a Single-Step Call transfer where User A and 
      User B are SIP participants. 
    
    
10. Security Considerations 
    
   The security considerations related to the SIP mechanisms used in 
   this document apply. 
    
   The security considerations related to the derivation of address and 
   identity between SIP and QSIG described in [5] apply. 
    
   The security considerations due to the transfer interworking 
   functions between QSIG and SIP are related to the derivation of the 
   identity of User A, User B and User C.  
    
   If identity information issued by the IP network is not trusted, the 
   gateway SHOULD not derive the transferredAddress, transferringAddress 
 
 
Rey et al.                Expires - April 2005                 [Page 30] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
   and redirectionNumber of the QSIG invoke APDUs from the SIP header 
   fields. It SHOULD indicate that the numbers are not available due to 
   interworking.  
    
   If identity information issued by the IP network is not to be 
   disclosed for privacy reasons, as indicated in the Privacy header 
   [10], the gateway SHALL not derive the transferredAddress, 
   transferringAddress and redirectionNumber of the QSIG invoke APDUs 
   from the SIP header fields, unless the targeted PINX is in the same 
   domain, in which case the gateway SHALL indicate that the numbers are 
   not available due to screening. If the targeted PINX is in the same 
   domain applies and the Privacy header defined in [10] is used, the 
   gateway MAY derive the identity information and SHALL indicate that 
   the presentation is restricted. 
    
   If identity information issued by the PISN is not to be disclosed 
   because of local policy or PISN privacy requests, the gateway SHALL 
   not derive SIP header field URIs from the transferredAddress, 
   transferringAddress and redirectionNumber of the QSIG invoke APDUs, 
   unless the targeted SIP entity is in the same domain, in which case 
   the information MAY be disclosed in conjunction with the Privacy 
   header defined in [10]. 
    
    
Normative References 
    
   [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). 
    
   [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 


 
 
Rey et al.                Expires - April 2005                 [Page 31] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
       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] Bradner, S., "Key words for use in RFCs to Indicate Requirement 
       Levels", BCP 14, RFC 2119. 
    
   [9] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation 
       protocol", RFC 3261. 
    
   [10] J. Peterson, "A Privacy Mechanism for the Session Initiation 
       Protocol (SIP)", RFC 3323. 
    
   [11] R. Sparks, "The Session Initiation Protocol (SIP) REFER Method", 
       RFC 3515. 
    
   [12] R. Mahy, B. Biggs, R. Dean, "The Session Inititation Protocol 
       (SIP) "Replaces" Header", RFC 3891. 
    
   [13] R. Sparks, "The Session Initiation Protocol (SIP) Referred-By 
       Mechanism", RFC 3892. 
    
    
Informative References 
    
   [14] Ecma Technical Report TR/86, "Corporate Telecommunication 
       Networks -- User Identification in a SIP/QSIG Environment". 
    
   [15] R. Sparks, A. Johnston, "Session Initiation Protocol Call 
       Control - Transfer", draft-ietf-sipping-cc-transfer-03 (work in 
       progress). 
 
 
Rey et al.                Expires - April 2005                 [Page 32] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
    
    
Authors' Addresses 
    
   Jean-Francois Rey 
   Alcatel Business Systems 
   8, rue de Kervezennec  BP 82 802 
   29228 Brest cedex 2 
   France 
   Email: jean-francois.rey@alcatel.fr 
    
   Olivier Rousseau 
   Alcatel Business Systems 
   32, Avenue Kleber 
   92700 Colombes 
   France  
   email: olivier.rousseau@alcatel.fr 
    
   John Elwell 
   Siemens Communications 
   Technology Drive 
   Beeston 
   Nottingham, UK, NG9 1LA 
   email: john.elwell@siemens.com 
    

























 
 
Rey et al.                Expires - April 2005                 [Page 33] 
Internet-Draft           qsig2sip-transfer-01             October 2004 
 
 
Intellectual Property Statement 
    
   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed to 
   pertain to the implementation or use of the technology described in 
   this document or the extent to which any license under such rights 
   might or might not be available; nor does it represent that it has 
   made any independent effort to identify any such rights. Information 
   on the IETF's procedures with respect to rights in IETF Documents can 
   be found in BCP 78 and BCP 79. 
    
   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use of 
   such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository at 
   http://www.ietf.org/ipr. 
    
   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard. Please address the information to the IETF at ietf-
   ipr@ietf.org. 
 
Disclaimer of Validity 
    
   This document and the information contained herein are provided on an 
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
    
Copyright Statement 
    
   Copyright (C) The Internet Society (2004). This document is subject 
   to the rights, licenses and restrictions contained in BCP 78, and 
   except as set forth therein, the authors retain all their rights. 
    
Acknowledgement 
    
   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 
    
    
    



 
 
Rey et al.                Expires - April 2005                 [Page 34]