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" Handoff-To: Alice 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 ;tag=02387 From: "Billy" ;tag=97655 Call-ID: 12487@10.0.0.77 CSeq: 123213123 Contact: Billy Handoff-To: Ronnen 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 ;tag=02387 From: "Billy" ;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 Handoff-To: Ronnen 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 From: Rick ;tag=2342 Call-ID: 12487@10.0.0.77 CSeq: 123213123 HANDOFF Contact: Rick Handoff: Billy 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 ;tag=02387 To: "Billy" ;tag=97655 Call-ID: 12487@10.0.0.77 CSeq: 56565656 HANDOFF Contact: Rick 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 ;tag=839c2a22 From: Billy ;tag=0329bc6 Call-ID: 12487@10.0.0.77 Contact: Billy Handoff-To: Ronnen 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 ;tag=02387 From: "Billy" ;tag=97655 Call-ID: 12487@10.0.0.77 CSeq: 123213123 Contact: Billy Handoff-To: Ronnen 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]