[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Internet Engineering Task Force                            Robert Sparks
Internet Draft                                              MCI WorldCom
draft-sparks-sip-cc-transfer-00.txt
March 2000

                        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.














Sparks                                                          [Page 1]


Internet Draft                CC Transfer                   March 2000



Table of Contents:

1  Overview ..........................................................3

2  Actors and Roles ..................................................4

3  Requirements ......................................................5

4  The TRANSFER Method ...............................................6

 4.1 The Transfer-To Header...........................................6
 4.2 Header Field Support for the TRANSFER Method.....................6
 4.3 Message Body Inclusion...........................................7
 4.4 Responses to the TRANSFER Method.................................8
 4.5 Behavior of SIP User Agents......................................8
 4.6 Behavior of SIP Registrars/Redirect Servers......................9
 4.7 Behavior of SIP Proxies..........................................9
 4.8 Security Considerations..........................................9
5  Example Uses ......................................................9

 5.1 Unattended Transfer..............................................9
 5.2 Unattended Transfer with Consultation Hold......................12
 5.3 Attended Transfer...............................................13
 5.4 Transfer with multiple parties..................................14
Author's Addresses...................................................16

6  Acknowledgments ..................................................16

7  References .......................................................16






















MCI WorldCom                                                    [Page 2]


Internet Draft                CC Transfer                   March 2000




1  Overview

   This document defines a SIP [2] extension to provide Call Transfer
   capabilities. It 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 and 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.




























MCI WorldCom                                                    [Page 3]


Internet Draft                CC Transfer                   March 2000




2  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 (and leaving the
                     call).

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



















MCI WorldCom                                                    [Page 4]


Internet Draft                CC Transfer                   March 2000




3  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 (see comment 1).

   3. The Transferor MUST know whether or not the transfer was
   successful (see comment 2).

Explicit non-Requirements

   1. There is no requirement for the Transfer Target to be notified
   that he is receiving an INVITE as the result of a TRANSFER request
   (see comment 2).

   2. Pending results from the SIP security infrastructure taskforce,
   there is no requirement for the Transfer Target to receive secured
   assurance of the Transferor's identity through SIP (see comment 2).



Comments on Requirements

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

   2. Those requirements and non-requirements referencing comment 2 are
   significantly different from those in draft-ietf-sip-cc-01.















MCI WorldCom                                                    [Page 5]


Internet Draft                CC Transfer                   March 2000




4  The TRANSFER Method

   TRANSFER is a SIP method as defined by [2]. The TRANSFER method
   indicates that the recipient (the transferee) should contact a third
   party (the transfer target) using the contact information provided
   in the method. A success response indicates that the transferee was
   able to establish a session with the transfer target. The TRANSFER
   method follows the session's current signaling path. In particular,
   the Request-URI of the TRANSFER method identifies the transferee.

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

   A successful TRANSFER 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.


4.1 The Transfer-To Header

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

     Transfer-To = "Transfer-To" ":" ( name-addr | addr-spec )

   A TRANSFER method MUST contain exactly one Transfer-To header.

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

   The Transfer-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.


4.2 Header Field Support for the TRANSFER Method

   This table adds a column to tables 4 and 5 in [2], describing header
   presence in a TRANSFER method. See [2] for a key for the symbols
   used. A row for the Transfer-To: request-header should be inferred,
   mandatory for TRANSFER, not applicable for all other methods. The
   enc and e-e columns in [2] apply to the TRANSFER method unmodified.


MCI WorldCom                                                    [Page 6]


Internet Draft                CC Transfer                   March 2000



       Header                    Where  TRANSFER
       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

4.3 Message Body Inclusion

   A TRANSFER method MUST NOT contain a body.



MCI WorldCom                                                    [Page 7]


Internet Draft                CC Transfer                   March 2000



4.4 Extension Negotiation

   A TRANSFER request MUST contain the header

         Requires: cc.transfer


4.5 Responses to the TRANSFER Method

   An agent responding to a TRANSFER Method MUST return a 400 Bad
   Request if the request contained zero or more than one Transfer-To
   headers. An agent (including proxies generating local responses) MAY
   return a 100 Trying or any appropriate 400-600 class response as
   prescribed by [2]. If the transferee's agent decides to attempt the
   transfer, a 200 OK response MUST be returned by the if it was able
   to establish a session with the transferor, otherwise a 603 Decline
   MUST be returned. In particular, the transferee's agent MUST NOT
   mirror the transfer targets response to the transferee's invite.


4.6 Behavior of SIP User Agents

   UA receiving a well-formed TRANSFER request SHOULD request approval
   from the user to proceed. In the absence of that request, or upon
   receiving approval from the user, the UA MUST submit an INVITE to
   the resource identified by the Transfer-To: header using the Call-ID
   from the TRANSFER request. The remainder of that INVITE message is
   formed exactly as if the UA were placing a new call to that
   resource. In particular, media negotiation between the transferee
   and the transfer target is not affected by the media that had been
   negotiated between the transferor and the transferee. In accordance
   with [2], the UA SHOULD issue a provisional response to the TRANSFER
   method if it cannot issue a final response within 200ms of its
   receipt. The appropriate response to issue on receipt of a final
   response to the INVITE is discussed in "Responses to the TRANSFER
   Method".

   The TRANSFER transaction does not terminate the session between the
   transferor and the transferee. When the UAs for those parties should
   terminate that session, they must do so explicitly with a BYE
   request.

   A TRANSFER request is meaningful only in the context of an existing
   session. A UA receiving a TRANSFER request for an unknown call leg
   MUST return a 481 Call Leg/Transaction Does Not Exist and MUST NOT
   issue an INVITE to resource identified by that request's Transfer-To
   header as part of the TRANSFER transaction.




MCI WorldCom                                                    [Page 8]


Internet Draft                CC Transfer                   March 2000



   The disposition of the media streams between the transferor and the
   transferee is not altered by the TRANSFER 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.


4.7 Behavior of SIP Registrars/Redirect Servers

   Since TRANSFER has meaning only in the context of an existing
   session, a Registrar/Redirect Server that is not also playing the
   role of a User Agent (never issues a 200 OK in response to an
   INVITE) MUST respond to a TRANSFER request with a 481 Call
   Leg/Transaction Does Not Exist.


4.8 Behavior of SIP Proxies

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


4.9 Security Considerations

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

   This draft does not provide a mechanism for the Transfer Target to
   be alerted that this is a transferred call or to be assured of the
   identity of the Transferor.

   This mechanism relies on providing contact information for the
   transfer target to the transferee. Care should be taken to provide a
   suitably restricted URI if the transfer target is a protected
   resource.


5  Example Uses


5.1 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


MCI WorldCom                                                    [Page 9]


Internet Draft                CC Transfer                   March 2000



   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.


5.1.1     Successful Unattended Transfer

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





MCI WorldCom                                                   [Page 10]


Internet Draft                CC Transfer                   March 2000




5.1.2     Failed Unattended Transfer

         Transferor           Transferee             Transfer
              |                    |                  Target
              |                    |                    |
              |            INVITE  |                    |
              |<-------------------|                    |
              |            200 OK  |                    |
              |------------------->|                    |
              |            ACK     |                    |
              |<-------------------|                    |
              |  INVITE (hold)     |                    |
              |------------------->|                    |
              |  200 OK            |                    |
              |<-------------------|                    |
              |  ACK               |                    |
              |------------------->|                    |
              |  TRANSFER          |                    |
              |------------------->|                    |
              |  100 Trying        |                    |
              |<-------------------|                    |
              |                    |  INVITE            |
              |                    |------------------->|
              |                    |  486 Busy Here     |
              |                    |<-------------------|
              |                    |  ACK               |
              |                    |------------------->|
              |  603 Decline       |                    |
              |<-------------------|                    |
              |  INVITE (unhold)   |                    |
              |------------------->|                    |
              |  200 OK            |                    |
              |<-------------------|                    |
              |  ACK               |                    |
              |------------------->|                    |
              |  BYE               |                    |
              |------------------->|                    |
              |  200 OK            |                    |
              |<-------------------|                    |











MCI WorldCom                                                   [Page 11]


Internet Draft                CC Transfer                   March 2000




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


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






MCI WorldCom                                                   [Page 12]


Internet Draft                CC Transfer                   March 2000




5.2.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 | TRANSFER           |                    |
              |---------------------------------------->|
              | 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        |
              |                    |------------------->|



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






MCI WorldCom                                                   [Page 13]


Internet Draft                CC Transfer                   March 2000



5.4 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
   TRANSFER 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    |            |TRANSFER    |          |
              |            |<-----------|          |
              |            |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    |TRANSFER    |            |          |
              |<-----------|            |          |
              |100 Trying  |            |          |
              |----------->|            |          |
         1    |INVITE/200 OK/ACK        |          |
              |----------------------------------->| "Hey Fred"
              |200 OK      |            |          |    "Hello Mary"
              |----------->|            |          |
         1    |BYE/200 OK  |            |          |
              |<-----------|            |          |


MCI WorldCom                                                   [Page 14]


Internet Draft                CC Transfer                   March 2000



         2    |            |BYE/200 OK  |          |
              |            |---------------------->|
         1    |BYE/200 OK  |            |          |
              |<-----------------------------------| "See you later"















































MCI WorldCom                                                   [Page 15]


Internet Draft                CC Transfer                   March 2000




Author's Addresses

         Robert Sparks
         MCI WorldCom
         2400 N Glenville Drive        Phone:  +1-972-729-5241
         Richardson, TX  75082         Email:  Robert.Sparks@wcom.com




6  Acknowledgments

   The author thanks the following for their contribution to this work:
   Ben Campbell, Chris Cunningham, Steve Donovan, Alan Johnston, Kevin
   Summers and Dean Willis.


7  References

   [1] S. Bradner, "The Internet Standards Process -- Revision 3", BCP
      9, 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-campbell-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).

















MCI WorldCom                                                   [Page 16]