view Side-By-Side changes

Internet-Draft                                               dynamicsoft
Expires: August 15, 2004 April 21, 2005                                      A. Johnston
                                                                     MCI
                                                       February 15,
                                                               D. Petrie
                                                           Pingtel Corp.
                                                        October 21, 2004



          Session Initiation Protocol Call Control - Transfer
                   draft-ietf-sipping-cc-transfer-02
                   draft-ietf-sipping-cc-transfer-03


Status of this Memo


   This document is an Internet-Draft and is in full conformance with subject to all provisions
   of Section 10 section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of RFC2026.
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."


   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.
   http://www.ietf.org/ietf/1id-abstracts.txt.


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


   This Internet-Draft will expire on August 15, 2004. April 21, 2005.


Copyright Notice


   Copyright (C) The Internet Society (2004). All Rights Reserved.


Abstract


   This document describes providing Call Transfer capabilities in the
   Session Initiation Protocol (SIP). This work is part of the  SIP
   Multiparty Call Control Framework.











Sparks & Johnston extensions such as REFER and
   Replaces are used to provide a number of transfer services including
   blind transfer, consultative transfer, and attended transfer.  This




Sparks, et al.           Expires August 15, 2004 April 21, 2005                 [Page 1]
Internet-Draft              SIP CC Transfer                February                 October 2004



   work is part of the SIP multiparty call control framework.


Table of Contents


   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Actors and Roles . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Using REFER to achieve Call Transfer . . . . . . . . . . . . .  4
   5.  Basic Transfer . . . . . . . . . . . . . . . . . . . . . . .  5 .  6
     5.1   Successful Transfer  . . . . . . . . . . . . . . . . . . . .  6
     5.2   Failed   Transfer without a GRUU  . . . . . . . . . . . . . . . . . 10
     5.3   Failed Transfer  . . . . . . . .  9
   5.2.1 Target Busy . . . . . . . . . . . . . 13
       5.3.1   Target Busy  . . . . . . . . . . .  9
   5.2.2 . . . . . . . . . . 13
       5.3.2   Transfer Target does not answer  . . . . . . . . . . . . . . 10 14
   6.  Transfer with Consultation Hold  . . . . . . . . . . . . . . 11 . 15
     6.1   Exposing transfer target . . . . . . . . . . . . . . . . . . 11 15
     6.2   Protecting transfer target . . . . . . . . . . . . . . . . . 13 16
     6.3   Attended Transfer  . . . . . . . . . . . . . . . . . . . . . 16 20
     6.4   Recovery when one party does not support REFER . . . . . . . 19 24
     6.5   Attended Transfer when Contact URI is Not Globally
         Routable not a GRUU . . . . . 25
     6.6   Semi-Attended Transfer . . . . . . . . . . . . . . . . . . 32
     6.7   Attended Transfer Fallback to Basic Transfer . . . . 20
   6.6   Aborting a Consultation Hold . . . 36
   7.  Transfer with Referred-By  . . . . . . . . . . . . . 24
   6.7   Attended Transfer Fallback to Basic . . . . . 38
   8.  Transfer as an Ad-Hoc Conference . . . . . . . . 24
   7. . . . . . . . 44
   9.  Transfer with Referred-By  . multiple parties . . . . . . . . . . . . . . . . 26
   8. 47
   10.   Gateway Transfer with multiple parties Issues  . . . . . . . . . . . . . . . 31
   9. . . . 49
     10.1  Coerce Gateway Hairpins to the Same Gateway  . . . . . . . 49
     10.2  Consultative Turned Blind Gateway Glare  . . . . . . . . . 50
   11.   Changes from draft-sipping-cc-transfer-02  . . . . . . . . . 50
   12.   Changes from draft-sipping-cc-transfer-01  . . . . . . . . . 33
   10. 50
   13.   Changes from draft-sipping-cc-transfer-00  . . . . . . . . . 33
   11. 50
   14.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 33
   12. 51
   15.   Security Considerations  . . . . . . . . . . . . . . . . . . 33
   13. 51
   16.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 33
         Normative 51
   17.   References . . . . . . . . . . . . . . . . . . . . 34
         Informative References . . . . . 51
   17.1  Normative References . . . . . . . . . . . . . . 34
         Authors' Addresses . . . . . . 51
   17.2  Informative References . . . . . . . . . . . . . . . 34
         Intellectual Property and Copyright Statements . . . . 52
       Authors' Addresses . . . 36




















Sparks & Johnston . . . . . . . . . . . . . . . . . . . 52
       Intellectual Property and Copyright Statements . . . . . . . . 54













Sparks, et al.           Expires August 15, 2004 April 21, 2005                 [Page 2]
Internet-Draft              SIP CC Transfer                February                 October 2004



1.  Overview


   This document describes providing Call Transfer capabilities and
   requirements in SIP [1].  This work is part of the Multiparty Call
   Control Framework [6].


   The mechanisms discussed here are most closely related to traditional
   basic and consultation hold transfers.


   This document does not discuss
   transfer scenarios involving ad-hoc conferences (where all parties
   involved are briefly in a conference until this transferor drops
   out).

   This document details the use of REFER method [2] and Replaces [3]
   header field to achieve call transfer.


   A user agent that fully supports the transfer mechanisms described in
   this document MUST support REFER[2] and Replaces[3] in addition to
   RFC 3261 [1].  A user agent SHOULD support GRUU[5].


2.  Actors and Roles


   There are three actors in a given transfer event, each playing one of
   the following roles:


        Transferee -      the party being transferred to the Transfer
                          Target.


        Transferor -      the party initiating the transfer


        Transfer Target - the new party being introduced into a call with
                          the Transferee.


   The following roles are used to describe transfer requirements and
   scenarios:


        Originator -  wishes to place a call to the Recipient. This actor
                      is the source of the first INVITE in a session, to
                      either a Facilitator or a Screener.


        Facilitator - receives a call or out-of-band request from the
                      Originator, establishes a call to the Recipient
                      through the Screener, and connects the Originator to
                      the Recipient.


        Screener -    receives a call ultimately intended for the Recipient
                      and transfers the calling party to the Recipient if
                      appropriate.




Sparks & Johnston       Expires August 15, 2004                 [Page 3]

Internet-Draft              SIP CC Transfer                February 2004


        Recipient -   the party the Originator is ultimately connected to.






Sparks, et al.           Expires April 21, 2005                 [Page 3]
Internet-Draft              SIP CC Transfer                 October 2004



3.  Requirements


   1.  Any party in a SIP session MUST be able to transfer any other
       party in that session at any point in that session.
   2.  The Transferor and the Transferee MUST NOT be removed from a
       session as part of a transfer transaction.


             At first glance, requirement 2 may seem to indicate
             that the user experience in a transfer must be
             significantly different from what a current PBX or
             Centrex user expects. As the call-flows in this
             document show, this is not the case. A client MAY
             preserve the current experience. In fact, without
             this requirement, some forms of the current
             experience (ringback on transfer failure
             for instance) will be lost.


   3.  The Transferor MUST know whether or not the transfer was
       successful (this is significantly different from the requirements
       of the earlier BYE-Also approach to transfer).
       successful.
   4.  The Transferee MUST be able to replace an existing dialog with a
       new dialog.
   5.  The Transferor and Transferee SHOULD indicate their support for
       the primitives required to achieve transfer.
   6.  The Transferor SHOULD provide the Transfer Target and Transferee
       with information about the nature and progress of the transfer
       operation being attempted.



             To meet this requirement, the transfer operation can
             be modeled as an ad-hoc conference between three
             parties, as discussed in Section 8.



4.  Using REFER to achieve Call Transfer


   A REFER [2] can be issued by the Transferor to cause the Transferee
   to issue an INVITE to the Transfer-Target.  Note that a successful
   REFER transaction does not terminate the session between the
   Transferor and the Transferee.  If those parties wish to terminate
   their session, they must do so with a subsequent BYE request.  The
   media negotiated between the transferee and the transfer target is
   not affected by the media that had been negotiated between the
   transferor and the transferee.  In particular, the INVITE issued by
   the Transferee will have the same SDP body it would have if he
   Transferee had initiated that INVITE on its own.  Further, the
   disposition of the media streams between the Transferor and the
   Transferee is not altered by the REFER method.





Sparks, et al.           Expires April 21, 2005                 [Page 4]
Internet-Draft              SIP CC Transfer                 October 2004



   Agents may alter a session's media through additional signaling.  For
   example, they may make use of the SIP hold re-INVITE [1] or the
   conferencing extensions
   provided by this framework.






Sparks & Johnston       Expires August 15, 2004                 [Page 4]

Internet-Draft              SIP CC Transfer                February 2004


5. Basic Transfer

   Basic Transfer consists of described in the Transferor providing conferencing framework [8].


   To perform the Transfer
   Target's contact to transfer, the Transferee. The Transferee attempts transferor and transferee could reuse an
   existing dialog established by an INVITE to
   establish send the REFER.  This
   would result in a session using that contact single dialog shared by two uses - an invite usage
   and reports a subscription usage.  The call flows for this are shown in
   detail in Section 5.2.  However, the results of
   that attempt approach described in this
   document is to the Transferor. avoid dialog reuse.  The signaling relationship between issues and difficulties
   associated with dialog reuse are described in [11].


   Prior to the Transferor development of GRUUs and Transferee is not terminated, so the call is
   recoverable if the Transfer Target cannot be reached. Note that use of grid parameters, the
   Transfer Target's contact information has been exposed
   reasons to reuse the
   Transferee. The provided contact can be used existing dialog included:
   1.  There was no way to make ensure that a REFER on a new calls in dialog would
       reach the
   future.

   The participants particular endpoint involved in a basic transfer should indicate support for the
   REFER transfer.  Many
       factors, including details of implementations and NOTIFY methods in Allow header fields changes in INVITE, 200 OK to
   INVITE,
       proxy routing between an INVITE and OPTIONS.

   The diagrams below show indicate the first line of each message. The
   first column of the figure shows the Call-ID used in that particular
   message. In these diagrams, media is managed through re-INVITE holds,
   but other mechanisms (mixing multiple media streams at a REFER could cause the UA or
   using REFER
       to be sent to the conferencing extensions for example) are valid.  Selected
   message details are shown labeled as message F1, F2, etc.

   Each of wrong place.  Sending the flows below shows REFER down the
       existing dialog between ensured it got to the Transferor and endpoint we were already
       talking to.
   2.  It was unclear how to associate an existing invite usage with a
       REFER arriving on a new dialog, where it was completely obvious
       what the Transferee remaining connected (on hold) during association was when the REFER
   process. While this provides came on the greatest flexibility invite
       usage's dialog.
   3.  There were concerns with authorizing out-of-dialog REFERs.  The
       authorization policy for recovery
   from failure, it is not necessary. If REFER in most implementations piggybacks
       on the Transferor's agent does not
   wish to participate authorization policy for INVITE (which is, in most cases,
       based simply on "I placed or answered this call").


   GRUUs [5] have been defined specifically to address problem 1.
   Problem 2 can be addressed using a GRUU's grid parameter.  In the remainder of
   immediate term, this solution to problem 2 allows the existing REFER process and has
   authorization policy to be reused.


   As a result, if the Transferee is using a GRUU, the REFER SHOULD be
   sent in a new dialog.  If the nature of the Contact URI is not known,
   the REFER should be sent inside the existing dialog.  This is because
   there is no
   intention current way for an out of assisting dialog REFER to be associated
   with recovery from transfer failure, it could
   emit a BYE to particular dialog, unless a GRUU is present.


   In most of the following examples, the Transferor is in the
   atlanta.example.com domain, the Transferee as soon as is in the REFER transaction
   completes. This flow
   biloxi.example.com, and the Transfer Target is sometimes known as "unattended transfer".




















Sparks & Johnston in the
   chicago.example.com domain.







Sparks, et al.           Expires August 15, 2004 April 21, 2005                 [Page 5]
Internet-Draft              SIP CC Transfer                February                 October 2004


5.1 Successful



5.  Basic Transfer


   Basic Transfer consists of the Transferor providing the Transfer
   Target's contact to the Transferee.  The Transferee attempts to
   establish a session using that contact and reports the results of
   that attempt to the Transferor.  The signaling relationship between
   the Transferor and Transferee is not terminated, so the call is
   recoverable if the Transfer
                   |                    | Target
                   |            INVITE  |                    |
         Call-ID:1 |<-------------------|                    |
                   |            200 OK  |                    |
         Call-ID:1 |------------------->|                    |
                   |            ACK     |                    |
         Call-ID:1 |<-------------------|                    |
                   |  INVITE (hold)     |                    |
         Call-ID:1 |------------------->|                    |
                   | cannot be reached.  Note that the
   Transfer Target's contact information has been exposed to the
   Transferee.  The provided contact can be used to make new calls in
   the future.


   The participants in a basic transfer should indicate support for the
   REFER and NOTIFY methods in Allow header fields in INVITE, 200 OK to
   INVITE, and OPTIONS messages.


   The diagrams below show the first line of each message.  The first
   column of the figure shows the Call-ID used in that particular
   message.  In these diagrams, media is managed through re-INVITE
   holds, but other mechanisms (mixing multiple media streams at the UA
   or using the conferencing extensions for example) are valid.
   Selected message details are shown labeled as message F1, F2, etc.


   Each of the flows below shows the dialog between the Transferor and
   the Transferee remaining connected (on hold) during the REFER
   process.  While this provides the greatest flexibility for recovery
   from failure, it is not necessary.  If the Transferor's agent does
   not wish to participate in the remainder of the REFER process and has
   no intention of assisting with recovery from transfer failure, it
   could emit a BYE to the Transferee as soon as the REFER transaction
   completes.  This flow is sometimes known as "unattended transfer" or
   "blind transfer".


   Figure 1 shows transfer when the Transferee utilizes a GRUU and
   indicates this to the Transferor.  As a result, the Transferor sends
   the REFER outside the INVITE dialog.  The Transferee is able to match
   this REFER to the existing dialog using the grid parameter in the
   Request-URI.


             Note that if the Transferee uses the same grid
             across multiple unrelated dialogs, then some
             other explicit dialog identifier will need to
             be carried in the REFER in order for this to work.



5.1  Successful Transfer






Sparks, et al.           Expires April 21, 2005                 [Page 6]
Internet-Draft              SIP CC Transfer                 October 2004



              Transferor           Transferee             Transfer
                   |                    |                  Target
                   |          INVITE F1 |                    |
         Call-ID:1 |<-------------------|                    |
                   |  ACK               |                    |
         Call-ID:1 |------------------->| |<-------------------|                    |
                   |  REFER F1          200 OK F2 |                    |
         Call-ID:1 |------------------->|                    |
                   |  202 Accepted            ACK     |                    |
         Call-ID:1 |<-------------------|                    |
                   | NOTIFY (100 Trying) F2  INVITE (hold)     |                    |
         Call-ID:1 |<-------------------| |------------------->|                    |
                   |  200 OK            |                    |
         Call-ID:1 |------------------->| |<-------------------|                    |
                   |  ACK               |                    |  INVITE
         Call-ID:1 |------------------->|                    |
                   |  REFER F3          |
         Call-ID:2                    |
         Call-ID:2 |------------------->|                    |
                   |  202 Accepted      |                    |
         Call-ID:2 |<-------------------|                    |
                   | NOTIFY (100 Trying) F4                  |
         Call-ID:2 |<-------------------|                    |
                   |            200 OK  |                    |
         Call-ID:2 |------------------->|                    |
                   |                    |  INVITE F5         |
         Call-ID:3 |                    |------------------->|
                   |                    |  200 OK            |
         Call-ID:3 |                    |<-------------------|
                   |                    |  ACK               |
         Call-ID:2
         Call-ID:3 |                    |------------------->|
                   |  NOTIFY (200 OK) F4| F6|                    |
         Call-ID:1
         Call-ID:2 |<-------------------|                    |
                   |            200 OK  |                    |
         Call-ID:1
         Call-ID:2 |------------------->|                    |
                   |  BYE               |                    |
         Call-ID:1 |------------------->|                    |
                   |  200 OK            |                    |
         Call-ID:1 |<-------------------|                    |
                   |                    |             BYE    |
         Call-ID:2
         Call-ID:3 |                    |<-------------------|
                   |                    |             200 OK |
         Call-ID:2
         Call-ID:3 |                    |------------------->|


    Figure 1.  Basic Transfer Call Flow.



   F1 REFER Transferor -> INVITE Transferee



Sparks & Johnston -> Transferor


   INVITE sips:transferor@atlanta.example.com SIP/2.0
   Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432




Sparks, et al.           Expires August 15, 2004 April 21, 2005                 [Page 6] 7]
Internet-Draft              SIP CC Transfer                February                 October 2004



   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:3k3k3ld812adkjw@biloxi.example.com;grid=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
   Contact: <sips:4889445d8kjtk3@atlanta.example.com;grid=723jd2d>
   Content-Type: application/sdp
   Content-Length: ...



   F3 REFER Transferor -> Transferee


   REFER sip:transferee@192.0.2.4 sips:3k3k3ld812adkjw@biloxi.example.com;grid=3413kj2ha SIP/2.0
   Via: SIP/2.0/UDP SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKna9
   Max-Forwards: 70
   To: <sip:transferee@biloxi.example.com>;tag=a6c85cf <sips:3k3k3ld812adkjw@biloxi.example.com;grid=3413kj2ha>
   From: <sip:transferor@atlanta.example.com>;tag=1928301774 <sips:transferor@atlanta.example.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314159 REFER
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: gruu, replaces
   Refer-To: <sip:transfertarget@chicago.example.com> <sips:transfertarget@chicago.example.com>
   Contact: <sip:transferor@pc33.atlanta.example.com> <sips:4889445d8kjtk3@atlanta.example.com;grid=723jd2d>
   Content-Length: 0


   F2



   F4 NOTIFY Transferee -> Transferor


   NOTIFY sip:transferor@pc33.atlanta.com sips:4889445d8kjtk3@atlanta.example.com;grid=723jd2d SIP/2.0
   Via: SIP/2.0/UDP SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
   Max-Forwards: 70




