[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 RFC 5589

SIPPING WG                                                     R. Sparks
Internet-Draft                                               dynamicsoft
Expires: April 25, 2003                                      A. Johnston
                                                                WorldCom
                                                        October 25, 2002


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

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

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

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

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

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

   This Internet-Draft will expire on April 25, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2002).  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        Expires April 25, 2003                 [Page 1]

Internet-Draft              SIP CC Transfer                 October 2002


Table of Contents

   1.    Overview . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    Changes from draft-sparks-sip-cc-transfer-06 . . . . . . . .  3
   3.    Actors and Roles . . . . . . . . . . . . . . . . . . . . . .  3
   4.    Requirements . . . . . . . . . . . . . . . . . . . . . . . .  4
   5.    Using REFER to achieve Call Transfer . . . . . . . . . . . .  5
   6.    Basic Transfer . . . . . . . . . . . . . . . . . . . . . . .  5
   6.1   Successful Transfer  . . . . . . . . . . . . . . . . . . . .  6
   6.2   Failed Transfer  . . . . . . . . . . . . . . . . . . . . . .  7
   6.2.1 Target Busy  . . . . . . . . . . . . . . . . . . . . . . . .  7
   6.2.2 Transfer Target does not answer  . . . . . . . . . . . . . .  8
   7.    Transfer with Consultation Hold  . . . . . . . . . . . . . .  9
   7.1   Exposing transfer target . . . . . . . . . . . . . . . . . .  9
   7.2   Protecting transfer target . . . . . . . . . . . . . . . . . 11
   7.3   Attended Transfer  . . . . . . . . . . . . . . . . . . . . . 12
   7.4   Recovery when one party does not support REFER . . . . . . . 13
   7.5   Consultation Hold in the presence of forking proxies . . . . 14
   7.6   Aborting a Consultation Hold . . . . . . . . . . . . . . . . 16
   8.    Transfer with multiple parties . . . . . . . . . . . . . . . 16
   9.    Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . 18
   10.   To Do  . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
   11.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 18
         References . . . . . . . . . . . . . . . . . . . . . . . . . 18
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 20

























Sparks & Johnston        Expires April 25, 2003                 [Page 2]

Internet-Draft              SIP CC Transfer                 October 2002


1. Overview

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

   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 [3] and Replaces [4]
   header field to achieve call transfer.

2. Changes from draft-sparks-sip-cc-transfer-06

   o  Fixed Call-ID errors

   o  Added Replaces requirement

   o  Added Supported, Allow, etc requirement

   o  Removed use of Accept-Contact header

   o  Added language about creation of routable Contact URI

   o  Updated flows for refer-06 behavior

   o  Editorial cleanup


3. 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:




Sparks & Johnston        Expires April 25, 2003                 [Page 3]

Internet-Draft              SIP CC Transfer                 October 2002


        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.

        Recipient -   the party the Originator is ultimately connected to.


4. Requirements

   1.  Any party in a SIP session MUST be able to transfer any other
       party in that session at any point in that session.

   2.  The Transferor and the Transferee MUST NOT be removed from a
       session as part of a transfer transaction.

             At first glance, requirement 2 may seem to indicate
             that the user experience in a transfer must be
             significantly different from what a current 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).

   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.








Sparks & Johnston        Expires April 25, 2003                 [Page 4]

Internet-Draft              SIP CC Transfer                 October 2002


5. Using REFER to achieve Call Transfer

   A REFER [3] 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.  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.

6. Basic Transfer

   Basic Transfer consists of the Transferor providing the Transfer
   Target's contact to the Transferee.  The Transferee attempts to
   establish a session using that contact and reports the results of
   that attempt to the Transferor.  The signaling relationship between
   the Transferor and Transferee is not terminated, so the call is
   recoverable if the Transfer Target cannot be reached.  Note that the
   Transfer Target's contact information has been exposed to the
   Transferee.  The provided contact can be used to make new calls in
   the future.

   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.

   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 the UA
   or using the conferencing extensions for example) are valid.

   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".



Sparks & Johnston        Expires April 25, 2003                 [Page 5]

Internet-Draft              SIP CC Transfer                 October 2002


6.1 Successful Transfer


              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 |                    |------------------->|
                   |                    |  200 OK            |
         Call-ID:2 |                    |<-------------------|
                   |                    |  ACK               |
         Call-ID:2 |                    |------------------->|
                   |  NOTIFY (200 OK)   |                    |
         Call-ID:1 |<-------------------|                    |
                   |            200 OK  |                    |
         Call-ID:1 |------------------->|                    |
                   |  BYE               |                    |
         Call-ID:1 |------------------->|                    |
                   |  200 OK            |                    |
         Call-ID:1 |<-------------------|                    |
                   |                    |             BYE    |
         Call-ID:2 |                    |<-------------------|
                   |                    |             200 OK |
         Call-ID:2 |                    |------------------->|

    Figure 1.  Basic Transfer Call Flow.






Sparks & Johnston        Expires April 25, 2003                 [Page 6]

