[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05                                             
Internet Engineering Task Force                                R. Sparks
Internet-Draft                                               dynamicsoft
Expires: August 3, 2001                                 February 2, 2001


                      SIP Call Control - Transfer
                        draft-sip-cc-transfer-03

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 August 3, 2001.

Copyright Notice

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

Abstract

   This document defines a SIP extension within the Call Control
   Framework and demonstrates its use to provide Call Transfer
   capabilities.












Sparks                   Expires August 3, 2001                 [Page 1]


Internet-Draft        SIP Call Control - Transfer          February 2001


Table of Contents

   1.    Overview . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    Changes from draft-sparks-sip-cc-transfer-02 . . . . . . . .  3
   3.    The REFER Method . . . . . . . . . . . . . . . . . . . . . .  3
   3.1   The Refer-To Header  . . . . . . . . . . . . . . . . . . . .  3
   3.1.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.2   The Referred-By Header . . . . . . . . . . . . . . . . . . .  4
   3.2.1 A PGP based signature-scheme . . . . . . . . . . . . . . . .  5
   3.2.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.3   Header Field Support for the REFER Method  . . . . . . . . .  6
   3.4   Message Body Inclusion . . . . . . . . . . . . . . . . . . .  7
   3.5   Responses within the REFER transaction . . . . . . . . . . .  7
   3.6   Behavior of SIP User Agents  . . . . . . . . . . . . . . . .  7
   3.6.1 Accessing the referred-to resource . . . . . . . . . . . . .  7
   3.6.2 Reporting on the results of the reference  . . . . . . . . .  8
   3.7   Behavior of SIP Registrars/Redirect Servers  . . . . . . . .  8
   3.8   Behavior of SIP Proxies  . . . . . . . . . . . . . . . . . .  8
   3.9   Prototypical REFER callflow  . . . . . . . . . . . . . . . .  9
   3.10  Security Considerations  . . . . . . . . . . . . . . . . . .  9
   4.    Call Transfer  . . . . . . . . . . . . . . . . . . . . . . .  9
   4.1   Actors and Roles . . . . . . . . . . . . . . . . . . . . . .  9
   4.2   Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10
   4.3   Using REFER to achieve Call Transfer . . . . . . . . . . . . 10
   4.4   Unattended Transfer  . . . . . . . . . . . . . . . . . . . . 11
   4.4.1 Successful Unattended Transfer . . . . . . . . . . . . . . . 12
   4.4.2 Failed Unattended Transfer . . . . . . . . . . . . . . . . . 13
   4.5   Unattended Transfer with Consultation Hold . . . . . . . . . 13
   4.5.1 Variation 1 : Exposes transfer target  . . . . . . . . . . . 14
   4.5.2 Variation 2 : Protects transfer target . . . . . . . . . . . 15
   4.5.3 Consultation Hold in the presence of forking proxies . . . . 15
   4.6   Attended Transfer  . . . . . . . . . . . . . . . . . . . . . 16
   4.7   Transfer with multiple parties . . . . . . . . . . . . . . . 16
   5.    Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . 17
   5.1   200 vs 202 . . . . . . . . . . . . . . . . . . . . . . . . . 17
   5.2   Should REFER expire? . . . . . . . . . . . . . . . . . . . . 17
   5.3   REFER is now dependent on sip-events . . . . . . . . . . . . 17
   5.4   Registering the events with IANA . . . . . . . . . . . . . . 18
   6.    Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 18
         References . . . . . . . . . . . . . . . . . . . . . . . . . 18
         Author's Address . . . . . . . . . . . . . . . . . . . . . . 18
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 19









Sparks                   Expires August 3, 2001                 [Page 2]


Internet-Draft        SIP Call Control - Transfer          February 2001


1. Overview

   This document defines a SIP[1] extension and details its use to
   provide Call Transfer capabilities. This is part of a family of Call
   Control extensions described in the Call Control Framework[2]
   document.

   The mechanisms discussed here are most closely related to
   traditional unattended and consultation hold transfers. Discussion
   of attended transfer (where all parties are briefly in a conference)
   is deferred until the conferencing features in this framework are
   addressed.

   This work has roots in draft-ietf-sip-cc-01[4] but some basic
   semantics are different. In particular, transfers are achieved
   through a new method that does not terminate the original signaling
   relationship. By disassociating transfers from the processing of
   BYE, these changes facilitate recovery of failed transfers and
   clarify state management in the participating entities.

2. Changes from draft-sparks-sip-cc-transfer-02
   o  Changed the REFER response to be immediate instead of waiting for
      the referred action to complete
   o  Added use of NOTIFY to deliver the result of the referred action
   o  Removed the claim of easy migration from BYE/ALSO

3. The REFER Method

   REFER is a SIP method as defined by RFC2543[1]. The REFER method
   indicates that the recipient should contact a third party using the
   contact information provided in the method. A success response
   indicates that the recipient was able to contact the third party.
   The REFER method follows the session's current signaling path. In
   particular, the Request-URI of the REFER method identifies the
   recipient.

   Unless stated otherwise, the protocol for emitting and responding to
   a REFER request are identical to those for a BYE request in [1]. The
   behavior of SIP entities not implementing the REFER (or any other
   unknown) method is explicitly defined in [1] and is not discussed
   further here.

3.1 The Refer-To Header

   Refer-To is a request-header as defined by [1]. It may only appear
   in a REFER request.

      Refer-To = ("Refer-To" | "r") ":" URL



Sparks                   Expires August 3, 2001                 [Page 3]


Internet-Draft        SIP Call Control - Transfer          February 2001


   A REFER method MUST contain exactly one Refer-To header.

   The Refer-To header MAY be encrypted as part of end-end encryption.

             The Contact header is an important part of the
             Route/Record-Route mechanism and is not available
             for this task.

3.1.1 Examples

      Refer-To: sip:alice@atlanta.com

      Refer-To:
      sip:bob@biloxi.com?Accept-Contact=sip:bobsdesk.biloxi.com?Ca
      ll-ID=55432@alicepc.atlanta.com

      Refer-To: sip:carol@cleveland.com;method=SUBSCRIBE

      Refer-To: http://www.ietf.org

3.2 The Referred-By Header

   Referred-By is a request-header as defined by [1]. It can appear in
   any request. It conveys the identity of the original REFERrer to the
   referred-to party, optionally proving the identity and that the
   REFERrer actually issued this reference.


        Referred-By      = ("Referred-By" | "b") ":" referrer-url ";"
                              (     referenced-url
                                | ( referenced-url ";" ref-signature )
                                | ( ref-signature ";" referenced-url )
                              )
        referrer-url     = ( name-addr | addr-spec )
        referenced-url   = "ref" "=" "<" URL ">"
        ref-signature    = signature-scheme *( ";" sig-scheme-params )
        signature-scheme = "scheme" "=" token
        sig-scheme-parms = token "=" ( token | quoted-string )

   The referrer-url contains the SIP URL of the party sending the REFER
   request. The referenced-url contains a copy of the URL placed in the
   Refer-To: header. Any occurrences of < or > in the referenced-url
   MUST be escaped. The ref-signature contains a signature over the
   concatenation of referrer-url and referenced-url.  An example
   signature scheme is given in section 3.1.2.

   A REFER request MUST contain exactly one Referred-By header.

   (Open Issue: Should Refer Expire? (Section 5.2).)


Sparks                   Expires August 3, 2001                 [Page 4]


Internet-Draft        SIP Call Control - Transfer          February 2001


   The Referred-By header SHOULD be signed to help detection of REFERs
   from unauthorized third parties. A signed Referred-By header SHOULD
   include a Date header in the referrer-url to facilitate detection of
   replay attacks.

   A UA MAY reject a request containing an unsigned Referred-By header.
   A UA SHOULD verify the signature on any Referred-By header it
   receives.

   The Referred-By header MAY be encrypted as part of end-end
   encryption.

3.2.1 A PGP based signature-scheme

   One signature-scheme for Referred-By headers uses PGP as follows:

        signature-scheme = "scheme" "=" "pgp"
        sig-scheme-parms = pgp-version | signed-by | pgp-signature

   pgp-version, signed-by and pgp-signature are defined in section 15.1
   of RFC2543, with the modification that the signature is computed
   across the concatenation of the referrer-url and the referenced-url.

3.2.2 Examples

      Referred-By: sip:alice@atlanta.com;ref=<http:www.ietf.org>

      Referred-By: "Bob"
      <sip:bob@biloxi.com>;ref=<sip:alice@atlanta.com>;scheme=pgp;pgp-version="5.0";signature="the signature"


      (Note that in the last example, the signature would be over the
      string "sip:bob@biloxi.comsip:alice@atlanta.com")


















Sparks                   Expires August 3, 2001                 [Page 5]


Internet-Draft        SIP Call Control - Transfer          February 2001


3.3 Header Field Support for the REFER Method

   This table adds a column to tables 4 and 5 in [1], describing header
   presence in a REFER method. See [1] for a key for the symbols used.
   A row for the Refer-To: and Referred-By request-header should be
   inferred, each mandatory for REFER. Refer-To is not applicable for
   all other methods. Referred-By is a general Request header. The enc
   and e-e columns in [1] apply to the REFER method unmodified.

            Header                    Where  REFER
            Accept                      R       -
            Accept-Encoding             R       -
            Accept-Language             R       o
            Allow                       R       -
            Allow                      405      m
            Authorization               R       o
            Call-ID                    gc       m
            Contact                     R       o
            Contact                    1xx      -
            Contact                   2-6xx     o
            Content-Encoding            e       -
            Content-Length              e       o
            Content-Type                e       -
            CSeq                       gc       m
            Date                        g       o
            Encryption                  g       o
            Expires                     R       o
            From                       gc       m
            Hide                        R       o
            Max-Forwards                R       o
            Organization                g       o
            Priority                    R       -
            Proxy-Authenticate         407      o
            Proxy-Authorization         R       o
            Proxy-Require               R       o
            Require                     R       o
            Retry-After                 R       -
            Retry-After            404,480,486  o
            Retry-After                503      o
            Retry-After              600,603    o
            Response-Key                R       o
            Record-Route                R       o
            Record-Route               2xx      o
            Route                       R       o
            Server                      r       o
            Subject                     R       -
            Timestamp                   g       o
            To                        gc(1)     m
            Unsupported                420      o


Sparks                   Expires August 3, 2001                 [Page 6]


Internet-Draft        SIP Call Control - Transfer          February 2001


            User-Agent                  g       o
            Via                       gc(2)     m
            Warning                     r       o
            WWW-Authenticate           401      o

3.4 Message Body Inclusion

   A REFER method may contain a body which SHOULD be processed
   according to its Content-Type.

3.5 Responses within the REFER transaction

   An agent responding to a REFER Method MUST return a 400 Bad Request
   if the request contained zero or more than one Refer-To headers. An
   agent responding to a REFER Method MUST return a 400 Bad Request if
   the request contained zero or more than one Referred-By headers. An
   agent (including proxies generating local responses) MAY return a
   100 Trying or any appropriate 400-600 class response as prescribed
   by [1]. If the recipient's agent decides to contact the resource in
   the Refer-To header, a 200 OK response MUST be returned before the
   REFER transaction expires. (Open Issue: Should this be a 202
   Accepted?) (Section 5.1)

   Editor's note - The previous version of this draft required the
   agent responding to REFER to wait until the referred action
   completed before sending a final response to the REFER. That final
   response reflected the success or failure of the referred action.
   This was infeasible due to the transaction timeout rules defined for
   non-INVITE requests in [1]. A REFER must always receive an immediate
   (within the lifetime of a non-INVITE transaction) final response.

3.6 Behavior of SIP User Agents

3.6.1 Accessing the referred-to resource

   A UA receiving a well-formed REFER request SHOULD request approval
   from the user to proceed (this request could be interactive or
   through configuration). Upon receiving approval from the user, the
   UA MUST contact the resource identified by the URL in the Refer-To:
   header. Note that if the URL is a SIP URL, it could contain header
   fields such as Call-Id that will be used to form the resulting
   request. If the URL is a SIP URL, the Referred-By header in the
   REFER request should be copied into the request sent to the
   referred-to resource.







Sparks                   Expires August 3, 2001                 [Page 7]


Internet-Draft        SIP Call Control - Transfer          February 2001


3.6.2 Reporting on the results of the reference

   Once it is known whether the reference succeeded or failed, the UA
   receiving the REFER SHOULD notify the agent sending the refer using
   the NOTIFY mechanism defined in Event Notification in SIP[3] as if
   the the REFER had established a subscription. In particular:

   o  The NOTIFY should reflect the To:, From:, and Call-ID headers
      from the REFER as if they had arrived in a SUBSCRIBE.

   o  If the reference succeeded, the NOTIFY MUST contain Event:
      refersuccess

   o  If the reference failed for any reason, or was not attempted
      after being accepted, the NOTIFY MUST contain Event: referfailure

   o  The notifying UA SHOULD send exactly one NOTIFY with an event
      from the profile {refersuccess,referfailure}. If multiple
      notifications are sent, perhaps including events from other
      extension drafts, the UA MUST NOT send both refersuccess and
      referfailure events.

   o  Analogous to the case for SUBSCRIBE described in [3], the agent
      that issued the REFER MUST be prepared to receive a NOTIFY before
      the REFER transaction completes.

   Open Issue: This makes REFER dependent on sip-events (Section 5.3)

   Open Issue: The events will need to be registered with IANA (Section
   5.4)

3.7 Behavior of SIP Registrars/Redirect Servers

   Registrars and Redirect Servers SHOULD return a 603 to a REFER
   request, unless they are also playing some other SIP role.

3.8 Behavior of SIP Proxies

   SIP Proxies do not require modification to support the REFER method.
   Specifically, as required by [1], a proxy should process a REFER
   request the same way it processes an OPTIONS request.










Sparks                   Expires August 3, 2001                 [Page 8]


Internet-Draft        SIP Call Control - Transfer          February 2001


3.9 Prototypical REFER callflow

          Agent A                  Agent B
             |                        |
             |   REFER                |
             |----------------------->|
             |            200 OK      |
             |<-----------------------|
             |                        |
             |                        |------->
             |                        |  (whatever)
             |                        |<------
             |                        |
             |            NOTIFY      |
             |<-----------------------|
             |   200 OK               |
             |----------------------->|
             |                        |
             |                        |

3.10 Security Considerations

   The security requirements of [1] apply to the REFER method.

   This mechanism relies on providing contact information for the
   referred-to resource to the party being referred. Care should be
   taken to provide a suitably restricted URI if the referred to
   resource should be protected.

   Care should be taken when implementing the logic that determines
   whether or not to accept the REFER request. A UA not capable of
   accessing non-SIP URLs SHOULD NOT accept REFER requests to them.

4. Call Transfer

4.1 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


Sparks                   Expires August 3, 2001                 [Page 9]


Internet-Draft        SIP Call Control - Transfer          February 2001


   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.

        Recipient -   the party the Originator is ultimately connected to.

4.2 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 unattended 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 draft-ietf-sip-cc-01).

