Internet Engineering Task Force                           Robert Sparks
Internet Draft                                              dynamicsoft
draft-ietf-sip-cc-transfer-00.txt
July
draft-ietf-sip-cc-transfer-01.txt
September 2000
Expires February April 2001

                             SIP Call Control
                                 Transfer

STATUS OF THIS MEMO

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

  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

Abstract

  This document defines a SIP extension within the new Call Control
  Framework to provide Call Transfer capabilities.

Robert Sparks                                                  [Page 1]

1 Overview...........................................................3
2 Changes from draft-sparks-sip-cc-transfer-00.......................3 draft-sparks-sip-cc-transfer-01.......................4
3 Actors and Roles...................................................4
4 Requirements.......................................................5
5 The REFER Method...................................................6
 5.1 Method...................................................5
 3.1  The Refer-To Header............................................6
 5.2 Header............................................5
 3.2  The Referred-By Header.........................................7
  5.2.1 Header.........................................6
  3.2.1 A PGP based signature-scheme.................................7
 5.3 signature-scheme.................................6
 3.3  Header Field Support for the REFER Method......................8
 5.4 Method......................7
 3.4  Message Body Inclusion.........................................9
 5.5 Inclusion.........................................8
 3.5  Responses to the REFER Method..................................9
 5.6 Method..................................8
 3.6  Behavior of SIP User Agents...................................10
 5.7 Agents....................................8
 3.7  Behavior of SIP Registrars/Redirect Servers...................10
 5.8 Servers....................9
 3.8  Behavior of SIP Proxies.......................................10
 5.9 Proxies........................................9
 3.9  Security Considerations.......................................11
6 Considerations........................................9
4 Call Transfer.....................................................10
 4.1  Actors and Roles..............................................10
 4.2  Requirements..................................................11
 4.3  Using REFER to achieve Call Transfer..............................11
 6.1 Transfer..........................12
 4.4  Unattended Transfer...........................................11
  6.1.1 Transfer...........................................12
  4.4.1 Successful Unattended Transfer..............................12
  6.1.2 Transfer..............................13
  4.4.2 Failed Unattended Transfer..................................13
 6.2 Transfer..................................14
 4.5  Unattended Transfer with Consultation Hold....................14
  6.2.1
  4.5.1 Variation 1 : Exposes transfer target.......................14
 6.3 target.......................15
  4.5.2 Variation 2 : Protects transfer target......................15
 4.6  Attended Transfer.............................................15
 6.4 Transfer.............................................16
 4.7  Transfer with multiple parties................................16
5 Editor's Address..................................................18
6 Acknowledgments...................................................18
7 Author's Addresses................................................17
8 Acknowledgments...................................................17
9 References........................................................17 References........................................................18

1  Overview

  This document defines a SIP [2] 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 document
  [3].

  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.

  Implementers that started with the sip-cc-01 BYE-ALSO technique for
  blind-transfer should find it straightforward to migrate to the
  mechanisms set forth here.

2  Changes from draft-sparks-sip-cc-transfer-00 draft-sparks-sip-cc-transfer-01
 . The method was renamed to reflect its function instead Separated definition of this
    particular application of its function. TRANSFER and Transfer-To
    became the REFER method and Refer-To. REFER was generalized to support URLs
    beyond those indicating SIP INVITEs.
  . A Require header is no longer required. Bodies are allowed.
  . Copying Call-ID headers from the request was replaced by using a Refer-To:
    URL containing any headers that should be use.
    definition of its use to achieve transfer.
 . Added a way for Replaced the identity specified in Refer-To: syntax of the Referred-By header to know it has
    been referred to. align with sip-
    ietf-sip-guidelines.
 . Added a mechanism to prove the identity short forms of Refer-To and Referred-By as recommended by
    sip-ietf-sip-guidelines.
 . Allows REFERs outside the issuer scope of the an existing call-leg.

3  The REFER
    to the identity specified in Refer-To.
  . Method

  REFER is a SIP method as defined by [2]. The failure response returned to an attempted REFER has been
    changed from 603 to 503 to facilitate different behavior in the
    cases of "I won't accept that REFER" and "I tried method indicates
  that REFER and it
    failed" with Retry-After: support for the later.

3  Actors and Roles

  There are three actors in recipient should contact a given transfer event, each playing one of third party using the following roles:

     Transferee - contact
  information provided in the party being transferred method. A success response indicates that
  the recipient was able to contact the Transfer
                       Target.

     Transferor - third party. The REFER method
  follows the party initiating session's current signaling path. In particular, the transfer

     Transfer Target -
  Request-URI of the new party being introduced into a call with REFER method identifies the Transferee.

  The following roles are used to describe transfer requirements recipient.

  Unless stated otherwise, the protocol for emitting and
  scenarios:

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

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

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

     Recipient -   the party the Originator is ultimately connected to.

