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]