Sparks, et al.           Expires April 21, 2005                 [Page 8]
Internet-Draft              SIP CC Transfer                 October 2004



   To: <sip:transferor@atlanta.example.com>;tag=1928301774 <sips:transferor@atlanta.example.com>;tag=1928301774
   From: <sip:transferee@biloxi.example.com>;tag=a6c85cf <sips:3k3k3ld812adkjw@biloxi.example.com;grid=3413kj2ha>
    ;tag=a6c85cf
   Call-ID: a84b4c76e66710
   CSeq: 73 NOTIFY
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: replaces
   Event: refer
   Subscription-State: active;expires=60
   Content-Type: message/sipfrag
   Content-Length: ...


   SIP/2.0 100 Trying


   F3



   F5 INVITE Transferee -> Transfer Target


   INVITE sip:transfertarget@chicago.example.com sips:transfertarget@chicago.example.com SIP/2.0
   Via: SIP/2.0/UDP SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas41234
   Max-Forwards: 70
   To: <sip:transfertarget@chicago.example.com> <sips:transfertarget@chicago.example.com>
   From: <sip:transferee@biloxi.example.com>;tag=j3kso3iqhq <sips:transferee@biloxi.example.com>;tag=j3kso3iqhq
   Call-ID: 90422f3sd23m4g56832034
   CSeq: 521 REFER
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: replaces replaces, gruu
   Contact: <sip:transferee@192.0.2.4> <sips:3k3k3ld812adkjw@biloxi.example.com;grid=3413kj2ha>
   Content-Type: application/sdp
   Content-Length: ...




Sparks & Johnston       Expires August 15, 2004                 [Page 7]

Internet-Draft              SIP CC Transfer                February 2004


   F4



   F6 NOTIFY Transferee -> Transferor


   NOTIFY sip:transferor@pc33.atlanta.com sips:4889445d8kjtk3@atlanta.example.com;grid=723jd2d SIP/2.0
   Via: SIP/2.0/UDP SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
   Max-Forwards: 70
   To: <sip:transferor@atlanta.example.com>;tag=1928301774 <sips:transferor@atlanta.example.com>;tag=1928301774
   From: <sip:transferee@biloxi.example.com>;tag=a6c85cf <sips:3k3k3ld812adkjw@biloxi.example.com;grid=3413kj2ha>
    ;tag=a6c85cf
   Call-ID: a84b4c76e66710
   CSeq: 74 NOTIFY
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: replaces
   Event: refer
   Subscription-State: terminated;reason=noresource
   Content-Type: message/sipfrag
   Content-Length: ...

   SIP/2.0 200 OK


































Sparks & Johnston





Sparks, et al.           Expires August 15, 2004 April 21, 2005                 [Page 8] 9]
Internet-Draft              SIP CC Transfer                February                 October 2004



   SIP/2.0 200 OK




5.2 Failed  Transfer

   This section shows examples of failed transfer attempts.  After the
   transfer failure occurs, the Transferor takes without a GRUU


   In this scenario, the Transferee off hold
   and resumes does not support GRUU, as a result,
   the session.

5.2.1 Target Busy REFER is sent inside the INVITE dialog.


              Transferor           Transferee             Transfer
                   |                    |                  Target
                   |                    |                    |
                   |         INVITE F1  |                    |
         Call-ID:1 |<-------------------|                    |
                   |         200 OK F2  |                    |
         Call-ID:1 |------------------->|                    |
                   |            ACK     |                    |
         Call-ID:1 |<-------------------|                    |
                   |  INVITE (hold)     |                    |
         Call-ID:1 |------------------->|                    |
                   |  200 OK            |                    |
         Call-ID:1 |<-------------------|                    |
                   |  ACK               |                    |
         Call-ID:1 |------------------->|                    |
                   |  REFER F3          |                    |
         Call-ID:1 |------------------->|                    |
                   |  202 Accepted      |                    |
         Call-ID:1 |<-------------------|                    |
                   | NOTIFY (100 Trying)| Trying) F4                  |
         Call-ID:1 |<-------------------|                    |
                   |            200 OK  |                    |
         Call-ID:1 |------------------->|                    |
                   |                    |  INVITE F5         |
         Call-ID:2 |                    |------------------->|
                   |                    |  486 Busy Here  200 OK            |
         Call-ID:2 |                    |<-------------------|
                   |                    |  ACK               |
         Call-ID:2 |                    |------------------->|
                   |  NOTIFY (503 Service Unavailable) (200 OK) F6|                    |
                   | or NOTIFY (486 Busy Here)               |
         Call-ID:1 |<-------------------|                    |
                   |            200 OK  |                    |
         Call-ID:1 |------------------->|                    |
                   |  INVITE (unhold)   |                    |
         Call-ID:1 |------------------->|
         Call-ID:1 |<-------------------|                    |
                   |            200 OK  |                    |
         Call-ID:1 |<-------------------|                    |
                   |  ACK               |                    |



Sparks & Johnston       Expires August 15, 2004                 [Page 9]

Internet-Draft              SIP CC Transfer                February 2004


         Call-ID:1 |------------------->|                    |
                   |  BYE               |                    |
         Call-ID:1 |------------------->|                    |
                   |  200 OK            |                    |
         Call-ID:1 |<-------------------|                    |

    Figure 2. Failed Transfer - Target Busy

5.2.2 Transfer Target does not answer


              Transferor           Transferee             Transfer
                   |                    |                  Target
                   |            INVITE  |                    |
         Call-ID:1 |<-------------------|                    |
                   |            200 OK  |                    |
         Call-ID:1 |------------------->|                    |
                   |            ACK     |                    |
         Call-ID:1 |<-------------------|                    |
                   |  INVITE (hold)     |                    |
         Call-ID:1 |------------------->|                    |
                   |  200 OK            |                    |
         Call-ID:1 |<-------------------|                    |
                   |  ACK               |                    |
         Call-ID:1 |------------------->|                    |
                   |  REFER             |                    |
         Call-ID:1 |------------------->|                    |
                   |  202 Accepted      |                    |
         Call-ID:1 |<-------------------|                    |
                   | NOTIFY (100 Trying)|                    |
         Call-ID:1 |<-------------------|                    |
                   |            200 OK  |                    |
         Call-ID:1 |------------------->|                    |
                   |                    |  INVITE            |
         Call-ID:2 |                    |------------------->|
                   |                    |  180 Ringing             BYE    |
         Call-ID:2 |                    |<-------------------|
                   |                    |   (Transferee gets tired of waiting)
                   |                    |  CANCEL            |
         Call-ID:2 |                    |------------------->|
                   |                    |             200 OK (CANCEL)   |
         Call-ID:2 |                    |<-------------------|
                   |                    |  487 Request Cancelled (INVITE)
         Call-ID:2 |                    |<-------------------|
                   |                    |  ACK               |
         Call-ID:2 |                    |------------------->|
                   |    NOTIFY (487 Request Cancelled)       |
         Call-ID:1 |<-------------------| |



Sparks & Johnston




Sparks, et al.           Expires August 15, 2004 April 21, 2005                [Page 10]
Internet-Draft              SIP CC Transfer                February                 October 2004



         Call-ID:2 |            200 OK  |                    |
         Call-ID:1                    |------------------->|                    |
                   |


   Figure 2.  Transfer without a GRUU.



   F1 INVITE (unhold)   |                    |
         Call-ID:1 |------------------->|                    |
                   | 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            |                    |
         Call-ID:1 |<-------------------|                    |
                   |  ACK               | 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;grid=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>




Sparks, et al.           Expires April 21, 2005                [Page 11]
Internet-Draft              SIP CC Transfer                 October 2004



   Contact: <sips:4889445d8kjtk3@atlanta.example.com;grid=723jd2d>
   Content-Length: 0



   F4 NOTIFY Transferee -> Transferor


   NOTIFY sips:4889445d8kjtk3@atlanta.example.com;grid=723jd2d SIP/2.0
   Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
   Max-Forwards: 70
   To: <sips:transferor@atlanta.example.com>;tag=31kdl4i3k
   From: <sips:transferee@biloxi.example.com>;tag=7553452
   Call-ID: 090459243588173445
   CSeq: 29888 INVITE
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: replaces
   Event: refer
   Subscription-State: active;expires=60
   Content-Type: message/sipfrag
   Content-Length: ...


   SIP/2.0 100 Trying



   F5 INVITE Transferee -> Transfer Target


   INVITE sips:transfertarget@chicago.example.com SIP/2.0
   Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas41234
   Max-Forwards: 70
   To: <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: ...



   F6 NOTIFY Transferee -> Transferor


   NOTIFY sips:4889445d8kjtk3@atlanta.example.com;grid=723jd2d SIP/2.0
   Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
   Max-Forwards: 70
   To: <sips:transferor@atlanta.example.com>;tag=31kdl4i3k
   From: <sips:transferee@biloxi.example.com>;tag=7553452
   Call-ID: 090459243588173445
   CSeq: 29889 INVITE




Sparks, et al.           Expires April 21, 2005                [Page 12]
Internet-Draft              SIP CC Transfer                 October 2004



   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: replaces
   Event: refer
   Subscription-State: terminated;reason=noresource
   Content-Type: message/sipfrag
   Content-Length: ...


   SIP/2.0 200 OK




5.3  Failed Transfer


   This section shows examples of failed transfer attempts.  After the
   transfer failure occurs, the Transferor takes the Transferee off hold
   and resumes the session.


5.3.1  Target Busy



              Transferor           Transferee             Transfer
                   |                    |                  Target
                   |                    |                    |
                   |            INVITE  |                    |
         Call-ID:1 |<-------------------|                    |
                   |            200 OK  |                    |
         Call-ID:1 |------------------->|                    |
                   |  BYE            ACK     |                    |
         Call-ID:1 |<-------------------|                    |
                   |  INVITE (hold)     |                    |
         Call-ID:1 |------------------->|                    |
                   |  200 OK            |                    |
         Call-ID:1 |<-------------------|                    |

    Figure 3. Failed Transfer - Target Does Not Answer.

6. Transfer with Consultation Hold

   Transfer with Consultation Hold involves a session between the
   transferor and the transfer target before the transfer actually takes
   place. This is implemented with SIP Hold and Transfer as described
   above.

6.1 Exposing transfer target

   The transferor places the transferee on hold, establishes a call with
   the transfer target to alert them to the impending transfer,
   terminates the connection with the transfer target, then proceeds
   with transfer as above. This variation can be used to provide an
   experience similar to that expected by current PBX and Centrex users.

   To (hopefully) improve clarity, non-REFER transactions have been
   collapsed into one indicator with the arrow showing the direction of
   the request.


















Sparks & Johnston       Expires August 15, 2004                [Page 11]

Internet-Draft              SIP CC Transfer                February 2004


              Transferor           Transferee             Transfer
                   |                    |                  Target
                   |  ACK               |                    |
         Call-ID:1 |------------------->|                    | INVITE/200 OK/ACK
                   |  REFER             |
                   |<-------------------|                    |
         Call-ID:1
         Call-ID:2 |------------------->|                    | INVITE (hold)/200 OK/ACK
                   |
                   |------------------->|  202 Accepted      |                    |
         Call-ID:2 |<-------------------|                    | INVITE/200 OK/ACK
                   | NOTIFY (100 Trying)|                    |
                   |---------------------------------------->|
         Call-ID:2 |<-------------------|                    | BYE/200
                   |            200 OK  |                    |
                   |---------------------------------------->|
         Call-ID:1
         Call-ID:2 |------------------->|                    | REFER
                   |                    |  INVITE            |
         Call-ID:3 |                    |------------------->|
                   |
         Call-ID:1                    | 202 Accepted  486 Busy Here     |
         Call-ID:3 |                    |<-------------------|
                   |
         Call-ID:1                    |  ACK               |




Sparks, et al.           Expires April 21, 2005                [Page 13]
Internet-Draft              SIP CC Transfer                 October 2004



         Call-ID:3 |                    |------------------->|
                   |    NOTIFY (100 Trying)| (503 Service Unavailable)     |
                   | or NOTIFY (486 Busy Here)               |
         Call-ID:2 |<-------------------|                    |
         Call-ID:1
                   |            200 OK  |                    |
         Call-ID:2 |------------------->|                    |
         Call-ID:3 |
                   |  INVITE/200 OK/ACK  INVITE (unhold)   |                    |                    |------------------->|
         Call-ID:1 |------------------->|                    | NOTIFY (200 OK)
                   |  200 OK            |                    |
         Call-ID:1 |<-------------------|                    |
         Call-ID:1
                   |            200 OK  ACK               |                    |
         Call-ID:1 |------------------->|                    |
         Call-ID:1
                   | BYE/200 OK  BYE               |                    |
         Call-ID:1 |------------------->|                    |
         Call-ID:3 |
                   |         BYE/200  200 OK            |                    |
         Call-ID:1 |<-------------------|                    |


    Figure 4. 3.  Failed Transfer with Consultation Hold - Exposing Target Busy


5.3.2  Transfer
   Target.



















Sparks & Johnston       Expires August 15, 2004 Target does not answer



              Transferor           Transferee             Transfer
                   |                    |                  Target
                   |            INVITE  |                    |
         Call-ID:1 |<-------------------|                    |
                   |            200 OK  |                    |
         Call-ID:1 |------------------->|                    |
                   |            ACK     |                    |
         Call-ID:1 |<-------------------|                    |
                   |  INVITE (hold)     |                    |
         Call-ID:1 |------------------->|                    |
                   |  200 OK            |                    |
         Call-ID:1 |<-------------------|                    |
                   |  ACK               |                    |
         Call-ID:1 |------------------->|                    |
                   |  REFER             |                    |
         Call-ID:2 |------------------->|                    |
                   |  202 Accepted      |                    |
         Call-ID:2 |<-------------------|                    |
                   | NOTIFY (100 Trying)|                    |
         Call-ID:2 |<-------------------|                    |
                   |            200 OK  |                    |
         Call-ID:2 |------------------->|                    |
                   |                    |  INVITE            |
         Call-ID:3 |                    |------------------->|
                   |                    |  180 Ringing       |
         Call-ID:3 |                    |<-------------------|




Sparks, et al.           Expires April 21, 2005                [Page 12] 14]
Internet-Draft              SIP CC Transfer                February                 October 2004


6.2 Protecting transfer target

   The transferor places the transferee on hold, establishes a call



                   |          (Transferee gets tired of waiting)
                   |                    |  CANCEL            |
         Call-ID:3 |                    |------------------->|
                   |                    |  200 OK (CANCEL)   |
         Call-ID:3 |                    |<-------------------|
                   |                    |  487 Request Cancelled (INVITE)
         Call-ID:3 |                    |<-------------------|
                   |                    |  ACK               |
         Call-ID:3 |                    |------------------->|
                   |    NOTIFY (487 Request Cancelled)       |
         Call-ID:2 |<-------------------|                    |
                   |            200 OK  |                    |
         Call-ID:2 |------------------->|                    |
                   |  INVITE (unhold)   |                    |
         Call-ID:1 |------------------->|                    |
                   |  200 OK            |                    |
         Call-ID:1 |<-------------------|                    |
                   |  ACK               |                    |
         Call-ID:1 |------------------->|                    |
                   |  BYE               |                    |
         Call-ID:1 |------------------->|                    |
                   |  200 OK            |                    |
         Call-ID:1 |<-------------------|                    |


    Figure 4.  Failed Transfer - Target Does Not Answer.


6.  Transfer with Consultation Hold


   Transfer with Consultation Hold involves a session between the transfer target
   transferor and then reverses their roles, transferring the
   original transfer target to before the original transferee. transfer actually takes
   place.  This has the
   advantage of hiding information about the original transfer target
   from the original transferee. On the other hand, the Transferee's
   experience is different that in current systems. The Transferee implemented with SIP Hold and Transfer as described
   above.


   A nice feature is
   effectively "called back" by for the Transfer Target.

   One of transferor to let the problems with this simplest implementation of a target
   protecting transfer is know that the transferee is receiving a new call
   from the transfer-target. Unless the transferee's agent has a
   reliable way
   session relates to associate this new call with an intended transfer.  Since many UAs render the call it already has
   with
   display name in the transferor, it will have From header field to alert the new call on another
   appearance. If this, or some other call-waiting-like UI were not
   available, the transferee might be stuck returning user, a Busy-Here consultation
   INVITE could contain a string such as "Incoming consultation from
   Transferor with intent to the transfer target, effectively preventing Transferee", where the transfer. There display
   names of the transferor and transferee are many
   ways that that correlation could be provided. The dialog parameters
   could be provided directly as header parameters included in the Refer-To: URI
   for example. string.


