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

Versions: (draft-sparks-sip-cc-transfer) 00 01 02 03 04 05

Network Working Group                                          R. Sparks
Internet-Draft                                               dynamicsoft
Expires: January 16, 2002                                  July 18, 2001


                      SIP Call Control - Transfer
                    draft-ietf-sip-cc-transfer-05

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 January 16, 2002.

Copyright Notice

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

Abstract

   This document describes providing Call Transfer capabilites in SIP.
   Transfer capabilities.  This work is part of the Call Control
   Framework.












Sparks                  Expires January 16, 2002                [Page 1]

Internet-Draft         SIP Call Control - Transfer             July 2001


Table of Contents

   1.    Overview . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    Changes from draft-sparks-sip-cc-transfer-04 . . . . . . . .  3
   3.    Actors and Roles . . . . . . . . . . . . . . . . . . . . . .  3
   4.    Requirements . . . . . . . . . . . . . . . . . . . . . . . .  4
   5.    Using REFER to achieve Call Transfer . . . . . . . . . . . .  4
   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 . . . . . . . . . . . . . . . . . 10
   7.3   Recovery when one party does not support REFER . . . . . . . 10
   7.4   Consultation Hold in the presence of forking proxies . . . . 11
   7.5   Using the Replaces header to improve the Consultation Hold
         experience . . . . . . . . . . . . . . . . . . . . . . . . . 12
   7.5.1 Consultation Hold protecting transfer target . . . . . . . . 12
   7.5.2 Recovering from one party not supporting the Replaces header 13
   7.6   Aborting a Consultation Hold . . . . . . . . . . . . . . . . 14
   8.    Transfer with multiple parties . . . . . . . . . . . . . . . 14
   9.    Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . 15
   10.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 15
         References . . . . . . . . . . . . . . . . . . . . . . . . . 15
         Author's Address . . . . . . . . . . . . . . . . . . . . . . 16
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 17























Sparks                  Expires January 16, 2002                [Page 2]

Internet-Draft         SIP Call Control - Transfer             July 2001


1. Overview

   This document describes providing Call Transfer capabilites in SIP.
   Transfer capabilities.  This work is part of the Call Control
   Framework.

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

   Editor's note: Per working group consensus, draft-ietf-sip-cc-
   transfer-04 was split into two drafts.  This document details the use
   of REFER to achieve call transfer.  The definition of REFER itself
   was removed to draft-ietf-sip-refer-00

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

   o  Split the draft
   o  Removed the contested distinction between attended and unattended
      transfer (involving an ad-hoc conference).
   o  Added new failure and recovery flows
   o  Added flow demonstrating the use of the Replaces header to affect
      user experience

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                  Expires January 16, 2002                [Page 3]

Internet-Draft         SIP Call Control - Transfer             July 2001


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

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



Sparks                  Expires January 16, 2002                [Page 4]

Internet-Draft         SIP Call Control - Transfer             July 2001


   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 diagrams below show indicate the first line of each message.  All
   messages in a particular diagram share the same Call-ID.  In these
   diagrams, media is managed through reINVITE 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 call-leg 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 neccessary.  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.


















Sparks                  Expires January 16, 2002                [Page 5]

Internet-Draft         SIP Call Control - Transfer             July 2001


6.1 Successful Transfer


              Transferor           Transferee             Transfer
                   |                    |                  Target
                   |            INVITE  |                    |
                   |<-------------------|                    |
                   |            200 OK  |                    |
                   |------------------->|                    |
                   |            ACK     |                    |
                   |<-------------------|                    |
                   |  INVITE (hold)     |                    |
                   |------------------->|                    |
                   |  200 OK            |                    |
                   |<-------------------|                    |
                   |  ACK               |                    |
                   |------------------->|                    |
                   |  REFER             |                    |
                   |------------------->|                    |
                   |  202 Accepted      |                    |
                   |<-------------------|                    |
                   |                    |  INVITE            |
                   |                    |------------------->|
                   |                    |  200 OK            |
                   |                    |<-------------------|
                   |                    |  ACK               |
                   |                    |------------------->|
                   |  NOTIFY (200 OK)   |                    |
                   |<-------------------|                    |
                   |            200 OK  |                    |
                   |------------------->|                    |
                   |  BYE               |                    |
                   |------------------->|                    |
                   |  200 OK            |                    |
                   |<-------------------|                    |
                   |                    |             BYE    |
                   |                    |<-------------------|
                   |                    |             200 OK |
                   |                    |------------------->|












Sparks                  Expires January 16, 2002                [Page 6]

Internet-Draft         SIP Call Control - Transfer             July 2001


6.2 Failed Transfer