4.3 Using REFER to achieve Call Transfer

   A REFER 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


Sparks                   Expires August 3, 2001                [Page 10]


Internet-Draft        SIP Call Control - Transfer          February 2001


   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.

4.4 Unattended Transfer

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






























Sparks                   Expires August 3, 2001                [Page 11]


Internet-Draft        SIP Call Control - Transfer          February 2001


4.4.1 Successful Unattended Transfer

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













Sparks                   Expires August 3, 2001                [Page 12]


Internet-Draft        SIP Call Control - Transfer          February 2001


4.4.2 Failed Unattended Transfer

              Transferor           Transferee             Transfer
                   |                    |                  Target
                   |                    |                    |
                   |            INVITE  |                    |
                   |<-------------------|                    |
                   |            200 OK  |                    |
                   |------------------->|                    |
                   |            ACK     |                    |
                   |<-------------------|                    |
                   |  INVITE (hold)     |                    |
                   |------------------->|                    |
                   |  200 OK            |                    |
                   |<-------------------|                    |
                   |  ACK               |                    |
                   |------------------->|                    |
                   |  REFER             |                    |
                   |------------------->|                    |
                   |  200 OK            |                    |
                   |<-------------------|                    |
                   |                    |  INVITE            |
                   |                    |------------------->|
                   |                    |  486 Busy Here     |
                   |                    |<-------------------|
                   |                    |  ACK               |
                   |                    |------------------->|
                   |  NOTIFY (referfailure)                  |
                   |<-------------------|                    |
                   |            200 OK  |                    |
                   |------------------->|                    |
                   |  INVITE (unhold)   |                    |
                   |------------------->|                    |
                   |  200 OK            |                    |
                   |<-------------------|                    |
                   |  ACK               |                    |
                   |------------------->|                    |
                   |  BYE               |                    |
                   |------------------->|                    |
                   |  200 OK            |                    |
                   |<-------------------|                    |

