summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5589.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc5589.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc5589.txt')
-rw-r--r--doc/rfc/rfc5589.txt3251
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]
+