Internet-Draft              SIP CC Transfer                 October 2002


6.2 Failed Transfer

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

6.2.1 Target Busy


              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 |                    |------------------->|
                   |                    |  486 Busy Here     |
         Call-ID:2 |                    |<-------------------|
                   |                    |  ACK               |
         Call-ID:2 |                    |------------------->|
                   |    NOTIFY (503 Service Unavailable)     |
                   | or NOTIFY (486 Busy Here)               |
         Call-ID:1 |<-------------------|                    |
                   |            200 OK  |                    |
         Call-ID:1 |------------------->|                    |
                   |  INVITE (unhold)   |                    |
         Call-ID:1 |------------------->|                    |
                   |  200 OK            |                    |
         Call-ID:1 |<-------------------|                    |
                   |  ACK               |                    |



Sparks & Johnston        Expires April 25, 2003                 [Page 7]

Internet-Draft              SIP CC Transfer                 October 2002


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

    Figure 2.  Failed Transfer - Target Busy

6.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       |
         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)       |



Sparks & Johnston        Expires April 25, 2003                 [Page 8]

Internet-Draft              SIP CC Transfer                 October 2002


         Call-ID:1 |<-------------------|                    |
                   |            200 OK  |                    |
         Call-ID:1 |------------------->|                    |
                   |  INVITE (unhold)   |                    |
         Call-ID:1 |------------------->|                    |
                   |  200 OK            |                    |
         Call-ID:1 |<-------------------|                    |
                   |  ACK               |                    |
         Call-ID:1 |------------------->|                    |
                   |  BYE               |                    |
         Call-ID:1 |------------------->|                    |
                   |  200 OK            |                    |
         Call-ID:1 |<-------------------|                    |

    Figure 3.  Failed Transfer - Target Does Not Answer.

7. Transfer with Consultation Hold

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

7.1 Exposing transfer target

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

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

















Sparks & Johnston        Expires April 25, 2003                 [Page 9]

Internet-Draft              SIP CC Transfer                 October 2002


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

    Figure 4.  Transfer with Consultation Hold - Exposing Transfer
   Target.



















Sparks & Johnston        Expires April 25, 2003                [Page 10]

Internet-Draft              SIP CC Transfer                 October 2002


7.2 Protecting transfer target

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

   One of the problems with this simplest implementation of a target
   protecting transfer is that the transferee is receiving a new call
   from the transfer-target.  Unless the transferee's agent has a
   reliable way to associate this new call with the call it already has
   with the transferor, it will have to alert the new call on another
   appearance.  If this, or some other call-waiting-like UI were not
   available, the 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 provided directly as header parameters in the Refer-To: URI
   for example.  The Replaces mechanism [4] 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 [4] this
   is the Call-ID, To-tag and From-tag.

   Note that the transferee's agent emits a BYE to the transferor's
   agent as an immediate consequence of processing the Replaces header.

   The Transferor knows that both the Transferee and the Transfer Target
   support the Replaces header from the Supported: replaces header
   contained in the 200 OK responses from both.


















Sparks & Johnston        Expires April 25, 2003                [Page 11]

Internet-Draft              SIP CC Transfer                 October 2002


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


    Figure 5.  Transfer Protecting Transfer Target.

7.3 Attended Transfer

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








Sparks & Johnston        Expires April 25, 2003                [Page 12]

Internet-Draft              SIP CC Transfer                 October 2002


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

    Figure 6.  Attended Transfer Call Flow.

7.4 Recovery when one party does not support REFER

   If protecting or exposing the transfer target is not a concern, it is
   possible to complete a transfer with consultation hold when only the
   transferor and one other party support REFER.  Note that a 405 Method
   Not Allowed might be returned instead of the 501 Not Implemented
   response.










Sparks & Johnston        Expires April 25, 2003                [Page 13]

Internet-Draft              SIP CC Transfer                 October 2002


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

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

7.5 Consultation Hold in the presence of forking proxies

   It is worth noting that the examples given above abstract away any
   proxies that might be between the three parties.  In the examples of
   Figures 4, 5, and 6, the URI used to reach the Transfer Target may go
   through a forking proxy.  There is no guarantee that the Transferee's
   and Transferor's invitations to the Transfer Target will reach the
   same endpoint.  If the proxy forked in parallel, both invitations
   could cause multiple endpoints to ring.




Sparks & Johnston        Expires April 25, 2003                [Page 14]

