Session Initiation Protocol (SIP) Call Control - Transfer
draft-ietf-sipping-cc-transfer-12
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 5589.
|
|
|---|---|---|---|
| Authors | Daniel Petrie , Robert Sparks , Alan Johnston | ||
| Last updated | 2023-11-10 (Latest revision 2009-03-03) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Best Current Practice | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | (None) | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 5589 (Best Current Practice) | |
| Action Holders |
(None)
|
||
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Cullen Fluffy Jennings | ||
| Send notices to | (None) |
draft-ietf-sipping-cc-transfer-12
SIPPING WG R. Sparks
Internet-Draft Estacado Systems
Intended status: BCP A. Johnston, Ed.
Expires: September 4, 2009 Avaya
D. Petrie
SIPez LLC
March 3, 2009
Session Initiation Protocol Call Control - Transfer
draft-ietf-sipping-cc-transfer-12
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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 September 4, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
Sparks, et al. Expires September 4, 2009 [Page 1]
Internet-Draft SIP CC Transfer March 2009
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document describes providing Call Transfer capabilities in the
Session Initiation Protocol (SIP). SIP extensions such as REFER and
Replaces are used to provide a number of transfer services including
blind transfer, consultative transfer, and attended transfer. This
work is part of the SIP multiparty call control framework.
Sparks, et al. Expires September 4, 2009 [Page 2]
Internet-Draft SIP CC Transfer March 2009
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Actors and Roles . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Using REFER to achieve Call Transfer . . . . . . . . . . . . . 6
6. Basic Transfer . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Successful Transfer . . . . . . . . . . . . . . . . . . . 8
6.2. Transfer with Dialog Reuse . . . . . . . . . . . . . . . . 12
6.3. Failed Transfer . . . . . . . . . . . . . . . . . . . . . 16
6.3.1. Target Busy . . . . . . . . . . . . . . . . . . . . . 16
6.3.2. Transfer Target does not answer . . . . . . . . . . . 18
7. Transfer with Consultation Hold . . . . . . . . . . . . . . . 19
7.1. Exposing transfer target . . . . . . . . . . . . . . . . . 19
7.2. Protecting transfer target . . . . . . . . . . . . . . . . 20
7.3. Attended Transfer . . . . . . . . . . . . . . . . . . . . 25
7.4. Recovery when one party does not support REFER . . . . . . 28
7.5. Attended transfer when Contact URI is not known to
route to a unique user agent. . . . . . . . . . . . . . . 29
7.6. Semi-Attended Transfer . . . . . . . . . . . . . . . . . . 36
7.7. Attended Transfer Fallback to Basic Transfer . . . . . . . 41
8. Transfer with Referred-By . . . . . . . . . . . . . . . . . . 43
9. Transfer as an Ad-Hoc Conference . . . . . . . . . . . . . . . 47
10. Transfer with multiple parties . . . . . . . . . . . . . . . . 50
11. Gateway Transfer Issues . . . . . . . . . . . . . . . . . . . 52
11.1. Coerce Gateway Hairpins to the Same Gateway . . . . . . . 52
11.2. Consultative Turned Blind Gateway Glare . . . . . . . . . 53
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
13. Security Considerations . . . . . . . . . . . . . . . . . . . 53
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
15.1. Normative References . . . . . . . . . . . . . . . . . . . 54
15.2. Informative References . . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
Sparks, et al. Expires September 4, 2009 [Page 3]
Internet-Draft SIP CC Transfer March 2009
1. Overview
This document describes providing Call Transfer capabilities and
requirements in SIP [RFC3261]. This work is part of the Multiparty
Call Control Framework [I-D.ietf-sipping-cc-framework].
The mechanisms discussed here are most closely related to traditional
basic and consultation hold transfers.
This document details the use of REFER method [RFC3515] and Replaces
[RFC3891] header field to achieve call transfer.
A user agent that fully supports the transfer mechanisms described in
this document supports REFER[RFC3515] and Replaces[RFC3891] in
addition to RFC 3261 [RFC3261]. A user agent should use a Contact
URI which meets the requirements in Section 8.1.1.8 of RFC 3261. A
compliant user agent supports the Target-Dialog header field
[RFC4538].
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:
Sparks, et al. Expires September 4, 2009 [Page 4]
Internet-Draft SIP CC Transfer March 2009
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. Typically, a Facilitator
acts on behalf of the Originator.
Screener - receives a call ultimately intended for the
Recipient and transfers the calling party to
the Recipient if appropriate. Typically, a Screener
acts on behalf of the Recipient.
Recipient - the party the Originator is ultimately
connected to.
3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
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 transfer failure
for instance) will be lost.
3. The Transferor must know whether or not the transfer was
successful.
Sparks, et al. Expires September 4, 2009 [Page 5]
Internet-Draft SIP CC Transfer March 2009
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.
6. The Transferor should provide the Transfer Target and Transferee
with information about the nature and progress of the transfer
operation being attempted.
To meet this requirement, the transfer operation can
be modeled as an ad-hoc conference between three
parties, as discussed in Section 8.
5. Using REFER to achieve Call Transfer
A REFER [RFC3515] 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 [RFC3261] or
conferencing extensions described in the conferencing framework
[RFC4353].
To perform the transfer, the transferor and transferee could reuse an
existing dialog established by an INVITE to send the REFER. This
would result in a single dialog shared by two uses - an invite usage
and a subscription usage. The call flows for this are shown in
detail in Section 6.2. However, the approach described in this
document is to avoid dialog reuse. The issues and difficulties
associated with dialog reuse are described in [RFC5057]
Motivations for reusing the existing dialog include:
1. There was no way to ensure that a REFER on a new dialog would
reach the particular endpoint involved in a transfer. Many
factors, including details of implementations and changes in
proxy routing between an INVITE and a REFER could cause the REFER
to be sent to the wrong place. Sending the REFER down the
Sparks, et al. Expires September 4, 2009 [Page 6]
Internet-Draft SIP CC Transfer March 2009
existing dialog ensured it got to the endpoint we were already
talking to.
2. It was unclear how to associate an existing invite usage with a
REFER arriving on a new dialog, where it was completely obvious
what the association was when the REFER came on the invite
usage's dialog.
3. There were concerns with authorizing out-of-dialog REFERs. The
authorization policy for REFER in most implementations piggybacks
on the authorization policy for INVITE (which is, in most cases,
based simply on "I placed or answered this call").
GRUUs [I-D.ietf-sip-gruu] can be used to address problem 1. Problem
2 can be addressed using the Target-Dialog header field defined in
[RFC4538]. In the immediate term, this solution to problem 2 allows
the existing REFER authorization policy to be reused.
As a result, if the Transferee supports the target-dialog extension
and the Transferor knows the Contact URI is routable outside the
dialog, the REFER SHOULD be sent in a new dialog. If the nature of
the Contact URI is not known or if support for the target-dialog
extension is not known, the REFER SHOULD be sent inside the existing
dialog. A Transferee MUST be prepared to receive a REFER either
inside or outside a dialog. One way that a Transferor could know
that a Contact URI is routable outside a dialog is by validation
(e.g. sending an OPTIONS and receiving a response) or if it satisfies
the properties described in the GRUU specification
[I-D.ietf-sip-gruu].
This document does not prescribe the flows and examples precisely as
they are shown, but rather the flows illustrate the principles for
best practice for the transfer feature. The call flows represent
well-reviewed examples of SIP usage to implement transfer with REFER,
which are best common practice according to IETF consensus.
In most of the following examples, the Transferor is in the
atlanta.example.com domain, the Transferee is in the
biloxi.example.com, and the Transfer Target is in the
chicago.example.com domain.
6. 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
Sparks, et al. Expires September 4, 2009 [Page 7]
Internet-Draft SIP CC Transfer March 2009
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 messages. Participants SHOULD also indicate
support for Target-Dialog in the Supported header field.
The diagrams below show the first line of each message. The first
column of the figure shows the dialog 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" or
"blind transfer".
Figure 1 shows transfer when the Transferee utilizes a GRUU and
supports the target-dialog extension and indicates this to the
Transferor. As a result, the Transferor sends the REFER outside the
INVITE dialog. The Transferee is able to match this REFER to the
existing dialog using the Target-Dialog header field in the refer
which references the existing dialog.
6.1. Successful Transfer
Sparks, et al. Expires September 4, 2009 [Page 8]
Internet-Draft SIP CC Transfer March 2009
Transferor Transferee Transfer
| | Target
| INVITE F1 | |
dialog1 |<-------------------| |
| 200 OK F2 | |
dialog1 |------------------->| |
| ACK | |
dialog1 |<-------------------| |
| INVITE (hold) | |
dialog1 |------------------->| |
| 200 OK | |
dialog1 |<-------------------| |
| ACK | |
dialog1 |------------------->| |
| REFER F3 (Target-Dialog:1) |
dialog2 |------------------->| |
| 202 Accepted | |
dialog2 |<-------------------| |
| NOTIFY (100 Trying) F4 |
dialog2 |<-------------------| |
| 200 OK | |
dialog2 |------------------->| |
| | INVITE F5 |
dialog3 | |------------------->|
| | 200 OK |
dialog3 | |<-------------------|
| | ACK |
dialog3 | |------------------->|
| NOTIFY (200 OK) F6| |
dialog2 |<-------------------| |
| 200 OK | |
dialog2 |------------------->| |
| BYE | |
dialog1 |------------------->| |
| 200 OK | |
dialog1 |<-------------------| |
| | BYE |
dialog3 | |<-------------------|
| | 200 OK |
dialog3 | |------------------->|
Figure 1. Basic Transfer Call Flow.
F1 INVITE Transferee -> Transferor
INVITE sips:transferor@atlanta.example.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Sparks, et al. Expires September 4, 2009 [Page 9]
Internet-Draft SIP CC Transfer March 2009
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>
From: <sips:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Content-Type: application/sdp
Content-Length: ...
F2 200 OK Transferor -> Transferee
SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
To: <sips:transferor@atlanta.example.com>;tag=31kdl4i3k
From: <sips:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d>
Content-Type: application/sdp
Content-Length: ...
F3 REFER Transferor -> Transferee
REFER sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKna9
Max-Forwards: 70
To: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
From: <sips:transferor@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 REFER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: gruu, replaces, tdialog
Require: tdialog
Refer-To: <sips:transfertarget@chicago.example.com>
Target-Dialog: 090459243588173445;local-tag=7553452
;remote-tag=31kdl4i3k
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d>
Content-Length: 0
F4 NOTIFY Transferee -> Transferor
Sparks, et al. Expires September 4, 2009 [Page 10]
Internet-Draft SIP CC Transfer March 2009
NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>;tag=1928301774
From: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
;tag=a6c85cf
Call-ID: a84b4c76e66710
CSeq: 73 NOTIFY
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, tdialog
Event: refer
Subscription-State: active;expires=60
Content-Type: message/sipfrag
Content-Length: ...
SIP/2.0 100 Trying
F5 INVITE Transferee -> Transfer Target
INVITE sips:transfertarget@chicago.example.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas41234
Max-Forwards: 70
To: <sips:transfertarget@chicago.example.com>
From: <sips:transferee@biloxi.example.com>;tag=j3kso3iqhq
Call-ID: 90422f3sd23m4g56832034
CSeq: 521 REFER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Content-Type: application/sdp
Content-Length: ...
F6 NOTIFY Transferee -> Transferor
NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>;tag=1928301774
From: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
;tag=a6c85cf
Call-ID: a84b4c76e66710
CSeq: 74 NOTIFY
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, tdialog
Event: refer
Subscription-State: terminated;reason=noresource
Sparks, et al. Expires September 4, 2009 [Page 11]
Internet-Draft SIP CC Transfer March 2009
Content-Type: message/sipfrag
Content-Length: ...
SIP/2.0 200 OK
6.2. Transfer with Dialog Reuse
In this scenario, the Transferor does not know the properties of the
Transferee's Contact URI or does not know that the Transferee
supports the Target-Dialog header field. As a result, the REFER is
sent inside the INVITE dialog.
Sparks, et al. Expires September 4, 2009 [Page 12]
Internet-Draft SIP CC Transfer March 2009
Transferor Transferee Transfer
| | Target
| INVITE F1 | |
dialog1 |<-------------------| |
| 200 OK F2 | |
dialog1 |------------------->| |
| ACK | |
dialog1 |<-------------------| |
| INVITE (hold) | |
dialog1 |------------------->| |
| 200 OK | |
dialog1 |<-------------------| |
| ACK | |
dialog1 |------------------->| |
| REFER F3 | |
dialog1 |------------------->| |
| 202 Accepted | |
dialog1 |<-------------------| |
| NOTIFY (100 Trying) F4 |
dialog1 |<-------------------| |
| 200 OK | |
dialog1 |------------------->| |
| | INVITE F5 |
dialog2 | |------------------->|
| | 200 OK |
dialog2 | |<-------------------|
| | ACK |
dialog2 | |------------------->|
| NOTIFY (200 OK) F6| |
dialog1 |<-------------------| |
| 200 OK | |
dialog1 |------------------->| |
| BYE | |
dialog1 |------------------->| |
| 200 OK | |
dialog1 |<-------------------| |
| | BYE |
dialog2 | |<-------------------|
| | 200 OK |
dialog2 | |------------------->|
Figure 2. Transfer with Dialog Reuse.
F1 INVITE Transferee -> Transferor
INVITE sips:transferor@atlanta.example.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Sparks, et al. Expires September 4, 2009 [Page 13]
Internet-Draft SIP CC Transfer March 2009
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>
From: <sips:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sips:transferee@192.0.2.4>
Content-Type: application/sdp
Content-Length: ...
F2 200 OK Transferor -> Transferee
SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
To: <sips:transferor@atlanta.example.com>;tag=31kdl4i3k
From: <sips:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: gruu, replaces
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d>
Content-Type: application/sdp
Content-Length: ...
F3 REFER Transferor -> Transferee
REFER sips:transferee@192.0.2.4 SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKna9
Max-Forwards: 70
To: <sips:transferee@biloxi.example.com>;tag=7553452
From: <sips:transferor@atlanta.example.com>;tag=31kdl4i3k
Call-ID: 090459243588173445
CSeq: 314159 REFER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Refer-To: <sips:transfertarget@chicago.example.com>
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d>
Content-Length: 0
F4 NOTIFY Transferee -> Transferor
NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
Sparks, et al. Expires September 4, 2009 [Page 14]
Internet-Draft SIP CC Transfer March 2009
To: <sips:transferor@atlanta.example.com>;tag=31kdl4i3k
From: <sips:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29888 INVITE
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
F5 INVITE Transferee -> Transfer Target
INVITE sips:transfertarget@chicago.example.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas41234
Max-Forwards: 70
To: <sips:transfertarget@chicago.example.com>
From: <sips:transferee@biloxi.example.com>;tag=j3kso3iqhq
Call-ID: 90422f3sd23m4g56832034
CSeq: 521 REFER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sips:transferee@192.0.2.4>
Content-Type: application/sdp
Content-Length: ...
F6 NOTIFY Transferee -> Transferor
NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>;tag=31kdl4i3k
From: <sips:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29889 INVITE
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, et al. Expires September 4, 2009 [Page 15]
Internet-Draft SIP CC Transfer March 2009
6.3. 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.
6.3.1. Target Busy
Sparks, et al. Expires September 4, 2009 [Page 16]
Internet-Draft SIP CC Transfer March 2009
Transferor Transferee Transfer
| | Target
| | |
| INVITE | |
dialog1 |<-------------------| |
| 200 OK | |
dialog1 |------------------->| |
| ACK | |
dialog1 |<-------------------| |
| INVITE (hold) | |
dialog1 |------------------->| |
| 200 OK | |
dialog1 |<-------------------| |
| ACK | |
dialog1 |------------------->| |
| REFER (Target-Dialog:1) |
dialog2 |------------------->| |
| 202 Accepted | |
dialog2 |<-------------------| |
| NOTIFY (100 Trying)| |
dialog2 |<-------------------| |
| 200 OK | |
dialog2 |------------------->| |
| | INVITE |
dialog3 | |------------------->|
| | 486 Busy Here |
dialog3 | |<-------------------|
| | ACK |
dialog3 | |------------------->|
| NOTIFY (486 Busy Here) |
dialog2 |<-------------------| |
| 200 OK | |
dialog2 |------------------->| |
| INVITE (unhold) | |
dialog1 |------------------->| |
| 200 OK | |
dialog1 |<-------------------| |
| ACK | |
dialog1 |------------------->| |
| BYE | |
dialog1 |------------------->| |
| 200 OK | |
dialog1 |<-------------------| |
Figure 3. Failed Transfer - Target Busy
Sparks, et al. Expires September 4, 2009 [Page 17]
Internet-Draft SIP CC Transfer March 2009
6.3.2. Transfer Target does not answer
Transferor Transferee Transfer
| | Target
| INVITE | |
dialog1 |<-------------------| |
| 200 OK | |
dialog1 |------------------->| |
| ACK | |
dialog1 |<-------------------| |
| INVITE (hold) | |
dialog1 |------------------->| |
| 200 OK | |
dialog1 |<-------------------| |
| ACK | |
dialog1 |------------------->| |
| REFER | |
dialog2 |------------------->| |
| 202 Accepted | |
dialog2 |<-------------------| |
| NOTIFY (100 Trying)| |
dialog2 |<-------------------| |
| 200 OK | |
dialog2 |------------------->| |
| | INVITE |
dialog3 | |------------------->|
| | 180 Ringing |
dialog3 | |<-------------------|
| (Transferee gets tired of waiting)
| | CANCEL |
dialog3 | |------------------->|
| | 200 OK (CANCEL) |
dialog3 | |<-------------------|
| 487 Request Cancelled (INVITE)
dialog3 | |<-------------------|
| | ACK |
dialog3 | |------------------->|
| NOTIFY (487 Request Cancelled) |
dialog2 |<-------------------| |
| 200 OK | |
dialog2 |------------------->| |
| INVITE (unhold) | |
dialog1 |------------------->| |
| 200 OK | |
dialog1 |<-------------------| |
| ACK | |
dialog1 |------------------->| |
Sparks, et al. Expires September 4, 2009 [Page 18]
Internet-Draft SIP CC Transfer March 2009
| BYE | |
dialog1 |------------------->| |
| 200 OK | |
dialog1 |<-------------------| |
Figure 4. Failed Transfer - Target Does Not Answer.
7. 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.
A nice feature is for the transferor to let the target know that the
session relates to an intended transfer. Since many UAs render the
display name in the From header field to the user, a consultation
INVITE could contain a string such as "Incoming consultation from
Transferor with intent to transfer Transferee", where the display
names of the transferor and transferee are included in the string.
7.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, et al. Expires September 4, 2009 [Page 19]
Internet-Draft SIP CC Transfer March 2009
Transferor Transferee Transfer
| | Target
| | |
dialog1 | INVITE/200 OK/ACK | |
|<-------------------| |
dialog1 | INVITE (hold)/200 OK/ACK |
|------------------->| |
dialog2 | INVITE/200 OK/ACK | |
|---------------------------------------->|
dialog2 | BYE/200 OK | |
|---------------------------------------->|
dialog3 | REFER | |
|------------------->| |
dialog3 | 202 Accepted | |
|<-------------------| |
dialog3 | NOTIFY (100 Trying)| |
|<-------------------| |
dialog3 | 200 OK | |
|------------------->| |
dialog4 | | INVITE/200 OK/ACK |
| |------------------->|
dialog3 | NOTIFY (200 OK) | |
|<-------------------| |
dialog3 | 200 OK | |
|------------------->| |
dialog1 | BYE/200 OK | |
|------------------->| |
dialog4 | | BYE/200 OK |
| |<-------------------|
Figure 5. Transfer with Consultation Hold - Exposing Transfer
Target.
7.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
Sparks, et al. Expires September 4, 2009 [Page 20]
Internet-Draft SIP CC Transfer March 2009
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 [RFC3891] 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 [RFC3891]
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.
In this scenario, the Transferee utilizes a GRUU as a Contact URI for
reasons discussed in Section 6.3.
Note that the conventions used in the SIP Torture Test Messages
[RFC4475] document are reused, specifically the <allOneLine> tag.
Sparks, et al. Expires September 4, 2009 [Page 21]
Internet-Draft SIP CC Transfer March 2009
Transferor Transferee Transfer
| | Target
| | |
dialog1 | INVITE/200 OK/ACK F1 F2 |
|<-------------------| |
dialog1 | INVITE (hold)/200 OK/ACK |
|------------------->| |
dialog2 | INVITE/200 OK/ACK F3 F4 |
|---------------------------------------->|
dialog2 | INVITE (hold)/200 OK/ACK |
|---------------------------------------->|
dialog3 | REFER (Target-Dialog:2, |
| Refer-To:sips:Transferee?Replaces=1) F5|
|---------------------------------------->|
dialog3 | 202 Accepted | |
|<----------------------------------------|
dialog3 | NOTIFY (100 Trying)| |
|<----------------------------------------|
dialog3 | | 200 OK |
|---------------------------------------->|
dialog4 | INVITE (Replaces:dialog1)/200 OK/ACK F6
| |<-------------------|
dialog1 | BYE/200 OK | |
|<-------------------| |
dialog3 | NOTIFY (200 OK) | |
|<----------------------------------------|
dialog3 | | 200 OK |
|---------------------------------------->|
dialog2 | BYE/200 OK | |
|---------------------------------------->|
| (transferee and target converse)
dialog4 | | BYE/200 OK |
| |------------------->|
Figure 6. Transfer Protecting Transfer Target.
F1 INVITE Transferee -> Transferor
INVITE sips:transferor@atlanta.example.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>
From: <sips:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Sparks, et al. Expires September 4, 2009 [Page 22]
Internet-Draft SIP CC Transfer March 2009
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Content-Type: application/sdp
Content-Length: ...
F2 200 OK Transferor -> Transferee
SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
To: <sips:transferor@atlanta.example.com>;tag=31431
From: <sips:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d>
Content-Type: application/sdp
Content-Length: ...
F3 INVITE Transferor -> Transfer Target
INVITE sips:transfertarget@chicago.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transfertarget@chicago.example.com>
From: <sips:transferor@atlanta.example.com>;tag=763231
Call-ID: 592435881734450904
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: gruu, replaces, tdialog
Require: replaces
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=384i32lw3>
Content-Type: application/sdp
Content-Length: ...
F4 200 OK Transfer Target -> Transferor
SIP/2.0 200 OK
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432
;received=192.0.2.1
To: <sips:transfertarget@chicago.example.com>;tag=9m2n3wq
From: <sips:transferor@atlanta.example.com>;tag=763231
Call-ID: 592435881734450904
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Sparks, et al. Expires September 4, 2009 [Page 23]
Internet-Draft SIP CC Transfer March 2009
Contact: <sips:482n4z24kdg@chicago.example.com;gr=8594958>
Content-Type: application/sdp
Content-Length: ...
F5 REFER Transferor -> Transfer Target
REFER sips:482n4z24kdg@chicago.example.com;gr=8594958 SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9
Max-Forwards: 70
To: <sips:482n4z24kdg@chicago.example.com;gr=8594958>
From: <sips:transferor@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 REFER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: gruu, replaces, tdialog
Require: tdialog
<allOneLine>
Refer-To: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha
?Replaces=090459243588173445%3Bto-tag%3D7553452%3Bfrom-tag%3D31431>
</allOneLine>
Target-Dialog: 592435881734450904;local-tag=9m2n3wq
;remote-tag=763231
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d>
Content-Length: 0
F6 INVITE Transfer Target -> Transferee
INVITE sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0
Via: SIP/2.0/TLS client.chicago.example.com;branch=z9hG4bKnaslu84
Max-Forwards: 70
To: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
From: <sips:transfertarget@chicago.example.com>;tag=341234
Call-ID: kmzwdle3dl3d08
CSeq: 41 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: gruu, replaces, tdialog
Contact: <sips:482n4z24kdg@chicago.example.com;gr=8594958>
Replaces: 090459243588173445;to-tag=7553452;from-tag=31431
Content-Type: application/sdp
Content-Length: ...
Sparks, et al. Expires September 4, 2009 [Page 24]
Internet-Draft SIP CC Transfer March 2009
7.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.
The Contact URI of the Transfer Target SHOULD be used by the
Transferor as the Refer-To URI, unless the URI is suspected or known
to not be routable outside the dialog. Otherwise, the Address of
Record (AOR) of the Transfer Target SHOULD be used. That is, the
same URI that the Transferor used to establish the session with the
Transfer Target should be used. In case the triggered INVITE is
routed to a different User Agent than the Transfer Target, the
Require: replaces header field SHOULD be used in the triggered
INVITE. (This is to prevent an incorrect User Agent which does not
support Replaces from ignoring the Replaces and answering the INVITE
without a dialog match.)
It is possible that proxy/service routing may prevent the triggered
INVITE from reaching the same User Agent. If this occurs, the
triggered invite will fail with a timout, 403, 404, etc error. The
Transferee MAY then retry the transfer with the Refer-To URI set to
the Contact URI.
Sparks, et al. Expires September 4, 2009 [Page 25]
Internet-Draft SIP CC Transfer March 2009
Transferor Transferee Transfer
| | Target
| | |
dialog1 | INVITE/200 OK/ACK F1 F2 |
|<-------------------| |
dialog1 | INVITE (hold)/200 OK/ACK |
|------------------->| |
dialog2 | INVITE/200 OK/ACK F3 F4 |
|---------------------------------------->|
dialog2 | INVITE (hold)/200 OK/ACK |
|---------------------------------------->|
dialog3 | REFER (Target-Dialog:1, |
| Refer-To:sips:TransferTarget?Replaces=2) F5
|------------------->| |
dialog3 | 202 Accepted | |
|<-------------------| |
dialog3 | NOTIFY (100 Trying)| |
|<-------------------| |
dialog3 | 200 OK | |
|------------------->| |
dialog4 | INVITE (Replaces:dialog2)/200 OK/ACK F6
| |------------------->|
dialog2 | BYE/200 OK | |
|<----------------------------------------|
dialog3 | NOTIFY (200 OK) | |
|<-------------------| |
dialog3 | 200 OK | |
|------------------->| |
dialog1 | BYE/200 OK | |
|------------------->| |
dialog4 | | BYE/200 OK |
| |<-------------------|
Figure 7. Attended Transfer Call Flow.
F1 INVITE Transferee -> Transferor
INVITE sips:transferor@atlanta.example.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>
From: <sips:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Sparks, et al. Expires September 4, 2009 [Page 26]
Internet-Draft SIP CC Transfer March 2009
Content-Type: application/sdp
Content-Length: ...
F2 200 OK Transferor -> Transferee
SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
To: <sips:transferor@atlanta.example.com>;tag=31431
From: <sips:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d>
Content-Type: application/sdp
Content-Length: ...
F3 INVITE Transferor -> Transfer Target
INVITE sips:transfertarget@chicago.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transfertarget@chicago.example.com>
From: <sips:transferor@atlanta.example.com>;tag=763231
Call-ID: 592435881734450904
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: gruu, replaces, tdialog
Require: replaces
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=384i32lw3>
Content-Type: application/sdp
Content-Length: ...
F4 200 OK Transfer Target -> Transferor
SIP/2.0 200 OK
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432
;received=192.0.2.1
To: <sips:transfertarget@chicago.example.com>;tag=9m2n3wq
From: <sips:transferor@atlanta.example.com>;tag=763231
Call-ID: 592435881734450904
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Contact: <sips:482n4z24kdg@chicago.example.com;gr=8594958>
Sparks, et al. Expires September 4, 2009 [Page 27]
Internet-Draft SIP CC Transfer March 2009
Content-Type: application/sdp
Content-Length: ...
F5 REFER Transferor -> Transferee
REFER sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9
Max-Forwards: 70
To: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
From: <sips:transferor@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 REFER
Require: tdialog
<allOneLine>
Refer-To: <sips:482n4z24kdg@chicago.example.com;gr=8594958?
Replaces=592435881734450904%3Bto-tag%3D9m2n3wq%3Bfrom-tag3D763231>
</allOneLine>
Target-Dialog: 592435881734450904;local-tag=9m2n3wq
;remote-tag=763231
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d>
Content-Length: 0
F6 INVITE Transferee -> Transfer Target
INVITE sips:482n4z24kdg@chicago.example.com;gr=8594958 SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnaslu82
Max-Forwards: 70
To: <sips:482n4z24kdg@chicago.example.com;gr=8594958>
From: <sips:transferee@biloxi.example.com>;tag=954
Call-ID: kmzwdle3dl3d08
CSeq: 41 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: gruu, replaces, tdialog
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Replaces: 592435881734450904;to-tag=9m2n3wq;from-tag=763231
Content-Type: application/sdp
Content-Length: ...
7.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.
Sparks, et al. Expires September 4, 2009 [Page 28]
Internet-Draft SIP CC Transfer March 2009
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 |
|---------------------------------------->|
dialog3 | REFER (Target-Dialog:1, |
| Refer-To:sips:TransferTarget?Replaces=2)
|------------------->| |
dialog3 | 501 Not Implemented |
|<-------------------| |
dialog4 | REFER (Refer-To:sips:Transferee?Replaces=dialog1)
|---------------------------------------->|
dialog4 | 202 Accepted | |
|<----------------------------------------|
dialog4 | NOTIFY (100 Trying)| |
|<----------------------------------------|
dialog4 | | 200 OK |
|---------------------------------------->|
dialog5 | INVITE (Replaces:dialog1)/200 OK/ACK
| |<-------------------|
dialog4 | NOTIFY (200 OK) | |
|<----------------------------------------|
dialog4 | | 200 OK |
|---------------------------------------->|
dialog1 | BYE/200 OK | |
|<-------------------| |
dialog2 | BYE/200 OK | |
|---------------------------------------->|
dialog5 | | BYE/200 OK |
| |------------------->|
Figure 8. Recovery when one party does not support REFER.
7.5. Attended transfer when Contact URI is not known to route to a
unique user agent.
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, 7, and 8 SHOULD
only be used if the Contact URI is known to be routable outside the
Sparks, et al. Expires September 4, 2009 [Page 29]
Internet-Draft SIP CC Transfer March 2009
dialog.
Figure 9 shows such a scenario where the Transfer Target Contact URI
is not routable outside the dialog, so the triggered INVITE is sent
to the AOR of the Transfer Target.
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 |
|--------------------------------|------------>|
dialog1 | REFER (Refer-To:sips:TargetAOR |
| ?Replaces=dialog2&Require=replaces) F3
|----------------->| | |
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 9. Attended Transfer Call Flow with a Contact URI not known
to be Globally Routable
F1 INVITE Transferor -> Transfer Target
INVITE sips:transfertarget@chicago.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK76
Max-Forwards: 70
Sparks, et al. Expires September 4, 2009 [Page 30]
Internet-Draft SIP CC Transfer March 2009
To: <sips:transfertarget@chicago.example.com>
From: <sips:transferor@atlanta.example.com>;tag=763231
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sips: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/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432
;received=192.0.2.1
To: <sips:transfertarget@chicago.example.com>;tag=9m2n3wq
From: <sips:transferor@atlanta.example.com>;tag=763231
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sips:transfertarget@client.chicago.example.com>
Content-Type: application/sdp
Content-Length: ...
F3 REFER Transferor -> Transferee
REFER sips:transferee@192.0.2.4 SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9
Max-Forwards: 70
To: <sips:transferee@biloxi.example.com>;tag=a6c85cf
From: <sips:transferor@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 REFER
<allOneLine>
Refer-To: <sips:transfertarget@chicago.example.com?Replaces=
090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-tag%3D763231
&Require=replaces>
<allOneLine>
Contact: <sips:transferor@pc33.atlanta.example.com>
Content-Length: 0
F4 INVITE Transferee -> Transfer Target
INVITE sips:transfertarget@chicago.example.com SIP/2.0
Sparks, et al. Expires September 4, 2009 [Page 31]
Internet-Draft SIP CC Transfer March 2009
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnaslu82
Max-Forwards: 70
To: <sips:transfertarget@chicago.example.com>
From: <sips:transferee@biloxi.example.com>;tag=954
Call-ID: 20482817324945934422930
CSeq: 42 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sips:transferee@192.0.2.4>
Replaces: 090459243588173445;to-tag=9m2n3wq;from-tag=763231
Require: replaces
Content-Type: application/sdp
Content-Length: ...
F5 NOTIFY Transferee -> Transferor
NOTIFY sips:transferor@pc33.atlanta.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>;tag=1928301774
From: <sips: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
Figure 10 shows a failure case in which the AOR URI fails to reach
the transfer Target. As a result, the transfer is retried with the
Contact URI which succeeds.
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.
Sparks, et al. Expires September 4, 2009 [Page 32]
Internet-Draft SIP CC Transfer March 2009
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 |
|--------------------------------|------------>|
dialog1 | REFER (Refer-To:sips:TargetAOR? |
| Replaces=dialog2&Require=replaces) F3 |
|----------------->| | |
dialog1 | 202 Accepted | | |
|<-----------------| | |
dialog1 | NOTIFY (100 Trying) | |
|<-----------------| | |
dialog1 | 200 OK | | |
|----------------->| | |
dialog3 | |INVITE (Replaces:dialog2, |
| | Require:replaces)/403/ACK |
| |------------>| |
dialog1 | NOTIFY (403 Forbidden) F4 | |
|<-----------------| | |
dialog1 | 200 OK | | |
|----------------->| | |
dialog1 |REFER(Refer-To:sips:TargetContact?Replaces=dialog2) F5
|----------------->| | |
dialog1 | 202 Accepted | | |
|<-----------------| | |
dialog1 | NOTIFY (100 Trying) | |
|<-----------------| | |
dialog1 | 200 OK | | |
|----------------->| | |
dialog4 | INVITE (Replaces:dialog2)/200 OK/ACK F6
| |------------>|------------>|
dialog2 | BYE/200 OK | | |
|<-------------------------------|<------------|
dialog1 | NOTIFY (200 OK) F7 | |
|<-----------------| | |
dialog1 | 200 OK | | |
|----------------->| | |
dialog1 | BYE/200 OK | | |
|----------------->| | |
dialog3 | | | BYE/200 OK |
| |<------------|-------------|
Sparks, et al. Expires September 4, 2009 [Page 33]
Internet-Draft SIP CC Transfer March 2009
Figure 10. Attended Transfer Call Flow with non-routable Contact URI
and AOR Failure
F1 INVITE Transferor -> Transfer Target
INVITE sips:transfertarget@chicago.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK76
Max-Forwards: 70
To: <sips:transfertarget@chicago.example.com>
From: <sips:transferor@atlanta.example.com>;tag=763231
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sips: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/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432
;received=192.0.2.1
To: <sips:transfertarget@chicago.example.com>;tag=9m2n3wq
From: <sips:transferor@atlanta.example.com>;tag=763231
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sips:transfertarget@client.chicago.example.com>
Content-Type: application/sdp
Content-Length: ...
F3 REFER Transferor -> Transferee
REFER sips:transferee@192.0.2.4 SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9
Max-Forwards: 70
To: <sips:transferee@biloxi.example.com>;tag=a6c85cf
From: <sips:transferor@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 REFER
<allOneLine>
Refer-To: <sips:transfertarget@chicago.example.com?Replaces=
090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-tag%3D763231
Sparks, et al. Expires September 4, 2009 [Page 34]
Internet-Draft SIP CC Transfer March 2009
&Require=replaces>
</allOneLine>
Contact: <sips:transferor@pc33.atlanta.example.com>
Content-Length: 0
F4 NOTIFY Transferee -> Transferor
NOTIFY sips:transferor@pc33.atlanta.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>;tag=1928301774
From: <sips:transferee@biloxi.example.com>;tag=a6c85cf
Call-ID: a84b4c76e66710
CSeq: 74 NOTIFY
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Event: refer;id=314159
Subscription-State: terminated;reason=noresource
Content-Type: message/sipfrag
Content-Length: ...
SIP/2.0 403 Forbidden
F5 REFER Transferor -> Transferee
REFER sips:transferee@192.0.2.4 SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9
Max-Forwards: 70
To: <sips:transferee@biloxi.example.com>;tag=a6c85cf
From: <sips:transferor@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 REFER
<allOneLine>
Refer-To: <sips:transfertarget@client.chicago.example.com
?Replaces=090459243588173445%3Bto-tag%3D9m2n3wq
%3Bfrom-tag%3D763231>
</allOneLine>
Contact: <sips:transferor@pc33.atlanta.example.com>
Content-Length: 0
F6 INVITE Transferee -> Transfer Target
INVITE sips:transfertarget@client.chicago.example.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnaslu82
Max-Forwards: 70
Sparks, et al. Expires September 4, 2009 [Page 35]
Internet-Draft SIP CC Transfer March 2009
To: <sips:transfertarget@chicago.example.com>
From: <sips:transferee@biloxi.example.com>;tag=954
Call-ID: 20482817324945934422930
CSeq: 42 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sips:transferee@192.0.2.4>
Replaces: 090459243588173445;to-tag=9m2n3wq;from-tag=763231
Content-Type: application/sdp
Content-Length: ...
F7 NOTIFY Transferee -> Transferor
NOTIFY sips:transferor@pc33.atlanta.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>;tag=1928301774
From: <sips: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=314160
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
use a Contact URI which is routable outside the dialog, which will
result in the call flow of Figure 7.
7.6. Semi-Attended Transfer
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, the Transferor 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 call flow is shown in Figure
11. In this flow, the Transferor's User Agent continues the transfer
Sparks, et al. Expires September 4, 2009 [Page 36]
Internet-Draft SIP CC Transfer March 2009
as an attended transfer even after the Transferor hangs up. Note
that media must be played to the Transfer Target upon answer -
otherwise, the Target may hang up and the resulting transfer
operation will fail.
Transferor Transferee Transfer
| | Target
| | |
dialog1 | INVITE/200 OK/ACK F1 F2 |
|<-------------------| |
dialog1 | INVITE (hold)/200 OK/ACK |
|------------------->| |
dialog2 | INVITE | |
|---------------------------------------->|
dialog2 | | 180 Ringing |
|<----------------------------------------|
Transferor hangs up but wants transfer to continue
| | |
| User Agent continues transfer operation |
| | |
dialog2 | | 200 OK |
|<----------------------------------------|
dialog2 | ACK | |
|---------------------------------------->|
dialog2 | Media Played to keep Target from hanging up
|========================================>|
dialog3 | REFER (Target-Dialog:1, |
| Refer-To:sips:TransferTarget?Replaces=2)
|------------------->| |
dialog3 | 202 Accepted | |
|<-------------------| |
dialog3 | NOTIFY (100 Trying)| |
|<-------------------| |
dialog3 | 200 OK | |
|------------------->| |
dialog4 | INVITE (Replaces:dialog2)/200 OK/ACK
| |------------------->|
dialog2 | BYE/200 OK | |
|<----------------------------------------|
dialog3 | NOTIFY (200 OK) | |
|<-------------------| |
dialog3 | 200 OK | |
|------------------->| |
dialog1 | BYE/200 OK | |
|------------------->| |
dialog4 | | BYE/200 OK |
| |<-------------------|
Sparks, et al. Expires September 4, 2009 [Page 37]
Internet-Draft SIP CC Transfer March 2009
Figure 11. Recommended Semi-Attended Transfer Call Flow.
Two other possible semi-attended transfer call flows are shown in
Figures 12 and 13. However, these call flows are NOT RECOMMENDED due
to a race conditions. In both of these flows, when the Transferor
hangs up, the Transferor attempts to revert to unattended transfer by
sending a CANCEL to the Target. This can result in two race
conditions. One is that the Target answers despite the CANCEL and
the resulting unattended transfer fails. This race condition can be
eliminated by the Transferor waiting to send the REFER until the 487
response from the Target is returned. Instead of a 487, a 200 OK may
return indicating that the Target has answered the consultation call.
In this, case the call flow in Figure 13 must be followed. In this
flow, the Transferor must play some kind of media to the Target to
prevent the Target from hanging up, or the Transfer will fail. That
is, the human at the Transfer Target will hear silence from when they
answer (message F1) until the transfer completes (F3 and they are
talking to the Transferee unless some media is played (F2).
The second race condition occurs in Figure 12 if the Transfer Target
goes "off hook" after the CANCEL is received and the 487 returned.
This may result in a 486 Busy Here response to the unattended
transfer.
The recommended call flow of Figure 11 does not utilize a CANCEL and
does not suffer from these race conditions.
Sparks, et al. Expires September 4, 2009 [Page 38]
Internet-Draft SIP CC Transfer March 2009
Transferor Transferee Transfer
| | Target
| | |
dialog1 | INVITE/200 OK/ACK | |
|<-------------------| |
dialog1 | INVITE (hold)/200 OK/ACK |
|------------------->| |
dialog2 | INVITE |
|---------------------------------------->|
dialog2 | 180 Ringing |
|<----------------------------------------|
| |
| Transferor gives up waiting |
| |
dialog2 | CANCEL |
|---------------------------------------->|
dialog2 | 200 OK |
|<----------------------------------------|
dialog2 | 487 Request Terminated |
|<----------------------------------------|
dialog2 | ACK |
|---------------------------------------->|
dialog3 | REFER (Target-Dialog:1) F3 |
|------------------->| |
dialog3 | 202 Accepted | |
|<-------------------| |
dialog3 | NOTIFY (100 Trying)| |
|<-------------------| |
dialog3 | 200 OK | |
|------------------->| |
dialog4 | INVITE/200 OK/ACK |
| |------------------->|
dialog3 | NOTIFY (200 OK) | |
|<-------------------| |
dialog3 | 200 OK | |
|------------------->| |
dialog1 | BYE/200 OK | |
|------------------->| |
dialog4 | | BYE/200 OK |
| |<-------------------|
Figure 12. Semi-Attended Transfer as Blind Transfer Call Flow. (Not
Recommended)
Sparks, et al. Expires September 4, 2009 [Page 39]
Internet-Draft SIP CC Transfer March 2009
Transferor Transferee Transfer
| | Target
| | |
dialog1 | INVITE/200 OK/ACK | |
|<-------------------| |
dialog1 | INVITE (hold)/200 OK/ACK |
|------------------->| |
dialog2 | INVITE |
|---------------------------------------->|
dialog2 | 180 Ringing |
|<----------------------------------------|
| |
|Transferor gives up waiting but Target answers
| |
dialog2 | CANCEL |
|---------------------------------------->|
dialog2 | 200 OK (CANCEL) |
|<----------------------------------------|
dialog2 | 200 OK (INVITE) F1 |
|<----------------------------------------|
dialog2 | ACK |
|---------------------------------------->|
dialog2 | INVITE (hold)/200 OK/ACK |
|---------------------------------------->|
| Tones or media played avoid silence F2 |
|========================================>|
dialog1 |REFER (Refer-To:sips:TransferTarget |
| ?Replaces=dialog2) |
|------------------->| |
dialog1 | 202 Accepted | |
|<-------------------| |
dialog1 | NOTIFY (100 Trying)| |
|<-------------------| |
dialog1 | 200 OK | |
|------------------->| |
dialog3 | INVITE (Replaces:dialog2)/200 OK/ACK F3
| |------------------->|
dialog2 | BYE/200 OK | |
|<----------------------------------------|
dialog1 | NOTIFY (200 OK) | |
|<-------------------| |
dialog1 | 200 OK | |
|------------------->| |
dialog1 | BYE/200 OK | |
|------------------->| |
dialog3 | | BYE/200 OK |
| |<-------------------|
Sparks, et al. Expires September 4, 2009 [Page 40]
Internet-Draft SIP CC Transfer March 2009
Figure 13. Semi-Attended Transfer as Attended Transfer Call Flow.
(Not Recommended)
7.7. Attended Transfer Fallback to Basic Transfer
In this flow, an attempted attended transfer fails so the transferor
falls back to basic transfer.
The call flow in Figure 14 shows the use of Require: replaces in the
INVITE sent by the Transferor to the Transfer Target in which the
Transferor's intention at the time of sending the INVITE to the
Transfer Target was known to be to complete an attended transfer.
Since the Target does not support Replaces, the INVITE is rejected
with a 420 Bad Extension response, and the Transferor switches from
attended transfer to basic transfer immediately.
Transferor Transferee Transfer
| | Target
| | |
dialog1 | INVITE/200 OK/ACK | |
|<-------------------| |
dialog1 | OPTIONS/200 OK | |
|------------------->| |
dialog1 | INVITE (hold)/200 OK/ACK |
|------------------->| |
dialog2 | INVITE (Require:replaces) |
|---------------------------------------->|
dialog2 | 420 Bad Extension |
|<----------------------------------------|
dialog2 | ACK |
|---------------------------------------->|
dialog1 | REFER (Refer-To:sips: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 |
Sparks, et al. Expires September 4, 2009 [Page 41]
Internet-Draft SIP CC Transfer March 2009
| |<-------------------|
Figure 14. Attended Transfer Fallback to Basic Transfer using
Require:replaces.
Figure 15 shows the use of OPTIONS when the Transferee and Transfer
Target do not explicitly indicate support for the REFER method and
Replaces header fields in Allow and Supported header fields and the
Transferor did not have the intention of performing an attended
transfer when the INVITE to the Target was sent. 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. The Transferor then ends dialog2 by sending a
BYE then sends a REFER to the Transferee using the AOR URI of the
Transfer Target.
Sparks, et al. Expires September 4, 2009 [Page 42]
Internet-Draft SIP CC Transfer March 2009
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 | |
|---------------------------------------->|
dialog3 |REFER (Target-Dialog:1, |
| Refer-To:sips:TransferTarget) |
|------------------->| |
dialog3 | 202 Accepted | |
|<-------------------| |
dialog3 | NOTIFY (100 Trying)| |
|<-------------------| |
dialog3 | 200 OK | |
|------------------->| |
dialog4 | | INVITE/200 OK/ACK |
| |------------------->|
dialog3 | NOTIFY (200 OK) | |
|<-------------------| |
dialog3 | 200 OK | |
|------------------->| |
dialog1 | BYE/200 OK | |
|------------------->| |
dialog4 | | BYE/200 OK |
| |<-------------------|
Figure 15. Attended Transfer Fallback to Basic Transfer.
8. 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 [RFC3892] 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
Sparks, et al. Expires September 4, 2009 [Page 43]
Internet-Draft SIP CC Transfer March 2009
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 is shown in Figure 16 showing the Referred-By header
field and body in the REFER F5 and triggered INVITE F6. Note that
the S/MIME signature is not shown in the example below. The
conventions used in the SIP Torture Test Messages [RFC4475] document
are reused, specifically the <hex> and <allOneLine> tags.
Transferor Transferee Transfer
| | Target
| | |
dialog1 | INVITE/200 OK/ACK F1 F2 |
|<-------------------| |
dialog1 | INVITE (hold)/200 OK/ACK |
|------------------->| |
dialog2 | INVITE/200 OK/ACK F3 F4 |
|---------------------------------------->|
dialog2 | INVITE (hold)/200 OK/ACK |
|---------------------------------------->|
dialog3 | REFER (Target-Dialog:1, Referred-By:Transferor,
| Refer-To:sips:TransferTarget?Replaces=2) F5
|------------------->| |
dialog3 | 202 Accepted | |
|<-------------------| |
dialog3 | NOTIFY (100 Trying)| |
|<-------------------| |
dialog3 | 200 OK | |
|------------------->| |
dialog4 | INVITE (Replaces:dialog2, |
| Referred-By:Transferor )/200 OK/ACK F6
| |------------------->|
dialog2 | BYE/200 OK | |
|<----------------------------------------|
dialog3 | NOTIFY (200 OK) | |
|<-------------------| |
dialog3 | 200 OK | |
|------------------->| |
dialog1 | BYE/200 OK | |
|------------------->| |
dialog4 | | BYE/200 OK |
| |<-------------------|
Figure 16. Attended Transfer Call Flow with Referred-By.
Sparks, et al. Expires September 4, 2009 [Page 44]
Internet-Draft SIP CC Transfer March 2009
F5 REFER Transferor -> Transferee
REFER sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK392039842
Max-Forwards: 70
To: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
From: <sips:transferor@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 REFER
<allOneLine>
Refer-To: <sips:482n4z24kdg@chicago.example.com;gr=8594958
?Replaces=090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-tag
%3D763231&Require=replaces>
</allOneLine>
Supported: gruu, replaces, tdialog
Require: tdialog
Referred-By: <sips:transferor@atlanta.example.com>
;cid="20398823.2UWQFN309shb3@atlanta.example.com"
Target-Dialog: 592435881734450904;local-tag=9m2n3wq;remote-tag=763231
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d>
Content-Type: multipart/mixed; boundary=unique-boundary-1
Content-Length: ...
--unique-boundary-1
Content-ID: <20398823.2UWQFN309shb3@atlanta.example.com>
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: <sips:482n4z24kdg@chicago.example.com;gr=8594958
?Replaces=090459243588173445%3B
to-tag%3D9m2n3wq%3Bfrom-tag%3D763231&Require=replaces>
</allOneLine>
Referred-By: <sips:transferor@atlanta.example.com>
;cid="20398823.2UWQFN309shb3@atlanta.example.com"
------590F24D439B31E08745DEF0CD9397189
Content-Type: application/pkcs-7-signature; name="smime.p7s"
Sparks, et al. Expires September 4, 2009 [Page 45]
Internet-Draft SIP CC Transfer March 2009
Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename="smime.p7s"
<hex>3082088806092A86
4886F70D010702A082087930820875020101310B300906052B0E03021A050030
. . . (Signature not shown)
8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B428388966
79089AAD95767F</hex>
------590F24D439B31E08745DEF0CD9397189--
--unique_boundary-1
F6 INVITE Transferee -> Transfer Target
INVITE sips:482n4z24kdg@chicago.example.com;gr=8594958 SIP/2.0
Via: SIP/2.0/TLS referee.example;branch=z9hG4bKffe209934aac
To: <sips:482n4z24kdg@chicago.example.com;gr=8594958>
From: <sips:transferee@biloxi.example.com>;tag=2909034023
Call-ID: fe9023940-a3465@referee.example
CSeq: 889823409 INVITE
Max-Forwards: 70
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Referred-By: <sips:transferor@atlanta.example.com>
;cid="20398823.2UWQFN309shb3@atlanta.example.com"
Replaces:090459243588173445;to-tag=9m2n3wq;from-
tag=76323
Require: replaces
Supported: gruu, replaces, tdialog
Content-Type: multipart/mixed; boundary=my-boundary-9
Content-Length: ...
--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
Sparks, et al. Expires September 4, 2009 [Page 46]
Internet-Draft SIP CC Transfer March 2009
--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: <sips:transfertarget@chicago.example.com;
Replaces=090459243588173445%3B
to-tag%3D9m2n3wq%3Bfrom-tag%3D763231&Require=replaces>
</allOneLine>
Referred-By: <sips: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
. . . (Signature not shown)
8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B428388966
79089AAD95767F</hex>
------590F24D439B31E08745DEF0CD9397189--
--my-boundary-9--
9. Transfer as an Ad-Hoc Conference
In this flow, shown in Figure 17, Bob does an attended transfer of
Alice to Carol. In order to keep both Alice and Carol fully informed
of the nature and state of the transfer operation, Bob acts as a
focus[RFC4579] and hosts an ad-hoc conference involving Alice, Bob,
and Carol. Alice and Carol subscribe to the conference
package[RFC4575] of Bob's focus, which allows them to know the exact
status of the operation. After the transfer operation is complete,
Sparks, et al. Expires September 4, 2009 [Page 47]
Internet-Draft SIP CC Transfer March 2009
Bob deletes the conference.
This call flow meets requirement 6 of Section 3. NOTIFY messages
related to the refer package are indicated as NOTIFY (refer), while
NOTIFYs related to the Conference Info package are indicated as
NOTIFY (Conf-Info).
Note that any type of semi-attended transfer in which media mixing or
relaying could be implemented using this model. In addition to
simply mixing, the focus could introduce additional media signals
such as simulated ring tone or on hold announcements to improve the
user experience.
Alice Bob Carol
| | |
| INVITE | |
|------------------->| |
| 180 Ringing | |
|<-------------------| |
| 200 OK | |
|<-------------------| |
| ACK | |
|------------------->| |
| RTP | |
|<==================>| |
| | |
Bob places Alice on hold and begins acting like a focus
| | |
| INVITE (hold) Contact:Conf-ID;isfocus |
|<-------------------| |
| 200 OK | |
|------------------->| |
| ACK | |
|<-------------------| |
| | |
| Alice subscribes to the conference package
| | |
| SUBSCRIBE sip:Conf-ID |
|------------------->| |
| 200 OK | |
|<-------------------| |
| NOTIFY (Conf-Info) | |
|<-------------------| |
| 200 OK | |
|------------------->| |
| | |
| Bob begins consultation operation |
| | |
Sparks, et al. Expires September 4, 2009 [Page 48]
Internet-Draft SIP CC Transfer March 2009
|INVITE Require:replaces Contact:Conf-ID;isfocus
| |------------------->|
| | 180 Ringing |
| |<-------------------|
| | 200 OK |
| |<-------------------|
| | ACK |
| |------------------->|
| | RTP |
| |<==================>|
| | |
|Carol subscribes to the conference package
| - learns Bob is on hold |
| | |
| |SUBSCRIBE sip:Conf-ID
| |<-------------------|
| | 200 OK |
| |------------------->|
| | NOTIFY (Conf-Info) |
| |------------------->|
| | 200 OK |
| |<-------------------|
| | |
| Alice learns that Bob is talking to Carol
| | |
| NOTIFY (Conf-Info) | |
|<-------------------| |
| 200 OK | |
|------------------->| |
| | INVITE (hold) |
| |------------------->|
| | 200 OK |
| |<-------------------|
| | ACK |
| |------------------->|
| | |
| Alice learns that Carol is now on hold |
| | |
| NOTIFY (Conf-Info) | |
|<-------------------| |
| 200 OK | |
|------------------->| |
| | |
| Bob begins transfer operation |
| | |
| REFER Refer-To: Carol |
|<-------------------| |
| 202 Accepted | |
Sparks, et al. Expires September 4, 2009 [Page 49]
Internet-Draft SIP CC Transfer March 2009
|------------------->| |
| NOTIFY (Refer) | |
|------------------->| |
| 200 OK | |
|<-------------------| |
| INVITE Replaces:B-C Contact:Alice |
|---------------------------------------->|
| 200 OK |
|<----------------------------------------|
| ACK |
|---------------------------------------->|
| RTP |
|<=======================================>|
| | BYE |
| |<-------------------|
| | 200 OK |
| |------------------->|
| NOTIFY (Refer) | |
|------------------->| |
| 200 OK | |
|<-------------------| |
| | |
| Bob terminates the ad-hoc conference |
| | |
| BYE | |
|<-------------------| |
| 200 OK | |
|------------------->| |
| | NOTIFY (Conf-Info) |
| |------------------->|
| | 200 OK |
| |<-------------------|
| NOTIFY (Conf-Info) | |
|<-------------------| |
| 200 OK | |
|------------------->| |
Figure 17. Attended Transfer as an Ad-Hoc Conference.
10. Transfer with multiple parties
In this example shown in Figure 18, the Originator places call to the
Facilitator who reaches the Recipient through the Screener. The
Sparks, et al. Expires September 4, 2009 [Page 50]
Internet-Draft SIP CC Transfer March 2009
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
| | | |
1 |INVITE/200 OK/ACK | |"Get Fred for me!"
|----------->| | | "Right away!"
2 |INVITE (hold)/200 OK/ACK | |
|<-----------| | |
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
| | |--------->|
4 | |REFER | |
| |<-----------| |
4 | |202 Accepted| |
| |----------->| |
4 | |NOTIFY (100 Trying) |
| |----------->| |
4 | |200 OK | |
| |<-----------| |
5 | |INVITE/200 OK/ACK |
| |---------------------->|"This is Fred"
4 | |NOTIFY (200 OK) | "Please hold for
| |----------->| | Mary"
4 | |200 OK | |
| |<-----------| |
2 | |BYE/200 OK | |
| |<-----------| |
3 | | |BYE/200 OK|
| | |--------->|
5 | |INVITE (hold)/200 OK/ACK
| |---------------------->|
6 |REFER | | |
|<-----------| | |
6 |202 Accepted| | |
|----------->| | |
6 |NOTIFY (100 Trying) | |
|----------->| | |
6 |200 OK | | |
Sparks, et al. Expires September 4, 2009 [Page 51]
Internet-Draft SIP CC Transfer March 2009
|<-----------| | |
7 |INVITE/200 OK/ACK | |
|----------------------------------->| "Hey Fred"
6 |NOTIFY (200 OK) | | "Hello Mary"
|----------->| | |
6 |200 OK | | |
|<-----------| | |
1 |BYE/200 OK | | |
|<-----------| | |
5 | |BYE/200 OK | |
| |---------------------->|
7 |BYE/200 OK | | |
|<-----------------------------------| "See you later"
Figure 18. Transfer with Multiple Parties Example.
11. Gateway Transfer Issues
A gateway in SIP acts as a User Agent. As a result, the entire
preceding discussion and call flows apply equally well to gateways as
native SIP endpoints. However, there are some gateway specific
issues that are documented in this section. While this discussion
focuses on the common cases involving PSTN gateways, similar
situations exist for other gateways, such as H.323/SIP gateways.
11.1. Coerce Gateway Hairpins to the Same Gateway
To illustrate how a hairpin situation can occur in transfer, consider
this example. The original call dialog is setup with the transferee
residing on the PSTN side of a SIP gateway. The transferor is a SIP
phone purely in the IP space. The transfer target is on the PSTN
side of a SIP gateway as well. After completing the transfer,
(regardless of consultative or blind) the transferee is in a call
with the transfer target (both on the PSTN side of a gateway). It is
often desirable to remove the gateway(s) out of the loop. This is
likely to only be possible if both legs of the target call are on the
same gateway. With both legs on the same gateway, it may be able to
invoke the analogous transfer on the PSTN side. Then the target call
would not involve the gateway.
So the problem is how to give the proxy enough information so that it
knows to route the call to the same gateway. With a simple single
call that hairpins, the incoming and outgoing leg have the same
dialog. The proxy should have enough information to optimize the
routing.
In the consultative transfer scenario, it is desirable to coerce the
Sparks, et al. Expires September 4, 2009 [Page 52]
Internet-Draft SIP CC Transfer March 2009
consultative INVITE out the same gateway as the original call to be
transferred. However there is no way to relate the consultation with
the original call. In the consultative case the target call INVITE
includes the Replaces header which contains dialog information that
can be used to relate it to the consultation. However there is no
information that relates the target call to the original.
In the blind transfer scenario, it is desirable to coerce the target
call onto the same gateway as the original call. However the same
problem exists in that the target dialog cannot be related to the
original dialog.
In either transfer scenario, it may be desirable to push the transfer
operation onto the non-SIP side of the gateway. Presumably this is
not possible unless all of the legs go out the same gateway. If the
gateway supports more than one truck group, it might also be
necessary to get all of the legs on the same trunk group in order to
perform the transfer on the non-SIP side of the gateway.
Solutions to these gateway specific issues may involve new extensions
to SIP in the future.
11.2. Consultative Turned Blind Gateway Glare
In the consultative transfer case turned blind, there is a glare-like
problem. The transferor initiates the consultation INVITE, the
transferor gets impatient and hangs up, transitioning this to a blind
transfer. The transfer target on the gateway (connected through a
PSTN switch to a single line or dumb analog phone) rings. The user
answers the phone just after the CANCEL is received by the transfer
target. The REFER and INVITE for the target call are sent. The
transferee attempts to setup the call on the PSTN side, but gets
either a busy or lands in the users voicemail as the user has the
handset in hand and off hook.
This is another example of a race condition that this call flow can
cause. The recommended behavior is to use the approach described in
Section 6.6.
12. IANA Considerations
None.
13. Security Considerations
The call transfer flows shown in this document are implemented using
Sparks, et al. Expires September 4, 2009 [Page 53]
Internet-Draft SIP CC Transfer March 2009
the REFER and Replaces call control primitives in SIP. As such, the
security considerations detailed in the REFER [RFC3515] and Replaces
[RFC3891] documents MUST be followed, 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
7.1 and 7.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. Special care is needed if the replaced dialog utilizes
additional media streams compared to the original dialog. In this
case, the user MUST authorize the addition of new media streams in a
dialog replacement. For example, the same mechanism used to
authorize the addition of a media stream in a re-INVITE could be
used.
14. Acknowledgments
This draft is a collaborative product of the SIP working group.
Thanks to Rohan Mahy for his input on the use of Replaces in
transfer.
15. References
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] 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.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
Sparks, et al. Expires September 4, 2009 [Page 54]
Internet-Draft SIP CC Transfer March 2009
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891,
September 2004.
[RFC3892] Sparks, R., "The Session Initiation Protocol (SIP)
Referred-By Mechanism", RFC 3892, September 2004.
[RFC4538] Rosenberg, J., "Request Authorization through Dialog
Identification in the Session Initiation Protocol (SIP)",
RFC 4538, June 2006.
15.2. Informative References
[I-D.ietf-sipping-cc-framework]
Mahy, R., Sparks, R., Rosenberg, J., Petrie, D., and A.
Johnston, "A Call Control and Multi-party usage framework
for the Session Initiation Protocol (SIP)",
draft-ietf-sipping-cc-framework-10 (work in progress),
April 2008.
[I-D.ietf-sip-gruu]
Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-15 (work in progress),
October 2007.
[RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J.,
and H. Schulzrinne, "Session Initiation Protocol (SIP)
Torture Test Messages", RFC 4475, May 2006.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353,
February 2006.
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
(SIP) Call Control - Conferencing for User Agents",
BCP 119, RFC 4579, August 2006.
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference
State", RFC 4575, August 2006.
[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session
Initiation Protocol", RFC 5057, November 2007.
Sparks, et al. Expires September 4, 2009 [Page 55]
Internet-Draft SIP CC Transfer March 2009
Authors' Addresses
Robert J. Sparks
Estacado Systems
Email: RjS@estacado.net
Alan Johnston (editor)
Avaya
St. Louis, MO
Email: alan@sipstation.com
Daniel Petrie
SIPez LLC
34 Robbins Rd.
Arlington, MA 02476
US
Phone: +1 617 273 4000
Email: dan.ietf AT SIPez DOT com
URI: http://www.SIPez.com/
Sparks, et al. Expires September 4, 2009 [Page 56]