Internet Engineering Task Force
Network Working Group                                          R. Sparks
Internet-Draft                                               dynamicsoft
Expires: August 27, 2001                               February 26, January 16, 2002                                  July 18, 2001

                      SIP Call Control - Transfer
                     draft-ietf-sip-cc-transfer-04
                    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.

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

Copyright Notice

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

Abstract

   This document defines a SIP extension, REFER, and demonstrates its
   use to provide describes providing Call Transfer capabilites in SIP.
   Transfer capabilities.  This work is part of the Call Control
   Framework.

Table of Contents

   1.    Overview . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    Changes from draft-sparks-sip-cc-transfer-03 draft-sparks-sip-cc-transfer-04 . . . . . . . .  3
   3.      The REFER Method . . . . . . .    Actors and Roles . . . . . . . . . . . . . .  4
   3.1     The Refer-To Header . . . . . . . .  3
   4.    Requirements . . . . . . . . . . .  4
   3.1.1   Examples . . . . . . . . . . . . .  4
   5.    Using REFER to achieve Call Transfer . . . . . . . . . . . .  4
   3.2     The Referred-By Header . . . . . . . . . .
   6.    Basic Transfer . . . . . . . .  5
   3.2.1   A PGP based signature-scheme . . . . . . . . . . . . . . .  5
   3.2.2   Examples . . . . .
   6.1   Successful Transfer  . . . . . . . . . . . . . . . . . . . .  6
   3.3     Header Field Support for the REFER Method  . . . .
   6.2   Failed Transfer  . . . .  6
   3.4     Message Body Inclusion . . . . . . . . . . . . . . . . . .  7
   3.5     Responses within the REFER transaction . . . . . . .
   6.2.1 Target Busy  . . .  7
   3.6     Behavior of SIP User Agents . . . . . . . . . . . . . . .  8
   3.6.1   Accessing the referred-to resource . . . . . .  7
   6.2.2 Transfer Target does not answer  . . . . . .  8
   3.6.2   Reporting on the results of the reference . . . . . . . .  8
   3.6.2.1 Using NOTIFY . . . . . . . . . . . . . . . .
   7.    Transfer with Consultation Hold  . . . . . . .  8
   3.6.2.2 The body of the NOTIFY . . . . . . .  9
   7.1   Exposing transfer target . . . . . . . . . . .  8
   3.7     Behavior of SIP Registrars/Redirect Servers . . . . . . .  9
   3.8     Behavior of SIP Proxies
   7.2   Protecting transfer target . . . . . . . . . . . . . . . . .  9
   3.9     Prototypical 10
   7.3   Recovery when one party does not support REFER callflow  . . . . . . . . . . . . . . . 10
   3.10    Security Considerations  . . . . . . . . . . . . .
   7.4   Consultation Hold in the presence of forking proxies . . . . 11
   3.10.1  Circumventing privacy  . . .
   7.5   Using the Replaces header to improve the Consultation Hold
         experience . . . . . . . . . . . . . . . 11
   3.10.2  Circumventing security . . . . . . . . . . 12
   7.5.1 Consultation Hold protecting transfer target . . . . . . . . 12
   3.10.3  Limiting
   7.5.2 Recovering from one party not supporting the breach Replaces header 13
   7.6   Aborting a Consultation Hold . . . . . . . . . . . . . . . . 14
   8.    Transfer with multiple parties . . . 12
   4.      Call Transfer . . . . . . . . . . . . 14
   9.    Open Issues  . . . . . . . . . . 13
   4.1     Actors and Roles . . . . . . . . . . . . . . 15
   10.   Acknowledgments  . . . . . . . 13
   4.2     Requirements . . . . . . . . . . . . . . . 15
         References . . . . . . . . 13
   4.3     Using REFER to achieve Call Transfer . . . . . . . . . . . 14
   4.4     Unattended Transfer . . . . . . 15
         Author's Address . . . . . . . . . . . . . 14
   4.4.1   Successful Unattended Transfer . . . . . . . . . 16
         Full Copyright Statement . . . . . 15
   4.4.2   Failed Unattended Transfer . . . . . . . . . . . . . . . . 16
   4.5     Unattended Transfer with Consultation Hold . . . . . . . . 16
   4.5.1   Variation 1 : Exposes transfer target  . . . . . . . . . . 17
   4.5.2   Variation 2 : Protects transfer target . . . . . . . . . . 18
   4.5.3   Consultation Hold in the presence of forking proxies . . . 18
   4.6     Attended Transfer  . . . . . . . . . . . . . . . . . . . . 19
   4.7     Transfer with multiple parties . . . . . . . . . . . . . . 19
   5.      Open Issues  . . . . . . . . . . . . . . . . . . . . . . . 20
   5.1     REFER is now dependent on sip-events . . . . . . . . . . . 20
   5.2     Registering the events with IANA . . . . . . . . . . . . . 20
   6.      Acknowledgments  . . . . . . . . . . . . . . . . . . . . . 20
           References . . . . . . . . . . . . . . . . . . . . . . . . 20
           Author's Address . . . . . . . . . . . . . . . . . . . . . 21
           Full Copyright Statement . . . . . . . . . . . . . . . . . 22

