SIP WG R. Mahy Internet-Draft Plantronics Expires: September 6, 2006 C. Jennings Cisco Systems March 5, 2006 Remote Call Control in the Session Initiation Protocol (SIP) using the REFER method and the session-oriented dialog package draft-mahy-sip-remote-cc-03 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 6, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes how to use the SIP REFER method and the dialog package to manipulate conversations, dialogs, and sessions on remote User Agents. Specifically it extents the REFER mechinims to allow the specificate of a response that a UA should send in a dialog. This functionality is most useful for collections of loosely coupled User Agents that wish to present a coordinated user Mahy & Jennings Expires September 6, 2006 [Page 1] Internet-Draft SIP Remote Call Control March 2006 experience. It does not require a Third-Party Call Control controller to be involved in any of the manipulated dialogs. Table of Contents 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Examples of Remote Call Control Operations . . . . . . . . . . 4 4. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 8 4.1 Organizing requests within dialogs . . . . . . . . . . . . 8 4.2 Addressing the relevant parties . . . . . . . . . . . . . 10 4.3 Selecting an existing dialog context for the triggered request . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.4 Accessing Local Services Remotely . . . . . . . . . . . . 11 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6.1 Authorizing remote call control requests . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1 Normative References . . . . . . . . . . . . . . . . . . . 12 9.2 Informational References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14 Mahy & Jennings Expires September 6, 2006 [Page 2] Internet-Draft SIP Remote Call Control March 2006 1. Conventions 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 RFC-2119 [2]. To simplify discussions related to the REFER method and its extensions, three new terms will be used: REFER-Issuer: the UA issuing the REFER request. Sometimes this document will also use the term "controller". REFER-Recipient: the UA receiving the REFER request REFER-Target: the UA designated in the Refer-To URI 2. Introduction The SIP [1] core protocol describes how User Agents originate and terminate sessions. Remote call control is the manipulation of conversations and session-oriented dialogs by a UA that is not directly involved in any of the relevant conversations, dialogs, or sessions. This manipulation generally involves sending REFER [4] requests to a UA which is directly involved, using information obtained via the dialog package [5]. (Although many are familiar with REFER only as used to implement call transfer [9], the authors of the REFER method never intended this limitation. In fact the REFER method was created when the SIP working group realized that a generic request to ask another UA to do something on your behalf was much more powerful than just doing transfers.) For convenience we can describe the SIP entity that sends requests to manipulate remote sessions "the controller", but this is just a logical role. A UA that acts as a controller for one request can terminate and originate its own sessions, and even receive remote call control requests as other requests. Remote call control is especially useful for collections of loosely coupled User Agents which would like to present a coordinated user experience. Among other things, this allows User Agents which handle orthogonal media types but which would like to be present in a single conversation to add and remove each other from the conversation as needed. This is especially appropriate when coordinating conversations among organizers, general purpose computers, and special purpose communications appliances like telephones, Internet televisions, in-room video systems, electronic whiteboards, and gaming devices. For example using remote call control, an Instant Messaging client could initiate a multiplayer gaming session and an audio session to a chat conversation. Likewise a telephone could add an electronic Mahy & Jennings Expires September 6, 2006 [Page 3] Internet-Draft SIP Remote Call Control March 2006 whiteboard session to a voice conversation. Finally, a computer or organizer could cause a nearby phone to dial from numbers or URIs in a document, email, or address book; allow users to answer or deflect incoming calls without removing hands from the computer keyboard; place calls on hold; and join other sessions on the phone or otherwise. 3. Examples of Remote Call Control Operations This entire section provide non-normative examples of functionality where a computer or PDA manipulates a telephone. The behavior for remote call control with other types of devices is similar, but describing similar manipulations for other media or device types would naturally use a different set of vocabulary. In the requests labeled with 1 and 2, Alice's PC or PDA sets up a subscription to the dialog package from Alice's phone (messages shown in a later section). All of the subsequent NOTIFY messages are notifications about changes in the dialog state at Alice's phone. In message 3, Alice's PC or PDA asks her phone to "call Bob" (message 4), which eventually results in an early dialog (5) with one of Bob's Contacts. [Note Well: Parts of the flow marked in parentheses (including messages 6, 7, 9, and 10) show alternative outcomes in the call flow.] Mahy & Jennings Expires September 6, 2006 [Page 4] Internet-Draft SIP Remote Call Control March 2006 Alice's Alice's Bob Cathy PC or PDA Phone | Call-ID: 123 | Call-ID: 456 | Call-ID: 789 | | | | | |---SUBSCRIBE/200--->| 1 | | |<--NOTIFY/200-------| 2 | | | | | | | | | | |---REFER/202------->| 3 | | |<--NOTIFY/200-------|---INVITE--------->| 4 | | |<-----180----------| 5 | |<--NOTIFY/200-------| | | | | | | | | | | ( |---REFER/202------->| 6 | ) | ( | |---CANCEL/200----->| ) | ( |<--NOTIFY/200-------|<-----487/ACK------| ) | | | | | | | | | | |<-----200/ACK------| | |<--NOTIFY/200-------| | | | | | | ( |---REFER/202------->| 7 | ) | ( | |---BYE/200-------->| ) | ( |<--NOTIFY/200-------| | ) | | | | | | | | | | |<----------------------INVITE/180-----| 8 |<--NOTIFY/200-------| | | | | | | | | | | ( |---REFER/202------->| 9 | | ) ( |<--NOTIFY/200-------|--------------------------302/ACK---->| ) | | | | | | | | ( |---REFER/202------->| 10 | | ) ( |<--NOTIFY/200-------|--------------------------486/ACK---->| ) | | | | | | | | |---REFER/202------->| 11 | | |<--NOTIFY/200-------|--------------------------200/ACK---->| | | | | | | | | Messages 3, 4, and 5 follow. The norefersub option-tag on each REFER suppresses the implicit subscription which would normally follow the Mahy & Jennings Expires September 6, 2006 [Page 5] Internet-Draft SIP Remote Call Control March 2006 REFER (the notifications in the call flow diagram are for the dialog package subscription in messages 1 and 2). Via and Max-Forward headers and session descriptions are omitted for brevity and clarity. In some cases, display names are added for simplify the task of the reader following the examples. Note that URIs in SIP cannot wrap lines. Due to RFC formatting conventions, this draft splits URIs across lines where the URI would exceed 72 characters. A backslash character marks where this line folding has taken place. Finally, some of the URIs shown here are not escaped properly to aid in readability. In message 9 the @ in the Refer-To URI should be escaped. Message 3: REFER sip:reg2@10.1.1.3 SIP/2.0 To: "Alice's phone" ;tag=def From: "Alice's PC or PDA" ;tag=abc Call-ID: 123 CSeq: 2 REFER Require: remotecc Supported: norefersub Refer-To: "Bob" Message 4: INVITE sip:bob@example.net SIP/2.0 To: "Bob" From: "Alice" ;tag=xyz Call-ID: 456 CSeq: 1 INVITE Contact: "Alice's Phone" Content-Type: application/sdp Content-Length: xxx Message 5: SIP/2.0 180 Ringing To: "Bob" ;tag=uvw From: "Alice's phone" ;tag=xyz Call-ID: 456 CSeq: 1 INVITE Contact: "Bob's Contact" Content-Type: application/sdp Content-Length: xxx The rest of the REFER messages in this example are identical to the REFER in Message 3 except for the Refer-To header, CSeq header, and Mahy & Jennings Expires September 6, 2006 [Page 6] Internet-Draft SIP Remote Call Control March 2006 Via branch id (not shown). Message fragment 6 and 7 show the Refer-To headers which Alice's PC or PDA would send to cause Alice's phone to terminate the session which Message 4 attempted to originate. The extra parameters in the Refer-To header are used to explicitly match a specific dialog. They are more fully described in a later section. Note: TODO In the example messages in this draft, the messages need to be changed to use the Target-Dialog [6] header. Header for Message 6: Refer-To: "Bob's Contact" ;call-id=456;remote-tag=;local-tag=xyz Header for Message 7: Refer-To: "Bob's Contact" ;call-id=456;remote-tag=uvw;local-tag=xyz Message 8 is an invitation received by Alice's phone from Cathy. Refer-To headers for Messages 9, 10, and 11 are shown below which would cause Alice's phone to redirect, reject, or accept the invitation. They use the response URI parameter defined in [7]. Note that some specialized User Agents might not be capable of accepting an invitation autonomously. For example, a SIP user agent which connect to an analog telephone cannot physically force the phone to go offhook. Mahy & Jennings Expires September 6, 2006 [Page 7] Internet-Draft SIP Remote Call Control March 2006 Message 8: INVITE sip:reg2@10.1.1.3 SIP/2.0 To: "Alice" From: "Cathy" ;tag=ijk Call-ID: 789 CSeq: 1 INVITE Contact: "Cathy's Contact" Content-Type: application/sdp Content-Length: xxx Header for 9: Refer-To: ;call-id=789;remote-tag=ijk;local-tag=lmn Header for 10: Refer-To: ;call-id=789;remote-tag=ijk;local-tag=lmn Header for 11: Refer-To: ;call-id=789;remote-tag=ijk;local-tag=lmn 4. User Agent Behavior 4.1 Organizing requests within dialogs REFER messages used for call transfer always arrive within an existing dialog which was created with the INVITE method. In general, REFER messages can be sent within an existing dialog, or they can start a new dialog (the dialog used by the implicit subscription they create). In many use cases of remote call control, receiving notifications about the status of a REFER request are superfluous, as the Refer-Issuer typically maintains a long duration subscription to the dialog package. This situation is complicated by the possible presence of the norefersub option-tag, defined in section 7 of [7]. When the norefersub option tag is present, a REFER request which would have created a new subscription and dialog becomes a standalone transaction instead. Each such standalone REFER transaction MUST use a new (unique) Call-Id header field value. The following three use cases are suggested: Mahy & Jennings Expires September 6, 2006 [Page 8] Internet-Draft SIP Remote Call Control March 2006 1. In the most common usage, the controller maintains a long duration subscription to the dialog package, and sends REFER requests within that dialog. Each REFER is sent within the context of the dialog created for the subscription to the dialog package, and could include the norefersub option-tag in a Supported header field value. 2. Occasionally the dialog package is only supported via a dialog state agent separate from the Refer-Receiver, in which case the controller maintains a long duration subscription to the dialog package to a dialog state agent, and the controller sends these individual REFER requests as standalone requests each with a different (unique) Call-ID header field value, which could also include the norefersub option-tag in a Supported header field value. 3. In some cases, the controller does not typically maintain a dialog package subscription for the Refer-Receiver. This might be the case for a "webdialer" or other application which associates with other UAs on an adhoc and intermitent basis. An initial REFER request is sent to start a new dialog, which is followed by notifications for the refer event type (the norefersub option-tag SHOULD NOT be used in this case). These notifications could contain message/sipfrag or application/dialog-info+xml notification bodies as described in Section 4 of [7]. Message 1: SUBSCRIBE sip:reg2@10.1.1.3 SIP/2.0 To: "Alice's phone" From: "Alice's PC or PDA" ;tag=abc Call-ID: 123 CSeq: 1 SUBSCRIBE Event: dialog Contact: Message 2: NOTIFY sip:reg2@10.1.1.3 SIP/2.0 To: "Alice's PC or PDA" ;tag=abc From: "Alice's phone" ;tag=def Call-ID: 123 CSeq: 1 NOTIFY Event: dialog Contact: Subscription-State: active;expires=3600 Content-Type: application/dialog-info+xml Content-Length: xxx Mahy & Jennings Expires September 6, 2006 [Page 9] Internet-Draft SIP Remote Call Control March 2006 4.2 Addressing the relevant parties REFER requests contain a number of URIs which need to address the appropriate parties. A list of the relevant fields include the Request-URI, To header URI, From header URI, Contact header URI, Refer-To header URI, and the Referred-By header URI. This section attempts to clarify what needs to be placed in each field. In most cases, remote call control seeks to manipulate dialogs or sessions on a specific UA. For this reason, the Request URI of the REFER request SHOULD be a valid Globally Routeable User-agent URI (GRUU) [8] for a single UA (a Contact URI). Contact URIs for a UA can be discovered by subscribing to the registration package for the relevant AORs. In the rare exceptions when the controller does not care which specifc UA it manipulates, an AOR MAY be used instead. When an AOR is used, the REFER request can include appropriate caller-preferences to encourage selection of an appropriate Contact. The norefersub option-tag MUST NOT be used when the REFER Request-URI is an AOR, as the REFER Request could fork and cause very odd behavior. While, the controller can discourage a proxy from forking remote call control request by using the Request-Disposition: no-fork header field, insuring that no proxy forks requires the use of the callerpref option-tag in a Proxy-Require header field value. Because any proxy in the chain of this request which did not support caller preferences would cause the request to fail, use of Proxy-Require is NOT RECOMMENDED. For remote call control requests to operate as expected, the Refer- Issuer needs to be confident that the Refer-Receiver supports the extensions and conventions described here. Otherwise, the triggered request might have completely different semantics from the request which was indicated in the Refer-To header. (Most implementations ignore unknown URI and header parameters). For example a REFER intended to cause the Refer-Receiver to send a 486 Busy Here response for an existing dialog, might instead trigger a new INVITE to the sender of the original INVITE. Implementations which send remote call control requests MUST include the remotecc option-tag in a Require header field value in each REFER request. (Note that support for this option-tag also implies support for the response URI parameter in a Refer-To header.) The To header field in the REFER request should contain the same URI as in the Request-URI, and the From identifies the AOR of the controller. The Refer-To is set to whatever URI would normally appear in the triggered request if the request were initiated autonomously by the Refer-Receiver. A REFER triggering a standalone Mahy & Jennings Expires September 6, 2006 [Page 10] Internet-Draft SIP Remote Call Control March 2006 request or dialog starting request, could send to either an AOR or a Contact address, but typically to an AOR. A REFER request triggering a request which is in a dialog MUST always place a Contact URI in the Refer-To header. 4.3 Selecting an existing dialog context for the triggered request Many uses of remote call control require that the Refer-Receiver generate a new request or response in the context of an existing dialog. For example, the controller might want the Refer-Receiver to send a BYE, CANCEL, or response to an INVITE in the context of a dialog created with INVITE. For subscriptions, the controller might want the Refer-Receiver to unsubscribe (send a SUBSCRIBE with an Expires header field of 0). To select the appropriate dialog from which to source the request, the Target-Dialog heder specified in [6] MUST be used. 4.4 Accessing Local Services Remotely It is desirable to have a URI convention for contacts on some UAs which gives autoanswer behavior. This allows for the development of several services if properly authorized (for example, an intercom service). This is done by sedning a refer with a response=200 to a dialog that is in the alterting state. UAs need to follow the authroization procedures described in Section 6.1. 5. Formal Syntax The following syntax specification extends the SIP URI ABNF in RFC3261 to have a response URI tag using the augmented Backus-Naur Form (BNF) as described in RFC-2234 [3]. uri-parameter = transport-param / user-param / method-param / ttl-param / maddr-param / lr-param / response-param / other-param response-param = "response=" 3DIGIT 6. Security Considerations The functionality described in this document allows an authorized party to manipulate SIP sessions and dialogs in arbitrary ways. Any user agent that accepts these types of requests needs to be very careful in who it authorizes to send these types of requests. Mahy & Jennings Expires September 6, 2006 [Page 11] Internet-Draft SIP Remote Call Control March 2006 6.1 Authorizing remote call control requests It is RECOMMENDED that for any refer that includes a response, if a user agent registers with the address-of-record X, that this user agent authorize subscriptions that come from any entity that can authenticate itself as X. This can be done by using Digest Authentication. 7. IANA Considerations Need to register the SIP URI parameter specified in Section 5. 8. Acknowledgments Many thanks to Sean Olson, Orit Levin, Robert Sparks, and Alan Johnston. 9. References 9.1 Normative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [4] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [5] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005. [6] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", draft-ietf-sip-target-dialog-03 (work in progress), December 2005. [7] Levin, O., "Suppression of Session Initiation Protocol REFER Method Implicit Subscription", draft-ietf-sip-refer-with-norefersub-04 (work in progress), January 2006. Mahy & Jennings Expires September 6, 2006 [Page 12] Internet-Draft SIP Remote Call Control March 2006 [8] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", draft-ietf-sip-gruu-06 (work in progress), October 2005. 9.2 Informational References [9] Sparks, R., "Session Initiation Protocol Call Control - Transfer", draft-ietf-sipping-cc-transfer-05 (work in progress), July 2005. Authors' Addresses Rohan Mahy Plantronics 345 Encincal Street Santa Cruz, CA USA Email: rohan@ekabal.com Cullen Jennings Cisco Systems 170 West Tasman Drive Mailstop SJC-21/2 San Jose, CA 95134 USA Phone: +1 408 902-3341 Email: fluffy@cisco.com Mahy & Jennings Expires September 6, 2006 [Page 13] Internet-Draft SIP Remote Call Control March 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Mahy & Jennings Expires September 6, 2006 [Page 14]