[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

INTERNET-DRAFT                                            R. Shekh-Yusef
Intended Status: Standards Track                                   Avaya
Expires: July 18, 2011                                       C. Jennings
                                                           Cisco Systems
                                                             A. Johnston
                                                                   Avaya
                                                                F. Audet
                                                                   Skype
                                                        January 14, 2011


       Action Referral in the Session Initiation Protocol (SIP)
                   draft-yusef-dispatch-action-ref-00

Abstract

   This specification defines action referral that allows an application
   to make a high level request to a User Agent to perform an action,
   and let the the User Agent execute the action as it sees fit. Action
   referral uses the SIP REFER method with a Refer-To header field
   containing a URN, which indicates the requested action.

   This specification also defines the option tag 'action-ref' to allow
   the UA to indicate its support for action referral.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice



Shekh-Yusef, et al.      Expires July 18, 2011                  [Page 1]


INTERNET DRAFT              Action Referral             January 14, 2011


   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.







































Shekh-Yusef, et al.      Expires July 18, 2011                  [Page 2]


INTERNET DRAFT              Action Referral             January 14, 2011


Table of Contents

   1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 5
   3. Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
      3.1.  Third-Party/Proxy Application  . . . . . . . . . . . . . . 7
      3.2.  Loosely Coupled UAs  . . . . . . . . . . . . . . . . . . . 7
      3.3.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8
         3.3.1.  Answer an audio call  . . . . . . . . . . . . . . . . 8
         3.3.2.  Answer an A/V call on two separate devices  . . . . . 9
         3.3.3.  Click-to-Dial . . . . . . . . . . . . . . . . . . .  10
   4.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .  11
      4.1.  URN Structure  . . . . . . . . . . . . . . . . . . . . .  11
      4.2.  URN Categories . . . . . . . . . . . . . . . . . . . . .  12
   5.  User Agent Behavior . . . . . . . . . . . . . . . . . . . . .  13
      5.1.  Dialog usage . . . . . . . . . . . . . . . . . . . . . .  13
      5.2.  Capabilities Indications . . . . . . . . . . . . . . . .  13
      5.3.  Addressing the relevant parties  . . . . . . . . . . . .  14
      5.4.  Monitoring Device Specific Events  . . . . . . . . . . .  14
      5.5.  Request Authorization  . . . . . . . . . . . . . . . . .  15
   6.  Call Flows  . . . . . . . . . . . . . . . . . . . . . . . . .  16
      6.1.  Answer Call Operation  . . . . . . . . . . . . . . . . .  17
      6.2.  Terminate Call Operation . . . . . . . . . . . . . . . .  19
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  22
   10.  References . . . . . . . . . . . . . . . . . . . . . . . . .  22
      10.1.  Normative References  . . . . . . . . . . . . . . . . .  22
      10.2  Informative References . . . . . . . . . . . . . . . . .  22
   Author's Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24





















Shekh-Yusef, et al.      Expires July 18, 2011                  [Page 3]


INTERNET DRAFT              Action Referral             January 14, 2011


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 RFC 2119 [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)


































Shekh-Yusef, et al.      Expires July 18, 2011                  [Page 4]


INTERNET DRAFT              Action Referral             January 14, 2011


2.  Introduction

   The Session Initiation Protocol (SIP) [RFC3261] provides users with
   the ability to initiate, manage and terminate multimedia sessions.
   Many deployments have SIP applications in the SIP signaling path that
   get involved in the setup and management of these multimedia
   sessions.

   A SIP application is a program running on a SIP network element that
   provides some value-added function to a user. Some of these
   applications need mechanisms to monitor or/and control a SIP User
   Agent (UA).


   SIP already provides an extensible framework, (SIP)-Specific Event
   Notification [RFC 3265], by which SIP UAs can monitor remote UAs and
   get indications that certain events have occurred. For example, the
   following are widely used event packages:

    o  Dialog package - call states

    o  Registration package - phone status

    o  Conference package - conference status



   SIP also provides a method for requesting UAs to perform certain
   task, i.e., REFER [RFC3515]. This REFER method is limited, as today
   it does not support the following:

    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 request another UA to invoke
       actions, e.g.,

       *  REFER does not allow for a UA to request another UA to
          place a call on hold or to mute it







Shekh-Yusef, et al.      Expires July 18, 2011                  [Page 5]


INTERNET DRAFT              Action Referral             January 14, 2011


   Action referral allows an application to make a high level request to
   a SIP [RFC3261] User Agent (UA) to perform an action or, and let the
   User Agent execute the action as it sees fit.

   Action referral uses the SIP REFER method [RFC3515] with a Refer-To
   header field containing a URN [RFC2141] to indicate the requested
   action. Action referral is consistent with the SIP call control
   framework [RFC5850] and is a natural expansion of the Framework for
   Application Interaction [RFC5629] which allows for referral to SIP
   and HTTP resources.



   OPEN QUESTION:

   The REFER method seems to be already overloaded with various
   capabilities. Take a look at the following draft draft-worley-sip-
   many-refers-00 for more details.

   Should a new SIP method be defined for this purpose?































Shekh-Yusef, et al.      Expires July 18, 2011                  [Page 6]


INTERNET DRAFT              Action Referral             January 14, 2011


3. Use Cases

   This section describes these applications for which the Action
   Referral can be useful.


3.1.  Third-Party/Proxy Application

   Action referral is useful for a wide range of third party or proxy
   applications that need to remotely control or influence a User Agent,
   e.g. 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] 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 to
   achieve such control for SIP, implementers 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.


