SIPPING JF Rey Internet Draft O Rousseau Expires: July 2004 Alcatel J. Elwell Siemens February 2004 Interworking between Session Initiation Protocol (SIP) and QSIG for call transfer draft-rey-sipping-qsig2sip-transfer-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. 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. 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 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. Rey et al. Expires - July 2004 [Page 1] Internet-Draft qsig2sip-transfer-00 February 2004 Table of Contents 1. Introduction...................................................3 2. Conventions used in this document..............................4 3. Definitions....................................................4 3.1 External definitions..........................................5 3.2 Other definitions.............................................5 3.2.1 Call transfer...............................................5 3.2.2 Single Step Call transfer...................................5 3.2.3 Call transfer by join.......................................5 3.2.4 Call transfer by rerouteing.................................5 3.2.5 Corporate telecommunication Network (CN)....................5 3.2.6 Gateway.....................................................6 3.2.7 IP network..................................................6 3.2.8 Private Integrated Services Network (PISN)..................6 3.2.9 Private Integrated services Network eXchange (PINX).........6 3.2.10 User A.....................................................6 3.2.11 User B.....................................................6 3.2.12 User C.....................................................6 4. Acronyms.......................................................6 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....................................................8 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 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............................21 8.4.2.1 Receipt of an INVITE with no Replaces header.............21 8.4.2.2 Receipt of an INVITE with a Replaces header..............22 9. Example message sequences.....................................23 10. Security Considerations......................................29 Normative References.............................................30 Rey et al. Expires - July 2004 [Page 2] Internet-Draft qsig2sip-transfer-00 February 2004 Informative References...........................................31 Authors' Addresses...............................................32 Intellectual Property Statement..................................33 Full Copyright Statement.........................................33 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 [2] (call control in support of basic services), [3] (generic functional protocol for the support of supplementary services) and a number of Standards specifying individual supplementary services. Transfer services are specified in [5], [7] and the QSIG signalling protocol in support of these services is specified in [6], [8]. 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 [1]. As the support of telephony within corporate networks evolves from circuit-switched technology to Internet technology, the two technologies will co-exist in many networks for a period, perhaps several years. Therefore there is a need to be able to establish, modify, terminate and transfer sessions involving participants in the SIP network and participants in the QSIG network. Such calls are supported by gateways that perform interworking between SIP and QSIG. This document specifies SIP-QSIG signalling interworking for transfer services between a PISN employing QSIG and a corporate IP network employing SIP. Rey et al. Expires - July 2004 [Page 3] Internet-Draft qsig2sip-transfer-00 February 2004 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 [4] 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 [2] and [3]. 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. - 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 Rey et al. Expires - July 2004 [Page 4] Internet-Draft qsig2sip-transfer-00 February 2004 For the purposes of this specification, the following definitions apply. 3.1 External definitions The definitions in [2] and [1] apply as appropriate. 3.2 Other definitions 3.2.1 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 [17]. A Call transfer before answer is a Call transfer that occurs before User C answers the call initiated by User A. 3.2.2 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) which 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 will no longer be involved in a call with User B or User C. Note: Single-Step Call transfer is very similar to the "basic transfer" described in [17]. 3.2.3 Call transfer by join The effecting of transfer by joining together the connections of the calls to User B and User C at User A's PINX. 3.2.4 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.5 Corporate telecommunication Network (CN) Sets of privately-owned or carrier-provided equipment that are located at geographically dispersed locations and are interconnected to provide telecommunication services to a defined group of users. Rey et al. Expires - July 2004 [Page 5] Internet-Draft qsig2sip-transfer-00 February 2004 NOTE 1. A CN can comprise a PISN, a private IP network (intranet) or a combination of the two. NOTE 2. Also known as enterprise network. 3.2.6 Gateway An entity that performs interworking between a PISN using QSIG and an IP network using SIP. 3.2.7 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.8 Private Integrated Services Network (PISN) A CN or part of a CN that employs circuit-switched technology. 3.2.9 Private Integrated services Network eXchange (PINX) A PISN nodal entity comprising switching and call handling functions and supporting QSIG signalling in accordance with [2]. 3.2.10 User A The served user, i.e. the user requesting Call transfer or Single- Step Call transfer. 3.2.11 User B A user who is in communication with User A and who will be transferred to User C. NOTE. This definitions differs from [5], in order to use similar conventions for QSIG Call transfer and QSIG Single-Step Call transfer. 3.2.12 User C The user to whom the call is transferred. 4. Acronyms APDU Application Protocol Data Unit IP Internet Protocol PINX Private Integrated services Network eXchange Rey et al. Expires - July 2004 [Page 6] Internet-Draft qsig2sip-transfer-00 February 2004 PISN Private Integrated Services Network SIP Session Initiation Protocol UA User Agent UAC User Agent Client UAS User Agent Server 5. Background and architecture for SIP-QSIG interworking The background and architecture of [11] 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 [6],[8] and SIP [1], including the use of UPDATE [10] and REFER [9] SIP methods, 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.3 ; - call transfer by rerouteing: defined in 3.2.4 ; and - single-step call transfer: defined in section 3.2.2. QSIG Call transfer by rerouteing is out of scope of this document because of its lesser deployment. QSIG signalling for transfers is based on [3] 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 comprises a "rerouteingNumber" of User C. It comprises 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 in alerting state. - callTransferActive - this unconfirmed operation is sent to User B. It indicates that answer has taken place following an alerting transfer. It comprises 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 comprises an alerting indication referred later in this document as Rey et al. Expires - July 2004 [Page 7] Internet-Draft qsig2sip-transfer-00 February 2004 "callStatus". It comprises 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 comprises an optional "transferringAddress" that indicates who initiated the transfer. - callTransferUpdate - this optional unconfirmed operation is sent to User B and User C. It informs each other of all details about the transferred users that are known to the network. - 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 comprises 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 [9]. SIP also has the concept of replacing a dialog by another one [12], and [13] provides a mechanism so that information about the initiator of the refer request is sent to the third party. The informational [17] gives examples on how to support call transfers thanks to these SIP extensions. 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. 8.1.2 SIP side The interworking functions rely on SIP mechanisms and are therefore scoped by them. 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 Rey et al. Expires - July 2004 [Page 8] Internet-Draft qsig2sip-transfer-00 February 2004 routable, or will use other future mechanisms that allow global routing, - it is RECOMMENDED that the gateway and the SIP User Agents have and apply security policies regarding mutual interactions and exchange of information. The required implementations for these assumptions are defined in the SIP documents, and are therefore out of scope of this document. 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 informational "basic transfer" described in [17]. The QSIG Call transfer is also very similar to the informational "attended transfer" described in [17]. 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 two gateways are used, 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. 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 Rey et al. Expires - July 2004 [Page 9] Internet-Draft qsig2sip-transfer-00 February 2004 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 the transfer takes place in the PISN, updating the display (name, address, and dialog state of the new remote party) of the SIP User Agents is needed. An existing dialog between a gateway and a SIP User Agent could be "refreshed" thanks to a SIP INVITE transaction or thanks to a SIP UPDATE transaction. Unfortunately, there is no clearly defined mechanism in SIP to update the display of the SIP User Agents with these transactions.If the situation is clarified, this document will be updated to take it into account. The present solution is based on the gateway sending an INVITE with new dialog identifiers and a Replaces header field that matches the 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 in alerting state. 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 - July 2004 [Page 10] Internet-Draft qsig2sip-transfer-00 February 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 a PISN number can be derived from the Refer-to URI, 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 - July 2004 [Page 11] Internet-Draft qsig2sip-transfer-00 February 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. The interworking of call transfer before answer is an open issue. 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 [17] cannot happen until User C answers the call. [17] suggests that a fallback to "unattended transfer" is 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 [18]. 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 - July 2004 [Page 12] Internet-Draft qsig2sip-transfer-00 February 2004 The identity of the remote party must be derived as described in section 9.1 and 9.2 of [11]. 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 identity information field in the INVITE request SHALL be derived from the redirectionNumber of the callTransferComplete invoke APDU. The INVITE request SHALL use [12] to indicate which dialog is replaced. The INVITE request SHOULD use [13] to indicate the identity of the Referrer and copy the URI of the PISN party of the replaced dialog into the Referred-By header field. 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 failed at that stage. +---------+ 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 OPEN ISSUE. If the existing dialog is not confirmed (because the call is not answered yet), the INVITE request can be rejected because the Replaces header field does not match. Instead, the gateway MAY cancel the existing dialog and send a SIP INVITE request as above, except that it does not contain a Replaces header. Rey et al. Expires - July 2004 [Page 13] Internet-Draft qsig2sip-transfer-00 February 2004 If the URI of the identity information field in the INVITE request cannot be derived from the QSIG number in the callTransferComplete invoke APDU, the gateway SHALL take no action. NOTE. If a SIP mechanism that describes how to update identity information in an existing dialog is defined later, this document will be updated to take it into account. 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 [9]. 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 the awaitConnect boolean value in the invoke APDU is TRUE. - 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 - July 2004 [Page 14] Internet-Draft qsig2sip-transfer-00 February 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 [11]. 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 [11]. Rey et al. Expires - July 2004 [Page 15] Internet-Draft qsig2sip-transfer-00 February 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 (cf. 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 Refer-To URI can be derived, 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 SHALL derive the rerouteingNumber from the URI in the Refer-To header field and SHOULD derive the transferredAddress from the identity of the local PISN user in the existing dialog. Rey et al. Expires - July 2004 [Page 16] Internet-Draft qsig2sip-transfer-00 February 2004 On receipt of a QSIG FACILITY message that comprises a ssctInitiate return result APDU, the gateway SHALL send a SIP NOTIFY request as described in [9]. 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 comprises a ssctInitiate return error APDU, the gateway SHALL send a SIP INVITE message as described in [9] and in [12]. The gateway SHALL then comply to [9] and in [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". 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 representing the called party transported in the responses to the INVITE request, or from the URI in the Refer-To header field if no Rey et al. Expires - July 2004 [Page 17] Internet-Draft qsig2sip-transfer-00 February 2004 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 transferror and transferree 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 compare the Refer-To URI with the local Contact URI of its internal list of SIP dialogs. If there is no match, the gateway SHALL act as described in section 8.4.1.3. If there is a match, 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 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 Rey et al. Expires - July 2004 [Page 18] Internet-Draft qsig2sip-transfer-00 February 2004 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 MAY then release the two SIP dialogs. The gateway SHALL then act as a transit PINX as defined in [3]. +---------+ 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) Rey et al. Expires - July 2004 [Page 19] Internet-Draft qsig2sip-transfer-00 February 2004 8.4.1.3 Non-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 in the Refer-To URI, the gateway SHALL compare the Refer-To URI with the local Contact URI of its internal list of SIP dialogs. If there is a match 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) If the Refer-To URI does not match any local Contact URI, the gateway SHALL accept the REFER request and send a SIP INVITE message as described in [9] and in [12]. The gateway SHALL then comply to [9] and in [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 Rey et al. Expires - July 2004 [Page 20] Internet-Draft qsig2sip-transfer-00 February 2004 callTransferActive invoke APDU from identity information representing the SIP 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. 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 transferror and transferree is active again. +---------+ 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 but has a Referred-by header, the gateway SHALL send an QSIG SETUP message as described in [11]. If the INVITE request comprises 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]. Rey et al. Expires - July 2004 [Page 21] Internet-Draft qsig2sip-transfer-00 February 2004 +---------+ 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) 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 [11]. +---------+ 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. Rey et al. Expires - July 2004 [Page 22] Internet-Draft qsig2sip-transfer-00 February 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 - July 2004 [Page 23] Internet-Draft qsig2sip-transfer-00 February 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 - July 2004 [Page 24] Internet-Draft qsig2sip-transfer-00 February 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 - July 2004 [Page 25] Internet-Draft qsig2sip-transfer-00 February 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 : | (D2-1)BYE |:.......................:..........: |<-------------| | | | (D2-1)200 OK | | | |------------->| | | Figure 17: Example of Call transfer by join where User A and User B are SIP participants. Rey et al. Expires - July 2004 [Page 26] Internet-Draft qsig2sip-transfer-00 February 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 - July 2004 [Page 27] Internet-Draft qsig2sip-transfer-00 February 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 - July 2004 [Page 28] Internet-Draft qsig2sip-transfer-00 February 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-5)200 OK |: Dialog D2 |Call Reference CR2| : |------------->|<============>|<================>| : | (D1-4)BYE |: ...........: |------------->|: : 8.4.2.1 : | (D1-4)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 [11] 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 - July 2004 [Page 29] Internet-Draft qsig2sip-transfer-00 February 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 disclosed for privacy reasons, the gateway SHALL not derive the transferredAddress, transferringAddress and redirectionNumber of the QSIG invoke APDUs from the SIP header fields, except if the trust model applies. It SHALL indicate that the numbers are not available due to screening. If the trust model applies and the Privacy header defined in [14] 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, except if the trust model of applies. If the trust model applies, the information MAY be disclosed in conjunction with the Privacy header defined in [14]. Normative References [1] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation protocol", RFC 3261, June 2002. [2] International Standard ISO/IEC 11572 "Private Integrated Services - Circuit-mode Bearer Services - Inter-Exchange Signalling Procedures and Protocol" (also published by ECMA as Standard ECMA-143). [3] International Standard ISO/IEC 11582 "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). [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] International Standard ISO/IEC 13865 "QSIG - Specification, functional model and information flows - Call transfer supplementary services" (also published by ECMA as Standard ECMA-177) [6] International Standard ISO/IEC 13869 "QSIG - Inter-Exchange Signalling Protocol for the Support of Call Transfer Supplementary Services" (also published by ECMA as Standard ECMA-178) Rey et al. Expires - July 2004 [Page 30] Internet-Draft qsig2sip-transfer-00 February 2004 [7] International Standard ISO/IEC 19459 "QSIG - Specification, Functional Model and Information Flows - Single Step Call Transfer Supplementary Service" (also published by ECMA as Standard ECMA-299) [8] International Standard ISO/IEC 19460 "QSIG - Inter-Exchange Signalling Protocol - Single Step Call Transfer Supplementary Service" (also published by ECMA as Standard ECMA-300) [9] R. Sparks, "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [10] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, September 2002. [11] F. Derks, J. Elwell, P. Mourot, O. Rousseau, "Interworking between SIP and QSIG", draft-ietf-sipping-qsig2sip-04 (work in progress) [12] R. Mahy, B. Biggs, R. Dean, " The Session Inititation Protocol (SIP) "Replaces" Header", draft-ietf-sip-replaces-04 (work in progress) [13] R. Sparks, " The SIP Referred-By Mechanism", draft-ietf-sip- referredby-03 (work in progress) [14] J. Peterson, "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323 [15] C. Jennings, J. Peterson, M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325 [16] J. Rosenberg, "The Session Initiation Protocol UPDATE Method", RFC 3311. Informative References [17] R. Sparks, A. Johnston, "Session Initiation Protocol Call Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in progress) [18] ECMA Technical Report ECMA-TR/86, "Corporate Telecommunication Networks - User Identification in a SIP/QSIG Environment" Rey et al. Expires - July 2004 [Page 31] Internet-Draft qsig2sip-transfer-00 February 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@col.bsf.alcatel.fr John Elwell Siemens Communications Technology Drive Beeston Nottingham, UK, NG9 1LA email: john.elwell@siemens.com Rey et al. Expires - July 2004 [Page 32] Internet-Draft qsig2sip-transfer-00 February 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Rey et al. Expires - July 2004 [Page 33]