6.1  Exposing transfer target


   The Replaces mechanism [3] uses this approach and solves
   this problem nicely.

   For the flow below, dialog1 means dialog identifier 1, and consists
   of transferor places the parameters of transferee on hold, establishes a call with
   the Replaces header for dialog 1. In [3] this is transfer target to alert them to the Call-ID, To-tag and From-tag.

   Note that impending transfer,
   terminates the transferee's agent emits a BYE to connection with the transferor's
   agent transfer target, then proceeds
   with transfer as above.  This variation can be used to provide an immediate consequence of processing the Replaces header.

   The Transferor knows
   experience similar to that both the Transferee expected by current PBX and the Transfer Target
   support the Replaces header from the Supported: replaces header
   contained in the 200 OK responses from both.


















Sparks & Johnston Centrex users.





Sparks, et al.           Expires August 15, 2004 April 21, 2005                [Page 13] 15]
Internet-Draft              SIP CC Transfer                February                 October 2004



   To (hopefully) improve clarity, non-REFER transactions have been
   collapsed into one indicator with the arrow showing the direction of
   the request.



              Transferor           Transferee             Transfer
                   |                    |                  Target
                   |                    |                    |
         dialog1
         Call-ID:1 | INVITE/200 OK/ACK F1 F2  |                    |
                   |<-------------------|                    |
         dialog1
         Call-ID:1 | INVITE (hold)/200 OK/ACK                |
                   |------------------->|                    |
         dialog2
         Call-ID:2 | INVITE/200 OK/ACK  |                    |
                   |---------------------------------------->|
         dialog2
         Call-ID:2 | BYE/200 OK         | INVITE (hold)/200 OK/ACK                    |
                   |---------------------------------------->|
         dialog2
         Call-ID:3 | REFER (Refer-To:sip:Transferee?Replaces=dialog1) F3
                   |---------------------------------------->|
         dialog2              |                    |
                   |------------------->|                    |
         Call-ID:3 | 202 Accepted       |                    |
                   |<----------------------------------------|
         dialog2
                   |<-------------------|                    |
         Call-ID:3 | NOTIFY (100 Trying)|                    |
                   |<----------------------------------------|
         dialog2
                   |<-------------------|                    |
         Call-ID:3 |            200 OK  |
                   |---------------------------------------->|
         dialog3                    |                 INVITE (Replaces:dialog1)/200 OK/ACK F4
                   |------------------->|                    |                    |<-------------------|
         dialog1
         Call-ID:4 | BYE/200 OK                    |  INVITE/200 OK/ACK |
                   |<-------------------|
                   |
         dialog2                    |------------------->|
         Call-ID:3 | NOTIFY (200 OK)    |                    |
                   |<----------------------------------------|
         dialog2
                   |<-------------------|                    |
         Call-ID:3 |            200 OK  |
                   |---------------------------------------->|
         dialog2                    |
                   |------------------->|                    |
         Call-ID:1 | BYE/200 OK         |                    |
                   |---------------------------------------->|
                   |
                   |------------------->|                    |  (transferee and target converse)
         dialog3
         Call-ID:4 |                    |         BYE/200 OK |
                   |                    |------------------->|                    |<-------------------|


    Figure 5.  Transfer Protecting with Consultation Hold - Exposing Transfer
   Target.


   F1 INVITE


6.2  Protecting transfer target


   The transferor places the transferee on hold, establishes a call with
   the transfer target and then reverses their roles, transferring the
   original transfer target to the original transferee.  This has the
   advantage of hiding information about the original transfer target
   from the original transferee.  On the other hand, the Transferee's
   experience is different that in current systems.  The Transferee -> Transferor

   INVITE sip:transferor@atlanta.example.com SIP/2.0
   Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas432
   Max-Forwards: 70
   To: <sip:transferor@atlanta.example.com>
   From: <sip:transferee@biloxi.example.com>;tag=7553452
   Call-ID: 090459243588173445
   CSeq: 29887 INVITE
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: replaces, gruu



Sparks & Johnston is
   effectively "called back" by the Transfer Target.





Sparks, et al.           Expires August 15, 2004 April 21, 2005                [Page 14] 16]
Internet-Draft              SIP CC Transfer                February                 October 2004


   Contact: <sip:transferee@92.0.2.4>
   Content-Type: application/sdp
   Content-Length: ...


   F2 200 OK Transferor -> Transferee

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas432
   To: <sip:transferor@atlanta.example.com>;tag=31431
   From: <sip:transferee@biloxi.example.com>;tag=7553452
   Call-ID: 090459243588173445
   CSeq: 29887 INVITE
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: replaces
   Contact: <sip:transferor@pc33.atlanta.example.com>
   Content-Type: application/sdp
   Content-Length: ...


   F3 REFER Transferor -> Transfer Target


   REFER sip:transfertarget@client.chicago.com SIP/2.0
   Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnashds9
   Max-Forwards: 70
   To: <sip:transfertarget@chicago.example.com>;tag=a6c85cf
   From: <sip:transferor@atlanta.example.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314159 REFER
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: replaces
   Refer-To: <sip:transferee@192.0.2.4;Replaces=
    090459243588173445%3Bto-tag%3D31431%3Bfrom-tag%3D7553452>
   Contact: <sip:transferor@pc33.atlanta.example.com>
   Content-Length: 0


   F4 INVITE Transfer Target -> Transferee

   INVITE sip:transferee@192.0.2.4 SIP/2.0
   Via: SIP/2.0/UDP client.chicago.com;branch=z9hG4bKnaslu84
   Max-Forwards: 70
   To: <sip:transferee@biloxi.example.com>
   From: <sip:transfertarget@chicago.example.com>;tag=341234
   Call-ID: kmzwdle3dl3d08
   CSeq: 41 INVITE
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY



Sparks & Johnston       Expires August 15, 2004                [Page 15]

Internet-Draft              SIP CC Transfer                February 2004


   Supported: replaces
   Contact: <sip:transfertarget@client.chicago.com>
   Replaces: 090459243588173445;to-tag=31431;from-tag=7553452
   Content-Type: application/sdp
   Content-Length: ...







6.3 Attended Transfer

   The transferor places



   One of the transferee on hold, establishes a call problems with
   the transfer target to alert them to the impending transfer, places
   the this simplest implementation of a target on hold, then proceeds with
   protecting transfer using an escaped
   Replaces header field in the Refer-To header. This is another common
   service expected by current PBX and Centrex users.

   In order to be sure that triggered INVITE (message F4) reaches the
   Transfer Target, the Contact URI transferee is used as the Refer-To URI.  The
   presence of receiving a Supported: gruu header field in the 200 OK (message F3) new call
   from the Transfer Target to transfer-target.  Unless the Transferee guarantees that this
   Contact URI is transferee's agent has a GRUU [5] (Globally Routable User Agent URI) and will
   be routable outside
   reliable way to associate this dialog.  Without an indication that new call with the
   Contact URI is a GRUU, call it already has
   with the Transferee should still use the Contact
   URI as transferor, it will have to alert the Refer-To URI.  However, new call on another
   appearance.  If this, or some other call-waiting-like UI were not
   available, the Transferee needs transferee might be stuck returning a Busy-Here to the
   transfer target, effectively preventing the transfer.  There are many
   ways that that correlation could be provided.  The dialog parameters
   could be
   prepared provided directly as header parameters in the event Refer-To: URI
   for example.  The Replaces mechanism [3] uses this approach and
   solves this problem nicely.


   For the flow below, dialog1 means dialog identifier 1, and consists
   of the parameters of the Replaces header for dialog 1.  In [3] this
   is the Call-ID, To-tag and From-tag.


   Note that the transfer fails, transferee's agent emits a BYE to the transferor's
   agent as described 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
   Section 6.5.





















Sparks & Johnston the 200 OK responses from both.





























Sparks, et al.           Expires August 15, 2004 April 21, 2005                [Page 16] 17]
Internet-Draft              SIP CC Transfer                February                 October 2004



              Transferor           Transferee             Transfer
                   |                    |                  Target
                   |                    |                    |
         dialog1   | INVITE/200 OK/ACK  | F1 F2                 |
                   |<-------------------|                    |
         dialog1   | INVITE (hold)/200 OK/ACK                |
                   |------------------->|                    |
         dialog2   | INVITE/200 OK/ACK F1 F2 F3 F4                 |
                   |---------------------------------------->|
         dialog2   | INVITE (hold)/200 OK/ACK                |
                   |---------------------------------------->|
          dialog1
         dialog3   | REFER (Refer-To:sip:TransferTarget?Replaces=dialog2) F3
                   |------------------->|                    |
          dialog1 (Refer-To:sips:Transferee?Replaces=dialog1) F5
                   |---------------------------------------->|
         dialog3   | 202 Accepted       |                    |
                   |<-------------------|                    |
          dialog1
                   |<----------------------------------------|
         dialog3   | NOTIFY (100 Trying)|                    |
                   |<-------------------|
                   |<----------------------------------------|
         dialog3   |
          dialog1                    |            200 OK  |                    |
                   |------------------->|                    |
          dialog3
                   |---------------------------------------->|
         dialog4   |                 INVITE (Replaces:dialog2)/200 (Replaces:dialog1)/200 OK/ACK F4 F6
                   |                    |------------------->|
          dialog2                    |<-------------------|
         dialog1   | BYE/200 OK         |                    |
                   |<----------------------------------------|
          dialog1
                   |<-------------------|                    |
         dialog3   | NOTIFY (200 OK)    |                    |
                   |<-------------------|
                   |<----------------------------------------|
         dialog3   |
          dialog1                    |            200 OK  |                    |
                   |------------------->|                    |
          dialog1
                   |---------------------------------------->|
         dialog2   | BYE/200 OK         |                    |
                   |------------------->|
                   |---------------------------------------->|
                   |
          dialog3                    |  (transferee and target converse)
         dialog4   |                    |  BYE/200 OK        |
                   |                    |<-------------------|                    |------------------->|


    Figure 6. Attended  Transfer Call Flow. Protecting Transfer Target.



   F1 INVITE Transferor Transferee -> Transfer Target Transferor


   INVITE sip:transfertarget@chicago.example.com sips:transferor@atlanta.example.com SIP/2.0
   Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnas432 SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
   Max-Forwards: 70
   To: <sip:transfertarget@chicago.example.com> <sips:transferor@atlanta.example.com>
   From: <sip:transferor@atlanta.example.com>;tag=763231 <sips:transferee@biloxi.example.com>;tag=7553452
   Call-ID: 090459243588173445
   CSeq: 29887 INVITE
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: replaces replaces, gruu
   Contact: <sip:transferor@pc33.atlanta.example.com>
   Content-Type: application/sdp



Sparks & Johnston <sips:3k3k3ld812adkjw@biloxi.example.com;grid=3413kj2ha>




Sparks, et al.           Expires August 15, 2004 April 21, 2005                [Page 17] 18]
Internet-Draft              SIP CC Transfer                February                 October 2004



   Content-Type: application/sdp
   Content-Length: ...



   F2 200 OK Transferor -> Transferee


   SIP/2.0 200 OK
   Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
   To: <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
   Contact: <sips:4889445d8kjtk3@atlanta.example.com;grid=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
   Require: replaces
   Contact: <sips:4889445d8kjtk3@atlanta.example.com;grid=384i32lw3>
   Content-Type: application/sdp
   Content-Length: ...



   F4 200 OK Transfer Target -> Transferee


   SIP/2.0 200 OK
   Via: SIP/2.0/UDP SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432
    ;received=192.0.2.1
   To: <sip:transfertarget@chicago.example.com>;tag=9m2n3wq <sips:transfertarget@chicago.example.com>;tag=9m2n3wq
   From: <sip:transferor@atlanta.example.com>;tag=763231 <sips:transferor@atlanta.example.com>;tag=763231
   Call-ID: 090459243588173445 592435881734450904
   CSeq: 29887 INVITE
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: replaces, gruu
   Contact: <sip:transfertarget@client.chicago.example.com> <sips:482n4z24kdg@chicago.example.com;grid=8594958>




Sparks, et al.           Expires April 21, 2005                [Page 19]
Internet-Draft              SIP CC Transfer                 October 2004



   Content-Type: application/sdp
   Content-Length: ...


   F3



   F5 REFER Transferor -> Transferee Transfer Target


   REFER sip:transferee@192.0.2.4 sips:482n4z24kdg@chicago.example.com;grid=8594958 SIP/2.0
   Via: SIP/2.0/UDP SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9
   Max-Forwards: 70
   To: <sip:transferee@biloxi.example.com>;tag=a6c85cf <sips:482n4z24kdg@chicago.example.com;grid=8594958>
   From: <sip:transferor@atlanta.example.com>;tag=1928301774 <sips:transferor@atlanta.example.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314159 REFER
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: gruu, replaces
   Refer-To: <sip:transfertarget@client.chicago.example.com;Replaces=
    090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-tag%3D763231> <sips:3k3k3ld812adkjw@biloxi.example.com;grid=3413kj2ha?Replaces=
    090459243588173445%3Bto-tag%3D31431%3Bfrom-tag%3D7553452>
   Contact: <sip:transferor@pc33.atlanta.example.com> <sips:4889445d8kjtk3@atlanta.example.com;grid=723jd2d>
   Content-Length: 0


   F4



   F6 INVITE Transferee -> Transfer Target -> Transferee


   INVITE sip:transfertarget@client.chicago.example.com sips:3k3k3ld812adkjw@biloxi.example.com;grid=3413kj2ha SIP/2.0
   Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnaslu82 SIP/2.0/TLS client.chicago.example.com;branch=z9hG4bKnaslu84
   Max-Forwards: 70
   To: <sip:transfertarget@chicago.example.com> <sips:3k3k3ld812adkjw@biloxi.example.com;grid=3413kj2ha>
   From: <sip:transferee@biloxi.example.com>;tag=954 <sips:transfertarget@chicago.example.com>;tag=341234
   Call-ID: kmzwdle3dl3d08
   CSeq: 41 INVITE
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: gruu, replaces
   Contact: <sip:transferee@192.0.2.4> <sips:482n4z24kdg@chicago.example.com;grid=8594958>
   Replaces: 090459243588173445;to-tag=9m2n3wq;from-tag=763231 090459243588173445;to-tag=31431;from-tag=7553452
   Content-Type: application/sdp



Sparks & Johnston
   Content-Length: ...





6.3  Attended Transfer


   The transferor places the transferee on hold, establishes a call with
   the transfer target to alert them to the impending transfer, places
   the target on hold, then proceeds with transfer using an escaped
   Replaces header field in the Refer-To header.  This is another common
   service expected by current PBX and Centrex users.





Sparks, et al.           Expires August 15, 2004 April 21, 2005                [Page 18] 20]
Internet-Draft              SIP CC Transfer                February                 October 2004


   Content-Length: ...



6.4 Recovery when one party does not support REFER



   If protecting or exposing the transfer target Contact URI of the Transfer Target is not a concern, it GRUU (Globally
   Routable User Agent URI) GRUU [5] then the Transferee SHOULD use that
   URI as the Refer-To URI.  If the Contact URI is
   possible not known to complete be a transfer with consultation hold when only
   GRUU (Supported: gruu is not present), then the
   transferor and one other party support REFER.  Note that a 405 Method
   Not Allowed might be returned instead Address of Record
   (AOR) of the 501 Not Implemented
   response. Transfer Target should be used.  That is, the same URI
   that the Transferee used to establish the session with the Transfer
   Target should be used.  In case the triggered INVITE is routed to a
   different User Agent than the Transfer Target, the Require: replaces
   header field should be used in the triggered INVITE.  (This is to
   prevent an incorrect User Agent which does not support Replaces from
   ignoring the Replaces and answering the INVITE without a dialog
   match.)


   It is possible that proxy/service routing may prevent the triggered
   INVITE from reaching the same User Agent.  If this occurs, the
   triggered invite will fail with a timout, 403, 404, etc error.  The
   Transferee MAY then retry the transfer with the Refer-To URI set to
   the Contact URI.


              Transferor           Transferee             Transfer
                   |                    |                  Target
                   |                    |                    |
          dialog1  | INVITE/200 OK/ACK  | F1 F2                 |
                   |<-------------------|                    |
          dialog1  | INVITE (hold)/200 OK/ACK                |
                   |------------------->|                    |
          dialog2  | INVITE/200 OK/ACK  | F3 F4                 |
                   |---------------------------------------->|
          dialog2  | INVITE (hold)/200 OK/ACK                |
                   |---------------------------------------->|
          dialog1
          dialog3  | REFER (Refer-To:sip:TransferTarget?Replaces=dialog2) (Refer-To:sips:TransferTarget?Replaces=dialog2) F5
                   |------------------->|                    |
          dialog1  | 501 Not Implemented                     |
                   |<-------------------|                    |
          dialog2  | REFER  (Refer-To:sip:Transferee?Replaces=dialog1)
                   |---------------------------------------->|
          dialog2
          dialog3  | 202 Accepted       |                    |
                   |<----------------------------------------|
          dialog2
                   |<-------------------|                    |
          dialog3  | NOTIFY (100 Trying)|                    |
                   |<----------------------------------------|
          dialog2
                   |<-------------------|                    |
          dialog3  |            200 OK  |
                   |---------------------------------------->|
          dialog3                    |
                   |------------------->|                    |
          dialog4  |                INVITE (Replaces:dialog1)/200 (Replaces:dialog2)/200 OK/ACK F6
                   |                    |<-------------------|                    |------------------->|
          dialog2  | NOTIFY (200 OK) BYE/200 OK         |                    |
                   |<----------------------------------------|
          dialog3  |                    |            200 OK  |
                   |---------------------------------------->|
          dialog1  | BYE/200 OK NOTIFY (200 OK)    |                    |
                   |<-------------------|                    |
          dialog2
          dialog3  | BYE/200            200 OK  |                    |
                   |---------------------------------------->|
          dialog3
                   |------------------->|                    |
          dialog1  | BYE/200 OK         |                    |
                   |------------------->|