4  Requirements

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

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

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

5  The REFER Method

  REFER is a SIP method as defined by [2]. 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 responding to a
  REFER request are identical to those for a BYE request in [2]. The
  behavior of SIP entities not implementing the REFER (or any other
  unknown) method is explicitly defined in [2] and is not discussed
  further here.

5.1

3.1 The Refer-To Header

  Refer-To is a request-header as defined by [2]. It may only appear in
  a REFER request. It identifies the transfer target.

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

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

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

          The Refer-To header has no short form.

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

5.2

3.2 The Referred-By Header

 Referred-By is a request-header as defined by [2]. 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" ("Referred-By" | "b") ":"     referrer-url
                                                  ";" referenced-url
                        [ref-signature]
                                                 [";" ref-signature]
     referrer-url     = SIP-URL
     referenced-url   = "ref" "=" URL
     ref-signature    = signature-scheme #sig-scheme-params *( ";" 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. The ref-signature contains a signature over the
 concatenation of referrer-url and referenced-url.  An example
 signature scheme is given in section 5.2.1. 3.2.1.

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

 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.

 The Referred-By header has no short form.

5.2.1

3.2.1 A PGP based signature-scheme

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

     Referred-By
     signature-scheme = "Referred-By" ":" referrer-url
                            referenced-url "scheme" "=" "pgp" pgp-sig-scheme-parms
     pgp-sig-scheme-parms
     sig-scheme-parms = pgp-version | signed-by | pgp-signature

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

5.3

3.3 Header Field Support for the REFER Method

  This table adds a column to tables 4 and 5 in [2], describing header
  presence in a REFER method. See [2] 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 [2] 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 <-SHOULD be present and
         Content-Type                e       -   have a value of zero
         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

5.4

3.4 Message Body Inclusion

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

5.5

3.5 Responses to the REFER Method

  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 100 Trying
  or any appropriate 400-600 class response as prescribed by [2]. If the
  recipient's agent decides to contact the resource in the Refer-To
  header, a 200 OK response MUST be returned if it the contact was
  successful, otherwise a 503 Service Unavailable MUST be returned. The
  503 response MAY contain a Retry-After: header indicating when the
  REFER may be attempted again.

3.6 Behavior of SIP User Agents

  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. In
  accordance with [2], the UA SHOULD issue a provisional response to the
  REFER method if it cannot issue a final response within 200ms of its
  receipt. The appropriate response to issue to the REFER on receipt of
  a final response from the referred-to resource is discussed in
  "Responses to the REFER Method".

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 prescribed required by [2]. If [2], a proxy should process a REFER
  request the
  recipient's agent decides same way it processes an OPTIONS request.

3.9 Security Considerations

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

  This mechanism relies on providing contact information for the
  referred-to resource in to the Refer-To
  header, a 200 OK response MUST party being referred. Care should be returned taken
  to provide a suitably restricted URI if it the contact was
  successful, otherwise a 503 Service Unavailable MUST referred to resource
  should be returned. The
  503 response MAY contain a Retry-After: header indicating protected.

  Care should be taken when implementing the logic that determines
  whether or not to accept the REFER may be attempted again.

          The original proposal called for 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 603 response if given transfer event, each playing one of
  the REFER was attempted but failed. This left no way
          for 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 referrer Transferee.

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

     Originator -  wishes to place a call to tell whether the recipient tried
          and failed, or just refused to try. A 603 Decline
          now means Recipient. This actor
                   is the recipient refuses source of the first INVITE in a session, to try. A 503 can
          mean
                   either "I tried and failed" a Facilitator or "I'm broken and
          couldn't try". In either case, if a Retry-After
          header is present, the request can be attempted
          again.

5.6 Behavior of SIP User Agents

  A UA receiving Screener.

     Facilitator - receives a well-formed REFER request SHOULD call or out-of-band request approval from the user
                   Originator, establishes a call 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 Recipient
                   through the Refer-To: header.
  Note that if Screener, and connects the URL is a SIP URL, it could contain header fields such
  as Call-Id that will be used Originator to form
                   the resulting request. If the URL
  is Recipient.

     Screener -    receives a SIP URL, the Referred-By header in the REFER request should be
  copied into the request sent to call ultimately intended for the referred-to resource. In
  accordance with [2], Recipient
                   and transfers the UA SHOULD issue a provisional response calling party to the
  REFER method Recipient if it cannot issue a final response within 200ms of its
  receipt. The appropriate response to issue to
                   appropriate.

     Recipient -   the REFER on receipt of
  a final response from party the referred-to resource Originator is discussed ultimately connected to.

