TOC 
SIPPING WGF. Audet
Internet-DraftNortel
Intended status: BCPA. Johnston
Expires: August 20, 2008Avaya
 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.

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. Feature referral uses the SIP REFER method with a Refer-To header field containing a URN.



Table of Contents

1.  Terminology
2.  Introduction
3.  Overview
4.  User Agent Behavior
    4.1.  Dialog usage
    4.2.  Addressing the relevant parties
5.  Call flows
    5.1.  Answer Call Operation
    5.2.  Clear Connection
    5.3.  Deflect Call
    5.4.  Hold Call
    5.5.  Retrieve Call
    5.6.  Single Step Transfer Call Flow Example
    5.7.  Conference Calls
    5.8.  Seperate Calls
6.  Security Considerations
7.  IANA Considerations
8.  Acknowledgments
9.  References
    9.1.  Normative References
    9.2.  Informational References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

To simplify discussions of the REFER method and its extensions, the three terms below are being used throughout the document:



 TOC 

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] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) 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] (Sparks, R., “The Session Initiation Protocol (SIP) Refer Method,” April 2003.) with a Refer-To header field containing a URN [RFC2141] (Moats, R., “URN Syntax,” May 1997.).

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 environments, these environments have been using "Computer Telephony Integration": for example, traditional PBXs use CTI protocols such as CSTA [ECMA269] (ECMA International, “Services for Computer Suported Telecommunications Communications Applications (CSTA) Phase III,” December 2006.) 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] (ECMA International, “XML Protocol for Computer Supported Telecommunications Applications (CSTA) Phase III,” December 2006.), 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:

SIP already provides some capabilities for monitoring, including the following:

SIP also provide a method for requesting UAs do perform certain task, i.e., REFER [RFC3515] (Sparks, R., “The Session Initiation Protocol (SIP) Refer Method,” April 2003.), but today is it limited. Specically:

Feature referral is consistent with the SIP call control framework [I‑D.ietf‑sipping‑cc‑framework] (Mahy, R., Sparks, R., Rosenberg, J., Petrie, D., and A. Johnston, “A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP),” December 2009.) and is a natural expansion of the Application Interaction Framework [I‑D.ietf‑sipping‑app‑interaction‑framework] (Rosenberg, J., “A Framework for Application Interaction in the Session Initiation Protocol (SIP),” July 2005.) which allows for referral to SIP resources (through the SIP URI scheme) and Web pages (through the HTTP URI scheme).



 TOC 

3.  Overview

A prototypical feature referal flow looks as per section 4.1 of [RFC3515] (Sparks, R., “The Session Initiation Protocol (SIP) Refer Method,” April 2003.). 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] (Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, “Uniform Resource Names (URN) Namespace Definition Mechanisms,” October 2002.). An alternative would be to use the service URN space [RFC5031] (Schulzrinne, H., “A Uniform Resource Name (URN) for Emergency and Other Well-Known Services,” January 2008.). 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] (Rosenberg, J., “Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP),” June 2006.). 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] (ECMA International, “Using CSTA for SIP Phone User Agents (uaCSTA),” June 2004.) minimal profile as a starting point):

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.:



 TOC 

4.  User Agent Behavior



 TOC 

4.1.  Dialog usage

This document attempts to avoid using multiple dialog usages, for the reasons described in [RFC5057] (Sparks, R., “Multiple Dialog Usages in the Session Initiation Protocol,” November 2007.). Therefore, this document will make use of the GRUU [I‑D.ietf‑sip‑gruu] (Rosenberg, J., “Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP),” October 2007.), and the Target-Dialog header field [RFC4538] (Rosenberg, J., “Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP),” June 2006.) 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] (Rosenberg, J., Schulzrinne, H., and R. Mahy, “An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP),” November 2005.). Suppression of the REFER notifications is done with the norefersub option-tag, defined in section 7 of [RFC4488] (Levin, O., “Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription,” May 2006.). 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).



 TOC 

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] (Rosenberg, J., “Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP),” October 2007.) 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] (Rosenberg, J., “A Session Initiation Protocol (SIP) Event Package for Registrations,” March 2004.) for the relevant AORs.

In the cases where the controller does not care which specific UA it 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] (Rosenberg, J., “Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP),” June 2006.) is used.



 TOC 

5.  Call flows

This sample provides non-normative sample calls flows for the features listed in Section 3 (Overview). 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.



 TOC 

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)             |                            |
        |----------------------------->|                            |
 Answer Call Flow Example 



 TOC 

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.



       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.



       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 



 TOC 

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)             |                            |
        |----------------------------->|                            |
        |                              |                            |
        |            Cathy                                          |
dialog4 |              | F13 INVITE sip:Cathy-AOR                   |
        |              |<-------------------------------------------|
dialog4 |              | F14 180 (INVITE)                           |
        |              |------------------------------------------->|
dialog4 |              | F15 200 (INVITE)                           |
        |              |------------------------------------------->|
dialog4 |              | F16 ACK                                    |
        |              |<-------------------------------------------|
 Deflect Call Flow Example 



 TOC 

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.



       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 



 TOC 

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.



       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 



 TOC 

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     |                            |
        |----------------------------->|                            |
        |                              |                            |
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)             |                            |
        |----------------------------->|                            |



 TOC 

5.7.  Conference Calls

T.B.D.



 TOC 

5.8.  Seperate Calls

T.B.D.



 TOC 

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] (Sparks, R., “The Session Initiation Protocol (SIP) Refer Method,” April 2003.) apply.



 TOC 

7.  IANA Considerations

T.B.D. Need to register urn namespace according to procedures of [RFC3406] (Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, “Uniform Resource Names (URN) Namespace Definition Mechanisms,” October 2002.).



 TOC 

8.  Acknowledgments

Many thanks to Sean Olson, Orit Levin, Robert Sparks, Jonathan Rosenberg, and John Elwell.



 TOC 

9.  References



 TOC 

9.1. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).


 TOC 

9.2. Informational References

[RFC2141] Moats, R., “URN Syntax,” RFC 2141, May 1997 (TXT, HTML, XML).
[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 (TXT).
[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, “Uniform Resource Names (URN) Namespace Definition Mechanisms,” BCP 66, RFC 3406, October 2002 (TXT).
[RFC3515] Sparks, R., “The Session Initiation Protocol (SIP) Refer Method,” RFC 3515, April 2003 (TXT).
[RFC3680] Rosenberg, J., “A Session Initiation Protocol (SIP) Event Package for Registrations,” RFC 3680, March 2004 (TXT).
[RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, “An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP),” RFC 4235, November 2005 (TXT).
[RFC4488] Levin, O., “Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription,” RFC 4488, May 2006 (TXT).
[RFC4538] Rosenberg, J., “Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP),” RFC 4538, June 2006 (TXT).
[RFC5031] Schulzrinne, H., “A Uniform Resource Name (URN) for Emergency and Other Well-Known Services,” RFC 5031, January 2008 (TXT).
[RFC5057] Sparks, R., “Multiple Dialog Usages in the Session Initiation Protocol,” RFC 5057, November 2007 (TXT).
[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 (TXT).
[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 (TXT).
[I-D.ietf-sipping-cc-framework] Mahy, R., Sparks, R., Rosenberg, J., Petrie, D., and A. Johnston, “A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP),” draft-ietf-sipping-cc-framework-12 (work in progress), December 2009 (TXT).
[ECMA269] ECMA International, “Services for Computer Suported Telecommunications Communications Applications (CSTA) Phase III,” Standard ECMA-269, December 2006.
[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.


 TOC 

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


 TOC 

Full Copyright Statement

Intellectual Property