draft-ietf-sip-cc-transfer-02.txt   draft-ietf-sip-cc-transfer-03.txt 
Internet Engineering Task Force Robert Sparks
Internet Draft dynamicsoft
draft-ietf-sip-cc-transfer-02.txt
November 2000
Expires May 2001
SIP Call Control Internet Engineering Task Force R. Sparks
Transfer Internet-Draft dynamicsoft
Expires: August 3, 2001 February 2, 2001
STATUS OF THIS MEMO SIP Call Control - Transfer
draft-sip-cc-transfer-03
This document is an Internet-Draft and is in full conformance with all Status of this Memo
provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering Task This document is an Internet-Draft and is in full conformance with
Force (IETF), its areas, and its working groups. Note that other all provisions of Section 10 of RFC2026.
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are working documents of the Internet Engineering
and may be updated, replaced, or obsoleted by other documents at any Task Force (IETF), its areas, and its working groups. Note that
time. It is inappropriate to use Internet-Drafts as reference material other groups may also distribute working documents as
or to cite them other than as work in progress. 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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 3, 2001.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
This document defines a SIP extension within the Call Control This document defines a SIP extension within the Call Control
Framework to provide Call Transfer capabilities. Framework and demonstrates its use to provide Call Transfer
capabilities.
1 Overview...........................................................3 Table of Contents
2 Changes from draft-sparks-sip-cc-transfer-01.......................4
3 The REFER Method...................................................5
3.1 The Refer-To Header............................................5
3.1.1 Examples.....................................................5
3.1.2 A PGP based signature-scheme.................................6
3.1.3 Examples.....................................................7
3.2 Header Field Support for the REFER Method......................7
3.3 Message Body Inclusion.........................................8
3.4 Responses to the REFER Method..................................8
3.5 Behavior of SIP User Agents....................................8
3.6 Behavior of SIP Registrars/Redirect Servers....................9
3.7 Behavior of SIP Proxies........................................9
3.8 Security Considerations........................................9
4 Call Transfer.....................................................10
4.1 Actors and Roles..............................................10
4.2 Requirements..................................................11
4.3 Using REFER to achieve Call Transfer..........................12
4.4 Unattended Transfer...........................................12
4.4.1 Successful Unattended Transfer..............................13
4.4.2 Failed Unattended Transfer..................................14
4.5 Unattended Transfer with Consultation Hold....................14
4.5.1 Variation 1 : Exposes transfer target.......................15
4.5.2 Variation 2 : Protects transfer target......................15
4.5.3 Consultation Hold in the presence of forking proxies........16
4.6 Attended Transfer.............................................17
4.7 Transfer with multiple parties................................17
5 Editor's Address..................................................18
6 Acknowledgments...................................................18
7 References........................................................18
1 Overview 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Changes from draft-sparks-sip-cc-transfer-02 . . . . . . . . 3
3. The REFER Method . . . . . . . . . . . . . . . . . . . . . . 3
3.1 The Refer-To Header . . . . . . . . . . . . . . . . . . . . 3
3.1.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 The Referred-By Header . . . . . . . . . . . . . . . . . . . 4
3.2.1 A PGP based signature-scheme . . . . . . . . . . . . . . . . 5
3.2.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Header Field Support for the REFER Method . . . . . . . . . 6
3.4 Message Body Inclusion . . . . . . . . . . . . . . . . . . . 7
3.5 Responses within the REFER transaction . . . . . . . . . . . 7
3.6 Behavior of SIP User Agents . . . . . . . . . . . . . . . . 7
3.6.1 Accessing the referred-to resource . . . . . . . . . . . . . 7
3.6.2 Reporting on the results of the reference . . . . . . . . . 8
3.7 Behavior of SIP Registrars/Redirect Servers . . . . . . . . 8
3.8 Behavior of SIP Proxies . . . . . . . . . . . . . . . . . . 8
3.9 Prototypical REFER callflow . . . . . . . . . . . . . . . . 9
3.10 Security Considerations . . . . . . . . . . . . . . . . . . 9
4. Call Transfer . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Actors and Roles . . . . . . . . . . . . . . . . . . . . . . 9
4.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3 Using REFER to achieve Call Transfer . . . . . . . . . . . . 10
4.4 Unattended Transfer . . . . . . . . . . . . . . . . . . . . 11
4.4.1 Successful Unattended Transfer . . . . . . . . . . . . . . . 12
4.4.2 Failed Unattended Transfer . . . . . . . . . . . . . . . . . 13
4.5 Unattended Transfer with Consultation Hold . . . . . . . . . 13
4.5.1 Variation 1 : Exposes transfer target . . . . . . . . . . . 14
4.5.2 Variation 2 : Protects transfer target . . . . . . . . . . . 15
4.5.3 Consultation Hold in the presence of forking proxies . . . . 15
4.6 Attended Transfer . . . . . . . . . . . . . . . . . . . . . 16
4.7 Transfer with multiple parties . . . . . . . . . . . . . . . 16
5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1 200 vs 202 . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2 Should REFER expire? . . . . . . . . . . . . . . . . . . . . 17
5.3 REFER is now dependent on sip-events . . . . . . . . . . . . 17
5.4 Registering the events with IANA . . . . . . . . . . . . . . 18
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18
References . . . . . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . 18
Full Copyright Statement . . . . . . . . . . . . . . . . . . 19
This document defines a SIP [2] extension and details its use to 1. Overview
This document defines a SIP[1] extension and details its use to
provide Call Transfer capabilities. This is part of a family of Call provide Call Transfer capabilities. This is part of a family of Call
Control extensions described in the Call Control Framework document Control extensions described in the Call Control Framework[2]
[3]. document.
The mechanisms discussed here are most closely related to traditional The mechanisms discussed here are most closely related to
unattended and consultation hold transfers. Discussion of attended traditional unattended and consultation hold transfers. Discussion
transfer (where all parties are briefly in a conference) is deferred of attended transfer (where all parties are briefly in a conference)
until the conferencing features in this framework are addressed. 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 This work has roots in draft-ietf-sip-cc-01 [4] but some basic
semantics are different. In particular, transfers are achieved through semantics are different. In particular, transfers are achieved
a new method that does not terminate the original signaling through a new method that does not terminate the original signaling
relationship. By disassociating transfers from the processing of BYE, relationship. By disassociating transfers from the processing of
these changes facilitate recovery of failed transfers and clarify BYE, these changes facilitate recovery of failed transfers and
state management in the participating entities. 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-01
. Allowed the ref= parameter in the Referred-By header to occur 2. Changes from draft-sparks-sip-cc-transfer-02
either before or after the optional signature. o Changed the REFER response to be immediate instead of waiting for
. Allowed name-addr|addr-spec for the referrer-url in a Referred-By the referred action to complete
header o Added use of NOTIFY to deliver the result of the referred action
. Quoted the referenced-url with <> and required escaping <> if o Removed the claim of easy migration from BYE/ALSO
they occur within the referenced-url
. Captured the results of the list discussion on having the REFERed
invite reach a particular endpoint in the presence of forking
proxies.
. Added example Refer-To: and Referred-By: headers.
3 The REFER Method 3. The REFER Method
REFER is a SIP method as defined by [2]. The REFER method indicates REFER is a SIP method as defined by RFC2543[1]. The REFER method
that the recipient should contact a third party using the contact indicates that the recipient should contact a third party using the
information provided in the method. A success response indicates that contact information provided in the method. A success response
the recipient was able to contact the third party. The REFER method indicates that the recipient was able to contact the third party.
follows the session's current signaling path. In particular, the The REFER method follows the session's current signaling path. In
Request-URI of the REFER method identifies the recipient. particular, the Request-URI of the REFER method identifies the
recipient.
Unless stated otherwise, the protocol for emitting and responding to a Unless stated otherwise, the protocol for emitting and responding to
REFER request are identical to those for a BYE request in [2]. The a REFER request are identical to those for a BYE request in [1]. The
behavior of SIP entities not implementing the REFER (or any other behavior of SIP entities not implementing the REFER (or any other
unknown) method is explicitly defined in [2] and is not discussed unknown) method is explicitly defined in [1] and is not discussed
further here. further here.
3.1 The Refer-To Header 3.1 The Refer-To Header
Refer-To is a request-header as defined by [2]. It may only appear in Refer-To is a request-header as defined by [1]. It may only appear
a REFER request. in a REFER request.
Refer-To = ("Refer-To" | "r") ":" URL Refer-To = ("Refer-To" | "r") ":" URL
A REFER method MUST contain exactly one Refer-To header. 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 MAY be encrypted as part of end-end encryption.
The Contact header is an important part of the The Contact header is an important part of the
Route/Record-Route mechanism and is not available Route/Record-Route mechanism and is not available
for this task. for this task.
3.1.1 Examples 3.1.1 Examples
Refer-To: sip:alice@atlanta.com Refer-To: sip:alice@atlanta.com
Refer-To: sip:bob@biloxi.com?Accept-Contact=sip:bobsdesk.biloxi.com?Ca Refer-To:
sip:bob@biloxi.com?Accept-Contact=sip:bobsdesk.biloxi.com?Ca
ll-ID=55432@alicepc.atlanta.com ll-ID=55432@alicepc.atlanta.com
Refer-To: sip:carol@cleveland.com;method=SUBSCRIBE Refer-To: sip:carol@cleveland.com;method=SUBSCRIBE
Refer-To: http://www.ietf.org Refer-To: http://www.ietf.org
The Referred-By Header
Referred-By is a request-header as defined by [2]. It can appear in 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 any request. It conveys the identity of the original REFERrer to the
referred-to party, optionally proving the identity and that the referred-to party, optionally proving the identity and that the
REFERrer actually issued this reference. REFERrer actually issued this reference.
Referred-By = ("Referred-By" | "b") ":" referrer-url ";" Referred-By = ("Referred-By" | "b") ":" referrer-url ";"
( referenced-url ( referenced-url
| ( referenced-url ";" ref-signature ) | ( referenced-url ";" ref-signature )
| ( ref-signature ";" referenced-url ) | ( ref-signature ";" referenced-url )
) )
referrer-url = ( name-addr | addr-spec ) referrer-url = ( name-addr | addr-spec )
referenced-url = "ref" "=" "<" URL ">" referenced-url = "ref" "=" "<" URL ">"
ref-signature = signature-scheme *( ";" sig-scheme-params ) ref-signature = signature-scheme *( ";" sig-scheme-params )
signature-scheme = "scheme" "=" token signature-scheme = "scheme" "=" token
sig-scheme-parms = token "=" ( token | quoted-string ) sig-scheme-parms = token "=" ( token | quoted-string )
The referrer-url contains the SIP URL of the party sending the REFER 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 request. The referenced-url contains a copy of the URL placed in the
Refer-To: header. Any occurrences of < or > in the referenced-url MUST Refer-To: header. Any occurrences of < or > in the referenced-url
be escaped. The ref-signature contains a signature over the MUST be escaped. The ref-signature contains a signature over the
concatenation of referrer-url and referenced-url. An example concatenation of referrer-url and referenced-url. An example
signature scheme is given in section 3.1.2. signature scheme is given in section 3.1.2.
A REFER request MUST contain exactly one Referred-By header. A REFER request MUST contain exactly one Referred-By header.
(Open Issue: Should Refer Expire? (Section 5.2).)
The Referred-By header SHOULD be signed to help detection of REFERs The Referred-By header SHOULD be signed to help detection of REFERs
from unauthorized third parties. A signed Referred-By header SHOULD from unauthorized third parties. A signed Referred-By header SHOULD
include a Date header in the referrer-url to facilitate detection of include a Date header in the referrer-url to facilitate detection of
replay attacks. replay attacks.
A UA MAY reject a request containing an unsigned Referred-By header. A A UA MAY reject a request containing an unsigned Referred-By header.
UA SHOULD verify the signature on any Referred-By header it receives. 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 MAY be encrypted as part of end-end
encryption.
3.1.2 A PGP based signature-scheme 3.2.1 A PGP based signature-scheme
One signature-scheme for Referred-By headers uses PGP as follows: One signature-scheme for Referred-By headers uses PGP as follows:
signature-scheme = "scheme" "=" "pgp" signature-scheme = "scheme" "=" "pgp"
sig-scheme-parms = pgp-version | signed-by | pgp-signature sig-scheme-parms = pgp-version | signed-by | pgp-signature
pgp-version, signed-by and pgp-signature are defined in section 15.1 pgp-version, signed-by and pgp-signature are defined in section 15.1
of RFC2543, with the modification that the signature is computed of RFC2543, with the modification that the signature is computed
across the concatenation of the referrer-url and the referenced-url. across the concatenation of the referrer-url and the referenced-url.
3.1.3 Examples 3.2.2 Examples
Referred-By: sip:alice@atlanta.com;ref=<http:www.ietf.org> Referred-By: sip:alice@atlanta.com;ref=<http:www.ietf.org>
Referred-By: "Bob" <sip:bob@biloxi.com>;ref=<sip:alice@atlanta.com>; Referred-By: "Bob"
scheme=pgp;pgp-version="5.0";signature="the signature" <sip:bob@biloxi.com>;ref=<sip:alice@atlanta.com>;scheme=pgp;pgp-version="5.0";signature="the signature"
(Note that in the last example, the signature would be over the (Note that in the last example, the signature would be over the
string "sip:bob@biloxi.comsip:alice@atlanta.com") string "sip:bob@biloxi.comsip:alice@atlanta.com")
3.2 Header Field Support for the REFER Method 3.3 Header Field Support for the REFER Method
This table adds a column to tables 4 and 5 in [2], describing header This table adds a column to tables 4 and 5 in [1], describing header
presence in a REFER method. See [2] for a key for the symbols used. A presence in a REFER method. See [1] for a key for the symbols used.
row for the Refer-To: and Referred-By request-header should be 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 inferred, each mandatory for REFER. Refer-To is not applicable for
other methods. Referred-By is a general Request header. The enc and e- all other methods. Referred-By is a general Request header. The enc
e columns in [2] apply to the REFER method unmodified. and e-e columns in [1] apply to the REFER method unmodified.
Header Where REFER Header Where REFER
Accept R - Accept R -
Accept-Encoding R - Accept-Encoding R -
Accept-Language R o Accept-Language R o
Allow R - Allow R -
Allow 405 m Allow 405 m
Authorization R o Authorization R o
Call-ID gc m Call-ID gc m
Contact R o Contact R o
skipping to change at page 8, line 24 skipping to change at page 7, line 9
Server r o Server r o
Subject R - Subject R -
Timestamp g o Timestamp g o
To gc(1) m To gc(1) m
Unsupported 420 o Unsupported 420 o
User-Agent g o User-Agent g o
Via gc(2) m Via gc(2) m
Warning r o Warning r o
WWW-Authenticate 401 o WWW-Authenticate 401 o
3.3 Message Body Inclusion 3.4 Message Body Inclusion
A REFER method may contain a body which SHOULD be processed according A REFER method may contain a body which SHOULD be processed
to its Content-Type. according to its Content-Type.
3.4 Responses to the REFER Method 3.5 Responses within the REFER transaction
An agent responding to a REFER Method MUST return a 400 Bad Request if An agent responding to a REFER Method MUST return a 400 Bad Request
the request contained zero or more than one Refer-To headers. An agent if the request contained zero or more than one Refer-To headers. An
responding to a REFER Method MUST return a 400 Bad Request if the agent responding to a REFER Method MUST return a 400 Bad Request if
request contained zero or more than one Referred-By headers. An agent the request contained zero or more than one Referred-By headers. An
(including proxies generating local responses) MAY return a 100 Trying agent (including proxies generating local responses) MAY return a
or any appropriate 400-600 class response as prescribed by [2]. If the 100 Trying or any appropriate 400-600 class response as prescribed
recipient's agent decides to contact the resource in the Refer-To by [1]. If the recipient's agent decides to contact the resource in
header, a 200 OK response MUST be returned if it the contact was the Refer-To header, a 200 OK response MUST be returned before the
successful, otherwise a 503 Service Unavailable MUST be returned. The REFER transaction expires. (Open Issue: Should this be a 202
503 response MAY contain a Retry-After: header indicating when the Accepted?) (Section 5.1)
REFER may be attempted again.
3.5 Behavior of SIP User Agents Editor's note - The previous version of this draft required the
agent responding to REFER to wait until the referred action
completed before sending a final response to the REFER. That final
response reflected the success or failure of the referred action.
This was infeasible due to the transaction timeout rules defined for
non-INVITE requests in [1]. A REFER must always receive an immediate
(within the lifetime of a non-INVITE transaction) final response.
3.6 Behavior of SIP User Agents
3.6.1 Accessing the referred-to resource
A UA receiving a well-formed REFER request SHOULD request approval A UA receiving a well-formed REFER request SHOULD request approval
from the user to proceed (this request could be interactive or through from the user to proceed (this request could be interactive or
configuration). Upon receiving approval from the user, the UA MUST through configuration). Upon receiving approval from the user, the
contact the resource identified by the URL in the Refer-To: header. 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.
Note that if the URL is a SIP URL, it could contain header fields such 3.6.2 Reporting on the results of the reference
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.6 Behavior of SIP Registrars/Redirect Servers Once it is known whether the reference succeeded or failed, the UA
receiving the REFER SHOULD notify the agent sending the refer using
the NOTIFY mechanism defined in Event Notification in SIP[3] as if
the the REFER had established a subscription. In particular:
o The NOTIFY should reflect the To:, From:, and Call-ID headers
from the REFER as if they had arrived in a SUBSCRIBE.
o If the reference succeeded, the NOTIFY MUST contain Event:
refersuccess
o If the reference failed for any reason, or was not attempted
after being accepted, the NOTIFY MUST contain Event: referfailure
o The notifying UA SHOULD send exactly one NOTIFY with an event
from the profile {refersuccess,referfailure}. If multiple
notifications are sent, perhaps including events from other
extension drafts, the UA MUST NOT send both refersuccess and
referfailure events.
o Analogous to the case for SUBSCRIBE described in [3], the agent
that issued the REFER MUST be prepared to receive a NOTIFY before
the REFER transaction completes.
Open Issue: This makes REFER dependent on sip-events (Section 5.3)
Open Issue: The events will need to be registered with IANA (Section
5.4)
3.7 Behavior of SIP Registrars/Redirect Servers
Registrars and Redirect Servers SHOULD return a 603 to a REFER Registrars and Redirect Servers SHOULD return a 603 to a REFER
request, unless they are also playing some other SIP role. request, unless they are also playing some other SIP role.
3.7 Behavior of SIP Proxies 3.8 Behavior of SIP Proxies
SIP Proxies do not require modification to support the REFER method. SIP Proxies do not require modification to support the REFER method.
Specifically, as required by [2], a proxy should process a REFER Specifically, as required by [1], a proxy should process a REFER
request the same way it processes an OPTIONS request. request the same way it processes an OPTIONS request.
3.8 Security Considerations 3.9 Prototypical REFER callflow
The security requirements of [2] apply to the REFER method. Agent A Agent B
| |
| REFER |
|----------------------->|
| 200 OK |
|<-----------------------|
| |
| |------->
| | (whatever)
| |<------
| |
| NOTIFY |
|<-----------------------|
| 200 OK |
|----------------------->|
| |
| |
3.10 Security Considerations
The security requirements of [1] apply to the REFER method.
This mechanism relies on providing contact information for the This mechanism relies on providing contact information for the
referred-to resource to the party being referred. Care should be taken referred-to resource to the party being referred. Care should be
to provide a suitably restricted URI if the referred to resource taken to provide a suitably restricted URI if the referred to
should be protected. resource should be protected.
Care should be taken when implementing the logic that determines Care should be taken when implementing the logic that determines
whether or not to accept the REFER request. A UA not capable of whether or not to accept the REFER request. A UA not capable of
accessing non-SIP URLs SHOULD NOT accept REFER requests to them. accessing non-SIP URLs SHOULD NOT accept REFER requests to them.
4 Call Transfer 4. Call Transfer
4.1 Actors and Roles 4.1 Actors and Roles
There are three actors in a given transfer event, each playing one of There are three actors in a given transfer event, each playing one
the following roles: of the following roles:
Transferee - the party being transferred to the Transfer Transferee - the party being transferred to the Transfer
Target. Target.
Transferor - the party initiating the transfer Transferor - the party initiating the transfer
Transfer Target - the new party being introduced into a call with Transfer Target - the new party being introduced into a call with
the Transferee. the Transferee.
The following roles are used to describe transfer requirements and The following roles are used to describe transfer requirements and
skipping to change at page 11, line 24 skipping to change at page 10, line 38
that the user experience in a transfer must be that the user experience in a transfer must be
significantly different from what a current PBX or significantly different from what a current PBX or
Centrex user expects. As the call-flows in this Centrex user expects. As the call-flows in this
document show, this is not the case. A client MAY document show, this is not the case. A client MAY
preserve the current experience. In fact, without preserve the current experience. In fact, without
this requirement, some forms of the current this requirement, some forms of the current
experience (ringback on unattended transfer failure experience (ringback on unattended transfer failure
for instance) will be lost. for instance) will be lost.
3. The Transferor MUST know whether or not the transfer was 3. The Transferor MUST know whether or not the transfer was
successful (this is significantly different from the requirements successful (this is significantly different from the
of draft-ietf-sip-cc-01). requirements of draft-ietf-sip-cc-01).
4.3 Using REFER to achieve Call Transfer 4.3 Using REFER to achieve Call Transfer
A REFER can be issued by the Transferor to cause the Transferee to 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 issue an INVITE to the Transfer-Target. Note that a successful REFER
transaction does not terminate the session between the Transferor and transaction does not terminate the session between the Transferor
the Transferee. If those parties wish to terminate their session, they and the Transferee. If those parties wish to terminate their
must do so with a subsequent BYE request. The media negotiated between session, they must do so with a subsequent BYE request. The media
the transferee and the transfer target is not affected by the media negotiated between the transferee and the transfer target is not
that had been negotiated between the transferor and the transferee. In affected by the media that had been negotiated between the
particular, the INVITE issued by the Transferee will have the same SDP transferor and the transferee. In particular, the INVITE issued by
body it would have if he Transferee had initiated that INVITE on its the Transferee will have the same SDP body it would have if he
own. Further, the disposition of the media streams between the Transferee had initiated that INVITE on its own. Further, the
Transferor and the Transferee is not altered by the REFER method. disposition of the media streams between the Transferor and the
Agents may alter a session's media through additional signaling. For Transferee is not altered by the REFER method. Agents may alter a
example, they may make use of the SIP hold re-INVITE [2] or the session's media through additional signaling. For example, they may
conferencing extensions provided by this framework. make use of the SIP hold re-INVITE [1] or the conferencing
extensions provided by this framework.
4.4 Unattended Transfer 4.4 Unattended Transfer
Unattended Transfer consists of the Transferor providing the Transfer Unattended Transfer consists of the Transferor providing the
Target's contact to the Transferee. The Transferee attempts to Transfer Target's contact to the Transferee. The Transferee attempts
establish a session using that contact and reports the results of that to establish a session using that contact and reports the results of
attempt to the Transferor. The signaling relationship between the that attempt to the Transferor. The signaling relationship between
Transferor and Transferee is not terminated, so the call is the Transferor and Transferee is not terminated, so the call is
recoverable if the Transfer Target cannot be reached. Note that the recoverable if the Transfer Target cannot be reached. Note that the
Transfer Target's contact information has been exposed to the Transfer Target's contact information has been exposed to the
Transferee. The provided contact can be used to make new calls in the Transferee. The provided contact can be used to make new calls in
future. the future. The diagrams below show indicate the first line of each
message. All messages in a particular diagram share the same
The diagrams below show indicate the first line of each message. All Call-ID. In these diagrams, media is managed through reINVITE holds,
messages in a particular diagram share the same Call-ID. In these but other mechanisms (mixing multiple media streams at the UA or
diagrams, media is managed through reINVITE holds, but other using the conferencing extensions for example) are valid.
mechanisms (mixing multiple media streams at the UA or using the
conferencing extensions for example) are valid.
4.4.1 Successful Unattended Transfer 4.4.1 Successful Unattended Transfer
Transferor Transferee Transfer Transferor Transferee Transfer
| | Target | | Target
| INVITE | | | INVITE | |
|<-------------------| | |<-------------------| |
| 200 OK | | | 200 OK | |
|------------------->| | |------------------->| |
| ACK | | | ACK | |
|<-------------------| | |<-------------------| |
| INVITE (hold) | | | INVITE (hold) | |
|------------------->| | |------------------->| |
| 200 OK | | | 200 OK | |
|<-------------------| | |<-------------------| |
| ACK | | | ACK | |
|------------------->| | |------------------->| |
| REFER | | | REFER | |
|------------------->| | |------------------->| |
| 100 Trying | | | 200 OK | |
|<-------------------| | |<-------------------| |
| | INVITE | | | INVITE |
| |------------------->| | |------------------->|
| | 200 OK | | | 200 OK |
| |<-------------------| | |<-------------------|
| | ACK | | | ACK |
| |------------------->| | |------------------->|
| 200 OK | | | NOTIFY (refersuccess) |
|<-------------------| | |<-------------------| |
| 200 OK | |
|------------------->| |
| BYE | | | BYE | |
|------------------->| | |------------------->| |
| 200 OK | | | 200 OK | |
|<-------------------| | |<-------------------| |
| | BYE | | | BYE |
| |<-------------------| | |<-------------------|
| | 200 OK | | | 200 OK |
| |------------------->| | |------------------->|
4.4.2 Failed Unattended Transfer 4.4.2 Failed Unattended Transfer
skipping to change at page 14, line 24 skipping to change at page 13, line 24
| ACK | | | ACK | |
|<-------------------| | |<-------------------| |
| INVITE (hold) | | | INVITE (hold) | |
|------------------->| | |------------------->| |
| 200 OK | | | 200 OK | |
|<-------------------| | |<-------------------| |
| ACK | | | ACK | |
|------------------->| | |------------------->| |
| REFER | | | REFER | |
|------------------->| | |------------------->| |
| 100 Trying | | | 200 OK | |
|<-------------------| | |<-------------------| |
| | INVITE | | | INVITE |
| |------------------->| | |------------------->|
| | 486 Busy Here | | | 486 Busy Here |
| |<-------------------| | |<-------------------|
| | ACK | | | ACK |
| |------------------->| | |------------------->|
| 503 Service Unavailable | | NOTIFY (referfailure) |
|<-------------------| | |<-------------------| |
| 200 OK | |
|------------------->| |
| INVITE (unhold) | | | INVITE (unhold) | |
|------------------->| | |------------------->| |
| 200 OK | | | 200 OK | |
|<-------------------| | |<-------------------| |
| ACK | | | ACK | |
|------------------->| | |------------------->| |
| BYE | | | BYE | |
|------------------->| | |------------------->| |
| 200 OK | | | 200 OK | |
|<-------------------| | |<-------------------| |
4.5 Unattended Transfer with Consultation Hold 4.5 Unattended Transfer with Consultation Hold
Transfer with Consultation Hold involves a session between the Transfer with Consultation Hold involves a session between the
transferor and the transfer target before the transfer actually takes transferor and the transfer target before the transfer actually
place. This is implemented with SIP Hold and Unattended Transfer as takes place. This is implemented with SIP Hold and Unattended
described above. Transfer as described above.
4.5.1 Variation 1 : Exposes transfer target 4.5.1 Variation 1 : Exposes transfer target
The transferor places the transferee on hold, establishes a call with The transferor places the transferee on hold, establishes a call
the transfer target to alert them to the impending transfer, with the transfer target to alert them to the impending transfer,
terminates the connection with the transfer target, then proceeds with terminates the connection with the transfer target, then proceeds
unattended transfer as above. This variation can be used to provide an with unattended transfer as above. This variation can be used to
experience similar to that expected by current PBX and Centrex users. provide an experience similar to that expected by current PBX and
Centrex users.
To (hopefully) improve clarity, non-REFER transactions have been To (hopefully) improve clarity, non-REFER transactions have been
collapsed into one indicator with the arrow showing the direction of collapsed into one indicator with the arrow showing the direction of
the request. the request.
Transferor Transferee Transfer Transferor Transferee Transfer
| | Target | | Target
| | | | | |
Call-ID:1 | INVITE/200 OK/ACK | | Call-ID:1 | INVITE/200 OK/ACK | |
|<-------------------| | |<-------------------| |
Call-ID:1 | INVITE (hold)/200 OK/ACK | Call-ID:1 | INVITE (hold)/200 OK/ACK |
|------------------->| | |------------------->| |
Call-ID:2 | INVITE/200 OK/ACK | | Call-ID:2 | INVITE/200 OK/ACK | |
|---------------------------------------->| |---------------------------------------->|
Call-ID:2 | BYE/200 OK | | Call-ID:2 | BYE/200 OK | |
|---------------------------------------->| |---------------------------------------->|
Call-ID:1 | REFER | | Call-ID:1 | REFER | |
|------------------->| | |------------------->| |
| 100 Trying | | | 200 OK | |
|<-------------------| | |<-------------------| |
Call-ID:1 | | INVITE/200 OK/ACK | Call-ID:1 | | INVITE/200 OK/ACK |
| |------------------->| | |------------------->|
| 200 OK | | Call-ID:1 | NOTIFY (refersuccess) |
|<-------------------| | |<-------------------| |
| 200 OK | |
|------------------->| |
Call-ID:1 | BYE/200 OK | | Call-ID:1 | BYE/200 OK | |
|------------------->| | |------------------->| |
Call-ID:1 | | BYE/200 OK | Call-ID:1 | | BYE/200 OK |
| |<-------------------| | |<-------------------|
4.5.2 Variation 2 : Protects transfer target 4.5.2 Variation 2 : Protects transfer target
The transferor places the transferee on hold, establishes a call with The transferor places the transferee on hold, establishes a call
the transfer target and then reverses their roles, transferring the with the transfer target and then reverses their roles, transferring
original transfer target to the original transferee. This has the the original transfer target to the original transferee. This has
advantage of hiding information about the original transfer target the advantage of hiding information about the original transfer
from the original transferee. On the other hand, the Transferee's target from the original transferee. On the other hand, the
experience is different that in current systems. The Transferee is Transferee's experience is different that in current systems. The
effectively "called back" by the Transfer Target. Transferee is effectively "called back" by the Transfer Target.
Transferor Transferee Transfer Transferor Transferee Transfer
| | Target | | Target
| | | | | |
Call-ID:1 | INVITE/200 OK/ACK | | Call-ID:1 | INVITE/200 OK/ACK | |
|<-------------------| | |<-------------------| |
Call-ID:1 | INVITE (hold)/200 OK/ACK | Call-ID:1 | INVITE (hold)/200 OK/ACK |
|------------------->| | |------------------->| |
Call-ID:2 | INVITE/200 OK/ACK | | Call-ID:2 | INVITE/200 OK/ACK | |
|---------------------------------------->| |---------------------------------------->|
Call-ID:2 | INVITE (hold)/200 OK/ACK | Call-ID:2 | INVITE (hold)/200 OK/ACK |
|---------------------------------------->| |---------------------------------------->|
Call-ID:2 | REFER | | Call-ID:2 | REFER | |
|---------------------------------------->| |---------------------------------------->|
| 100 Trying | | | 200 Trying | |
|<----------------------------------------| |<----------------------------------------|
Call-ID:2 | | INVITE/200 OK/ACK | Call-ID:2 | | INVITE/200 OK/ACK |
| |<-------------------| | |<-------------------|
| 200 OK | | Call-ID:2 | NOTIFY (refersuccess) |
|<----------------------------------------| |<----------------------------------------|
| 200 OK | |
|------------------->| |
Call-ID:1 | BYE/200 OK | | Call-ID:1 | BYE/200 OK | |
|------------------->| | |------------------->| |
Call-ID:2 | BYE/200 OK | | Call-ID:2 | BYE/200 OK | |
|---------------------------------------->| |---------------------------------------->|
Call-ID:2 | | BYE/200 OK | Call-ID:2 | | BYE/200 OK |
| |------------------->| | |------------------->|
4.5.3 Consultation Hold in the presence of forking proxies 4.5.3 Consultation Hold in the presence of forking proxies
It is worth noting that the examples given above abstract away any 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, proxies that might be between the three parties. In 4.5.1 for
the URL used to reach the Transfer Target may go through a forking example, the URL used to reach the Transfer Target may go through a
proxy. There is no guarantee that the Transferee's and Transferor's forking proxy. There is no guarantee that the Transferee's and
invitations to the Transfer Target will reach the same endpoint. If Transferor's invitations to the Transfer Target will reach the same
the proxy forked in parallel, both invitations could cause multiple endpoint. If the proxy forked in parallel, both invitations could
endpoints to ring. To increase the probability of the desired behavior cause multiple endpoints to ring. To increase the probability of the
of having the referred invite reach and ring only the same endpoint as desired behavior of having the referred invite reach and ring only
the consultation invite, the Transferor SHOULD issue the REFER request the same endpoint as the consultation invite, the Transferor SHOULD
with the Refer-To: header containing the Contact the Transfer Target issue the REFER request with the Refer-To: header containing the
provided in its 200 OK to the Transferor's INVITE. If that REFER Contact the Transfer Target provided in its 200 OK to the
fails, the Transferor SHOULD issue another REFER with the Refer-To: Transferor's INVITE. If that REFER fails, the Transferor SHOULD
header containing the URL it used to reach the Transfer Target, issue another REFER with the Refer-To: header containing the URL it
augmented with an Accept-Contact header containing the Contact the used to reach the Transfer Target, augmented with an Accept-Contact
Transfer Target provided. header containing the Contact the Transfer Target provided.
4.6 Attended Transfer 4.6 Attended Transfer
In an attended transfer, the three actors participate in an ad-hoc In an attended transfer, the three actors participate in an ad-hoc
conference as part of the event. Discussion of the implementation of conference as part of the event. Discussion of the implementation of
attended transfer is thus deferred until the conferencing portion of attended transfer is thus deferred until the conferencing portion of
the Call Control framework has been addressed. the Call Control framework has been addressed.
4.7 Transfer with multiple parties 4.7 Transfer with multiple parties
skipping to change at page 17, line 39 skipping to change at page 16, line 45
2 | |INVITE (hold)/200 OK/ACK "Hold please" 2 | |INVITE (hold)/200 OK/ACK "Hold please"
| |<-----------| | | |<-----------| |
3 | | |INVITE/200 OK/ACK 3 | | |INVITE/200 OK/ACK
| | |--------->|"You have a call | | |--------->|"You have a call
| | | |from Mary" | | | |from Mary"
| | | | "Put her through" | | | | "Put her through"
3 | | |INVITE (hold)/200 OK/ACK 3 | | |INVITE (hold)/200 OK/ACK
| | |--------->| | | |--------->|
2 | |REFER | | 2 | |REFER | |
| |<-----------| | | |<-----------| |
| |100 Trying | | | |200 OK | |
| |----------->| | | |----------->| |
2 | |INVITE/200 OK/ACK | 2 | |INVITE/200 OK/ACK |
| |---------------------->|"This is Fred" | |---------------------->|"This is Fred"
| |200 OK | | "Please hold for 2 | |NOTIFY (refersuccess) | "Please hold for
| |----------->| | Mary" | |----------->| | Mary"
| |200 OK | |
| |<-----------| |
2 | |BYE/200 OK | | 2 | |BYE/200 OK | |
| |<-----------| | | |<-----------| |
3 | | |BYE/200 OK| 3 | | |BYE/200 OK|
| | |--------->| | | |--------->|
2 | |INVITE (hold)/200 OK/ACK 2 | |INVITE (hold)/200 OK/ACK
| |---------------------->| | |---------------------->|
1 |REFER | | | 1 |REFER | | |
|<-----------| | | |<-----------| | |
|100 Trying | | | |200 OK | | |
|----------->| | | |----------->| | |
1 |INVITE/200 OK/ACK | | 1 |INVITE/200 OK/ACK | |
|----------------------------------->| "Hey Fred" |----------------------------------->| "Hey Fred"
|200 OK | | | "Hello Mary" 1 |NOTIFY (refersuccess) | | "Hello Mary"
|----------->| | | |----------->| | |
|200 OK | | |
|<-----------| | |
1 |BYE/200 OK | | | 1 |BYE/200 OK | | |
|<-----------| | | |<-----------| | |
2 | |BYE/200 OK | | 2 | |BYE/200 OK | |
| |---------------------->| | |---------------------->|
1 |BYE/200 OK | | | 1 |BYE/200 OK | | |
|<-----------------------------------| "See you later" |<-----------------------------------| "See you later"
5 Editor's Address 5. Open Issues
Robert Sparks 5.1 200 vs 202
dynamicsoft
200 Executive Drive
Suite 120
West Orange, NJ 07052
email: rsparks@dynamicsoft.com
6 Acknowledgments Should an agent accepting a NOTIFY request return a 200 OK or a 202
Accepted?
5.2 Should REFER expire?
Since REFER is effectively establishing a Subscription per [3],
should the REFER request be required to contain an Expires: header?
This would allow REFERer to specify how long he's willing to wait
for the reference to complete. If the referred action exceeds that
time, the agent processing the refer could return referfailure, stop
trying, and free the state it needed for that processing. Without
this or a similar mechanism, both agents involved in a REFER
transaction could be forced to hold state indefinitely.
5.3 REFER is now dependent on sip-events
By introducing NOTIFY, this work is prevented from moving to RFC
until the sip-events draft moves to that level (that work is
currently an individual submission). What needs to happen to our
deliverable schedule to allow for completing the sip-events work?
5.4 Registering the events with IANA
When we near the end of the process, the events we agree to use for
this purpose (currently proposed as refersuccess and referfailure)
will need to be registered with IANA per [3].
6. Acknowledgments
This draft is a collaborative product of the SIP working group. The This draft is a collaborative product of the SIP working group. The
editor thanks the following for their early contributions to this editor thanks the following for their early contributions to this
work: Ben Campbell, Chris Cunningham, Steve Donovan, Alan Johnston, work: Ben Campbell, Chris Cunningham, Steve Donovan, Alan Johnston,
Kevin Summers and Dean Willis. Kevin Summers and Dean Willis.
7 References References
[1] S. Bradner, "The Internet Standards Process -- Revision 3",
BCP9, RFC2026, October 1996.
[2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, [1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"SIP:Session Initiation Protocol", RFC 2543, March 1999. "SIP:Session Initiation Protocol", RFC 2543, March 1999.
[3] B. Campbell, "Framework for SIP Call Control Extensions", [2] Campbell, B., "Framework for SIP Call Control Extensions",
Internet Draft draft-ietf-sip-cc-framework-00, Internet draft-ietf-sip-cc-framework-00 (work in progress), March 2000.
Engineering Task Force, March 2000. Work in Progress.
[4] H. Schulzrinne, J. Rosenberg, "SIP Call Control Services", [3] Roach, A., "Event Notification in SIP",
Internet Draft draft-ietf-sip-cc-01, Internet Engineering Task draft-roach-sip-subscibe-notify-02 (work in progress), November
Force, June 17, 1999 Work in Progress (expired). 2000.
[4] Schulzrinne, H. and J. Rosenberg, "SIP Call Control Services",
draft-ietf-sip-cc-01 (work in progress - expired), June 1999.
Author's Address
Robert J. Sparks
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, TX 75024
email: rsparks@dynamicsoft.com
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/