SIPPING WG R. Sparks
Internet-Draft dynamicsoft
Expires: August 15, 2004 A. Johnston
MCI
February 15, 2004
Session Initiation Protocol Call Control - Transfer
draft-ietf-sipping-cc-transfer-02
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 15, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes providing Call Transfer capabilities in the
Session Initiation Protocol (SIP). This work is part of the SIP
Multiparty Call Control Framework.
Sparks & Johnston Expires August 15, 2004 [Page 1]
Internet-Draft SIP CC Transfer February 2004
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Actors and Roles . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Using REFER to achieve Call Transfer . . . . . . . . . . . . 4
5. Basic Transfer . . . . . . . . . . . . . . . . . . . . . . . 5
5.1 Successful Transfer . . . . . . . . . . . . . . . . . . . . 6
5.2 Failed Transfer . . . . . . . . . . . . . . . . . . . . . . 9
5.2.1 Target Busy . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2.2 Transfer Target does not answer . . . . . . . . . . . . . . 10
6. Transfer with Consultation Hold . . . . . . . . . . . . . . 11
6.1 Exposing transfer target . . . . . . . . . . . . . . . . . . 11
6.2 Protecting transfer target . . . . . . . . . . . . . . . . . 13
6.3 Attended Transfer . . . . . . . . . . . . . . . . . . . . . 16
6.4 Recovery when one party does not support REFER . . . . . . . 19
6.5 Attended Transfer when Contact URI is Not Globally
Routable . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.6 Aborting a Consultation Hold . . . . . . . . . . . . . . . . 24
6.7 Attended Transfer Fallback to Basic Transfer . . . . . . . . 24
7. Transfer with Referred-By . . . . . . . . . . . . . . . . . 26
8. Transfer with multiple parties . . . . . . . . . . . . . . . 31
9. Changes from draft-sipping-cc-transfer-01 . . . . . . . . . 33
10. Changes from draft-sipping-cc-transfer-00 . . . . . . . . . 33
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 33
12. Security Considerations . . . . . . . . . . . . . . . . . . 33
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 33
Normative References . . . . . . . . . . . . . . . . . . . . 34
Informative References . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . 36
Sparks & Johnston Expires August 15, 2004 [Page 2]
Internet-Draft SIP CC Transfer February 2004
1. Overview
This document describes providing Call Transfer capabilities and
requirements in SIP [1]. This work is part of the Multiparty Call
Control Framework [6].
The mechanisms discussed here are most closely related to traditional
basic and consultation hold transfers. This document does not discuss
transfer scenarios involving ad-hoc conferences (where all parties
involved are briefly in a conference until this transferor drops
out).
This document details the use of REFER method [2] and Replaces [3]
header field to achieve call transfer.
A user agent that fully supports the transfer mechanisms described in
this document MUST support REFER[2] and Replaces[3] in addition to
RFC 3261 [1].
2. 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.
Sparks & Johnston Expires August 15, 2004 [Page 3]
Internet-Draft SIP CC Transfer February 2004
Recipient - the party the Originator is ultimately connected to.
3. 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 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 the earlier BYE-Also approach to transfer).
4. The Transferee MUST be able to replace an existing dialog with a
new dialog.
5. The Transferor and Transferee SHOULD indicate their support for
the primitives required to achieve transfer.
4. Using REFER to achieve Call Transfer
A REFER [2] can be issued by the Transferor to cause the Transferee
to issue an INVITE to the Transfer-Target. Note that a successful
REFER transaction does not terminate the session between the
Transferor and the Transferee. If those parties wish to terminate
their session, they must do so with a subsequent BYE request. The
media negotiated between the transferee and the transfer target is
not affected by the media that had been negotiated between the
transferor and the transferee. In 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 own. Further, the
disposition of the media streams between the Transferor and the
Transferee is not altered by the REFER method. Agents may alter a
session's media through additional signaling. For example, they may
make use of the SIP hold re-INVITE [1] or the conferencing extensions
provided by this framework.
Sparks & Johnston Expires August 15, 2004 [Page 4]
Internet-Draft SIP CC Transfer February 2004
5. Basic Transfer
Basic Transfer consists of the Transferor providing the Transfer
Target's contact to the Transferee. The Transferee attempts to
establish a session using that contact and reports the results of
that attempt to the Transferor. The signaling relationship between
the Transferor and Transferee is not terminated, so the call is
recoverable if the Transfer Target cannot be reached. Note that the
Transfer Target's contact information has been exposed to the
Transferee. The provided contact can be used to make new calls in the
future.
The participants in a basic transfer should indicate support for the
REFER and NOTIFY methods in Allow header fields in INVITE, 200 OK to
INVITE, and OPTIONS.
The diagrams below show indicate the first line of each message. The
first column of the figure shows the Call-ID used in that particular
message. In these diagrams, media is managed through re-INVITE holds,
but other mechanisms (mixing multiple media streams at the UA or
using the conferencing extensions for example) are valid. Selected
message details are shown labeled as message F1, F2, etc.
Each of the flows below shows the dialog between the Transferor and
the Transferee remaining connected (on hold) during the REFER
process. While this provides the greatest flexibility for recovery
from failure, it is not necessary. If the Transferor's agent does not
wish to participate in the remainder of the REFER process and has no
intention of assisting with recovery from transfer failure, it could
emit a BYE to the Transferee as soon as the REFER transaction
completes. This flow is sometimes known as "unattended transfer".
Sparks & Johnston Expires August 15, 2004 [Page 5]
Internet-Draft SIP CC Transfer February 2004
5.1 Successful Transfer
Transferor Transferee Transfer
| | Target
| INVITE | |
Call-ID:1 |<-------------------| |
| 200 OK | |
Call-ID:1 |------------------->| |
| ACK | |
Call-ID:1 |<-------------------| |
| INVITE (hold) | |
Call-ID:1 |------------------->| |
| 200 OK | |
Call-ID:1 |<-------------------| |
| ACK | |
Call-ID:1 |------------------->| |
| REFER F1 | |
Call-ID:1 |------------------->| |
| 202 Accepted | |
Call-ID:1 |<-------------------| |
| NOTIFY (100 Trying) F2 |
Call-ID:1 |<-------------------| |
| 200 OK | |
Call-ID:1 |------------------->| |
| | INVITE F3 |
Call-ID:2 | |------------------->|
| | 200 OK |
Call-ID:2 | |<-------------------|
| | ACK |
Call-ID:2 | |------------------->|
| NOTIFY (200 OK) F4| |
Call-ID:1 |<-------------------| |
| 200 OK | |
Call-ID:1 |------------------->| |
| BYE | |
Call-ID:1 |------------------->| |
| 200 OK | |
Call-ID:1 |<-------------------| |
| | BYE |
Call-ID:2 | |<-------------------|
| | 200 OK |
Call-ID:2 | |------------------->|
Figure 1. Basic Transfer Call Flow.
F1 REFER Transferor -> Transferee
Sparks & Johnston Expires August 15, 2004 [Page 6]
Internet-Draft SIP CC Transfer February 2004
REFER sip:transferee@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKna9
Max-Forwards: 70
To: <sip:transferee@biloxi.example.com>;tag=a6c85cf
From: <sip:transferor@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 REFER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Refer-To: <sip:transfertarget@chicago.example.com>
Contact: <sip:transferor@pc33.atlanta.example.com>
Content-Length: 0
F2 NOTIFY Transferee -> Transferor
NOTIFY sip:transferor@pc33.atlanta.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sip:transferor@atlanta.example.com>;tag=1928301774
From: <sip:transferee@biloxi.example.com>;tag=a6c85cf
Call-ID: a84b4c76e66710
CSeq: 73 NOTIFY
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Event: refer
Subscription-State: active;expires=60
Content-Type: message/sipfrag
Content-Length: ...
SIP/2.0 100 Trying
F3 INVITE Transferee -> Transfer Target
INVITE sip:transfertarget@chicago.example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas41234
Max-Forwards: 70
To: <sip:transfertarget@chicago.example.com>
From: <sip:transferee@biloxi.example.com>;tag=j3kso3iqhq
Call-ID: 90422f3sd23m4g56832034
CSeq: 521 REFER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sip:transferee@192.0.2.4>
Content-Type: application/sdp
Content-Length: ...
Sparks & Johnston Expires August 15, 2004 [Page 7]
Internet-Draft SIP CC Transfer February 2004
F4 NOTIFY Transferee -> Transferor
NOTIFY sip:transferor@pc33.atlanta.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sip:transferor@atlanta.example.com>;tag=1928301774
From: <sip:transferee@biloxi.example.com>;tag=a6c85cf
Call-ID: a84b4c76e66710
CSeq: 74 NOTIFY
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Event: refer
Subscription-State: terminated;reason=noresource
Content-Type: message/sipfrag
Content-Length: ...
SIP/2.0 200 OK
Sparks & Johnston Expires August 15, 2004 [Page 8]
Internet-Draft SIP CC Transfer February 2004
5.2 Failed Transfer
This section shows examples of failed transfer attempts. After the
transfer failure occurs, the Transferor takes the Transferee off hold
and resumes the session.
5.2.1 Target Busy
Transferor Transferee Transfer
| | Target
| | |
| INVITE | |
Call-ID:1 |<-------------------| |
| 200 OK | |
Call-ID:1 |------------------->| |
| ACK | |
Call-ID:1 |<-------------------| |
| INVITE (hold) | |
Call-ID:1 |------------------->| |
| 200 OK | |
Call-ID:1 |<-------------------| |
| ACK | |
Call-ID:1 |------------------->| |
| REFER | |
Call-ID:1 |------------------->| |
| 202 Accepted | |
Call-ID:1 |<-------------------| |
| NOTIFY (100 Trying)| |
Call-ID:1 |<-------------------| |
| 200 OK | |
Call-ID:1 |------------------->| |
| | INVITE |
Call-ID:2 | |------------------->|
| | 486 Busy Here |
Call-ID:2 | |<-------------------|
| | ACK |
Call-ID:2 | |------------------->|
| NOTIFY (503 Service Unavailable) |
| or NOTIFY (486 Busy Here) |
Call-ID:1 |<-------------------| |
| 200 OK | |
Call-ID:1 |------------------->| |
| INVITE (unhold) | |
Call-ID:1 |------------------->| |
| 200 OK | |
Call-ID:1 |<-------------------| |
| ACK | |
Sparks & Johnston Expires August 15, 2004 [Page 9]
Internet-Draft SIP CC Transfer February 2004
Call-ID:1 |------------------->| |
| BYE | |
Call-ID:1 |------------------->| |
| 200 OK | |
Call-ID:1 |<-------------------| |
Figure 2. Failed Transfer - Target Busy
5.2.2 Transfer Target does not answer
Transferor Transferee Transfer
| | Target
| INVITE | |
Call-ID:1 |<-------------------| |
| 200 OK | |
Call-ID:1 |------------------->| |
| ACK | |
Call-ID:1 |<-------------------| |
| INVITE (hold) | |
Call-ID:1 |------------------->| |
| 200 OK | |
Call-ID:1 |<-------------------| |
| ACK | |
Call-ID:1 |------------------->| |
| REFER | |
Call-ID:1 |------------------->| |
| 202 Accepted | |
Call-ID:1 |<-------------------| |
| NOTIFY (100 Trying)| |
Call-ID:1 |<-------------------| |
| 200 OK | |
Call-ID:1 |------------------->| |
| | INVITE |
Call-ID:2 | |------------------->|
| | 180 Ringing |
Call-ID:2 | |<-------------------|
| | (Transferee gets tired of waiting)
| | CANCEL |
Call-ID:2 | |------------------->|
| | 200 OK (CANCEL) |
Call-ID:2 | |<-------------------|
| | 487 Request Cancelled (INVITE)
Call-ID:2 | |<-------------------|
| | ACK |
Call-ID:2 | |------------------->|
| NOTIFY (487 Request Cancelled) |
Call-ID:1 |<-------------------| |
Sparks & Johnston Expires August 15, 2004 [Page 10]
Internet-Draft SIP CC Transfer February 2004
| 200 OK | |
Call-ID:1 |------------------->| |
| INVITE (unhold) | |
Call-ID:1 |------------------->| |
| 200 OK | |
Call-ID:1 |<-------------------| |
| ACK | |
Call-ID:1 |------------------->| |
| BYE | |
Call-ID:1 |------------------->| |
| 200 OK | |
Call-ID:1 |<-------------------| |
Figure 3. Failed Transfer - Target Does Not Answer.
6. Transfer with Consultation Hold
Transfer with Consultation Hold involves a session between the
transferor and the transfer target before the transfer actually takes
place. This is implemented with SIP Hold and Transfer as described
above.
6.1 Exposing transfer target
The transferor places the transferee on hold, establishes a call with
the transfer target to alert them to the impending transfer,
terminates the connection with the transfer target, then proceeds
with transfer as above. This variation can be used to provide an
experience similar to that expected by current PBX and Centrex users.
To (hopefully) improve clarity, non-REFER transactions have been
collapsed into one indicator with the arrow showing the direction of
the request.
Sparks & Johnston Expires August 15, 2004 [Page 11]
Internet-Draft SIP CC Transfer February 2004
Transferor Transferee Transfer
| | Target
| | |
Call-ID:1 | INVITE/200 OK/ACK | |
|<-------------------| |
Call-ID:1 | INVITE (hold)/200 OK/ACK |
|------------------->| |
Call-ID:2 | INVITE/200 OK/ACK | |
|---------------------------------------->|
Call-ID:2 | BYE/200 OK | |
|---------------------------------------->|
Call-ID:1 | REFER | |
|------------------->| |
Call-ID:1 | 202 Accepted | |
|<-------------------| |
Call-ID:1 | NOTIFY (100 Trying)| |
|<-------------------| |
Call-ID:1 | 200 OK | |
|------------------->| |
Call-ID:3 | | INVITE/200 OK/ACK |
| |------------------->|
Call-ID:1 | NOTIFY (200 OK) | |
|<-------------------| |
Call-ID:1 | 200 OK | |
|------------------->| |
Call-ID:1 | BYE/200 OK | |
|------------------->| |
Call-ID:3 | | BYE/200 OK |
| |<-------------------|
Figure 4. Transfer with Consultation Hold - Exposing Transfer
Target.
Sparks & Johnston Expires August 15, 2004 [Page 12]
Internet-Draft SIP CC Transfer February 2004
6.2 Protecting transfer target
The transferor places the transferee on hold, establishes a call with
the transfer target and then reverses their roles, transferring the
original transfer target to the original transferee. This has the
advantage of hiding information about the original transfer target
from the original transferee. On the other hand, the Transferee's
experience is different that in current systems. The Transferee is
effectively "called back" by the Transfer Target.
One of the problems with this simplest implementation of a target
protecting transfer is that the transferee is receiving a new call
from the transfer-target. Unless the transferee's agent has a
reliable way to associate this new call with the call it already has
with the transferor, it will have to alert the new call on another
appearance. If this, or some other call-waiting-like UI were not
available, the transferee might be stuck returning a Busy-Here to the
transfer target, effectively preventing the transfer. There are many
ways that that correlation could be provided. The dialog parameters
could be provided directly as header parameters in the Refer-To: URI
for example. The Replaces mechanism [3] uses this approach and solves
this problem nicely.
For the flow below, dialog1 means dialog identifier 1, and consists
of the parameters of the Replaces header for dialog 1. In [3] this is
the Call-ID, To-tag and From-tag.
Note that the transferee's agent emits a BYE to the transferor's
agent as an immediate consequence of processing the Replaces header.
The Transferor knows that both the Transferee and the Transfer Target
support the Replaces header from the Supported: replaces header
contained in the 200 OK responses from both.
Sparks & Johnston Expires August 15, 2004 [Page 13]
Internet-Draft SIP CC Transfer February 2004
Transferor Transferee Transfer
| | Target
| | |
dialog1 | INVITE/200 OK/ACK F1 F2 |
|<-------------------| |
dialog1 | INVITE (hold)/200 OK/ACK |
|------------------->| |
dialog2 | INVITE/200 OK/ACK | |
|---------------------------------------->|
dialog2 | INVITE (hold)/200 OK/ACK |
|---------------------------------------->|
dialog2 | REFER (Refer-To:sip:Transferee?Replaces=dialog1) F3
|---------------------------------------->|
dialog2 | 202 Accepted | |
|<----------------------------------------|
dialog2 | NOTIFY (100 Trying)| |
|<----------------------------------------|
dialog2 | | 200 OK |
|---------------------------------------->|
dialog3 | INVITE (Replaces:dialog1)/200 OK/ACK F4
| |<-------------------|
dialog1 | BYE/200 OK | |
|<-------------------| |
dialog2 | NOTIFY (200 OK) | |
|<----------------------------------------|
dialog2 | | 200 OK |
|---------------------------------------->|
dialog2 | BYE/200 OK | |
|---------------------------------------->|
| | (transferee and target converse)
dialog3 | | BYE/200 OK |
| |------------------->|
Figure 5. Transfer Protecting Transfer Target.
F1 INVITE Transferee -> Transferor
INVITE sip:transferor@atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sip:transferor@atlanta.example.com>
From: <sip:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Sparks & Johnston Expires August 15, 2004 [Page 14]
Internet-Draft SIP CC Transfer February 2004
Contact: <sip:transferee@92.0.2.4>
Content-Type: application/sdp
Content-Length: ...
F2 200 OK Transferor -> Transferee
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas432
To: <sip:transferor@atlanta.example.com>;tag=31431
From: <sip:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sip:transferor@pc33.atlanta.example.com>
Content-Type: application/sdp
Content-Length: ...
F3 REFER Transferor -> Transfer Target
REFER sip:transfertarget@client.chicago.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnashds9
Max-Forwards: 70
To: <sip:transfertarget@chicago.example.com>;tag=a6c85cf
From: <sip:transferor@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 REFER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Refer-To: <sip:transferee@192.0.2.4;Replaces=
090459243588173445%3Bto-tag%3D31431%3Bfrom-tag%3D7553452>
Contact: <sip:transferor@pc33.atlanta.example.com>
Content-Length: 0
F4 INVITE Transfer Target -> Transferee
INVITE sip:transferee@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP client.chicago.com;branch=z9hG4bKnaslu84
Max-Forwards: 70
To: <sip:transferee@biloxi.example.com>
From: <sip:transfertarget@chicago.example.com>;tag=341234
Call-ID: kmzwdle3dl3d08
CSeq: 41 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Sparks & Johnston Expires August 15, 2004 [Page 15]
Internet-Draft SIP CC Transfer February 2004
Supported: replaces
Contact: <sip:transfertarget@client.chicago.com>
Replaces: 090459243588173445;to-tag=31431;from-tag=7553452
Content-Type: application/sdp
Content-Length: ...
6.3 Attended Transfer
The transferor places the transferee on hold, establishes a call with
the transfer target to alert them to the impending transfer, places
the target on hold, then proceeds with transfer using an escaped
Replaces header field in the Refer-To header. This is another common
service expected by current PBX and Centrex users.
In order to be sure that triggered INVITE (message F4) reaches the
Transfer Target, the Contact URI is used as the Refer-To URI. The
presence of a Supported: gruu header field in the 200 OK (message F3)
from the Transfer Target to the Transferee guarantees that this
Contact URI is a GRUU [5] (Globally Routable User Agent URI) and will
be routable outside this dialog. Without an indication that the
Contact URI is a GRUU, the Transferee should still use the Contact
URI as the Refer-To URI. However, the Transferee needs to be
prepared in the event that the transfer fails, as described in
Section 6.5.
Sparks & Johnston Expires August 15, 2004 [Page 16]
Internet-Draft SIP CC Transfer February 2004
Transferor Transferee Transfer
| | Target
| | |
dialog1 | INVITE/200 OK/ACK | |
|<-------------------| |
dialog1 | INVITE (hold)/200 OK/ACK |
|------------------->| |
dialog2 | INVITE/200 OK/ACK F1 F2 |
|---------------------------------------->|
dialog2 | INVITE (hold)/200 OK/ACK |
|---------------------------------------->|
dialog1 | REFER (Refer-To:sip:TransferTarget?Replaces=dialog2) F3
|------------------->| |
dialog1 | 202 Accepted | |
|<-------------------| |
dialog1 | NOTIFY (100 Trying)| |
|<-------------------| |
dialog1 | 200 OK | |
|------------------->| |
dialog3 | INVITE (Replaces:dialog2)/200 OK/ACK F4
| |------------------->|
dialog2 | BYE/200 OK | |
|<----------------------------------------|
dialog1 | NOTIFY (200 OK) | |
|<-------------------| |
dialog1 | 200 OK | |
|------------------->| |
dialog1 | BYE/200 OK | |
|------------------->| |
dialog3 | | BYE/200 OK |
| |<-------------------|
Figure 6. Attended Transfer Call Flow.
F1 INVITE Transferor -> Transfer Target
INVITE sip:transfertarget@chicago.example.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sip:transfertarget@chicago.example.com>
From: <sip:transferor@atlanta.example.com>;tag=763231
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sip:transferor@pc33.atlanta.example.com>
Content-Type: application/sdp
Sparks & Johnston Expires August 15, 2004 [Page 17]
Internet-Draft SIP CC Transfer February 2004
Content-Length: ...
F2 200 OK Transfer Target -> Transferee
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnas432
;received=192.0.2.1
To: <sip:transfertarget@chicago.example.com>;tag=9m2n3wq
From: <sip:transferor@atlanta.example.com>;tag=763231
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Contact: <sip:transfertarget@client.chicago.example.com>
Content-Type: application/sdp
Content-Length: ...
F3 REFER Transferor -> Transferee
REFER sip:transferee@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnashds9
Max-Forwards: 70
To: <sip:transferee@biloxi.example.com>;tag=a6c85cf
From: <sip:transferor@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 REFER
Refer-To: <sip:transfertarget@client.chicago.example.com;Replaces=
090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-tag%3D763231>
Contact: <sip:transferor@pc33.atlanta.example.com>
Content-Length: 0
F4 INVITE Transferee -> Transfer Target
INVITE sip:transfertarget@client.chicago.example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnaslu82
Max-Forwards: 70
To: <sip:transfertarget@chicago.example.com>
From: <sip:transferee@biloxi.example.com>;tag=954
Call-ID: kmzwdle3dl3d08
CSeq: 41 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sip:transferee@192.0.2.4>
Replaces: 090459243588173445;to-tag=9m2n3wq;from-tag=763231
Content-Type: application/sdp
Sparks & Johnston Expires August 15, 2004 [Page 18]
Internet-Draft SIP CC Transfer February 2004
Content-Length: ...
6.4 Recovery when one party does not support REFER
If protecting or exposing the transfer target is not a concern, it is
possible to complete a transfer with consultation hold when only the
transferor and one other party support REFER. Note that a 405 Method
Not Allowed might be returned instead of the 501 Not Implemented
response.
Transferor Transferee Transfer
| | Target
| | |
dialog1 | INVITE/200 OK/ACK | |
|<-------------------| |
dialog1 | INVITE (hold)/200 OK/ACK |
|------------------->| |
dialog2 | INVITE/200 OK/ACK | |
|---------------------------------------->|
dialog2 | INVITE (hold)/200 OK/ACK |
|---------------------------------------->|
dialog1 | REFER (Refer-To:sip:TransferTarget?Replaces=dialog2)
|------------------->| |
dialog1 | 501 Not Implemented |
|<-------------------| |
dialog2 | REFER (Refer-To:sip:Transferee?Replaces=dialog1)
|---------------------------------------->|
dialog2 | 202 Accepted | |
|<----------------------------------------|
dialog2 | NOTIFY (100 Trying)| |
|<----------------------------------------|
dialog2 | | 200 OK |
|---------------------------------------->|
dialog3 | | INVITE (Replaces:dialog1)/200 OK/ACK
| |<-------------------|
dialog2 | NOTIFY (200 OK) | |
|<----------------------------------------|
| | 200 OK |
|---------------------------------------->|
dialog1 | BYE/200 OK | |
|<-------------------| |
dialog2 | BYE/200 OK | |
|---------------------------------------->|
dialog3 | | BYE/200 OK |
| |------------------->|
Sparks & Johnston Expires August 15, 2004 [Page 19]
Internet-Draft SIP CC Transfer February 2004
Figure 7. Recovery when one party does not support REFER.
6.5 Attended Transfer when Contact URI is Not Globally Routable
It is a requirement of RFC3261 that a Contact URI be globally
routable even outside the dialog. However, due to RFC2543 User
Agents and some architectures (NAT/Firewall traversal, screening
proxies, ALGs, etc.) this will not always be the case. As a result,
the method of Attended transfer shown in Figures 6 and 7 may fail
since they use the Contact URI in the Refer-To header field.
Participants in transfer scenarios should indicate if their Contact
URIs are GRUUs using the Supported: gruu header field.
Figure 8 shows such a scenario involving a Screening Proxy in which
the transfer initially fails but succeeds on a second try. The
failure (403 Forbidden, 404 Not Found, or a timeout after no
response) response is communicated back to the Transferor. Since
this may be caused by routing problems with the Contact URI, the
Transferor retries the REFER this time with Refer-To containing the
Address of Record (AOR) of the Target (the same URI the Transferor
used to reach the Target). However, the use of the AOR URI may
result in routing features being activated such as forking or
sequential searching which may result in the triggered INVITE
reaching the wrong UA. To prevent an incorrect UA answering the
INVITE, a Require: replaces header field is included in the Refer-To.
This ensures that only the UA which matches the Replaces dialog will
answer the INVITE, since any incorrect UA which supports Replaces
will reply with a 481 and a UA which does not support Replaces will
reply with a 420.
Note that there is still no guarantee that the correct endpoint will
be reached, and the result of this second REFER may also be a
failure. In that case, the Transferor could fall back to unattended
transfer or give up on the transfer entirely. Since two REFERs are
sent within the dialog creating two distinct subscriptions, the
Transferee uses the 'id' parameter in the Event header field to
distinguish notifications for the two subscriptions.
Transferor Transferee Screening Transfer
| | Proxy Target
| | | |
dialog1 | INVITE/200 OK/ACK| | |
|<-----------------| | |
dialog1 | INVITE (hold)/200 OK/ACK | |
|----------------->| | |
dialog2 | INVITE/200 OK/ACK F1 F2 | |
|--------------------------------|------------>|
dialog2 | INVITE (hold)/200 OK/ACK |
Sparks & Johnston Expires August 15, 2004 [Page 20]
Internet-Draft SIP CC Transfer February 2004
|--------------------------------|------------>|
dialog1 | REFER (Refer-To:sip:TargetContact?Replaces=dialog2) F3
|----------------->| | |
dialog1 | 202 Accepted | | |
|<-----------------| | |
dialog1 | NOTIFY (100 Trying) | |
|<-----------------| | |
dialog1 | 200 OK | | |
|----------------->| | |
dialog3 | | INVITE (Replaces:dialog2)/403/ACK
| |------------>| |
dialog1 | NOTIFY (403 Forbidden) F4 | |
|<-----------------| | |
dialog1 | 200 OK | | |
|----------------->| | |
dialog1 |REFER(Refer-To:sip:TargetAOR?Replaces=dialog2&Require=replaces) F5
|----------------->| | |
dialog1 | 202 Accepted | | |
|<-----------------| | |
dialog1 | NOTIFY (100 Trying) | |
|<-----------------| | |
dialog1 | 200 OK | | |
|----------------->| | |
dialog4 | INVITE (Replaces:dialog2, Require:replaces)/200 OK/ACK F6
| |------------>|------------>|
dialog2 | BYE/200 OK | | |
|<-------------------------------|<------------|
dialog1 | NOTIFY (200 OK) F7 | |
|<-----------------| | |
dialog1 | 200 OK | | |
|----------------->| | |
dialog1 | BYE/200 OK | | |
|----------------->| | |
dialog3 | | | BYE/200 OK |
| |<------------|-------------|
Figure 8. Attended Transfer Call Flow with non-routable Contact URI
F1 INVITE Transferor -> Transfer Target
INVITE sip:transfertarget@chicago.example.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bK76
Max-Forwards: 70
To: <sip:transfertarget@chicago.example.com>
From: <sip:transferor@atlanta.example.com>;tag=763231
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Sparks & Johnston Expires August 15, 2004 [Page 21]
Internet-Draft SIP CC Transfer February 2004
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sip:transferor@pc33.atlanta.example.com>
Content-Type: application/sdp
Content-Length: ...
F2 200 OK Transfer Target -> Transferee
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnas432
;received=192.0.2.1
To: <sip:transfertarget@chicago.example.com>;tag=9m2n3wq
From: <sip:transferor@atlanta.example.com>;tag=763231
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sip:transfertarget@client.chicago.example.com>
Content-Type: application/sdp
Content-Length: ...
F3 REFER Transferor -> Transferee
REFER sip:transferee@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnashds9
Max-Forwards: 70
To: <sip:transferee@biloxi.example.com>;tag=a6c85cf
From: <sip:transferor@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 REFER
Refer-To: <sip:transfertarget@client.chicago.example.com;Replaces=
090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-tag%3D763231>
Contact: <sip:transferor@pc33.atlanta.example.com>
Content-Length: 0
F4 NOTIFY Transferee -> Transferor
NOTIFY sip:transferor@pc33.atlanta.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sip:transferor@atlanta.example.com>;tag=1928301774
From: <sip:transferee@biloxi.example.com>;tag=a6c85cf
Call-ID: a84b4c76e66710
CSeq: 74 NOTIFY
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Sparks & Johnston Expires August 15, 2004 [Page 22]
Internet-Draft SIP CC Transfer February 2004
Supported: replaces
Event: refer;id=3112
Subscription-State: terminated;reason=noresource
Content-Type: message/sipfrag
Content-Length: ...
SIP/2.0 403 Forbidden
F5 REFER Transferor -> Transferee
REFER sip:transferee@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnashds9
Max-Forwards: 70
To: <sip:transferee@biloxi.example.com>;tag=a6c85cf
From: <sip:transferor@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 REFER
Refer-To: <sip:transfertarget@chicago.example.com;Replaces=
090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-tag%3D763231&Require=replaces>
Contact: <sip:transferor@pc33.atlanta.example.com>
Content-Length: 0
F6 INVITE Transferee -> Transfer Target
INVITE sip:transfertarget@chicago.example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnaslu82
Max-Forwards: 70
To: <sip:transfertarget@chicago.example.com>
From: <sip:transferee@biloxi.example.com>;tag=954
Call-ID: 20482817324945934422930
CSeq: 42 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sip:transferee@192.0.2.4>
Replaces: 090459243588173445;to-tag=9m2n3wq;from-tag=763231
Require: replaces
Content-Type: application/sdp
Content-Length: ...
F7 NOTIFY Transferee -> Transferor
NOTIFY sip:transferor@pc33.atlanta.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sip:transferor@atlanta.example.com>;tag=1928301774
Sparks & Johnston Expires August 15, 2004 [Page 23]
Internet-Draft SIP CC Transfer February 2004
From: <sip:transferee@biloxi.example.com>;tag=a6c85cf
Call-ID: a84b4c76e66710
CSeq: 76 NOTIFY
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Event: refer;id=98873867
Subscription-State: terminated;reason=noresource
Content-Type: message/sipfrag
Content-Length: ...
SIP/2.0 200 OK
To prevent this scenario from happening, the Transfer Target should
obtain a GRUU and use it in the Contact header field, which will
result in the call flow of Figure 6.
6.6 Aborting a Consultation Hold
In any of the consultation hold flows above, the Transferor may
decide to terminate its attempt to contact the Transfer target before
that session is established. Most frequently, that will be the end of
the scenario, but in some circumstances, the transferor may wish to
proceed with the transfer action. For example, he may wish to
complete the transfer knowing that the transferee will end up
eventually talking to the transfer-target's voice-mail service. Some
PBX systems support this feature, sometimes called "semi-attended
transfer", that is effectively a hybrid between a fully attended
transfer and an unattended transfer. A true implementation of this
feature requires a short ad-hoc conference between all parties, which
ensures that no media clipping occurs. This flow is outside the
scope of this document.
For flows that expose the transfer target, this simply becomes a
basic transfer.
This scenario is far more complicated for flows that protect the
transfer target. Since no session is established between the
transferor and the transfer target, the transfer target's agent would
have to honor out-of-session REFERs, and somehow indicate what's
happening via its user interface (this scenario is most likely to
occur when the transfer-target is away from his agent).
6.7 Attended Transfer Fallback to Basic Transfer
In this flow, an attempted attended transfer fails so the transferor
falls back to basic transfer. The use of OPTIONS is shown when the
Transferee and Transfer Target do not explicitly indicate support for
Sparks & Johnston Expires August 15, 2004 [Page 24]
Internet-Draft SIP CC Transfer February 2004
the REFER method and Replaces header fields in Allow and Supported
header fields. In dialog1, the Transferor determines using OPTIONS
that the Transferee does support REFER and Replaces. As a result,
the Transferor begins the attended transfer by placing the Transferee
on hold and calling the Transfer Target. Using an OPTIONS in
dialog2, the Transferor determines that the Target does not support
either REFER or Replaces, making attended transfer impossible. (Note
that the same information could have been determined by including a
Require: replaces in the initial INVITE in dialog2, which would have
failed with a 421 response.) The Transferor then ends dialog2 by
sending a BYE then sends a REFER to the Transferee using the AOR URI
of the Transfer Target.
Transferor Transferee Transfer
| | Target
| | |
dialog1 | INVITE/200 OK/ACK | |
|<-------------------| |
dialog1 | OPTIONS/200 OK | |
|------------------->| |
dialog1 | INVITE (hold)/200 OK/ACK |
|------------------->| |
dialog2 | INVITE/200 OK/ACK | |
|---------------------------------------->|
dialog2 | OPTIONS/200 OK | |
|---------------------------------------->|
dialog2 | BYE/200 OK | |
|---------------------------------------->|
dialog1 | REFER (Refer-To:sip:TransferTarget) |
|------------------->| |
dialog1 | 202 Accepted | |
|<-------------------| |
dialog1 | NOTIFY (100 Trying)| |
|<-------------------| |
dialog1 | 200 OK | |
|------------------->| |
dialog3 | | INVITE/200 OK/ACK |
| |------------------->|
dialog1 | NOTIFY (200 OK) | |
|<-------------------| |
dialog1 | 200 OK | |
|------------------->| |
dialog1 | BYE/200 OK | |
|------------------->| |
dialog3 | | BYE/200 OK |
| |<-------------------|
Figure 9. Attended Transfer Fallback to Basic Transfer.
Sparks & Johnston Expires August 15, 2004 [Page 25]
Internet-Draft SIP CC Transfer February 2004
7. Transfer with Referred-By
In the previous examples, the Transfer Target does not have
definitive information about what party initiated the transfer, or,
in some cases, even that transfer is taking place. The Referred-By
mechanism [4] provides a way for the Transferor to provide the
Transferee with a way to let the Transfer Target know what party
initiated the transfer.
The simplest and least secure approach just involves the inclusion of
the Referred-By header field in the REFER which is then copied into
the triggered INVITE. However, a more secure mechanism involving the
Referred-By security token which is generated and signed by the
Transferor and passed in a message body to the Transferee then to the
Transfer Target.
The call flow would be identical to Figure 6. However, the REFER and
triggered INVITE messages for this flow showing the Referred-By
mechanism are shown below. Note that the conventions used in the SIP
Torture Test Messages [7] document are reused, specifically the
<hex> and <allOneLine> tags.
F3 REFER Transferor -> Transferee
REFER sip:transferee@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bK392039842
Max-Forwards: 70
To: <sip:transferee@biloxi.example.com>;tag=a6c85cf
From: <sip:transferor@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 REFER
<allOneLine>
Refer-To: <sip:transfertarget@chicago.example.com;Replaces=
090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-
tag%3D763231&Require=replaces>
</allOneLine>
Referred-By: <sip:transferor@atlanta.example.com>
;cid="20398823.2UWQFN309shb3@atlanta.example.com"
Contact: <sip:transferor@pc33.atlanta.example.com>
Content-Type: multipart/mixed; boundary=unique-boundary-1
Content-Length: 3267
--unique-boundary-1
Content-ID: <20398823.2UWQFN309shb3@atlanta.example.com>
Content-Length: 2961
Content-Type: multipart/signed;
Sparks & Johnston Expires August 15, 2004 [Page 26]
Internet-Draft SIP CC Transfer February 2004
protocol="application/pkcs-7-signature";
micalg=sha1;
boundary="----590F24D439B31E08745DEF0CD9397189"
------590F24D439B31E08745DEF0CD9397189
Content-Type: message/sipfrag
Date: Thu, 18 Sep 2003 13:07:43 GMT
<allOneLine>
Refer-To: <sip:transfertarget@chicago.example.com;
Replaces=090459243588173445%3B
to-tag%3D9m2n3wq%3Bfrom-tag%3D763231&Require=replaces>
</allOneLine>
Referred-By: <sip:transferor@atlanta.example.com>
;cid="20398823.2UWQFN309shb3@atlanta.example.com"
------590F24D439B31E08745DEF0CD9397189
Content-Type: application/pkcs-7-signature; name="smime.p7s"
Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename="smime.p7s"
<hex>3082088806092A86
4886F70D010702A082087930820875020101310B300906052B0E03021A050030
0B06092A864886F70D010701A082067A30820339308202A2A003020102020800
90008902240001300D06092A864886F70D01010505003070310B300906035504
0613025553311330110603550408130A43616C69666F726E69613111300F0603
550407130853616E4A6F7365310E300C060355040A1305736970697431293027
060355040B135369706974546573744365727469666963617465417574686F72
697479301E170D3033313032313134343332355A170D31333130313831343433
32355A3062310B3009060355040613025553311330110603550408130A43616C
69666F726E69613111300F0603550407130853616E4A6F7365310E300C060355
040A13057369706974311B30190603550403141273656E646572406578616D70
6C652E6F726730819F300D06092A864886F70D010101050003818D0030818902
818100CB8302060F12C8FA2D1786922CA173DCEB80BF1B1B8AF74A310C6975A5
56A7630FB6E044D9E994DCD49AFF7976C462D7A8E74ECBF98723AEBF2796EDDD
6263577C6C2B77DC7C300B533DEDB5FB8EB3827FD6FC9B37B9A0DE829F1B1081
D632A8AD9FB00A860928E88F87E0B979BA65294AC7D6D2D18A78C86B4FA73387
4E230203010001A381E93081E6301D0603551D1104163014811273656E646572
406578616D706C652E6F726730090603551D1304023000301D0603551D0E0416
041440FF1C0C1BB8684CA917839D70E97DF8DD5B60D130819A0603551D230481
9230818F80146B461714EA94762580546E1354DAA1E35414A1B6A174A4723070
310B3009060355040613025553311330110603550408130A43616C69666F726E
69613111300F0603550407130853616E4A6F7365310E300C060355040A130573
6970697431293027060355040B13536970697454657374436572746966696361
7465417574686F72697479820100300D06092A864886F70D0101050500038181
006FFE1A3B5CE807C3DD2CFDF6E9787F491C84DBF7DCD11DB2D6A8887D2FE3F2
2E9C6894994282E50AA0DFFE1CBD4EC2C20217831FC2AD360FF1C0DE1DE1E870
102CFA99EE504C7DC0D8752A63294AC748DDDEFADE55C6D051F1CD54CFE7C153
Sparks & Johnston Expires August 15, 2004 [Page 27]
Internet-Draft SIP CC Transfer February 2004
278962A53CEF61B875C1FD3C74E972242CBA0131B3B8C607BF95B378212CA9A7
5E30820339308202A2A00302010202080090008902240001300D06092A864886
F70D01010505003070310B300906035504061302555331133011060355040813
0A43616C69666F726E69613111300F0603550407130853616E4A6F7365310E30
0C060355040A1305736970697431293027060355040B13536970697454657374
4365727469666963617465417574686F72697479301E170D3033313032313134
343332355A170D3133313031383134343332355A3062310B3009060355040613
025553311330110603550408130A43616C69666F726E69613111300F06035504
07130853616E4A6F7365310E300C060355040A13057369706974311B30190603
550403141273656E646572406578616D706C652E6F726730819F300D06092A86
4886F70D010101050003818D0030818902818100CB8302060F12C8FA2D178692
2CA173DCEB80BF1B1B8AF74A310C6975A556A7630FB6E044D9E994DCD49AFF79
76C462D7A8E74ECBF98723AEBF2796EDDD6263577C6C2B77DC7C300B533DEDB5
FB8EB3827FD6FC9B37B9A0DE829F1B1081D632A8AD9FB00A860928E88F87E0B9
79BA65294AC7D6D2D18A78C86B4FA733874E230203010001A381E93081E6301D
0603551D1104163014811273656E646572406578616D706C652E6F7267300906
03551D1304023000301D0603551D0E0416041440FF1C0C1BB8684CA917839D70
E97DF8DD5B60D130819A0603551D2304819230818F80146B461714EA94762580
546E1354DAA1E35414A1B6A174A4723070310B30090603550406130255533113
30110603550408130A43616C69666F726E69613111300F060355040713085361
6E4A6F7365310E300C060355040A1305736970697431293027060355040B1353
69706974546573744365727469666963617465417574686F7269747982010030
0D06092A864886F70D0101050500038181006FFE1A3B5CE807C3DD2CFDF6E978
7F491C84DBF7DCD11DB2D6A8887D2FE3F22E9C6894994282E50AA0DFFE1CBD4E
C2C20217831FC2AD360FF1C0DE1DE1E870102CFA99EE504C7DC0D8752A63294A
C748DDDEFADE55C6D051F1CD54CFE7C153278962A53CEF61B875C1FD3C74E972
242CBA0131B3B8C607BF95B378212CA9A75E318201D6308201D2020101307C30
70310B3009060355040613025553311330110603550408130A43616C69666F72
6E69613111300F0603550407130853616E4A6F7365310E300C060355040A1305
736970697431293027060355040B135369706974546573744365727469666963
617465417574686F7269747902080090008902240001300906052B0E03021A05
00A081B1301806092A864886F70D010903310B06092A864886F70D010701301C
06092A864886F70D010905310F170D3034303132363139313831345A30230609
2A864886F70D01090431160414408CCA5772916A968204FD24CC24EDAEAD3943
95305206092A864886F70D01090F31453043300A06082A864886F70D0307300E
06082A864886F70D030202020080300D06082A864886F70D0302020140300706
052B0E030207300D06082A864886F70D0302020128300D06092A864886F70D01
010105000481807795329BB23B8BB9F72526AB9CC22D93B9A37A2E69A0171D3C
C417DD394F0A5FD4F8B082733CD9F2E26F6991031F7FF2EAD31640718502FB4C
822771211E6228C793DA4DBBA2159227C221030FE9088CD659578EB862568087
8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B428388966
79089AAD95767F</hex>
------590F24D439B31E08745DEF0CD9397189--
--unique_boundary-1
Sparks & Johnston Expires August 15, 2004 [Page 28]
Internet-Draft SIP CC Transfer February 2004
F4 INVITE Transferee -> Transfer Target
INVITE sip:transfertarget@chicago.example.com SIP/2.0
Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac
To: <sip:transfertarget@chicago.example.com>
From: <sip:transferee@biloxi.example.com>;tag=2909034023
Call-ID: fe9023940-a3465@referee.example
CSeq: 889823409 INVITE
Max-Forwards: 70
Contact: <sip:transferee@192.0.2.4>
Referred-By: <sip:transferor@atlanta.example.com>
;cid="20398823.2UWQFN309shb3@atlanta.example.com"
Replaces:090459243588173445;to-tag=9m2n3wq;from-
tag=76323
Require:replaces
Content-Type: multipart/mixed; boundary=my-boundary-9
Content-Length: 3432
--my-boundary-9
Content-Type: application/sdp
Content-Length: 156
v=0
o=referee 2890844526 2890844526 IN IP4 referee.example
s=Session SDP
c=IN IP4 referee.example
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
--my-boundary-9
Content-Length: 2961
Content-Type: multipart/signed;
protocol="application/pkcs-7-signature";
micalg=sha1;
boundary="----590F24D439B31E08745DEF0CD9397189"
------590F24D439B31E08745DEF0CD9397189
Content-Type: message/sipfrag
Date: Thu, 18 Sep 2003 13:07:43 GMT
<allOneLine>
Refer-To: <sip:transfertarget@chicago.example.com;
Replaces=090459243588173445%3B
to-tag%3D9m2n3wq%3Bfrom-tag%3D763231&Require=replaces>
</allOneLine>
Referred-By: <sip:transferor@atlanta.example.com>
;cid="20398823.2UWQFN309shb3@atlanta.example.com"
Sparks & Johnston Expires August 15, 2004 [Page 29]
Internet-Draft SIP CC Transfer February 2004
------590F24D439B31E08745DEF0CD9397189
Content-Type: application/pkcs-7-signature; name="smime.p7s"
Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename="smime.p7s"
<hex>3082088806092A86
4886F70D010702A082087930820875020101310B300906052B0E03021A050030
0B06092A864886F70D010701A082067A30820339308202A2A003020102020800
90008902240001300D06092A864886F70D01010505003070310B300906035504
0613025553311330110603550408130A43616C69666F726E69613111300F0603
550407130853616E4A6F7365310E300C060355040A1305736970697431293027
060355040B135369706974546573744365727469666963617465417574686F72
697479301E170D3033313032313134343332355A170D31333130313831343433
32355A3062310B3009060355040613025553311330110603550408130A43616C
69666F726E69613111300F0603550407130853616E4A6F7365310E300C060355
040A13057369706974311B30190603550403141273656E646572406578616D70
6C652E6F726730819F300D06092A864886F70D010101050003818D0030818902
818100CB8302060F12C8FA2D1786922CA173DCEB80BF1B1B8AF74A310C6975A5
56A7630FB6E044D9E994DCD49AFF7976C462D7A8E74ECBF98723AEBF2796EDDD
6263577C6C2B77DC7C300B533DEDB5FB8EB3827FD6FC9B37B9A0DE829F1B1081
D632A8AD9FB00A860928E88F87E0B979BA65294AC7D6D2D18A78C86B4FA73387
4E230203010001A381E93081E6301D0603551D1104163014811273656E646572
406578616D706C652E6F726730090603551D1304023000301D0603551D0E0416
041440FF1C0C1BB8684CA917839D70E97DF8DD5B60D130819A0603551D230481
9230818F80146B461714EA94762580546E1354DAA1E35414A1B6A174A4723070
310B3009060355040613025553311330110603550408130A43616C69666F726E
69613111300F0603550407130853616E4A6F7365310E300C060355040A130573
6970697431293027060355040B13536970697454657374436572746966696361
7465417574686F72697479820100300D06092A864886F70D0101050500038181
006FFE1A3B5CE807C3DD2CFDF6E9787F491C84DBF7DCD11DB2D6A8887D2FE3F2
2E9C6894994282E50AA0DFFE1CBD4EC2C20217831FC2AD360FF1C0DE1DE1E870
102CFA99EE504C7DC0D8752A63294AC748DDDEFADE55C6D051F1CD54CFE7C153
278962A53CEF61B875C1FD3C74E972242CBA0131B3B8C607BF95B378212CA9A7
5E30820339308202A2A00302010202080090008902240001300D06092A864886
F70D01010505003070310B300906035504061302555331133011060355040813
0A43616C69666F726E69613111300F0603550407130853616E4A6F7365310E30
0C060355040A1305736970697431293027060355040B13536970697454657374
4365727469666963617465417574686F72697479301E170D3033313032313134
343332355A170D3133313031383134343332355A3062310B3009060355040613
025553311330110603550408130A43616C69666F726E69613111300F06035504
07130853616E4A6F7365310E300C060355040A13057369706974311B30190603
550403141273656E646572406578616D706C652E6F726730819F300D06092A86
4886F70D010101050003818D0030818902818100CB8302060F12C8FA2D178692
2CA173DCEB80BF1B1B8AF74A310C6975A556A7630FB6E044D9E994DCD49AFF79
76C462D7A8E74ECBF98723AEBF2796EDDD6263577C6C2B77DC7C300B533DEDB5
FB8EB3827FD6FC9B37B9A0DE829F1B1081D632A8AD9FB00A860928E88F87E0B9
79BA65294AC7D6D2D18A78C86B4FA733874E230203010001A381E93081E6301D
0603551D1104163014811273656E646572406578616D706C652E6F7267300906
Sparks & Johnston Expires August 15, 2004 [Page 30]
Internet-Draft SIP CC Transfer February 2004
03551D1304023000301D0603551D0E0416041440FF1C0C1BB8684CA917839D70
E97DF8DD5B60D130819A0603551D2304819230818F80146B461714EA94762580
546E1354DAA1E35414A1B6A174A4723070310B30090603550406130255533113
30110603550408130A43616C69666F726E69613111300F060355040713085361
6E4A6F7365310E300C060355040A1305736970697431293027060355040B1353
69706974546573744365727469666963617465417574686F7269747982010030
0D06092A864886F70D0101050500038181006FFE1A3B5CE807C3DD2CFDF6E978
7F491C84DBF7DCD11DB2D6A8887D2FE3F22E9C6894994282E50AA0DFFE1CBD4E
C2C20217831FC2AD360FF1C0DE1DE1E870102CFA99EE504C7DC0D8752A63294A
C748DDDEFADE55C6D051F1CD54CFE7C153278962A53CEF61B875C1FD3C74E972
242CBA0131B3B8C607BF95B378212CA9A75E318201D6308201D2020101307C30
70310B3009060355040613025553311330110603550408130A43616C69666F72
6E69613111300F0603550407130853616E4A6F7365310E300C060355040A1305
736970697431293027060355040B135369706974546573744365727469666963
617465417574686F7269747902080090008902240001300906052B0E03021A05
00A081B1301806092A864886F70D010903310B06092A864886F70D010701301C
06092A864886F70D010905310F170D3034303132363139313831345A30230609
2A864886F70D01090431160414408CCA5772916A968204FD24CC24EDAEAD3943
95305206092A864886F70D01090F31453043300A06082A864886F70D0307300E
06082A864886F70D030202020080300D06082A864886F70D0302020140300706
052B0E030207300D06082A864886F70D0302020128300D06092A864886F70D01
010105000481807795329BB23B8BB9F72526AB9CC22D93B9A37A2E69A0171D3C
C417DD394F0A5FD4F8B082733CD9F2E26F6991031F7FF2EAD31640718502FB4C
822771211E6228C793DA4DBBA2159227C221030FE9088CD659578EB862568087
8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B428388966
79089AAD95767F</hex>
------590F24D439B31E08745DEF0CD9397189--
--my-boundary-9--
8. Transfer with multiple parties
In this example the Originator places call to the Facilitator who
reaches the Recipient through the Screener. The Recipient's contact
information is exposed to the Facilitator and the Originator. This
example is provided for clarification of the semantics of the REFER
method only and should not be used as the design of an
implementation.
Originator Facilitator Screener Recipient
Call-ID | | | |
1 |INVITE/200 OK/ACK | |"Get Fred for me!"
|----------->| | | "Right away!"
1 |INVITE (hold)/200 OK/ACK | |
|<-----------| | |
Sparks & Johnston Expires August 15, 2004 [Page 31]
Internet-Draft SIP CC Transfer February 2004
2 | |INVITE/200 OK/ACK |"I have a call
| |----------->| |from Mary for Fred"
2 | |INVITE (hold)/200 OK/ACK "Hold please"
| |<-----------| |
3 | | |INVITE/200 OK/ACK
| | |--------->|"You have a call
| | | |from Mary"
| | | | "Put her through"
3 | | |INVITE (hold)/200 OK/ACK
| | |--------->|
2 | |REFER | |
| |<-----------| |
2 | |202 Accepted| |
| |----------->| |
2 | |NOTIFY (100 Trying) |
| |----------->| |
2 | |200 OK | |
| |<-----------| |
2 | |INVITE/200 OK/ACK |
| |---------------------->|"This is Fred"
2 | |NOTIFY (200 OK) | "Please hold for
| |----------->| | Mary"
2 | |200 OK | |
| |<-----------| |
2 | |BYE/200 OK | |
| |<-----------| |
3 | | |BYE/200 OK|
| | |--------->|
2 | |INVITE (hold)/200 OK/ACK
| |---------------------->|
1 |REFER | | |
|<-----------| | |
1 |202 Accepted| | |
|----------->| | |
1 |NOTIFY (100 Trying) | |
|----------->| | |
1 |200 OK | | |
|<-----------| | |
1 |INVITE/200 OK/ACK | |
|----------------------------------->| "Hey Fred"
1 |NOTIFY (200 OK) | | "Hello Mary"
|----------->| | |
1 |200 OK | | |
|<-----------| | |
1 |BYE/200 OK | | |
|<-----------| | |
2 | |BYE/200 OK | |
| |---------------------->|
Sparks & Johnston Expires August 15, 2004 [Page 32]
Internet-Draft SIP CC Transfer February 2004
1 |BYE/200 OK | | |
|<-----------------------------------| "See you later"
Figure 10. Transfer with Multiple Parties Example.
9. Changes from draft-sipping-cc-transfer-01
o Added example S/MIME messages in Referred-By section.
o Added reference and discussion of GRUUs
10. Changes from draft-sipping-cc-transfer-00
o Added section on use of Referred-By header.
o Added selected message details.
o Added flow for attended transfer with non-globally routable
Contact URI.
o Added flow for attended transfer fallback to unattended transfer.
o Added Security Considerations Section.
11. IANA Considerations
None.
12. Security Considerations
The call transfer flows shown in this document are implemented using
the REFER and Replaces call control primitives in SIP. As such, the
attacks and security approaches are those detailed in the REFER and
Replaces documents which are briefly summarized in the following
paragraphs. This document addresses the issue of protecting the
Address of Record URI of a transfer target in Sections 6.1 and 6.2.
Any REFER request must be appropriately authenticated and authorized
using standard SIP mechanisms or calls may be hijacked. A user agent
may use local policy or human intervention in deciding whether or not
to accept a REFER. In generating NOTIFY responses based on the
outcome of the triggered request, care should be taken in
constructing the message/sipfrag body to ensure that no private
information is leaked.
An INVITE containing a Replaces header field should only be accepted
if it has been properly authenticated and authorized using standard
SIP mechanisms, and the requestor is authorized to perform dialog
replacement.
13. Acknowledgments
This draft is a collaborative product of the SIP working group.
Sparks & Johnston Expires August 15, 2004 [Page 33]
Internet-Draft SIP CC Transfer February 2004
Thanks to Rohan Mahy for his input on the use of Replaces in
transfer.
Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[3] Biggs, B., Dean, R. and R. Mahy, "The Session Inititation
Protocol (SIP) 'Replaces' Header", draft-ietf-sip-replaces-04
(work in progress), August 2003.
[4] Sparks, R., "The SIP Referred-By Mechanism",
draft-ietf-sip-referredby-03 (work in progress), August 2003.
[5] Rosenberg, J., "Obtaining and Using Globally Routable User Agent
(UA) URIs (GRUU) in the Session Initiation Protocol (SIP)",
draft-ietf-sip-gruu-00 (work in progress), January 2004.
Informative References
[6] Mahy, R., "A Call Control and Multi-party usage framework for
the Session Initiation Protocol (SIP)",
draft-ietf-sipping-cc-framework-03 (work in progress), October
2003.
[7] Sparks, R., "Session Initiation Protocol Torture Test Messages",
draft-ietf-sipping-torture-tests-03 (work in progress), January
2004.
Authors' Addresses
Robert J. Sparks
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, TX 75024
EMail: rsparks@dynamicsoft.com
Sparks & Johnston Expires August 15, 2004 [Page 34]
Internet-Draft SIP CC Transfer February 2004
Alan Johnston
MCI
100 South 4th Street
St. Louis, MO 63102
EMail: alan.johnston@mci.com
Sparks & Johnston Expires August 15, 2004 [Page 35]
Internet-Draft SIP CC Transfer February 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Sparks & Johnston Expires August 15, 2004 [Page 36]
Internet-Draft SIP CC Transfer February 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Sparks & Johnston Expires August 15, 2004 [Page 37]
