Internet Engineering Task Force Biggs/Dean
Internet Draft U. Waterloo/3Com
draft-dean-handoff-00.txt
January 19, 2001
Expires: July 2001
SIP Call Control: Call Handoff
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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 document is an individual submission to the IETF. Comments
should be directed to the authors.
Abstract
This document describes a method of signaling call handoff using SIP.
Call handoff is the process of moving one end of an active call
without creating a new logical call. Handoff is an important
primitive for providing advanced telephony services.
1 Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
indicate requirement levels for compliant implementations.
2 Introduction
This document describes a method of signaling call handoff using SIP.
Call handoff is the process of moving one end of an active call
without creating a new logical call. This process can be simulated
using a back-to-back SIP User Agent, however handoff reduces state
and improves response times.
Biggs/Dean [Page 1]
Internet Draft SIP Handoff January 19, 2001
Handoff is an important primitive for providing advanced telephony
services such as:
* Call Transfer, both Attended and Unattended
* Call Park/Un-Park
* Multi-Stage Dialing
* Operator Services
* Conference Call Management
* Call Mobility
* Call Pickup
3 Definitions
SIP call-leg: A unique combination of Call-ID, to, and from. A
call-leg may also have an optional route including contact.
session: A call leg where an INVITE has succeeded but a BYE has
not.
back-to-back user agent (B2BUA): A device which establishes two
independent SIP calls, and selectively bridges audio and other
information between them. The public switched telephony network
(PSTN) is an example of a B2BUA.
two-party call-leg: A call-leg with only two call leg ends. This
is achieved by having both a "to" and "from" tag.
blind transfer: Transfer where the person leaving the conversation
does not talk to the person joining the conversation.
consultation hold transfer: Transfer where the person leaving the
conversation talks to the person joining the conversation, but
the third person can't hear it.
supervised transfer: Transfer where a three way conference occurs.
transferor: The person who initiates a transfer. The person leaves
a transfered call.
transferee: The person who stays connected throughout a transfered
call.
target: The new participant of a transfered call.
media: A generalization for stuff like audio caried in RTP.
session media description: A generalization for SDP and future
replacements.
Biggs/Dean [Page 2]
Internet Draft SIP Handoff January 19, 2001
4 Goals of this Document
Reliability: Phone systems place a huge premium on reliability. Any
Internet based phone system needs to meet or exceed this high
standard.
Ease of Implementation: Implementation difficulty has been a serious
constraint for Internet Telephony protocols. Thus, HANDOFF places an
emphasis on simple syntax and limited scope. A detailed listing of
recommended behaviors seeks to facilitate implementation.
Minimum transactions: Internet telephony is still usable with round
trip times of 100ms. Unfortunately, if a long sequence of serialized
messages can make this delay can become human noticeable. Sequenced
messages make state machines more complicated, increase complexity of
testing packet loss, waste network resources, and further obscure
error messages. Thus, HANDOFF strives to minimize message count.
Limited scope: Phones by their nature require painless
interoperability. Thus, HANDOFF strives to limit is scope to solving
an essential problem, and solving it well.
Security: Handoff is inherently dangerous because one client is
taking a third party action based on a request of another. This
proposal attempts to minimize the transmission of extra information.
Layering: Layering can make a protocol more understandable and
easier to implement. SIP is not a remote control protocol, and those
purposes are better suited for a protocol carried by SIP as a
transport.
Acceptance: We hope that all SIP implementations will support
receipt of a HANDOFF request.
5 Media Mixing for Supervised Transfer
Supervised transfer has a three-way conferencing stage. The SIP
signaling is dependent on who will mix (audio) media.
In traditional PSTN transfer, the transferor (who is leaving the
conversation) is in control. Sure, everyone can opt-out if they
wish, but the transferor determines the rest. The advantages are
many, including mindshare. This draft only addresses these
transferor dominant scenarios.
If the media is not mixed by the transferor, then a means of
controlling the remote mixer by the transferor is required. This is
best performed by a remote control protocol like PhoneControl [5], or
less ideally by DTMF/flashhook. A session protocol such as SIP is
not appropriate and would mix two layers, which could and should
Biggs/Dean [Page 3]
Internet Draft SIP Handoff January 19, 2001
otherwise be separate. Note that PhoneControl may use SIP as a
transport.
An alternative mixing strategy is by everyone though media multicast.
If the transferor finds and reserves the multicast address, this
functionally the same as the transferor mixing the media as far as
SIP is concerned. The examples in this draft only show the
non-multicast-media scenarios.
For the highest reliability system. The transferee would mix the
media, but the transferor cannot assume he can do this. The
transferor which is the premium device claiming the supervised
transfer feature, needs to be ready to mix. Provided the transferor
can recover if the handoff fails, then he might as well mix and stay
in control.
With a dominant mixing transferor, the HANDOFF is not required. The
transferor could continue to back-to-back user agent (B2BUA) the
call, and nothing but RFC2543 SIP would be required. This lets the
transferor keep his dominant position.
Unfortunately, continued B2BUA'ing adds additional messages and state
to the call. Should the transferor lose power, the two end points
would have no way to communicate with each other. The transferor may
have limited resources and transfer many calls, such as a
receptionist. HANDOFF seeks to fix this.
Thus, supervised transfer requires HANDOFF and only HANDOFF.
6 Non-Uses of HANDOFF
Music-on-hold requires the UA to regain control from the
music-on-hold server, thus HANDOFF is not appropriate. Instead the
UA should consider B2BUA'ing the call to the music-on-hold server.
With propper handling of SDP, the B2BUA need not touch the media
stream directly.
7 The HANDOFF Method
HANDOFF is a SIP method like any other non-INVITE method. A handoff
request asks the recipient to establish a session with a third party
identified by the "Handoff-To" header. The new session may
frequently replace an existing session on that third party (a.k.a.
the target).
A HANDOFF request MUST only be sent in a two-party call-leg. A
HANDOFF request MUST only be sent after an INVITE has succeeded and
before a BYE has. A HANDOFF request received outside of an
Biggs/Dean [Page 4]
Internet Draft SIP Handoff January 19, 2001
established call leg SHOULD be responded to with a 400-class
response.
The HANDOFF request SHOULD be responded to quickly. Proxy timeout
restrictions and packet loss complications mean the transferee SHOULD
send a final HANDOFF response in less than a second. The typical
response is 200 OK which only means the transfer will be acted upon.
This does not mean the transfer is successful or even passed
rudimentary tests such as DNS.
A UA receiving a well-formed HANDOFF request SHOULD NOT request
approval from the user by default. If handoff cannot be relied upon
to be quiet, then its use will be discouraged. If the UA will not
follow the handoff automatically, it SHOULD give a non-200 response.
The HANDOFF request may contain a body of MIME-type
application/sip-headers, which contains headers requested to be
copied into the spawned INVITE request. These headers SHOULD be
copied to the resulting INVITE without escape processing. See the
section on message body for a list of illegal headers, including
"call-id:" for which a "replaces:" should be used instead.
For a HANDOFF request, the "Handoff-To" URI SHOULD NOT include
question-mark delimited headers for the subsequent INVITE.
When the HANDOFF response (not handoff-status) is 200 OK, it
implicitly cancels all session media description (e.g. SDP), thus
muting media. This can be overridden by including a session media
description in the HANDOFF transaction, but operates on a
per-direction basis.
For the protection of the transferee, the handoff induced INVITE MUST
contain a "Handoff" header. Thus, targets and proxies can screen
calls based on handoff. Some destinations such as +1-900 PSTN number
may by administratively prohibited.
The transferor learns the final status of the HANDOFF request by
receiving a "Handoff-Status" header in a INVITE or BYE. The choice
of which indicates whether the HANDOFF recipient wants to continue
the session. Any SIP requests received without this header should be
assumed to have originated before the HANDOFF request was received,
or to not comment on the handoff status.
"Handoff-Status" with provisional response code MAY be sent in a
NOTIFY request. They do not replace the final status.
After the HANDOFF request has succeeded and before the final
"Handoff-Status", the transferor may send a BYE to the transferee
without affecting the HANDOFF. The final "Handoff-Status" would then
not be sent.
Biggs/Dean [Page 5]
Internet Draft SIP Handoff January 19, 2001
Clients should be prepared to receive many provisional responses such
as 180 ringing to a re-INVITE with a "Handoff-Status". The
transferor may be B2BUA'ing the call to the third party.
HANDOFF is designed to proceed quickly at the end of conferencing,
thus media mixing in the transferee is not required.
8 New Headers
8.1 The Handoff-To Header
The "Handoff-To" header may only appear in a HANDOFF request. The
Handoff-To header indicates a SIP address to which a new call should
be made. The "Handoff-To" URI SHOULD NOT include question-mark
delimited headers for the subsequent INVITE.
Handoff-To = ("Handoff-To" | "r") ":" SIP-URL
A HANDOFF request MUST contain exactly one Handoff-To header.
Examples:
Handoff-To: sip:alice@atlanta.com
Handoff-To: "Alice" <sip:alice@atlanta.com>
Handoff-To: Alice <sip:alice@atlanta.com>
Handoff-To: sip:+19115551212@atlanta.com;ugly-uri-param=foo
8.2 The Replaces Header
The "replaces" header may only appear in an INVITE request or
application/sip-headers document. If the Replaces header contains a
Call-ID which matches an existing call then the recipient is being
asked to replace the matched call-leg with the new one. The
replacement SHOULD occur immediately, sending a BYE to the original
endpoint and accepting the incoming INVITE with a 200-class response.
8.3 The Handoff Header
The "Handoff" header may only appear in an INVITE request. Every
session-initiating INVITE spawned from a HANDOFF MUST include a
"Handoff" header. The header's value SHOULD contain either
"anonymous" or the transferor's contact, unless the transferor's
call-leg has a route in which case the transferee should replace the
contact with the nearest route hop.
Handoff = "Handoff" ":" ( "anonymous" | SIP-URL )
The "Handoff" header is useful for screening INVITEs for
administrative policy.
Biggs/Dean [Page 6]
Internet Draft SIP Handoff January 19, 2001
8.4 The Handoff-Status Header
When the handoff completes, the transferee sends a requests to
transferor including a "Handoff-Status" header if that call-leg has
not had a BYE.
Handoff-Status = "Handoff-Status" ":" Status-Code SP Reason-Phrase
Status-Code and Reason-Phrase are as defined by RFC2543.
9 Message Body Inclusion
A HANDOFF method may contain a body which SHOULD be processed
according to its Content-Type. The body may be a multi-part.
9.1 Session Media Description (for example SDP)
This sesction uses the term SDP for clarity, but intends to mean any
future session media description replacement of SDP. Similarly, RTP
for media.
User agents should be prepared to receive SDP and honor it like a
re-INVITE. If the HANDOFF request or response does not include SDP
then a media description of no media is implied.
To keep the transferor-transferee RTP path open in both directions
after the HANDOFF, both the HANDOFF request and response must include
SDP. If only one sends SDP, the RTP path is only open in the one
direction as expected.
The anticipated use of transferor-transferee media after HANDOFF is
minimal, so default hold simplifies most messages.
9.2 application/sip-headers
The application/sip-headers MIME type contains headers requested to
be copied into the spawned INVITE request without escape processing.
An application/sip-headers body MUST NOT contain the headers of "To",
"From", "Call-ID", "CSeq", "Via", or "Handoff", "Contact",
"Content-Length", "Content-Type", or any header beginning with "--".
The application/sip-headers document MUST not contain any blank
lines.
By moving these headers to the body from question-mark delimited
parameters, escape processing is not required, and the messages
become more readable.
Biggs/Dean [Page 7]
Internet Draft SIP Handoff January 19, 2001
10 Example messages
10.1 Example #1: Failed Handoff
Transferor Transferee Target
10.0.0.77 10.0.0.88 10.0.0.99
Billy Rick Ronnen
| | |
| --- INVITE -------------> | |
| <--- 200 ok ------------ | |
| --- ACK ----------------> | |
| | |
| | |
(1) | --- HANDOFF ------------> | |
(2) | <--- 200 ok ------------ | |
(3) | | - INVITE --------> |
| | handoff: |
| | <-- 180 ringing --- |
| | |
| | <-- 404 not found - |
(4) | <-INVITE ---------------- | - ACK -----------> |
| handoff-status: 404 | |
| -- 180 ringing ---------> | |
| | |
| ------ 200 ok ----------> | |
| <---- ACK --------------- | |
| | |
Message (1): The HANDOFF request...
HANDOFF sip:rick@3com.com SIP/2.0
Via: SIP/2.0/UDP 10.0.0.77
To: Rick <sip:rick@3com.com>;tag=02387
From: "Billy" <sip:billy@dumbterm.net>;tag=97655
Call-ID: 12487@10.0.0.77
CSeq: 123213123
Contact: Billy <sip:10.0.0.77>
Handoff-To: Ronnen <sip:ronnen@10.0.0.99>
Content-type: application/SIP-handoff
L: 31
Replaces: 1231231@10.10.10.10
Message (2): The HANDOFF response...
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.0.77
To: Rick <sip:rick@3com.com>;tag=02387
From: "Billy" <sip:billy@dumbterm.net>;tag=97655
Biggs/Dean [Page 8]
Internet Draft SIP Handoff January 19, 2001
Call-ID: 12487@10.0.0.77
CSeq: 123213123 HANDOFF
Contact: Rick <sip:10.0.0.88>
Handoff-To: Ronnen <sip:10.0.0.99>
L: 0
Message (3): The resulting session initiating INVITE...
INVITE sip:ronnen@10.0.0.99 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.88
To: Ronnen <sip:ronnen@10.0.0.99>
From: Rick <sip:rick@3com.com>;tag=2342
Call-ID: 12487@10.0.0.77
CSeq: 123213123 HANDOFF
Contact: Rick <sip:10.0.0.88>
Handoff: Billy <sip:10.0.0.77>
Content-Type: application/SDP
L: 110
v=0
o=s 23 23 IN IP4 10.0.0.88
s=s
c=IN IP4 0.0.0.0
t=0 0
m=audio 14200 RTP/AVP 0 96
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
Message (4): The handoff-status INVITE...
INVITE sip:10.0.0.77 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.88
From: Rick <sip:rick@3com.com>;tag=02387
To: "Billy" <sip:billy@dumbterm.net>;tag=97655
Call-ID: 12487@10.0.0.77
CSeq: 56565656 HANDOFF
Contact: Rick <sip:10.0.0.88>
handoff-status: 404 Not found
Content-Type: application/sdp
L: 110
v=0
o=s 23 23 IN IP4 10.0.0.77
s=s
c=IN IP4 0.0.0.0
t=0 0
m=audio 32022 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Biggs/Dean [Page 9]
Internet Draft SIP Handoff January 19, 2001
10.2 Example #2: Successful Supervised Transfer
Transferor Transferee Target
10.0.0.77 10.0.0.88 10.0.0.99
Billy Rick Ronnen
| | |
| <-- INVITE ------------- | |
| ---- 180 ringing ------- | |
| ---- 200 ok ------------ | |
| <-- ACK ---------------- | |
| | |
| |
| --- INVITE -----------------------------------> |
| <--- 180 ringing ----------------------------- |
| |
| <--- 200 ok ---------------------------------- |
| --- ACK --------------------------------------> |
| |
| (transferor mixes audio) |
| |
(5) | --- HANDOFF ------------> | |
| <--- 200 ok ------------ | - INVITE --------> |
| | handoff: |
| | replaces: |
| | <-- 200 OK -------- |
| <--- BYE ------------------------------------- |
| --- 200 OK -----------------------------------> |
| <- BYE ------------------ | --- ACK ----------> |
| handoff-status: 200 OK | |
| -- 200 ok --------------> | |
| | |
Message (5): The HANDOFF request...
HANDOFF sip:farend@foo.com SIP/2.0
Via: SIP/2.0/UDP 10.0.0.77
To: Rick <sip:rick@3com.com>;tag=839c2a22
From: Billy <sip:billy@dumbterm.net>;tag=0329bc6
Call-ID: 12487@10.0.0.77
Contact: Billy <sip:10.0.0.77>
Handoff-To: Ronnen <sip:10.0.0.99>
L: 110
Content-type: application/sip-headers
Replaces: 1231231@10.0.0.77
Proprietary-billing-certificate: 18a563fb325c1241d4214e72d181
10.3 Example #3: Transferor-Transferee media after HADNOFF
HANDOFF sip:farend@foo.com SIP/2.0
Via: SIP/2.0/UDP 10.0.0.77
Biggs/Dean [Page 10]
Internet Draft SIP Handoff January 19, 2001
To: Rick <sip:rick@3com.com>;tag=02387
From: "Billy" <sip:billy@dumbterm.net>;tag=97655
Call-ID: 12487@10.0.0.77
CSeq: 123213123
Contact: Billy <sip:10.0.0.77>
Handoff-To: Ronnen <sip:10.0.0.99>
Content-Type: multipart/mixed; boundary="abcdefg"
L: 110
--abcdefg
Content-type: application/SIP-handoff
Replaces: 1231231@10.10.10.10
--abcdefg
Content-type: application/SDP
v=0
o=s 23 23 IN IP4 10.0.0.77
s=s
c=IN IP4 10.0.0.77
t=0 0
m=audio 2342 RTP/AVP 0
a=rtpmap:0 PCMU/8000
--abcdefg--
11 Security Considerations
Handoff is inherently dangerous because one client is taking a third
party action based on a request from another. Unfortunately, in this
case it can mean a rate bearing call, or some deleted voice-mails.
Clients should take care not to blindly follow all HANDOFF requests.
The HANDOFF request may contain additional headers in document type
application/sip-headers, which the target and transferor have
colluded to bill the call back to the transferor.
HANDOFF initiated INVITEs MUST include a "Handoff" header, which can
be used by targets and proxies to screen inappropriate calls from
handoffs.
12 References
[1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
Session Initiation Protocol", RFC2543, March 1999
[2] J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen,
E. Sink, and L. Stewart, "An extension to HTTP: Digest Access
Authentication", RFC2069, January 1997
Biggs/Dean [Page 11]
Internet Draft SIP Handoff January 19, 2001
[3] D. Crocker, "Standard for the Format of ARPA Internet Text
Messages", RFC822, August 1982
[4] R. Dean, R. Belkind, and B. Biggs, "PhoneControl",
draft-dean-phonectl-03.txt, January 2001
More recently updated versions of this document can be found at
http://phonectl.sfour.com/
13 Acknowledgments
This draft is a collaborative product of the SIP working group. The
draft's editors would like to thank Robert Sparks of Dynamicsoft for
his draft on the subject.
Thank you Rohan Mahy of Cisco for many excellent suggestions.
14 Editors' Addresses
Billy Biggs
University of Waterloo
billy@div8.net
Rick Dean
3Com
3800 Golf Road
Rolling Meadows, IL 60008
Rick_Dean@3com.com
sip:Rick_Dean@sip.3com.com
15 Full Copyright Statement
Copyright (c) The Internet Society (2001). 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.
Biggs/Dean [Page 12]
Internet Draft SIP Handoff January 19, 2001
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
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
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Biggs/Dean [Page 13]