4.5 Unattended 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 Unattended
   Transfer as described above.



Sparks                   Expires August 3, 2001                [Page 13]


Internet-Draft        SIP Call Control - Transfer          February 2001


4.5.1 Variation 1 : Exposes 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 unattended 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              |                    |
                   |------------------->|                    |
                   | 200 OK             |                    |
                   |<-------------------|                    |
         Call-ID:1 |                    |  INVITE/200 OK/ACK |
                   |                    |------------------->|
         Call-ID:1 | NOTIFY (refersuccess)                   |
                   |<-------------------|                    |
                   |            200 OK  |                    |
                   |------------------->|                    |
         Call-ID:1 | BYE/200 OK         |                    |
                   |------------------->|                    |
         Call-ID:1 |                    |         BYE/200 OK |
                   |                    |<-------------------|













Sparks                   Expires August 3, 2001                [Page 14]


Internet-Draft        SIP Call Control - Transfer          February 2001


4.5.2 Variation 2 : Protects 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.

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

4.5.3 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


Sparks                   Expires August 3, 2001                [Page 15]


Internet-Draft        SIP Call Control - Transfer          February 2001


   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
   used to reach the Transfer Target, augmented with an Accept-Contact
   header containing the Contact the Transfer Target provided.

4.6 Attended Transfer

   In an attended transfer, the three actors participate in an ad-hoc
   conference as part of the event. Discussion of the implementation of
   attended transfer is thus deferred until the conferencing portion of
   the Call Control framework has been addressed.