3.2.  Loosely Coupled UAs

   Action referral is 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 action referral, an Instant
   Messaging client could initiate a multi-player 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 redirect incoming calls without removing hands from the computer
   keyboard, place calls on hold, and join other sessions on the phone
   or otherwise.



Shekh-Yusef, et al.      Expires July 18, 2011                  [Page 7]


INTERNET DRAFT              Action Referral             January 14, 2011


3.3.  Examples

   In the following examples, Alice has two SIP clients; a PC with a
   soft client and a desk phone. Alice prefers to answer incoming audio
   calls on her desk phone.


3.3.1.  Answer an audio call

   In this example, Bob makes an audio call to Alice and the proxy forks
   the call to both of Alice's clients. Alice decided that she wants to
   answer the call on her desk phone remotely using her soft client.

   To do that, the soft client sends a REFER with a well-defined URN,
   which instructs the desk phone to answer the call. As a result, the
   desk phone sends a 200 OK to answer the incoming call, and the proxy
   then cancels the INVITE to the soft client.

   Alice                 Alice                Proxy                  Bob
    PC                 Desk Phone
    |                     |                     | INVITE Alice        |
    |                     |                     |<--------------------|
    |                     | INVITE Alice        |                     |
    |                     |<--------------------|                     |
    | INVITE Alice        |                     |                     |
    |<------------------------------------------|                     |
    | REFER Refer-To: urn:sip-action:call:answer|                     |
    |-------------------->|                     |                     |
    | 202                 |                     |                     |
    |<--------------------|                     |                     |
    | NOTIFY [Trying]     |                     |                     |
    |<--------------------|                     |                     |
    | 200 OK              |                     |                     |
    |-------------------->|                     |                     |
    |                     | 200 OK              |                     |
    |                     |-------------------->| 200 OK              |
    |                     |                     |-------------------->|
    |                     |                     | ACK                 |
    |                     |                     |<--------------------|
    |                     | ACK                 |                     |
    |                     |<--------------------|                     |
    | NOTIFY [200 OK]     |                     |                     |
    |<--------------------|                     |                     |
    | 200 OK              |                     |                     |
    |-------------------->|                     |                     |
    | CANCEL              |                     |                     |
    |<------------------------------------------|                     |
    |                     |                     |                     |



Shekh-Yusef, et al.      Expires July 18, 2011                  [Page 8]


INTERNET DRAFT              Action Referral             January 14, 2011


3.3.2.  Answer an A/V call on two separate devices

   In this example, Bob makes a video call to Alice. Alice interested in
   accepting the video using her soft client on her PC and accepting the
   audio on her desk phone.

   To do that, the soft client sends a REFER with the URN urn:sip-
   action:audio:answer which asks the desk phone to return its audio
   answer to the incoming call. The desk phone returns its audio answer
   in the body of the sipfrag message in the NOTIFY request. The soft
   client then aggregates the audio SDP answer from the desk phone with
   the video answer from the soft client and sends it to Bob's phone. As
   a result a video call is established, with the video streaming
   between Alice's PC and Bob's phone while the audio is streaming
   between Alice's desk phone and Bob's phone.


   Alice                 Alice                Proxy                  Bob
    PC                 Desk Phone
    |                     |                     | INVITE Alice [A/V]  |
    |                     |                     |<--------------------|
    |                     | INVITE Alice [A/V]  |                     |
    |                     |<--------------------|                     |
    | INVITE Alice [A/V]  |                     |                     |
    |<------------------------------------------|                     |
    | REFER Refer-To: urn:sip-action:audio:answer                     |
    |-------------------->|                     |                     |
    | 202                 |                     |                     |
    |<--------------------|                     |                     |
    | NOTIFY [100 Trying] |                     |                     |
    |<--------------------|                     |                     |
    | 200 OK              |                     |                     |
    |-------------------->|                     |                     |
    | NOTIFY [200 OK [Audio SDP answer]]        |                     |
    |<--------------------|                     |                     |
    | 200 OK              |                     |                     |
    |-------------------->|                     |                     |
    | 200 OK [A/V SDP answer]                   |                     |
    |------------------------------------------>|                     |
    |                     |                     | 200 OK [A/V]        |
    |                     |                     |-------------------->|
    |                     | CANCEL              |                     |
    |                     |<--------------------|                     |
    |                     |<======audio==============================>|
    |<============================video==============================>|
    |                     |                     |                     |





Shekh-Yusef, et al.      Expires July 18, 2011                  [Page 9]


INTERNET DRAFT              Action Referral             January 14, 2011


3.3.3.  Click-to-Dial


   In this example, while browsing the web on her PC, Alice clicks on
   Bob's SIP URI, intending to initiate a call to Bob.  Alice's web
   browser passes the SIP URI to the soft client on Alice's PC.  The
   soft client is configured with the URI of Alice's desk phone.  A
   REFER is sent to the desk phone, which results in Alice's desk phone
   initiating a call to Bob.

   Alice decided to cancel the call to Bob because he is no answering.
   To do that, the soft client sends a REFER request with the URN
   urn:sip-action:call:terminate which results in Alice's desk phone
   sending a CANCEL request to terminate the call to Bob.



          Alice                 Alice                  Bob
           PC                 Desk Phone
            |                     |                     |
            | REFER Refer-To: Bob |                     |
            |-------------------->|                     |
            | 202 Accepted        |                     |
            |<--------------------|                     |
            |                     | INVITE              |
            |                     |-------------------->|
            |                     | 180 Ringing         |
            |                     |<--------------------|
            |                     |                     |
            | REFER Refer-To: urn:sip-action:call:terminate
            |-------------------->|                     |
            | 202 Accepted        |                     |
            |<--------------------|                     |
            |                     |                     |
            |                     | CANCEL              |
            |                     |-------------------->|
            |                     |                     |














Shekh-Yusef, et al.      Expires July 18, 2011                 [Page 10]


INTERNET DRAFT              Action Referral             January 14, 2011


4.  Overview

   A prototypical action referral flow looks as per section 4.1 of
   [RFC3515].  The Refer-To URI in the REFER message includes a URN
   describing the action.

   Action referral is sent to a GRUU when a specific instance of a UA is
   the desired target.  When the action 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).
   To address the multiple dialogs need, one REFER is sent per dialog
   with a URN with a bridge action telling the phone to put the dialog
   on the bridge. While this requires multiple requests to be sent, the
   requests can be sent overlapped at the same time. This approach is
   flexible enough to allow adding and removing parties to the
   conference in very simple and straightforward way without changes to
   existing standard behavior.


4.1.  URN Structure

   The Namespace Identifier (NID) of the URN is intended 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: "sip-action".

   The Namespace Specific String (NSS) of the URN includes the action
   name, and may be followed by a semi-colon and additional action-
   specific parameters.

   The action name might consist of a number of categories that start
   from the most general category and go down to more specific category,
   with the last value representing the request.

   For example, the structure of the NSS of the urn:sip-
   action:call:answer has two categories: 'service' and 'call' and the
   request 'answer'.

   The reason behind the above structure is to avoid the creation of a
   namespace with a very long list of unrelated actions.

   The above structure allows grouping of related actions under one
   category to allow application to apply actions, e.g. enable/disable,
   to the whole category.



Shekh-Yusef, et al.      Expires July 18, 2011                 [Page 11]


INTERNET DRAFT              Action Referral             January 14, 2011