6.2.1 Target Busy


              Transferor           Transferee             Transfer
                   |                    |                  Target
                   |                    |                    |
                   |            INVITE  |                    |
                   |<-------------------|                    |
                   |            200 OK  |                    |
                   |------------------->|                    |
                   |            ACK     |                    |
                   |<-------------------|                    |
                   |  INVITE (hold)     |                    |
                   |------------------->|                    |
                   |  200 OK            |                    |
                   |<-------------------|                    |
                   |  ACK               |                    |
                   |------------------->|                    |
                   |  REFER             |                    |
                   |------------------->|                    |
                   |  202 Accepted      |                    |
                   |<-------------------|                    |
                   |                    |  INVITE            |
                   |                    |------------------->|
                   |                    |  486 Busy Here     |
                   |                    |<-------------------|
                   |                    |  ACK               |
                   |                    |------------------->|
                   |    NOTIFY (503 Service Unavailable)     |
                   | or NOTIFY (486 Busy Here)               |
                   |<-------------------|                    |
                   |            200 OK  |                    |
                   |------------------->|                    |
                   |  INVITE (unhold)   |                    |
                   |------------------->|                    |
                   |  200 OK            |                    |
                   |<-------------------|                    |
                   |  ACK               |                    |
                   |------------------->|                    |
                   |  BYE               |                    |
                   |------------------->|                    |
                   |  200 OK            |                    |
                   |<-------------------|                    |






Sparks                  Expires January 16, 2002                [Page 7]

Internet-Draft         SIP Call Control - Transfer             July 2001


6.2.2 Transfer Target does not answer


              Transferor           Transferee             Transfer
                   |                    |                  Target
                   |            INVITE  |                    |
                   |<-------------------|                    |
                   |            200 OK  |                    |
                   |------------------->|                    |
                   |            ACK     |                    |
                   |<-------------------|                    |
                   |  INVITE (hold)     |                    |
                   |------------------->|                    |
                   |  200 OK            |                    |
                   |<-------------------|                    |
                   |  ACK               |                    |
                   |------------------->|                    |
                   |  REFER             |                    |
                   |------------------->|                    |
                   |  202 Accepted      |                    |
                   |<-------------------|                    |
                   |                    |  INVITE            |
                   |                    |------------------->|
                   |                    |  180 Ringing       |
                   |                    |<-------------------|
                   |                    |   (Transferee gets tired of waiting)
                   |                    |  CANCEL            |
                   |                    |------------------->|
                   |                    |  200 OK (CANCEL)   |
                   |                    |<-------------------|
                   |                    |  487 Request Cancelled (INVITE)
                   |                    |<-------------------|
                   |                    |  ACK               |
                   |                    |------------------->|
                   |    NOTIFY (487 Request Cancelled)       |
                   |<-------------------|                    |
                   |            200 OK  |                    |
                   |------------------->|                    |
                   |  INVITE (unhold)   |                    |
                   |------------------->|                    |
                   |  200 OK            |                    |
                   |<-------------------|                    |
                   |  ACK               |                    |
                   |------------------->|                    |
                   |  BYE               |                    |
                   |------------------->|                    |
                   |  200 OK            |                    |
                   |<-------------------|                    |



Sparks                  Expires January 16, 2002                [Page 8]

Internet-Draft         SIP Call Control - Transfer             July 2001


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.

              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              |                    |
                   |------------------->|                    |
                   | 202 Accepted       |                    |
                   |<-------------------|                    |
         Call-ID:1 |                    |  INVITE/200 OK/ACK |
                   |                    |------------------->|
         Call-ID:1 | NOTIFY (200 OK)    |                    |
                   |<-------------------|                    |
                   |            200 OK  |                    |
                   |------------------->|                    |
         Call-ID:1 | BYE/200 OK         |                    |
                   |------------------->|                    |
         Call-ID:1 |                    |         BYE/200 OK |
                   |                    |<-------------------|







Sparks                  Expires January 16, 2002                [Page 9]

Internet-Draft         SIP Call Control - Transfer             July 2001


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.  If supported, use
   of the Replaces header can help improve this experience.  Examples of
   this usage appear later in this document.


              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 | INVITE (hold)/200 OK/ACK                |
                   |---------------------------------------->|
         Call-ID:2 | REFER              |                    |
                   |---------------------------------------->|
                   | 202 Accepted       |                    |
                   |<----------------------------------------|
         Call-ID:2 |                    |  INVITE/200 OK/ACK |
                   |                    |<-------------------|
         Call-ID:2 | NOTIFY (200 OK)    |                    |
                   |<----------------------------------------|
                   |                    |            200 OK  |
                   |---------------------------------------->|
         Call-ID:1 | BYE/200 OK         |                    |
                   |------------------->|                    |
         Call-ID:2 | BYE/200 OK         |                    |
                   |---------------------------------------->|
         Call-ID:2 |                    |  BYE/200 OK        |
                   |                    |------------------->|


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




Sparks                  Expires January 16, 2002               [Page 10]