1. Overview

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

   Editor's note: Per consensus at the February interim WG meeting, the
   two parts of this document, the definition of REFER and its use to
   achieve transfer, will be separated into separate documents. That
   separation will take place with the next revision of this document.
   Framework.

   The mechanisms discussed here are most closely related to traditional unattended
   basic and consultation hold transfers. Discussion
   of attended  This document does not
   discuss transfer scenarios involving ad-hoc conferences (where all
   parties involved are briefly in a conference)
   is deferred conference until the conferencing features in this framework are
   addressed. transferor
   drops out).

   Editor's note: Per working group consensus, draft-ietf-sip-cc-
   transfer-04 was split into two drafts.  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 document details the processing use
   of
   BYE, these changes facilitate recovery REFER to achieve call transfer.  The definition of failed transfers and
   clarify state management in the participating entities. REFER itself
   was removed to draft-ietf-sip-refer-00

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

   Editor's note: The changes for this revision focused on draft-sparks-sip-cc-transfer-04

   o  Split the changes
   to draft
   o  Removed the NOTIFY response mechanism discussed at February's interim
   meeting, contested distinction between attended and clarification to unattended
      transfer (involving an ad-hoc conference).
   o  Added new failure and recovery flows
   o  Added flow demonstrating the REFER method itself. As mentioned
   above, use of the intent is Replaces header to separate this document into two. The split
   was postponed affect
      user experience

3. Actors and Roles

   There are three actors in a version to ensure given transfer event, each playing one of
   the edits to REFER/NOTIFY would be
   reflected in following roles:

        Transferee -      the ID repository in time for discussion at IETF 50.

   o  Modified contents of NOTIFYs party being transferred to reflect the consensus at Transfer
                          Target.

        Transferor -      the
      interim meeting. One event type, party initiating the transfer

        Transfer Target - the new party being introduced into a call with an application/sip body
      representing
                          the information Transferee.

   The following roles are used to be returned.
   o  Added message detail describe transfer requirements and
   scenarios:

        Originator -  wishes to place a call to the prototypical flow
   o  More explicitly stated that REFER MAY occur outside an existing
      call-leg
   o  Reinforced that REFER can be record-routed
   o  Made Recipient. This actor
                      is the presence source of a Contact header mandatory
   o  Changed the positive response to first INVITE in a REFER request session, to 202 Accepted
      instead of 200 OK
   o  Corrected editing errors in examples and message diagrams

3. The REFER Method

   REFER is
                      either a SIP method as defined by RFC2543[1]. The REFER method
   indicates that the recipient (identified by Facilitator or a Screener.

        Facilitator - receives a call or out-of-band request from the Request-URI) should
   contact
                      Originator, establishes a third party using call to the contact information provided in Recipient
                      through the
   method. A success response indicates that Screener, and connects the recipient was able Originator to
   contact the third party.

   Unless stated otherwise,
                      the protocol Recipient.

        Screener -    receives a call ultimately intended for emitting the Recipient
                      and responding to
   a REFER request are identical transfers the calling party to those for a BYE request the Recipient if
                      appropriate.

        Recipient -   the party the Originator is ultimately connected to.

