diff options
Diffstat (limited to 'doc/rfc/rfc5589.txt')
| -rw-r--r-- | doc/rfc/rfc5589.txt | 3251 |
1 files changed, 3251 insertions, 0 deletions
diff --git a/doc/rfc/rfc5589.txt b/doc/rfc/rfc5589.txt new file mode 100644 index 0000000..d55087a --- /dev/null +++ b/doc/rfc/rfc5589.txt @@ -0,0 +1,3251 @@ + + + + + + +Network Working Group R. Sparks +Request for Comments: 5589 Tekelec +BCP: 149 A. Johnston, Ed. +Category: Best Current Practice Avaya + D. Petrie + SIPez LLC + June 2009 + + + Session Initiation Protocol (SIP) Call Control - Transfer + +Status of This Memo + + This document 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 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. + + 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. + +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. Best Current Practice [Page 1] + +RFC 5589 SIP CC Transfer June 2009 + + +Table of Contents + + 1. Overview ........................................................3 + 2. Actors and Roles ................................................3 + 3. Terminology .....................................................4 + 4. Requirements ....................................................4 + 5. Using REFER to Achieve Call Transfer ............................5 + 6. Basic Transfer ..................................................6 + 6.1. Successful Transfer ........................................8 + 6.2. Transfer with Dialog Reuse ................................11 + 6.3. Failed Transfer ...........................................15 + 6.3.1. Target Busy ........................................16 + 6.3.2. Transfer Target Does Not Answer ....................17 + 7. Transfer with Consultation Hold ................................18 + 7.1. Exposing Transfer Target ..................................18 + 7.2. Protecting Transfer Target ................................19 + 7.3. Attended Transfer .........................................24 + 7.4. Recovery When One Party Does Not Support REFER ............28 + 7.5. Attended Transfer When Contact URI Is Not Known to + Route to a User Agent .....................................29 + 7.6. Semi-Attended Transfer ....................................37 + 7.7. Attended Transfer Fallback to Basic Transfer ..............42 + 8. Transfer with Referred-By ......................................45 + 9. Transfer as an Ad Hoc Conference ...............................49 + 10. Transfer with Multiple Parties ................................52 + 11. Gateway Transfer Issues .......................................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 ....................................................56 + 14.1. Normative References .....................................56 + 14.2. Informative References ...................................57 + + + + + + + + + + + + + + + + + + +Sparks, et al. Best Current Practice [Page 2] + +RFC 5589 SIP CC Transfer June 2009 + + +1. Overview + + This document describes providing Call Transfer capabilities and + requirements in SIP [RFC3261]. This work is part of the multiparty + call control framework [CC-FRMWRK]. + + The mechanisms discussed here are most closely related to + traditional, basic, and consultation hold transfers. + + This document details the use of the REFER method [RFC3515] and + Replaces [RFC3891] header field to achieve call transfer. + + A User Agent (UA) that fully supports the transfer mechanisms + described in this document supports REFER [RFC3515] and Replaces + [RFC3891] in addition to RFC 3261 [RFC3261]. A User Agent should use + a Contact URI that meets the requirements in Section 8.1.1.8 of RFC + 3261. A compliant User 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: the party being transferred to the Transfer + Target. + + Transferor: the party initiating the transfer. + + Transfer Target: the new party being introduced into a call with + the Transferee. + + The following roles are used to describe transfer requirements and + scenarios: + + Originator: wishes to place a call to the Recipient. This + actor is the source of the first INVITE in a + session, to either a Facilitator or a Screener. + + Facilitator: receives a call or out-of-band request from the + Originator, establishes a call to the Recipient + through the Screener, and connects the Originator + to the Recipient. Typically, a Facilitator acts + on behalf of the Originator. + + + + + + + +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: the party to which the Originator is ultimately + 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 current Private Branch + Exchange (PBX) or Centrex user expects. As the call flows + in this document show, this is not the case. A client may + preserve the current experience. In fact, without + this requirement, some forms of the current + experience (ringback on transfer failure, + for instance) will be lost. + + 3. The Transferor must know whether or not the transfer was + successful. + + 4. The Transferee must be able to replace an existing dialog with a + new dialog. + + 5. The Transferor and Transferee should indicate their support for + the primitives required to achieve transfer. + + 6. The Transferor should provide the Transfer Target and Transferee + with information about the nature and progress of the transfer + operation being attempted. + + + + + + +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 an ad hoc conference between three + parties, as discussed in Section 9. + +5. Using REFER to Achieve Call Transfer + + A REFER [RFC3515] can be issued by the Transferor to cause the + Transferee to issue an INVITE to the Transfer Target. Note that a + successful REFER transaction does not terminate the session between + the Transferor and the Transferee. If those parties wish to + terminate their session, they must do so with a subsequent BYE + request. The media negotiated between the transferee and the + Transfer Target is not affected by the media that had been negotiated + between the Transferor and the Transferee. In particular, the INVITE + issued by the Transferee will have the same Session Description + Protocol (SDP) body it would have if the 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, the Transferor and Transferee could reuse an + existing dialog established by an INVITE to send the REFER. This + would result in a single dialog shared by two uses -- an invite usage + and a subscription usage. The call flows for this are shown in + detail in Section 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]. + + 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 the + existing dialog ensured it got to the endpoint to which we were + already 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 the INVITE + 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"). + + 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., sending an OPTIONS and receiving a response) or if it + satisfies the properties described in the GRUU specification + [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 are Best 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 the + Transfer Target's contact information has been exposed to the + Transferee. The provided contact can be used to make new calls in + the future. + + + + + + +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 conferencing extensions, for example) are valid. + Selected message details are shown labeled as message F1, F2, etc. + + Each of the flows below shows the dialog between the Transferor and + the Transferee remaining connected (on hold) during the REFER + process. While this provides the greatest flexibility for recovery + from failure, it is not necessary. If the Transferor's agent does + not wish to participate in the remainder of the REFER process and has + no intention of assisting with recovery from transfer failure, it + could emit a BYE to the Transferee as soon as the REFER transaction + completes. This flow is sometimes known as "unattended transfer" or + "blind transfer". + + Figure 1 shows transfer when the Transferee utilizes a GRUU and + 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. + + + + + + + + + + + + + + + + + + + + + + + +Sparks, et al. Best Current Practice [Page 7] + +RFC 5589 SIP CC Transfer June 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 | |------------------->| + + Figure 1: Basic Transfer Call 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=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> + 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: 0 + + + +Sparks, et al. Best Current Practice [Page 9] + +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: 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=noresource + Content-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. Best Current Practice [Page 11] + +RFC 5589 SIP CC Transfer June 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 | |------------------->| + + Figure 2: Transfer with Dialog 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=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 + 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: 70 + To: <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 OK + +6.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. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sparks, et al. Best Current Practice [Page 15] + +RFC 5589 SIP CC Transfer June 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 |<-------------------| | + + Figure 3: Failed Transfer - Target Busy + + + + +Sparks, et al. Best Current Practice [Page 16] + +RFC 5589 SIP CC Transfer June 2009 + + +6.3.2. Transfer Target Does 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. Best Current Practice [Page 17] + +RFC 5589 SIP CC Transfer June 2009 + + + dialog1 |------------------->| | + | 200 OK | | + dialog1 |<-------------------| | + + Figure 4: Failed Transfer - Target Does Not Answer + +7. Transfer with Consultation Hold + + Transfer with consultation hold involves a session between the + Transferor and the Transfer Target before the transfer actually takes + place. This is implemented with SIP Hold and Transfer as described + above. + + A nice feature is for the Transferor to let the target know that the + session relates to an intended transfer. Since many UAs render the + display name in the From header field to the user, a consultation + INVITE could contain a string such as "Incoming consultation from + Transferor with intent to transfer Transferee", where the display + names of the transferor and transferee are included in the string. + +7.1. Exposing Transfer Target + + The Transferor places the Transferee on hold, establishes a call with + the Transfer Target to alert them to the impending transfer, + terminates the connection with the Transfer Target, then proceeds + with transfer as above. This variation can be used to provide an + experience similar to that expected by current PBX and Centrex users. + + 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. Best Current Practice [Page 18] + +RFC 5589 SIP CC Transfer June 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 | + | |<-------------------| + + Figure 5: Transfer with Consultation Hold - Exposing Transfer Target + +7.2. Protecting Transfer Target + + The Transferor places the Transferee on hold, establishes a call with + the Transfer Target and then reverses their roles, transferring the + original Transfer Target to the original Transferee. This has the + advantage of hiding information about the original Transfer Target + from the original Transferee. On the other hand, the Transferee's + experience is different than 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 the Transferee is receiving a new call + from the Transfer Target. Unless the Transferee's agent has a + reliable way to associate this new call with the call it already has + with the Transferor, it will have to alert the new call on another + appearance. If this, or some other call-waiting-like UI were not + + + +Sparks, et al. Best Current Practice [Page 19] + +RFC 5589 SIP CC Transfer June 2009 + + + available, the Transferee might be stuck returning a Busy-Here to the + Transfer Target, effectively preventing the transfer. There are many + ways that correlation could be provided. The dialog parameters could + be provided directly as header parameters in the Refer-To URI, for + example. The Replaces mechanism [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], + this is the Call-ID, To-tag, and From-tag. + + Note that the Transferee's agent emits a BYE to the Transferor's + agent as an immediate consequence of processing the Replaces header. + + The Transferor knows that both the Transferee and the Transfer Target + support the Replaces header from the Supported: replaces header + contained in the 200 OK responses from both. + + 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. Best Current Practice [Page 20] + +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: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 and target converse) + dialog4 | | BYE/200 OK | + | |------------------->| + + Figure 6: Transfer Protecting Transfer 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, gruu + 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=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, tdialog + Contact: <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: ... + +7.3. Attended Transfer + + The Transferor places the Transferee on hold, establishes a call with + the Transfer Target to alert them to the impending transfer, places + the target on hold, then proceeds with transfer using an escaped + Replaces header field in the Refer-To header. This is another common + service expected by current PBX and Centrex users. + + 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 Agent that does not + support Replaces from ignoring the Replaces and answering the INVITE + without a dialog match.) + + It is possible that proxy/service routing may prevent the triggered + INVITE from reaching the same User Agent. If this occurs, the + triggered invite will fail with a timeout, 403, 404, etc. error. The + Transferee MAY then retry the transfer with the Refer-To URI set to + the Contact URI. + + + + + + + + + + +Sparks, et al. Best Current Practice [Page 24] + +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, | + | 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 | + | |<-------------------| + + Figure 7: Attended Transfer Call 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> + 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 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> + Content-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. Recovery When One Party Does Not Support REFER + + If protecting or exposing the Transfer Target is not a concern, it is + possible to complete a transfer with consultation hold when only the + transferor and one other party support REFER. Note that a 405 Method + Not Allowed might be returned instead of the 501 Not Implemented + response. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sparks, et al. Best Current Practice [Page 28] + +RFC 5589 SIP CC Transfer June 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 | + | |------------------->| + + Figure 8: Recovery When One Party Does Not Support REFER + +7.5. Attended Transfer When Contact URI Is Not Known to Route to a + Unique User Agent + + It is a requirement of RFC 3261 that a Contact URI be globally + routable even outside the dialog. However, due to RFC 2543 User + Agents and some architectures (NAT/Firewall traversal, screening + proxies, 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 of attended transfer + shown in Figures 6, 7, and 8 SHOULD only be used if the Contact URI + is known to be routable outside the dialog. + + 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 | + | |<------------|-------------| + + Figure 9: Attended Transfer Call Flow with a Contact URI Not Known to + Be 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: 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: ... + + + 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: 0 + + + +Sparks, et al. Best Current Practice [Page 31] + +RFC 5589 SIP CC Transfer June 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 + the Transfer Target. As a result, the transfer is retried with the + Contact URI, 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. Best Current Practice [Page 32] + +RFC 5589 SIP CC Transfer June 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. Best Current Practice [Page 33] + +RFC 5589 SIP CC Transfer June 2009 + + + Figure 10: Attended Transfer Call Flow with Non-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%3D763231 + &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: 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 + 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 URI that 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 Transfer Target before + that session is established. Most frequently, that will be the end + of the scenario, but in some circumstances, the Transferor may wish + to proceed with the transfer action. For example, the Transferor may + wish to complete the transfer knowing that the Transferee will end up + eventually talking to the Transfer Target's 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 transfer + as an attended transfer even after the Transferor hangs up. Note + that media must be played to the Transfer Target upon answer -- + otherwise, the Target may hang up and the resulting transfer + operation will fail. + + + + + + + + + + + +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 | + | |<-------------------| + + Figure 11: Recommended Semi-Attended Transfer Call Flow + + Two other possible semi-attended transfer call flows are shown in + Figures 12 and 13. However, these call flows are NOT RECOMMENDED due + to race 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 the target. This can result in two race + conditions. One is that the target answers despite the CANCEL and + the resulting unattended transfer fails. This race condition can be + eliminated by the Transferor waiting to send the REFER until the 487 + response from the target is returned. Instead of a 487, a 200 OK may + be returned indicating that the target has answered the consultation + call. In this case, the call flow in Figure 13 must be followed. In + this flow, the Transferor must play some kind of media to the Target + to prevent the Target from hanging up, or the transfer will fail. + That is, the human at the Transfer Target will hear silence from when + they answer (message F1) until the transfer completes (F3 and they + are talking to the Transferee unless some media is played (F2)). + + 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. Best Current Practice [Page 39] + +RFC 5589 SIP CC Transfer June 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 | + | |<-------------------| + + Figure 12: Semi-Attended Transfer as Blind Transfer Call Flow (Not + Recommended) + + + + + + + + +Sparks, et al. Best Current Practice [Page 40] + +RFC 5589 SIP CC Transfer June 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. Best Current Practice [Page 41] + +RFC 5589 SIP CC Transfer June 2009 + + + Figure 13: Semi-Attended Transfer as Attended Transfer Call Flow (Not + Recommended) + +7.7. Attended Transfer Fallback to Basic Transfer + + In this flow, an attempted attended transfer fails so the Transferor + falls back to basic transfer. + + The call flow in Figure 14 shows the use of Require: replaces in the + INVITE sent by the Transferor to the Transfer Target in which the + Transferor's intention at the time of sending the INVITE to the + Transfer Target was known to be to 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 | + | |<-------------------| + + Figure 14: Attended Transfer Fallback to Basic Transfer 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 + Transferor determines, using OPTIONS, that the Transferee does + support REFER and Replaces. As a result, the Transferor begins the + attended transfer by placing the Transferee on hold and calling the + Transfer Target. Using an OPTIONS in dialog2, the Transferor + determines that the target does not support either REFER or Replaces, + + + + +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. + + Transferor Transferee Transfer + | | Target + | | | + dialog1 | INVITE/200 OK/ACK | | + |<-------------------| | + dialog1 | OPTIONS/200 OK | | + |------------------->| | + dialog1 | INVITE (hold)/200 OK/ACK | + |------------------->| | + dialog2 | INVITE/200 OK/ACK | | + |---------------------------------------->| + dialog2 | OPTIONS/200 OK | | + |---------------------------------------->| + dialog2 | BYE/200 OK | | + |---------------------------------------->| + dialog3 |REFER (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 | + | |<-------------------| + + Figure 15: Attended Transfer Fallback to Basic 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 of + the Referred-By header field in the REFER, which is then copied into + the triggered INVITE. However, a more secure mechanism involving the + Referred-By security token, which is generated and signed by the + Transferor and passed in a message body to the Transferee then to the + Transfer Target. + + The call flow in Figure 16 shows the Referred-By header field and + body in the REFER F5 and triggered INVITE F6. Note that the Secure/ + 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 | + | |<-------------------| + + Figure 16: Attended Transfer Call Flow with Referred-By + + + + + + + + + + + + + + + + +Sparks, et al. Best Current Practice [Page 46] + +RFC 5589 SIP CC Transfer June 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. Best Current Practice [Page 47] + +RFC 5589 SIP CC Transfer June 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. Best Current Practice [Page 48] + +RFC 5589 SIP CC Transfer June 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 an Ad 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 a + focus [RFC4579] and hosts an ad hoc conference involving Alice, Bob, + and Carol. Alice and Carol subscribe to the conference 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. Best Current Practice [Page 49] + +RFC 5589 SIP CC Transfer June 2009 + + + This call flow meets requirement 6 of Section 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. Best Current Practice [Page 50] + +RFC 5589 SIP CC Transfer June 2009 + + + | | 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. Best Current Practice [Page 51] + +RFC 5589 SIP CC Transfer June 2009 + + + |------------------->| | + | 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 | | + |------------------->| | + + Figure 17: Attended Transfer as an Ad Hoc Conference + +10. Transfer with Multiple Parties + + In this example, shown in Figure 18, the Originator places a call to + the Facilitator who reaches the Recipient through the Screener. The + Recipient's contact information is exposed to the Facilitator and the + Originator. This example is provided for clarification of the + semantics of the REFER method only, and 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 | | | + |<-----------| | | + 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" + + Figure 18: Transfer with Multiple Parties 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 some gateway-specific + issues that are documented in this section. While this discussion + focuses on the common cases involving Public 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 the Transferee + residing on the PSTN side of a SIP gateway. The Transferor is a SIP + phone purely in the IP space. The Transfer Target is on the PSTN + side of a SIP gateway as well. After completing the transfer, + (regardless of consultative or blind) the Transferee is in a call + with the Transfer Target (both on the PSTN side of a gateway). It is + often desirable to remove the gateway(s) out of the loop. This is + likely to only be possible if both legs of the target call are on the + same gateway. With both legs on the same gateway, it may be able to + invoke the analogous transfer on the PSTN side. Then the target call + would not involve the gateway. + + So the problem is how to give the proxy enough information so that it + knows to route the call to the same gateway. With a simple single + call that hairpins, the incoming and outgoing leg have the same + dialog. The proxy should have enough information to optimize the + routing. + + In the consultative transfer scenario, it is desirable to coerce the + consultative INVITE out the same gateway as the original call to be + transferred. However, there is no way to relate the consultation + with the original call. In the consultative case, the target call + + + +Sparks, et al. Best Current Practice [Page 54] + +RFC 5589 SIP CC Transfer June 2009 + + + INVITE includes the Replaces header, which contains dialog + information that can be used to relate it to the consultation. + However, there is no information that relates the target call to the + original. + + In the blind transfer scenario, it is desirable to coerce the target + call onto the same gateway as the original call. However, the same + problem exists in that the target-dialog cannot be related to the + original dialog. + + In either transfer scenario, it may be desirable to push the transfer + operation onto the non-SIP side of the gateway. Presumably, this is + not possible unless all of the legs go out the same gateway. If the + gateway supports more than one trunk 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. The Transferor initiates the consultation INVITE, the + Transferor gets impatient and hangs up, transitioning this to a blind + transfer. The Transfer Target on the gateway (connected through a + PSTN switch to a single line or dumb analog phone) rings. The user + answers the phone just after the CANCEL is received by the Transfer + Target. The REFER and INVITE for the target call are sent. The + Transferee attempts to set 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 + Section 7.6. + +12. Security Considerations + + The call transfer flows shown in this document are implemented using + the REFER and Replaces call control primitives in SIP. As such, the + 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 a Transfer 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. A User + Agent may use local policy or human intervention in deciding whether + or not to accept a REFER. In generating NOTIFY responses based on + the outcome of the triggered request, care should be taken in + constructing the message/sipfrag body to ensure that no private + information is leaked. + + An INVITE containing a Replaces header field SHOULD only be accepted + if it has been properly authenticated and authorized using standard + SIP mechanisms, and the requestor is authorized to perform dialog + replacement. 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. + +13. Acknowledgments + + This document is a collaborative product of the SIP working group. + Thanks to Rohan Mahy for his input on the use of Replaces in + transfer. + +14. References + +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. + + [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. + +14.2. Informative References + + [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)", + Work in Progress, March 2009. + + [RFC4353] Rosenberg, J., "A Framework for Conferencing with the + Session Initiation Protocol (SIP)", 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. + + [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session + Initiation Protocol (SIP) Event Package for Conference + State", RFC 4575, August 2006. + + [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol + (SIP) Call Control - Conferencing for User Agents", + BCP 119, RFC 4579, 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. Best Current Practice [Page 57] + +RFC 5589 SIP CC Transfer June 2009 + + +Authors' Addresses + + Robert Sparks + Tekelec + 17210 Campbell Road + Suite 250 + Dallas, Texas 75252 + USA + + EMail: RjS@nostrum.com + + + Alan Johnston (editor) + Avaya + St. Louis, MO + + EMail: alan@sipstation.com + + + Daniel Petrie + SIPez LLC + Arlington, MA 02476 + US + + Phone: +1 617 273 4000 + EMail: dan.ietf@SIPez.com + URI: http://www.SIPez.com/ + + + + + + + + + + + + + + + + + + + + + + + + +Sparks, et al. Best Current Practice [Page 58] + |