[Docs] [txt|pdf] [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]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/