4.7 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       |          |
                 |            |<-----------|          |
                 |            |200 OK      |          |
                 |            |----------->|          |
            2    |            |INVITE/200 OK/ACK      |
                 |            |---------------------->|"This is Fred"
            2    |            |NOTIFY (refersuccess)  |  "Please hold for
                 |            |----------->|          |              Mary"
                 |            |200 OK      |          |
                 |            |<-----------|          |


Sparks                   Expires August 3, 2001                [Page 16]


Internet-Draft        SIP Call Control - Transfer          February 2001


            2    |            |BYE/200 OK  |          |
                 |            |<-----------|          |
            3    |            |            |BYE/200 OK|
                 |            |            |--------->|
            2    |            |INVITE (hold)/200 OK/ACK
                 |            |---------------------->|
            1    |REFER       |            |          |
                 |<-----------|            |          |
                 |200 OK      |            |          |
                 |----------->|            |          |
            1    |INVITE/200 OK/ACK        |          |
                 |----------------------------------->| "Hey Fred"
            1    |NOTIFY (refersuccess)    |          |    "Hello Mary"
                 |----------->|            |          |
                 |200 OK      |            |          |
                 |<-----------|            |          |
            1    |BYE/200 OK  |            |          |
                 |<-----------|            |          |
            2    |            |BYE/200 OK  |          |
                 |            |---------------------->|
            1    |BYE/200 OK  |            |          |
                 |<-----------------------------------| "See you later"