Internet-Draft              SIP CC Transfer                 October 2002


   To increase the probability of the desired behavior of having the
   referred invite reach and ring only the same endpoint as the
   consultation invite, the Transferor SHOULD issue the REFER request
   with the Refer-To: header containing the Contact URI the Transfer
   Target provided in its 200 OK to the Transferor's INVITE.  If that
   REFER fails, the Transferor SHOULD issue another REFER with the
   Refer-To: header containing the URI it used to reach the Transfer
   Target, augmented with a Require: replaces header field.

   This ensures that only the endpoint which has the active dialog will
   accept the INVITE request.

   Note that the Require:replaces header is necessary so that a if the
   request is forked to a different endpoint which does not support
   Replaces, the endpoint will respond with a 420 Bad Extension instead
   of accepting the INVITE.

   Note that any RFC 3261 compliant will generate a Contact URI which is
   routable outside a dialog as per Section 8.1.1.8 of RFC 3261.  For a
   UA which requires all request to be routed through a proxy (such as
   for NAT/firewall traversal or screening/feature reasons), special
   care must be taken in constructing the Contact URI.  One approach is
   to construct a URI which is unique for the device which resolves to
   the proxy.  A registration would then be required to bind this URI to
   a URI which resolves directly to the device.

   For example, consider a UA with a username carol and a hostname
   server51.chicago.com.  A normal Contact would be automatically
   generated in the form:

      Contact: sip:carol@serv51.chicago.com

   However, if this UA requires that all requests come through a proxy
   server at p1.chicago.com then this Contact will not work as the proxy
   will be bypassed.

   Another approach would involve a Contact of the form:

      Contact: sip:serv51@chicago.com

   in which this sip:serv51@chicago.com URI would be registered by the
   UA against a Contact:

      Contact: sip:carol@serv51.chicago.com

   which resolves directly to the UA.

   This means that a UA would first register a URI that corresponds to



Sparks & Johnston        Expires April 25, 2003                [Page 15]

Internet-Draft              SIP CC Transfer                 October 2002


   the device.  Then, it would register a users URI (AOR) and use the
   device URI that it registered as the Contact URI.

   An alternative approach (which is not compatible with unextended RFC
   2543 or 3261) would be to include an escaped loose Route header field
   in the Contact URI:

    Contact: sip:carol@serv51.chicago.com?Route=sip:p1.chicago.com;lr

   This would result in a request being sent to
   sip:carol@serv51.chicago.com with a loose Route header forcing
   routing to sip:p1.chicago.com first.

              Open Issue: This syntax, while allowed in a redirection, is not
              permitted in an INVITE or 200 OK response per Table 1 in RFC 3261.

   Other approaches may also be used to generate this globally routable
   Contact URI.

7.6 Aborting a Consultation Hold

   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, he 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 true implementation of this
   feature requires a short ad-hoc conference between all parties, which
   ensures that no media clipping occurs.  This flow is outside the
   scope of this document.

   For flows that expose the transfer target, this simply becomes a
   basic transfer.

   This scenario is far more complicated for flows that protect the
   transfer target.  Since no session is established between the
   transferor and 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).

8. Transfer with multiple parties

   In this example the Originator places call to the Facilitator who



Sparks & Johnston        Expires April 25, 2003                [Page 16]

Internet-Draft              SIP CC Transfer                 October 2002


   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
                 |            |----------->|          |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
                 |            |            |--------->|
            2    |            |REFER       |          |
                 |            |<-----------|          |
            2    |            |202 Accepted|          |
                 |            |----------->|          |
            2    |            |NOTIFY (100 Trying)    |
                 |            |----------->|          |
            2    |            |200 OK      |          |
                 |            |<-----------|          |
            2    |            |INVITE/200 OK/ACK      |
                 |            |---------------------->|"This 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)      |          |
                 |----------->|            |          |



Sparks & Johnston        Expires April 25, 2003                [Page 17]

Internet-Draft              SIP CC Transfer                 October 2002


            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  |          |
                 |            |---------------------->|
            1    |BYE/200 OK  |            |          |
                 |<-----------------------------------| "See you later"

   Figure 8.  Transfer with Multiple Parties Example.

9. Open Issues

   The creation of globally routable Contact URIs and the use of escaped
   Route headers in Contact header fields in INVITE and 200 OK
   responses.

10. To Do

   Add message details to all the call flows.

11. Acknowledgments

   This draft is a collaborative product of the SIP working group.
   Thanks to Rohan Mahy for his input on the use of Replaces in
   transfer.

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]  Mahy, R., Campbell, B., Johnston, A., Petrie, D., Rosenberg, J.
        and R. Sparks, "A Multi-party Application Framework for SIP",
        draft-ietf-sipping-cc-framework-01 (work in progress), June
        2002.

   [3]  Sparks, R., "The REFER Method", draft-ietf-sip-refer-06 (work in
        progress), July 2002.

   [4]  Mahy, R., Biggs, B. and R. Dean, "The SIP Replaces Header",



Sparks & Johnston        Expires April 25, 2003                [Page 18]

Internet-Draft              SIP CC Transfer                 October 2002


        draft-ietf-sipping-replaces-02 (work in progress), April 2002.


Authors' Addresses

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

   EMail: rsparks@dynamicsoft.com


   Alan Johnston
   WorldCom
   100 South 4th Street
   St. Louis, MO  63104

   EMail: alan.johnston@wcom.com































Sparks & Johnston        Expires April 25, 2003                [Page 19]

Internet-Draft              SIP CC Transfer                 October 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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 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 assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

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



















Sparks & Johnston        Expires April 25, 2003                [Page 20]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/