Sparks & Johnston                    |




Sparks, et al.           Expires August 15, 2004 April 21, 2005                [Page 19] 21]
Internet-Draft              SIP CC Transfer                February                 October 2004



          dialog4  |                    |         BYE/200 OK |
                   |                    |<-------------------|


   Figure 7. Recovery when one party does not support REFER.

6.5  Attended Transfer when Contact URI is Not Globally Routable

   It is a requirement of RFC3261 that a Contact URI be globally
   routable even outside the dialog.  However, due to RFC2543 User
   Agents and some architectures (NAT/Firewall traversal, screening
   proxies, ALGs, etc.) this will not always be the case.  As a result,
   the method of Attended transfer shown in Figures 6 and 7 may fail
   since they use the Contact URI in the Refer-To header field.
   Participants in transfer scenarios should indicate if their Contact
   URIs are GRUUs using the Call Flow.



   F1 INVITE Transferee -> Transferor


   INVITE sips:transferor@atlanta.example.com SIP/2.0
   Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
   Max-Forwards: 70
   To: <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 header field.

   Figure 8 shows such a scenario involving a Screening Proxy in which
   the transfer initially fails but succeeds on a second try. The
   failure (403 Forbidden, 404 Not Found, or a timeout after no
   response) response is communicated back to the Transferor.  Since
   this may be caused by routing problems with the Contact URI, the
   Contact: <sips:3k3k3ld812adkjw@biloxi.example.com;grid=3413kj2ha>
   Content-Type: application/sdp
   Content-Length: ...



   F2 200 OK Transferor retries the REFER this time with Refer-To containing the
   Address of Record (AOR) of the Target (the same URI the -> 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
   Contact: <sips:4889445d8kjtk3@atlanta.example.com;grid=723jd2d>
   Content-Type: application/sdp
   Content-Length: ...



   F3 INVITE Transferor
   used to reach the Target).  However, the use of the AOR URI may
   result in routing features being activated such as forking or
   sequential searching which may result in the triggered -> Transfer Target


   INVITE
   reaching the wrong UA.  To prevent an incorrect UA answering the 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, a ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: gruu, replaces




Sparks, et al.           Expires April 21, 2005                [Page 22]
Internet-Draft              SIP CC Transfer                 October 2004



   Require: replaces header field is included in the Refer-To.
   This ensures that only the UA which matches the Replaces dialog will
   answer the
   Contact: <sips:4889445d8kjtk3@atlanta.example.com;grid=384i32lw3>
   Content-Type: application/sdp
   Content-Length: ...



   F4 200 OK Transfer Target -> Transferee


   SIP/2.0 200 OK
   Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432
    ;received=192.0.2.1
   To: <sips:transfertarget@chicago.example.com>;tag=9m2n3wq
   From: <sips:transferor@atlanta.example.com>;tag=763231
   Call-ID: 592435881734450904
   CSeq: 29887 INVITE
   Allow: INVITE, since any incorrect UA which supports Replaces
   will reply with a 481 and a UA which ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: replaces, gruu
   Contact: <sips:482n4z24kdg@chicago.example.com;grid=8594958>
   Content-Type: application/sdp
   Content-Length: ...



   F5 REFER Transferor -> Transferee


   REFER sips:3k3k3ld812adkjw@biloxi.example.com;grid=3413kj2ha SIP/2.0
   Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9
   Max-Forwards: 70
   To: <sips:3k3k3ld812adkjw@biloxi.example.com;grid=3413kj2ha>
   From: <sips:transferor@atlanta.example.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314159 REFER
   Refer-To: <sips:482n4z24kdg@chicago.example.com;grid=8594958?Replaces=
    592435881734450904%3Bto-tag%3D9m2n3wq%3Bfrom-tag%3D763231>
   Contact: <sips:4889445d8kjtk3@atlanta.example.com;grid=723jd2d>
   Content-Length: 0



   F6 INVITE Transferee -> Transfer Target


   INVITE sips:482n4z24kdg@chicago.example.com;grid=8594958 SIP/2.0
   Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnaslu82
   Max-Forwards: 70
   To: <sips:482n4z24kdg@chicago.example.com;grid=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




Sparks, et al.           Expires April 21, 2005                [Page 23]
Internet-Draft              SIP CC Transfer                 October 2004



   Contact: <sips:3k3k3ld812adkjw@biloxi.example.com;grid=3413kj2ha>
   Replaces: 592435881734450904;to-tag=9m2n3wq;from-tag=763231
   Content-Type: application/sdp
   Content-Length: ...




6.4  Recovery when one party does not support Replaces will
   reply with a 420.

   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


   If protecting or give up on exposing 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 target is not a concern, it is
   possible to
   distinguish notifications for complete a transfer with consultation hold when only the two subscriptions.
   transferor and one other party support REFER.  Note that a 405 Method
   Not Allowed might be returned instead of the 501 Not Implemented
   response.






































Sparks, et al.           Expires April 21, 2005                [Page 24]
Internet-Draft              SIP CC Transfer                 October 2004



              Transferor           Transferee  Screening             Transfer
                   |                    |           Proxy                  Target
                   |                    |                    |             |
          dialog1  | INVITE/200 OK/ACK|             | OK/ACK  |
           |<-----------------|                    |
                   |<-------------------|                    |
          dialog1  | INVITE (hold)/200 OK/ACK                |             |
           |----------------->|             |
                   |------------------->|                    |
          dialog2  | INVITE/200 OK/ACK F1 F2  |                    |
           |--------------------------------|------------>|
                   |---------------------------------------->|
          dialog2  | INVITE (hold)/200 OK/ACK                |



Sparks & Johnston       Expires August 15, 2004                [Page 20]

Internet-Draft              SIP CC Transfer                February 2004


           |--------------------------------|------------>|
   dialog1
                   |---------------------------------------->|
          dialog3  | REFER (Refer-To:sip:TargetContact?Replaces=dialog2) F3
           |----------------->|             |             |
   dialog1 | 202 Accepted     |             |             |
           |<-----------------|             |             |
   dialog1 | NOTIFY (100 Trying)            |             |
           |<-----------------|             |             |
   dialog1 |          200 OK  |             |             |
           |----------------->|             | (Refer-To:sips:TransferTarget?Replaces=dialog2)
                   |------------------->|                    |
          dialog3  | 501 Not Implemented                     |  INVITE (Replaces:dialog2)/403/ACK
           |                  |------------>|             |
   dialog1 | NOTIFY (403 Forbidden) F4      |             |
           |<-----------------|             |             |
   dialog1 |          200 OK  |             |             |
           |----------------->|             |             |
   dialog1 |REFER(Refer-To:sip:TargetAOR?Replaces=dialog2&Require=replaces) F5
           |----------------->|
                   |<-------------------|                    |
          dialog4  |
   dialog1 REFER  (Refer-To:sips:Transferee?Replaces=dialog1)
                   |---------------------------------------->|
          dialog4  | 202 Accepted       |                    |             |
           |<-----------------|             |             |
   dialog1
                   |<----------------------------------------|
          dialog4  | NOTIFY (100 Trying)            |             |
           |<-----------------| Trying)|                    |
                   |<----------------------------------------|
          dialog4  |
   dialog1                    |            200 OK  |
                   |---------------------------------------->|
          dialog5  |                    |
           |----------------->|             |             |
   dialog4 |  INVITE (Replaces:dialog2, Require:replaces)/200 (Replaces:dialog1)/200 OK/ACK F6
           |                  |------------>|------------>|
   dialog2 | BYE/200 OK       |
                   |             |
           |<-------------------------------|<------------|
   dialog1                    |<-------------------|
          dialog4  | NOTIFY (200 OK) F7    |                    |
           |<-----------------|             |
                   |<----------------------------------------|
          dialog4  |
   dialog1                    |            200 OK  |             |             |
           |----------------->|             |             |
                   |---------------------------------------->|
          dialog1  | BYE/200 OK         |                    |
                   |<-------------------|                    |
           |----------------->|
          dialog2  | BYE/200 OK         |
   dialog3                    |
                   |---------------------------------------->|
          dialog5  |                    |  BYE/200 OK        |
                   |                  |<------------|-------------|                    |------------------->|


    Figure 8.  Recovery when one party does not support REFER.


6.5  Attended Transfer Call Flow with non-routable when Contact URI


   F1 INVITE Transferor -> Transfer Target

   INVITE sip:transfertarget@chicago.example.com SIP/2.0
   Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bK76
   Max-Forwards: 70
   To: <sip:transfertarget@chicago.example.com>
   From: <sip:transferor@atlanta.example.com>;tag=763231
   Call-ID: 090459243588173445
   CSeq: 29887 INVITE



Sparks & Johnston       Expires August 15, 2004                [Page 21]

Internet-Draft              SIP CC Transfer                February 2004


   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: replaces
   Contact: <sip: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/UDP pc33.atlanta.example.com;branch=z9hG4bKnas432
    ;received=192.0.2.1
   To: <sip:transfertarget@chicago.example.com>;tag=9m2n3wq
   From: <sip:transferor@atlanta.example.com>;tag=763231
   Call-ID: 090459243588173445
   CSeq: 29887 INVITE
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: replaces
   Contact: <sip:transfertarget@client.chicago.example.com>
   Content-Type: application/sdp
   Content-Length: ...


   F3 REFER Transferor -> Transferee

   REFER sip:transferee@192.0.2.4 SIP/2.0
   Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnashds9
   Max-Forwards: 70
   To: <sip:transferee@biloxi.example.com>;tag=a6c85cf
   From: <sip:transferor@atlanta.example.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314159 REFER
   Refer-To: <sip:transfertarget@client.chicago.example.com;Replaces=
    090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-tag%3D763231>
   Contact: <sip:transferor@pc33.atlanta.example.com>
   Content-Length: 0


   F4 NOTIFY Transferee -> Transferor

   NOTIFY sip:transferor@pc33.atlanta.com SIP/2.0
   Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas432
   Max-Forwards: 70
   To: <sip:transferor@atlanta.example.com>;tag=1928301774
   From: <sip:transferee@biloxi.example.com>;tag=a6c85cf
   Call-ID: a84b4c76e66710
   CSeq: 74 NOTIFY
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY



Sparks & Johnston is not a GRUU


   It is a requirement of RFC3261 that a Contact URI be globally
   routable even outside the dialog.  However, due to RFC2543 User
   Agents and some architectures (NAT/Firewall traversal, screening
   proxies, ALGs, etc.) this will not always be the case.  Only if a
   Contact URI is a GRUU should a UA assume that the Contact URI will be
   routable.  As a result, the method of Attended transfer shown in
   Figures 6, 7, and 8 should not be used unless the Contact URI is
   known to be a GRUU.




Sparks, et al.           Expires August 15, 2004 April 21, 2005                [Page 22] 25]
Internet-Draft              SIP CC Transfer                February                 October 2004


   Supported: replaces
   Event: refer;id=3112
   Subscription-State: terminated;reason=noresource
   Content-Type: message/sipfrag
   Content-Length: ...

   SIP/2.0 403 Forbidden


   F5 REFER Transferor -> Transferee

   REFER sip:transferee@192.0.2.4 SIP/2.0
   Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnashds9
   Max-Forwards: 70
   To: <sip:transferee@biloxi.example.com>;tag=a6c85cf
   From: <sip:transferor@atlanta.example.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314160 REFER
   Refer-To: <sip:transfertarget@chicago.example.com;Replaces=
    090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-tag%3D763231&Require=replaces>
   Contact: <sip:transferor@pc33.atlanta.example.com>
   Content-Length: 0


   F6



   Figure 9 shows such a scenario where the Transfer Target does not use
   a GRUU so the triggered INVITE is sent to the AOR of the Transfer
   Target.


       Transferor           Transferee ->  Screening       Transfer
           |                  |           Proxy         Target
           |                  |             |             |
   dialog1 | INVITE/200 OK/ACK|             |             |
           |<-----------------|             |             |
   dialog1 | INVITE sip:transfertarget@chicago.example.com SIP/2.0
   Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnaslu82
   Max-Forwards: 70
   To: <sip:transfertarget@chicago.example.com>
   From: <sip:transferee@biloxi.example.com>;tag=954
   Call-ID: 20482817324945934422930
   CSeq: 42 (hold)/200 OK/ACK       |             |
           |----------------->|             |             |
   dialog2 | INVITE/200 OK/ACK F1 F2        |             |
           |--------------------------------|------------>|
   dialog2 | INVITE
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: replaces
   Contact: <sip:transferee@192.0.2.4>
   Replaces: 090459243588173445;to-tag=9m2n3wq;from-tag=763231
   Require: replaces
   Content-Type: application/sdp
   Content-Length: ...


   F7 (hold)/200 OK/ACK                     |
           |--------------------------------|------------>|
   dialog1 | REFER (Refer-To:sips:TargetAOR?Replaces=dialog2&Require=replaces) F3
           |----------------->|             |             |
   dialog1 | 202 Accepted     |             |             |
           |<-----------------|             |             |
   dialog1 | NOTIFY Transferee -> Transferor (100 Trying)            |             |
           |<-----------------|             |             |
   dialog1 |          200 OK  |             |             |
           |----------------->|             |             |
   dialog4 |       INVITE (Replaces:dialog2, Require:replaces)/200 OK/ACK F6
           |                  |------------>|------------>|
   dialog2 | BYE/200 OK       |             |             |
           |<-------------------------------|<------------|
   dialog1 | NOTIFY sip:transferor@pc33.atlanta.com (200 OK) F7             |             |
           |<-----------------|             |             |
   dialog1 |          200 OK  |             |             |
           |----------------->|             |             |
   dialog1 | BYE/200 OK       |             |             |
           |----------------->|             |             |
   dialog3 |                  |             |  BYE/200 OK |
           |                  |<------------|-------------|


   Figure 9.  Attended Transfer Call Flow with non-GRUU Contact URI



   F1 INVITE Transferor -> Transfer Target


   INVITE sips:transfertarget@chicago.example.com SIP/2.0
   Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas432 SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK76
   Max-Forwards: 70
   To: <sip:transferor@atlanta.example.com>;tag=1928301774



Sparks & Johnston <sips:transfertarget@chicago.example.com>
   From: <sips:transferor@atlanta.example.com>;tag=763231
   Call-ID: 090459243588173445
   CSeq: 29887 INVITE




Sparks, et al.           Expires August 15, 2004 April 21, 2005                [Page 23] 26]
Internet-Draft              SIP CC Transfer                February                 October 2004



   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: <sip:transferee@biloxi.example.com>;tag=a6c85cf <sips:transferor@atlanta.example.com>;tag=763231
   Call-ID: a84b4c76e66710 090459243588173445
   CSeq: 76 NOTIFY 29887 INVITE
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: replaces
   Event: refer;id=98873867
   Subscription-State: terminated;reason=noresource
   Contact: <sips:transfertarget@client.chicago.example.com>
   Content-Type: message/sipfrag application/sdp
   Content-Length: ...



   F3 REFER Transferor -> Transferee


   REFER sips:transferee@192.0.2.4 SIP/2.0 200 OK


   To prevent this scenario from happening, the
   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
   Refer-To: <sips:transfertarget@chicago.example.com?Replaces=
    090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-tag%3D763231&Require=replaces>
   Contact: <sips:transferor@pc33.atlanta.example.com>
   Content-Length: 0



   F4 INVITE Transferee -> Transfer Target should
   obtain a GRUU and use it in the Contact header field, which will
   result in the call flow of Figure 6.

6.6 Aborting a Consultation Hold

   In any of the consultation hold flows above, the Transferor may
   decide to terminate its attempt to contact the


   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




Sparks, et al.           Expires April 21, 2005                [Page 27]
Internet-Draft              SIP CC Transfer target before
   that session is established. Most frequently, that will be the end of
   the scenario, but                 October 2004



   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
   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 some circumstances, which the transferor may wish AOR URI fails to
   proceed with reach
   the transfer action. For example, he may wish to
   complete Target.  As a result, the transfer knowing that the transferee will end up
   eventually talking to the transfer-target's voice-mail service.  Some
   PBX systems support this feature, sometimes called "semi-attended
   transfer", that is effectively a hybrid between a fully attended
   transfer and an unattended transfer.  A true implementation of this
   feature requires a short ad-hoc conference between all parties, retried with the
   Contact URI which
   ensures succeeds.


   Note that no media clipping occurs.  This flow there is outside still no guarantee that the
   scope correct endpoint will
   be reached, and the result of this document.

   For flows second REFER may also be a
   failure.  In that expose case, the Transferor could fall back to unattended
   transfer target, this simply becomes a
   basic transfer.

   This scenario is far more complicated for flows that protect or give up on the transfer target. entirely.  Since no session is established between the
   transferor and two REFERs are
   sent within the transfer target, the transfer target's agent would
   have to honor out-of-session REFERs, and somehow indicate what's
   happening via its user interface (this scenario is most likely to
   occur when the transfer-target is away from his agent).