4.2.  URN Categories

   This document defines the following categories as part of the NSS of
   the URN:

      o call: to allow access to call actions available on a SIP UA,
        e.g. answer a call, decline a call, ...

      o conference: to allow access to conference actions available on a
        SIP UA, e.g.  add, remove, ...



   This document defines the following actions:

    o  Answer call       - urn:sip-action:call:answer
    o  Terminate call    - urn:sip-action:call:terminate
    o  Decline call      - urn:sip-action:call:decline
       The REFER-Recipient returns 603 Decline
    o  Ignore call       - urn:sip-action:call:ignore
       The REFER-Recipient stops ringing and clears the call
    o  Send call to VM   - urn:sip-action:call:sendvm
       Stop ringing and send the call to VM.
    o  Hold call         - urn:sip-action:call:hold
    o  Unhold call       - urn:sip-action:call:unhold
    o  Mute call         - urn:sip-action:call:mute
    o  Unmute call       - urn:sip-action:call:unmute
    o  Conference        - urn:sip-action:conference:add
                         - urn:sip-action:conference:remove


   Note that the very important "Make call" CTI primitive does not
   require a action 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).

   This specification defines the above list as an initial set of URNs,
   to be registered with IETF, for use with this specification.

   In order to add any new action URN to the list above, it must go
   through the "IETF review" process as defined in RFC 5226.










Shekh-Yusef, et al.      Expires July 18, 2011                 [Page 12]


INTERNET DRAFT              Action Referral             January 14, 2011


5.  User Agent Behavior

5.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 [RFC5627], and the Target-Dialog header field
   [RFC4538] to associate an existing INVITE usage with a REFER arriving
   on a new dialog to facilitate authorization of that REFER.

   In many use cases of action 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
   separate 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-Recipient.  This might be the case for a
   "webdialer" or other application which associates with other UAs on
   an adhoc and intermittent 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).


5.2.  Capabilities Indications

   A UA compliant to this specification SHOULD indicate its support by
   including the option tag 'action-ref' in the Supported header of all
   requests it sends.

   The UA MAY also indicate its support for this action referral by
   adding the 'action-ref' value to the extentions parameter in the
   Contact header field of its REGISTER request, as described in [RFC
   3840].







Shekh-Yusef, et al.      Expires July 18, 2011                 [Page 13]


INTERNET DRAFT              Action Referral             January 14, 2011


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

   Action referral applies to dialogs or sessions on a specific UA,
   which requires the use of GRUU [RFC5627] for a single UA.  Contact
   URIs for a UA can be discovered by subscribing to the registration
   package [RFC3680] for the relevant AORs.

   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 action referral URN.

   Many uses of action referral require that the REFER-Recipient take
   some action in the context of an existing dialog.  For example, the
   controller might want the REFER-Recipient to 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.4.  Monitoring Device Specific Events

   Some applications need a mechanism to monitor events on a SIP UA that
   are device specific.

   The following is a list of some these device specific events:

      1. Hook status
      2. Transducer status (handset, headset, speaker)
      3. Active call
      4. Volume status
      5. Mute status
      6. MWI light status
      7. IM light status

   A separate document that defines a new event package will be created
   to address this need.









Shekh-Yusef, et al.      Expires July 18, 2011                 [Page 14]


INTERNET DRAFT              Action Referral             January 14, 2011


5.5.  Request Authorization


   When a UA receives a request to invoke an action, it needs to
   authorize that request. Some requests can be authorized based on the
   identity of the sender, the request method, local policy, etc.

   All action referral requests MUST be challenged using the digest
   authentication mechanism described by [RFC 3261]. In most cases, the
   same user will be logged in to the different devices using the same
   credentials provided in the REGISTER requests.








































Shekh-Yusef, et al.      Expires July 18, 2011                 [Page 15]


INTERNET DRAFT              Action Referral             January 14, 2011


6.  Call Flows

   This sample provides non-normative sample calls flows for some of the
   actions listed in Section 4. It is important to understand that the
   actual "realization" of the action (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 action 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.






























Shekh-Yusef, et al.      Expires July 18, 2011                 [Page 16]


INTERNET DRAFT              Action Referral             January 14, 2011


6.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:sip-action:call:answer                  |
           |     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)             |                            |
           |----------------------------->|                            |



Shekh-Yusef, et al.      Expires July 18, 2011                 [Page 17]


