GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:bcp:bcp149

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: ...
  1. -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"
  1. —–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"
  1. —–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>
  1. —–590F24D439B31E08745DEF0CD9397189–
  1. -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: ...
  1. -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

  1. -my-boundary-9

Content-Length: 2961

 Content-Type: multipart/signed;
              protocol="application/pkcs-7-signature";
              micalg=sha1;
              boundary="----590F24D439B31E08745DEF0CD9397189"
  1. —–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"
  1. —–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>
  1. —–590F24D439B31E08745DEF0CD9397189–
  1. -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]

/data/webs/external/dokuwiki/data/pages/rfc/bcp/bcp149.txt · Last modified: 2009/06/26 17:49 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki