SIPPING WG R. Sparks Internet-Draft dynamicsoft Expires: April 21, 2005 A. Johnston MCI D. Petrie Pingtel Corp. October 21, 2004 Session Initiation Protocol Call Control - Transfer draft-ietf-sipping-cc-transfer-03 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. 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. This Internet-Draft will expire on April 21, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document describes providing Call Transfer capabilities in the Session Initiation Protocol (SIP). SIP extensions such as REFER and Replaces are used to provide a number of transfer services including blind transfer, consultative transfer, and attended transfer. This Sparks, et al. Expires April 21, 2005 [Page 1] Internet-Draft SIP CC Transfer October 2004 work is part of the SIP multiparty call control framework. Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Actors and Roles . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Using REFER to achieve Call Transfer . . . . . . . . . . . . . 4 5. Basic Transfer . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1 Successful Transfer . . . . . . . . . . . . . . . . . . . 6 5.2 Transfer without a GRUU . . . . . . . . . . . . . . . . . 10 5.3 Failed Transfer . . . . . . . . . . . . . . . . . . . . . 13 5.3.1 Target Busy . . . . . . . . . . . . . . . . . . . . . 13 5.3.2 Transfer Target does not answer . . . . . . . . . . . 14 6. Transfer with Consultation Hold . . . . . . . . . . . . . . . 15 6.1 Exposing transfer target . . . . . . . . . . . . . . . . . 15 6.2 Protecting transfer target . . . . . . . . . . . . . . . . 16 6.3 Attended Transfer . . . . . . . . . . . . . . . . . . . . 20 6.4 Recovery when one party does not support REFER . . . . . . 24 6.5 Attended Transfer when Contact URI is not a GRUU . . . . . 25 6.6 Semi-Attended Transfer . . . . . . . . . . . . . . . . . . 32 6.7 Attended Transfer Fallback to Basic Transfer . . . . . . . 36 7. Transfer with Referred-By . . . . . . . . . . . . . . . . . . 38 8. Transfer as an Ad-Hoc Conference . . . . . . . . . . . . . . . 44 9. Transfer with multiple parties . . . . . . . . . . . . . . . . 47 10. Gateway Transfer Issues . . . . . . . . . . . . . . . . . . 49 10.1 Coerce Gateway Hairpins to the Same Gateway . . . . . . . 49 10.2 Consultative Turned Blind Gateway Glare . . . . . . . . . 50 11. Changes from draft-sipping-cc-transfer-02 . . . . . . . . . 50 12. Changes from draft-sipping-cc-transfer-01 . . . . . . . . . 50 13. Changes from draft-sipping-cc-transfer-00 . . . . . . . . . 50 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 51 15. Security Considerations . . . . . . . . . . . . . . . . . . 51 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 51 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 17.1 Normative References . . . . . . . . . . . . . . . . . . . . 51 17.2 Informative References . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 52 Intellectual Property and Copyright Statements . . . . . . . . 54 Sparks, et al. Expires April 21, 2005 [Page 2] Internet-Draft SIP CC Transfer October 2004 1. Overview This document describes providing Call Transfer capabilities and requirements in SIP [1]. This work is part of the Multiparty Call Control Framework [6]. The mechanisms discussed here are most closely related to traditional basic and consultation hold transfers. This document details the use of REFER method [2] and Replaces [3] header field to achieve call transfer. A user agent that fully supports the transfer mechanisms described in this document MUST support REFER[2] and Replaces[3] in addition to RFC 3261 [1]. A user agent SHOULD support GRUU[5]. 2. Actors and Roles There are three actors in a given transfer event, each playing one of the following roles: Transferee - the party being transferred to the Transfer Target. Transferor - the party initiating the transfer Transfer Target - the new party being introduced into a call with the Transferee. The following roles are used to describe transfer requirements and scenarios: Originator - wishes to place a call to the Recipient. This actor is the source of the first INVITE in a session, to either a Facilitator or a Screener. Facilitator - receives a call or out-of-band request from the Originator, establishes a call to the Recipient through the Screener, and connects the Originator to the Recipient. Screener - receives a call ultimately intended for the Recipient and transfers the calling party to the Recipient if appropriate. Recipient - the party the Originator is ultimately connected to. Sparks, et al. Expires April 21, 2005 [Page 3] Internet-Draft SIP CC Transfer October 2004 3. Requirements 1. Any party in a SIP session MUST be able to transfer any other party in that session at any point in that session. 2. The Transferor and the Transferee MUST NOT be removed from a session as part of a transfer transaction. At first glance, requirement 2 may seem to indicate that the user experience in a transfer must be significantly different from what a current PBX or Centrex user expects. As the call-flows in this document show, this is not the case. A client MAY preserve the current experience. In fact, without this requirement, some forms of the current experience (ringback on transfer failure for instance) will be lost. 3. The Transferor MUST know whether or not the transfer was successful. 4. The Transferee MUST be able to replace an existing dialog with a new dialog. 5. The Transferor and Transferee SHOULD indicate their support for the primitives required to achieve transfer. 6. The Transferor SHOULD provide the Transfer Target and Transferee with information about the nature and progress of the transfer operation being attempted. To meet this requirement, the transfer operation can be modeled as an ad-hoc conference between three parties, as discussed in Section 8. 4. Using REFER to achieve Call Transfer A REFER [2] can be issued by the Transferor to cause the Transferee to issue an INVITE to the Transfer-Target. Note that a successful REFER transaction does not terminate the session between the Transferor and the Transferee. If those parties wish to terminate their session, they must do so with a subsequent BYE request. The media negotiated between the transferee and the transfer target is not affected by the media that had been negotiated between the transferor and the transferee. In particular, the INVITE issued by the Transferee will have the same SDP body it would have if he Transferee had initiated that INVITE on its own. Further, the disposition of the media streams between the Transferor and the Transferee is not altered by the REFER method. Sparks, et al. Expires April 21, 2005 [Page 4] Internet-Draft SIP CC Transfer October 2004 Agents may alter a session's media through additional signaling. For example, they may make use of the SIP hold re-INVITE [1] or conferencing extensions described in the conferencing framework [8]. To perform the transfer, the transferor and transferee could reuse an existing dialog established by an INVITE to send the REFER. This would result in a single dialog shared by two uses - an invite usage and a subscription usage. The call flows for this are shown in detail in Section 5.2. However, the approach described in this document is to avoid dialog reuse. The issues and difficulties associated with dialog reuse are described in [11]. Prior to the development of GRUUs and the use of grid parameters, the reasons to reuse the existing dialog included: 1. There was no way to ensure that a REFER on a new dialog would reach the particular endpoint involved in a transfer. Many factors, including details of implementations and changes in proxy routing between an INVITE and a REFER could cause the REFER to be sent to the wrong place. Sending the REFER down the existing dialog ensured it got to the endpoint we were already talking to. 2. It was unclear how to associate an existing invite usage with a REFER arriving on a new dialog, where it was completely obvious what the association was when the REFER came on the invite usage's dialog. 3. There were concerns with authorizing out-of-dialog REFERs. The authorization policy for REFER in most implementations piggybacks on the authorization policy for INVITE (which is, in most cases, based simply on "I placed or answered this call"). GRUUs [5] have been defined specifically to address problem 1. Problem 2 can be addressed using a GRUU's grid parameter. In the immediate term, this solution to problem 2 allows the existing REFER authorization policy to be reused. As a result, if the Transferee is using a GRUU, the REFER SHOULD be sent in a new dialog. If the nature of the Contact URI is not known, the REFER should be sent inside the existing dialog. This is because there is no current way for an out of dialog REFER to be associated with a particular dialog, unless a GRUU is present. In most of the following examples, the Transferor is in the atlanta.example.com domain, the Transferee is in the biloxi.example.com, and the Transfer Target is in the chicago.example.com domain. Sparks, et al. Expires April 21, 2005 [Page 5] Internet-Draft SIP CC Transfer October 2004 5. Basic Transfer Basic Transfer consists of the Transferor providing the Transfer Target's contact to the Transferee. The Transferee attempts to establish a session using that contact and reports the results of that attempt to the Transferor. The signaling relationship between the Transferor and Transferee is not terminated, so the call is recoverable if the Transfer Target cannot be reached. Note that the Transfer Target's contact information has been exposed to the Transferee. The provided contact can be used to make new calls in the future. The participants in a basic transfer should indicate support for the REFER and NOTIFY methods in Allow header fields in INVITE, 200 OK to INVITE, and OPTIONS messages. The diagrams below show the first line of each message. The first column of the figure shows the Call-ID used in that particular message. In these diagrams, media is managed through re-INVITE holds, but other mechanisms (mixing multiple media streams at the UA or using the conferencing extensions for example) are valid. Selected message details are shown labeled as message F1, F2, etc. Each of the flows below shows the dialog between the Transferor and the Transferee remaining connected (on hold) during the REFER process. While this provides the greatest flexibility for recovery from failure, it is not necessary. If the Transferor's agent does not wish to participate in the remainder of the REFER process and has no intention of assisting with recovery from transfer failure, it could emit a BYE to the Transferee as soon as the REFER transaction completes. This flow is sometimes known as "unattended transfer" or "blind transfer". Figure 1 shows transfer when the Transferee utilizes a GRUU and indicates this to the Transferor. As a result, the Transferor sends the REFER outside the INVITE dialog. The Transferee is able to match this REFER to the existing dialog using the grid parameter in the Request-URI. Note that if the Transferee uses the same grid across multiple unrelated dialogs, then some other explicit dialog identifier will need to be carried in the REFER in order for this to work. 5.1 Successful Transfer Sparks, et al. Expires April 21, 2005 [Page 6] Internet-Draft SIP CC Transfer October 2004 Transferor Transferee Transfer | | Target | INVITE F1 | | Call-ID:1 |<-------------------| | | 200 OK F2 | | Call-ID:1 |------------------->| | | ACK | | Call-ID:1 |<-------------------| | | INVITE (hold) | | Call-ID:1 |------------------->| | | 200 OK | | Call-ID:1 |<-------------------| | | ACK | | Call-ID:1 |------------------->| | | REFER F3 | | Call-ID:2 |------------------->| | | 202 Accepted | | Call-ID:2 |<-------------------| | | NOTIFY (100 Trying) F4 | Call-ID:2 |<-------------------| | | 200 OK | | Call-ID:2 |------------------->| | | | INVITE F5 | Call-ID:3 | |------------------->| | | 200 OK | Call-ID:3 | |<-------------------| | | ACK | Call-ID:3 | |------------------->| | NOTIFY (200 OK) F6| | Call-ID:2 |<-------------------| | | 200 OK | | Call-ID:2 |------------------->| | | BYE | | Call-ID:1 |------------------->| | | 200 OK | | Call-ID:1 |<-------------------| | | | BYE | Call-ID:3 | |<-------------------| | | 200 OK | Call-ID:3 | |------------------->| Figure 1. Basic Transfer Call Flow. F1 INVITE Transferee -> Transferor INVITE sips:transferor@atlanta.example.com SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 Sparks, et al. Expires April 21, 2005 [Page 7] Internet-Draft SIP CC Transfer October 2004 Max-Forwards: 70 To: From: ;tag=7553452 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Contact: Content-Type: application/sdp Content-Length: ... F2 200 OK Transferor -> Transferee SIP/2.0 200 OK Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 To: ;tag=31kdl4i3k From: ;tag=7553452 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Contact: Content-Type: application/sdp Content-Length: ... F3 REFER Transferor -> Transferee REFER sips:3k3k3ld812adkjw@biloxi.example.com;grid=3413kj2ha SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKna9 Max-Forwards: 70 To: From: ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 REFER Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: gruu, replaces Refer-To: Contact: Content-Length: 0 F4 NOTIFY Transferee -> Transferor NOTIFY sips:4889445d8kjtk3@atlanta.example.com;grid=723jd2d SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 Max-Forwards: 70 Sparks, et al. Expires April 21, 2005 [Page 8] Internet-Draft SIP CC Transfer October 2004 To: ;tag=1928301774 From: ;tag=a6c85cf Call-ID: a84b4c76e66710 CSeq: 73 NOTIFY Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Event: refer Subscription-State: active;expires=60 Content-Type: message/sipfrag Content-Length: ... SIP/2.0 100 Trying F5 INVITE Transferee -> Transfer Target INVITE sips:transfertarget@chicago.example.com SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas41234 Max-Forwards: 70 To: From: ;tag=j3kso3iqhq Call-ID: 90422f3sd23m4g56832034 CSeq: 521 REFER Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Contact: Content-Type: application/sdp Content-Length: ... F6 NOTIFY Transferee -> Transferor NOTIFY sips:4889445d8kjtk3@atlanta.example.com;grid=723jd2d SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 Max-Forwards: 70 To: ;tag=1928301774 From: ;tag=a6c85cf Call-ID: a84b4c76e66710 CSeq: 74 NOTIFY Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Event: refer Subscription-State: terminated;reason=noresource Content-Type: message/sipfrag Content-Length: ... Sparks, et al. Expires April 21, 2005 [Page 9] Internet-Draft SIP CC Transfer October 2004 SIP/2.0 200 OK 5.2 Transfer without a GRUU In this scenario, the Transferee does not support GRUU, as a result, the REFER is sent inside the INVITE dialog. Transferor Transferee Transfer | | Target | INVITE F1 | | Call-ID:1 |<-------------------| | | 200 OK F2 | | Call-ID:1 |------------------->| | | ACK | | Call-ID:1 |<-------------------| | | INVITE (hold) | | Call-ID:1 |------------------->| | | 200 OK | | Call-ID:1 |<-------------------| | | ACK | | Call-ID:1 |------------------->| | | REFER F3 | | Call-ID:1 |------------------->| | | 202 Accepted | | Call-ID:1 |<-------------------| | | NOTIFY (100 Trying) F4 | Call-ID:1 |<-------------------| | | 200 OK | | Call-ID:1 |------------------->| | | | INVITE F5 | Call-ID:2 | |------------------->| | | 200 OK | Call-ID:2 | |<-------------------| | | ACK | Call-ID:2 | |------------------->| | NOTIFY (200 OK) F6| | Call-ID:1 |<-------------------| | | 200 OK | | Call-ID:1 |------------------->| | | BYE | | Call-ID:1 |------------------->| | | 200 OK | | Call-ID:1 |<-------------------| | | | BYE | Call-ID:2 | |<-------------------| | | 200 OK | Sparks, et al. Expires April 21, 2005 [Page 10] Internet-Draft SIP CC Transfer October 2004 Call-ID:2 | |------------------->| Figure 2. Transfer without a GRUU. F1 INVITE Transferee -> Transferor INVITE sips:transferor@atlanta.example.com SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 Max-Forwards: 70 To: From: ;tag=7553452 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Contact: Content-Type: application/sdp Content-Length: ... F2 200 OK Transferor -> Transferee SIP/2.0 200 OK Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 To: ;tag=31kdl4i3k From: ;tag=7553452 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: gruu, replaces Contact: Content-Type: application/sdp Content-Length: ... F3 REFER Transferor -> Transferee REFER sips:transferee@192.0.2.4 SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKna9 Max-Forwards: 70 To: ;tag=7553452 From: ;tag=31kdl4i3k Call-ID: 090459243588173445 CSeq: 314159 REFER Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Refer-To: Sparks, et al. Expires April 21, 2005 [Page 11] Internet-Draft SIP CC Transfer October 2004 Contact: Content-Length: 0 F4 NOTIFY Transferee -> Transferor NOTIFY sips:4889445d8kjtk3@atlanta.example.com;grid=723jd2d SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 Max-Forwards: 70 To: ;tag=31kdl4i3k From: ;tag=7553452 Call-ID: 090459243588173445 CSeq: 29888 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Event: refer Subscription-State: active;expires=60 Content-Type: message/sipfrag Content-Length: ... SIP/2.0 100 Trying F5 INVITE Transferee -> Transfer Target INVITE sips:transfertarget@chicago.example.com SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas41234 Max-Forwards: 70 To: From: ;tag=j3kso3iqhq Call-ID: 90422f3sd23m4g56832034 CSeq: 521 REFER Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Contact: Content-Type: application/sdp Content-Length: ... F6 NOTIFY Transferee -> Transferor NOTIFY sips:4889445d8kjtk3@atlanta.example.com;grid=723jd2d SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 Max-Forwards: 70 To: ;tag=31kdl4i3k From: ;tag=7553452 Call-ID: 090459243588173445 CSeq: 29889 INVITE Sparks, et al. Expires April 21, 2005 [Page 12] Internet-Draft SIP CC Transfer October 2004 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Event: refer Subscription-State: terminated;reason=noresource Content-Type: message/sipfrag Content-Length: ... SIP/2.0 200 OK 5.3 Failed Transfer This section shows examples of failed transfer attempts. After the transfer failure occurs, the Transferor takes the Transferee off hold and resumes the session. 5.3.1 Target Busy Transferor Transferee Transfer | | Target | | | | INVITE | | Call-ID:1 |<-------------------| | | 200 OK | | Call-ID:1 |------------------->| | | ACK | | Call-ID:1 |<-------------------| | | INVITE (hold) | | Call-ID:1 |------------------->| | | 200 OK | | Call-ID:1 |<-------------------| | | ACK | | Call-ID:1 |------------------->| | | REFER | | Call-ID:2 |------------------->| | | 202 Accepted | | Call-ID:2 |<-------------------| | | NOTIFY (100 Trying)| | Call-ID:2 |<-------------------| | | 200 OK | | Call-ID:2 |------------------->| | | | INVITE | Call-ID:3 | |------------------->| | | 486 Busy Here | Call-ID:3 | |<-------------------| | | ACK | Sparks, et al. Expires April 21, 2005 [Page 13] Internet-Draft SIP CC Transfer October 2004 Call-ID:3 | |------------------->| | NOTIFY (503 Service Unavailable) | | or NOTIFY (486 Busy Here) | Call-ID:2 |<-------------------| | | 200 OK | | Call-ID:2 |------------------->| | | INVITE (unhold) | | Call-ID:1 |------------------->| | | 200 OK | | Call-ID:1 |<-------------------| | | ACK | | Call-ID:1 |------------------->| | | BYE | | Call-ID:1 |------------------->| | | 200 OK | | Call-ID:1 |<-------------------| | Figure 3. Failed Transfer - Target Busy 5.3.2 Transfer Target does not answer Transferor Transferee Transfer | | Target | INVITE | | Call-ID:1 |<-------------------| | | 200 OK | | Call-ID:1 |------------------->| | | ACK | | Call-ID:1 |<-------------------| | | INVITE (hold) | | Call-ID:1 |------------------->| | | 200 OK | | Call-ID:1 |<-------------------| | | ACK | | Call-ID:1 |------------------->| | | REFER | | Call-ID:2 |------------------->| | | 202 Accepted | | Call-ID:2 |<-------------------| | | NOTIFY (100 Trying)| | Call-ID:2 |<-------------------| | | 200 OK | | Call-ID:2 |------------------->| | | | INVITE | Call-ID:3 | |------------------->| | | 180 Ringing | Call-ID:3 | |<-------------------| Sparks, et al. Expires April 21, 2005 [Page 14] Internet-Draft SIP CC Transfer October 2004 | (Transferee gets tired of waiting) | | CANCEL | Call-ID:3 | |------------------->| | | 200 OK (CANCEL) | Call-ID:3 | |<-------------------| | | 487 Request Cancelled (INVITE) Call-ID:3 | |<-------------------| | | ACK | Call-ID:3 | |------------------->| | NOTIFY (487 Request Cancelled) | Call-ID:2 |<-------------------| | | 200 OK | | Call-ID:2 |------------------->| | | INVITE (unhold) | | Call-ID:1 |------------------->| | | 200 OK | | Call-ID:1 |<-------------------| | | ACK | | Call-ID:1 |------------------->| | | BYE | | Call-ID:1 |------------------->| | | 200 OK | | Call-ID:1 |<-------------------| | Figure 4. Failed Transfer - Target Does Not Answer. 6. Transfer with Consultation Hold Transfer with Consultation Hold involves a session between the transferor and the transfer target before the transfer actually takes place. This is implemented with SIP Hold and Transfer as described above. A nice feature is for the transferor to let the target know that the session relates to an intended transfer. Since many UAs render the display name in the From header field to the user, a consultation INVITE could contain a string such as "Incoming consultation from Transferor with intent to transfer Transferee", where the display names of the transferor and transferee are included in the string. 6.1 Exposing transfer target The transferor places the transferee on hold, establishes a call with the transfer target to alert them to the impending transfer, terminates the connection with the transfer target, then proceeds with transfer as above. This variation can be used to provide an experience similar to that expected by current PBX and Centrex users. Sparks, et al. Expires April 21, 2005 [Page 15] Internet-Draft SIP CC Transfer October 2004 To (hopefully) improve clarity, non-REFER transactions have been collapsed into one indicator with the arrow showing the direction of the request. Transferor Transferee Transfer | | Target | | | Call-ID:1 | INVITE/200 OK/ACK | | |<-------------------| | Call-ID:1 | INVITE (hold)/200 OK/ACK | |------------------->| | Call-ID:2 | INVITE/200 OK/ACK | | |---------------------------------------->| Call-ID:2 | BYE/200 OK | | |---------------------------------------->| Call-ID:3 | REFER | | |------------------->| | Call-ID:3 | 202 Accepted | | |<-------------------| | Call-ID:3 | NOTIFY (100 Trying)| | |<-------------------| | Call-ID:3 | 200 OK | | |------------------->| | Call-ID:4 | | INVITE/200 OK/ACK | | |------------------->| Call-ID:3 | NOTIFY (200 OK) | | |<-------------------| | Call-ID:3 | 200 OK | | |------------------->| | Call-ID:1 | BYE/200 OK | | |------------------->| | Call-ID:4 | | BYE/200 OK | | |<-------------------| Figure 5. Transfer with Consultation Hold - Exposing Transfer Target. 6.2 Protecting transfer target The transferor places the transferee on hold, establishes a call with the transfer target and then reverses their roles, transferring the original transfer target to the original transferee. This has the advantage of hiding information about the original transfer target from the original transferee. On the other hand, the Transferee's experience is different that in current systems. The Transferee is effectively "called back" by the Transfer Target. Sparks, et al. Expires April 21, 2005 [Page 16] Internet-Draft SIP CC Transfer October 2004 One of the problems with this simplest implementation of a target protecting transfer is that the transferee is receiving a new call from the transfer-target. Unless the transferee's agent has a reliable way to associate this new call with the call it already has with the transferor, it will have to alert the new call on another appearance. If this, or some other call-waiting-like UI were not available, the transferee might be stuck returning a Busy-Here to the transfer target, effectively preventing the transfer. There are many ways that that correlation could be provided. The dialog parameters could be provided directly as header parameters in the Refer-To: URI for example. The Replaces mechanism [3] uses this approach and solves this problem nicely. For the flow below, dialog1 means dialog identifier 1, and consists of the parameters of the Replaces header for dialog 1. In [3] this is the Call-ID, To-tag and From-tag. Note that the transferee's agent emits a BYE to the transferor's agent as an immediate consequence of processing the Replaces header. The Transferor knows that both the Transferee and the Transfer Target support the Replaces header from the Supported: replaces header contained in the 200 OK responses from both. Sparks, et al. Expires April 21, 2005 [Page 17] Internet-Draft SIP CC Transfer October 2004 Transferor Transferee Transfer | | Target | | | dialog1 | INVITE/200 OK/ACK F1 F2 | |<-------------------| | dialog1 | INVITE (hold)/200 OK/ACK | |------------------->| | dialog2 | INVITE/200 OK/ACK F3 F4 | |---------------------------------------->| dialog2 | INVITE (hold)/200 OK/ACK | |---------------------------------------->| dialog3 | REFER (Refer-To:sips:Transferee?Replaces=dialog1) F5 |---------------------------------------->| dialog3 | 202 Accepted | | |<----------------------------------------| dialog3 | NOTIFY (100 Trying)| | |<----------------------------------------| dialog3 | | 200 OK | |---------------------------------------->| dialog4 | INVITE (Replaces:dialog1)/200 OK/ACK F6 | |<-------------------| dialog1 | BYE/200 OK | | |<-------------------| | dialog3 | NOTIFY (200 OK) | | |<----------------------------------------| dialog3 | | 200 OK | |---------------------------------------->| dialog2 | BYE/200 OK | | |---------------------------------------->| | | (transferee and target converse) dialog4 | | BYE/200 OK | | |------------------->| Figure 6. Transfer Protecting Transfer Target. F1 INVITE Transferee -> Transferor INVITE sips:transferor@atlanta.example.com SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 Max-Forwards: 70 To: From: ;tag=7553452 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Contact: Sparks, et al. Expires April 21, 2005 [Page 18] Internet-Draft SIP CC Transfer October 2004 Content-Type: application/sdp Content-Length: ... F2 200 OK Transferor -> Transferee SIP/2.0 200 OK Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 To: ;tag=31431 From: ;tag=7553452 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Contact: Content-Type: application/sdp Content-Length: ... F3 INVITE Transferor -> Transfer Target INVITE sips:transfertarget@chicago.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432 Max-Forwards: 70 To: From: ;tag=763231 Call-ID: 592435881734450904 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: gruu, replaces Require: replaces Contact: Content-Type: application/sdp Content-Length: ... F4 200 OK Transfer Target -> Transferee SIP/2.0 200 OK Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432 ;received=192.0.2.1 To: ;tag=9m2n3wq From: ;tag=763231 Call-ID: 592435881734450904 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Contact: Sparks, et al. Expires April 21, 2005 [Page 19] Internet-Draft SIP CC Transfer October 2004 Content-Type: application/sdp Content-Length: ... F5 REFER Transferor -> Transfer Target REFER sips:482n4z24kdg@chicago.example.com;grid=8594958 SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 Max-Forwards: 70 To: From: ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 REFER Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: gruu, replaces Refer-To: Contact: Content-Length: 0 F6 INVITE Transfer Target -> Transferee INVITE sips:3k3k3ld812adkjw@biloxi.example.com;grid=3413kj2ha SIP/2.0 Via: SIP/2.0/TLS client.chicago.example.com;branch=z9hG4bKnaslu84 Max-Forwards: 70 To: From: ;tag=341234 Call-ID: kmzwdle3dl3d08 CSeq: 41 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: gruu, replaces Contact: Replaces: 090459243588173445;to-tag=31431;from-tag=7553452 Content-Type: application/sdp Content-Length: ... 6.3 Attended Transfer The transferor places the transferee on hold, establishes a call with the transfer target to alert them to the impending transfer, places the target on hold, then proceeds with transfer using an escaped Replaces header field in the Refer-To header. This is another common service expected by current PBX and Centrex users. Sparks, et al. Expires April 21, 2005 [Page 20] Internet-Draft SIP CC Transfer October 2004 If the Contact URI of the Transfer Target is a GRUU (Globally Routable User Agent URI) GRUU [5] then the Transferee SHOULD use that URI as the Refer-To URI. If the Contact URI is not known to be a GRUU (Supported: gruu is not present), then the Address of Record (AOR) of the Transfer Target should be used. That is, the same URI that the Transferee used to establish the session with the Transfer Target should be used. In case the triggered INVITE is routed to a different User Agent than the Transfer Target, the Require: replaces header field should be used in the triggered INVITE. (This is to prevent an incorrect User Agent which does not support Replaces from ignoring the Replaces and answering the INVITE without a dialog match.) It is possible that proxy/service routing may prevent the triggered INVITE from reaching the same User Agent. If this occurs, the triggered invite will fail with a timout, 403, 404, etc error. The Transferee MAY then retry the transfer with the Refer-To URI set to the Contact URI. Transferor Transferee Transfer | | Target | | | dialog1 | INVITE/200 OK/ACK F1 F2 | |<-------------------| | dialog1 | INVITE (hold)/200 OK/ACK | |------------------->| | dialog2 | INVITE/200 OK/ACK F3 F4 | |---------------------------------------->| dialog2 | INVITE (hold)/200 OK/ACK | |---------------------------------------->| dialog3 | REFER (Refer-To:sips:TransferTarget?Replaces=dialog2) F5 |------------------->| | dialog3 | 202 Accepted | | |<-------------------| | dialog3 | NOTIFY (100 Trying)| | |<-------------------| | dialog3 | 200 OK | | |------------------->| | dialog4 | INVITE (Replaces:dialog2)/200 OK/ACK F6 | |------------------->| dialog2 | BYE/200 OK | | |<----------------------------------------| dialog3 | NOTIFY (200 OK) | | |<-------------------| | dialog3 | 200 OK | | |------------------->| | dialog1 | BYE/200 OK | | |------------------->| | Sparks, et al. Expires April 21, 2005 [Page 21] Internet-Draft SIP CC Transfer October 2004 dialog4 | | BYE/200 OK | | |<-------------------| Figure 7. Attended Transfer Call Flow. F1 INVITE Transferee -> Transferor INVITE sips:transferor@atlanta.example.com SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 Max-Forwards: 70 To: From: ;tag=7553452 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Contact: Content-Type: application/sdp Content-Length: ... F2 200 OK Transferor -> Transferee SIP/2.0 200 OK Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 To: ;tag=31431 From: ;tag=7553452 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Contact: Content-Type: application/sdp Content-Length: ... F3 INVITE Transferor -> Transfer Target INVITE sips:transfertarget@chicago.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432 Max-Forwards: 70 To: From: ;tag=763231 Call-ID: 592435881734450904 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: gruu, replaces Sparks, et al. Expires April 21, 2005 [Page 22] Internet-Draft SIP CC Transfer October 2004 Require: replaces Contact: Content-Type: application/sdp Content-Length: ... F4 200 OK Transfer Target -> Transferee SIP/2.0 200 OK Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432 ;received=192.0.2.1 To: ;tag=9m2n3wq From: ;tag=763231 Call-ID: 592435881734450904 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Contact: Content-Type: application/sdp Content-Length: ... F5 REFER Transferor -> Transferee REFER sips:3k3k3ld812adkjw@biloxi.example.com;grid=3413kj2ha SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 Max-Forwards: 70 To: From: ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 REFER Refer-To: Contact: Content-Length: 0 F6 INVITE Transferee -> Transfer Target INVITE sips:482n4z24kdg@chicago.example.com;grid=8594958 SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnaslu82 Max-Forwards: 70 To: From: ;tag=954 Call-ID: kmzwdle3dl3d08 CSeq: 41 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: gruu, replaces Sparks, et al. Expires April 21, 2005 [Page 23] Internet-Draft SIP CC Transfer October 2004 Contact: Replaces: 592435881734450904;to-tag=9m2n3wq;from-tag=763231 Content-Type: application/sdp Content-Length: ... 6.4 Recovery when one party does not support REFER If protecting or exposing the transfer target is not a concern, it is possible to complete a transfer with consultation hold when only the transferor and one other party support REFER. Note that a 405 Method Not Allowed might be returned instead of the 501 Not Implemented response. Sparks, et al. Expires April 21, 2005 [Page 24] Internet-Draft SIP CC Transfer October 2004 Transferor Transferee Transfer | | Target | | | dialog1 | INVITE/200 OK/ACK | | |<-------------------| | dialog1 | INVITE (hold)/200 OK/ACK | |------------------->| | dialog2 | INVITE/200 OK/ACK | | |---------------------------------------->| dialog2 | INVITE (hold)/200 OK/ACK | |---------------------------------------->| dialog3 | REFER (Refer-To:sips:TransferTarget?Replaces=dialog2) |------------------->| | dialog3 | 501 Not Implemented | |<-------------------| | dialog4 | REFER (Refer-To:sips:Transferee?Replaces=dialog1) |---------------------------------------->| dialog4 | 202 Accepted | | |<----------------------------------------| dialog4 | NOTIFY (100 Trying)| | |<----------------------------------------| dialog4 | | 200 OK | |---------------------------------------->| dialog5 | | INVITE (Replaces:dialog1)/200 OK/ACK | |<-------------------| dialog4 | NOTIFY (200 OK) | | |<----------------------------------------| dialog4 | | 200 OK | |---------------------------------------->| dialog1 | BYE/200 OK | | |<-------------------| | dialog2 | BYE/200 OK | | |---------------------------------------->| dialog5 | | BYE/200 OK | | |------------------->| Figure 8. Recovery when one party does not support REFER. 6.5 Attended Transfer when Contact URI is not a GRUU It is a requirement of RFC3261 that a Contact URI be globally routable even outside the dialog. However, due to RFC2543 User Agents and some architectures (NAT/Firewall traversal, screening proxies, ALGs, etc.) this will not always be the case. Only if a Contact URI is a GRUU should a UA assume that the Contact URI will be routable. As a result, the method of Attended transfer shown in Figures 6, 7, and 8 should not be used unless the Contact URI is known to be a GRUU. Sparks, et al. Expires April 21, 2005 [Page 25] Internet-Draft SIP CC Transfer October 2004 Figure 9 shows such a scenario where the Transfer Target does not use a GRUU so the triggered INVITE is sent to the AOR of the Transfer Target. Transferor Transferee Screening Transfer | | Proxy Target | | | | dialog1 | INVITE/200 OK/ACK| | | |<-----------------| | | dialog1 | INVITE (hold)/200 OK/ACK | | |----------------->| | | dialog2 | INVITE/200 OK/ACK F1 F2 | | |--------------------------------|------------>| dialog2 | INVITE (hold)/200 OK/ACK | |--------------------------------|------------>| dialog1 | REFER (Refer-To:sips:TargetAOR?Replaces=dialog2&Require=replaces) F3 |----------------->| | | dialog1 | 202 Accepted | | | |<-----------------| | | dialog1 | NOTIFY (100 Trying) | | |<-----------------| | | dialog1 | 200 OK | | | |----------------->| | | dialog4 | INVITE (Replaces:dialog2, Require:replaces)/200 OK/ACK F6 | |------------>|------------>| dialog2 | BYE/200 OK | | | |<-------------------------------|<------------| dialog1 | NOTIFY (200 OK) F7 | | |<-----------------| | | dialog1 | 200 OK | | | |----------------->| | | dialog1 | BYE/200 OK | | | |----------------->| | | dialog3 | | | BYE/200 OK | | |<------------|-------------| Figure 9. Attended Transfer Call Flow with non-GRUU Contact URI F1 INVITE Transferor -> Transfer Target INVITE sips:transfertarget@chicago.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK76 Max-Forwards: 70 To: From: ;tag=763231 Call-ID: 090459243588173445 CSeq: 29887 INVITE Sparks, et al. Expires April 21, 2005 [Page 26] Internet-Draft SIP CC Transfer October 2004 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Contact: Content-Type: application/sdp Content-Length: ... F2 200 OK Transfer Target -> Transferee SIP/2.0 200 OK Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432 ;received=192.0.2.1 To: ;tag=9m2n3wq From: ;tag=763231 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Contact: Content-Type: application/sdp Content-Length: ... F3 REFER Transferor -> Transferee REFER sips:transferee@192.0.2.4 SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 Max-Forwards: 70 To: ;tag=a6c85cf From: ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314160 REFER Refer-To: Contact: Content-Length: 0 F4 INVITE Transferee -> Transfer Target INVITE sips:transfertarget@chicago.example.com SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnaslu82 Max-Forwards: 70 To: From: ;tag=954 Call-ID: 20482817324945934422930 CSeq: 42 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Sparks, et al. Expires April 21, 2005 [Page 27] Internet-Draft SIP CC Transfer October 2004 Supported: replaces Contact: Replaces: 090459243588173445;to-tag=9m2n3wq;from-tag=763231 Require: replaces Content-Type: application/sdp Content-Length: ... F5 NOTIFY Transferee -> Transferor NOTIFY sips:transferor@pc33.atlanta.com SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 Max-Forwards: 70 To: ;tag=1928301774 From: ;tag=a6c85cf Call-ID: a84b4c76e66710 CSeq: 76 NOTIFY Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Event: refer;id=98873867 Subscription-State: terminated;reason=noresource Content-Type: message/sipfrag Content-Length: ... SIP/2.0 200 OK Figure 10 shows a failure case in which the AOR URI fails to reach the transfer Target. As a result, the transfer is retried with the Contact URI which succeeds. Note that there is still no guarantee that the correct endpoint will be reached, and the result of this second REFER may also be a failure. In that case, the Transferor could fall back to unattended transfer or give up on the transfer entirely. Since two REFERs are sent within the dialog creating two distinct subscriptions, the Transferee uses the 'id' parameter in the Event header field to distinguish notifications for the two subscriptions. Transferor Transferee Screening Transfer | | Proxy Target | | | | dialog1 | INVITE/200 OK/ACK| | | |<-----------------| | | dialog1 | INVITE (hold)/200 OK/ACK | | |----------------->| | | dialog2 | INVITE/200 OK/ACK F1 F2 | | |--------------------------------|------------>| Sparks, et al. Expires April 21, 2005 [Page 28] Internet-Draft SIP CC Transfer October 2004 dialog2 | INVITE (hold)/200 OK/ACK | |--------------------------------|------------>| dialog1 | REFER (Refer-To:sips:TargetAOR?Replaces=dialog2&Require=replaces) F3 |----------------->| | | dialog1 | 202 Accepted | | | |<-----------------| | | dialog1 | NOTIFY (100 Trying) | | |<-----------------| | | dialog1 | 200 OK | | | |----------------->| | | dialog3 | INVITE (Replaces:dialog2,Require:replaces)/403/ACK | |------------>| | dialog1 | NOTIFY (403 Forbidden) F4 | | |<-----------------| | | dialog1 | 200 OK | | | |----------------->| | | dialog1 |REFER(Refer-To:sips:TargetContact?Replaces=dialog2) F5 |----------------->| | | dialog1 | 202 Accepted | | | |<-----------------| | | dialog1 | NOTIFY (100 Trying) | | |<-----------------| | | dialog1 | 200 OK | | | |----------------->| | | dialog4 | INVITE (Replaces:dialog2)/200 OK/ACK F6 | |------------>|------------>| dialog2 | BYE/200 OK | | | |<-------------------------------|<------------| dialog1 | NOTIFY (200 OK) F7 | | |<-----------------| | | dialog1 | 200 OK | | | |----------------->| | | dialog1 | BYE/200 OK | | | |----------------->| | | dialog3 | | | BYE/200 OK | | |<------------|-------------| Figure 10. Attended Transfer Call Flow with non-GRUU URI and AOR Failure F1 INVITE Transferor -> Transfer Target INVITE sips:transfertarget@chicago.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK76 Max-Forwards: 70 To: From: ;tag=763231 Sparks, et al. Expires April 21, 2005 [Page 29] Internet-Draft SIP CC Transfer October 2004 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Contact: Content-Type: application/sdp Content-Length: ... F2 200 OK Transfer Target -> Transferee SIP/2.0 200 OK Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432 ;received=192.0.2.1 To: ;tag=9m2n3wq From: ;tag=763231 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Contact: Content-Type: application/sdp Content-Length: ... F3 REFER Transferor -> Transferee REFER sips:transferee@192.0.2.4 SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 Max-Forwards: 70 To: ;tag=a6c85cf From: ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 REFER Refer-To: Contact: Content-Length: 0 F4 NOTIFY Transferee -> Transferor NOTIFY sips:transferor@pc33.atlanta.com SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 Max-Forwards: 70 To: ;tag=1928301774 From: ;tag=a6c85cf Call-ID: a84b4c76e66710 Sparks, et al. Expires April 21, 2005 [Page 30] Internet-Draft SIP CC Transfer October 2004 CSeq: 74 NOTIFY Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Event: refer;id=314159 Subscription-State: terminated;reason=noresource Content-Type: message/sipfrag Content-Length: ... SIP/2.0 403 Forbidden F5 REFER Transferor -> Transferee REFER sips:transferee@192.0.2.4 SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 Max-Forwards: 70 To: ;tag=a6c85cf From: ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314160 REFER Refer-To: Contact: Content-Length: 0 F6 INVITE Transferee -> Transfer Target INVITE sips:transfertarget@client.chicago.example.com SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnaslu82 Max-Forwards: 70 To: From: ;tag=954 Call-ID: 20482817324945934422930 CSeq: 42 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Contact: Replaces: 090459243588173445;to-tag=9m2n3wq;from-tag=763231 Content-Type: application/sdp Content-Length: ... F7 NOTIFY Transferee -> Transferor NOTIFY sips:transferor@pc33.atlanta.com SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 Max-Forwards: 70 Sparks, et al. Expires April 21, 2005 [Page 31] Internet-Draft SIP CC Transfer October 2004 To: ;tag=1928301774 From: ;tag=a6c85cf Call-ID: a84b4c76e66710 CSeq: 76 NOTIFY Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Event: refer;id=314160 Subscription-State: terminated;reason=noresource Content-Type: message/sipfrag Content-Length: ... SIP/2.0 200 OK To prevent this scenario from happening, the Transfer Target should obtain a GRUU and use it in the Contact header field, which will result in the call flow of Figure 7. 6.6 Semi-Attended Transfer In any of the consultation hold flows above, the Transferor may decide to terminate its attempt to contact the Transfer target before that session is established. Most frequently, that will be the end of the scenario, but in some circumstances, the transferor may wish to proceed with the transfer action. For example, the Transferor may wish to complete the transfer knowing that the transferee will end up eventually talking to the transfer-target's voice-mail service. Some PBX systems support this feature, sometimes called "semi-attended transfer", that is effectively a hybrid between a fully attended transfer and an unattended transfer. A call flow is shown in Figure 11. In this flow, the Transferor's User Agent continues the transfer as an attended transfer even after the Transferor hangs up. Note that media must be played to the Transfer Target upon answer - otherwise, the Target may hang up and the resulting transfer operation will fail. Transferor Transferee Transfer | | Target | | | dialog1 | INVITE/200 OK/ACK F1 F2 | |<-------------------| | dialog1 | INVITE (hold)/200 OK/ACK | |------------------->| | dialog2 | INVITE | | |---------------------------------------->| dialog2 | | 180 Ringing | |<----------------------------------------| | Transferor hangs up but wants transfer to continue Sparks, et al. Expires April 21, 2005 [Page 32] Internet-Draft SIP CC Transfer October 2004 | | | | User Agent continues transfer operation | | | | dialog2 | | 200 OK | |<----------------------------------------| dialog2 | ACK | | |---------------------------------------->| dialog2 | Media Played to keep Target from hanging up |========================================>| dialog3 | REFER (Refer-To:sips:TransferTarget?Replaces=dialog2) |------------------->| | dialog3 | 202 Accepted | | |<-------------------| | dialog3 | NOTIFY (100 Trying)| | |<-------------------| | dialog3 | 200 OK | | |------------------->| | dialog4 | INVITE (Replaces:dialog2)/200 OK/ACK | |------------------->| dialog2 | BYE/200 OK | | |<----------------------------------------| dialog3 | NOTIFY (200 OK) | | |<-------------------| | dialog3 | 200 OK | | |------------------->| | dialog1 | BYE/200 OK | | |------------------->| | dialog4 | | BYE/200 OK | | |<-------------------| Figure 11. Recommended Semi-Attended Transfer Call Flow. Two other possible semi-attended transfer call flows are shown in Figures 12 and 13. However, these call flows are NOT RECOMMENDED due to a race conditions. In both of these flows, when the Transferor hangs up, the User Agent attempts to revert to unattended transfer by sending a CANCEL to the Target. This can result in two race conditions. One is that the Target answers despite the CANCEL and the resulting unattended transfer fails. This race condition can be eliminated by the Transferor waiting to send the REFER until the 487 response from the Target is returned. Instead of a 487, a 200 OK may return indicating that the Target has answered the consultation call. In this, case the call flow in Figure 13 must be followed. In this flow, the Transferor must play some kind of media to the Target to prevent the Target from hanging up, or the Transfer will fail. That is, the human at the Transfer Target will hear silence from when they answer (message F1) until the transfer completes (F3 and they are talking to the Transferee unless some media is played (F2). Sparks, et al. Expires April 21, 2005 [Page 33] Internet-Draft SIP CC Transfer October 2004 The second race condition occurs in Figure 12 if the Transfer Target goes "off hook" after the CANCEL is received and the 487 returned. This may result in a 486 Busy Here response to the unattended transfer. The recommended call flow of Figure 11 does not utilize a CANCEL and does not suffer from these race conditions. Transferor Transferee Transfer | | Target | | | dialog1 | INVITE/200 OK/ACK | | |<-------------------| | dialog1 | INVITE (hold)/200 OK/ACK | |------------------->| | dialog2 | INVITE | |---------------------------------------->| dialog2 | 180 Ringing | |<----------------------------------------| | | | Transferor gives up waiting | | | dialog2 | CANCEL | |---------------------------------------->| dialog2 | 200 OK | |<----------------------------------------| dialog2 | 487 Request Terminated | |<----------------------------------------| dialog2 | ACK | |---------------------------------------->| dialog3 | REFER F3 | |------------------->| | dialog3 | 202 Accepted | | |<-------------------| | dialog3 | NOTIFY (100 Trying)| | |<-------------------| | dialog3 | 200 OK | | |------------------->| | dialog4 | INVITE/200 OK/ACK | | |------------------->| dialog3 | NOTIFY (200 OK) | | |<-------------------| | dialog3 | 200 OK | | |------------------->| | dialog1 | BYE/200 OK | | |------------------->| | dialog4 | | BYE/200 OK | | |<-------------------| Sparks, et al. Expires April 21, 2005 [Page 34] Internet-Draft SIP CC Transfer October 2004 Figure 12. Semi-Attended Transfer as Blind Transfer Call Flow. (Not Recommended) Transferor Transferee Transfer | | Target | | | dialog1 | INVITE/200 OK/ACK | | |<-------------------| | dialog1 | INVITE (hold)/200 OK/ACK | |------------------->| | dialog2 | INVITE | |---------------------------------------->| dialog2 | 180 Ringing | |<----------------------------------------| | | | Transferor gives up waiting but Target answers | | dialog2 | CANCEL | |---------------------------------------->| dialog2 | 200 OK (CANCEL) | |<----------------------------------------| dialog2 | 200 OK (INVITE) F1 | |<----------------------------------------| dialog2 | ACK | |---------------------------------------->| dialog2 | INVITE (hold)/200 OK/ACK | |---------------------------------------->| | Tones or media played avoid silence F2 |========================================>| dialog1 | REFER (Refer-To:sips:TransferTarget?Replaces=dialog2) |------------------->| | dialog1 | 202 Accepted | | |<-------------------| | dialog1 | NOTIFY (100 Trying)| | |<-------------------| | dialog1 | 200 OK | | |------------------->| | dialog3 | INVITE (Replaces:dialog2)/200 OK/ACK F3 | |------------------->| dialog2 | BYE/200 OK | | |<----------------------------------------| dialog1 | NOTIFY (200 OK) | | |<-------------------| | dialog1 | 200 OK | | |------------------->| | dialog1 | BYE/200 OK | | |------------------->| | dialog3 | | BYE/200 OK | Sparks, et al. Expires April 21, 2005 [Page 35] Internet-Draft SIP CC Transfer October 2004 | |<-------------------| Figure 13. Semi-Attended Transfer as Attended Transfer Call Flow. (Not Recommended) 6.7 Attended Transfer Fallback to Basic Transfer In this flow, an attempted attended transfer fails so the transferor falls back to basic transfer. The call flow in Figure 14 shows the use of Require:replaces in the INVITE sent by the Transferor to the Transfer Target in which the Transferor's intention at the time of sending the INVITE to the Transfer Target was known to be to complet an attended transfer. Since the Target does not support Replaces, the INVITE is rejected with a 420 Bad Extension response, and the Transferor switches from attended transfer to basic transfer immediately. Sparks, et al. Expires April 21, 2005 [Page 36] Internet-Draft SIP CC Transfer October 2004 Transferor Transferee Transfer | | Target | | | dialog1 | INVITE/200 OK/ACK | | |<-------------------| | dialog1 | OPTIONS/200 OK | | |------------------->| | dialog1 | INVITE (hold)/200 OK/ACK | |------------------->| | dialog2 | INVITE (Require:replaces) | |---------------------------------------->| dialog2 | 420 Bad Extension | |<----------------------------------------| dialog2 | ACK | |---------------------------------------->| dialog1 | REFER (Refer-To:sips:TransferTarget) | |------------------->| | dialog1 | 202 Accepted | | |<-------------------| | dialog1 | NOTIFY (100 Trying)| | |<-------------------| | dialog1 | 200 OK | | |------------------->| | dialog3 | | INVITE/200 OK/ACK | | |------------------->| dialog1 | NOTIFY (200 OK) | | |<-------------------| | dialog1 | 200 OK | | |------------------->| | dialog1 | BYE/200 OK | | |------------------->| | dialog3 | | BYE/200 OK | | |<-------------------| Figure 14. Attended Transfer Fallback to Basic Transfer using Require:replaces. Figure 13 shows the use of OPTIONS when the Transferee and Transfer Target do not explicitly indicate support for the REFER method and Replaces header fields in Allow and Supported header fields and the Transferor did not have the intention of performing an attended transfer when the INVITE to the Target was sent. In dialog1, the Transferor determines using OPTIONS that the Transferee does support REFER and Replaces. As a result, the Transferor begins the attended transfer by placing the Transferee on hold and calling the Transfer Target. Using an OPTIONS in dialog2, the Transferor determines that the Target does not support either REFER or Replaces, making attended transfer impossible. The Transferor then ends dialog2 by sending a Sparks, et al. Expires April 21, 2005 [Page 37] Internet-Draft SIP CC Transfer October 2004 BYE then sends a REFER to the Transferee using the AOR URI of the Transfer Target. Transferor Transferee Transfer | | Target | | | dialog1 | INVITE/200 OK/ACK | | |<-------------------| | dialog1 | OPTIONS/200 OK | | |------------------->| | dialog1 | INVITE (hold)/200 OK/ACK | |------------------->| | dialog2 | INVITE/200 OK/ACK | | |---------------------------------------->| dialog2 | OPTIONS/200 OK | | |---------------------------------------->| dialog2 | BYE/200 OK | | |---------------------------------------->| dialog3 | REFER (Refer-To:sips:TransferTarget) | |------------------->| | dialog3 | 202 Accepted | | |<-------------------| | dialog3 | NOTIFY (100 Trying)| | |<-------------------| | dialog3 | 200 OK | | |------------------->| | dialog4 | | INVITE/200 OK/ACK | | |------------------->| dialog3 | NOTIFY (200 OK) | | |<-------------------| | dialog3 | 200 OK | | |------------------->| | dialog1 | BYE/200 OK | | |------------------->| | dialog4 | | BYE/200 OK | | |<-------------------| Figure 14. Attended Transfer Fallback to Basic Transfer. 7. Transfer with Referred-By In the previous examples, the Transfer Target does not have definitive information about what party initiated the transfer, or, in some cases, even that transfer is taking place. The Referred-By mechanism [4] provides a way for the Transferor to provide the Transferee with a way to let the Transfer Target know what party initiated the transfer. Sparks, et al. Expires April 21, 2005 [Page 38] Internet-Draft SIP CC Transfer October 2004 The simplest and least secure approach just involves the inclusion of the Referred-By header field in the REFER which is then copied into the triggered INVITE. However, a more secure mechanism involving the Referred-By security token which is generated and signed by the Transferor and passed in a message body to the Transferee then to the Transfer Target. The call flow would be identical to Figure 7. However, the REFER and triggered INVITE messages for this flow showing the Referred-By mechanism are shown below. Note that the conventions used in the SIP Torture Test Messages [7] document are reused, specifically the and tags. F5 REFER Transferor -> Transferee REFER sips:3k3k3ld812adkjw@biloxi.example.com;grid=3413kj2ha SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK392039842 Max-Forwards: 70 To: From: ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314160 REFER Refer-To: Supported: gruu, replaces Referred-By: ;cid="20398823.2UWQFN309shb3@atlanta.example.com" Contact: Content-Type: multipart/mixed; boundary=unique-boundary-1 Content-Length: 3267 --unique-boundary-1 Content-ID: <20398823.2UWQFN309shb3@atlanta.example.com> Content-Length: 2961 Content-Type: multipart/signed; protocol="application/pkcs-7-signature"; micalg=sha1; boundary="----590F24D439B31E08745DEF0CD9397189" ------590F24D439B31E08745DEF0CD9397189 Content-Type: message/sipfrag Sparks, et al. Expires April 21, 2005 [Page 39] Internet-Draft SIP CC Transfer October 2004 Date: Thu, 18 Sep 2003 13:07:43 GMT Refer-To: Referred-By: ;cid="20398823.2UWQFN309shb3@atlanta.example.com" ------590F24D439B31E08745DEF0CD9397189 Content-Type: application/pkcs-7-signature; name="smime.p7s" Content-Transfer-Encoding: binary Content-Disposition: attachment; filename="smime.p7s" 3082088806092A86 4886F70D010702A082087930820875020101310B300906052B0E03021A050030 0B06092A864886F70D010701A082067A30820339308202A2A003020102020800 90008902240001300D06092A864886F70D01010505003070310B300906035504 0613025553311330110603550408130A43616C69666F726E69613111300F0603 550407130853616E4A6F7365310E300C060355040A1305736970697431293027 060355040B135369706974546573744365727469666963617465417574686F72 697479301E170D3033313032313134343332355A170D31333130313831343433 32355A3062310B3009060355040613025553311330110603550408130A43616C 69666F726E69613111300F0603550407130853616E4A6F7365310E300C060355 040A13057369706974311B30190603550403141273656E646572406578616D70 6C652E6F726730819F300D06092A864886F70D010101050003818D0030818902 818100CB8302060F12C8FA2D1786922CA173DCEB80BF1B1B8AF74A310C6975A5 56A7630FB6E044D9E994DCD49AFF7976C462D7A8E74ECBF98723AEBF2796EDDD 6263577C6C2B77DC7C300B533DEDB5FB8EB3827FD6FC9B37B9A0DE829F1B1081 D632A8AD9FB00A860928E88F87E0B979BA65294AC7D6D2D18A78C86B4FA73387 4E230203010001A381E93081E6301D0603551D1104163014811273656E646572 406578616D706C652E6F726730090603551D1304023000301D0603551D0E0416 041440FF1C0C1BB8684CA917839D70E97DF8DD5B60D130819A0603551D230481 9230818F80146B461714EA94762580546E1354DAA1E35414A1B6A174A4723070 310B3009060355040613025553311330110603550408130A43616C69666F726E 69613111300F0603550407130853616E4A6F7365310E300C060355040A130573 6970697431293027060355040B13536970697454657374436572746966696361 7465417574686F72697479820100300D06092A864886F70D0101050500038181 006FFE1A3B5CE807C3DD2CFDF6E9787F491C84DBF7DCD11DB2D6A8887D2FE3F2 2E9C6894994282E50AA0DFFE1CBD4EC2C20217831FC2AD360FF1C0DE1DE1E870 102CFA99EE504C7DC0D8752A63294AC748DDDEFADE55C6D051F1CD54CFE7C153 278962A53CEF61B875C1FD3C74E972242CBA0131B3B8C607BF95B378212CA9A7 5E30820339308202A2A00302010202080090008902240001300D06092A864886 F70D01010505003070310B300906035504061302555331133011060355040813 0A43616C69666F726E69613111300F0603550407130853616E4A6F7365310E30 0C060355040A1305736970697431293027060355040B13536970697454657374 4365727469666963617465417574686F72697479301E170D3033313032313134 343332355A170D3133313031383134343332355A3062310B3009060355040613 Sparks, et al. Expires April 21, 2005 [Page 40] Internet-Draft SIP CC Transfer October 2004 025553311330110603550408130A43616C69666F726E69613111300F06035504 07130853616E4A6F7365310E300C060355040A13057369706974311B30190603 550403141273656E646572406578616D706C652E6F726730819F300D06092A86 4886F70D010101050003818D0030818902818100CB8302060F12C8FA2D178692 2CA173DCEB80BF1B1B8AF74A310C6975A556A7630FB6E044D9E994DCD49AFF79 76C462D7A8E74ECBF98723AEBF2796EDDD6263577C6C2B77DC7C300B533DEDB5 FB8EB3827FD6FC9B37B9A0DE829F1B1081D632A8AD9FB00A860928E88F87E0B9 79BA65294AC7D6D2D18A78C86B4FA733874E230203010001A381E93081E6301D 0603551D1104163014811273656E646572406578616D706C652E6F7267300906 03551D1304023000301D0603551D0E0416041440FF1C0C1BB8684CA917839D70 E97DF8DD5B60D130819A0603551D2304819230818F80146B461714EA94762580 546E1354DAA1E35414A1B6A174A4723070310B30090603550406130255533113 30110603550408130A43616C69666F726E69613111300F060355040713085361 6E4A6F7365310E300C060355040A1305736970697431293027060355040B1353 69706974546573744365727469666963617465417574686F7269747982010030 0D06092A864886F70D0101050500038181006FFE1A3B5CE807C3DD2CFDF6E978 7F491C84DBF7DCD11DB2D6A8887D2FE3F22E9C6894994282E50AA0DFFE1CBD4E C2C20217831FC2AD360FF1C0DE1DE1E870102CFA99EE504C7DC0D8752A63294A C748DDDEFADE55C6D051F1CD54CFE7C153278962A53CEF61B875C1FD3C74E972 242CBA0131B3B8C607BF95B378212CA9A75E318201D6308201D2020101307C30 70310B3009060355040613025553311330110603550408130A43616C69666F72 6E69613111300F0603550407130853616E4A6F7365310E300C060355040A1305 736970697431293027060355040B135369706974546573744365727469666963 617465417574686F7269747902080090008902240001300906052B0E03021A05 00A081B1301806092A864886F70D010903310B06092A864886F70D010701301C 06092A864886F70D010905310F170D3034303132363139313831345A30230609 2A864886F70D01090431160414408CCA5772916A968204FD24CC24EDAEAD3943 95305206092A864886F70D01090F31453043300A06082A864886F70D0307300E 06082A864886F70D030202020080300D06082A864886F70D0302020140300706 052B0E030207300D06082A864886F70D0302020128300D06092A864886F70D01 010105000481807795329BB23B8BB9F72526AB9CC22D93B9A37A2E69A0171D3C C417DD394F0A5FD4F8B082733CD9F2E26F6991031F7FF2EAD31640718502FB4C 822771211E6228C793DA4DBBA2159227C221030FE9088CD659578EB862568087 8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B428388966 79089AAD95767F ------590F24D439B31E08745DEF0CD9397189-- --unique_boundary-1 F6 INVITE Transferee -> Transfer Target INVITE sips:482n4z24kdg@chicago.example.com;grid=8594958 SIP/2.0 Via: SIP/2.0/TLS referee.example;branch=z9hG4bKffe209934aac To: Sparks, et al. Expires April 21, 2005 [Page 41] Internet-Draft SIP CC Transfer October 2004 From: ;tag=2909034023 Call-ID: fe9023940-a3465@referee.example CSeq: 889823409 INVITE Max-Forwards: 70 Contact: Referred-By: ;cid="20398823.2UWQFN309shb3@atlanta.example.com" Replaces:090459243588173445;to-tag=9m2n3wq;from- tag=76323 Require: replaces Supported: gruu, replaces Content-Type: multipart/mixed; boundary=my-boundary-9 Content-Length: 3432 --my-boundary-9 Content-Type: application/sdp Content-Length: 156 v=0 o=referee 2890844526 2890844526 IN IP4 referee.example s=Session SDP c=IN IP4 referee.example t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 --my-boundary-9 Content-Length: 2961 Content-Type: multipart/signed; protocol="application/pkcs-7-signature"; micalg=sha1; boundary="----590F24D439B31E08745DEF0CD9397189" ------590F24D439B31E08745DEF0CD9397189 Content-Type: message/sipfrag Date: Thu, 18 Sep 2003 13:07:43 GMT Refer-To: Referred-By: ;cid="20398823.2UWQFN309shb3@atlanta.example.com" ------590F24D439B31E08745DEF0CD9397189 Sparks, et al. Expires April 21, 2005 [Page 42] Internet-Draft SIP CC Transfer October 2004 Content-Type: application/pkcs-7-signature; name="smime.p7s" Content-Transfer-Encoding: binary Content-Disposition: attachment; filename="smime.p7s" 3082088806092A86 4886F70D010702A082087930820875020101310B300906052B0E03021A050030 0B06092A864886F70D010701A082067A30820339308202A2A003020102020800 90008902240001300D06092A864886F70D01010505003070310B300906035504 0613025553311330110603550408130A43616C69666F726E69613111300F0603 550407130853616E4A6F7365310E300C060355040A1305736970697431293027 060355040B135369706974546573744365727469666963617465417574686F72 697479301E170D3033313032313134343332355A170D31333130313831343433 32355A3062310B3009060355040613025553311330110603550408130A43616C 69666F726E69613111300F0603550407130853616E4A6F7365310E300C060355 040A13057369706974311B30190603550403141273656E646572406578616D70 6C652E6F726730819F300D06092A864886F70D010101050003818D0030818902 818100CB8302060F12C8FA2D1786922CA173DCEB80BF1B1B8AF74A310C6975A5 56A7630FB6E044D9E994DCD49AFF7976C462D7A8E74ECBF98723AEBF2796EDDD 6263577C6C2B77DC7C300B533DEDB5FB8EB3827FD6FC9B37B9A0DE829F1B1081 D632A8AD9FB00A860928E88F87E0B979BA65294AC7D6D2D18A78C86B4FA73387 4E230203010001A381E93081E6301D0603551D1104163014811273656E646572 406578616D706C652E6F726730090603551D1304023000301D0603551D0E0416 041440FF1C0C1BB8684CA917839D70E97DF8DD5B60D130819A0603551D230481 9230818F80146B461714EA94762580546E1354DAA1E35414A1B6A174A4723070 310B3009060355040613025553311330110603550408130A43616C69666F726E 69613111300F0603550407130853616E4A6F7365310E300C060355040A130573 6970697431293027060355040B13536970697454657374436572746966696361 7465417574686F72697479820100300D06092A864886F70D0101050500038181 006FFE1A3B5CE807C3DD2CFDF6E9787F491C84DBF7DCD11DB2D6A8887D2FE3F2 2E9C6894994282E50AA0DFFE1CBD4EC2C20217831FC2AD360FF1C0DE1DE1E870 102CFA99EE504C7DC0D8752A63294AC748DDDEFADE55C6D051F1CD54CFE7C153 278962A53CEF61B875C1FD3C74E972242CBA0131B3B8C607BF95B378212CA9A7 5E30820339308202A2A00302010202080090008902240001300D06092A864886 F70D01010505003070310B300906035504061302555331133011060355040813 0A43616C69666F726E69613111300F0603550407130853616E4A6F7365310E30 0C060355040A1305736970697431293027060355040B13536970697454657374 4365727469666963617465417574686F72697479301E170D3033313032313134 343332355A170D3133313031383134343332355A3062310B3009060355040613 025553311330110603550408130A43616C69666F726E69613111300F06035504 07130853616E4A6F7365310E300C060355040A13057369706974311B30190603 550403141273656E646572406578616D706C652E6F726730819F300D06092A86 4886F70D010101050003818D0030818902818100CB8302060F12C8FA2D178692 2CA173DCEB80BF1B1B8AF74A310C6975A556A7630FB6E044D9E994DCD49AFF79 76C462D7A8E74ECBF98723AEBF2796EDDD6263577C6C2B77DC7C300B533DEDB5 FB8EB3827FD6FC9B37B9A0DE829F1B1081D632A8AD9FB00A860928E88F87E0B9 79BA65294AC7D6D2D18A78C86B4FA733874E230203010001A381E93081E6301D 0603551D1104163014811273656E646572406578616D706C652E6F7267300906 Sparks, et al. Expires April 21, 2005 [Page 43] Internet-Draft SIP CC Transfer October 2004 03551D1304023000301D0603551D0E0416041440FF1C0C1BB8684CA917839D70 E97DF8DD5B60D130819A0603551D2304819230818F80146B461714EA94762580 546E1354DAA1E35414A1B6A174A4723070310B30090603550406130255533113 30110603550408130A43616C69666F726E69613111300F060355040713085361 6E4A6F7365310E300C060355040A1305736970697431293027060355040B1353 69706974546573744365727469666963617465417574686F7269747982010030 0D06092A864886F70D0101050500038181006FFE1A3B5CE807C3DD2CFDF6E978 7F491C84DBF7DCD11DB2D6A8887D2FE3F22E9C6894994282E50AA0DFFE1CBD4E C2C20217831FC2AD360FF1C0DE1DE1E870102CFA99EE504C7DC0D8752A63294A C748DDDEFADE55C6D051F1CD54CFE7C153278962A53CEF61B875C1FD3C74E972 242CBA0131B3B8C607BF95B378212CA9A75E318201D6308201D2020101307C30 70310B3009060355040613025553311330110603550408130A43616C69666F72 6E69613111300F0603550407130853616E4A6F7365310E300C060355040A1305 736970697431293027060355040B135369706974546573744365727469666963 617465417574686F7269747902080090008902240001300906052B0E03021A05 00A081B1301806092A864886F70D010903310B06092A864886F70D010701301C 06092A864886F70D010905310F170D3034303132363139313831345A30230609 2A864886F70D01090431160414408CCA5772916A968204FD24CC24EDAEAD3943 95305206092A864886F70D01090F31453043300A06082A864886F70D0307300E 06082A864886F70D030202020080300D06082A864886F70D0302020140300706 052B0E030207300D06082A864886F70D0302020128300D06092A864886F70D01 010105000481807795329BB23B8BB9F72526AB9CC22D93B9A37A2E69A0171D3C C417DD394F0A5FD4F8B082733CD9F2E26F6991031F7FF2EAD31640718502FB4C 822771211E6228C793DA4DBBA2159227C221030FE9088CD659578EB862568087 8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B428388966 79089AAD95767F ------590F24D439B31E08745DEF0CD9397189-- --my-boundary-9-- 8. Transfer as an Ad-Hoc Conference In this flow, Bob does an attended transfer of Alice to Carol. In order to keep both Alice and Carol fully informed of the nature and state of the transfer operation, Bob acts as a focus[9] and hosts an ad-hoc conference involving Alice, Bob, and Carol. Alice and Carol subscribe to the conference package[10] of Bob's focus, which allows them to know the exact status of the operation. After the transfer operation is complete, Bob deletes the conference. This call flow meets requirement 6 of Section 3. NOTIFY messages related to the refer package are indicated as NOTIFY (refer), while NOTIFYs related to the Conference Info package are indicated as NOTIFY (Conf-Info). Sparks, et al. Expires April 21, 2005 [Page 44] Internet-Draft SIP CC Transfer October 2004 Note that any type of semi-attended transfer in which media mixing or relaying could be implemented using this model. In addition to simply mixing, the focus could introduce additional media signals such as simulated ring tone or on hold announcements to improve the user experience. Alice Bob Carol | | | | INVITE | | |------------------->| | | 180 Ringing | | |<-------------------| | | 200 OK | | |<-------------------| | | ACK | | |------------------->| | | RTP | | |<==================>| | | | | | Bob places Alice on hold and begins acting like a focus | | | | INVITE (hold) Contact:Conf-ID;isfocus | |<-------------------| | | 200 OK | | |------------------->| | | ACK | | |<-------------------| | | | | | Alice subscribes to the conference package | | | | SUBSCRIBE sip:Conf-ID | |------------------->| | | 200 OK | | |<-------------------| | | NOTIFY (Conf-Info) | | |<-------------------| | | 200 OK | | |------------------->| | | | | | Bob begins consultation operation | | | | | INVITE Require:replaces Contact:Conf-ID;isfocus | |------------------->| | | 180 Ringing | | |<-------------------| | | 200 OK | | |<-------------------| | | ACK | Sparks, et al. Expires April 21, 2005 [Page 45] Internet-Draft SIP CC Transfer October 2004 | |------------------->| | | RTP | | |<==================>| | | | Carol subscribes to the conference package - learns Bob is on hold | | | | |SUBSCRIBE sip:Conf-ID | |<-------------------| | | 200 OK | | |------------------->| | | NOTIFY (Conf-Info) | | |------------------->| | | 200 OK | | |<-------------------| | | | | Alice learns that Bob is talking to Carol | | | | NOTIFY (Conf-Info) | | |<-------------------| | | 200 OK | | |------------------->| | | | INVITE (hold) | | |------------------->| | | 200 OK | | |<-------------------| | | ACK | | |------------------->| | | | | Alice learns that Carol is now on hold | | | | | NOTIFY (Conf-Info) | | |<-------------------| | | 200 OK | | |------------------->| | | | | | Bob begins transfer operation | | | | | REFER Refer-To: Carol | |<-------------------| | | 202 Accepted | | |------------------->| | | NOTIFY (Refer) | | |------------------->| | | 200 OK | | |<-------------------| | | INVITE Replaces:B-C Contact:Alice | |---------------------------------------->| | 200 OK | Sparks, et al. Expires April 21, 2005 [Page 46] Internet-Draft SIP CC Transfer October 2004 |<----------------------------------------| | ACK | |---------------------------------------->| | RTP | |<=======================================>| | | BYE | | |<-------------------| | | 200 OK | | |------------------->| | NOTIFY (Refer) | | |------------------->| | | 200 OK | | |<-------------------| | | | | | Bob terminates the ad-hoc conference | | | | | BYE | | |<-------------------| | | 200 OK | | |------------------->| | | | NOTIFY (Conf-Info) | | |------------------->| | | 200 OK | | |<-------------------| | NOTIFY (Conf-Info) | | |<-------------------| | | 200 OK | | |------------------->| | Figure 15. Attended Transfer as an Ad-Hoc Conference. 9. Transfer with multiple parties In this example the Originator places call to the Facilitator who reaches the Recipient through the Screener. The Recipient's contact information is exposed to the Facilitator and the Originator. This example is provided for clarification of the semantics of the REFER method only and should not be used as the design of an implementation. Originator Facilitator Screener Recipient Call-ID | | | | 1 |INVITE/200 OK/ACK | |"Get Fred for me!" |----------->| | | "Right away!" 1 |INVITE (hold)/200 OK/ACK | | |<-----------| | | 2 | |INVITE/200 OK/ACK |"I have a call Sparks, et al. Expires April 21, 2005 [Page 47] Internet-Draft SIP CC Transfer October 2004 | |----------->| |from Mary for Fred" 2 | |INVITE (hold)/200 OK/ACK "Hold please" | |<-----------| | 3 | | |INVITE/200 OK/ACK | | |--------->|"You have a call | | | |from Mary" | | | | "Put her through" 3 | | |INVITE (hold)/200 OK/ACK | | |--------->| 4 | |REFER | | | |<-----------| | 4 | |202 Accepted| | | |----------->| | 4 | |NOTIFY (100 Trying) | | |----------->| | 4 | |200 OK | | | |<-----------| | 5 | |INVITE/200 OK/ACK | | |---------------------->|"This is Fred" 4 | |NOTIFY (200 OK) | "Please hold for | |----------->| | Mary" 4 | |200 OK | | | |<-----------| | 2 | |BYE/200 OK | | | |<-----------| | 3 | | |BYE/200 OK| | | |--------->| 5 | |INVITE (hold)/200 OK/ACK | |---------------------->| 6 |REFER | | | |<-----------| | | 6 |202 Accepted| | | |----------->| | | 6 |NOTIFY (100 Trying) | | |----------->| | | 6 |200 OK | | | |<-----------| | | 7 |INVITE/200 OK/ACK | | |----------------------------------->| "Hey Fred" 6 |NOTIFY (200 OK) | | "Hello Mary" |----------->| | | 6 |200 OK | | | |<-----------| | | 1 |BYE/200 OK | | | |<-----------| | | 5 | |BYE/200 OK | | | |---------------------->| 7 |BYE/200 OK | | | Sparks, et al. Expires April 21, 2005 [Page 48] Internet-Draft SIP CC Transfer October 2004 |<-----------------------------------| "See you later" Figure 16. Transfer with Multiple Parties Example. 10. Gateway Transfer Issues A gateway in SIP acts as a User Agent. As a result, the entire preceding discussion and call flows apply equally well to gateways as native SIP endpoints. However, there are some gateway specific issues that are documented in this section. While this discussion focuses on the common cases involving PSTN gateways, similar situations exist for other gateways, such as H.323/SIP gateways. 10.1 Coerce Gateway Hairpins to the Same Gateway To illustrate how a hairpin situation can occur in transfer, consider this example. The original call dialog is setup with the transferee residing on the PSTN side of a SIP gateway. The transferor is a SIP phone purely in the IP space. The transfer target is on the PSTN side of a SIP gateway as well. After completing the transfer, (regardless of consultative or blind) the transferee is in a call with the transfer target (both on the PSTN side of a gateway). It is often desirable to remove the gateway(s) out of the loop. This is likely to only be possible if both legs of the target call are on the same gateway. With both legs on the same gateway, it may be able to invoke the analogous transfer on the PSTN side. Then the target call would not involve the gateway. So the problem is how to give the proxy enough information so that it knows to route the call to the same gateway. With a simple single call that hairpins, the incoming and outgoing leg have the same dialog. The proxy should have enough information to optimize the routing. In the consultative transfer scenario, it is desirable to coerce the consultative INVITE out the same gateway as the original call to be transferred. However there is no way to relate the consultation with the original call. In the consultative case the target call INVITE includes the Replaces header which contains dialog information that can be used to relate it to the consultation. However there is no information that relates the target call to the original. In the blind transfer scenario, it is desirable to coerce the target call onto the same gateway as the original call. However the same problem exists in that the target dialog cannot be related to the original dialog. In either transfer scenario, it may be desirable to push the transfer Sparks, et al. Expires April 21, 2005 [Page 49] Internet-Draft SIP CC Transfer October 2004 operation onto the non-SIP side of the gateway. Presumably this is not possible unless all of the legs go out the same gateway. If the gateway supports more than one truck group, it might also be necessary to get all of the legs on the same trunk group in order to perform the transfer on the non-SIP side of the gateway. Solutions to these gateway specific issues may involve new extensions to SIP in the future. 10.2 Consultative Turned Blind Gateway Glare In the consultative transfer case turned blind, there is a glare-like problem. The transferor initiates the consultation INVITE, the user gets impatient and hangs up, transitioning this to a blind transfer. The transfer target on the gateway (connected through a PSTN switch to a single line or dumb analog phone) rings. The user answers the phone just after the CANCEL is received by the transfer target. The REFER and INVITE for the target call are sent. The transferee attempts to setup the call on the PSTN side, but gets either a busy or lands in the users voicemail as the user has the handset in hand and off hook. This is another example of a race condition that this call flow can cause. The recommended behavior is to use the approach described in Section 6.6. 11. Changes from draft-sipping-cc-transfer-02 o Changed to REFERs sent out of dialog if recipient provides a GRUU. o Changed to Refer-To set to GRUU if present, AOR if not, and Contact if AOR fails. o Included transfer as an Ad-hoc conference call flow. o Included semi -attended transfer discussion. Included one recommended flow and two not recommended flows. o Included issues from Transfer Issues I-D. o Added section on gateway transfer issues. 12. Changes from draft-sipping-cc-transfer-01 o Added example S/MIME messages in Referred-By section. o Added reference and discussion of GRUUs 13. Changes from draft-sipping-cc-transfer-00 o Added section on use of Referred-By header. o Added selected message details. o Added flow for attended transfer with non-globally routable Contact URI. Sparks, et al. Expires April 21, 2005 [Page 50] Internet-Draft SIP CC Transfer October 2004 o Added flow for attended transfer fallback to unattended transfer. o Added Security Considerations Section. 14. IANA Considerations None. 15. Security Considerations The call transfer flows shown in this document are implemented using the REFER and Replaces call control primitives in SIP. As such, the attacks and security approaches are those detailed in the REFER and Replaces documents which are briefly summarized in the following paragraphs. This document addresses the issue of protecting the Address of Record URI of a transfer target in Sections 6.1 and 6.2. Any REFER request must be appropriately authenticated and authorized using standard SIP mechanisms or calls may be hijacked. A user agent may use local policy or human intervention in deciding whether or not to accept a REFER. In generating NOTIFY responses based on the outcome of the triggered request, care should be taken in constructing the message/sipfrag body to ensure that no private information is leaked. An INVITE containing a Replaces header field should only be accepted if it has been properly authenticated and authorized using standard SIP mechanisms, and the requestor is authorized to perform dialog replacement. 16. Acknowledgments This draft is a collaborative product of the SIP working group. Thanks to Rohan Mahy for his input on the use of Replaces in transfer. 17. References 17.1 Normative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [3] Mahy, R., Biggs, B. and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. Sparks, et al. Expires April 21, 2005 [Page 51] Internet-Draft SIP CC Transfer October 2004 [4] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004. [5] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", draft-ietf-sip-gruu-02 (work in progress), July 2004. 17.2 Informative References [6] Mahy, R., "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", draft-ietf-sipping-cc-framework-03 (work in progress), October 2003. [7] Sparks, R., "Session Initiation Protocol Torture Test Messages", draft-ietf-sipping-torture-tests-04 (work in progress), July 2004. [8] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", draft-ietf-sipping-conferencing-framework-03 (work in progress), October 2004. [9] Johnston, A. and O. Levin, "Session Initiation Protocol Call Control - Conferencing for User Agents", draft-ietf-sipping-cc-conferencing-04 (work in progress), July 2004. [10] Rosenberg, J. and H. Schulzrinne, "A Session Initiation Protocol (SIP) Event Package for Conference State", draft-ietf-sipping-conference-package-05 (work in progress), July 2004. [11] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", draft-sparks-sipping-dialogusage-00 (work in progress), July 2004. Authors' Addresses Robert J. Sparks dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 EMail: rsparks@dynamicsoft.com Sparks, et al. Expires April 21, 2005 [Page 52] Internet-Draft SIP CC Transfer October 2004 Alan Johnston MCI 100 South 4th Street St. Louis, MO 63102 EMail: alan.johnston@mci.com Daniel Petrie Pingtel Corp. 400 W. Cummings Park Suite 2200 Woburn, MA 01801 EMail: dpetrie@pingtel.com Sparks, et al. Expires April 21, 2005 [Page 53] Internet-Draft SIP CC Transfer 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 procedures with respect to rights in RFC 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Sparks, et al. Expires April 21, 2005 [Page 54]