4. Requirements

   1.  Any party in [1]. The
   behavior of a SIP entities not implementing the REFER (or session MUST be able to transfer any other
   unknown) method is explicitly defined
       party in [1].

   A REFER request MAY be placed outside that session at any point in that session.
   2.  The Transferor and the scope of a call-leg
   created with an INVITE. REFER MAY be Record-Routed, hence MUST
   contain a single Contact header. REFERs occurring inside an existing
   call-leg Transferee MUST follow the Route/Record-Route logic of that call-leg.
   REFERs occurring outside an existing call-leg effectively create NOT be removed from a
   new call-leg following the behavior
       session as part of SUBSCRIBE specified [3].

3.1 The Refer-To Header

   Refer-To is a request-header as defined by [1]. It transfer transaction.

             At first glance, requirement 2 may only appear seem to indicate
             that the user experience in a REFER request.

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

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

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

        The Contact header is an important part of
             significantly different from what a current PBX or
             Centrex user expects. As the Route/Record-Route
        mechanism and call-flows in this
             document show, this 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&Call-ID=55432@alicepc.atlanta.com

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

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

   Long headers are line-wrapped here for clarity only.

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 case. A client MAY
             preserve the
   REFERrer actually issued current experience. In fact, without
             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 requirement, some forms of the party sending the REFER
   request. current
             experience (ringback on transfer failure
             for instance) will be lost.

   3.  The referenced-url contains a copy of the URL placed in the
   Refer-To: header. Any occurrences of < Transferor MUST know whether or > in not the referenced-url
   MUST be escaped. The ref-signature contains a signature over transfer was
       successful (this is significantly different from the
   concatenation requirements
       of referrer-url and referenced-url.  An example
   signature scheme is given in section 3.1.2. the earlier BYE-Also approach to transfer).

5. Using REFER to achieve Call Transfer

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

   The Referred-By header SHOULD [3] can be signed issued by the Transferor to help detection of REFERs
   from unauthorized third parties. A signed Referred-By header SHOULD
   include a Date header in cause the referrer-url Transferee
   to facilitate detection of
   replay attacks.

   A UA MAY reject a request containing issue an unsigned Referred-By header.
   A UA SHOULD verify INVITE to 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 Transfer-Target.  Note that a successful
   REFER transaction does not terminate the session between the
   Transferor and pgp-signature are defined in section 15.1
   of RFC2543, the Transferee.  If those parties wish to terminate
   their session, they must do so with a subsequent BYE request.  The
   media negotiated between the modification that transferee and the signature transfer target is computed
   across
   not affected by the concatenation of media that had been negotiated between the referrer-url
   transferor 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 transferee.  In particular, the last example, INVITE issued by
   the Transferee will have the signature same SDP body it would be over have if he
   Transferee had initiated that INVITE on its own.  Further, the
   string "sip:bob@biloxi.comsip:alice@atlanta.com")

3.3 Header Field Support for
   disposition of 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 media streams between the Refer-To: Transferor and Referred-By request-header should be
   inferred, each mandatory for REFER. Refer-To the
   Transferee is not applicable for
   all other methods. Referred-By is a general Request header. The enc
   and e-e columns in [1] apply to altered by 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       m
            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
            User-Agent                  g       o
            Via                       gc(2)     m
            Warning                     r       o
            WWW-Authenticate           401      o

3.4 Message Body Inclusion

   A REFER method method.  Agents 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 alter a 400 Bad Request
   if
   session's media through additional signaling.  For example, they may
   make use of the request contained zero SIP hold re-INVITE [1] 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 conferencing extensions
   provided by [1]. If this framework.

