SIPPING WG F. Audet Internet-Draft Nortel Intended status: Best Current A. Johnston Practice Avaya Expires: August 20, 2008 R. Mahy Plantronics C. Jennings Cisco Systems February 17, 2008 Feature Referral in the Session Initiation Protocol (SIP) draft-audet-sipping-feature-ref-00 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 August 20, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract Feature referral allows for an application to make a high level request to a User Agent to perform an action or "feature", and let the the User Agent actually execute the feature as it sees fit. Audet, et al. Expires August 20, 2008 [Page 1] Internet-Draft Feature Referral February 2008 Feature referral uses the SIP REFER method with a Refer-To header field containing a URN. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 6 4.1. Dialog usage . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Addressing the relevant parties . . . . . . . . . . . . . 6 5. Call flows . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Answer Call Operation . . . . . . . . . . . . . . . . . . 8 5.2. Clear Connection . . . . . . . . . . . . . . . . . . . . . 9 5.3. Deflect Call . . . . . . . . . . . . . . . . . . . . . . . 12 5.4. Hold Call . . . . . . . . . . . . . . . . . . . . . . . . 13 5.5. Retrieve Call . . . . . . . . . . . . . . . . . . . . . . 14 5.6. Single Step Transfer Call Flow Example . . . . . . . . . . 15 5.7. Conference Calls . . . . . . . . . . . . . . . . . . . . . 17 5.8. Seperate Calls . . . . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.2. Informational References . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Audet, et al. Expires August 20, 2008 [Page 2] Internet-Draft Feature Referral February 2008 1. 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 [RFC2119]. To simplify discussions of the REFER method and its extensions, the three terms below are being used throughout the document: o REFER-Issuer: the UA issuing the REFER request o REFER-Recipient: the UA receiving the REFER request o REFER-Target: the UA designated in the Refer-To Uniform Resource Identifier (URI), which, for this specification, is a Uniform Resource Name (URN) 2. Introduction Feature referral allows for an application (such as a proxy or a user agent) to make a high level request to a SIP [RFC3261] User Agent (UA) to perform an action or "feature", and let the the User Agent actually execute the feature as it sees fit. Feature referral uses the SIP REFER method [RFC3515] with a Refer-To header field containing a URN [RFC2141]. Feature referral is useful for collections of loosely coupled User Agents which would like to present a coordinated user experience (i.e., when the Application is co-resident in the UA). 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 feature referral, 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 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. Feature referral is also useful for a wide range of third party applications that need to remotely control or influence a User Agent (for example, in Contact center environment). In pre-SIP Audet, et al. Expires August 20, 2008 [Page 3] Internet-Draft Feature Referral February 2008 environments, these environments have been using "Computer Telephony Integration": for example, traditional PBXs use CTI protocols such as CSTA [ECMA269] to provide this functionality. CSTA works fine for legacy PBXs with legacy phones but is problematic in a SIP environment. For example, SIP includes totally new capabilities such as presence and instant messaging. SIP also supports multiple users with multiple devices operating at once, and with complex User Interfaces. Furthermore, multiple applications may want to simultaneously wish to interact with the device. Because of the lack of a native mechanism mechanism to achieve such control for SIP, implementors have had to implement such techniques as mapping CSTA's ASN.1 encoding to XML then encapsulate it into SIP INFO requests in order to tunnel it to a SIP B2BUA [ECMA323], which then maps it to proprietary device control protocols or to SIP with proprietary and incompatible extensions. This document provides a clean and native way to meet the requirements. CTI fundamentally requires two components: o Monitoring - to learn the state of the UA o Control - request the UA to perform certain features SIP already provides some capabilities for monitoring, including the following: o Dialog package - call states o Registration package - phone status o Conference package - conference status SIP also provide a method for requesting UAs do perform certain task, i.e., REFER [RFC3515], but today is it limited. Specically: o REFER does not allow for a UA to request another UA to respond to requests, e.g., * A UA cannot request another UA to answer a call * A UA cannot request another UA to reject a call o REFER does not allow for a UA to reques another UA to invoke features, e.g., * REFER does not allow for a UA to request another UA to place a call on hold, or to mute it * REFER does not allow for a UA to request another UA to transfer, conference, or park a call Feature referral is consistent with the SIP call control framework [I-D.ietf-sipping-cc-framework] and is a natural expansion of the Application Interaction Framework [I-D.ietf-sipping-app-interaction-framework] which allows for referral to SIP resources (through the SIP URI scheme) and Web pages Audet, et al. Expires August 20, 2008 [Page 4] Internet-Draft Feature Referral February 2008 (through the HTTP URI scheme). 3. Overview A prototypical feature referal flow looks as per section 4.1 of [RFC3515]. The Refer-To URI in the REFER message includes a URN describing the feature. The first part of the URN, i.e., the Namespace Identifier, is indended to be in the formal space and assigned by IANA, as per the procedures of [RFC3406]. An alternative would be to use the service URN space [RFC5031]. Until this is resolved, this document will use the following namespace: "feature". The second part of the URN includes the feature name, and may be followed by a semi-colon and additional feature-specific parameters. Feature referral are sent to a GRUU when a specific instance of a UA is the desired target. When the feature referral needs to be correlated to a specific dialog, the Target-Dialog header field is used [RFC4538]. Some primitives require a second dialog identifier (such as ConferenceCalls which causes the media from two dialogs to be mixed). The mechanism to convey this second dialog identifier is TBD. The following is a list of sample features (using the CSTA TR/87 [TR87] minimal profile as a starting point): o Answer call - urn:feature:AnswerCall o Clear connection - urn:feature:ClearConnection o Deflect call - urn:feature:DeflectCall o Hold call - urn:feature:HoldCall o Retrieve call - urn:feature:RetrieveCall o Single step transfer -urn:feature:SingleStepTransfer o Conference calls - urn:feature:ConferenceCalls o Separate calls - urn:feature:SeparateCalls Note that the very important "Make call" CTI primitive does not require a feature referral URN since it is accomplished by sending a normal REFER with a URI identifying the resource (e.g., a sip, sips or tel URI). Of course, other features could also be added, beyond the realm of traditional telephony, e.g.: o Add buddy to list - urn:feature:AddBuddy;sip@bob@example.com o Send vCard - urn:feature:SendVCard Audet, et al. Expires August 20, 2008 [Page 5] Internet-Draft Feature Referral February 2008 4. User Agent Behavior 4.1. Dialog usage This document attempts to avoid using multiple dialog usages, for the reasons described in [RFC5057]. Therefore, this document will make use of the GRUU [I-D.ietf-sip-gruu], and the Target-Dialog header field [RFC4538] to associated and existing INVITE usage with a REFER arriving on a new dialog to facilitate authorization of that REFER. In many use cases of feature referral, receiving notifications about the status of a REFER request are superfluous, as the Refer issuer often maintains a long duration subscription to the dialog package [RFC4235]. Suppression of the REFER notifications is done with the norefersub option-tag, defined in section 7 of [RFC4488]. When the norefersub option tag is present, a REFER request which would have created a new subscription and dialog becomes a standalone transaction instead, eliminating a multiple dialog usage. Each such standalone REFER transaction use a new (unique) Call-ID header field value. In the most common usage, the controller maintains a long duration subscription to the dialog package, and sends REFER requests in seperate dialogs Each REFER would include the norefersub option-tag in a Supported header field. In some cases, the controller does not 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 is not used in this case). 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 URI, From URI, Contact URI, Refer-To URI, and the Referred-By URI, as well as the Target-Dialog itself. This section attempts to clarify what needs to be placed in each field. In most cases, feature referral applies to dialogs or sessions on a specific UA, in which case a GRUU [I-D.ietf-sip-gruu] for a single UA (i.e., Contact URI) is used. Contact URIs for a UA can be discovered by subscribing to the registration package [RFC3680] for the relevant AORs. In the cases where the controller does not care which specific UA it Audet, et al. Expires August 20, 2008 [Page 6] Internet-Draft Feature Referral February 2008 manipulates, an AOR can 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 is not 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. Use of Proxy-Require is not normally advised because any proxy in the chain of this request which did not support caller preferences would cause the request to fail. The To header field in the REFER request normally contains the same URI as in the Request-URI. The From identifies the AOR of the controller. The Refer-To URI is the feature referral URN. Many uses of feature referral require that the Refer-Receiver take some action in the context of an existing dialog. For example, the controller might want the Refer-Receiver to send terminate an existing dialog. To select the appropriate dialog from which to source the request, the Target-Dialog header specified in [RFC4538] is used. 5. Call flows This sample provides non-normative sample calls flows for the features listed in Section 3. It is important to understand that the actual "realization" of the feature (i.e., the actual procedures invoked) are the sole responsibility of the Refer-Recipient. This document in no way attempts to standardize those procedures, and the call flow below are merely examples. In all cases, the "controller" (i.e., the Refer-Issuer) could be Alice's PC, PDA, or a third party application. The controlled device is Alice's phone (i.e., the Refer-Recipient). The Refer-Target is obviously the feature referral URN. In all cases, it is assumed that the controller is subscribed to Alice's Phone's dialog package. The call flows in this document use the following conventions. The dialog each message is sent in is shown on the left hand side. Selected Request-URI and header fields are shown. The contents of message bodies are shown for dialog-info+xml, sdp, and sipfrag message bodies. For responses, the method is shown in parentheses. For reference, the messages are labeled F1, F2, etc. Audet, et al. Expires August 20, 2008 [Page 7] Internet-Draft Feature Referral February 2008 5.1. Answer Call Operation In message 1, Bob makes a call to Alice's Phone. A notification of "trying" is sent to the controller. Alice's phone automatically sends a "ringing" to Bob. Another notification of "early" is then sent to the controller. The controller then tells the phone to answer the call. Alice's phone sends a notification of "confirmed" to the controller. Controller Alice Bob |<<< Controller subscribed >>>| | |<< to Alice's dialog events >>| | dialog1 | | F1 INVITE sip:Alice-AOR | | |<---------------------------| dialog2 | F2 NOTIFY sip:Controller-GRUU| | | dialog-info+xml: dialog1=trying | |<-----------------------------| | | | | dialog2 | F3 200 (NOTIFY) | | |----------------------------->| | dialog1 | | F4 180 (INVITE) | | |--------------------------->| dialog2 | F5 NOTIFY sip:Controller-GRUU| | | dialog-info+xml: dialog1=early | |<-----------------------------| | | | | dialog2 | F6 200 (NOTIFY) | | |----------------------------->| | | | | dialog3 | F7 REFER sip:Alice-GRUU | | | To: sip:Alice-GRUU | | | Refer-To: urn:feature:AnswerCall | | Target-Dialog: dialog1 | | |----------------------------->| | | | | dialog3 | F8 202 (REFER) | | |<-----------------------------| | dialog1 | | F9 200 (INVITE) | | |--------------------------->| | | | dialog1 | | F10 ACK | | |<---------------------------| dialog2 | F11 NOTIFY sip:Controller-GRUU | | dialog-info+xml: dialog1=confirmed | |<-----------------------------| | | | | dialog2 | F12 200 (NOTIFY) | | |----------------------------->| | Audet, et al. Expires August 20, 2008 [Page 8] Internet-Draft Feature Referral February 2008 Answer Call Flow Example 5.2. Clear Connection Clear Connection is a perfect example of a feature whose treatment (and consequently, the resulting call flow) depends on the situation, for example, the state of the dialog between the remote parties. Alice's Phone and Bob are currently in an established dialog. The controller tells Alice's phone to "clear the connection" with Bob's phone. Controller Alice Bob |<< Controller subscribed to >>|<<< Established dialog1 >>>>| |<<< Alice's dialog events >>>>| | | | | dialog3 | F1 REFER sip:Alice-GRUU | | | To: sip:Alice-GRUU | | | Refer-To: urn:feature:ClearConnection | | Target-Dialog: dialog1 | | |----------------------------->| | | | | dialog3 | F2 202 (REFER) | | |<-----------------------------| | dialog1 | | F3 BYE sip:Bob-GRUU | | |--------------------------->| | | | dialog1 | | F4 200 (BYE) | | |<---------------------------| | F5 NOTIFY sip:Controller-GRUU | | dialog-info+xml: dialog2=local-bye | |<-----------------------------| | | | | dialog2 | F6 200 (NOTIFY) | | |----------------------------->| | Clear Connection in Established Dialog Call Flow Example If Alice's Phone and Bob are in an early dialog with Bob calling Alice, the call flow could be as follows. Audet, et al. Expires August 20, 2008 [Page 9] Internet-Draft Feature Referral February 2008 Controller Alice Bob |<< Controller subscribed to >>| | |<<< Alice's dialog events >>>>| | dialog1 | | F1 INVITE sip:Alice-AOR | | (dialog2) |<---------------------------| | | | dialog2 | F2 NOTIFY sip:Controller-GRUU| | | dialog-info+xml: dialog1=trying | |<-----------------------------| | | | | dialog2 | F3 200 (NOTIFY) | | |----------------------------->| | dialog1 | | F4 180 (INVITE) | | |--------------------------->| dialog2 | F5 NOTIFY sip:Controller-GRUU| | | dialog-info+xml: dialog1=early | |<-----------------------------| | | | | dialog2 | F6 200 (NOTIFY) | | |----------------------------->| | | | | dialog3 | F7 REFER sip:Alice-GRUU | | | To: sip:Alice-GRUU | | | Refer-To: urn:ietf:feature:ClearConnection | | Target-Dialog: dialog1 | | |----------------------------->| | | | | dialog3 | F8 202 (REFER) (dialog3) | | |<-----------------------------| | dialog1 | | F9 480 (INVITE) | | |--------------------------->| | | | dialog1 | | F10 ACK | | |<---------------------------| dialog2 | F11 NOTIFY (Controller-GRUU) | | | dialog-info+xml: dialog1=rejected | |<-----------------------------| | | | | dialog2 | F12 200 (NOTIFY) | | |----------------------------->| | Clear Connection in Early Dialog Call Flow Example If Alice's Phone and Bob are in an early dialog with Alice calling Bob, the call flow could be as follows. Audet, et al. Expires August 20, 2008 [Page 10] Internet-Draft Feature Referral February 2008 Controller Alice Bob |<< Controller subscribed to >>| | |<<< Alice's dialog events >>>| | dialog1 | | F1 INVITE sip:Bob-AOR | | |--------------------------->| dialog2 | F2 NOTIFY sip:Controller-GRUU| | | dialog-info+xml: dialog1=trying | |<-----------------------------| | | | | dialog2 | F3 200 (NOTIFY) | | |----------------------------->| | dialog1 | | F4 180 (INVITE) | | |<---------------------------| dialog2 | F5 NOTIFY sip:Controller-GRUU| | | dialog-info+xml: dialog1=early | |<-----------------------------| | | | | dialog2 | F6 200 (NOTIFY) | | |----------------------------->| | | | | dialog3 | F7 REFER sip:Alice-GRUU | | | To: sip:Alice-GRUU | | | Refer-To: urn:feature:ClearConnection | | Target-Dialog: dialog1 | | |----------------------------->| | | | | dialog3 | F8 202 (REFER) | | |<-----------------------------| | dialog1 | | F9 CANCEL | | |--------------------------->| | | | dialog1 | | F10 200 (CANCEL) | | |<---------------------------| | | | dialog1 | | F11 487 (INVITE) | | |<---------------------------| | | | dialog1 | | F12 ACK | | |--------------------------->| | | | dialog1 | F13 NOTIFY sip:Controller-GRUU | | dialog-info+xml: dialog1=rejected | |<-----------------------------| | | | | dialog2 | F14 200 (NOTIFY) | | |----------------------------->| | Clear Connection Initiated Call Flow Example Audet, et al. Expires August 20, 2008 [Page 11] Internet-Draft Feature Referral February 2008 5.3. Deflect Call Bob makes a call to Alice's Phone. A notification of "trying" is sent to the controller. Alice's phone automatically sends a "ringing" to Bob. Another notification of "early" is then sent to the controller. The controller tells the phone to deflect the call to Cathy. Alice's phone sends a notification of "terminated" to the controller. Bob's will attempt the call to Cathy. Controller Alice Bob |<< Controller subscribed to >>| | |<<< Alice's dialog events >>>>| | dialog1 | | F1 INVITE sip:Alice-AOR | | |<---------------------------| dialog2 | F2 NOTIFY sip:Controller-GRUU| | | dialog-info+xml: dialog1=trying | |<-----------------------------| | | | | dialog2 | F3 200 (NOTIFY) | | |----------------------------->| | dialog1 | | F4 180 (INVITE) | | |--------------------------->| dialog2 | F5 NOTIFY sip:Controller-GRUU| | | dialog-info+xml: dialog1=early | |<-----------------------------| | | | | dialog2 | F6 200 (NOTIFY) | | |----------------------------->| | | | | dialog3 | F7 REFER sip:Alice-GRUU | | | To: sip:Alice-GRUU | | | Refer-To: urn:feature:DeflectCall;target=(Cathy-AOR) | | Target-Dialog: dialog1 | | |----------------------------->| | | | | dialog3 | F8 202 (REFER) | | |<-----------------------------| | dialog1 | | F9 302 (INVITE) | | | Contact: sip:Cathy-AOR | | |--------------------------->| | | | dialog1 | | F10 ACK | | |<---------------------------| dialog2 | F11 NOTIFY sip:Controller-GRUU | | dialog-info+xml: dialog1=rejected | |<-----------------------------| | | | | dialog2 | F12 200 (NOTIFY) | | Audet, et al. Expires August 20, 2008 [Page 12] Internet-Draft Feature Referral February 2008 |----------------------------->| | | | | | Cathy | dialog4 | | F13 INVITE sip:Cathy-AOR | | |<-------------------------------------------| dialog4 | | F14 180 (INVITE) | | |------------------------------------------->| dialog4 | | F15 200 (INVITE) | | |------------------------------------------->| dialog4 | | F16 ACK | | |<-------------------------------------------| Deflect Call Flow Example 5.4. Hold Call The controller tells Alice's phone to put on hold the already established dialog with Bob. Alice's phone sends a re-INVVITE to Bob's contact to put the media stream on hold. Note that a call hold is different concept than held media. In fact, a user can be placed on hold, and be provided with music on hold. A held call is a logical state which could be useful for a number of things such as monitoring the amount of time a user stays in a queue. Audet, et al. Expires August 20, 2008 [Page 13] Internet-Draft Feature Referral February 2008 Controller Alice Bob |<< Controller subscribed to >>|<<<< Established dialog1 >>>| |<<< Alice's dialog events >>>>| | | | | dialog3 | F1 REFER sip:Alice-GRUU | | | To: sip:Alice-GRUU | | | Refer-To: urn:feature:HoldCall | | Target-Dialog: dialog1 | | |----------------------------->| | | | | dialog3 | F2 202 (REFER) | | |<-----------------------------| | dialog1 | | F3 re-INVITE sip:Bob-GRUU | | | sdp: hold | | |--------------------------->| | | | dialog1 | | F4 200 (re-INVITE) | | |<---------------------------| | | | dialog1 | | F5 ACK | | |<---------------------------| dialog2 | F6 NOTIFY sip:Controller-GRUU| | | dialog-info+xml: dialog2;confirmed;+sip.rendering="no" | |<-----------------------------| | | | | dialog2 | F7 200 (NOTIFY) | | |----------------------------->| | Call Hold Call Flow Example 5.5. Retrieve Call The controller tells Alice's phone to retrieve an held call with Bob. Alice's phone sends a re-INVVITE to Bob's contact to resume the media stream which was already on hold. Audet, et al. Expires August 20, 2008 [Page 14] Internet-Draft Feature Referral February 2008 Controller Alice Bob |<< Controller subscribed to >>|<<<< Established dialog1 >>>| |<<< Alice's dialog events >>>>| | | | | | F1 REFER sip:Alice-GRUU | | | To: sip:Alice-GRUU | | | Refer-To: urn:feature:RetrieveCall | | Target-Dialog: dialog1 | | |----------------------------->| | | | | dialog3 | F2 202 (REFER) | | |<-----------------------------| | dialog1 | | F3 re-INVITE sip:Bob-GRUU | | | sdp: un-hold | | |--------------------------->| | | | dialog1 | | F4 200 (re-INVITE) | |<---------------------------| | | | dialog1 | | F5 ACK | | |<---------------------------| dialog2 | F6 NOTIFY sip:Controller-GRUU | | | dialog-info+xml: dialog2;confirmed;+sip.rendering="yes"| |<-----------------------------| | | | | dialog2 | F7 200 (NOTIFY) (dialog2) | | |----------------------------->| | Retrieve Call Flow Example 5.6. Single Step Transfer Call Flow Example Alice's phone and Bob are currently in an established dialog. The controller tells Alice's phone to transfer the call to Cathy. Alice's phone sends a REFER to Bob to transfer the call to Cathy. Cathy's phone rings, is and is answered. Bob sends a notification to Alice's phone of completion of REFER (using the implicit subscription). Alice's phone then terminates the session with Bob and sends a notification of "terminated" to the controller. Controller Alice Bob |<< Controller subscribed to >>|<<<< Established dialog1 >>>| |<<< Alice's dialog events >>>>| | | | | dialog3 |F1 REFER sip:Alice-GRUU | | | To: sip:Alice-GRUU | | | Refer-To: urn:feature:SingleStepTransfer;target=Cathy-AOR | Target-Dialog: dialog1 | | Audet, et al. Expires August 20, 2008 [Page 15] Internet-Draft Feature Referral February 2008 |----------------------------->| | | | | dialog3 | F2 202 (REFER) | | |<-----------------------------| | dialog4 | | F3 REFER sip:Bob-GRUU | | | Refer-To: (Cathy-AOR) | | |--------------------------->| | | | dialog4 | | F4 200 (REFER) | | |<---------------------------| | | | dialog4 | | F5 NOTIFY sip:Alice-GRUU | | | sipfrag: 100 | | |<---------------------------| | | | dialog4 | | F6 200 (NOTIFY) | | Cathy |--------------------------->| dialog5 | | F7 INVITE sip:Cathy-AOR | | |<-------------------------------------------| dialog5 | | F8 180 | | |------------------------------------------->| dialog5 | | F9 200 | | |------------------------------------------->| dialog5 | | F10 ACK | | |<-------------------------------------------| dialog4 | | F11 NOTIFY sip:Alice-GRUU | | | sipfrag: 200 | | |<---------------------------| | | | dialog4 | | F12 200 (NOTIFY) | | |--------------------------->| | | | dialog1 | | F13 BYE | | |--------------------------->| | | | dialog1 | | F14 200 (BYE) | | |<---------------------------| dialog2 | F15 NOTIFY sip:Controller-GRUU| | | dialog-info+xml: dialog1=terminated | |<-----------------------------| | | | | dialog2 | F16 200 (NOTIFY) | | |----------------------------->| | Audet, et al. Expires August 20, 2008 [Page 16] Internet-Draft Feature Referral February 2008 5.7. Conference Calls T.B.D. 5.8. Seperate Calls T.B.D. 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. The same security considerations as [RFC3515] apply. 7. IANA Considerations T.B.D. Need to register urn namespace according to procedures of [RFC3406]. 8. Acknowledgments Many thanks to Sean Olson, Orit Levin, Robert Sparks, Jonathan Rosenberg, and John Elwell. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informational References [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 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. [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Audet, et al. Expires August 20, 2008 [Page 17] Internet-Draft Feature Referral February 2008 Mechanisms", BCP 66, RFC 3406, October 2002. [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004. [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005. [RFC4488] Levin, O., "Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription", RFC 4488, May 2006. [RFC4538] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, June 2006. [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008. [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", RFC 5057, November 2007. [I-D.ietf-sipping-app-interaction-framework] Rosenberg, J., "A Framework for Application Interaction in the Session Initiation Protocol (SIP)", draft-ietf-sipping-app-interaction-framework-05 (work in progress), July 2005. [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. [I-D.ietf-sipping-cc-framework] Mahy, R., "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", draft-ietf-sipping-cc-framework-09 (work in progress), December 2007. [ECMA269] ECMA International, "Services for Computer Suported Telecommunications Communications Applications (CSTA) Phase III", Standard ECMA-269, December 2006. Audet, et al. Expires August 20, 2008 [Page 18] Internet-Draft Feature Referral February 2008 [ECMA323] ECMA International, "XML Protocol for Computer Supported Telecommunications Applications (CSTA) Phase III", Standard ECMA-323, December 2006. [TR87] ECMA International, "Using CSTA for SIP Phone User Agents (uaCSTA)", Technical Report TR/87, June 2004. Authors' Addresses Francois Audet Nortel 4655 Great America Parkway Santa Clara, CA 95054 US Phone: +1 408 495 2456 Email: audet@nortel.com Alan Johnston Avaya St. Louis, MO 63124 US Email: alan@sipstation.com Rohan Mahy Plantronics 345 Encincal Street Santa Cruz, CA US Email: rohan@ekabal.com Cullen Jennings Cisco Systems 170 West Tasman Drive Mailstop SJC-21/2 San Jose, CA 95134 US Phone: +1 408 902-3341 Email: fluffy@cisco.com Audet, et al. Expires August 20, 2008 [Page 19] Internet-Draft Feature Referral February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Audet, et al. Expires August 20, 2008 [Page 20]