view Side-By-Side changes
SIPPING WGNetwork Working Group R. SparksInternet-Draft Estacado Systems Intended status: BCPRequest for Comments: 5589 Tekelec BCP: 149 A. Johnston, Ed.Expires: September 4, 2009Category: Best Current Practice Avaya D. Petrie SIPez LLCMarch 3,June 2009 Session Initiation Protocol (SIP) Call Control - Transferdraft-ietf-sipping-cc-transfer-12Status ofthisThis Memo ThisInternet-Draftdocument specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document issubmittedsubject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents infull conformance witheffect on theprovisionsdate ofBCP 78publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights andBCP 79.restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 4, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the Sparks, et al. Expires September 4, 2009 [Page 1] Internet-Draft SIP CC Transfer March 2009 document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.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 work is part of the SIP multiparty call control framework. Sparks, et al.Expires September 4, 2009Best Current Practice [Page2] Internet-Draft1] RFC 5589 SIP CC TransferMarchJune 2009 Table of Contents 1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 4........................................................3 2. Actors and Roles. . . . . . . . . . . . . . . . . . . . . . . 4................................................3 3. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . 5.....................................................4 4. Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 5....................................................4 5. Using REFER toachieveAchieve Call Transfer. . . . . . . . . . . . . 6............................5 6. Basic Transfer. . . . . . . . . . . . . . . . . . . . . . . . 7..................................................6 6.1. Successful Transfer. . . . . . . . . . . . . . . . . . . 8........................................8 6.2. Transfer with Dialog Reuse. . . . . . . . . . . . . . . . 12................................11 6.3. Failed Transfer. . . . . . . . . . . . . . . . . . . . . 16...........................................15 6.3.1. Target Busy. . . . . . . . . . . . . . . . . . . . . 16........................................16 6.3.2. Transfer Targetdoes not answer . . . . . . . . . . . 18Does Not Answer ....................17 7. Transfer with Consultation Hold. . . . . . . . . . . . . . . 19................................18 7.1. Exposingtransfer target . . . . . . . . . . . . . . . . . 19Transfer Target ..................................18 7.2. Protectingtransfer target . . . . . . . . . . . . . . . . 20Transfer Target ................................19 7.3. Attended Transfer. . . . . . . . . . . . . . . . . . . . 25.........................................24 7.4. Recoverywhen one party does not supportWhen One Party Does Not Support REFER. . . . . . 28............28 7.5. Attendedtransfer whenTransfer When Contact URIis not knownIs Not Known torouteRoute to aunique user agent. . . . . . . . . . . . . . . 29User Agent .....................................29 7.6. Semi-Attended Transfer. . . . . . . . . . . . . . . . . . 36....................................37 7.7. Attended Transfer Fallback to Basic Transfer. . . . . . . 41..............42 8. Transfer with Referred-By. . . . . . . . . . . . . . . . . . 43......................................45 9. Transfer as anAd-HocAd Hoc Conference. . . . . . . . . . . . . . . 47...............................49 10. Transfer withmultiple parties . . . . . . . . . . . . . . . . 50Multiple Parties ................................52 11. Gateway Transfer Issues. . . . . . . . . . . . . . . . . . . 52 11.1. Coerce Gateway Hairpins to the Same Gateway . . . . . . . 52 11.2. Consultative Turned Blind Gateway Glare . . . . . . . . . 53 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 13. Security Considerations . . . . . . . . . . . . . . . . . . . 53 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54 15........................................54 11.1. Coerce Gateway Hairpins to the Same Gateway ..............54 11.2. Consultative Turned Blind Gateway Glare ..................55 12. Security Considerations .......................................55 13. Acknowledgments ...............................................56 14. References. . . . . . . . . . . . . . . . . . . . . . . . . . 54 15.1.....................................................56 14.1. Normative References. . . . . . . . . . . . . . . . . . . 54 15.2......................................56 14.2. Informative References. . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55...................................57 Sparks, et al.Expires September 4, 2009Best Current Practice [Page3] Internet-Draft2] RFC 5589 SIP CC TransferMarchJune 2009 1. Overview This document describes providing Call Transfer capabilities and requirements in SIP [RFC3261]. This work is part of theMultiparty Call Control Framework [I-D.ietf-sipping-cc-framework].multiparty call control framework [CC-FRMWRK]. The mechanisms discussed here are most closely related totraditional basictraditional, basic, and consultation hold transfers. This document details the use of the REFER method [RFC3515] and Replaces [RFC3891] header field to achieve call transfer. Auser agentUser Agent (UA) that fully supports the transfer mechanisms described in this document supportsREFER[RFC3515]REFER [RFC3515] andReplaces[RFC3891]Replaces [RFC3891] in addition to RFC 3261 [RFC3261]. Auser agentUser Agent should use a Contact URIwhichthat meets the requirements in Section 8.1.1.8 of RFC 3261. A compliantuser agentUser Agent supports the Target-Dialog header field [RFC4538]. 2. Actors and Roles There are three actors in a given transfer event, each playing one of the following roles:Transferee -Transferee: the party being transferred to the Transfer Target.Transferor -Transferor: the party initiating thetransfertransfer. TransferTarget -Target: the new party being introduced into a call with the Transferee. The following roles are used to describe transfer requirements and scenarios:Sparks, et al. Expires September 4, 2009 [Page 4] Internet-Draft SIP CC Transfer March 2009 Originator -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 -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. Typically, a Facilitator acts on behalf of the Originator.Screener -Sparks, et al. Best Current Practice [Page 3] RFC 5589 SIP CC Transfer June 2009 Screener: receives a call ultimately intended for the Recipient and transfers the calling party to the Recipient if appropriate. Typically, a Screener acts on behalf of the Recipient.Recipient -Recipient: the party to which the Originator is ultimatelyconnected to.connected. 3. Terminology 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 BCP 14, RFC 2119 [RFC2119]. 4. 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 currentPBXPrivate Branch Exchange (PBX) or Centrex user expects. As thecall-flowscall 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 transferfailurefailure, for instance) will be lost. 3. The Transferor must know whether or not the transfer was successful.Sparks, et al. Expires September 4, 2009 [Page 5] Internet-Draft SIP CC Transfer March 20094. 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. Sparks, et al. Best Current Practice [Page 4] RFC 5589 SIP CC Transfer June 2009 To meet this requirement, the transfer operation can be modeled as anad-hocad hoc conference between three parties, as discussed in Section8.9. 5. Using REFER toachieveAchieve Call Transfer A REFER [RFC3515] can be issued by the Transferor to cause the Transferee to issue an INVITE to theTransfer-Target.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 thetransfer targetTransfer Target is not affected by the media that had been negotiated between thetransferorTransferor and thetransferee.Transferee. In particular, the INVITE issued by the Transferee will have the sameSDPSession Description Protocol (SDP) body it would have ifhethe 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. Agents may alter a session's media through additional signaling. For example, they may make use of the SIP hold re-INVITE [RFC3261] or conferencing extensions described in the conferencing framework [RFC4353]. To perform the transfer, thetransferorTransferor andtransfereeTransferee 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 6.2. However, the approach described in this document is to avoid dialog reuse. The issues and difficulties associated with dialog reuse are described in[RFC5057][RFC5057]. Motivations for reusing the existing dialog include: 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 theSparks, et al. Expires September 4, 2009 [Page 6] Internet-Draft SIP CC Transfer March 2009existing dialog ensured it got to the endpoint to which we were alreadytalking to.talking. 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 theinviteINVITE usage's dialog. Sparks, et al. Best Current Practice [Page 5] RFC 5589 SIP CC Transfer June 2009 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 [I-D.ietf-sip-gruu]Globally Routable UA URIs (GRUUs) [SIP-GRUU] can be used to address problem 1. Problem 2 can be addressed using the Target-Dialog header field defined in [RFC4538]. In the immediate term, this solution to problem 2 allows the existing REFER authorization policy to be reused. As a result, if the Transferee supports the target-dialog extension and the Transferor knows the Contact URI is routable outside the dialog, the REFER SHOULD be sent in a new dialog. If the nature of the Contact URI is not known or if support for the target-dialog extension is not known, the REFER SHOULD be sent inside the existing dialog. A Transferee MUST be prepared to receive a REFER either inside or outside a dialog. One way that a Transferor could know that a Contact URI is routable outside a dialog is by validation(e.g.(e.g., sending an OPTIONS and receiving a response) or if it satisfies the properties described in the GRUU specification[I-D.ietf-sip-gruu].[SIP-GRUU]. This document does not prescribe the flows and examples precisely as they are shown, but rather the flows illustrate the principles for best practice for the transfer feature. The call flows represent well-reviewed examples of SIP usage to implement transfer with REFER, which arebest common practiceBest Common Practice according to IETF consensus. 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. 6. 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 theSparks, et al. Expires September 4, 2009 [Page 7] Internet-Draft SIP CC Transfer March 2009Transfer Target's contact information has been exposed to the Transferee. The provided contact can be used to make new calls in the future. Sparks, et al. Best Current Practice [Page 6] RFC 5589 SIP CC Transfer June 2009 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. Participants SHOULD also indicate support for Target-Dialog in the Supported header field. The diagrams below show the first line of each message. The first column of the figure shows the dialog 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 conferencingextensionsextensions, 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 supports the target-dialog extension 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 Target-Dialog header field in the refer which references the existing dialog.6.1. Successful TransferSparks, et al.Expires September 4, 2009Best Current Practice [Page8] Internet-Draft7] RFC 5589 SIP CC TransferMarchJune 2009 6.1. Successful Transfer Transferor Transferee Transfer | | Target | INVITE F1 | | dialog1 |<-------------------| | | 200 OK F2 | | dialog1 |------------------->| | | ACK | | dialog1 |<-------------------| | | INVITE (hold) | | dialog1 |------------------->| | | 200 OK | | dialog1 |<-------------------| | | ACK | | dialog1 |------------------->| | | REFER F3 (Target-Dialog:1) | dialog2 |------------------->| | | 202 Accepted | | dialog2 |<-------------------| | | NOTIFY (100 Trying) F4 | dialog2 |<-------------------| | | 200 OK | | dialog2 |------------------->| | | | INVITE F5 | dialog3 | |------------------->| | | 200 OK | dialog3 | |<-------------------| | | ACK | dialog3 | |------------------->| | NOTIFY (200 OK) F6| | dialog2 |<-------------------| | | 200 OK | | dialog2 |------------------->| | | BYE | | dialog1 |------------------->| | | 200 OK | | dialog1 |<-------------------| | | | BYE | dialog3 | |<-------------------| | | 200 OK | dialog3 | |------------------->| Figure1.1: Basic Transfer CallFlow.Flow Sparks, et al. Best Current Practice [Page 8] RFC 5589 SIP CC Transfer June 2009 F1 INVITE Transferee -> Transferor INVITE sips:transferor@atlanta.example.com SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432Sparks, et al. Expires September 4, 2009 [Page 9] Internet-Draft SIP CC Transfer March 2009Max-Forwards: 70 To: <sips:transferor@atlanta.example.com> From: <sips:transferee@biloxi.example.com>;tag=7553452 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu, tdialog Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha> 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: <sips:transferor@atlanta.example.com>;tag=31kdl4i3k From: <sips:transferee@biloxi.example.com>;tag=7553452 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu, tdialog Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d> Content-Type: application/sdp Content-Length: ... F3 REFER Transferor -> Transferee REFER sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKna9 Max-Forwards: 70 To: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha> From: <sips:transferor@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 REFER Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: gruu, replaces, tdialog Require: tdialog Refer-To: <sips:transfertarget@chicago.example.com> Target-Dialog: 090459243588173445;local-tag=7553452 ;remote-tag=31kdl4i3k Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d> Content-Length: 0F4 NOTIFY Transferee -> TransferorSparks, et al.Expires September 4, 2009Best Current Practice [Page10] Internet-Draft9] RFC 5589 SIP CC TransferMarchJune 2009 F4 NOTIFY Transferee -> Transferor NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 Max-Forwards: 70 To: <sips:transferor@atlanta.example.com>;tag=1928301774 From: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha> ;tag=a6c85cf Call-ID: a84b4c76e66710 CSeq: 73 NOTIFY Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, tdialog 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: <sips:transfertarget@chicago.example.com> From: <sips:transferee@biloxi.example.com>;tag=j3kso3iqhq Call-ID: 90422f3sd23m4g56832034 CSeq: 521 REFER Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu, tdialog Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha> Content-Type: application/sdp Content-Length: ... Sparks, et al. Best Current Practice [Page 10] RFC 5589 SIP CC Transfer June 2009 F6 NOTIFY Transferee -> Transferor NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 Max-Forwards: 70 To: <sips:transferor@atlanta.example.com>;tag=1928301774 From: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha> ;tag=a6c85cf Call-ID: a84b4c76e66710 CSeq: 74 NOTIFY Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, tdialog Event: refer Subscription-State: terminated;reason=noresourceSparks, et al. Expires September 4, 2009 [Page 11] Internet-Draft SIP CC Transfer March 2009Content-Type: message/sipfrag Content-Length: ... SIP/2.0 200 OK 6.2. Transfer with Dialog Reuse In this scenario, the Transferor does not know the properties of the Transferee's Contact URI or does not know that the Transferee supports the Target-Dialog header field. As a result, the REFER is sent inside the INVITE dialog. Sparks, et al.Expires September 4, 2009Best Current Practice [Page12] Internet-Draft11] RFC 5589 SIP CC TransferMarchJune 2009 Transferor Transferee Transfer | | Target | INVITE F1 | | dialog1 |<-------------------| | | 200 OK F2 | | dialog1 |------------------->| | | ACK | | dialog1 |<-------------------| | | INVITE (hold) | | dialog1 |------------------->| | | 200 OK | | dialog1 |<-------------------| | | ACK | | dialog1 |------------------->| | | REFER F3 | | dialog1 |------------------->| | | 202 Accepted | | dialog1 |<-------------------| | | NOTIFY (100 Trying) F4 | dialog1 |<-------------------| | | 200 OK | | dialog1 |------------------->| | | | INVITE F5 | dialog2 | |------------------->| | | 200 OK | dialog2 | |<-------------------| | | ACK | dialog2 | |------------------->| | NOTIFY (200 OK) F6| | dialog1 |<-------------------| | | 200 OK | | dialog1 |------------------->| | | BYE | | dialog1 |------------------->| | | 200 OK | | dialog1 |<-------------------| | | | BYE | dialog2 | |<-------------------| | | 200 OK | dialog2 | |------------------->| Figure2.2: Transfer with DialogReuse.Reuse Sparks, et al. Best Current Practice [Page 12] RFC 5589 SIP CC Transfer June 2009 F1 INVITE Transferee -> Transferor INVITE sips:transferor@atlanta.example.com SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432Sparks, et al. Expires September 4, 2009 [Page 13] Internet-Draft SIP CC Transfer March 2009Max-Forwards: 70 To: <sips:transferor@atlanta.example.com> From: <sips:transferee@biloxi.example.com>;tag=7553452 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Contact: <sips:transferee@192.0.2.4> 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: <sips:transferor@atlanta.example.com>;tag=31kdl4i3k From: <sips:transferee@biloxi.example.com>;tag=7553452 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: gruu, replaces Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d> 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: <sips:transferee@biloxi.example.com>;tag=7553452 From: <sips:transferor@atlanta.example.com>;tag=31kdl4i3k Call-ID: 090459243588173445 CSeq: 314159 REFER Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Refer-To: <sips:transfertarget@chicago.example.com> Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d> Content-Length: 0 Sparks, et al. Best Current Practice [Page 13] RFC 5589 SIP CC Transfer June 2009 F4 NOTIFY Transferee -> Transferor NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 Max-Forwards: 70Sparks, et al. Expires September 4, 2009 [Page 14] Internet-Draft SIP CC Transfer March 2009To: <sips:transferor@atlanta.example.com>;tag=31kdl4i3k From: <sips:transferee@biloxi.example.com>;tag=7553452 Call-ID: 090459243588173445 CSeq: 29888 INVITE Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha> 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: <sips:transfertarget@chicago.example.com> From: <sips:transferee@biloxi.example.com>;tag=j3kso3iqhq Call-ID: 90422f3sd23m4g56832034 CSeq: 521 REFER Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Contact: <sips:transferee@192.0.2.4> Content-Type: application/sdp Content-Length: ... Sparks, et al. Best Current Practice [Page 14] RFC 5589 SIP CC Transfer June 2009 F6 NOTIFY Transferee -> Transferor NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 Max-Forwards: 70 To: <sips:transferor@atlanta.example.com>;tag=31kdl4i3k From: <sips:transferee@biloxi.example.com>;tag=7553452 Call-ID: 090459243588173445 CSeq: 29889 INVITE Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha> 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 OKSparks, et al. Expires September 4, 2009 [Page 15] Internet-Draft SIP CC Transfer March 20096.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.6.3.1. Target BusySparks, et al.Expires September 4, 2009Best Current Practice [Page16] Internet-Draft15] RFC 5589 SIP CC TransferMarchJune 2009 6.3.1. Target Busy Transferor Transferee Transfer | | Target | | | | INVITE | | dialog1 |<-------------------| | | 200 OK | | dialog1 |------------------->| | | ACK | | dialog1 |<-------------------| | | INVITE (hold) | | dialog1 |------------------->| | | 200 OK | | dialog1 |<-------------------| | | ACK | | dialog1 |------------------->| | | REFER (Target-Dialog:1) | dialog2 |------------------->| | | 202 Accepted | | dialog2 |<-------------------| | | NOTIFY (100 Trying)| | dialog2 |<-------------------| | | 200 OK | | dialog2 |------------------->| | | | INVITE | dialog3 | |------------------->| | | 486 Busy Here | dialog3 | |<-------------------| | | ACK | dialog3 | |------------------->| | NOTIFY (486 Busy Here) | dialog2 |<-------------------| | | 200 OK | | dialog2 |------------------->| | | INVITE (unhold) | | dialog1 |------------------->| | | 200 OK | | dialog1 |<-------------------| | | ACK | | dialog1 |------------------->| | | BYE | | dialog1 |------------------->| | | 200 OK | | dialog1 |<-------------------| | Figure3.3: Failed Transfer - Target Busy Sparks, et al.Expires September 4, 2009Best Current Practice [Page17] Internet-Draft16] RFC 5589 SIP CC TransferMarchJune 2009 6.3.2. Transfer Targetdoes not answerDoes Not Answer Transferor Transferee Transfer | | Target | INVITE | | dialog1 |<-------------------| | | 200 OK | | dialog1 |------------------->| | | ACK | | dialog1 |<-------------------| | | INVITE (hold) | | dialog1 |------------------->| | | 200 OK | | dialog1 |<-------------------| | | ACK | | dialog1 |------------------->| | | REFER | | dialog2 |------------------->| | | 202 Accepted | | dialog2 |<-------------------| | | NOTIFY (100 Trying)| | dialog2 |<-------------------| | | 200 OK | | dialog2 |------------------->| | | | INVITE | dialog3 | |------------------->| | | 180 Ringing | dialog3 | |<-------------------| | (Transferee gets tired of waiting) | | CANCEL | dialog3 | |------------------->| | | 200 OK (CANCEL) | dialog3 | |<-------------------| | 487 Request Cancelled (INVITE) dialog3 | |<-------------------| | | ACK | dialog3 | |------------------->| | NOTIFY (487 Request Cancelled) | dialog2 |<-------------------| | | 200 OK | | dialog2 |------------------->| | | INVITE (unhold) | | dialog1 |------------------->| | | 200 OK | | dialog1 |<-------------------| | | ACK | | dialog1 |------------------->| | | BYE | | Sparks, et al.Expires September 4, 2009Best Current Practice [Page18] Internet-Draft17] RFC 5589 SIP CC TransferMarchJune 2009| BYE | |dialog1 |------------------->| | | 200 OK | | dialog1 |<-------------------| | Figure4.4: Failed Transfer - Target Does NotAnswer.Answer 7. Transfer with Consultation Hold Transfer withConsultation Holdconsultation hold involves a session between thetransferorTransferor and thetransfer targetTransfer Target before the transfer actually takes place. This is implemented with SIP Hold and Transfer as described above. A nice feature is for thetransferorTransferor 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. 7.1. Exposingtransfer targetTransfer Target ThetransferorTransferor places thetransfereeTransferee on hold, establishes a call with thetransfer targetTransfer Target to alert them to the impending transfer, terminates the connection with thetransfer target,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. To (hopefully) improve clarity, non-REFER transactions have been collapsed into one indicator with the arrow showing the direction of the request. Sparks, et al.Expires September 4, 2009Best Current Practice [Page19] Internet-Draft18] RFC 5589 SIP CC TransferMarchJune 2009 Transferor Transferee Transfer | | Target | | | dialog1 | INVITE/200 OK/ACK | | |<-------------------| | dialog1 | INVITE (hold)/200 OK/ACK | |------------------->| | dialog2 | INVITE/200 OK/ACK | | |---------------------------------------->| dialog2 | BYE/200 OK | | |---------------------------------------->| dialog3 | REFER | | |------------------->| | 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 | | |<-------------------| Figure5.5: Transfer with Consultation Hold - Exposing TransferTarget.Target 7.2. Protectingtransfer targetTransfer Target ThetransferorTransferor places thetransfereeTransferee on hold, establishes a call with thetransfer targetTransfer Target and then reverses their roles, transferring the originaltransfer targetTransfer Target to the originaltransferee.Transferee. This has the advantage of hiding information about the originaltransfer targetTransfer Target from the originaltransferee.Transferee. On the other hand, the Transferee's experience is differentthatthan in current systems. The Transferee is effectively "called back" by the Transfer Target. One of the problems with this simplest implementation of a target protecting transfer is that thetransfereeTransferee is receiving a new call from thetransfer-target.Transfer Target. Unless thetransferee'sTransferee's agent has a reliable way to associate this new call with the call it already has with thetransferor,Transferor, it will have to alert the new call on anotherSparks, et al. Expires September 4, 2009 [Page 20] Internet-Draft SIP CC Transfer March 2009appearance. If this, or some other call-waiting-like UI were not Sparks, et al. Best Current Practice [Page 19] RFC 5589 SIP CC Transfer June 2009 available, thetransfereeTransferee might be stuck returning a Busy-Here to thetransfer target,Transfer Target, effectively preventing the transfer. There are many ways thatthatcorrelation could be provided. The dialog parameters could be provided directly as header parameters in theRefer-To: URIRefer-To URI, for example. The Replaces mechanism [RFC3891] 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[RFC3891][RFC3891], this is the Call-ID,To-tagTo-tag, and From-tag. Note that thetransferee'sTransferee's agent emits a BYE to thetransferor'sTransferor'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. In this scenario, the Transferee utilizes a GRUU as a Contact URI for reasons discussed in Section 6.3. Note that the conventions used in the SIP Torture Test Messages [RFC4475] document are reused, specifically the <allOneLine> tag. Sparks, et al.Expires September 4, 2009Best Current Practice [Page21] Internet-Draft20] RFC 5589 SIP CC TransferMarchJune 2009 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 (Target-Dialog:2, | | Refer-To:sips:Transferee?Replaces=1) 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(Transferee and target converse) dialog4 | | BYE/200 OK | | |------------------->| Figure6.6: Transfer Protecting TransferTarget.Target Sparks, et al. Best Current Practice [Page 21] RFC 5589 SIP CC Transfer June 2009 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: <sips:transferor@atlanta.example.com> From: <sips:transferee@biloxi.example.com>;tag=7553452 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruuSparks, et al. Expires September 4, 2009 [Page 22] Internet-Draft SIP CC Transfer March 2009Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha> 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: <sips:transferor@atlanta.example.com>;tag=31431 From: <sips:transferee@biloxi.example.com>;tag=7553452 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu, tdialog Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d> 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: <sips:transfertarget@chicago.example.com> From: <sips:transferor@atlanta.example.com>;tag=763231 Call-ID: 592435881734450904 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: gruu, replaces, tdialog Require: replaces Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=384i32lw3> Content-Type: application/sdp Content-Length: ... Sparks, et al. Best Current Practice [Page 22] RFC 5589 SIP CC Transfer June 2009 F4 200 OK Transfer Target -> Transferor SIP/2.0 200 OK Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432 ;received=192.0.2.1 To: <sips:transfertarget@chicago.example.com>;tag=9m2n3wq From: <sips:transferor@atlanta.example.com>;tag=763231 Call-ID: 592435881734450904 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu, tdialogSparks, et al. Expires September 4, 2009 [Page 23] Internet-Draft SIP CC Transfer March 2009Contact: <sips:482n4z24kdg@chicago.example.com;gr=8594958> Content-Type: application/sdp Content-Length: ... F5 REFER Transferor -> Transfer Target REFER sips:482n4z24kdg@chicago.example.com;gr=8594958 SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 Max-Forwards: 70 To: <sips:482n4z24kdg@chicago.example.com;gr=8594958> From: <sips:transferor@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 REFER Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: gruu, replaces, tdialog Require: tdialog <allOneLine> Refer-To: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha ?Replaces=090459243588173445%3Bto-tag%3D7553452%3Bfrom-tag%3D31431> </allOneLine> Target-Dialog: 592435881734450904;local-tag=9m2n3wq ;remote-tag=763231 Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d> Content-Length: 0 Sparks, et al. Best Current Practice [Page 23] RFC 5589 SIP CC Transfer June 2009 F6 INVITE Transfer Target -> Transferee INVITE sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0 Via: SIP/2.0/TLS client.chicago.example.com;branch=z9hG4bKnaslu84 Max-Forwards: 70 To: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha> From: <sips:transfertarget@chicago.example.com>;tag=341234 Call-ID: kmzwdle3dl3d08 CSeq: 41 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: gruu, replaces, tdialog Contact: <sips:482n4z24kdg@chicago.example.com;gr=8594958> Replaces: 090459243588173445;to-tag=7553452;from-tag=31431 Content-Type: application/sdp Content-Length: ...Sparks, et al. Expires September 4, 2009 [Page 24] Internet-Draft SIP CC Transfer March 20097.3. Attended Transfer ThetransferorTransferor places thetransfereeTransferee on hold, establishes a call with thetransfer targetTransfer 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. The Contact URI of the Transfer Target SHOULD be used by the Transferor as the Refer-To URI, unless the URI is suspected or known to not be routable outside the dialog. Otherwise, the Address of Record (AOR) of the Transfer Target SHOULD be used. That is, the same URI that the Transferor 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 Agentwhichthat 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 atimout,timeout, 403, 404,etcetc. error. The Transferee MAY then retry the transfer with the Refer-To URI set to the Contact URI. Sparks, et al.Expires September 4, 2009Best Current Practice [Page25] Internet-Draft24] RFC 5589 SIP CC TransferMarchJune 2009 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 (Target-Dialog:1, | | Refer-To:sips:TransferTarget?Replaces=2) 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 | | |------------------->| | dialog4 | | BYE/200 OK | | |<-------------------| Figure7.7: Attended Transfer CallFlow.Flow Sparks, et al. Best Current Practice [Page 25] RFC 5589 SIP CC Transfer June 2009 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: <sips:transferor@atlanta.example.com> From: <sips:transferee@biloxi.example.com>;tag=7553452 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu, tdialog Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>Sparks, et al. Expires September 4, 2009 [Page 26] Internet-Draft SIP CC Transfer March 2009Content-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: <sips:transferor@atlanta.example.com>;tag=31431 From: <sips:transferee@biloxi.example.com>;tag=7553452 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu, tdialog Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d> 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: <sips:transfertarget@chicago.example.com> From: <sips:transferor@atlanta.example.com>;tag=763231 Call-ID: 592435881734450904 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: gruu, replaces, tdialog Require: replaces Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=384i32lw3> Content-Type: application/sdp Content-Length: ... Sparks, et al. Best Current Practice [Page 26] RFC 5589 SIP CC Transfer June 2009 F4 200 OK Transfer Target -> Transferor SIP/2.0 200 OK Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432 ;received=192.0.2.1 To: <sips:transfertarget@chicago.example.com>;tag=9m2n3wq From: <sips:transferor@atlanta.example.com>;tag=763231 Call-ID: 592435881734450904 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Contact: <sips:482n4z24kdg@chicago.example.com;gr=8594958>Sparks, et al. Expires September 4, 2009 [Page 27] Internet-Draft SIP CC Transfer March 2009Content-Type: application/sdp Content-Length: ... F5 REFER Transferor -> Transferee REFER sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 Max-Forwards: 70 To: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha> From: <sips:transferor@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 REFER Require: tdialog <allOneLine> Refer-To: <sips:482n4z24kdg@chicago.example.com;gr=8594958? Replaces=592435881734450904%3Bto-tag%3D9m2n3wq%3Bfrom-tag3D763231> </allOneLine> Target-Dialog: 592435881734450904;local-tag=9m2n3wq ;remote-tag=763231 Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d> Content-Length: 0 Sparks, et al. Best Current Practice [Page 27] RFC 5589 SIP CC Transfer June 2009 F6 INVITE Transferee -> Transfer Target INVITE sips:482n4z24kdg@chicago.example.com;gr=8594958 SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnaslu82 Max-Forwards: 70 To: <sips:482n4z24kdg@chicago.example.com;gr=8594958> From: <sips:transferee@biloxi.example.com>;tag=954 Call-ID: kmzwdle3dl3d08 CSeq: 41 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: gruu, replaces, tdialog Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha> Replaces: 592435881734450904;to-tag=9m2n3wq;from-tag=763231 Content-Type: application/sdp Content-Length: ... 7.4. Recoverywhen one party does not supportWhen One Party Does Not Support REFER If protecting or exposing thetransfer targetTransfer 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 September 4, 2009Best Current Practice [Page 28]Internet-DraftRFC 5589 SIP CC TransferMarchJune 2009 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 (Target-Dialog:1, | | Refer-To:sips:TransferTarget?Replaces=2) |------------------->| | 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 | | |------------------->| Figure8.8: Recoverywhen one party does not support REFER.When One Party Does Not Support REFER 7.5. Attendedtransfer whenTransfer When Contact URIis not knownIs Not Known torouteRoute to aunique user agent.Unique User Agent It is a requirement ofRFC3261RFC 3261 that a Contact URI be globally routable even outside the dialog. However, due toRFC2543RFC 2543 User Agents and some architectures (NAT/Firewall traversal, screening proxies,ALGs,Application Layer Gateways (ALGs), etc.) this will not Sparks, et al. Best Current Practice [Page 29] RFC 5589 SIP CC Transfer June 2009 always be the case. As a result, the method ofAttended Transferattended transfer shown in Figures 6, 7, and 8 SHOULD only be used if the Contact URI is known to be routable outside theSparks, et al. Expires September 4, 2009 [Page 29] Internet-Draft SIP CC Transfer March 2009dialog. Figure 9 shows such a scenario where the Transfer Target Contact URI is not routable outside the dialog, 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 | | |<------------|-------------| Figure9.9: Attended Transfer Call Flow with a Contact URInot knownNot Known tobeBe Globally Routable Sparks, et al. Best Current Practice [Page 30] RFC 5589 SIP CC Transfer June 2009 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: 70Sparks, et al. Expires September 4, 2009 [Page 30] Internet-Draft SIP CC Transfer March 2009To: <sips:transfertarget@chicago.example.com> From: <sips:transferor@atlanta.example.com>;tag=763231 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Contact: <sips:transferor@pc33.atlanta.example.com> 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: <sips:transfertarget@chicago.example.com>;tag=9m2n3wq From: <sips:transferor@atlanta.example.com>;tag=763231 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Contact: <sips:transfertarget@client.chicago.example.com> 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: <sips:transferee@biloxi.example.com>;tag=a6c85cf From: <sips:transferor@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314160 REFER <allOneLine> Refer-To: <sips:transfertarget@chicago.example.com?Replaces= 090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-tag%3D763231 &Require=replaces> <allOneLine> Contact: <sips:transferor@pc33.atlanta.example.com> Content-Length: 0F4 INVITE Transferee -> Transfer Target INVITE sips:transfertarget@chicago.example.com SIP/2.0Sparks, et al.Expires September 4, 2009Best Current Practice [Page 31]Internet-DraftRFC 5589 SIP CC TransferMarchJune 2009 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: <sips:transfertarget@chicago.example.com> From: <sips:transferee@biloxi.example.com>;tag=954 Call-ID: 20482817324945934422930 CSeq: 42 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Contact: <sips:transferee@192.0.2.4> 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: <sips:transferor@atlanta.example.com>;tag=1928301774 From: <sips:transferee@biloxi.example.com>;tag=a6c85cf Call-ID: a84b4c76e66710 CSeq: 76 NOTIFY Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha> 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 thetransferTransfer Target. As a result, the transfer is retried with the ContactURIURI, at which point it 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. Sparks, et al.Expires September 4, 2009Best Current Practice [Page 32]Internet-DraftRFC 5589 SIP CC TransferMarchJune 2009 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 | | | |----------------->| | | 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 | | |<------------|-------------| Sparks, et al.Expires September 4, 2009Best Current Practice [Page 33]Internet-DraftRFC 5589 SIP CC TransferMarchJune 2009 Figure10.10: Attended Transfer Call Flow withnon-routableNon-Routable Contact 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: <sips:transfertarget@chicago.example.com> From: <sips:transferor@atlanta.example.com>;tag=763231 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Contact: <sips:transferor@pc33.atlanta.example.com> 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: <sips:transfertarget@chicago.example.com>;tag=9m2n3wq From: <sips:transferor@atlanta.example.com>;tag=763231 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Contact: <sips:transfertarget@client.chicago.example.com> Content-Type: application/sdp Content-Length: ... Sparks, et al. Best Current Practice [Page 34] RFC 5589 SIP CC Transfer June 2009 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: <sips:transferee@biloxi.example.com>;tag=a6c85cf From: <sips:transferor@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 REFER <allOneLine> Refer-To: <sips:transfertarget@chicago.example.com?Replaces= 090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-tag%3D763231Sparks, et al. Expires September 4, 2009 [Page 34] Internet-Draft SIP CC Transfer March 2009&Require=replaces> </allOneLine> Contact: <sips:transferor@pc33.atlanta.example.com> 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: <sips:transferor@atlanta.example.com>;tag=1928301774 From: <sips:transferee@biloxi.example.com>;tag=a6c85cf Call-ID: a84b4c76e66710 CSeq: 74 NOTIFY Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha> 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 Sparks, et al. Best Current Practice [Page 35] RFC 5589 SIP CC Transfer June 2009 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: <sips:transferee@biloxi.example.com>;tag=a6c85cf From: <sips:transferor@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314160 REFER <allOneLine> Refer-To: <sips:transfertarget@client.chicago.example.com ?Replaces=090459243588173445%3Bto-tag%3D9m2n3wq %3Bfrom-tag%3D763231> </allOneLine> Contact: <sips:transferor@pc33.atlanta.example.com> 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: 70Sparks, et al. Expires September 4, 2009 [Page 35] Internet-Draft SIP CC Transfer March 2009To: <sips:transfertarget@chicago.example.com> From: <sips:transferee@biloxi.example.com>;tag=954 Call-ID: 20482817324945934422930 CSeq: 42 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Contact: <sips:transferee@192.0.2.4> Replaces: 090459243588173445;to-tag=9m2n3wq;from-tag=763231 Content-Type: application/sdp Content-Length: ... Sparks, et al. Best Current Practice [Page 36] RFC 5589 SIP CC Transfer June 2009 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 To: <sips:transferor@atlanta.example.com>;tag=1928301774 From: <sips:transferee@biloxi.example.com>;tag=a6c85cf Call-ID: a84b4c76e66710 CSeq: 76 NOTIFY Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha> 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 use a Contact URIwhichthat is routable outside the dialog, which will result in the call flow of Figure 7. 7.6. Semi-Attended Transfer In any of the consultation hold flows above, the Transferor may decide to terminate its attempt to contact the TransfertargetTarget before that session is established. Most frequently, that will be the end of the scenario, but in some circumstances, thetransferorTransferor may wish to proceed with the transfer action. For example, the Transferor may wish to complete the transfer knowing that thetransfereeTransferee will end up eventually talking to thetransfer-target's voice-mailTransfer Target's voicemail 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 transferSparks, et al. Expires September 4, 2009 [Page 36] Internet-Draft SIP CC Transfer March 2009as 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. Sparks, et al. Best Current Practice [Page 37] RFC 5589 SIP CC Transfer June 2009 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 | | | | User Agent continues transfer operation | | | | dialog2 | | 200 OK | |<----------------------------------------| dialog2 | ACK | | |---------------------------------------->| dialog2 | Media Played to keep Target from hanging up |========================================>| dialog3 | REFER (Target-Dialog:1, | | Refer-To:sips:TransferTarget?Replaces=2) |------------------->| | 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 | | |<-------------------|Sparks, et al. Expires September 4, 2009 [Page 37] Internet-Draft SIP CC Transfer March 2009Figure11.11: Recommended Semi-Attended Transfer CallFlow.Flow Two other possible semi-attended transfer call flows are shown in Figures 12 and 13. However, these call flows are NOT RECOMMENDED due toarace conditions. In both of these flows, when the Transferor Sparks, et al. Best Current Practice [Page 38] RFC 5589 SIP CC Transfer June 2009 hangs up, the Transferor attempts to revert to unattended transfer by sending a CANCEL to theTarget.target. This can result in two race conditions. One is that theTargettarget 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 theTargettarget is returned. Instead of a 487, a 200 OK mayreturnbe returned indicating that theTargettarget has answered the consultation call. Inthis, casethis 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 theTransfertransfer 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).(F2)). 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. Sparks, et al.Expires September 4, 2009Best Current Practice [Page38] Internet-Draft39] RFC 5589 SIP CC TransferMarchJune 2009 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 (Target-Dialog:1) 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 | | |<-------------------| Figure12.12: Semi-Attended Transfer as Blind Transfer CallFlow.Flow (Not Recommended) Sparks, et al.Expires September 4, 2009Best Current Practice [Page39] Internet-Draft40] RFC 5589 SIP CC TransferMarchJune 2009 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 September 4, 2009Best Current Practice [Page40] Internet-Draft41] RFC 5589 SIP CC TransferMarchJune 2009 Figure13.13: Semi-Attended Transfer as Attended Transfer CallFlow.Flow (Not Recommended) 7.7. Attended Transfer Fallback to Basic Transfer In this flow, an attempted attended transfer fails so thetransferorTransferor 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 complete 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. Best Current Practice [Page 42] RFC 5589 SIP CC Transfer June 2009 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 |Sparks, et al. Expires September 4, 2009 [Page 41] Internet-Draft SIP CC Transfer March 2009| |<-------------------| Figure14.14: Attended Transfer Fallback to Basic Transferusing Require:replaces.Using Require:replaces Figure 15 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 Transferordeterminesdetermines, usingOPTIONSOPTIONS, 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 theTargettarget does not support either REFER or Replaces, Sparks, et al. Best Current Practice [Page 43] RFC 5589 SIP CC Transfer June 2009 making attended transfer impossible. The Transferor then ends dialog2 by sending a BYE then sends a REFER to the Transferee using the AOR URI of the Transfer Target.Sparks, et al. Expires September 4, 2009 [Page 42] Internet-Draft SIP CC Transfer March 2009Transferor 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 (Target-Dialog:1, | | 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 | | |<-------------------| Figure15.15: Attended Transfer Fallback to BasicTransfer.Transfer Sparks, et al. Best Current Practice [Page 44] RFC 5589 SIP CC Transfer June 2009 8. 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 [RFC3892] provides a way for the Transferor to provide the Transferee with a way to let the Transfer Target know what party initiated the transfer. The simplest and least secure approach just involves the inclusion ofSparks, et al. Expires September 4, 2009 [Page 43] Internet-Draft SIP CC Transfer March 2009the Referred-By header field in theREFERREFER, which is then copied into the triggered INVITE. However, a more secure mechanism involving the Referred-By securitytokentoken, which is generated and signed by the Transferor and passed in a message body to the Transferee then to the Transfer Target. The call flowis shownin Figure 16showingshows the Referred-By header field and body in the REFER F5 and triggered INVITE F6. Note that theS/MIMESecure/ Multipurpose Internet Mail Extensions (S/MIME) signature is not shown in the example below. The conventions used in the SIP Torture Test Messages [RFC4475] document are reused, specifically the <hex> and <allOneLine> tags. Sparks, et al. Best Current Practice [Page 45] RFC 5589 SIP CC Transfer June 2009 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 (Target-Dialog:1, Referred-By:Transferor, | Refer-To:sips:TransferTarget?Replaces=2) F5 |------------------->| | dialog3 | 202 Accepted | | |<-------------------| | dialog3 | NOTIFY (100 Trying)| | |<-------------------| | dialog3 | 200 OK | | |------------------->| | dialog4 | INVITE (Replaces:dialog2, | | Referred-By:Transferor )/200 OK/ACK F6 | |------------------->| dialog2 | BYE/200 OK | | |<----------------------------------------| dialog3 | NOTIFY (200 OK) | | |<-------------------| | dialog3 | 200 OK | | |------------------->| | dialog1 | BYE/200 OK | | |------------------->| | dialog4 | | BYE/200 OK | | |<-------------------| Figure16.16: Attended Transfer Call Flow withReferred-By.Referred-By Sparks, et al.Expires September 4, 2009Best Current Practice [Page44] Internet-Draft46] RFC 5589 SIP CC TransferMarchJune 2009 F5 REFER Transferor -> Transferee REFER sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK392039842 Max-Forwards: 70 To: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha> From: <sips:transferor@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314160 REFER <allOneLine> Refer-To: <sips:482n4z24kdg@chicago.example.com;gr=8594958 ?Replaces=090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-tag %3D763231&Require=replaces> </allOneLine> Supported: gruu, replaces, tdialog Require: tdialog Referred-By: <sips:transferor@atlanta.example.com> ;cid="20398823.2UWQFN309shb3@atlanta.example.com" Target-Dialog: 592435881734450904;local-tag=9m2n3wq;remote-tag=763231 Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d> Content-Type: multipart/mixed; boundary=unique-boundary-1 Content-Length: ... --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 Date: Thu, 18 Sep 2003 13:07:43 GMT <allOneLine> Refer-To: <sips:482n4z24kdg@chicago.example.com;gr=8594958 ?Replaces=090459243588173445%3B to-tag%3D9m2n3wq%3Bfrom-tag%3D763231&Require=replaces> </allOneLine> Referred-By: <sips:transferor@atlanta.example.com> ;cid="20398823.2UWQFN309shb3@atlanta.example.com" ------590F24D439B31E08745DEF0CD9397189 Content-Type: application/pkcs-7-signature; name="smime.p7s" Sparks, et al.Expires September 4, 2009Best Current Practice [Page45] Internet-Draft47] RFC 5589 SIP CC TransferMarchJune 2009 Content-Transfer-Encoding: binary Content-Disposition: attachment; filename="smime.p7s" <hex>3082088806092A86 4886F70D010702A082087930820875020101310B300906052B0E03021A050030 . . . (Signature not shown) 8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B428388966 79089AAD95767F</hex> ------590F24D439B31E08745DEF0CD9397189-- --unique_boundary-1 F6 INVITE Transferee -> Transfer Target INVITE sips:482n4z24kdg@chicago.example.com;gr=8594958 SIP/2.0 Via: SIP/2.0/TLS referee.example;branch=z9hG4bKffe209934aac To: <sips:482n4z24kdg@chicago.example.com;gr=8594958> From: <sips:transferee@biloxi.example.com>;tag=2909034023 Call-ID: fe9023940-a3465@referee.example CSeq: 889823409 INVITE Max-Forwards: 70 Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha> Referred-By: <sips:transferor@atlanta.example.com> ;cid="20398823.2UWQFN309shb3@atlanta.example.com" Replaces:090459243588173445;to-tag=9m2n3wq;from- tag=76323 Require: replaces Supported: gruu, replaces, tdialog Content-Type: multipart/mixed; boundary=my-boundary-9 Content-Length: ... --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 Sparks, et al.Expires September 4, 2009Best Current Practice [Page46] Internet-Draft48] RFC 5589 SIP CC TransferMarchJune 2009 --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 <allOneLine> Refer-To: <sips:transfertarget@chicago.example.com; Replaces=090459243588173445%3B to-tag%3D9m2n3wq%3Bfrom-tag%3D763231&Require=replaces> </allOneLine> Referred-By: <sips:transferor@atlanta.example.com> ;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" <hex>3082088806092A86 4886F70D010702A082087930820875020101310B300906052B0E03021A050030 . . . (Signature not shown) 8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B428388966 79089AAD95767F</hex> ------590F24D439B31E08745DEF0CD9397189-- --my-boundary-9-- 9. Transfer as anAd-HocAd Hoc Conference In this flow, shown in Figure 17, 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 afocus[RFC4579]focus [RFC4579] and hosts anad-hocad hoc conference involving Alice, Bob, and Carol. Alice and Carol subscribe to the conferencepackage[RFC4575]package [RFC4575] 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. Sparks, et al.Expires September 4, 2009Best Current Practice [Page47] Internet-Draft49] RFC 5589 SIP CC TransferMarchJune 2009Bob deletes the conference.This call flow meets requirement 6 of Section3.4. 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). 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 | |------------------->| Sparks, et al.Expires September 4, 2009Best Current Practice [Page48] Internet-Draft50] RFC 5589 SIP CC TransferMarchJune 2009|INVITE Require:replaces Contact:Conf-ID;isfocus | |------------------->|| | 180 Ringing | | |<-------------------| | | 200 OK | | |<-------------------| | | ACK | | |------------------->| | | 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) | | Sparks, et al.Expires September 4, 2009Best Current Practice [Page49] Internet-Draft51] RFC 5589 SIP CC TransferMarchJune 2009 |------------------->| | |NOTIFY (Refer) | | |------------------->| | |200 OK | | |<-------------------| | | INVITE Replaces:B-C Contact:Alice | |---------------------------------------->| | 200 OK | |<----------------------------------------| | 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 | | |------------------->| | Figure17.17: Attended Transfer as anAd-Hoc Conference.Ad Hoc Conference 10. Transfer withmultiple partiesMultiple Parties In thisexampleexample, shown in Figure 18, the Originator places a call to the Facilitator who reaches the Recipient through the Screener. TheSparks, et al. Expires September 4, 2009 [Page 50] Internet-Draft SIP CC Transfer March 2009Recipient's contact information is exposed to the Facilitator and the Originator. This example is provided for clarification of the semantics of the REFER methodonlyonly, and it should not be used as the design of an implementation. Sparks, et al. Best Current Practice [Page 52] RFC 5589 SIP CC Transfer June 2009 Originator Facilitator Screener Recipient | | | | 1 |INVITE/200 OK/ACK | |"Get Fred for me!" |----------->| | | "Right away!" 2 |INVITE (hold)/200 OK/ACK | | |<-----------| | | 2 | |INVITE/200 OK/ACK |"I have a call | |----------->| |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 | | |Sparks, et al. Expires September 4, 2009 [Page 51] Internet-Draft SIP CC Transfer March 2009|<-----------| | | 7 |INVITE/200 OK/ACK | | |----------------------------------->| "Hey Fred" Sparks, et al. Best Current Practice [Page 53] RFC 5589 SIP CC Transfer June 2009 6 |NOTIFY (200 OK) | | "Hello Mary" |----------->| | | 6 |200 OK | | | |<-----------| | | 1 |BYE/200 OK | | | |<-----------| | | 5 | |BYE/200 OK | | | |---------------------->| 7 |BYE/200 OK | | | |<-----------------------------------| "See you later" Figure18.18: Transfer with Multiple PartiesExample.Example 11. 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 somegateway specificgateway-specific issues that are documented in this section. While this discussion focuses on the common cases involvingPSTNPublic Switched Telephone Network (PSTN) gateways, similar situations exist for other gateways, such as H.323/SIP gateways. 11.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 thetransfereeTransferee residing on the PSTN side of a SIP gateway. ThetransferorTransferor is a SIP phone purely in the IP space. Thetransfer targetTransfer Target is on the PSTN side of a SIP gateway as well. After completing the transfer, (regardless of consultative or blind) thetransfereeTransferee is in a call with thetransfer targetTransfer 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 theSparks, et al. Expires September 4, 2009 [Page 52] Internet-Draft SIP CC Transfer March 2009consultative INVITE out the same gateway as the original call to be transferred.HoweverHowever, there is no way to relate the consultation with the original call. In the consultativecasecase, the target call Sparks, et al. Best Current Practice [Page 54] RFC 5589 SIP CC Transfer June 2009 INVITE includes the Replacesheaderheader, which contains dialog information that can be used to relate it to the consultation.HoweverHowever, 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.HoweverHowever, the same problem exists in that thetarget dialogtarget-dialog cannot be related to the original dialog. In either transfer scenario, it may be desirable to push the transfer operation onto the non-SIP side of the gateway.PresumablyPresumably, this is not possible unless all of the legs go out the same gateway. If the gateway supports more than onetrucktrunk 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. 11.2. Consultative Turned Blind Gateway Glare In the consultative transfer case turned blind, there is a glare-like problem. ThetransferorTransferor initiates the consultation INVITE, thetransferorTransferor gets impatient and hangs up, transitioning this to a blind transfer. Thetransfer targetTransfer 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 thetransfer target.Transfer Target. The REFER and INVITE for the target call are sent. ThetransfereeTransferee attempts tosetupset up the call on the PSTN side, but gets either a busy response 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 Section6.6.7.6. 12.IANA Considerations None. 13.Security Considerations The call transfer flows shown in this document are implemented usingSparks, et al. Expires September 4, 2009 [Page 53] Internet-Draft SIP CC Transfer March 2009the REFER and Replaces call control primitives in SIP. As such, the security considerations detailed in the REFER [RFC3515] and Replaces [RFC3891] documents MUST be followed, which are briefly summarized in the following paragraphs. This document addresses the issue of protecting the Address of Record URI of atransfer targetTransfer Target in Sections 7.1 and 7.2. Sparks, et al. Best Current Practice [Page 55] RFC 5589 SIP CC Transfer June 2009 Any REFER request MUST be appropriately authenticated and authorized using standard SIP mechanisms or else calls may be hijacked. Auser agentUser 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. Special care is needed if the replaced dialog utilizes additional media streams compared to the original dialog. In this case, the user MUST authorize the addition of new media streams in a dialog replacement. For example, the same mechanism used to authorize the addition of a media stream in a re-INVITE could be used.14.13. Acknowledgments Thisdraftdocument is a collaborative product of the SIP working group. Thanks to Rohan Mahy for his input on the use of Replaces in transfer.15.14. References15.1.14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] 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. [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.Sparks, et al. Expires September 4, 2009 [Page 54] Internet-Draft SIP CC Transfer March 2009[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. [RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004. Sparks, et al. Best Current Practice [Page 56] RFC 5589 SIP CC Transfer June 2009 [RFC4538] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, June 2006.15.2.14.2. Informative References[I-D.ietf-sipping-cc-framework][CC-FRMWRK] Mahy, R., Sparks, R., Rosenberg, J., Petrie, D., and A. Johnston, "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)",draft-ietf-sipping-cc-framework-10 (workWork inprogress), April 2008. [I-D.ietf-sip-gruu]Progress, March 2009. [RFC4353] Rosenberg, J.,"Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in"A Framework for Conferencing with the Session Initiation Protocol (SIP)",draft-ietf-sip-gruu-15 (work in progress), October 2007.RFC 4353, February 2006. [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006.[RFC4353][RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "AFramework for Conferencing with theSession Initiation Protocol(SIP)",(SIP) Event Package for Conference State", RFC4353, February4575, August 2006. [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006.[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", RFC 5057, November 2007. [SIP-GRUU] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Work in Progress, October 2007. Sparks, et al.Expires September 4, 2009Best Current Practice [Page55] Internet-Draft57] RFC 5589 SIP CC TransferMarchJune 2009 Authors' Addresses RobertJ.SparksEstacado Systems Email: RjS@estacado.netTekelec 17210 Campbell Road Suite 250 Dallas, Texas 75252 USA EMail: RjS@nostrum.com Alan Johnston (editor) Avaya St. Louis, MOEmail:EMail: alan@sipstation.com Daniel Petrie SIPez LLC34 Robbins Rd.Arlington, MA 02476 US Phone: +1 617 273 4000Email: dan.ietf AT SIPez DOT comEMail: dan.ietf@SIPez.com URI: http://www.SIPez.com/ Sparks, et al.Expires September 4, 2009Best Current Practice [Page56]58] ----