4.2 Requirements

    1. Any party in
  "Responses a SIP session MUST be able to the REFER Method".

  A REFER request is meaningful only transfer any other
       party in the context of an existing that session at any point in that session. A UA receiving a REFER request for an unknown call leg MUST
  return a 481 Call Leg/Transaction Does Not Exist

    2. The Transferor and the Transferee MUST NOT contact
  the resource identified by that request's Refer-To header be removed from a
       session as part of
  the REFER transaction.

5.7 Behavior of SIP Registrars/Redirect Servers

  Since REFER has meaning only in the context of an existing session, a
  Registrar or Redirect Server transfer transaction.

          At first glance, requirement 2 may seem to indicate
          that is not also playing the role of a
  User Agent (never issues a 200 OK user experience in response to an INVITE) MUST
  respond to a REFER request with transfer must be
          significantly different from what a 481 Call Leg/Transaction Does Not
  Exist.

5.8 Behavior of SIP Proxies

  SIP Proxies do current PBX or
          Centrex user expects. As the call-flows in this
          document show, this is not require modification to support the REFER method.
  Specifically, as required by [2], a proxy should process a REFER
  request case. A client MAY
          preserve the same way it processes an OPTIONS request.

5.9 Security Considerations

  The security requirements current experience. In fact, without
          this requirement, some forms of [2] apply to the REFER method.

  This mechanism relies current
          experience (ringback on providing contact information unattended transfer failure
          for the
  referred-to resource to the party being referred (the transfer-target
  and transferee in a transfer). Care should be taken to provide a
  suitably restricted URI if the referred to resource should be
  protected.

  Care should instance) will be taken when implementing the logic that determines lost.

    3. The Transferor MUST know whether or not to accept the REFER request. A UA not capable of
  accessing non-SIP URLs SHOULD NOT accept REFER requests to them.
  Unless transfer was
       successful (this is significantly different from the UA has good reason (perhaps as part requirements
       of an as yet undefined
  application), it SHOULD NOT accept REFERences to SIP URLs for methods
  other than INVITE.

6 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 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 [2] or the
  conferencing extensions provided by this framework.

6.1

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 using other
  mechanisms (mixing multiple media streams at the UA or using the
  conferencing extensions for example) are valid.

6.1.1

4.4.1 Successful Unattended Transfer

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

6.1.2

4.4.2 Failed Unattended Transfer

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

6.2

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.

6.2.1

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

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

6.3

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.

6.4

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       |          |
              |            |<-----------|          |
              |            |100 Trying  |          |
              |            |----------->|          |
         2    |            |INVITE/200 OK/ACK      |
              |            |---------------------->|"This is Fred"
              |            |200 OK      |          |  "Please hold for
              |            |----------->|          |              Mary"
         2    |            |BYE/200 OK  |          |
              |            |<-----------|          |
         3    |            |            |BYE/200 OK|
              |            |            |--------->|
         2    |            |INVITE (hold)/200 OK/ACK
              |            |---------------------->|
         1    |REFER       |            |          |
              |<-----------|            |          |
              |100 Trying  |            |          |
              |----------->|            |          |
         1    |INVITE/200 OK/ACK        |          |
              |----------------------------------->| "Hey Fred"
              |200 OK      |            |          |    "Hello Mary"
              |----------->|            |          |
         1    |BYE/200 OK  |            |          |
              |<-----------|            |          |
         2    |            |BYE/200 OK  |          |
              |            |---------------------->|
         1    |BYE/200 OK  |            |          |
              |<-----------------------------------| "See you later"

7  Author's Addresses

5  Editor's Address

  Robert Sparks
  dynamicsoft
  200 Executive Drive
  Suite 120
  West Orange, NJ 07052
  email: rsparks@dynamicsoft.com

8

6  Acknowledgments

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

9

7  References

     [1] S. Bradner, "The Internet Standards Process -- Revision 3",
         BCP9, RFC2026, October 1996.

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

     [3] B. Campbell, "Framework for SIP Call Control Extensions",
         Internet Draft draft-ietf-sip-cc-framework-00, Internet
         Engineering Task Force, March 2000. Work in Progress.

     [4] H. Schulzrinne, J. Rosenberg, "SIP Call Control Services",
         Internet Draft draft-ietf-sip-cc-01, Internet Engineering Task
         Force, June 17, 1999 Work in Progress (expired).