Internet-Draft         SIP Call Control - Transfer             July 2001


              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 | INVITE (hold)/200 OK/ACK                |
                   |---------------------------------------->|
         Call-ID:1 | REFER              |                    |
                   |------------------->|                    |
         Call-ID:1 | 501 Not Implemented
                   |<-------------------|                    |
         Call-ID:2 | REFER              |                    |
                   |---------------------------------------->|
                   | 202 Accepted       |                    |
                   |<----------------------------------------|
         Call-ID:2 |                    |  INVITE/200 OK/ACK |
                   |                    |<-------------------|
         Call-ID:2 | NOTIFY (200 OK)    |                    |
                   |<----------------------------------------|
                   |                    |            200 OK  |
                   |---------------------------------------->|
         Call-ID:1 | BYE/200 OK         |                    |
                   |------------------->|                    |
         Call-ID:2 | BYE/200 OK         |                    |
                   |---------------------------------------->|
         Call-ID:2 |                    |  BYE/200 OK        |
                   |                    |------------------->|


7.4 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 4.5.1 for
   example, the URL 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.  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 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 URL it



Sparks                  Expires January 16, 2002               [Page 11]

Internet-Draft         SIP Call Control - Transfer             July 2001


   used to reach the Transfer Target, augmented with an Accept-Contact
   header containing the Contact the Transfer Target provided.

7.5 Using the Replaces header to improve the Consultation Hold
    experience

7.5.1 Consultation Hold protecting transfer target

   One of the problems with the 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 call leg
   parameters could be provided directly as header parameters in the
   Refer-To: URL for example.  The Replaces mechanism [4] uses this
   approach and solves this problem nicely.

   For the flow below, clid1 means Call Leg Identifier 1, and consists
   of the parameters to the Replaces header for call-leg 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.
























Sparks                  Expires January 16, 2002               [Page 12]

Internet-Draft         SIP Call Control - Transfer             July 2001


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


7.5.2 Recovering from one party not supporting the Replaces header

   Similar to the case of recovering from a party not supporting REFER,
   the transferor can recover from a party not supporting the Replaces
   header, at the potential cost of not protecting the transfer target
   and reverting to the non-Replaces user experience.

   In the above flow, if all of the following are true:
   o  The Transferee's agent does not support the Replaces header
   o  The Transferee's agent does not support multiple appearences or
      call-waiting and returns Busy-Here to all new INVITEs when engaged
      in a call.
   o  The Transfer-Target's agent is configured to expose the cause of a
      REFERenced action failure in its NOTIFY (see the security issues
      associated with this choice in [3]).
   o  The Transferor is willing to expose the Transfer-Target.
   then the Transferor can retry the transfer by sending a new REFER to
   the Transferee.



Sparks                  Expires January 16, 2002               [Page 13]

Internet-Draft         SIP Call Control - Transfer             July 2001


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
   evenutally talking to the transfer-target's voice-mail service.

   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
   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       |          |
                 |            |<-----------|          |
                 |            |202 Accepted|          |



Sparks                  Expires January 16, 2002               [Page 14]

Internet-Draft         SIP Call Control - Transfer             July 2001


                 |            |----------->|          |
            2    |            |INVITE/200 OK/ACK      |
                 |            |---------------------->|"This is Fred"
            2    |            |NOTIFY (200 OK)        |  "Please hold for
                 |            |----------->|          |              Mary"
                 |            |200 OK      |          |
                 |            |<-----------|          |
            2    |            |BYE/200 OK  |          |
                 |            |<-----------|          |
            3    |            |            |BYE/200 OK|
                 |            |            |--------->|
            2    |            |INVITE (hold)/200 OK/ACK
                 |            |---------------------->|
            1    |REFER       |            |          |
                 |<-----------|            |          |
                 |202 Accepted|            |          |
                 |----------->|            |          |
            1    |INVITE/200 OK/ACK        |          |
                 |----------------------------------->| "Hey Fred"
            1    |NOTIFY (200 OK)          |          |    "Hello Mary"
                 |----------->|            |          |
                 |200 OK      |            |          |
                 |<-----------|            |          |
            1    |BYE/200 OK  |            |          |
                 |<-----------|            |          |
            2    |            |BYE/200 OK  |          |
                 |            |---------------------->|
            1    |BYE/200 OK  |            |          |
                 |<-----------------------------------| "See you later"


9. Open Issues

10. Acknowledgments

   This draft is a collaborative product of the SIP working group.
   Thanks to Alan Johnston for providing the starting point for the new
   error and recovery flows.

References

   [1]  Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
        "SIP: Session Initiation Protocol", RFC 2543, March 1999.

   [2]  Campbell, B., "Framework for SIP Call Control Extensions",
        draft-ietf-sip-cc-framework-00 (work in progress), March 2000.

   [3]  Sparks, R., "The REFER Method", draft-ietf-sip-refer-00 (work in



Sparks                  Expires January 16, 2002               [Page 15]

Internet-Draft         SIP Call Control - Transfer             July 2001


        progress), July 2001.

   [4]  Biggs, B. and R. Dean, "The SIP Replaces Header", draft-biggs-
        sip-replaces-00 (work in progress), November 2000.


Author's Address

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

   EMail: rsparks@dynamicsoft.com




































Sparks                  Expires January 16, 2002               [Page 16]

Internet-Draft         SIP Call Control - Transfer             July 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  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                  Expires January 16, 2002               [Page 17]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/