6. Basic Transfer

   Basic Transfer consists of the recipient's agent decides to contact Transferor providing the resource in Transfer
   Target's contact to the Refer-To header, Transferee.  The Transferee attempts to
   establish a 202 Accepted response MUST be returned before session using that contact and reports the REFER transaction expires.

   Editor's note - earlier versions results of this draft required the agent
   responding to REFER
   that attempt to wait until the referred action completed
   before sending a final response to Transferor.  The signaling relationship between
   the REFER. That final response
   reflected Transferor and Transferee is not terminated, so the success or failure of call is
   recoverable if the referred action. This was
   infeasible due Transfer Target cannot be reached.  Note that the
   Transfer Target's contact information has been exposed 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
   Transferee.  The provided 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 can be used to form the resulting
   request. If the URL is a SIP URL, the Referred-By header make new calls in
   the
   REFER request should be copied into the request sent to the
   referred-to resource.

3.6.2 Reporting on future.

   The diagrams below show indicate the results first line of each message.  All
   messages in a particular diagram share the reference

3.6.2.1 Using NOTIFY

   Once it same Call-ID.  In these
   diagrams, media is known whether the reference succeeded or failed, managed through reINVITE holds, but other
   mechanisms (mixing multiple media streams at the UA
   receiving the REFER SHOULD notify the agent sending the refer or using the NOTIFY mechanism defined in Event Notification in SIP[3] as if
   conferencing extensions for example) are valid.

   Each of the flows below shows the REFER had established a subscription. In particular:

   o  Each NOTIFY should reflect call-leg between the To:, From:, Transferor and Call-ID headers
      from
   the Transferee remaining connected (on hold) during the REFER as if they had arrived in a SUBSCRIBE.

   o  Each NOTIFY MUST contain an event header of Event: refer

   o  Each NOTIFY MUST contain a body of type "application/sip". The
      contents of
   process.  While this body are detailed in Section 3.6.2.2

   o  Analogous to provides the case greatest flexibility for SUBSCRIBE described in [3], recovery
   from failure, it is not neccessary.  If the Transferor's agent
      that issued does
   not wish to participate in the remainder of the REFER MUST be prepared to receive process and has
   no intention of assisting with recovery from transfer failure, it
   could emit a NOTIFY before BYE to the Transferee as soon as the REFER transaction
   completes.

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

   Open Issue: The refer event will need to be registered with IANA
   (Section 5.2)

3.6.2.2 The body of the NOTIFY

   Each NOTIFY MUST contain a body of type "application/sip". This body
   MUST begin with a SIP Response Status-Line as defined in [1]. The
   response class in this status line indicates the success of the
   referred action. The body MAY contain other SIP headers to provide
   information about the outcome of the referenced action.

   A minimal, but complete, implementation can respond with a single
   NOTIFY containing either the body:

      SIP/2.0 200 OK

   if the reference was successful or the body:

      SIP/2.0 503 Service Unavailable

   if the reference failed.

   An implementation MAY include more of a SIP message in that body to
   convey more information. Warning headers received in responses to
   the referred action are good candidates. In fact, if the reference
   was to a SIP URL, entire response to the referenced action could be
   returned. However, doing so could have grave security repercussions
   (see Section 3.10). Implementers must carefully consider what they
   choose to include.

   Note that if the reference was to a non-SIP URL, status in any
   NOTIFYs to the referrer must still be in the form of SIP Response
   Status-Lines. The minimal implementation discussed above is
   sufficient to provide a basic indication of success or failure. For
   example, if a client receives a REFER to a HTTP URL, and is
   successful in accessing the resource, its NOTIFY to the referrer can
   contain the application/sip body of "SIP/2.0 200 OK"

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.

3.9 Prototypical REFER callflow

          Agent A                  Agent B

