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