5. Open Issues

5.1 200 vs 202

   Should an agent accepting a NOTIFY request return a 200 OK or a 202
   Accepted?

5.2 Should REFER expire?

   Since REFER is effectively establishing a Subscription per [3],
   should the REFER request be required to contain an Expires: header?
   This would allow REFERer to specify how long he's willing to wait
   for the reference to complete. If the referred action exceeds that
   time, the agent processing the refer could return referfailure, stop
   trying, and free the state it needed for that processing. Without
   this or a similar mechanism, both agents involved in a REFER
   transaction could be forced to hold state indefinitely.

5.3 REFER is now dependent on sip-events

   By introducing NOTIFY, this work is prevented from moving to RFC
   until the sip-events draft moves to that level (that work is
   currently an individual submission). What needs to happen to our
   deliverable schedule to allow for completing the sip-events work?




Sparks                   Expires August 3, 2001                [Page 17]


Internet-Draft        SIP Call Control - Transfer          February 2001


5.4 Registering the events with IANA

   When we near the end of the process, the events we agree to use for
   this purpose (currently proposed as refersuccess and referfailure)
   will need to be registered with IANA per [3].

6. Acknowledgments

   This draft is a collaborative product of the SIP working group. The
   editor thanks the following for their early contributions to this
   work:  Ben Campbell, Chris Cunningham, Steve Donovan, Alan Johnston,
   Kevin Summers and Dean Willis.

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]  Roach, A., "Event Notification in SIP",
        draft-roach-sip-subscibe-notify-02 (work in progress), November
        2000.

   [4]  Schulzrinne, H. and J. Rosenberg, "SIP Call Control Services",
        draft-ietf-sip-cc-01 (work in progress - expired), June 1999.


Author's Address

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

   email: rsparks@dynamicsoft.com













Sparks                   Expires August 3, 2001                [Page 18]


Internet-Draft        SIP Call Control - Transfer          February 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 August 3, 2001                [Page 19]