6.1 Successful Transfer

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

   Here are examples of what the four messages between Agent A and
   Agent B might look like if the reference to (whatever) that Agent B
   makes is successful:
      Message One

       REFER sip:b@agentland SIP/2.0
       Via: SIP/2.0/UDP agenta.agentland
       To: sip:b@agentland
       From: sip:a@agentland;tag=193402342
       Call-ID: 898234234@agenta.agentland
       CSeq: 93809823  REFER
       Refer-To: (whatever URL)
       Referred-By: <sip:a@agentland>;ref=<whatever URL>;
          scheme=pgp;pgp-version="5.0";signature="signature goes here"
       Contact: sip:a@agentland
       Content-Length: 0

      Message Two

       SIP/2.0             |                    |
                   |------------------->|                    |
                   |  202 Accepted
       Via: SIP/2.0/UDP agenta.agentland
       To: sip:b@agentland;tag=4992881234
       From: sip:a@agentland;tag=193402342
       Call-ID: 898234234@agenta.agentland
       CSeq: 93809823 REFER
       Contact: sip:b@agentland
       Content-Length: 0

      Message Three
       NOTIFY sip:a@agentland SIP/2.0
       Via: SIP/2.0/UDP agentb.agentland
       To: sip:a@agentland;tag=193402342
       From: sip:b@agentland;tag=4992881234
       Call-ID: 898234234@agenta.agentland
       CSeq: 1993402      |                    |
                   |<-------------------|                    |
                   |                    |  INVITE            |
                   |                    |------------------->|
                   |                    |  200 OK            |
                   |                    |<-------------------|
                   |                    |  ACK               |
                   |                    |------------------->|
                   |  NOTIFY
       Event: refer
       Contact: sip:b@agentland
       Content-Type: application/sip
       Content-Length: 16

       SIP/2.0 (200 OK)   |                    |
                   |<-------------------|                    |
                   |            200 OK

      Message Four

       SIP/2.0  |                    |
                   |------------------->|                    |
                   |  BYE               |                    |
                   |------------------->|                    |
                   |  200 OK
       Via: SIP/2.0/UDP agentb.agentland
       To: sip:a@agentland;tag=193402342
       From: sip:b@agentland;tag=4992881234
       Call-ID: 898234234@agenta.agentland
       CSeq: 1993402 NOTIFY
       Contact: sip:a@agentland
       Content-Length: 0

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.

   Using application/sip bodies to return the progress and results of a
   REFER request is extremely powerful. Careless use of that capability
   will compromise security and privacy. Here are a couple of simple,
   somewhat contrived, examples to demonstrate the potential for harm.

3.10.1 Circumventing privacy

   Suppose Alice has a user-agent that accepts REFER requests to SIP
   INVITE URLs, and NOTIFYs the referrer of the progress of the            |                    |
                   |<-------------------|                    |
                   |                    |             BYE    |
                   |                    |<-------------------|
                   |                    |             200 OK |
                   |                    |------------------->|

6.2 Failed Transfer

6.2.1 Target Busy

              Transferor           Transferee             Transfer
                   |                    |                  Target
                   |                    |                    |
                   |            INVITE
   by copying each response to the  |                    |
                   |<-------------------|                    |
                   |            200 OK  |                    |
                   |------------------->|                    |
                   |            ACK     |                    |
                   |<-------------------|                    |
                   |  INVITE into the body of a NOTIFY.

   Suppose further that Carol has a reason to avoid Mallory and has
   configured her system at her proxy to only accept calls from a
   certain set of people she trusts (including Alice), so that Mallory
   doesn't learn when she's around, or what user agent she's actually
   using.

   Mallory can send a REFER to Alice, with a Refer-To: indicating
   Carol. If Alice can reach Carol, the (hold)     |                    |
                   |------------------->|                    |
                   |  200 OK Carol sends gets
   returned to Mallory in a NOTIFY, letting him know not only that
   Carol is around, but also the IP address of the agent she's using.