6.7 Attended Transfer Fallback to Basic Transfer

   In this flow, an attempted attended transfer fails so the transferor
   falls back to basic transfer.  The use of OPTIONS is shown when the
   Transferee and Transfer Target do not explicitly indicate support for



Sparks & Johnston       Expires August 15, 2004                [Page 24]

Internet-Draft              SIP CC Transfer                February 2004


   the REFER method and Replaces header fields in Allow and Supported
   header fields.  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 dialog creating two distinct subscriptions, the
   Transferee
   on hold and calling the Transfer Target.  Using an OPTIONS in
   dialog2, the Transferor determines that the Target does not support
   either REFER or Replaces, making attended transfer impossible.  (Note
   that uses the same information could have been determined by including a
   Require: replaces 'id' parameter in the initial INVITE in dialog2, which would have
   failed with a 421 response.)  The Transferor then ends dialog2 by
   sending a BYE then sends a REFER Event header field to
   distinguish notifications for the Transferee using the AOR URI
   of the Transfer Target. two subscriptions.


       Transferor           Transferee  Screening       Transfer
           |                  |           Proxy         Target
           |                  |             |             |
   dialog1 | INVITE/200 OK/ACK  |                    |
                   |<-------------------|                    |
          dialog1 OK/ACK|             |   OPTIONS/200 OK             |
           |<-----------------|             |
                   |------------------->|             |
   dialog1 | INVITE (hold)/200 OK/ACK       |
                   |------------------->|                    |
          dialog2             | INVITE/200 OK/ACK
           |----------------->|             |             |
                   |---------------------------------------->|
   dialog2 | OPTIONS/200 OK INVITE/200 OK/ACK F1 F2        |             |
                   |---------------------------------------->|
           |--------------------------------|------------>|




Sparks, et al.           Expires April 21, 2005                [Page 28]
Internet-Draft              SIP CC Transfer                 October 2004



   dialog2 |    BYE/200 OK      | INVITE (hold)/200 OK/ACK                     |
                   |---------------------------------------->|
           |--------------------------------|------------>|
   dialog1 | REFER (Refer-To:sip:TransferTarget) (Refer-To:sips:TargetAOR?Replaces=dialog2&Require=replaces) F3
           |----------------->|             |
                   |------------------->|             |
   dialog1 | 202 Accepted     |             |
                   |<-------------------|             |
           |<-----------------|             |             |
   dialog1 | NOTIFY (100 Trying)| Trying)            |             |
           |<-----------------|             |
                   |<-------------------|             |
   dialog1 |          200 OK  |             |
                   |------------------->|             |
           |----------------->|             |             |
   dialog3 |               INVITE (Replaces:dialog2,Require:replaces)/403/ACK
           |  INVITE/200                  |------------>|             |
   dialog1 | NOTIFY (403 Forbidden) F4      |             |
           |<-----------------|             |             |
   dialog1 |          200 OK  |             |             |
           |----------------->|             |             |
   dialog1 |REFER(Refer-To:sips:TargetContact?Replaces=dialog2) F5
           |----------------->|             |             |
   dialog1 | 202 Accepted     |             |             |
           |<-----------------|             |             |
   dialog1 | NOTIFY (100 Trying)            |             |
           |<-----------------|             |             |
   dialog1 |          200 OK  |             |             |
           |----------------->|             |             |
   dialog4 |                INVITE (Replaces:dialog2)/200 OK/ACK F6
           |                  |------------>|------------>|
   dialog2 | BYE/200 OK       |                    |------------------->|             |             |
           |<-------------------------------|<------------|
   dialog1 | NOTIFY (200 OK) F7             |             |
                   |<-------------------|
           |<-----------------|             |             |
   dialog1 |          200 OK  |             |
                   |------------------->|             |
           |----------------->|             |             |
   dialog1 | BYE/200 OK       |             |
                   |------------------->|             |
           |----------------->|             |             |
   dialog3 |                  |             |  BYE/200 OK |
           |                    |<-------------------|                  |<------------|-------------|


   Figure 9. 10.  Attended Transfer Fallback to Basic Transfer.



Sparks & Johnston Call Flow with non-GRUU URI and AOR
   Failure



   F1 INVITE Transferor -> Transfer Target


   INVITE sips:transfertarget@chicago.example.com SIP/2.0
   Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK76
   Max-Forwards: 70
   To: <sips:transfertarget@chicago.example.com>
   From: <sips:transferor@atlanta.example.com>;tag=763231




Sparks, et al.           Expires August 15, 2004 April 21, 2005                [Page 25] 29]
Internet-Draft              SIP CC Transfer                February                 October 2004


7. Transfer with Referred-By

   In the previous examples, the



   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 does not have
   definitive information about what party initiated the transfer, or,
   in some cases, even that transfer is taking place.  The Referred-By
   mechanism [4] provides a way for the -> 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 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 would be identical to Figure 6.  However, the 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 and
   triggered INVITE messages for this flow showing the Referred-By
   mechanism are shown below.  Note that the conventions used in the
   Refer-To: <sips:transfertarget@chicago.example.com?Replaces=
    090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-tag%3D763231&Require=replaces>
   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




Sparks, et al.           Expires April 21, 2005                [Page 30]
Internet-Draft              SIP
   Torture Test Messages [7] document are reused, specifically the
   &lthex&gt and &ltallOneLine&gt tags.


   F3 CC Transfer                 October 2004



   CSeq: 74 NOTIFY
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: replaces
   Event: refer;id=314159
   Subscription-State: terminated;reason=noresource
   Content-Type: message/sipfrag
   Content-Length: ...


   SIP/2.0 403 Forbidden



   F5 REFER Transferor -> Transferee


   REFER sip:transferee@192.0.2.4 sips:transferee@192.0.2.4 SIP/2.0
   Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bK392039842 SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9
   Max-Forwards: 70
   To: <sip:transferee@biloxi.example.com>;tag=a6c85cf <sips:transferee@biloxi.example.com>;tag=a6c85cf
   From: <sip:transferor@atlanta.example.com>;tag=1928301774 <sips:transferor@atlanta.example.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314160 REFER
   <allOneLine>
   Refer-To: <sip:transfertarget@chicago.example.com;Replaces=
   090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-
   tag%3D763231&Require=replaces>
   </allOneLine>
   Referred-By: <sip:transferor@atlanta.example.com>
     ;cid="20398823.2UWQFN309shb3@atlanta.example.com" <sips:transfertarget@client.chicago.example.com?Replaces=
    090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-tag%3D763231>
   Contact: <sip:transferor@pc33.atlanta.example.com>
   Content-Type: multipart/mixed; boundary=unique-boundary-1
   Content-Length: 3267

   --unique-boundary-1
   Content-ID: <20398823.2UWQFN309shb3@atlanta.example.com> <sips:transferor@pc33.atlanta.example.com>
   Content-Length: 2961 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: multipart/signed;



Sparks & Johnston application/sdp
   Content-Length: ...



   F7 NOTIFY Transferee -> Transferor


   NOTIFY sips:transferor@pc33.atlanta.com SIP/2.0
   Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
   Max-Forwards: 70




Sparks, et al.           Expires August 15, 2004 April 21, 2005                [Page 26] 31]
Internet-Draft              SIP CC Transfer                February                 October 2004


                 protocol="application/pkcs-7-signature";
                 micalg=sha1;
                 boundary="----590F24D439B31E08745DEF0CD9397189"

   ------590F24D439B31E08745DEF0CD9397189



   To: <sips:transferor@atlanta.example.com>;tag=1928301774
   From: <sips:transferee@biloxi.example.com>;tag=a6c85cf
   Call-ID: a84b4c76e66710
   CSeq: 76 NOTIFY
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: replaces
   Event: refer;id=314160
   Subscription-State: terminated;reason=noresource
   Content-Type: message/sipfrag

   Date: Thu, 18 Sep
   Content-Length: ...


   SIP/2.0 200 OK



   To prevent this scenario from happening, the Transfer Target should
   obtain a GRUU and use it in the Contact header field, which will
   result in the call flow of Figure 7.


6.6  Semi-Attended Transfer


   In any of the consultation hold flows above, the Transferor may
   decide to terminate its attempt to contact the Transfer target before
   that session is established.  Most frequently, that will be the end
   of the scenario, but in some circumstances, the transferor may wish
   to proceed with the transfer action.  For example, the Transferor may
   wish to complete the transfer knowing that the transferee will end up
   eventually talking to the transfer-target's voice-mail service.  Some
   PBX systems support this feature, sometimes called "semi-attended
   transfer", that is effectively a hybrid between a fully attended
   transfer and an unattended transfer.  A call flow is shown in Figure
   11.  In this flow, the Transferor's User Agent continues the transfer
   as an attended transfer even after the Transferor hangs up.  Note
   that media must be played to the Transfer Target upon answer -
   otherwise, the Target may hang up and the resulting transfer
   operation will fail.


              Transferor           Transferee             Transfer
                   |                    |                  Target
                   |                    |                    |
          dialog1  | INVITE/200 OK/ACK F1 F2                 |
                   |<-------------------|                    |
          dialog1  | INVITE (hold)/200 OK/ACK                |
                   |------------------->|                    |
          dialog2  | INVITE             |                    |
                   |---------------------------------------->|
          dialog2  |                    |       180 Ringing  |
                   |<----------------------------------------|
                   | Transferor hangs up but wants transfer to continue