INTERNET DRAFT              Action Referral             January 14, 2011


   In the following flow, the application is in the signaling path
   between Alice and Bob and is aware of a dialog that was established
   between the UAs.

   Alice calls Bob, and Bob's UA is ringing. At this stage, the
   application decides that it wants to ask Bob's UA to answer the call.
   The application sends a REFER request asking Bob's UA to answer the
   call, which results on Bob's UA sending an 200 OK and a call is
   established with Alice.

            Alice                 Application                  Bob
              | F1 INVITE              |                        |
              |----------------------->|                        |
              |                        | F2 INVITE              |
              |                        |----------------------->|
              |                        | F3 180 Ringing         |
              |                        |<-----------------------|
              | F4 180 Ringing         |                        |
              |<-----------------------|                        |
              |                        |                        |
              |                        | F5 REFER sip:Bob-GRUU  |
              |                        |    To: sip:Bob-GRUU    |
              |                        |    Refer-To:           |
              |                        |     urn:sip-action:call:answer
              |                        |    Target-Dialog: dialog1
              |                        |----------------------->|
              |                        | F6 202 (REFER)         |
              |                        |<-----------------------|
              |                        |                        |
              |                        |                        |
              |                        | F7 200 OK              |
              |                        |<-----------------------|
              | F8 200 OK              |                        |
              |<-----------------------|                        |
              | F9 ACK                 |                        |
              |----------------------->|                        |
              |                        | F10 ACK                |
              |                        |----------------------->|
              |                        |                        |
              |                        |                        |
              |                        | F11 NOTIFY             |
              |                        |<-----------------------|
              |                        |                        |
              |                        | F12 200 OK             |
              |                        |----------------------->|
              |                        |                        |





Shekh-Yusef, et al.      Expires July 18, 2011                 [Page 18]


INTERNET DRAFT              Action Referral             January 14, 2011


6.2.  Terminate Call Operation

   Terminate Call is a perfect example of an action 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 terminate the call 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:sip-action:call:terminate               |
           |     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)             |                            |
           |----------------------------->|                            |

         Terminate Call in Established Dialog Call Flow Example
















Shekh-Yusef, et al.      Expires July 18, 2011                 [Page 19]


INTERNET DRAFT              Action Referral             January 14, 2011


   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:sip-action:call:terminate               |
           |     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)             |                            |
           |----------------------------->|                            |

            Terminate Call in Early Dialog Call Flow Example






Shekh-Yusef, et al.      Expires July 18, 2011                 [Page 20]


INTERNET DRAFT              Action Referral             January 14, 2011


   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:sip-action:call:terminate               |
           |     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)             |                            |
           |----------------------------->|                            |

               Terminate Call Initiated Call Flow Example



Shekh-Yusef, et al.      Expires July 18, 2011                 [Page 21]


INTERNET DRAFT              Action Referral             January 14, 2011


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


8.  IANA Considerations

   TODO: Need to register urn namespace according to procedures of
   [RFC3406].


9.  Acknowledgments

   TODO


10.  References


10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.


10.2  Informative 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
              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.




Shekh-Yusef, et al.      Expires July 18, 2011                 [Page 22]


INTERNET DRAFT              Action Referral             January 14, 2011


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

   [RFC5629]  Rosenberg, J., "A Framework for Application Interaction in
              the Session Initiation Protocol  (SIP)", RFC 5629,
              October 2009.

   [RFC5627]  Rosenberg, J., "Obtaining and Using Globally Routable User
              Agent (UA) URIs (GRUU) in the  Session Initiation
              Protocol (SIP)", RFC 5627, October 2009.

   [RFC5850]  Mahy, R., "A Call Control and Multi-party usage framework
              for the Session Initiation  Protocol (SIP)", RFC 5850,
              May 2010.

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










Shekh-Yusef, et al.      Expires July 18, 2011                 [Page 23]


INTERNET DRAFT              Action Referral             January 14, 2011


Author's Addresses



   Rifaat Shekh-Yusef
   Avaya
   250 Sidney Street
   Belleville, Ontario K8P 5B7
   Canada

   Phone: +1-613-967-5267
   Email: rifatyu@avaya.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


   Alan Johnston
   Avaya
   St. Louis, MO  63124
   USA

   Email: alan.b.johnston@gmail.com


   Francois Audet
   Skype
   USA

   Email: francois.audet@skype.net













Shekh-Yusef, et al.      Expires July 18, 2011                 [Page 24]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/