draft-ietf-sip-cc-transfer-03.txt   draft-ietf-sip-cc-transfer-04.txt 
Internet Engineering Task Force R. Sparks Internet Engineering Task Force R. Sparks
Internet-Draft dynamicsoft Internet-Draft dynamicsoft
Expires: August 3, 2001 February 2, 2001 Expires: August 27, 2001 February 26, 2001
SIP Call Control - Transfer SIP Call Control - Transfer
draft-sip-cc-transfer-03 draft-ietf-sip-cc-transfer-04
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-Drafts. Internet-Drafts.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any 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 3, 2001. This Internet-Draft will expire on August 27, 2001.
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 within the Call Control This document defines a SIP extension, REFER, and demonstrates its
Framework and demonstrates its use to provide Call Transfer use to provide Call Transfer capabilities. This work is part of the
capabilities. Call Control Framework.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Changes from draft-sparks-sip-cc-transfer-02 . . . . . . . . 3 2. Changes from draft-sparks-sip-cc-transfer-03 . . . . . . . 3
3. The REFER Method . . . . . . . . . . . . . . . . . . . . . . 3 3. The REFER Method . . . . . . . . . . . . . . . . . . . . . 4
3.1 The Refer-To Header . . . . . . . . . . . . . . . . . . . . 3 3.1 The Refer-To Header . . . . . . . . . . . . . . . . . . . 4
3.1.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 The Referred-By Header . . . . . . . . . . . . . . . . . . . 4 3.2 The Referred-By Header . . . . . . . . . . . . . . . . . . 5
3.2.1 A PGP based signature-scheme . . . . . . . . . . . . . . . . 5 3.2.1 A PGP based signature-scheme . . . . . . . . . . . . . . . 5
3.2.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3 Header Field Support for the REFER Method . . . . . . . . . 6 3.3 Header Field Support for the REFER Method . . . . . . . . 6
3.4 Message Body Inclusion . . . . . . . . . . . . . . . . . . . 7 3.4 Message Body Inclusion . . . . . . . . . . . . . . . . . . 7
3.5 Responses within the REFER transaction . . . . . . . . . . . 7 3.5 Responses within the REFER transaction . . . . . . . . . . 7
3.6 Behavior of SIP User Agents . . . . . . . . . . . . . . . . 7 3.6 Behavior of SIP User Agents . . . . . . . . . . . . . . . 8
3.6.1 Accessing the referred-to resource . . . . . . . . . . . . . 7 3.6.1 Accessing the referred-to resource . . . . . . . . . . . . 8
3.6.2 Reporting on the results of the reference . . . . . . . . . 8 3.6.2 Reporting on the results of the reference . . . . . . . . 8
3.7 Behavior of SIP Registrars/Redirect Servers . . . . . . . . 8 3.6.2.1 Using NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 8
3.8 Behavior of SIP Proxies . . . . . . . . . . . . . . . . . . 8 3.6.2.2 The body of the NOTIFY . . . . . . . . . . . . . . . . . . 8
3.9 Prototypical REFER callflow . . . . . . . . . . . . . . . . 9 3.7 Behavior of SIP Registrars/Redirect Servers . . . . . . . 9
3.10 Security Considerations . . . . . . . . . . . . . . . . . . 9 3.8 Behavior of SIP Proxies . . . . . . . . . . . . . . . . . 9
4. Call Transfer . . . . . . . . . . . . . . . . . . . . . . . 9 3.9 Prototypical REFER callflow . . . . . . . . . . . . . . . 10
4.1 Actors and Roles . . . . . . . . . . . . . . . . . . . . . . 9 3.10 Security Considerations . . . . . . . . . . . . . . . . . 11
4.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10 3.10.1 Circumventing privacy . . . . . . . . . . . . . . . . . . 11
4.3 Using REFER to achieve Call Transfer . . . . . . . . . . . . 10 3.10.2 Circumventing security . . . . . . . . . . . . . . . . . . 12
4.4 Unattended Transfer . . . . . . . . . . . . . . . . . . . . 11 3.10.3 Limiting the breach . . . . . . . . . . . . . . . . . . . 12
4.4.1 Successful Unattended Transfer . . . . . . . . . . . . . . . 12 4. Call Transfer . . . . . . . . . . . . . . . . . . . . . . 13
4.4.2 Failed Unattended Transfer . . . . . . . . . . . . . . . . . 13 4.1 Actors and Roles . . . . . . . . . . . . . . . . . . . . . 13
4.5 Unattended Transfer with Consultation Hold . . . . . . . . . 13 4.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . 13
4.5.1 Variation 1 : Exposes transfer target . . . . . . . . . . . 14 4.3 Using REFER to achieve Call Transfer . . . . . . . . . . . 14
4.5.2 Variation 2 : Protects transfer target . . . . . . . . . . . 15 4.4 Unattended Transfer . . . . . . . . . . . . . . . . . . . 14
4.5.3 Consultation Hold in the presence of forking proxies . . . . 15 4.4.1 Successful Unattended Transfer . . . . . . . . . . . . . . 15
4.6 Attended Transfer . . . . . . . . . . . . . . . . . . . . . 16 4.4.2 Failed Unattended Transfer . . . . . . . . . . . . . . . . 16
4.7 Transfer with multiple parties . . . . . . . . . . . . . . . 16 4.5 Unattended Transfer with Consultation Hold . . . . . . . . 16
5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 17 4.5.1 Variation 1 : Exposes transfer target . . . . . . . . . . 17
5.1 200 vs 202 . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.5.2 Variation 2 : Protects transfer target . . . . . . . . . . 18
5.2 Should REFER expire? . . . . . . . . . . . . . . . . . . . . 17 4.5.3 Consultation Hold in the presence of forking proxies . . . 18
5.3 REFER is now dependent on sip-events . . . . . . . . . . . . 17 4.6 Attended Transfer . . . . . . . . . . . . . . . . . . . . 19
5.4 Registering the events with IANA . . . . . . . . . . . . . . 18 4.7 Transfer with multiple parties . . . . . . . . . . . . . . 19
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 20
References . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1 REFER is now dependent on sip-events . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . 18 5.2 Registering the events with IANA . . . . . . . . . . . . . 20
Full Copyright Statement . . . . . . . . . . . . . . . . . . 19 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 20
References . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . 21
Full Copyright Statement . . . . . . . . . . . . . . . . . 22
1. Overview 1. Overview
This document defines a SIP[1] extension and details its use to This document defines a SIP[1] extension, REFER, and details its use
provide Call Transfer capabilities. This is part of a family of Call to provide Call Transfer capabilities. This is part of a family of
Control extensions described in the Call Control Framework[2] Call Control extensions described in the Call Control Framework[2]
document. 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 The mechanisms discussed here are most closely related to
traditional unattended and consultation hold transfers. Discussion traditional unattended and consultation hold transfers. Discussion
of attended transfer (where all parties are briefly in a conference) of attended transfer (where all parties are briefly in a conference)
is deferred until the conferencing features in this framework are is deferred until the conferencing features in this framework are
addressed. 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 semantics are different. In particular, transfers are achieved
through 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 relationship. By disassociating transfers from the processing of
BYE, these changes facilitate recovery of failed transfers and BYE, these changes facilitate recovery of failed transfers and
clarify state management in the participating entities. clarify state management in the participating entities.
2. Changes from draft-sparks-sip-cc-transfer-02 2. Changes from draft-sparks-sip-cc-transfer-03
o Changed the REFER response to be immediate instead of waiting for
the referred action to complete Editor's note: The changes for this revision focused on the changes
o Added use of NOTIFY to deliver the result of the referred action to the NOTIFY response mechanism discussed at February's interim
o Removed the claim of easy migration from BYE/ALSO 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 3. The REFER Method
REFER is a SIP method as defined by RFC2543[1]. The REFER method REFER is a SIP method as defined by RFC2543[1]. The REFER method
indicates that the recipient should contact a third party using the indicates that the recipient (identified by the Request-URI) should
contact information provided in the method. A success response contact a third party using the contact information provided in the
indicates that the recipient was able to contact the third party. method. A success response indicates that the recipient was able to
The REFER method follows the session's current signaling path. In contact the third party.
particular, the Request-URI of the REFER method identifies the
recipient.
Unless stated otherwise, the protocol for emitting and responding to Unless stated otherwise, the protocol for emitting and responding to
a REFER request are identical to those for a BYE request in [1]. 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 [1] and is not discussed unknown) method is explicitly defined in [1].
further here.
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 3.1 The Refer-To Header
Refer-To is a request-header as defined by [1]. It may only appear Refer-To is a request-header as defined by [1]. It may only appear
in 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
Route/Record-Route mechanism and is not available 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: Refer-To: sip:bob@biloxi.com?Accept-Contact=sip:bobsdesk.
sip:bob@biloxi.com?Accept-Contact=sip:bobsdesk.biloxi.com?Ca biloxi.com&Call-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
Long headers are line-wrapped here for clarity only.
3.2 The Referred-By Header 3.2 The Referred-By Header
Referred-By is a request-header as defined by [1]. It can appear in 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 )
skipping to change at page 4, line 51 skipping to change at page 5, line 32
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 Refer-To: header. Any occurrences of < or > in the referenced-url
MUST 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 UA MAY reject a request containing an unsigned Referred-By header.
A UA SHOULD verify the signature on any Referred-By header it A UA SHOULD verify the signature on any Referred-By header it
receives. receives.
The Referred-By header MAY be encrypted as part of end-end The Referred-By header MAY be encrypted as part of end-end
skipping to change at page 5, line 31 skipping to change at page 6, line 10
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.2.2 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" Referred-By: "Bob" <sip:bob@biloxi.com>;
<sip:bob@biloxi.com>;ref=<sip:alice@atlanta.com>;scheme=pgp;pgp-version="5.0";signature="the signature" 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.3 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 [1], describing header 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. 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 A row for the Refer-To: and Referred-By request-header should be
inferred, each mandatory for REFER. Refer-To is not applicable for inferred, each mandatory for REFER. Refer-To is not applicable for
skipping to change at page 6, line 22 skipping to change at page 6, line 34
and e-e columns in [1] 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 m
Contact 1xx - Contact 1xx -
Contact 2-6xx o Contact 2-6xx o
Content-Encoding e - Content-Encoding e -
Content-Length e o Content-Length e o
Content-Type e - Content-Type e -
CSeq gc m CSeq gc m
Date g o Date g o
Encryption g o Encryption g o
Expires R o Expires R o
From gc m From gc m
skipping to change at page 7, line 23 skipping to change at page 7, line 38
3.5 Responses within the REFER transaction 3.5 Responses within the REFER transaction
An agent responding to a REFER Method MUST return a 400 Bad Request 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 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 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 the request contained zero or more than one Referred-By headers. An
agent (including proxies generating local responses) MAY return a agent (including proxies generating local responses) MAY return a
100 Trying or any appropriate 400-600 class response as prescribed 100 Trying or any appropriate 400-600 class response as prescribed
by [1]. If the recipient's agent decides to contact the resource in by [1]. If the recipient's agent decides to contact the resource in
the Refer-To header, a 200 OK response MUST be returned before the the Refer-To header, a 202 Accepted response MUST be returned before
REFER transaction expires. (Open Issue: Should this be a 202 the REFER transaction expires.
Accepted?) (Section 5.1)
Editor's note - The previous version of this draft required the Editor's note - earlier versions of this draft required the agent
agent responding to REFER to wait until the referred action responding to REFER to wait until the referred action completed
completed before sending a final response to the REFER. That final before sending a final response to the REFER. That final response
response reflected the success or failure of the referred action. reflected the success or failure of the referred action. This was
This was infeasible due to the transaction timeout rules defined for infeasible due to the transaction timeout rules defined for
non-INVITE requests in [1]. A REFER must always receive an immediate non-INVITE requests in [1]. A REFER must always receive an immediate
(within the lifetime of a non-INVITE transaction) final response. (within the lifetime of a non-INVITE transaction) final response.
3.6 Behavior of SIP User Agents 3.6 Behavior of SIP User Agents
3.6.1 Accessing the referred-to resource 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 from the user to proceed (this request could be interactive or
through configuration). Upon receiving approval from the user, the through configuration). Upon receiving approval from the user, the
UA MUST contact the resource identified by the URL in the Refer-To: 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 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 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 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 REFER request should be copied into the request sent to the
referred-to resource. referred-to resource.
3.6.2 Reporting on the results of the reference 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 Once it is known whether the reference succeeded or failed, the UA
receiving the REFER SHOULD notify the agent sending the refer using receiving the REFER SHOULD notify the agent sending the refer using
the NOTIFY mechanism defined in Event Notification in SIP[3] as if the NOTIFY mechanism defined in Event Notification in SIP[3] as if
the the REFER had established a subscription. In particular: the the REFER had established a subscription. In particular:
o The NOTIFY should reflect the To:, From:, and Call-ID headers o Each NOTIFY should reflect the To:, From:, and Call-ID headers
from the REFER as if they had arrived in a SUBSCRIBE. from the REFER as if they had arrived in a SUBSCRIBE.
o If the reference succeeded, the NOTIFY MUST contain Event: o Each NOTIFY MUST contain an event header of Event: refer
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 o Each NOTIFY MUST contain a body of type "application/sip". The
from the profile {refersuccess,referfailure}. If multiple contents of this body are detailed in Section 3.6.2.2
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 o Analogous to the case for SUBSCRIBE described in [3], the agent
that issued the REFER MUST be prepared to receive a NOTIFY before that issued the REFER MUST be prepared to receive a NOTIFY before
the REFER transaction completes. the REFER transaction completes.
Open Issue: This makes REFER dependent on sip-events (Section 5.3) Open Issue: This makes REFER dependent on sip-events (Section 5.1)
Open Issue: The events will need to be registered with IANA (Section Open Issue: The refer event will need to be registered with IANA
5.4) (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 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.8 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 [1], 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.9 Prototypical REFER callflow 3.9 Prototypical REFER callflow
Agent A Agent B Agent A Agent B
| | | |
| REFER | | REFER |
|----------------------->| |----------------------->|
| 200 OK | | 202 Accepted |
|<-----------------------| |<-----------------------|
| | | |
| |-------> | |------->
| | (whatever) | | (whatever)
| |<------ | |<------
| | | |
| NOTIFY | | NOTIFY |
|<-----------------------| |<-----------------------|
| 200 OK | | 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 3.10 Security Considerations
The security requirements of [1] apply to the REFER method. 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 referred-to resource to the party being referred. Care should be
taken to provide a suitably restricted URI if the referred to taken to provide a suitably restricted URI if the referred to
resource 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.
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
3.10.3 Limiting the breach
For each of these cases, and in general, returning a carefully
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 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 There are three actors in a given transfer event, each playing one
of 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.
skipping to change at page 12, line 23 skipping to change at page 15, line 23
| ACK | | | ACK | |
|<-------------------| | |<-------------------| |
| INVITE (hold) | | | INVITE (hold) | |
|------------------->| | |------------------->| |
| 200 OK | | | 200 OK | |
|<-------------------| | |<-------------------| |
| ACK | | | ACK | |
|------------------->| | |------------------->| |
| REFER | | | REFER | |
|------------------->| | |------------------->| |
| 200 OK | | | 202 Accepted | |
|<-------------------| | |<-------------------| |
| | INVITE | | | INVITE |
| |------------------->| | |------------------->|
| | 200 OK | | | 200 OK |
| |<-------------------| | |<-------------------|
| | ACK | | | ACK |
| |------------------->| | |------------------->|
| NOTIFY (refersuccess) | | NOTIFY (200 OK) | |
|<-------------------| | |<-------------------| |
| 200 OK | | | 200 OK | |
|------------------->| | |------------------->| |
| BYE | | | BYE | |
|------------------->| | |------------------->| |
| 200 OK | | | 200 OK | |
|<-------------------| | |<-------------------| |
| | BYE | | | BYE |
| |<-------------------| | |<-------------------|
| | 200 OK | | | 200 OK |
skipping to change at page 13, line 24 skipping to change at page 16, line 24
| ACK | | | ACK | |
|<-------------------| | |<-------------------| |
| INVITE (hold) | | | INVITE (hold) | |
|------------------->| | |------------------->| |
| 200 OK | | | 200 OK | |
|<-------------------| | |<-------------------| |
| ACK | | | ACK | |
|------------------->| | |------------------->| |
| REFER | | | REFER | |
|------------------->| | |------------------->| |
| 200 OK | | | 202 Accepted | |
|<-------------------| | |<-------------------| |
| | INVITE | | | INVITE |
| |------------------->| | |------------------->|
| | 486 Busy Here | | | 486 Busy Here |
| |<-------------------| | |<-------------------|
| | ACK | | | ACK |
| |------------------->| | |------------------->|
| NOTIFY (referfailure) | | NOTIFY (503 Service Unavailable) |
| or NOTIFY (486 Busy Here) |
|<-------------------| | |<-------------------| |
| 200 OK | | | 200 OK | |
|------------------->| | |------------------->| |
| INVITE (unhold) | | | INVITE (unhold) | |
|------------------->| | |------------------->| |
| 200 OK | | | 200 OK | |
|<-------------------| | |<-------------------| |
| ACK | | | ACK | |
|------------------->| | |------------------->| |
| BYE | | | BYE | |
skipping to change at page 14, line 31 skipping to change at page 17, line 31
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 | |
|------------------->| | |------------------->| |
| 200 OK | | | 202 Accepted | |
|<-------------------| | |<-------------------| |
Call-ID:1 | | INVITE/200 OK/ACK | Call-ID:1 | | INVITE/200 OK/ACK |
| |------------------->| | |------------------->|
Call-ID:1 | NOTIFY (refersuccess) | 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 4.5.2 Variation 2 : Protects transfer target
skipping to change at page 15, line 28 skipping to change at page 18, line 28
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 | |
|---------------------------------------->| |---------------------------------------->|
| 200 Trying | | | 202 Accepted | |
|<----------------------------------------| |<----------------------------------------|
Call-ID:2 | | INVITE/200 OK/ACK | Call-ID:2 | | INVITE/200 OK/ACK |
| |<-------------------| | |<-------------------|
Call-ID:2 | NOTIFY (refersuccess) | Call-ID:2 | NOTIFY (200 OK) | |
|<----------------------------------------| |<----------------------------------------|
| 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 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
skipping to change at page 16, line 45 skipping to change at page 19, 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 | |
| |<-----------| | | |<-----------| |
| |200 OK | | | |202 Accepted| |
| |----------->| | | |----------->| |
2 | |INVITE/200 OK/ACK | 2 | |INVITE/200 OK/ACK |
| |---------------------->|"This is Fred" | |---------------------->|"This is Fred"
2 | |NOTIFY (refersuccess) | "Please hold for 2 | |NOTIFY (200 OK) | "Please hold for
| |----------->| | Mary" | |----------->| | Mary"
| |200 OK | | | |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 | | |
|<-----------| | | |<-----------| | |
|200 OK | | | |202 Accepted| | |
|----------->| | | |----------->| | |
1 |INVITE/200 OK/ACK | | 1 |INVITE/200 OK/ACK | |
|----------------------------------->| "Hey Fred" |----------------------------------->| "Hey Fred"
1 |NOTIFY (refersuccess) | | "Hello Mary" 1 |NOTIFY (200 OK) | | "Hello Mary"
|----------->| | | |----------->| | |
|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 5. Open Issues
5.1 200 vs 202 5.1 REFER is now dependent on sip-events
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 By introducing NOTIFY, this work is prevented from moving to RFC
until the sip-events draft moves to that level (that work is until the sip-events draft moves to that level (that work is
currently an individual submission). What needs to happen to our currently an individual submission). What needs to happen to our
deliverable schedule to allow for completing the sip-events work? deliverable schedule to allow for completing the sip-events work?
5.4 Registering the events with IANA 5.2 Registering the events with IANA
When we near the end of the process, the events we agree to use for When we near the end of the process, the refer event will need to be
this purpose (currently proposed as refersuccess and referfailure) registered with IANA per [3].
will need to be registered with IANA per [3].
6. Acknowledgments 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.
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] Roach, A., "Event Notification in SIP",
draft-roach-sip-subscibe-notify-02 (work in progress), November draft-roach-sip-subscibe-notify-03 (work in progress), February
2000. 2001.
[4] Schulzrinne, H. and J. Rosenberg, "SIP Call Control Services", [4] Schulzrinne, H. and J. Rosenberg, "SIP Call Control Services",
draft-ietf-sip-cc-01 (work in progress - expired), June 1999. draft-ietf-sip-cc-01 (work in progress - expired), June 1999.
Author's Address Author's Address
Robert J. Sparks Robert J. Sparks
dynamicsoft dynamicsoft
5100 Tennyson Parkway 5100 Tennyson Parkway
Suite 1200 Suite 1200
 End of changes. 

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