Sparks, et al.           Expires April 21, 2005                [Page 32]
Internet-Draft              SIP CC Transfer                 October 2004



                   |                    |                    |
                   | User Agent continues transfer operation |
                   |                    |                    |
          dialog2  |                    |           200 OK   |
                   |<----------------------------------------|
          dialog2  | ACK                |                    |
                   |---------------------------------------->|
          dialog2  | Media Played to keep Target from hanging up
                   |========================================>|
          dialog3  | REFER (Refer-To:sips:TransferTarget?Replaces=dialog2)
                   |------------------->|                    |
          dialog3  | 202 Accepted       |                    |
                   |<-------------------|                    |
          dialog3  | NOTIFY (100 Trying)|                    |
                   |<-------------------|                    |
          dialog3  |            200 OK  |                    |
                   |------------------->|                    |
          dialog4  |                INVITE (Replaces:dialog2)/200 OK/ACK
                   |                    |------------------->|
          dialog2  | BYE/200 OK         |                    |
                   |<----------------------------------------|
          dialog3  | NOTIFY (200 OK)    |                    |
                   |<-------------------|                    |
          dialog3  |            200 OK  |                    |
                   |------------------->|                    |
          dialog1  | BYE/200 OK         |                    |
                   |------------------->|                    |
          dialog4  |                    |         BYE/200 OK |
                   |                    |<-------------------|


   Figure 11.  Recommended Semi-Attended Transfer Call Flow.


   Two other possible semi-attended transfer call flows are shown in
   Figures 12 and 13.  However, these call flows are NOT RECOMMENDED due
   to a race conditions.  In both of these flows, when the Transferor
   hangs up, the User Agent attempts to revert to unattended transfer by
   sending a CANCEL to the Target.  This can result in two race
   conditions.  One is that the Target answers despite the CANCEL and
   the resulting unattended transfer fails.  This race condition can be
   eliminated by the Transferor waiting to send the REFER until the 487
   response from the Target is returned.  Instead of a 487, a 200 OK may
   return indicating that the Target has answered the consultation call.
   In this, case the call flow in Figure 13 must be followed.  In this
   flow, the Transferor must play some kind of media to the Target to
   prevent the Target from hanging up, or the Transfer will fail.  That
   is, the human at the Transfer Target will hear silence from when they
   answer (message F1) until the transfer completes (F3 and they are
   talking to the Transferee unless some media is played (F2).




Sparks, et al.           Expires April 21, 2005                [Page 33]
Internet-Draft              SIP CC Transfer                 October 2004



   The second race condition occurs in Figure 12 if the Transfer Target
   goes "off hook" after the CANCEL is received and the 487 returned.
   This may result in a 486 Busy Here response to the unattended
   transfer.


   The recommended call flow of Figure 11 does not utilize a CANCEL and
   does not suffer from these race conditions.


              Transferor           Transferee             Transfer
                   |                    |                  Target
                   |                    |                    |
          dialog1  | INVITE/200 OK/ACK  |                    |
                   |<-------------------|                    |
          dialog1  | INVITE (hold)/200 OK/ACK                |
                   |------------------->|                    |
          dialog2  | INVITE                                  |
                   |---------------------------------------->|
          dialog2  | 180 Ringing                             |
                   |<----------------------------------------|
                   |                                         |
                   |  Transferor gives up waiting            |
                   |                                         |
          dialog2  | CANCEL                                  |
                   |---------------------------------------->|
          dialog2  | 200 OK                                  |
                   |<----------------------------------------|
          dialog2  | 487 Request Terminated                  |
                   |<----------------------------------------|
          dialog2  | ACK                                     |
                   |---------------------------------------->|
          dialog3  | REFER F3                                |
                   |------------------->|                    |
          dialog3  | 202 Accepted       |                    |
                   |<-------------------|                    |
          dialog3  | NOTIFY (100 Trying)|                    |
                   |<-------------------|                    |
          dialog3  |            200 OK  |                    |
                   |------------------->|                    |
          dialog4  |                INVITE/200 OK/ACK        |
                   |                    |------------------->|
          dialog3  | NOTIFY (200 OK)    |                    |
                   |<-------------------|                    |
          dialog3  |            200 OK  |                    |
                   |------------------->|                    |
          dialog1  | BYE/200 OK         |                    |
                   |------------------->|                    |
          dialog4  |                    |         BYE/200 OK |
                   |                    |<-------------------|




Sparks, et al.           Expires April 21, 2005                [Page 34]
Internet-Draft              SIP CC Transfer                 October 2004



   Figure 12.  Semi-Attended Transfer as Blind Transfer Call Flow.  (Not
   Recommended)


              Transferor           Transferee             Transfer
                   |                    |                  Target
                   |                    |                    |
          dialog1  | INVITE/200 OK/ACK  |                    |
                   |<-------------------|                    |
          dialog1  | INVITE (hold)/200 OK/ACK                |
                   |------------------->|                    |
          dialog2  | INVITE                                  |
                   |---------------------------------------->|
          dialog2  | 180 Ringing                             |
                   |<----------------------------------------|
                   |                                         |
                   | Transferor gives up waiting but Target answers
                   |                                         |
          dialog2  | CANCEL                                  |
                   |---------------------------------------->|
          dialog2  | 200 OK (CANCEL)                         |
                   |<----------------------------------------|
          dialog2  | 200 OK (INVITE) F1                      |
                   |<----------------------------------------|
          dialog2  | ACK                                     |
                   |---------------------------------------->|
          dialog2  | INVITE (hold)/200 OK/ACK                |
                   |---------------------------------------->|
                   |  Tones or media played avoid silence F2
                   |========================================>|
          dialog1  | REFER (Refer-To:sips:TransferTarget?Replaces=dialog2)
                   |------------------->|                    |
          dialog1  | 202 Accepted       |                    |
                   |<-------------------|                    |
          dialog1  | NOTIFY (100 Trying)|                    |
                   |<-------------------|                    |
          dialog1  |            200 OK  |                    |
                   |------------------->|                    |
          dialog3  |                INVITE (Replaces:dialog2)/200 OK/ACK F3
                   |                    |------------------->|
          dialog2  | BYE/200 OK         |                    |
                   |<----------------------------------------|
          dialog1  | NOTIFY (200 OK)    |                    |
                   |<-------------------|                    |
          dialog1  |            200 OK  |                    |
                   |------------------->|                    |
          dialog1  | BYE/200 OK         |                    |
                   |------------------->|                    |
          dialog3  |                    |         BYE/200 OK |




Sparks, et al.           Expires April 21, 2005                [Page 35]
Internet-Draft              SIP CC Transfer                 October 2004



                   |                    |<-------------------|


   Figure 13.  Semi-Attended Transfer as Attended Transfer Call Flow.
   (Not Recommended)


6.7  Attended Transfer Fallback to Basic Transfer


   In this flow, an attempted attended transfer fails so the transferor
   falls back to basic transfer.


   The call flow in Figure 14 shows the use of Require:replaces in the
   INVITE sent by the Transferor to the Transfer Target in which the
   Transferor's intention at the time of sending the INVITE to the
   Transfer Target was known to be to complet an attended transfer.
   Since the Target does not support Replaces, the INVITE is rejected
   with a 420 Bad Extension response, and the Transferor switches from
   attended transfer to basic transfer immediately.



































Sparks, et al.           Expires April 21, 2005                [Page 36]
Internet-Draft              SIP CC Transfer                 October 2004



              Transferor           Transferee             Transfer
                   |                    |                  Target
                   |                    |                    |
          dialog1  | INVITE/200 OK/ACK  |                    |
                   |<-------------------|                    |
          dialog1  |   OPTIONS/200 OK   |                    |
                   |------------------->|                    |
          dialog1  | INVITE (hold)/200 OK/ACK                |
                   |------------------->|                    |
          dialog2  | INVITE (Require:replaces)               |
                   |---------------------------------------->|
          dialog2  |                     420 Bad Extension   |
                   |<----------------------------------------|
          dialog2  |    ACK                                  |
                   |---------------------------------------->|
          dialog1  | REFER (Refer-To:sips:TransferTarget)    |
                   |------------------->|                    |
          dialog1  |    202 Accepted    |                    |
                   |<-------------------|                    |
          dialog1  | NOTIFY (100 Trying)|                    |
                   |<-------------------|                    |
          dialog1  |            200 OK  |                    |
                   |------------------->|                    |
          dialog3  |                    |  INVITE/200 OK/ACK |
                   |                    |------------------->|
          dialog1  | NOTIFY (200 OK)    |                    |
                   |<-------------------|                    |
          dialog1  |            200 OK  |                    |
                   |------------------->|                    |
          dialog1  | BYE/200 OK         |                    |
                   |------------------->|                    |
          dialog3  |                    |         BYE/200 OK |
                   |                    |<-------------------|


   Figure 14.  Attended Transfer Fallback to Basic Transfer using
   Require:replaces.


   Figure 13 shows the use of OPTIONS when the Transferee and Transfer
   Target do not explicitly indicate support for the REFER method and
   Replaces header fields in Allow and Supported header fields and the
   Transferor did not have the intention of performing an attended
   transfer when the INVITE to the Target was sent.  In dialog1, the
   Transferor determines using OPTIONS that the Transferee does support
   REFER and Replaces.  As a result, the Transferor begins the attended
   transfer by placing the Transferee on hold and calling the Transfer
   Target.  Using an OPTIONS in dialog2, the Transferor determines that
   the Target does not support either REFER or Replaces, making attended
   transfer impossible.  The Transferor then ends dialog2 by sending a




Sparks, et al.           Expires April 21, 2005                [Page 37]
Internet-Draft              SIP CC Transfer                 October 2004



   BYE then sends a REFER to the Transferee using the AOR URI of the
   Transfer Target.


              Transferor           Transferee             Transfer
                   |                    |                  Target
                   |                    |                    |
          dialog1  | INVITE/200 OK/ACK  |                    |
                   |<-------------------|                    |
          dialog1  |   OPTIONS/200 OK   |                    |
                   |------------------->|                    |
          dialog1  | INVITE (hold)/200 OK/ACK                |
                   |------------------->|                    |
          dialog2  | INVITE/200 OK/ACK  |                    |
                   |---------------------------------------->|
          dialog2  | OPTIONS/200 OK     |                    |
                   |---------------------------------------->|
          dialog2  |    BYE/200 OK      |                    |
                   |---------------------------------------->|
          dialog3  | REFER (Refer-To:sips:TransferTarget)    |
                   |------------------->|                    |
          dialog3  |    202 Accepted    |                    |
                   |<-------------------|                    |
          dialog3  | NOTIFY (100 Trying)|                    |
                   |<-------------------|                    |
          dialog3  |            200 OK  |                    |
                   |------------------->|                    |
          dialog4  |                    |  INVITE/200 OK/ACK |
                   |                    |------------------->|
          dialog3  | NOTIFY (200 OK)    |                    |
                   |<-------------------|                    |
          dialog3  |            200 OK  |                    |
                   |------------------->|                    |
          dialog1  | BYE/200 OK         |                    |
                   |------------------->|                    |
          dialog4  |                    |         BYE/200 OK |
                   |                    |<-------------------|


    Figure 14.  Attended Transfer Fallback to Basic Transfer.


7.  Transfer with Referred-By


   In the previous examples, the Transfer Target does not have
   definitive information about what party initiated the transfer, or,
   in some cases, even that transfer is taking place.  The Referred-By
   mechanism [4] provides a way for the Transferor to provide the
   Transferee with a way to let the Transfer Target know what party
   initiated the transfer.





Sparks, et al.           Expires April 21, 2005                [Page 38]
Internet-Draft              SIP CC Transfer                 October 2004



   The simplest and least secure approach just involves the inclusion of
   the Referred-By header field in the REFER which is then copied into
   the triggered INVITE.  However, a more secure mechanism involving the
   Referred-By security token which is generated and signed by the
   Transferor and passed in a message body to the Transferee then to the
   Transfer Target.


   The call flow would be identical to Figure 7.  However, the REFER and
   triggered INVITE messages for this flow showing the Referred-By
   mechanism are shown below.  Note that the conventions used in the SIP
   Torture Test Messages [7] document are reused, specifically the <hex>
   and <allOneLine> tags.



   F5 REFER Transferor -> Transferee


   REFER sips:3k3k3ld812adkjw@biloxi.example.com;grid=3413kj2ha SIP/2.0
   Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK392039842
   Max-Forwards: 70
   To: <sips:3k3k3ld812adkjw@biloxi.example.com;grid=3413kj2ha>
   From: <sips:transferor@atlanta.example.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314160 REFER
   <allOneLine>
   Refer-To: <sips:482n4z24kdg@chicago.example.com;grid=8594958?Replaces=
   090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-
   tag%3D763231&Require=replaces>
   </allOneLine>
   Supported: gruu, replaces
   Referred-By: <sips:transferor@atlanta.example.com>
     ;cid="20398823.2UWQFN309shb3@atlanta.example.com"
   Contact: <sips:4889445d8kjtk3@atlanta.example.com;grid=723jd2d>
   Content-Type: multipart/mixed; boundary=unique-boundary-1
   Content-Length: 3267


   --unique-boundary-1
   Content-ID: <20398823.2UWQFN309shb3@atlanta.example.com>


   Content-Length: 2961
   Content-Type: multipart/signed;
                 protocol="application/pkcs-7-signature";
                 micalg=sha1;
                 boundary="----590F24D439B31E08745DEF0CD9397189"



   ------590F24D439B31E08745DEF0CD9397189
   Content-Type: message/sipfrag





Sparks, et al.           Expires April 21, 2005                [Page 39]
Internet-Draft              SIP CC Transfer                 October 2004



   Date: Thu, 18 Sep 2003 13:07:43 GMT
   <allOneLine>
   Refer-To: <sips:482n4z24kdg@chicago.example.com;grid=8594958;
   Replaces=090459243588173445%3B
   to-tag%3D9m2n3wq%3Bfrom-tag%3D763231&Require=replaces>
   </allOneLine>
   Referred-By: <sips:transferor@atlanta.example.com>
     ;cid="20398823.2UWQFN309shb3@atlanta.example.com"


   ------590F24D439B31E08745DEF0CD9397189
   Content-Type: application/pkcs-7-signature; name="smime.p7s"
   Content-Transfer-Encoding: binary
   Content-Disposition: attachment; filename="smime.p7s"


   <hex>3082088806092A86
   4886F70D010702A082087930820875020101310B300906052B0E03021A050030
   0B06092A864886F70D010701A082067A30820339308202A2A003020102020800
   90008902240001300D06092A864886F70D01010505003070310B300906035504
   0613025553311330110603550408130A43616C69666F726E69613111300F0603
   550407130853616E4A6F7365310E300C060355040A1305736970697431293027
   060355040B135369706974546573744365727469666963617465417574686F72
   697479301E170D3033313032313134343332355A170D31333130313831343433
   32355A3062310B3009060355040613025553311330110603550408130A43616C
   69666F726E69613111300F0603550407130853616E4A6F7365310E300C060355
   040A13057369706974311B30190603550403141273656E646572406578616D70
   6C652E6F726730819F300D06092A864886F70D010101050003818D0030818902
   818100CB8302060F12C8FA2D1786922CA173DCEB80BF1B1B8AF74A310C6975A5
   56A7630FB6E044D9E994DCD49AFF7976C462D7A8E74ECBF98723AEBF2796EDDD
   6263577C6C2B77DC7C300B533DEDB5FB8EB3827FD6FC9B37B9A0DE829F1B1081
   D632A8AD9FB00A860928E88F87E0B979BA65294AC7D6D2D18A78C86B4FA73387
   4E230203010001A381E93081E6301D0603551D1104163014811273656E646572
   406578616D706C652E6F726730090603551D1304023000301D0603551D0E0416
   041440FF1C0C1BB8684CA917839D70E97DF8DD5B60D130819A0603551D230481
   9230818F80146B461714EA94762580546E1354DAA1E35414A1B6A174A4723070
   310B3009060355040613025553311330110603550408130A43616C69666F726E
   69613111300F0603550407130853616E4A6F7365310E300C060355040A130573
   6970697431293027060355040B13536970697454657374436572746966696361
   7465417574686F72697479820100300D06092A864886F70D0101050500038181
   006FFE1A3B5CE807C3DD2CFDF6E9787F491C84DBF7DCD11DB2D6A8887D2FE3F2
   2E9C6894994282E50AA0DFFE1CBD4EC2C20217831FC2AD360FF1C0DE1DE1E870
   102CFA99EE504C7DC0D8752A63294AC748DDDEFADE55C6D051F1CD54CFE7C153
   278962A53CEF61B875C1FD3C74E972242CBA0131B3B8C607BF95B378212CA9A7
   5E30820339308202A2A00302010202080090008902240001300D06092A864886
   F70D01010505003070310B300906035504061302555331133011060355040813
   0A43616C69666F726E69613111300F0603550407130853616E4A6F7365310E30
   0C060355040A1305736970697431293027060355040B13536970697454657374
   4365727469666963617465417574686F72697479301E170D3033313032313134
   343332355A170D3133313031383134343332355A3062310B3009060355040613




Sparks, et al.           Expires April 21, 2005                [Page 40]
Internet-Draft              SIP CC Transfer                 October 2004



   025553311330110603550408130A43616C69666F726E69613111300F06035504
   07130853616E4A6F7365310E300C060355040A13057369706974311B30190603
   550403141273656E646572406578616D706C652E6F726730819F300D06092A86
   4886F70D010101050003818D0030818902818100CB8302060F12C8FA2D178692
   2CA173DCEB80BF1B1B8AF74A310C6975A556A7630FB6E044D9E994DCD49AFF79
   76C462D7A8E74ECBF98723AEBF2796EDDD6263577C6C2B77DC7C300B533DEDB5
   FB8EB3827FD6FC9B37B9A0DE829F1B1081D632A8AD9FB00A860928E88F87E0B9
   79BA65294AC7D6D2D18A78C86B4FA733874E230203010001A381E93081E6301D
   0603551D1104163014811273656E646572406578616D706C652E6F7267300906
   03551D1304023000301D0603551D0E0416041440FF1C0C1BB8684CA917839D70
   E97DF8DD5B60D130819A0603551D2304819230818F80146B461714EA94762580
   546E1354DAA1E35414A1B6A174A4723070310B30090603550406130255533113
   30110603550408130A43616C69666F726E69613111300F060355040713085361
   6E4A6F7365310E300C060355040A1305736970697431293027060355040B1353
   69706974546573744365727469666963617465417574686F7269747982010030
   0D06092A864886F70D0101050500038181006FFE1A3B5CE807C3DD2CFDF6E978
   7F491C84DBF7DCD11DB2D6A8887D2FE3F22E9C6894994282E50AA0DFFE1CBD4E
   C2C20217831FC2AD360FF1C0DE1DE1E870102CFA99EE504C7DC0D8752A63294A
   C748DDDEFADE55C6D051F1CD54CFE7C153278962A53CEF61B875C1FD3C74E972
   242CBA0131B3B8C607BF95B378212CA9A75E318201D6308201D2020101307C30
   70310B3009060355040613025553311330110603550408130A43616C69666F72
   6E69613111300F0603550407130853616E4A6F7365310E300C060355040A1305
   736970697431293027060355040B135369706974546573744365727469666963
   617465417574686F7269747902080090008902240001300906052B0E03021A05
   00A081B1301806092A864886F70D010903310B06092A864886F70D010701301C
   06092A864886F70D010905310F170D3034303132363139313831345A30230609
   2A864886F70D01090431160414408CCA5772916A968204FD24CC24EDAEAD3943
   95305206092A864886F70D01090F31453043300A06082A864886F70D0307300E
   06082A864886F70D030202020080300D06082A864886F70D0302020140300706
   052B0E030207300D06082A864886F70D0302020128300D06092A864886F70D01
   010105000481807795329BB23B8BB9F72526AB9CC22D93B9A37A2E69A0171D3C
   C417DD394F0A5FD4F8B082733CD9F2E26F6991031F7FF2EAD31640718502FB4C
   822771211E6228C793DA4DBBA2159227C221030FE9088CD659578EB862568087
   8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B428388966
   79089AAD95767F</hex>


   ------590F24D439B31E08745DEF0CD9397189--


   --unique_boundary-1





   F6 INVITE Transferee -> Transfer Target


   INVITE sips:482n4z24kdg@chicago.example.com;grid=8594958 SIP/2.0
   Via: SIP/2.0/TLS referee.example;branch=z9hG4bKffe209934aac
   To: <sips:482n4z24kdg@chicago.example.com;grid=8594958>




Sparks, et al.           Expires April 21, 2005                [Page 41]
Internet-Draft              SIP CC Transfer                 October 2004



   From: <sips:transferee@biloxi.example.com>;tag=2909034023
   Call-ID: fe9023940-a3465@referee.example
   CSeq: 889823409 INVITE
   Max-Forwards: 70
   Contact: <sips:3k3k3ld812adkjw@biloxi.example.com;grid=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
   Content-Type: multipart/mixed; boundary=my-boundary-9
   Content-Length: 3432


   --my-boundary-9
   Content-Type: application/sdp


   Content-Length: 156


   v=0
   o=referee 2890844526 2890844526 IN IP4 referee.example
   s=Session SDP
   c=IN IP4 referee.example
   t=0 0
   m=audio 49172 RTP/AVP 0
   a=rtpmap:0 PCMU/8000


   --my-boundary-9
   Content-Length: 2961
   Content-Type: multipart/signed;
                 protocol="application/pkcs-7-signature";
                 micalg=sha1;
                 boundary="----590F24D439B31E08745DEF0CD9397189"


   ------590F24D439B31E08745DEF0CD9397189
   Content-Type: message/sipfrag


   Date: Thu, 18 Sep 2003 13:07:43 GMT


   <allOneLine>
   Refer-To: <sip:transfertarget@chicago.example.com; <sips:transfertarget@chicago.example.com;
   Replaces=090459243588173445%3B
   to-tag%3D9m2n3wq%3Bfrom-tag%3D763231&Require=replaces>
   </allOneLine>
   Referred-By: <sip:transferor@atlanta.example.com> <sips:transferor@atlanta.example.com>
     ;cid="20398823.2UWQFN309shb3@atlanta.example.com"


   ------590F24D439B31E08745DEF0CD9397189




Sparks, et al.           Expires April 21, 2005                [Page 42]
Internet-Draft              SIP CC Transfer                 October 2004



   Content-Type: application/pkcs-7-signature; name="smime.p7s"
   Content-Transfer-Encoding: binary
   Content-Disposition: attachment; filename="smime.p7s"


   <hex>3082088806092A86


   4886F70D010702A082087930820875020101310B300906052B0E03021A050030
   0B06092A864886F70D010701A082067A30820339308202A2A003020102020800
   90008902240001300D06092A864886F70D01010505003070310B300906035504
   0613025553311330110603550408130A43616C69666F726E69613111300F0603
   550407130853616E4A6F7365310E300C060355040A1305736970697431293027
   060355040B135369706974546573744365727469666963617465417574686F72
   697479301E170D3033313032313134343332355A170D31333130313831343433
   32355A3062310B3009060355040613025553311330110603550408130A43616C
   69666F726E69613111300F0603550407130853616E4A6F7365310E300C060355
   040A13057369706974311B30190603550403141273656E646572406578616D70
   6C652E6F726730819F300D06092A864886F70D010101050003818D0030818902
   818100CB8302060F12C8FA2D1786922CA173DCEB80BF1B1B8AF74A310C6975A5
   56A7630FB6E044D9E994DCD49AFF7976C462D7A8E74ECBF98723AEBF2796EDDD
   6263577C6C2B77DC7C300B533DEDB5FB8EB3827FD6FC9B37B9A0DE829F1B1081
   D632A8AD9FB00A860928E88F87E0B979BA65294AC7D6D2D18A78C86B4FA73387
   4E230203010001A381E93081E6301D0603551D1104163014811273656E646572
   406578616D706C652E6F726730090603551D1304023000301D0603551D0E0416
   041440FF1C0C1BB8684CA917839D70E97DF8DD5B60D130819A0603551D230481
   9230818F80146B461714EA94762580546E1354DAA1E35414A1B6A174A4723070
   310B3009060355040613025553311330110603550408130A43616C69666F726E
   69613111300F0603550407130853616E4A6F7365310E300C060355040A130573
   6970697431293027060355040B13536970697454657374436572746966696361
   7465417574686F72697479820100300D06092A864886F70D0101050500038181
   006FFE1A3B5CE807C3DD2CFDF6E9787F491C84DBF7DCD11DB2D6A8887D2FE3F2
   2E9C6894994282E50AA0DFFE1CBD4EC2C20217831FC2AD360FF1C0DE1DE1E870
   102CFA99EE504C7DC0D8752A63294AC748DDDEFADE55C6D051F1CD54CFE7C153



Sparks & Johnston
   278962A53CEF61B875C1FD3C74E972242CBA0131B3B8C607BF95B378212CA9A7
   5E30820339308202A2A00302010202080090008902240001300D06092A864886
   F70D01010505003070310B300906035504061302555331133011060355040813
   0A43616C69666F726E69613111300F0603550407130853616E4A6F7365310E30
   0C060355040A1305736970697431293027060355040B13536970697454657374
   4365727469666963617465417574686F72697479301E170D3033313032313134
   343332355A170D3133313031383134343332355A3062310B3009060355040613
   025553311330110603550408130A43616C69666F726E69613111300F06035504
   07130853616E4A6F7365310E300C060355040A13057369706974311B30190603
   550403141273656E646572406578616D706C652E6F726730819F300D06092A86
   4886F70D010101050003818D0030818902818100CB8302060F12C8FA2D178692
   2CA173DCEB80BF1B1B8AF74A310C6975A556A7630FB6E044D9E994DCD49AFF79
   76C462D7A8E74ECBF98723AEBF2796EDDD6263577C6C2B77DC7C300B533DEDB5
   FB8EB3827FD6FC9B37B9A0DE829F1B1081D632A8AD9FB00A860928E88F87E0B9
   79BA65294AC7D6D2D18A78C86B4FA733874E230203010001A381E93081E6301D
   0603551D1104163014811273656E646572406578616D706C652E6F7267300906




Sparks, et al.           Expires April 21, 2005                [Page 43]
Internet-Draft              SIP CC Transfer                 October 2004



   03551D1304023000301D0603551D0E0416041440FF1C0C1BB8684CA917839D70
   E97DF8DD5B60D130819A0603551D2304819230818F80146B461714EA94762580
   546E1354DAA1E35414A1B6A174A4723070310B30090603550406130255533113
   30110603550408130A43616C69666F726E69613111300F060355040713085361
   6E4A6F7365310E300C060355040A1305736970697431293027060355040B1353
   69706974546573744365727469666963617465417574686F7269747982010030
   0D06092A864886F70D0101050500038181006FFE1A3B5CE807C3DD2CFDF6E978
   7F491C84DBF7DCD11DB2D6A8887D2FE3F22E9C6894994282E50AA0DFFE1CBD4E
   C2C20217831FC2AD360FF1C0DE1DE1E870102CFA99EE504C7DC0D8752A63294A
   C748DDDEFADE55C6D051F1CD54CFE7C153278962A53CEF61B875C1FD3C74E972
   242CBA0131B3B8C607BF95B378212CA9A75E318201D6308201D2020101307C30
   70310B3009060355040613025553311330110603550408130A43616C69666F72
   6E69613111300F0603550407130853616E4A6F7365310E300C060355040A1305
   736970697431293027060355040B135369706974546573744365727469666963
   617465417574686F7269747902080090008902240001300906052B0E03021A05
   00A081B1301806092A864886F70D010903310B06092A864886F70D010701301C
   06092A864886F70D010905310F170D3034303132363139313831345A30230609
   2A864886F70D01090431160414408CCA5772916A968204FD24CC24EDAEAD3943
   95305206092A864886F70D01090F31453043300A06082A864886F70D0307300E
   06082A864886F70D030202020080300D06082A864886F70D0302020140300706
   052B0E030207300D06082A864886F70D0302020128300D06092A864886F70D01
   010105000481807795329BB23B8BB9F72526AB9CC22D93B9A37A2E69A0171D3C
   C417DD394F0A5FD4F8B082733CD9F2E26F6991031F7FF2EAD31640718502FB4C
   822771211E6228C793DA4DBBA2159227C221030FE9088CD659578EB862568087
   8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B428388966
   79089AAD95767F</hex>


   ------590F24D439B31E08745DEF0CD9397189--


   --my-boundary-9--




8.  Transfer as an Ad-Hoc Conference


   In this flow, Bob does an attended transfer of Alice to Carol.  In
   order to keep both Alice and Carol fully informed of the nature and
   state of the transfer operation, Bob acts as a focus[9]  and hosts an
   ad-hoc conference involving Alice, Bob, and Carol.  Alice and Carol
   subscribe to the conference package[10]  of Bob's focus, which allows
   them to know the exact status of the operation.  After the transfer
   operation is complete, Bob deletes the conference.


   This call flow meets requirement 6 of Section 3.  NOTIFY messages
   related to the refer package are indicated as NOTIFY (refer), while
   NOTIFYs related to the Conference Info package are indicated as
   NOTIFY (Conf-Info).





Sparks, et al.           Expires April 21, 2005                [Page 44]
Internet-Draft              SIP CC Transfer                 October 2004



   Note that any type of semi-attended transfer in which media mixing or
   relaying could be implemented using this model.  In addition to
   simply mixing, the focus could introduce additional media signals
   such as simulated ring tone or on hold announcements to improve the
   user experience.


    Alice                  Bob                 Carol
       |                    |                    |
       | INVITE             |                    |
       |------------------->|                    |
       |   180 Ringing      |                    |
       |<-------------------|                    |
       |     200 OK         |                    |
       |<-------------------|                    |
       |        ACK         |                    |
       |------------------->|                    |
       |        RTP         |                    |
       |<==================>|                    |
       |                    |                    |
       | Bob places Alice on hold and begins acting like a focus
       |                    |                    |
       | INVITE (hold) Contact:Conf-ID;isfocus   |
       |<-------------------|                    |
       |    200 OK          |                    |
       |------------------->|                    |
       |        ACK         |                    |
       |<-------------------|                    |
       |                    |                    |
       | Alice subscribes to the conference package
       |                    |                    |
       | SUBSCRIBE sip:Conf-ID                   |
       |------------------->|                    |
       |     200 OK         |                    |
       |<-------------------|                    |
       | NOTIFY (Conf-Info) |                    |
       |<-------------------|                    |
       |     200 OK         |                    |
       |------------------->|                    |
       |                    |                    |
       |       Bob begins consultation operation |
       |                    |                    |
       |       INVITE Require:replaces Contact:Conf-ID;isfocus
       |                    |------------------->|
       |                    |   180 Ringing      |
       |                    |<-------------------|
       |                    |     200 OK         |
       |                    |<-------------------|
       |                    |       ACK          |




Sparks, et al.           Expires April 21, 2005                [Page 45]
Internet-Draft              SIP CC Transfer                 October 2004



       |                    |------------------->|
       |                    |        RTP         |
       |                    |<==================>|
       |                    |                    |
   Carol subscribes to the conference package - learns Bob is on hold
       |                    |                    |
       |                    |SUBSCRIBE sip:Conf-ID
       |                    |<-------------------|
       |                    |      200 OK        |
       |                    |------------------->|
       |                    | NOTIFY (Conf-Info) |
       |                    |------------------->|
       |                    |      200 OK        |
       |                    |<-------------------|
       |                    |                    |
       | Alice learns that Bob is talking to Carol
       |                    |                    |
       | NOTIFY (Conf-Info) |                    |
       |<-------------------|                    |
       |     200 OK         |                    |
       |------------------->|                    |
       |                    |  INVITE (hold)     |
       |                    |------------------->|
       |                    |      200 OK        |
       |                    |<-------------------|
       |                    |      ACK           |
       |                    |------------------->|
       |                    |                    |
       | Alice learns that Carol is now on hold  |
       |                    |                    |
       | NOTIFY (Conf-Info) |                    |
       |<-------------------|                    |
       |     200 OK         |                    |
       |------------------->|                    |
       |                    |                    |
       |           Bob begins transfer operation |
       |                    |                    |
       |     REFER Refer-To: Carol               |
       |<-------------------|                    |
       |     202 Accepted   |                    |
       |------------------->|                    |
       | NOTIFY (Refer)     |                    |
       |------------------->|                    |
       |     200 OK         |                    |
       |<-------------------|                    |
       |  INVITE Replaces:B-C Contact:Alice      |
       |---------------------------------------->|
       |                 200 OK                  |




Sparks, et al.           Expires April 21, 2005                [Page 46]
Internet-Draft              SIP CC Transfer                 October 2004



       |<----------------------------------------|
       |                   ACK                   |
       |---------------------------------------->|
       |                    RTP                  |
       |<=======================================>|
       |                    |       BYE          |
       |                    |<-------------------|
       |                    |      200 OK        |
       |                    |------------------->|
       | NOTIFY (Refer)     |                    |
       |------------------->|                    |
       |     200 OK         |                    |
       |<-------------------|                    |
       |                    |                    |
       | Bob terminates the ad-hoc conference    |
       |                    |                    |
       |       BYE          |                    |
       |<-------------------|                    |
       |     200 OK         |                    |
       |------------------->|                    |
       |                    | NOTIFY (Conf-Info) |
       |                    |------------------->|
       |                    |      200 OK        |
       |                    |<-------------------|
       | NOTIFY (Conf-Info) |                    |
       |<-------------------|                    |
       |     200 OK         |                    |
       |------------------->|                    |


   Figure 15. Attended Transfer as an Ad-Hoc Conference.



9.  Transfer with multiple parties


   In this example the Originator places call to the Facilitator who
   reaches the Recipient through the Screener.  The Recipient's contact
   information is exposed to the Facilitator and the Originator.  This
   example is provided for clarification of the semantics of the REFER
   method only and should not be used as the design of an
   implementation.


            Originator   Facilitator   Screener   Recipient
        Call-ID  |            |            |          |
            1    |INVITE/200 OK/ACK        |          |"Get Fred for me!"
                 |----------->|            |          |     "Right away!"
            1    |INVITE (hold)/200 OK/ACK |          |
                 |<-----------|            |          |
            2    |            |INVITE/200 OK/ACK      |"I have a call




Sparks, et al.           Expires August 15, 2004 April 21, 2005                [Page 27] 47]
Internet-Draft              SIP CC Transfer                February                 October 2004


   278962A53CEF61B875C1FD3C74E972242CBA0131B3B8C607BF95B378212CA9A7
   5E30820339308202A2A00302010202080090008902240001300D06092A864886
   F70D01010505003070310B300906035504061302555331133011060355040813
   0A43616C69666F726E69613111300F0603550407130853616E4A6F7365310E30
   0C060355040A1305736970697431293027060355040B13536970697454657374
   4365727469666963617465417574686F72697479301E170D3033313032313134
   343332355A170D3133313031383134343332355A3062310B3009060355040613
   025553311330110603550408130A43616C69666F726E69613111300F06035504
   07130853616E4A6F7365310E300C060355040A13057369706974311B30190603
   550403141273656E646572406578616D706C652E6F726730819F300D06092A86
   4886F70D010101050003818D0030818902818100CB8302060F12C8FA2D178692
   2CA173DCEB80BF1B1B8AF74A310C6975A556A7630FB6E044D9E994DCD49AFF79
   76C462D7A8E74ECBF98723AEBF2796EDDD6263577C6C2B77DC7C300B533DEDB5
   FB8EB3827FD6FC9B37B9A0DE829F1B1081D632A8AD9FB00A860928E88F87E0B9
   79BA65294AC7D6D2D18A78C86B4FA733874E230203010001A381E93081E6301D
   0603551D1104163014811273656E646572406578616D706C652E6F7267300906
   03551D1304023000301D0603551D0E0416041440FF1C0C1BB8684CA917839D70
   E97DF8DD5B60D130819A0603551D2304819230818F80146B461714EA94762580
   546E1354DAA1E35414A1B6A174A4723070310B30090603550406130255533113
   30110603550408130A43616C69666F726E69613111300F060355040713085361
   6E4A6F7365310E300C060355040A1305736970697431293027060355040B1353
   69706974546573744365727469666963617465417574686F7269747982010030
   0D06092A864886F70D0101050500038181006FFE1A3B5CE807C3DD2CFDF6E978
   7F491C84DBF7DCD11DB2D6A8887D2FE3F22E9C6894994282E50AA0DFFE1CBD4E
   C2C20217831FC2AD360FF1C0DE1DE1E870102CFA99EE504C7DC0D8752A63294A
   C748DDDEFADE55C6D051F1CD54CFE7C153278962A53CEF61B875C1FD3C74E972
   242CBA0131B3B8C607BF95B378212CA9A75E318201D6308201D2020101307C30
   70310B3009060355040613025553311330110603550408130A43616C69666F72
   6E69613111300F0603550407130853616E4A6F7365310E300C060355040A1305
   736970697431293027060355040B135369706974546573744365727469666963
   617465417574686F7269747902080090008902240001300906052B0E03021A05
   00A081B1301806092A864886F70D010903310B06092A864886F70D010701301C
   06092A864886F70D010905310F170D3034303132363139313831345A30230609
   2A864886F70D01090431160414408CCA5772916A968204FD24CC24EDAEAD3943
   95305206092A864886F70D01090F31453043300A06082A864886F70D0307300E
   06082A864886F70D030202020080300D06082A864886F70D0302020140300706
   052B0E030207300D06082A864886F70D0302020128300D06092A864886F70D01
   010105000481807795329BB23B8BB9F72526AB9CC22D93B9A37A2E69A0171D3C
   C417DD394F0A5FD4F8B082733CD9F2E26F6991031F7FF2EAD31640718502FB4C
   822771211E6228C793DA4DBBA2159227C221030FE9088CD659578EB862568087
   8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B428388966
   79089AAD95767F</hex>

   ------590F24D439B31E08745DEF0CD9397189--

   --unique_boundary-1