3.10.2 Circumventing security

   Suppose Alice, with the same user agent as above, is working at a
   company that is working on the greatest SIP device ever invented -
   the SIP FOO. The company has been working for months building the
   device and the marketing materials, carefully keeping the idea, even
   the name of the idea secret (since a FOO is one of those things that
   anybody could do if they'd just had the idea first). FOO is up and
   running, and anyone at the company can use it, but it's not
   available outside the company firewall.

   Mallory has heard rumor that Alice's company is onto something big,
   and has even managed to get his hands on a URL that he suspects
   might have something to do with it. He sends a REFER to ALICE with
   the mysterious URL and as Alice connects to the FOO, Mallory gets
   NOTIFYs with bodies containing

      Server: FOO/v0.9.7

3.10.3 Limiting the breach

   For each of these cases, and in general, returning a carefully
   selected subset of the information available about the progress of
   the reference through the NOTIFYs mitigates risk. The minimal
   implementation described in Section 3.6.2.2 exposes the least
   information about what the agent operating on the            |                    |
                   |<-------------------|                    |
                   |  ACK               |                    |
                   |------------------->|                    |
                   |  REFER request has
   done, and is least likely to be a useful tool for malicious users.

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
   scenarios:

        Originator -  wishes to place a call to the Recipient. This actor
                      is the source of the first             |                    |
                   |------------------->|                    |
                   |  202 Accepted      |                    |
                   |<-------------------|                    |
                   |                    |  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            |
                   |                    |------------------->|
                   |                    |  486 Busy Here     |
                   |                    |<-------------------|
                   |                    |  ACK               |
                   |                    |------------------->|
                   |    NOTIFY (503 Service Unavailable)     |
                   | 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 NOTIFY (486 Busy Here)               |
                   |<-------------------|                    |
                   |            200 OK  |                    |
                   |------------------->|                    |
                   |  INVITE (unhold)   |                    |
                   |------------------->|                    |
                   |  200 OK            |                    |
                   |<-------------------|                    |
                   |  ACK               |                    |
                   |------------------->|                    |
                   |  BYE               |                    |
                   |------------------->|                    |
                   |  200 OK            |                    |
                   |<-------------------|                    |

6.2.2 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 Target does not terminate the session between the answer

              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             Transfer
                   |                    |                  Target
                   |            INVITE on its own. Further, the
   disposition  |                    |
                   |<-------------------|                    |
                   |            200 OK  |                    |
                   |------------------->|                    |
                   |            ACK     |                    |
                   |<-------------------|                    |
                   |  INVITE (hold)     |                    |
                   |------------------->|                    |
                   |  200 OK            |                    |
                   |<-------------------|                    |
                   |  ACK               |                    |
                   |------------------->|                    |
                   |  REFER             |                    |
                   |------------------->|                    |
                   |  202 Accepted      |                    |
                   |<-------------------|                    |
                   |                    |  INVITE            |
                   |                    |------------------->|
                   |                    |  180 Ringing       |
                   |                    |<-------------------|
                   |                    |   (Transferee gets tired of the media streams waiting)
                   |                    |  CANCEL            |
                   |                    |------------------->|
                   |                    |  200 OK (CANCEL)   |
                   |                    |<-------------------|
                   |                    |  487 Request Cancelled (INVITE)
                   |                    |<-------------------|
                   |                    |  ACK               |
                   |                    |------------------->|
                   |    NOTIFY (487 Request Cancelled)       |
                   |<-------------------|                    |
                   |            200 OK  |                    |
                   |------------------->|                    |
                   |  INVITE (unhold)   |                    |
                   |------------------->|                    |
                   |  200 OK            |                    |
                   |<-------------------|                    |
                   |  ACK               |                    |
                   |------------------->|                    |
                   |  BYE               |                    |
                   |------------------->|                    |
                   |  200 OK            |                    |
                   |<-------------------|                    |

7. Transfer with Consultation Hold

   Transfer with Consultation Hold involves a session between the Transferor
   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 transfer target before the transfer actually takes
   place.  This is implemented with 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 Hold and Transfer Target's contact to the Transferee. as described
   above.

7.1 Exposing transfer target

   The Transferee attempts
   to establish transferor places the transferee on hold, establishes a session using that contact and reports call with
   the results of
   that attempt transfer target to alert them 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 impending transfer,
   terminates the
   Transfer Target's contact information has been exposed to connection with the
   Transferee. The provided contact transfer target, then proceeds
   with transfer as above.  This variation can be used to make new calls in 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 future. The diagrams below show indicate arrow showing the first line direction 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.

4.4.1 Successful Unattended Transfer request.

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

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
                   |             BYE                    |                    |                    |<-------------------|
         Call-ID:1 | INVITE/200 OK/ACK  |             200 OK                    |
                   |<-------------------|                    |                    |------------------->|

4.4.2 Failed Unattended Transfer

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

              Transferor           Transferee             Transfer
                   |                    |                  Target
                   |                    |                    |
         Call-ID:1 | INVITE/200 OK/ACK  |  REFER                    |
                   |<-------------------|                    |
                   |------------------->|
         Call-ID:1 | INVITE (hold)/200 OK/ACK                |  202 Accepted
                   |------------------->|                    |
         Call-ID:2 |
                   |<-------------------| INVITE/200 OK/ACK  |                    |
                   |---------------------------------------->|
         Call-ID:2 | INVITE (hold)/200 OK/ACK                |
                   |---------------------------------------->|
         Call-ID:1 |                    |------------------->| REFER              |                    |  486 Busy Here
                   |------------------->|                    |
         Call-ID:1 | 501 Not Implemented
                   |<-------------------|                    |
         Call-ID:2 |  ACK               |
                   |                    |------------------->| REFER              |    NOTIFY (503 Service Unavailable)                    |
                   |---------------------------------------->|
                   | or NOTIFY (486 Busy Here) 202 Accepted       |
                   |<-------------------|                    |
                   |<----------------------------------------|
         Call-ID:2 |            200 OK                    |  INVITE/200 OK/ACK |
                   |------------------->|
                   |                    |<-------------------|
         Call-ID:2 |  INVITE (unhold) NOTIFY (200 OK)    |                    |
                   |------------------->|
                   |<----------------------------------------|
                   |                    |            200 OK  |
                   |---------------------------------------->|
         Call-ID:1 |
                   |<-------------------|                    |
                   |  ACK BYE/200 OK         |                    |
                   |------------------->|                    |
         Call-ID:2 |  BYE BYE/200 OK         |                    |
                   |------------------->|
                   |---------------------------------------->|
         Call-ID:2 |                    |  200  BYE/200 OK        |
                   |
                   |<-------------------|                    |

4.5 Unattended Transfer with                    |------------------->|

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
   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 involves a session between the
   transferor and the protecting transfer target before

   One of the transfer actually
   takes place. This is implemented problems with SIP Hold and Unattended
   Transfer as described above.

4.5.1 Variation 1 : Exposes transfer the simplest implementation of a target

   The transferor places
   protecting transfer is that the transferee on hold, establishes is receiving a new call
   with the transfer target to alert them to
   from the impending transfer,
   terminates transfer-target.  Unless the connection transferee's agent has a
   reliable way to associate this new call with the transfer target, then proceeds call it already has
   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 the transferor, it will have been
   collapsed into one indicator with to alert the arrow showing new call on another
   appearance.  If this, or some other call-waiting-like UI were not
   available, the direction of transferee might be stuck returning a Busy-Here to 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 |
                   |                    |<-------------------|

4.5.2 Variation 2 : Protects
   transfer target

   The transferor places target, effectively preventing the transferee on hold, establishes a transfer.  There are many
   ways that that correlation could be provided.  The call
   with 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 transfer target flow below, clid1 means Call Leg Identifier 1, and then reverses their roles, transferring consists
   of the original transfer target parameters to the original transferee. This has
   the advantage of hiding information about the original transfer
   target from Replaces header for call-leg 1.  In [4] this
   is the original transferee. On Call-ID, To-tag and From-tag.

   Note that the other hand, transferee's agent emits a BYE to the
   Transferee's experience is different that in current systems. The
   Transferee is effectively "called back" by transferor's
   agent as an immediate consequence of processing the Transfer Target. Replaces header.

              Transferor           Transferee             Transfer
                   |                    |                  Target
                   |                    |                    |
         Call-ID:1
         clid1     | INVITE/200 OK/ACK  |                    |
                   |<-------------------|                    |
         Call-ID:1
         clid1     | INVITE (hold)/200 OK/ACK                |
                   |------------------->|                    |
         Call-ID:2
         clid2     | INVITE/200 OK/ACK  |                    |
                   |---------------------------------------->|
         Call-ID:2
         clid2     | INVITE (hold)/200 OK/ACK                |
                   |---------------------------------------->|
         Call-ID:2
         clid2     | REFER              |                    | (Refer-To: sip:transferee?Replaces=clid1)
                   |---------------------------------------->|
         clid2     | 202 Accepted       |                    |
                   |<----------------------------------------|
         Call-ID:2
         clid3     |                    |  INVITE/200  INVITE (Replaces=clid1)/200 OK/ACK
                   |                    |<-------------------|
         clid1     | BYE/200 OK         |                    |
                   |<-------------------|
         Call-ID:2                    |
         clid2     | NOTIFY (200 OK)    |                    |
                   |<----------------------------------------|
         clid2     |                    |            200 OK  |
                   |---------------------------------------->|
         Call-ID:1
         clid2     | BYE/200 OK         |                    |
                   |------------------->|                    |
         Call-ID:2 | BYE/200 OK
                   |---------------------------------------->|
                   |                    |
                   |---------------------------------------->|
         Call-ID:2  (transferee and target converse)
         clid3     |                    |  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,

7.5.2 Recovering from one party not supporting the URL used Replaces header

   Similar to reach the Transfer Target may go through case of recovering from a
   forking proxy. There is no guarantee that party not supporting REFER,
   the Transferee's and
   Transferor's invitations to transferor can recover from a party not supporting the Transfer Target will reach Replaces
   header, at the same
   endpoint. If potential cost of not protecting the proxy forked in parallel, both invitations could
   cause multiple endpoints transfer target
   and reverting to ring. To increase the probability of non-Replaces user experience.

   In the
   desired behavior above flow, if all of having the referred invite reach 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 ring only returns Busy-Here to all new INVITEs when engaged
      in a call.
   o  The Transfer-Target's agent is configured to expose the same endpoint as cause of a
      REFERenced action failure in its NOTIFY (see the consultation invite, security issues
      associated with this choice in [3]).
   o  The Transferor is willing to expose the Transfer-Target.
   then the Transferor SHOULD
   issue can retry the transfer by sending a new REFER request with to
   the Refer-To: header containing Transferee.

7.6 Aborting a Consultation Hold

   In any of the
   Contact consultation hold flows above, the Transfer Target provided in Transferor may
   decide to terminate its 200 OK attempt to contact the
   Transferor's INVITE. If Transfer target before
   that REFER fails, session is established.  Most frequently, that will be the Transferor SHOULD
   issue another REFER with end
   of the Refer-To: header containing scenario, but in some circumstances, the URL it
   used transferor may wish
   to reach the Transfer Target, augmented proceed with an Accept-Contact
   header containing the Contact transfer action.  For example, he may wish to
   complete the Transfer Target provided.

4.6 Attended Transfer

   In an attended transfer, transfer knowing that the three actors participate in an ad-hoc
   conference as part of transferee will end up
   evenutally talking to the event. Discussion of transfer-target's voice-mail service.

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

   This scenario is thus deferred until far more complicated for flows that protect the conferencing portion of
   transfer target.  Since no session is established between the Call Control framework has been addressed.

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

5.

9. Open Issues

5.1 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?

5.2 Registering the events with IANA

   When we near the end of the process, the refer event will need to be
   registered with IANA per [3].

6.

10. Acknowledgments

   This draft is a collaborative product of the SIP working group. The
   editor thanks the following for their early contributions
   Thanks to this
   work:  Ben Campbell, Chris Cunningham, Steve Donovan, Alan Johnston,
   Kevin Summers Johnston for providing the starting point for the new
   error and Dean Willis. 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]  Roach, A., "Event Notification in SIP",
        draft-roach-sip-subscibe-notify-03  Sparks, R., "The REFER Method", draft-ietf-sip-refer-00 (work in
        progress), February July 2001.

   [4]  Schulzrinne, H.  Biggs, B. and J. Rosenberg, "SIP Call Control Services",
        draft-ietf-sip-cc-01 R. Dean, "The SIP Replaces Header", draft-biggs-
        sip-replaces-00 (work in progress - expired), June 1999. progress), November 2000.

Author's Address

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

   email:

   EMail: rsparks@dynamicsoft.com

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 Editor function is currently provided by the
   Internet Society.