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]