Sparks & Johnston



                 |            |----------->|          |from Mary for Fred"
            2    |            |INVITE (hold)/200 OK/ACK   "Hold please"
                 |            |<-----------|          |
            3    |            |            |INVITE/200 OK/ACK
                 |            |            |--------->|"You have a call
                 |            |            |          |from Mary"
                 |            |            |          |  "Put her through"
            3    |            |            |INVITE (hold)/200 OK/ACK
                 |            |            |--------->|
            4    |            |REFER       |          |
                 |            |<-----------|          |
            4    |            |202 Accepted|          |
                 |            |----------->|          |
            4    |            |NOTIFY (100 Trying)    |
                 |            |----------->|          |
            4    |            |200 OK      |          |
                 |            |<-----------|          |
            5    |            |INVITE/200 OK/ACK      |
                 |            |---------------------->|"This is Fred"
            4    |            |NOTIFY (200 OK)        |  "Please hold for
                 |            |----------->|          |              Mary"
            4    |            |200 OK      |          |
                 |            |<-----------|          |
            2    |            |BYE/200 OK  |          |
                 |            |<-----------|          |
            3    |            |            |BYE/200 OK|
                 |            |            |--------->|
            5    |            |INVITE (hold)/200 OK/ACK
                 |            |---------------------->|
            6    |REFER       |            |          |
                 |<-----------|            |          |
            6    |202 Accepted|            |          |
                 |----------->|            |          |
            6    |NOTIFY (100 Trying)      |          |
                 |----------->|            |          |
            6    |200 OK      |            |          |
                 |<-----------|            |          |
            7    |INVITE/200 OK/ACK        |          |
                 |----------------------------------->| "Hey Fred"
            6    |NOTIFY (200 OK)          |          |    "Hello Mary"
                 |----------->|            |          |
            6    |200 OK      |            |          |
                 |<-----------|            |          |
            1    |BYE/200 OK  |            |          |
                 |<-----------|            |          |
            5    |            |BYE/200 OK  |          |
                 |            |---------------------->|
            7    |BYE/200 OK  |            |          |




Sparks, et al.           Expires August 15, 2004 April 21, 2005                [Page 28] 48]
Internet-Draft              SIP CC Transfer                February                 October 2004


   F4 INVITE Transferee ->



                 |<-----------------------------------| "See you later"


   Figure 16.  Transfer Target

   INVITE sip:transfertarget@chicago.example.com SIP/2.0
   Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac
   To: <sip:transfertarget@chicago.example.com>
   From: <sip:transferee@biloxi.example.com>;tag=2909034023
   Call-ID: fe9023940-a3465@referee.example
   CSeq: 889823409 INVITE
   Max-Forwards: 70
   Contact: <sip:transferee@192.0.2.4>
   Referred-By: <sip:transferor@atlanta.example.com>
       ;cid="20398823.2UWQFN309shb3@atlanta.example.com"
   Replaces:090459243588173445;to-tag=9m2n3wq;from-
     tag=76323
   Require:replaces
   Content-Type: multipart/mixed; boundary=my-boundary-9
   Content-Length: 3432

   --my-boundary-9
   Content-Type: application/sdp
   Content-Length: 156

   v=0
   o=referee 2890844526 2890844526 IN IP4 referee.example
   s=Session SDP
   c=IN IP4 referee.example
   t=0 0
   m=audio 49172 RTP/AVP 0
   a=rtpmap:0 PCMU/8000

   --my-boundary-9
   Content-Length: 2961
   Content-Type: multipart/signed;
                 protocol="application/pkcs-7-signature";
                 micalg=sha1;
                 boundary="----590F24D439B31E08745DEF0CD9397189"

   ------590F24D439B31E08745DEF0CD9397189
   Content-Type: message/sipfrag

   Date: Thu, 18 Sep 2003 13:07:43 GMT
   <allOneLine>
   Refer-To: <sip:transfertarget@chicago.example.com;
   Replaces=090459243588173445%3B
   to-tag%3D9m2n3wq%3Bfrom-tag%3D763231&Require=replaces>
   </allOneLine>
   Referred-By: <sip:transferor@atlanta.example.com>
     ;cid="20398823.2UWQFN309shb3@atlanta.example.com"



Sparks & Johnston       Expires August 15, 2004                [Page 29]

Internet-Draft              SIP CC with Multiple Parties Example.


