draft-ietf-sip-cc-transfer-01.txt   draft-ietf-sip-cc-transfer-02.txt 
Internet Engineering Task Force Robert Sparks Internet Engineering Task Force Robert Sparks
Internet Draft dynamicsoft Internet Draft dynamicsoft
draft-ietf-sip-cc-transfer-01.txt draft-ietf-sip-cc-transfer-02.txt
September 2000 November 2000
Expires April 2001 Expires May 2001
SIP Call Control SIP Call Control
Transfer Transfer
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026 [1]. provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
skipping to change at page 2, line 9 skipping to change at page 2, line 9
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 to provide Call Transfer capabilities.
1 Overview...........................................................3 1 Overview...........................................................3
2 Changes from draft-sparks-sip-cc-transfer-01.......................4 2 Changes from draft-sparks-sip-cc-transfer-01.......................4
3 The REFER Method...................................................5 3 The REFER Method...................................................5
3.1 The Refer-To Header............................................5 3.1 The Refer-To Header............................................5
3.2 The Referred-By Header.........................................6 3.1.1 Examples.....................................................5
3.2.1 A PGP based signature-scheme.................................6 3.1.2 A PGP based signature-scheme.................................6
3.3 Header Field Support for the REFER Method......................7 3.1.3 Examples.....................................................7
3.4 Message Body Inclusion.........................................8 3.2 Header Field Support for the REFER Method......................7
3.5 Responses to the REFER Method..................................8 3.3 Message Body Inclusion.........................................8
3.6 Behavior of SIP User Agents....................................8 3.4 Responses to the REFER Method..................................8
3.7 Behavior of SIP Registrars/Redirect Servers....................9 3.5 Behavior of SIP User Agents....................................8
3.8 Behavior of SIP Proxies........................................9 3.6 Behavior of SIP Registrars/Redirect Servers....................9
3.9 Security Considerations........................................9 3.7 Behavior of SIP Proxies........................................9
3.8 Security Considerations........................................9
4 Call Transfer.....................................................10 4 Call Transfer.....................................................10
4.1 Actors and Roles..............................................10 4.1 Actors and Roles..............................................10
4.2 Requirements..................................................11 4.2 Requirements..................................................11
4.3 Using REFER to achieve Call Transfer..........................12 4.3 Using REFER to achieve Call Transfer..........................12
4.4 Unattended Transfer...........................................12 4.4 Unattended Transfer...........................................12
4.4.1 Successful Unattended Transfer..............................13 4.4.1 Successful Unattended Transfer..............................13
4.4.2 Failed Unattended Transfer..................................14 4.4.2 Failed Unattended Transfer..................................14
4.5 Unattended Transfer with Consultation Hold....................14 4.5 Unattended Transfer with Consultation Hold....................14
4.5.1 Variation 1 : Exposes transfer target.......................15 4.5.1 Variation 1 : Exposes transfer target.......................15
4.5.2 Variation 2 : Protects transfer target......................15 4.5.2 Variation 2 : Protects transfer target......................15
4.6 Attended Transfer.............................................16 4.5.3 Consultation Hold in the presence of forking proxies........16
4.7 Transfer with multiple parties................................16 4.6 Attended Transfer.............................................17
4.7 Transfer with multiple parties................................17
5 Editor's Address..................................................18 5 Editor's Address..................................................18
6 Acknowledgments...................................................18 6 Acknowledgments...................................................18
7 References........................................................18 7 References........................................................18
1 Overview 1 Overview
This document defines a SIP [2] extension and details its use to This document defines a SIP [2] 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 document
[3]. [3].
skipping to change at page 4, line 6 skipping to change at page 4, line 6
a new method that does not terminate the original signaling 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 BYE,
these changes facilitate recovery of failed transfers and clarify these changes facilitate recovery of failed transfers and clarify
state management in the participating entities. state management in the participating entities.
Implementers that started with the sip-cc-01 BYE-ALSO technique for Implementers that started with the sip-cc-01 BYE-ALSO technique for
blind-transfer should find it straightforward to migrate to the blind-transfer should find it straightforward to migrate to the
mechanisms set forth here. mechanisms set forth here.
2 Changes from draft-sparks-sip-cc-transfer-01 2 Changes from draft-sparks-sip-cc-transfer-01
. Separated definition of the REFER method and headers from the
definition of its use to achieve transfer. . Allowed the ref= parameter in the Referred-By header to occur
. Replaced the syntax of the Referred-By header to align with sip- either before or after the optional signature.
ietf-sip-guidelines. . Allowed name-addr|addr-spec for the referrer-url in a Referred-By
. Added short forms of Refer-To and Referred-By as recommended by header
sip-ietf-sip-guidelines. . Quoted the referenced-url with <> and required escaping <> if
. Allows REFERs outside the scope of an existing call-leg. 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 [2]. The REFER method indicates
that the recipient should contact a third party using the contact that the recipient should contact a third party using the contact
information provided in the method. A success response indicates that information provided in the method. A success response indicates that
the recipient was able to contact the third party. The REFER method the recipient was able to contact the third party. The REFER method
follows the session's current signaling path. In particular, the follows the session's current signaling path. In particular, the
Request-URI of the REFER method identifies the recipient. Request-URI of the REFER method identifies the recipient.
skipping to change at page 6, line 5 skipping to change at page 5, line 35
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.2 The Referred-By Header 3.1.1 Examples
Refer-To: sip:alice@atlanta.com
Refer-To: sip:bob@biloxi.com?Accept-Contact=sip:bobsdesk.biloxi.com?Ca
ll-ID=55432@alicepc.atlanta.com
Refer-To: sip:carol@cleveland.com;method=SUBSCRIBE
Refer-To: http://www.ietf.org
The Referred-By Header
Referred-By is a request-header as defined by [2]. It can appear in Referred-By is a request-header as defined by [2]. It can appear in
any request. It conveys the identity of the original REFERrer to the 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
[";" ref-signature] | ( referenced-url ";" ref-signature )
referrer-url = SIP-URL | ( ref-signature ";" referenced-url )
referenced-url = "ref" "=" URL )
referrer-url = ( name-addr | addr-spec )
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. The ref-signature contains a signature over 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 concatenation of referrer-url and referenced-url. An example
signature scheme is given in section 3.2.1. 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.
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. A
UA SHOULD verify the signature on any Referred-By header it receives. 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.2.1 A PGP based signature-scheme 3.1.2 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.3 Header Field Support for the REFER Method 3.1.3 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.2 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 [2], describing header
presence in a REFER method. See [2] for a key for the symbols used. A presence in a REFER method. See [2] for a key for the symbols used. A
row for the Refer-To: and Referred-By request-header should be 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 all
other methods. Referred-By is a general Request header. The enc and e- other methods. Referred-By is a general Request header. The enc and e-
e columns in [2] apply to the REFER method unmodified. e columns in [2] apply to the REFER method unmodified.
Header Where REFER Header Where REFER
Accept R - Accept R -
skipping to change at page 8, line 14 skipping to change at page 8, line 24
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.4 Message Body Inclusion 3.3 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 according
to its Content-Type. to its Content-Type.
3.5 Responses to the REFER Method 3.4 Responses to the REFER Method
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 if
the request contained zero or more than one Refer-To headers. An agent 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 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 request contained zero or more than one Referred-By headers. An agent
(including proxies generating local responses) MAY return a 100 Trying (including proxies generating local responses) MAY return a 100 Trying
or any appropriate 400-600 class response as prescribed by [2]. If the or any appropriate 400-600 class response as prescribed by [2]. If the
recipient's agent decides to contact the resource in the Refer-To recipient's agent decides to contact the resource in the Refer-To
header, a 200 OK response MUST be returned if it the contact was header, a 200 OK response MUST be returned if it the contact was
successful, otherwise a 503 Service Unavailable MUST be returned. The successful, otherwise a 503 Service Unavailable MUST be returned. The
503 response MAY contain a Retry-After: header indicating when the 503 response MAY contain a Retry-After: header indicating when the
REFER may be attempted again. REFER may be attempted again.
3.6 Behavior of SIP User Agents 3.5 Behavior of SIP User Agents
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 through
configuration). Upon receiving approval from the user, the UA MUST configuration). Upon receiving approval from the user, the UA MUST
contact the resource identified by the URL in the Refer-To: header. 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 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 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 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 copied into the request sent to the referred-to resource. In
accordance with [2], the UA SHOULD issue a provisional response to the 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 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 receipt. The appropriate response to issue to the REFER on receipt of
a final response from the referred-to resource is discussed in a final response from the referred-to resource is discussed in
"Responses to the REFER Method". "Responses to the REFER Method".
skipping to change at page 9, line 5 skipping to change at page 9, line 15
Note that if the URL is a SIP URL, it could contain header fields such 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 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 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 copied into the request sent to the referred-to resource. In
accordance with [2], the UA SHOULD issue a provisional response to the 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 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 receipt. The appropriate response to issue to the REFER on receipt of
a final response from the referred-to resource is discussed in a final response from the referred-to resource is discussed in
"Responses to the REFER Method". "Responses to the REFER Method".
3.7 Behavior of SIP Registrars/Redirect Servers 3.6 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.8 Behavior of SIP Proxies 3.7 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 [2], 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.9 Security Considerations 3.8 Security Considerations
The security requirements of [2] apply to the REFER method. The security requirements of [2] 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 taken
to provide a suitably restricted URI if the referred to resource to provide a suitably restricted URI if the referred to resource
should be protected. 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
skipping to change at page 12, line 36 skipping to change at page 12, line 36
establish a session using that contact and reports the results of that establish a session using that contact and reports the results of that
attempt to the Transferor. The signaling relationship between the attempt to the Transferor. The signaling relationship between the
Transferor and Transferee is not terminated, so the call is 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 the
future. future.
The diagrams below show indicate the first line of each message. All The diagrams below show indicate the first line of each message. All
messages in a particular diagram share the same Call-ID. In these messages in a particular diagram share the same Call-ID. In these
diagrams, media is managed through reINVITE holds, but using other diagrams, media is managed through reINVITE holds, but other
mechanisms (mixing multiple media streams at the UA or using the mechanisms (mixing multiple media streams at the UA or using the
conferencing extensions for example) are valid. 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 | |
skipping to change at page 16, line 30 skipping to change at page 16, line 30
Call-ID:2 | | INVITE/200 OK/ACK | Call-ID:2 | | INVITE/200 OK/ACK |
| |<-------------------| | |<-------------------|
| 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
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,
the URL used to reach the Transfer Target may go through a forking
proxy. There is no guarantee that the Transferee's and Transferor's
invitations to the Transfer Target will reach the same endpoint. If
the proxy forked in parallel, both invitations could cause multiple
endpoints to ring. To increase the probability of the desired behavior
of having the referred invite reach and ring only the same endpoint as
the consultation invite, the Transferor SHOULD issue the REFER request
with the Refer-To: header containing the Contact the Transfer Target
provided in its 200 OK to the Transferor's INVITE. If that REFER
fails, the Transferor SHOULD issue another REFER with the Refer-To:
header containing the URL it used to reach the Transfer Target,
augmented with an Accept-Contact 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
 End of changes. 

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