draft-ietf-sip-cc-transfer-00.txt   draft-ietf-sip-cc-transfer-01.txt 
Internet Engineering Task Force Robert Sparks Internet Engineering Task Force Robert Sparks
Internet Draft dynamicsoft Internet Draft dynamicsoft
draft-ietf-sip-cc-transfer-00.txt draft-ietf-sip-cc-transfer-01.txt
July 2000 September 2000
Expires February 2001 Expires April 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 ? skipping to change at page 1, line 33
or to cite them other than as work in progress. 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
Abstract Abstract
This document defines a SIP extension within the new Call Control This document defines a SIP extension within the Call Control
Framework to provide Call Transfer capabilities. Framework to provide Call Transfer capabilities.
Robert Sparks [Page 1]
1 Overview...........................................................3 1 Overview...........................................................3
2 Changes from draft-sparks-sip-cc-transfer-00.......................3 2 Changes from draft-sparks-sip-cc-transfer-01.......................4
3 Actors and Roles...................................................4 3 The REFER Method...................................................5
4 Requirements.......................................................5 3.1 The Refer-To Header............................................5
5 The REFER Method...................................................6 3.2 The Referred-By Header.........................................6
5.1 The Refer-To Header............................................6 3.2.1 A PGP based signature-scheme.................................6
5.2 The Referred-By Header.........................................7 3.3 Header Field Support for the REFER Method......................7
5.2.1 A PGP based signature-scheme.................................7 3.4 Message Body Inclusion.........................................8
5.3 Header Field Support for the REFER Method......................8 3.5 Responses to the REFER Method..................................8
5.4 Message Body Inclusion.........................................9 3.6 Behavior of SIP User Agents....................................8
5.5 Responses to the REFER Method..................................9 3.7 Behavior of SIP Registrars/Redirect Servers....................9
5.6 Behavior of SIP User Agents...................................10 3.8 Behavior of SIP Proxies........................................9
5.7 Behavior of SIP Registrars/Redirect Servers...................10 3.9 Security Considerations........................................9
5.8 Behavior of SIP Proxies.......................................10 4 Call Transfer.....................................................10
5.9 Security Considerations.......................................11 4.1 Actors and Roles..............................................10
6 Using REFER to achieve Call Transfer..............................11 4.2 Requirements..................................................11
6.1 Unattended Transfer...........................................11 4.3 Using REFER to achieve Call Transfer..........................12
6.1.1 Successful Unattended Transfer..............................12 4.4 Unattended Transfer...........................................12
6.1.2 Failed Unattended Transfer..................................13 4.4.1 Successful Unattended Transfer..............................13
6.2 Unattended Transfer with Consultation Hold....................14 4.4.2 Failed Unattended Transfer..................................14
6.2.1 Variation 1 : Exposes transfer target.......................14 4.5 Unattended Transfer with Consultation Hold....................14
6.3 Attended Transfer.............................................15 4.5.1 Variation 1 : Exposes transfer target.......................15
6.4 Transfer with multiple parties................................16 4.5.2 Variation 2 : Protects transfer target......................15
7 Author's Addresses................................................17 4.6 Attended Transfer.............................................16
8 Acknowledgments...................................................17 4.7 Transfer with multiple parties................................16
9 References........................................................17 5 Editor's Address..................................................18
6 Acknowledgments...................................................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].
The mechanisms discussed here are most closely related to traditional The mechanisms discussed here are most closely related to traditional
unattended and consultation hold transfers. Discussion of attended unattended and consultation hold transfers. Discussion of attended
skipping to change at page 3, line 28 skipping to change at page 4, line 5
semantics are different. In particular, transfers are achieved through semantics are different. In particular, transfers are achieved through
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-00 2 Changes from draft-sparks-sip-cc-transfer-01
. Separated definition of the REFER method and headers from the
. The method was renamed to reflect its function instead of this definition of its use to achieve transfer.
particular application of its function. TRANSFER and Transfer-To . Replaced the syntax of the Referred-By header to align with sip-
became REFER and Refer-To. REFER was generalized to support URLs ietf-sip-guidelines.
beyond those indicating SIP INVITEs. . Added short forms of Refer-To and Referred-By as recommended by
. A Require header is no longer required. Bodies are allowed. sip-ietf-sip-guidelines.
. Copying Call-ID from the request was replaced by using a Refer-To: . Allows REFERs outside the scope of an existing call-leg.
URL containing any headers that should be use.
. Added a way for the identity specified in Refer-To: to know it has
been referred to.
. Added a mechanism to prove the identity of the issuer of the REFER
to the identity specified in Refer-To.
. The failure response returned to an attempted REFER has been
changed from 603 to 503 to facilitate different behavior in the
cases of "I won't accept that REFER" and "I tried that REFER and it
failed" with Retry-After: support for the later.
3 Actors and Roles
There are three actors in a given transfer event, each playing one of
the following roles:
Transferee - the party being transferred to the Transfer
Target.
Transferor - the party initiating the transfer
Transfer Target - the new party being introduced into a call with
the Transferee.
The following roles are used to describe transfer requirements and
scenarios:
Originator - wishes to place a call to the Recipient. This actor
is the source of the first INVITE in a session, to
either a Facilitator or a Screener.
Facilitator - receives a call or out-of-band request from the
Originator, establishes a call to the Recipient
through the Screener, and connects the Originator to
the Recipient.
Screener - receives a call ultimately intended for the Recipient
and transfers the calling party to the Recipient if
appropriate.
Recipient - the party the Originator is ultimately connected to.
4 Requirements
1. Any party in a SIP session MUST be able to transfer any other
party in that session at any point in that session.
2. The Transferor and the Transferee MUST NOT be removed from a
session as part of a transfer transaction.
At first glance, requirement 2 may seem to indicate
that the user experience in a transfer must be
significantly different from what a current PBX or
Centrex user expects. As the call-flows in this
document show, this is not the case. A client MAY
preserve the current experience. In fact, without
this requirement, some forms of the current
experience (ringback on unattended transfer failure
for instance) will be lost.
3. The Transferor MUST know whether or not the transfer was
successful (this is significantly different from the requirements
of draft-ietf-sip-cc-01).
5 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.
Unless stated otherwise, the protocol for emitting and responding to a Unless stated otherwise, the protocol for emitting and responding to a
REFER request are identical to those for a BYE request in [2]. The REFER request are identical to those for a BYE request in [2]. The
behavior of SIP entities not implementing the REFER (or any other behavior of SIP entities not implementing the REFER (or any other
unknown) method is explicitly defined in [2] and is not discussed unknown) method is explicitly defined in [2] and is not discussed
further here. further here.
5.1 The Refer-To Header 3.1 The Refer-To Header
Refer-To is a request-header as defined by [2]. It may only appear in Refer-To is a request-header as defined by [2]. It may only appear in
a REFER request. It identifies the transfer target. a REFER request.
Refer-To = "Refer-To" ":" 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 Refer-To header has no short form.
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.
5.2 The Referred-By Header 3.2 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" ":" referrer-url referenced-url Referred-By = ("Referred-By" | "b") ":" referrer-url
[ref-signature] ";" referenced-url
[";" ref-signature]
referrer-url = SIP-URL referrer-url = SIP-URL
referenced-url = URL referenced-url = "ref" "=" URL
ref-signature = signature-scheme #sig-scheme-params ref-signature = signature-scheme *( ";" sig-scheme-params )
signature-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. 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 5.2.1. signature scheme is given in section 3.2.1.
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.
The Referred-By header has no short form. 3.2.1 A PGP based signature-scheme
5.2.1 A PGP based signature-scheme
One signature-scheme for Referred-By headers uses PGP as follows: One signature-scheme for Referred-By headers uses PGP as follows:
signature-scheme = "scheme" "=" "pgp"
sig-scheme-parms = pgp-version | signed-by | pgp-signature
Referred-By = "Referred-By" ":" referrer-url pgp-version, signed-by and pgp-signature are defined in section 15.1
referenced-url "pgp" pgp-sig-scheme-parms
pgp-sig-scheme-parms = pgp-version | signed-by | pgp-signature
pgp-version, signed-by and pgp-signature are defined in section 15.1.2
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.
5.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 [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 -
Accept-Encoding R - Accept-Encoding R -
Accept-Language R o Accept-Language R o
Allow R - Allow R -
Allow 405 m Allow 405 m
Authorization R o Authorization R o
Call-ID gc m Call-ID gc m
Contact R o Contact R o
Contact 1xx - Contact 1xx -
Contact 2-6xx o Contact 2-6xx o
Content-Encoding e - Content-Encoding e -
Content-Length e o <-SHOULD be present and Content-Length e o
Content-Type e - have a value of zero 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
Hide R o Hide R o
Max-Forwards R o Max-Forwards R o
Organization g o Organization g o
Priority R - Priority R -
Proxy-Authenticate 407 o Proxy-Authenticate 407 o
skipping to change at page 9, line 12 skipping to change at page 8, line 14
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
5.4 Message Body Inclusion 3.4 Message Body Inclusion
A REFER method may contain a body which SHOULD be processed according A REFER method may contain a body which SHOULD be processed according
to its Content-Type. to its Content-Type.
5.5 Responses to the REFER Method 3.5 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.
The original proposal called for a 603 response if 3.6 Behavior of SIP User Agents
the REFER was attempted but failed. This left no way
for the referrer to tell whether the recipient tried
and failed, or just refused to try. A 603 Decline
now means the recipient refuses to try. A 503 can
mean either "I tried and failed" or "I'm broken and
couldn't try". In either case, if a Retry-After
header is present, the request can be attempted
again.
5.6 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".
A REFER request is meaningful only in the context of an existing 3.7 Behavior of SIP Registrars/Redirect Servers
session. A UA receiving a REFER request for an unknown call leg MUST
return a 481 Call Leg/Transaction Does Not Exist and MUST NOT contact
the resource identified by that request's Refer-To header as part of
the REFER transaction.
5.7 Behavior of SIP Registrars/Redirect Servers
Since REFER has meaning only in the context of an existing session, a Registrars and Redirect Servers SHOULD return a 603 to a REFER
Registrar or Redirect Server that is not also playing the role of a request, unless they are also playing some other SIP role.
User Agent (never issues a 200 OK in response to an INVITE) MUST
respond to a REFER request with a 481 Call Leg/Transaction Does Not
Exist.
5.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 [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.
5.9 Security Considerations 3.9 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 (the transfer-target referred-to resource to the party being referred. Care should be taken
and transferee in a transfer). Care should be taken to provide a to provide a suitably restricted URI if the referred to resource
suitably restricted URI if the referred to resource should be should be protected.
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.
Unless the UA has good reason (perhaps as part of an as yet undefined
application), it SHOULD NOT accept REFERences to SIP URLs for methods
other than INVITE.
6 Using REFER to achieve Call Transfer 4 Call Transfer
4.1 Actors and Roles
There are three actors in a given transfer event, each playing one of
the following roles:
Transferee - the party being transferred to the Transfer
Target.
Transferor - the party initiating the transfer
Transfer Target - the new party being introduced into a call with
the Transferee.
The following roles are used to describe transfer requirements and
scenarios:
Originator - wishes to place a call to the Recipient. This actor
is the source of the first INVITE in a session, to
either a Facilitator or a Screener.
Facilitator - receives a call or out-of-band request from the
Originator, establishes a call to the Recipient
through the Screener, and connects the Originator to
the Recipient.
Screener - receives a call ultimately intended for the Recipient
and transfers the calling party to the Recipient if
appropriate.
Recipient - the party the Originator is ultimately connected to.
4.2 Requirements
1. Any party in a SIP session MUST be able to transfer any other
party in that session at any point in that session.
2. The Transferor and the Transferee MUST NOT be removed from a
session as part of a transfer transaction.
At first glance, requirement 2 may seem to indicate
that the user experience in a transfer must be
significantly different from what a current PBX or
Centrex user expects. As the call-flows in this
document show, this is not the case. A client MAY
preserve the current experience. In fact, without
this requirement, some forms of the current
experience (ringback on unattended transfer failure
for instance) will be lost.
3. The Transferor MUST know whether or not the transfer was
successful (this is significantly different from the requirements
of draft-ietf-sip-cc-01).
4.3 Using REFER to achieve Call Transfer
A REFER can be issued by the Transferor to cause the Transferee to A REFER can be issued by the Transferor to cause the Transferee to
issue an INVITE to the Transfer-Target. Note that a successful REFER issue an INVITE to the Transfer-Target. Note that a successful REFER
transaction does not terminate the session between the Transferor and transaction does not terminate the session between the Transferor and
the Transferee. If those parties wish to terminate their session, they the Transferee. If those parties wish to terminate their session, they
must do so with a subsequent BYE request. The media negotiated between must do so with a subsequent BYE request. The media negotiated between
the transferee and the transfer target is not affected by the media the transferee and the transfer target is not affected by the media
that had been negotiated between the transferor and the transferee. In that had been negotiated between the transferor and the transferee. In
particular, the INVITE issued by the Transferee will have the same SDP particular, the INVITE issued by the Transferee will have the same SDP
body it would have if he Transferee had initiated that INVITE on its body it would have if he Transferee had initiated that INVITE on its
own. Further, the disposition of the media streams between the own. Further, the disposition of the media streams between the
Transferor and the Transferee is not altered by the REFER method. Transferor and the Transferee is not altered by the REFER method.
Agents may alter a session's media through additional signaling. For Agents may alter a session's media through additional signaling. For
example, they may make use of the SIP hold re-INVITE [2] or the example, they may make use of the SIP hold re-INVITE [2] or the
conferencing extensions provided by this framework. conferencing extensions provided by this framework.
6.1 Unattended Transfer 4.4 Unattended Transfer
Unattended Transfer consists of the Transferor providing the Transfer Unattended Transfer consists of the Transferor providing the Transfer
Target's contact to the Transferee. The Transferee attempts to Target's contact to the Transferee. The Transferee attempts to
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 using 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.
6.1.1 Successful Unattended Transfer 4.4.1 Successful Unattended Transfer
Transferor Transferee Transfer Transferor Transferee Transfer
| | Target | | Target
| INVITE | | | INVITE | |
|<-------------------| | |<-------------------| |
| 200 OK | | | 200 OK | |
|------------------->| | |------------------->| |
| ACK | | | ACK | |
|<-------------------| | |<-------------------| |
| INVITE (hold) | | | INVITE (hold) | |
skipping to change at page 13, line 5 skipping to change at page 14, line 5
|<-------------------| | |<-------------------| |
| BYE | | | BYE | |
|------------------->| | |------------------->| |
| 200 OK | | | 200 OK | |
|<-------------------| | |<-------------------| |
| | BYE | | | BYE |
| |<-------------------| | |<-------------------|
| | 200 OK | | | 200 OK |
| |------------------->| | |------------------->|
6.1.2 Failed Unattended Transfer 4.4.2 Failed Unattended Transfer
Transferor Transferee Transfer Transferor Transferee Transfer
| | Target | | Target
| | | | | |
| INVITE | | | INVITE | |
|<-------------------| | |<-------------------| |
| 200 OK | | | 200 OK | |
|------------------->| | |------------------->| |
| ACK | | | ACK | |
|<-------------------| | |<-------------------| |
skipping to change at page 14, line 5 skipping to change at page 14, line 45
|------------------->| | |------------------->| |
| 200 OK | | | 200 OK | |
|<-------------------| | |<-------------------| |
| ACK | | | ACK | |
|------------------->| | |------------------->| |
| BYE | | | BYE | |
|------------------->| | |------------------->| |
| 200 OK | | | 200 OK | |
|<-------------------| | |<-------------------| |
6.2 Unattended Transfer with Consultation Hold 4.5 Unattended Transfer with Consultation Hold
Transfer with Consultation Hold involves a session between the Transfer with Consultation Hold involves a session between the
transferor and the transfer target before the transfer actually takes transferor and the transfer target before the transfer actually takes
place. This is implemented with SIP Hold and Unattended Transfer as place. This is implemented with SIP Hold and Unattended Transfer as
described above. described above.
6.2.1 Variation 1 : Exposes transfer target 4.5.1 Variation 1 : Exposes transfer target
The transferor places the transferee on hold, establishes a call with The transferor places the transferee on hold, establishes a call 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 with terminates the connection with the transfer target, then proceeds with
unattended transfer as above. This variation can be used to provide an unattended transfer as above. This variation can be used to provide an
experience similar to that expected by current PBX and Centrex users. experience similar to that expected by current PBX and Centrex users.
To (hopefully) improve clarity, non-REFER transactions have been To (hopefully) improve clarity, non-REFER transactions have been
collapsed into one indicator with the arrow showing the direction of collapsed into one indicator with the arrow showing the direction of
the request. the request.
skipping to change at page 15, line 4 skipping to change at page 15, line 40
| 100 Trying | | | 100 Trying | |
|<-------------------| | |<-------------------| |
Call-ID:1 | | INVITE/200 OK/ACK | Call-ID:1 | | INVITE/200 OK/ACK |
| |------------------->| | |------------------->|
| 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 |
| |<-------------------| | |<-------------------|
5.2.2 Variation 2 : Protects transfer target
4.5.2 Variation 2 : Protects transfer target
The transferor places the transferee on hold, establishes a call with The transferor places the transferee on hold, establishes a call with
the transfer target and then reverses their roles, transferring the the transfer target and then reverses their roles, transferring the
original transfer target to the original transferee. This has the original transfer target to the original transferee. This has the
advantage of hiding information about the original transfer target advantage of hiding information about the original transfer target
from the original transferee. On the other hand, the Transferee's from the original transferee. On the other hand, the Transferee's
experience is different that in current systems. The Transferee is experience is different that in current systems. The Transferee is
effectively "called back" by the Transfer Target. effectively "called back" by the Transfer Target.
Transferor Transferee Transfer Transferor Transferee Transfer
skipping to change at page 15, line 40 skipping to change at page 16, line 31
| |<-------------------| | |<-------------------|
| 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 |
| |------------------->| | |------------------->|
6.3 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.
6.4 Transfer with multiple parties 4.7 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 17, line 11 skipping to change at page 18, line 5
|----------------------------------->| "Hey Fred" |----------------------------------->| "Hey Fred"
|200 OK | | | "Hello Mary" |200 OK | | | "Hello Mary"
|----------->| | | |----------->| | |
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"
7 Author's Addresses 5 Editor's Address
Robert Sparks Robert Sparks
dynamicsoft dynamicsoft
200 Executive Drive 200 Executive Drive
Suite 120 Suite 120
West Orange, NJ 07052 West Orange, NJ 07052
email: rsparks@dynamicsoft.com email: rsparks@dynamicsoft.com
8 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
author 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.
9 References 7 References
[1] S. Bradner, "The Internet Standards Process -- Revision 3", [1] S. Bradner, "The Internet Standards Process -- Revision 3",
BCP9, RFC2026, October 1996. BCP9, RFC2026, October 1996.
[2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg,
"SIP:Session Initiation Protocol", RFC 2543, March 1999. "SIP:Session Initiation Protocol", RFC 2543, March 1999.
[3] B. Campbell, "Framework for SIP Call Control Extensions", [3] B. Campbell, "Framework for SIP Call Control Extensions",
Internet Draft draft-ietf-sip-cc-framework-00, Internet Internet Draft draft-ietf-sip-cc-framework-00, Internet
Engineering Task Force, March 2000. Work in Progress. Engineering Task Force, March 2000. Work in Progress.
 End of changes. 

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