draft-ietf-sip-cc-transfer-04.txt   draft-ietf-sip-cc-transfer-05.txt 
Internet Engineering Task Force R. Sparks Network Working Group R. Sparks
Internet-Draft dynamicsoft Internet-Draft dynamicsoft
Expires: August 27, 2001 February 26, 2001 Expires: January 16, 2002 July 18, 2001
SIP Call Control - Transfer SIP Call Control - Transfer
draft-ietf-sip-cc-transfer-04 draft-ietf-sip-cc-transfer-05
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 27, 2001. This Internet-Draft will expire on January 16, 2002.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
This document defines a SIP extension, REFER, and demonstrates its This document describes providing Call Transfer capabilites in SIP.
use to provide Call Transfer capabilities. This work is part of the Transfer capabilities. This work is part of the Call Control
Call Control Framework. Framework.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Changes from draft-sparks-sip-cc-transfer-03 . . . . . . . 3 2. Changes from draft-sparks-sip-cc-transfer-04 . . . . . . . . 3
3. The REFER Method . . . . . . . . . . . . . . . . . . . . . 4 3. Actors and Roles . . . . . . . . . . . . . . . . . . . . . . 3
3.1 The Refer-To Header . . . . . . . . . . . . . . . . . . . 4 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Using REFER to achieve Call Transfer . . . . . . . . . . . . 4
3.2 The Referred-By Header . . . . . . . . . . . . . . . . . . 5 6. Basic Transfer . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1 A PGP based signature-scheme . . . . . . . . . . . . . . . 5 6.1 Successful Transfer . . . . . . . . . . . . . . . . . . . . 6
3.2.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.2 Failed Transfer . . . . . . . . . . . . . . . . . . . . . . 7
3.3 Header Field Support for the REFER Method . . . . . . . . 6 6.2.1 Target Busy . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4 Message Body Inclusion . . . . . . . . . . . . . . . . . . 7 6.2.2 Transfer Target does not answer . . . . . . . . . . . . . . 8
3.5 Responses within the REFER transaction . . . . . . . . . . 7 7. Transfer with Consultation Hold . . . . . . . . . . . . . . 9
3.6 Behavior of SIP User Agents . . . . . . . . . . . . . . . 8 7.1 Exposing transfer target . . . . . . . . . . . . . . . . . . 9
3.6.1 Accessing the referred-to resource . . . . . . . . . . . . 8 7.2 Protecting transfer target . . . . . . . . . . . . . . . . . 10
3.6.2 Reporting on the results of the reference . . . . . . . . 8 7.3 Recovery when one party does not support REFER . . . . . . . 10
3.6.2.1 Using NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 8 7.4 Consultation Hold in the presence of forking proxies . . . . 11
3.6.2.2 The body of the NOTIFY . . . . . . . . . . . . . . . . . . 8 7.5 Using the Replaces header to improve the Consultation Hold
3.7 Behavior of SIP Registrars/Redirect Servers . . . . . . . 9 experience . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.8 Behavior of SIP Proxies . . . . . . . . . . . . . . . . . 9 7.5.1 Consultation Hold protecting transfer target . . . . . . . . 12
3.9 Prototypical REFER callflow . . . . . . . . . . . . . . . 10 7.5.2 Recovering from one party not supporting the Replaces header 13
3.10 Security Considerations . . . . . . . . . . . . . . . . . 11 7.6 Aborting a Consultation Hold . . . . . . . . . . . . . . . . 14
3.10.1 Circumventing privacy . . . . . . . . . . . . . . . . . . 11 8. Transfer with multiple parties . . . . . . . . . . . . . . . 14
3.10.2 Circumventing security . . . . . . . . . . . . . . . . . . 12 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 15
3.10.3 Limiting the breach . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15
4. Call Transfer . . . . . . . . . . . . . . . . . . . . . . 13 References . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1 Actors and Roles . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . 16
4.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . 13 Full Copyright Statement . . . . . . . . . . . . . . . . . . 17
4.3 Using REFER to achieve Call Transfer . . . . . . . . . . . 14
4.4 Unattended Transfer . . . . . . . . . . . . . . . . . . . 14
4.4.1 Successful Unattended Transfer . . . . . . . . . . . . . . 15
4.4.2 Failed Unattended Transfer . . . . . . . . . . . . . . . . 16
4.5 Unattended Transfer with Consultation Hold . . . . . . . . 16
4.5.1 Variation 1 : Exposes transfer target . . . . . . . . . . 17
4.5.2 Variation 2 : Protects transfer target . . . . . . . . . . 18
4.5.3 Consultation Hold in the presence of forking proxies . . . 18
4.6 Attended Transfer . . . . . . . . . . . . . . . . . . . . 19
4.7 Transfer with multiple parties . . . . . . . . . . . . . . 19
5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 20
5.1 REFER is now dependent on sip-events . . . . . . . . . . . 20
5.2 Registering the events with IANA . . . . . . . . . . . . . 20
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 20
References . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . 21
Full Copyright Statement . . . . . . . . . . . . . . . . . 22
1. Overview 1. Overview
This document defines a SIP[1] extension, REFER, and details its use This document describes providing Call Transfer capabilites in SIP.
to provide Call Transfer capabilities. This is part of a family of Transfer capabilities. This work is part of the Call Control
Call Control extensions described in the Call Control Framework[2] Framework.
document.
Editor's note: Per consensus at the February interim WG meeting, the
two parts of this document, the definition of REFER and its use to
achieve transfer, will be separated into separate documents. That
separation will take place with the next revision of this document.
The mechanisms discussed here are most closely related to
traditional unattended and consultation hold transfers. Discussion
of attended transfer (where all parties are briefly in a conference)
is deferred until the conferencing features in this framework are
addressed.
This work has roots in draft-ietf-sip-cc-01[4] but some basic
semantics are different. In particular, transfers are achieved
through a new method that does not terminate the original signaling
relationship. By disassociating transfers from the processing of
BYE, these changes facilitate recovery of failed transfers and
clarify state management in the participating entities.
2. Changes from draft-sparks-sip-cc-transfer-03
Editor's note: The changes for this revision focused on the changes
to the NOTIFY response mechanism discussed at February's interim
meeting, and clarification to the REFER method itself. As mentioned
above, the intent is to separate this document into two. The split
was postponed a version to ensure the edits to REFER/NOTIFY would be
reflected in the ID repository in time for discussion at IETF 50.
o Modified contents of NOTIFYs to reflect the consensus at the
interim meeting. One event type, with an application/sip body
representing the information to be returned.
o Added message detail to the prototypical flow
o More explicitly stated that REFER MAY occur outside an existing
call-leg
o Reinforced that REFER can be record-routed
o Made the presence of a Contact header mandatory
o Changed the positive response to a REFER request to 202 Accepted
instead of 200 OK
o Corrected editing errors in examples and message diagrams
3. The REFER Method
REFER is a SIP method as defined by RFC2543[1]. The REFER method
indicates that the recipient (identified by the Request-URI) should
contact a third party using the contact information provided in the
method. A success response indicates that the recipient was able to
contact the third party.
Unless stated otherwise, the protocol for emitting and responding to
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
unknown) method is explicitly defined in [1].
A REFER request MAY be placed outside the scope of a call-leg
created with an INVITE. REFER MAY be Record-Routed, hence MUST
contain a single Contact header. REFERs occurring inside an existing
call-leg MUST follow the Route/Record-Route logic of that call-leg.
REFERs occurring outside an existing call-leg effectively create a
new call-leg following the behavior of SUBSCRIBE specified [3].
3.1 The Refer-To Header
Refer-To is a request-header as defined by [1]. It may only appear
in a REFER request.
Refer-To = ("Refer-To" | "r") ":" URL
A REFER method MUST contain exactly one Refer-To header.
The Refer-To header MAY be encrypted as part of end-end encryption.
The Contact header is an important part of the Route/Record-Route
mechanism and is not available for this task.
3.1.1 Examples
Refer-To: sip:alice@atlanta.com
Refer-To: sip:bob@biloxi.com?Accept-Contact=sip:bobsdesk.
biloxi.com&Call-ID=55432@alicepc.atlanta.com
Refer-To: sip:carol@cleveland.com;method=SUBSCRIBE
Refer-To: http://www.ietf.org
Long headers are line-wrapped here for clarity only.
3.2 The Referred-By Header
Referred-By is a request-header as defined by [1]. It can appear in
any request. It conveys the identity of the original REFERrer to the
referred-to party, optionally proving the identity and that the
REFERrer actually issued this reference.
Referred-By = ("Referred-By" | "b") ":" referrer-url ";"
( referenced-url
| ( referenced-url ";" ref-signature )
| ( ref-signature ";" referenced-url )
)
referrer-url = ( name-addr | addr-spec )
referenced-url = "ref" "=" "<" URL ">"
ref-signature = signature-scheme *( ";" sig-scheme-params )
signature-scheme = "scheme" "=" token
sig-scheme-parms = token "=" ( token | quoted-string )
The referrer-url contains the SIP URL of the party sending the REFER
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 be escaped. The ref-signature contains a signature over the
concatenation of referrer-url and referenced-url. An example
signature scheme is given in section 3.1.2.
A REFER request MUST contain exactly one Referred-By header.
The Referred-By header SHOULD be signed to help detection of REFERs
from unauthorized third parties. A signed Referred-By header SHOULD
include a Date header in the referrer-url to facilitate detection of
replay attacks.
A UA MAY reject a request containing an unsigned Referred-By header.
A UA SHOULD verify the signature on any Referred-By header it
receives.
The Referred-By header MAY be encrypted as part of end-end
encryption.
3.2.1 A PGP based signature-scheme
One signature-scheme for Referred-By headers uses PGP as follows:
signature-scheme = "scheme" "=" "pgp"
sig-scheme-parms = pgp-version | signed-by | pgp-signature
pgp-version, signed-by and pgp-signature are defined in section 15.1
of RFC2543, with the modification that the signature is computed
across the concatenation of the referrer-url and the referenced-url.
3.2.2 Examples
Referred-By: sip:alice@atlanta.com;ref=<http:www.ietf.org>
Referred-By: "Bob" <sip:bob@biloxi.com>;
ref=<sip:alice@atlanta.com>;scheme=pgp;
pgp-version="5.0";signature="the signature"
(Note that in the last example, the signature would be over the
string "sip:bob@biloxi.comsip:alice@atlanta.com")
3.3 Header Field Support for the REFER Method
This table adds a column to tables 4 and 5 in [1], describing header
presence in a REFER method. See [1] for a key for the symbols used.
A row for the Refer-To: and Referred-By request-header should be
inferred, each mandatory for REFER. Refer-To is not applicable for
all other methods. Referred-By is a general Request header. The enc
and e-e columns in [1] apply to the REFER method unmodified.
Header Where REFER
Accept R -
Accept-Encoding R -
Accept-Language R o
Allow R -
Allow 405 m
Authorization R o
Call-ID gc m
Contact R m
Contact 1xx -
Contact 2-6xx o
Content-Encoding e -
Content-Length e o
Content-Type e -
CSeq gc m
Date g o
Encryption g o
Expires R o
From gc m
Hide R o
Max-Forwards R o
Organization g o
Priority R -
Proxy-Authenticate 407 o
Proxy-Authorization R o
Proxy-Require R o
Require R o
Retry-After R -
Retry-After 404,480,486 o
Retry-After 503 o
Retry-After 600,603 o
Response-Key R o
Record-Route R o
Record-Route 2xx o
Route R o
Server r o
Subject R -
Timestamp g o
To gc(1) m
Unsupported 420 o
User-Agent g o
Via gc(2) m
Warning r o
WWW-Authenticate 401 o
3.4 Message Body Inclusion
A REFER method may contain a body which SHOULD be processed
according to its Content-Type.
3.5 Responses within the REFER transaction
An agent responding to a REFER Method MUST return a 400 Bad Request
if the request contained zero or more than one Refer-To headers. An
agent responding to a REFER Method MUST return a 400 Bad Request if
the request contained zero or more than one Referred-By headers. An
agent (including proxies generating local responses) MAY return a
100 Trying or any appropriate 400-600 class response as prescribed
by [1]. If the recipient's agent decides to contact the resource in
the Refer-To header, a 202 Accepted response MUST be returned before
the REFER transaction expires.
Editor's note - earlier versions 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
from the user to proceed (this request could be interactive or
through configuration). Upon receiving approval from the user, the
UA MUST contact the resource identified by the URL in the Refer-To:
header. Note that if the URL is a SIP URL, it could contain header
fields such as Call-Id that will be used to form the resulting
request. If the URL is a SIP URL, the Referred-By header in the
REFER request should be copied into the request sent to the
referred-to resource.
3.6.2 Reporting on the results of the reference
3.6.2.1 Using NOTIFY
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 Each NOTIFY should reflect the To:, From:, and Call-ID headers
from the REFER as if they had arrived in a SUBSCRIBE.
o Each NOTIFY MUST contain an event header of Event: refer
o Each NOTIFY MUST contain a body of type "application/sip". The
contents of this body are detailed in Section 3.6.2.2
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.1)
Open Issue: The refer event will need to be registered with IANA
(Section 5.2)
3.6.2.2 The body of the NOTIFY
Each NOTIFY MUST contain a body of type "application/sip". This body
MUST begin with a SIP Response Status-Line as defined in [1]. The
response class in this status line indicates the success of the
referred action. The body MAY contain other SIP headers to provide
information about the outcome of the referenced action.
A minimal, but complete, implementation can respond with a single
NOTIFY containing either the body:
SIP/2.0 200 OK
if the reference was successful or the body:
SIP/2.0 503 Service Unavailable
if the reference failed.
An implementation MAY include more of a SIP message in that body to
convey more information. Warning headers received in responses to
the referred action are good candidates. In fact, if the reference
was to a SIP URL, entire response to the referenced action could be
returned. However, doing so could have grave security repercussions
(see Section 3.10). Implementers must carefully consider what they
choose to include.
Note that if the reference was to a non-SIP URL, status in any
NOTIFYs to the referrer must still be in the form of SIP Response
Status-Lines. The minimal implementation discussed above is
sufficient to provide a basic indication of success or failure. For
example, if a client receives a REFER to a HTTP URL, and is
successful in accessing the resource, its NOTIFY to the referrer can
contain the application/sip body of "SIP/2.0 200 OK"
3.7 Behavior of SIP Registrars/Redirect Servers
Registrars and Redirect Servers SHOULD return a 603 to a REFER
request, unless they are also playing some other SIP role.
3.8 Behavior of SIP Proxies
SIP Proxies do not require modification to support the REFER method.
Specifically, as required by [1], a proxy should process a REFER
request the same way it processes an OPTIONS request.
3.9 Prototypical REFER callflow
Agent A Agent B
| |
| REFER |
|----------------------->|
| 202 Accepted |
|<-----------------------|
| |
| |------->
| | (whatever)
| |<------
| |
| NOTIFY |
|<-----------------------|
| 200 OK |
|----------------------->|
| |
| |
Here are examples of what the four messages between Agent A and
Agent B might look like if the reference to (whatever) that Agent B
makes is successful:
Message One
REFER sip:b@agentland SIP/2.0
Via: SIP/2.0/UDP agenta.agentland
To: sip:b@agentland
From: sip:a@agentland;tag=193402342
Call-ID: 898234234@agenta.agentland
CSeq: 93809823 REFER
Refer-To: (whatever URL)
Referred-By: <sip:a@agentland>;ref=<whatever URL>;
scheme=pgp;pgp-version="5.0";signature="signature goes here"
Contact: sip:a@agentland
Content-Length: 0
Message Two
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP agenta.agentland
To: sip:b@agentland;tag=4992881234
From: sip:a@agentland;tag=193402342
Call-ID: 898234234@agenta.agentland
CSeq: 93809823 REFER
Contact: sip:b@agentland
Content-Length: 0
Message Three
NOTIFY sip:a@agentland SIP/2.0
Via: SIP/2.0/UDP agentb.agentland
To: sip:a@agentland;tag=193402342
From: sip:b@agentland;tag=4992881234
Call-ID: 898234234@agenta.agentland
CSeq: 1993402 NOTIFY
Event: refer
Contact: sip:b@agentland
Content-Type: application/sip
Content-Length: 16
SIP/2.0 200 OK
Message Four
SIP/2.0 200 OK
Via: SIP/2.0/UDP agentb.agentland
To: sip:a@agentland;tag=193402342
From: sip:b@agentland;tag=4992881234
Call-ID: 898234234@agenta.agentland
CSeq: 1993402 NOTIFY
Contact: sip:a@agentland
Content-Length: 0
3.10 Security Considerations
The security requirements of [1] apply to the REFER method.
This mechanism relies on providing contact information for the
referred-to resource to the party being referred. Care should be
taken to provide a suitably restricted URI if the referred to
resource should be protected.
Care should be taken when implementing the logic that determines
whether or not to accept the REFER request. A UA not capable of
accessing non-SIP URLs SHOULD NOT accept REFER requests to them.
Using application/sip bodies to return the progress and results of a
REFER request is extremely powerful. Careless use of that capability
will compromise security and privacy. Here are a couple of simple,
somewhat contrived, examples to demonstrate the potential for harm.
3.10.1 Circumventing privacy
Suppose Alice has a user-agent that accepts REFER requests to SIP
INVITE URLs, and NOTIFYs the referrer of the progress of the INVITE
by copying each response to the INVITE into the body of a NOTIFY.
Suppose further that Carol has a reason to avoid Mallory and has
configured her system at her proxy to only accept calls from a
certain set of people she trusts (including Alice), so that Mallory
doesn't learn when she's around, or what user agent she's actually
using.
Mallory can send a REFER to Alice, with a Refer-To: indicating
Carol. If Alice can reach Carol, the 200 OK Carol sends gets
returned to Mallory in a NOTIFY, letting him know not only that
Carol is around, but also the IP address of the agent she's using.
3.10.2 Circumventing security
Suppose Alice, with the same user agent as above, is working at a
company that is working on the greatest SIP device ever invented -
the SIP FOO. The company has been working for months building the
device and the marketing materials, carefully keeping the idea, even
the name of the idea secret (since a FOO is one of those things that
anybody could do if they'd just had the idea first). FOO is up and
running, and anyone at the company can use it, but it's not
available outside the company firewall.
Mallory has heard rumor that Alice's company is onto something big,
and has even managed to get his hands on a URL that he suspects
might have something to do with it. He sends a REFER to ALICE with
the mysterious URL and as Alice connects to the FOO, Mallory gets
NOTIFYs with bodies containing
Server: FOO/v0.9.7 The mechanisms discussed here are most closely related to traditional
basic and consultation hold transfers. This document does not
discuss transfer scenarios involving ad-hoc conferences (where all
parties involved are briefly in a conference until this transferor
drops out).
3.10.3 Limiting the breach Editor's note: Per working group consensus, draft-ietf-sip-cc-
transfer-04 was split into two drafts. This document details the use
of REFER to achieve call transfer. The definition of REFER itself
was removed to draft-ietf-sip-refer-00
For each of these cases, and in general, returning a carefully 2. Changes from draft-sparks-sip-cc-transfer-04
selected subset of the information available about the progress of
the reference through the NOTIFYs mitigates risk. The minimal
implementation described in Section 3.6.2.2 exposes the least
information about what the agent operating on the REFER request has
done, and is least likely to be a useful tool for malicious users.
4. Call Transfer o Split the draft
o Removed the contested distinction between attended and unattended
transfer (involving an ad-hoc conference).
o Added new failure and recovery flows
o Added flow demonstrating the use of the Replaces header to affect
user experience
4.1 Actors and Roles 3. Actors and Roles
There are three actors in a given transfer event, each playing one There are three actors in a given transfer event, each playing one of
of the following roles: 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 13, line 38 skipping to change at page 4, line 20
Originator, establishes a call to the Recipient Originator, establishes a call to the Recipient
through the Screener, and connects the Originator to through the Screener, and connects the Originator to
the Recipient. the Recipient.
Screener - receives a call ultimately intended for the Recipient Screener - receives a call ultimately intended for the Recipient
and transfers the calling party to the Recipient if and transfers the calling party to the Recipient if
appropriate. appropriate.
Recipient - the party the Originator is ultimately connected to. Recipient - the party the Originator is ultimately connected to.
4.2 Requirements 4. Requirements
1. Any party in a SIP session MUST be able to transfer any other 1. Any party in a SIP session MUST be able to transfer any other
party in that session at any point in that session. party in that session at any point in that session.
2. The Transferor and the Transferee MUST NOT be removed from a 2. The Transferor and the Transferee MUST NOT be removed from a
session as part of a transfer transaction. session as part of a transfer transaction.
At first glance, requirement 2 may seem to indicate At first glance, requirement 2 may seem to indicate
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 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 successful (this is significantly different from the requirements
requirements of draft-ietf-sip-cc-01). of the earlier BYE-Also approach to transfer).
4.3 Using REFER to achieve Call Transfer 5. Using REFER to achieve Call Transfer
A REFER can be issued by the Transferor to cause the Transferee to A REFER [3] can be issued by the Transferor to cause the Transferee
issue an INVITE to the Transfer-Target. Note that a successful REFER to issue an INVITE to the Transfer-Target. Note that a successful
transaction does not terminate the session between the Transferor REFER transaction does not terminate the session between the
and the Transferee. If those parties wish to terminate their Transferor and the Transferee. If those parties wish to terminate
session, they must do so with a subsequent BYE request. The media their session, they must do so with a subsequent BYE request. The
negotiated between the transferee and the transfer target is not media negotiated between the transferee and the transfer target is
affected by the media that had been negotiated between the not affected by the media that had been negotiated between the
transferor and the transferee. In particular, the INVITE issued by transferor and the transferee. In particular, the INVITE issued by
the Transferee will have the same SDP body it would have if he the Transferee will have the same SDP body it would have if he
Transferee had initiated that INVITE on its own. Further, the Transferee had initiated that INVITE on its own. Further, the
disposition of the media streams between the Transferor and the disposition of the media streams between the Transferor and the
Transferee is not altered by the REFER method. Agents may alter a Transferee is not altered by the REFER method. Agents may alter a
session's media through additional signaling. For example, they may session's media through additional signaling. For example, they may
make use of the SIP hold re-INVITE [1] or the conferencing make use of the SIP hold re-INVITE [1] or the conferencing extensions
extensions provided by this framework. provided by this framework.
4.4 Unattended Transfer 6. Basic Transfer
Unattended Transfer consists of the Transferor providing the Basic Transfer consists of the Transferor providing the Transfer
Transfer Target's contact to the Transferee. The Transferee attempts Target's contact to the Transferee. The Transferee attempts to
to establish a session using that contact and reports the results of establish a session using that contact and reports the results of
that attempt to the Transferor. The signaling relationship between that attempt to the Transferor. The signaling relationship between
the 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 Transferee. The provided contact can be used to make new calls in
the future. The diagrams below show indicate the first line of each the future.
message. All messages in a particular diagram share the same
Call-ID. In these diagrams, media is managed through reINVITE holds,
but other mechanisms (mixing multiple media streams at the UA or
using the conferencing extensions for example) are valid.
4.4.1 Successful Unattended Transfer 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 other
mechanisms (mixing multiple media streams at the UA or using the
conferencing extensions for example) are valid.
Each of the flows below shows the call-leg between the Transferor and
the Transferee remaining connected (on hold) during the REFER
process. While this provides the greatest flexibility for recovery
from failure, it is not neccessary. If the Transferor's agent does
not wish to participate in the remainder of the REFER process and has
no intention of assisting with recovery from transfer failure, it
could emit a BYE to the Transferee as soon as the REFER transaction
completes.
6.1 Successful Transfer
Transferor Transferee Transfer Transferor Transferee Transfer
| | Target | | Target
| INVITE | | | INVITE | |
|<-------------------| | |<-------------------| |
| 200 OK | | | 200 OK | |
|------------------->| | |------------------->| |
| ACK | | | ACK | |
|<-------------------| | |<-------------------| |
| INVITE (hold) | | | INVITE (hold) | |
skipping to change at page 16, line 5 skipping to change at page 7, line 5
|------------------->| | |------------------->| |
| BYE | | | BYE | |
|------------------->| | |------------------->| |
| 200 OK | | | 200 OK | |
|<-------------------| | |<-------------------| |
| | BYE | | | BYE |
| |<-------------------| | |<-------------------|
| | 200 OK | | | 200 OK |
| |------------------->| | |------------------->|
4.4.2 Failed Unattended Transfer 6.2 Failed Transfer
6.2.1 Target Busy
Transferor Transferee Transfer Transferor Transferee Transfer
| | Target | | Target
| | | | | |
| INVITE | | | INVITE | |
|<-------------------| | |<-------------------| |
| 200 OK | | | 200 OK | |
|------------------->| | |------------------->| |
| ACK | | | ACK | |
|<-------------------| | |<-------------------| |
skipping to change at page 16, line 48 skipping to change at page 8, line 5
|------------------->| | |------------------->| |
| 200 OK | | | 200 OK | |
|<-------------------| | |<-------------------| |
| ACK | | | ACK | |
|------------------->| | |------------------->| |
| BYE | | | BYE | |
|------------------->| | |------------------->| |
| 200 OK | | | 200 OK | |
|<-------------------| | |<-------------------| |
4.5 Unattended Transfer with Consultation Hold 6.2.2 Transfer Target does not answer
Transferor Transferee Transfer
| | Target
| INVITE | |
|<-------------------| |
| 200 OK | |
|------------------->| |
| ACK | |
|<-------------------| |
| INVITE (hold) | |
|------------------->| |
| 200 OK | |
|<-------------------| |
| ACK | |
|------------------->| |
| REFER | |
|------------------->| |
| 202 Accepted | |
|<-------------------| |
| | INVITE |
| |------------------->|
| | 180 Ringing |
| |<-------------------|
| | (Transferee gets tired of waiting)
| | CANCEL |
| |------------------->|
| | 200 OK (CANCEL) |
| |<-------------------|
| | 487 Request Cancelled (INVITE)
| |<-------------------|
| | ACK |
| |------------------->|
| NOTIFY (487 Request Cancelled) |
|<-------------------| |
| 200 OK | |
|------------------->| |
| INVITE (unhold) | |
|------------------->| |
| 200 OK | |
|<-------------------| |
| ACK | |
|------------------->| |
| BYE | |
|------------------->| |
| 200 OK | |
|<-------------------| |
7. Transfer with Consultation Hold
Transfer with Consultation Hold involves a session between the Transfer with Consultation Hold involves a session between the
transferor and the transfer target before the transfer actually transferor and the transfer target before the transfer actually takes
takes place. This is implemented with SIP Hold and Unattended place. This is implemented with SIP Hold and Transfer as described
Transfer as described above. above.
4.5.1 Variation 1 : Exposes transfer target 7.1 Exposing transfer target
The transferor places the transferee on hold, establishes a call The transferor places the transferee on hold, establishes a call with
with the transfer target to alert them to the impending transfer, the transfer target to alert them to the impending transfer,
terminates the connection with the transfer target, then proceeds terminates the connection with the transfer target, then proceeds
with unattended transfer as above. This variation can be used to with transfer as above. This variation can be used to provide an
provide an experience similar to that expected by current PBX and experience similar to that expected by current PBX and Centrex users.
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 | |
|<-------------------| | |<-------------------| |
skipping to change at page 18, line 5 skipping to change at page 10, line 5
| |------------------->| | |------------------->|
Call-ID:1 | NOTIFY (200 OK) | | Call-ID:1 | NOTIFY (200 OK) | |
|<-------------------| | |<-------------------| |
| 200 OK | | | 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 7.2 Protecting transfer target
The transferor places the transferee on hold, establishes a call The transferor places the transferee on hold, establishes a call with
with the transfer target and then reverses their roles, transferring the transfer target and then reverses their roles, transferring the
the original transfer target to the original transferee. This has original transfer target to the original transferee. This has the
the advantage of hiding information about the original transfer advantage of hiding information about the original transfer target
target from the original transferee. On the other hand, the from the original transferee. On the other hand, the Transferee's
Transferee's experience is different that in current systems. The experience is different that in current systems. The Transferee is
Transferee is effectively "called back" by the Transfer Target. effectively "called back" by the Transfer Target. If supported, use
of the Replaces header can help improve this experience. Examples of
this usage appear later in this document.
Transferor Transferee Transfer 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 | |
|---------------------------------------->| |---------------------------------------->|
skipping to change at page 18, line 43 skipping to change at page 10, line 45
|<----------------------------------------| |<----------------------------------------|
| | 200 OK | | | 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 7.3 Recovery when one party does not support REFER
If protecting or exposing the transfer target is not a concern, it is
possible to complete a transfer with consultation hold when only the
transferor and one other party support REFER.
Transferor Transferee Transfer
| | Target
| | |
Call-ID:1 | INVITE/200 OK/ACK | |
|<-------------------| |
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:1 | REFER | |
|------------------->| |
Call-ID:1 | 501 Not Implemented
|<-------------------| |
Call-ID:2 | REFER | |
|---------------------------------------->|
| 202 Accepted | |
|<----------------------------------------|
Call-ID:2 | | INVITE/200 OK/ACK |
| |<-------------------|
Call-ID:2 | NOTIFY (200 OK) | |
|<----------------------------------------|
| | 200 OK |
|---------------------------------------->|
Call-ID:1 | BYE/200 OK | |
|------------------->| |
Call-ID:2 | BYE/200 OK | |
|---------------------------------------->|
Call-ID:2 | | BYE/200 OK |
| |------------------->|
7.4 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 proxies that might be between the three parties. In 4.5.1 for
example, the URL used to reach the Transfer Target may go through a example, the URL used to reach the Transfer Target may go through a
forking proxy. There is no guarantee that the Transferee's and forking proxy. There is no guarantee that the Transferee's and
Transferor's invitations to the Transfer Target will reach the same Transferor's invitations to the Transfer Target will reach the same
endpoint. If the proxy forked in parallel, both invitations could endpoint. If the proxy forked in parallel, both invitations could
cause multiple endpoints to ring. To increase the probability of the cause multiple endpoints to ring. To increase the probability of the
desired behavior of having the referred invite reach and ring only desired behavior of having the referred invite reach and ring only
the same endpoint as the consultation invite, the Transferor SHOULD the same endpoint as the consultation invite, the Transferor SHOULD
issue the REFER request with the Refer-To: header containing the issue the REFER request with the Refer-To: header containing the
Contact the Transfer Target provided in its 200 OK to the Contact the Transfer Target provided in its 200 OK to the
Transferor's INVITE. If that REFER fails, the Transferor SHOULD Transferor's INVITE. If that REFER fails, the Transferor SHOULD
issue another REFER with the Refer-To: header containing the URL it issue another REFER with the Refer-To: header containing the URL it
used to reach the Transfer Target, augmented with an Accept-Contact used to reach the Transfer Target, augmented with an Accept-Contact
header containing the Contact the Transfer Target provided. header containing the Contact the Transfer Target provided.
4.6 Attended Transfer 7.5 Using the Replaces header to improve the Consultation Hold
experience
In an attended transfer, the three actors participate in an ad-hoc 7.5.1 Consultation Hold protecting transfer target
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.
4.7 Transfer with multiple parties One of the problems with the simplest implementation of a target
protecting transfer is that the transferee is receiving a new call
from the transfer-target. Unless the transferee's agent has a
reliable way to associate this new call with the call it already has
with the transferor, it will have to alert the new call on another
appearance. If this, or some other call-waiting-like UI were not
available, the transferee might be stuck returning a Busy-Here to the
transfer target, effectively preventing the transfer. There are many
ways that that correlation could be provided. The call leg
parameters could be provided directly as header parameters in the
Refer-To: URL for example. The Replaces mechanism [4] uses this
approach and solves this problem nicely.
For the flow below, clid1 means Call Leg Identifier 1, and consists
of the parameters to the Replaces header for call-leg 1. In [4] this
is the Call-ID, To-tag and From-tag.
Note that the transferee's agent emits a BYE to the transferor's
agent as an immediate consequence of processing the Replaces header.
Transferor Transferee Transfer
| | Target
| | |
clid1 | INVITE/200 OK/ACK | |
|<-------------------| |
clid1 | INVITE (hold)/200 OK/ACK |
|------------------->| |
clid2 | INVITE/200 OK/ACK | |
|---------------------------------------->|
clid2 | INVITE (hold)/200 OK/ACK |
|---------------------------------------->|
clid2 | REFER (Refer-To: sip:transferee?Replaces=clid1)
|---------------------------------------->|
clid2 | 202 Accepted | |
|<----------------------------------------|
clid3 | | INVITE (Replaces=clid1)/200 OK/ACK
| |<-------------------|
clid1 | BYE/200 OK | |
|<-------------------| |
clid2 | NOTIFY (200 OK) | |
|<----------------------------------------|
clid2 | | 200 OK |
|---------------------------------------->|
clid2 | BYE/200 OK | |
|---------------------------------------->|
| | (transferee and target converse)
clid3 | | BYE/200 OK |
| |------------------->|
7.5.2 Recovering from one party not supporting the Replaces header
Similar to the case of recovering from a party not supporting REFER,
the transferor can recover from a party not supporting the Replaces
header, at the potential cost of not protecting the transfer target
and reverting to the non-Replaces user experience.
In the above flow, if all of the following are true:
o The Transferee's agent does not support the Replaces header
o The Transferee's agent does not support multiple appearences or
call-waiting and returns Busy-Here to all new INVITEs when engaged
in a call.
o The Transfer-Target's agent is configured to expose the cause of a
REFERenced action failure in its NOTIFY (see the security issues
associated with this choice in [3]).
o The Transferor is willing to expose the Transfer-Target.
then the Transferor can retry the transfer by sending a new REFER to
the Transferee.
7.6 Aborting a Consultation Hold
In any of the consultation hold flows above, the Transferor may
decide to terminate its attempt to contact the Transfer target before
that session is established. Most frequently, that will be the end
of the scenario, but in some circumstances, the transferor may wish
to proceed with the transfer action. For example, he may wish to
complete the transfer knowing that the transferee will end up
evenutally talking to the transfer-target's voice-mail service.
For flows that expose the transfer target, this simply becomes a
basic transfer.
This scenario is far more complicated for flows that protect the
transfer target. Since no session is established between the
transferor and the transfer target, the transfer target's agent would
have to honor out-of-session REFERs, and somehow indicate what's
happening via its user interface (this scenario is most likely to
occur when the transfer-target is away from his agent).
8. Transfer with multiple parties
In this example the Originator places call to the Facilitator who In this example the Originator places call to the Facilitator who
reaches the Recipient through the Screener. The Recipient's contact reaches the Recipient through the Screener. The Recipient's contact
information is exposed to the Facilitator and the Originator. This information is exposed to the Facilitator and the Originator. This
example is provided for clarification of the semantics of the REFER example is provided for clarification of the semantics of the REFER
method only and should not be used as the design of an method only and should not be used as the design of an
implementation. implementation.
Originator Facilitator Screener Recipient Originator Facilitator Screener Recipient
Call-ID | | | | Call-ID | | | |
skipping to change at page 20, line 27 skipping to change at page 15, line 34
|----------->| | | |----------->| | |
|200 OK | | | |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. Open Issues 9. Open Issues
5.1 REFER is now dependent on sip-events
By introducing NOTIFY, this work is prevented from moving to RFC
until the sip-events draft moves to that level (that work is
currently an individual submission). What needs to happen to our
deliverable schedule to allow for completing the sip-events work?
5.2 Registering the events with IANA
When we near the end of the process, the refer event will need to be
registered with IANA per [3].
6. Acknowledgments 10. Acknowledgments
This draft is a collaborative product of the SIP working group. The This draft is a collaborative product of the SIP working group.
editor thanks the following for their early contributions to this Thanks to Alan Johnston for providing the starting point for the new
work: Ben Campbell, Chris Cunningham, Steve Donovan, Alan Johnston, error and recovery flows.
Kevin Summers and Dean Willis.
References References
[1] Handley, M., Schulzrinne, H., Schooler, E. 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.
[2] Campbell, B., "Framework for SIP Call Control Extensions", [2] Campbell, B., "Framework for SIP Call Control Extensions",
draft-ietf-sip-cc-framework-00 (work in progress), March 2000. draft-ietf-sip-cc-framework-00 (work in progress), March 2000.
[3] Roach, A., "Event Notification in SIP", [3] Sparks, R., "The REFER Method", draft-ietf-sip-refer-00 (work in
draft-roach-sip-subscibe-notify-03 (work in progress), February progress), July 2001.
2001.
[4] Schulzrinne, H. and J. Rosenberg, "SIP Call Control Services", [4] Biggs, B. and R. Dean, "The SIP Replaces Header", draft-biggs-
draft-ietf-sip-cc-01 (work in progress - expired), June 1999. sip-replaces-00 (work in progress), November 2000.
Author's Address Author's Address
Robert J. Sparks Robert J. Sparks
dynamicsoft dynamicsoft
5100 Tennyson Parkway 5100 Tennyson Parkway
Suite 1200 Suite 1200
Plano, TX 75024 Plano, TX 75024
email: rsparks@dynamicsoft.com EMail: rsparks@dynamicsoft.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph are
are included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
Funding for the RFC editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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