10.  Gateway Transfer                February 2004


   ------590F24D439B31E08745DEF0CD9397189
   Content-Type: application/pkcs-7-signature; name="smime.p7s"
   Content-Transfer-Encoding: binary
   Content-Disposition: attachment; filename="smime.p7s"

   <hex>3082088806092A86
   4886F70D010702A082087930820875020101310B300906052B0E03021A050030
   0B06092A864886F70D010701A082067A30820339308202A2A003020102020800
   90008902240001300D06092A864886F70D01010505003070310B300906035504
   0613025553311330110603550408130A43616C69666F726E69613111300F0603
   550407130853616E4A6F7365310E300C060355040A1305736970697431293027
   060355040B135369706974546573744365727469666963617465417574686F72
   697479301E170D3033313032313134343332355A170D31333130313831343433
   32355A3062310B3009060355040613025553311330110603550408130A43616C
   69666F726E69613111300F0603550407130853616E4A6F7365310E300C060355
   040A13057369706974311B30190603550403141273656E646572406578616D70
   6C652E6F726730819F300D06092A864886F70D010101050003818D0030818902
   818100CB8302060F12C8FA2D1786922CA173DCEB80BF1B1B8AF74A310C6975A5
   56A7630FB6E044D9E994DCD49AFF7976C462D7A8E74ECBF98723AEBF2796EDDD
   6263577C6C2B77DC7C300B533DEDB5FB8EB3827FD6FC9B37B9A0DE829F1B1081
   D632A8AD9FB00A860928E88F87E0B979BA65294AC7D6D2D18A78C86B4FA73387
   4E230203010001A381E93081E6301D0603551D1104163014811273656E646572
   406578616D706C652E6F726730090603551D1304023000301D0603551D0E0416
   041440FF1C0C1BB8684CA917839D70E97DF8DD5B60D130819A0603551D230481
   9230818F80146B461714EA94762580546E1354DAA1E35414A1B6A174A4723070
   310B3009060355040613025553311330110603550408130A43616C69666F726E
   69613111300F0603550407130853616E4A6F7365310E300C060355040A130573
   6970697431293027060355040B13536970697454657374436572746966696361
   7465417574686F72697479820100300D06092A864886F70D0101050500038181
   006FFE1A3B5CE807C3DD2CFDF6E9787F491C84DBF7DCD11DB2D6A8887D2FE3F2
   2E9C6894994282E50AA0DFFE1CBD4EC2C20217831FC2AD360FF1C0DE1DE1E870
   102CFA99EE504C7DC0D8752A63294AC748DDDEFADE55C6D051F1CD54CFE7C153
   278962A53CEF61B875C1FD3C74E972242CBA0131B3B8C607BF95B378212CA9A7
   5E30820339308202A2A00302010202080090008902240001300D06092A864886
   F70D01010505003070310B300906035504061302555331133011060355040813
   0A43616C69666F726E69613111300F0603550407130853616E4A6F7365310E30
   0C060355040A1305736970697431293027060355040B13536970697454657374
   4365727469666963617465417574686F72697479301E170D3033313032313134
   343332355A170D3133313031383134343332355A3062310B3009060355040613
   025553311330110603550408130A43616C69666F726E69613111300F06035504
   07130853616E4A6F7365310E300C060355040A13057369706974311B30190603
   550403141273656E646572406578616D706C652E6F726730819F300D06092A86
   4886F70D010101050003818D0030818902818100CB8302060F12C8FA2D178692
   2CA173DCEB80BF1B1B8AF74A310C6975A556A7630FB6E044D9E994DCD49AFF79
   76C462D7A8E74ECBF98723AEBF2796EDDD6263577C6C2B77DC7C300B533DEDB5
   FB8EB3827FD6FC9B37B9A0DE829F1B1081D632A8AD9FB00A860928E88F87E0B9
   79BA65294AC7D6D2D18A78C86B4FA733874E230203010001A381E93081E6301D
   0603551D1104163014811273656E646572406578616D706C652E6F7267300906



Sparks & Johnston       Expires August 15, 2004                [Page 30]

Internet-Draft Issues


   A gateway in SIP CC Transfer                February 2004


   03551D1304023000301D0603551D0E0416041440FF1C0C1BB8684CA917839D70
   E97DF8DD5B60D130819A0603551D2304819230818F80146B461714EA94762580
   546E1354DAA1E35414A1B6A174A4723070310B30090603550406130255533113
   30110603550408130A43616C69666F726E69613111300F060355040713085361
   6E4A6F7365310E300C060355040A1305736970697431293027060355040B1353
   69706974546573744365727469666963617465417574686F7269747982010030
   0D06092A864886F70D0101050500038181006FFE1A3B5CE807C3DD2CFDF6E978
   7F491C84DBF7DCD11DB2D6A8887D2FE3F22E9C6894994282E50AA0DFFE1CBD4E
   C2C20217831FC2AD360FF1C0DE1DE1E870102CFA99EE504C7DC0D8752A63294A
   C748DDDEFADE55C6D051F1CD54CFE7C153278962A53CEF61B875C1FD3C74E972
   242CBA0131B3B8C607BF95B378212CA9A75E318201D6308201D2020101307C30
   70310B3009060355040613025553311330110603550408130A43616C69666F72
   6E69613111300F0603550407130853616E4A6F7365310E300C060355040A1305
   736970697431293027060355040B135369706974546573744365727469666963
   617465417574686F7269747902080090008902240001300906052B0E03021A05
   00A081B1301806092A864886F70D010903310B06092A864886F70D010701301C
   06092A864886F70D010905310F170D3034303132363139313831345A30230609
   2A864886F70D01090431160414408CCA5772916A968204FD24CC24EDAEAD3943
   95305206092A864886F70D01090F31453043300A06082A864886F70D0307300E
   06082A864886F70D030202020080300D06082A864886F70D0302020140300706
   052B0E030207300D06082A864886F70D0302020128300D06092A864886F70D01
   010105000481807795329BB23B8BB9F72526AB9CC22D93B9A37A2E69A0171D3C
   C417DD394F0A5FD4F8B082733CD9F2E26F6991031F7FF2EAD31640718502FB4C
   822771211E6228C793DA4DBBA2159227C221030FE9088CD659578EB862568087
   8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B428388966
   79089AAD95767F</hex>

   ------590F24D439B31E08745DEF0CD9397189--

   --my-boundary-9--



8. Transfer with multiple parties

   In 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 example section.  While this discussion
   focuses on the common cases involving PSTN gateways, similar
   situations exist for other gateways, such as H.323/SIP gateways.


10.1  Coerce Gateway Hairpins to the Originator places Same Gateway


   To illustrate how a hairpin situation can occur in transfer, consider
   this example.  The original call to dialog is setup with the Facilitator who
   reaches transferee
   residing on the Recipient through PSTN side of a SIP gateway.  The transferor is a SIP
   phone purely in the Screener. IP space.  The Recipient's contact
   information transfer target is exposed to on the Facilitator and PSTN
   side of a SIP gateway as well.  After completing the Originator. This
   example transfer,
   (regardless of consultative or blind) the transferee is provided for clarification in a call
   with the transfer target (both on the PSTN side of a gateway).  It is
   often desirable to remove the semantics gateway(s) out of the REFER
   method loop.  This is
   likely to only and should not be used as the design possible if both legs of an
   implementation.

            Originator   Facilitator   Screener   Recipient
        Call-ID  |            |            |          |
            1    |INVITE/200 OK/ACK        |          |"Get Fred for me!"
                 |----------->|            |          |     "Right away!"
            1    |INVITE (hold)/200 OK/ACK |          |
                 |<-----------|            |          |



Sparks & Johnston       Expires August 15, 2004                [Page 31]

Internet-Draft              SIP CC Transfer                February 2004


            2    |            |INVITE/200 OK/ACK      |"I have 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
                 |            |----------->|          |from Mary for Fred"
            2    |            |INVITE (hold)/200 OK/ACK   "Hold please"
                 |            |<-----------|          |
            3    |            |            |INVITE/200 OK/ACK
                 |            |            |--------->|"You that hairpins, the incoming and outgoing leg have a the same
   dialog.  The proxy should have enough information to optimize the
   routing.


   In the consultative transfer scenario, it is desirable to coerce the
   consultative INVITE out the same gateway as the original call to be
   transferred.  However there is no way to relate the consultation with
   the original call.  In the consultative case the target call INVITE
   includes the Replaces header which contains dialog information that
   can be used to relate it to the consultation.  However there is no
   information that relates the target call
                 |            |            |          |from Mary"
                 |            |            |          |  "Put her through"
            3    |            |            |INVITE (hold)/200 OK/ACK
                 |            |            |--------->|
            2    |            |REFER       |          |
                 |            |<-----------|          |
            2    |            |202 Accepted|          |
                 |            |----------->|          |
            2    |            |NOTIFY (100 Trying)    |
                 |            |----------->|          |
            2    |            |200 OK      |          |
                 |            |<-----------|          |
            2    |            |INVITE/200 OK/ACK      |
                 |            |---------------------->|"This to the original.


   In the blind transfer scenario, it is Fred"
            2    |            |NOTIFY (200 OK)        |  "Please hold for
                 |            |----------->|          |              Mary"
            2    |            |200 OK      |          |
                 |            |<-----------|          |
            2    |            |BYE/200 OK  |          |
                 |            |<-----------|          |
            3    |            |            |BYE/200 OK|
                 |            |            |--------->|
            2    |            |INVITE (hold)/200 OK/ACK
                 |            |---------------------->|
            1    |REFER       |            |          |
                 |<-----------|            |          |
            1    |202 Accepted|            |          |
                 |----------->|            |          |
            1    |NOTIFY (100 Trying)      |          |
                 |----------->|            |          |
            1    |200 OK      |            |          |
                 |<-----------|            |          |
            1    |INVITE/200 OK/ACK        |          |
                 |----------------------------------->| "Hey Fred"
            1    |NOTIFY (200 OK)          |          |    "Hello Mary"
                 |----------->|            |          |
            1    |200 OK      |            |          |
                 |<-----------|            |          |
            1    |BYE/200 OK  |            |          |
                 |<-----------|            |          |
            2    |            |BYE/200 OK  |          |
                 |            |---------------------->|



Sparks & Johnston desirable to coerce the target
   call onto the same gateway as the original call.  However the same
   problem exists in that the target dialog cannot be related to the
   original dialog.


   In either transfer scenario, it may be desirable to push the transfer




Sparks, et al.           Expires August 15, 2004 April 21, 2005                [Page 32] 49]
Internet-Draft              SIP CC Transfer                February                 October 2004


            1    |BYE/200 OK  |            |          |
                 |<-----------------------------------| "See you later"

   Figure 10.



   operation onto the non-SIP side of the gateway.  Presumably this is
   not possible unless all of the legs go out the same gateway.  If the
   gateway supports more than one truck group, it might also be
   necessary to get all of the legs on the same trunk group in order to
   perform the transfer on the non-SIP side of the gateway.


   Solutions to these gateway specific issues may involve new extensions
   to SIP in the future.


10.2  Consultative Turned Blind Gateway Glare


   In the consultative transfer case turned blind, there is a glare-like
   problem.  The transferor initiates the consultation INVITE, the user
   gets impatient and hangs up, transitioning this to a blind transfer.
   The transfer target on the gateway (connected through a PSTN switch
   to a single line or dumb analog phone) rings.  The user answers the
   phone just after the CANCEL is received by the transfer target.  The
   REFER and INVITE for the target call are sent.  The transferee
   attempts to setup the call on the PSTN side, but gets either a busy
   or lands in the users voicemail as the user has the handset in hand
   and off hook.


   This is another example of a race condition that this call flow can
   cause.  The recommended behavior is to use the approach described in
   Section 6.6.


11.  Changes from draft-sipping-cc-transfer-02


   o  Changed to REFERs sent out of dialog if recipient provides a GRUU.
   o  Changed to Refer-To set to GRUU if present, AOR if not, and
      Contact if AOR fails.
   o  Included transfer as an Ad-hoc conference call flow.
   o  Included semi -attended transfer discussion.  Included one
      recommended flow and two not recommended flows.
   o  Included issues from Transfer with Multiple Parties Example.

9. Issues I-D.
   o  Added section on gateway transfer issues.


12.  Changes from draft-sipping-cc-transfer-01


   o  Added example S/MIME messages in Referred-By section.
   o  Added reference and discussion of GRUUs

10.


13.  Changes from draft-sipping-cc-transfer-00


   o  Added section on use of Referred-By header.
   o  Added selected message details.
   o  Added flow for attended transfer with non-globally routable
      Contact URI.




Sparks, et al.           Expires April 21, 2005                [Page 50]
Internet-Draft              SIP CC Transfer                 October 2004



   o  Added flow for attended transfer fallback to unattended transfer.
   o  Added Security Considerations Section.

11.


14.  IANA Considerations


   None.

12.


15.  Security Considerations


   The call transfer flows shown in this document are implemented using
   the REFER and Replaces call control primitives in SIP.  As such, the
   attacks and security approaches are those detailed in the REFER and
   Replaces documents which are briefly summarized in the following
   paragraphs.  This document addresses the issue of protecting the
   Address of Record URI of a transfer target in Sections 6.1 and 6.2.


   Any REFER request must be appropriately authenticated and authorized
   using standard SIP mechanisms or calls may be hijacked.  A user agent
   may use local policy or human intervention in deciding whether or not
   to accept a REFER.  In generating NOTIFY responses based on the
   outcome of the triggered request, care should be taken in
   constructing the message/sipfrag body to ensure that no private
   information is leaked.


   An INVITE containing a Replaces header field should only be accepted
   if it has been properly authenticated and authorized using standard
   SIP mechanisms, and the requestor is authorized to perform dialog
   replacement.

13.


16.  Acknowledgments


   This draft is a collaborative product of the SIP working group.



Sparks & Johnston       Expires August 15, 2004                [Page 33]

Internet-Draft              SIP CC Transfer                February 2004
   Thanks to Rohan Mahy for his input on the use of Replaces in
   transfer.


17.  References


17.1  Normative References


   [1]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.


   [2]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
        Method", RFC 3515, April 2003.


   [3]  Mahy, R., Biggs, B., Dean, R. B. and R. Mahy, Dean, "The Session Inititation Initiation
        Protocol (SIP) 'Replaces' "Replaces" Header", draft-ietf-sip-replaces-04
        (work in progress), August 2003. RFC 3891, September 2004.




Sparks, et al.           Expires April 21, 2005                [Page 51]
Internet-Draft              SIP CC Transfer                 October 2004



   [4]  Sparks, R., "The SIP Session Initiation Protocol (SIP) Referred-By
        Mechanism",
        draft-ietf-sip-referredby-03 (work in progress), August 2003. RFC 3892, September 2004.


   [5]  Rosenberg, J., "Obtaining and Using Globally Routable User Agent
        (UA) URIs (GRUU) in the  Session Initiation Protocol (SIP)",
        draft-ietf-sip-gruu-00
        draft-ietf-sip-gruu-02 (work in progress), January July 2004.


17.2  Informative References


   [6]   Mahy, R., "A Call Control and Multi-party usage framework for
         the Session Initiation  Protocol (SIP)",
         draft-ietf-sipping-cc-framework-03 (work in progress), October
         2003.


   [7]   Sparks, R., "Session Initiation Protocol Torture Test
         Messages",
        draft-ietf-sipping-torture-tests-03 draft-ietf-sipping-torture-tests-04 (work in
         progress), July 2004.


   [8]   Rosenberg, J., "A Framework for Conferencing with the Session
         Initiation Protocol",
         draft-ietf-sipping-conferencing-framework-03 (work in
         progress), October 2004.


   [9]   Johnston, A. and O. Levin, "Session Initiation Protocol Call
         Control - Conferencing for User Agents",
         draft-ietf-sipping-cc-conferencing-04 (work in progress), July
         2004.


   [10]  Rosenberg, J. and H. Schulzrinne, "A Session Initiation
         Protocol (SIP) Event Package for Conference State",
         draft-ietf-sipping-conference-package-05 (work in progress),
         July 2004.


   [11]  Sparks, R., "Multiple Dialog Usages in the Session Initiation
         Protocol", draft-sparks-sipping-dialogusage-00 (work in
         progress), January July 2004.



Authors' Addresses


   Robert J. Sparks
   dynamicsoft
   5100 Tennyson Parkway
   Suite 1200
   Plano, TX  75024


   EMail: rsparks@dynamicsoft.com







Sparks & Johnston





Sparks, et al.           Expires August 15, 2004 April 21, 2005                [Page 34] 52]
Internet-Draft              SIP CC Transfer                February                 October 2004



   Alan Johnston
   MCI
   100 South 4th Street
   St. Louis, MO  63102


   EMail: alan.johnston@mci.com













































Sparks & Johnston



   Daniel Petrie
   Pingtel Corp.
   400 W. Cummings Park
   Suite 2200
   Woburn, MA  01801


   EMail: dpetrie@pingtel.com





































Sparks, et al.           Expires August 15, 2004 April 21, 2005                [Page 35] 53]
Internet-Draft              SIP CC Transfer                February                 October 2004



Intellectual Property Statement


   The IETF takes no position regarding the validity or scope of any
   intellectual property
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation RFC documents can be
   found in BCP-11. BCP 78 and BCP 79.


   Copies of
   claims of rights IPR disclosures made available for publication to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementors implementers or users of this
   specification can be obtained from the IETF Secretariat. on-line IPR repository at
   http://www.ietf.org/ipr.


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which that may cover technology that may be required to practice implement
   this standard.  Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2004). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose at
   ietf-ipr@ietf.org.



Disclaimer of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees. Validity


   This document and the information contained herein is are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIMS DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION



Sparks & Johnston       Expires August 15, 2004                [Page 36]

Internet-Draft              SIP CC Transfer                February 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



Copyright Statement


   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.



Acknowledgment


   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Sparks & Johnston




Sparks, et al.           Expires August 15, 2004 April 21, 2005                [Page 37] 54] 
----