SIPPING J. Rosenberg
Internet-Draft dynamicsoft
Expires: April 19, 2004 October 20, 2003
Requirements for Construction and Usage of Globally Routable User
Agent (UA) URIs for the Session Initiation Protocol (SIP)
draft-rosenberg-sipping-gruu-reqs-01
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 19, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
Several applications of the Session Initiation Protocol (SIP) require
a user agent (UA) to construct and distribute a URI which can be used
by anyone on the Internet to route a call to that specific UA
instance. A URI which routes to a specific UA instance is called a
Globally Routable UA URI (GRUU). This document presents some
motivating use cases for GRUUs, and presents some requirements for
their construction and usage.
Rosenberg Expires April 19, 2004 [Page 1]
Internet-Draft GRUU Requirements October 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Defining a GRUU . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 REFER . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Conferencing . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3 Presence . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4 An Alternative to Dialog Reuse . . . . . . . . . . . . . . . . 5
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Requirements . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
Informative References . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . 9
Rosenberg Expires April 19, 2004 [Page 2]
Internet-Draft GRUU Requirements October 2003
1. Introduction
Several applications of the Session Initiation Protocol (SIP) [1]
require a user agent (UA) to construct and distribute a URI which can
be used by anyone on the Internet to route a call to that specific UA
instance. An example of such an application is call transfer, based
on the REFER method [8]. Another application is the usage of
endpoint-hosted conferences within the conferencing framework [2]. We
call these URIs Globally Routable UA URIs (GRUU).
This document formally defines a GRUU, presents motivating use cases,
and introduces requirements for their construction and usage.
2. Defining a GRUU
A GRUU is a SIP URI which has a specific set of characteristics:
Global: It can be used by any UAC connected to the Internet. In
that regard, it is like an address-of-record (AOR) for a user. The
address-of-record for a user, sip:joe@example.com, is meant to be
used by anyone to call that user. The same is true for a GRUU.
Temporally Scoped: It may be temporally scoped. In that regard,
its not like an AOR for a user. The general assumption is that an
AOR for a user is valid so long as the user resides within that
domain (of course, policies can be imposed to limit its validity,
but that is not the default case). However, a GRUU has a limited
lifetime by default. It can never be valid for longer than the
duration of the registration of the UA to which it is bound. For
example, if my PC registers to the SIP network, a GRUU for my PC
is only valid as long as my PC is registered. If the PC
unregisters, the GRUU is invalid; calls to it would result in a
404. If the PC comes back, the GRUU may or may not be valid once
more. Furthermore, it will frequently be the case that the GRUU
has a lifetime shorter than the duration of the registration.
Instance Routing: It routes to a specific UA instance, and never
forks. In that regard, it is unlike an address-of-record. When a
call is made to a normal AOR which represents a user, routing
logic is applied in proxies to deliver the call to one or more
UAs. That logic can result in a different routing decision based
on the time-of-day, or the identity of the caller. However, when a
call is made to a GRUU, the routing logic is much more static. It
has to cause the call to be delivered to a very specific UA
instance. That UA instance has to be the same UA instance
throughout the lifetime of the GRUU. This does not mean that a
GRUU represents a fundamentally different type of URI; it only
means that the logic a proxy applies to a GRUU is going to
Rosenberg Expires April 19, 2004 [Page 3]
Internet-Draft GRUU Requirements October 2003
generally be simpler than that it applies to a normal AOR.
3. Use Cases
We have encountered several use cases for a GRUU.
3.1 REFER
Consider a blind transfer application [6]. User A is talking to user
B. A wants to transfer the call to user C. So, it sends a REFER to
user C. That REFER looks like, in part:
REFER sip:C@example.com SIP/2.0
From: sip:A@example.com;tag=99asd
To: sip:C@example.com
Refer-To: (URI that identifiers B's UA)
The Refer-To header needs to contain a URI that can be used by C to
place a call to B. However, this call needs to route to the specific
UA which B is using to talk to A. If it didn't, the transfer service
would not execute. This URI is provided to A by B. Because B doesn't
know who A will transfer the call to, the URI has to be usable by
anyone. Therefore, it is a GRUU.
3.2 Conferencing
A similar need arises in conferencing [2]. In that framework, a
conference is described by a URI which identifies the focus of the
conference. The focus is a SIP UA at the center of a conference. Each
conference participant has a dialog with the focus. One case
described in the framework is where a user A has made a call to B.
They then put B on hold, and call C. Now, A has two separate dialogs
for two separate calls - one to B, and one to C. A would like to
conference them. One model is that A morphs itself into a focus. It
sends a re-INVITE on each existing dialog, and provides both B and C
with an updated URI that now holds the conference URI. It also has a
callee capabilities [3] parameter which indicates that this URI is a
conference URI. A proceeds to mix the media streams from B and C.
This is called an ad-hoc conference.
At this point, normal conferencing features can be applied. That
means that B can send another user, D, the conference URI, perhaps in
an email. D can send an INVITE to that URI, and join the conference.
For this to work, the conference URI used by A in its re-INVITE has
to be usable by anyone, and it has to route to the specific UA
instance of A that is acting as the focus. If it didn't, basic
conferencing features would fail. Therefore, it is a GRUU.
Rosenberg Expires April 19, 2004 [Page 4]
Internet-Draft GRUU Requirements October 2003
3.3 Presence
In a SIP-based presence [7] system, the presence agent (PA) generates
notifications about the state of a user. This state is represented
with the Presence Information Document Format (PIDF) [5]. In a PIDF
document, a user is represented by a series of tuples, each of which
identifies the devices that the user has and provides information
about them. Each tuple also has a contact URI, which is a SIP URI
representing that device. A watcher can make a call to that URI, with
the expectation that the call is routed to the device whose presence
is represented in the tuple.
The URI in the presence document therefore has to route to the
specific UA instance whose presence was reported. Furthermore, since
the presence document could be used by anyone who subscribes to the
user, the URI has to be usable by anyone. As a result, it is a GRUU.
It is interesting to note that, in this case, the GRUU needs to be
constructed by a presence agent. This may be a server in the network,
or may be on an end-device, such as a PC.
3.4 An Alternative to Dialog Reuse
RFC 3261 describes a concept called dialog reuse. This feature allows
a dialog, created by a SUBSCRIBE or INVITE request, to be reused for
other methods which normally would create a dialog. The common use
case is when there is an INVITE-initiated dialog between UA 1 and UA
2, and UA 1 wishes to SUBSCRIBE to the dialog event package [4] for
UA 2. This subscription has to reach UA 2, not any of the other UAs
representing the user. To do that, a SUBSCRIBE is sent on the dialog
created by the INVITE.
However, since the publication of RFC 3261, many problems have been
discovered with dialog reuse. Lifecycle management of the dialogs
becomes much more complex. The dialog needs to exist so long as there
is some kind of "application state" still in usage on that dialog.
This makes it hard to determine when the dialog has terminated.
Secondly, it is confusing to entities, such as UAs, proxies, and
B2BUAs, which had formally equated dialog state with call state. This
has been a common assumption in many implementations, and would now
be broken.
GRUUs provide an alternative and easier means for achieving the same
effect. Instead of launching the SUBSCRIBE on the same dialog, the
SUBSCRIBE would be sent to the GRUU for UA 2. Thus, there are now
separate dialogs for the session and for the subscription. We could
deprecate dialog reuse.
Rosenberg Expires April 19, 2004 [Page 5]
Internet-Draft GRUU Requirements October 2003
4. Requirements
The following requirements pertain to the construction and usage of a
GRUU:
REQ 1: When a UA invokes a GRUU, it MUST cause the request to be
routed to the specific UA instance to which the GRUU refers.
REQ 2: It MUST be possible for a GRUU to be invoked from anywhere on
the Internet, and still cause the request to be routed
appropriately. That is, a GRUU MUST NOT be restricted to use
within a specific addressing realm.
REQ 3: It MUST be possible for a GRUU to be constructed without
requiring the network to store additional state.
REQ 4: It MUST be possible for a UA to obtain a multiplicity of
GRUUs, each one of which routes to that UA instance. This is
needed to support ad-hoc conferencing, for example, where a a UA
instance needs a different URI for each conference it is hosting.
REQ 5: When a UA receives a request sent to a GRUU, it MUST be
possible for the UA to know the GRUU which was used to invoke the
request. This is necessary as a consequence of requirement 4.
REQ 6: It MUST be possible for a UA to add opaque content to a GRUU,
which is not interpreted or altered by the network, and used only
by the UA instance to whom the GRUU refers. This provides a basic
cookie type of functionality, allowing a UA to build a GRUU with
state embedded within it.
REQ 7: It MUST be possible for a proxy to execute services and
features on behalf of a UA instace represented by a GRUU. As an
example, if a user has call blocking features, a proxy may want to
apply those call blocking features to calls made to the GRUU in
addition to calls made to the user's AOR.
REQ 8: It MUST be possible for a UA in a dialog to inform its peer of
its GRUU, and for the peer to know that the URI represents a GRUU.
This is needed for the conferencing and dialog reuse applications
of GRUUs, where the URIs are transferred within a dialog.
REQ 9: When transferring a GRUU per requirement 8, it MUST be
possible for the UA receiving the GRUU to be assured of its
integrity and authenticity.
Rosenberg Expires April 19, 2004 [Page 6]
Internet-Draft GRUU Requirements October 2003
REQ 10: It MUST be possible for a server, authoritative for a domain,
to construct a GRUU which routes to a UA instace bound to an AOR
in that domain. In other words, the proxy can construct a GRUU
too. This is needed for the presence application.
5. Security Requirements
When transferring a GRUU from one UA to another UA within the same
dialog, a man-in-the-middle could modify the GRUU, resulting in
subsequent calls (such as a transfer) to that user actually
misrouting the call to the attacker. This means that mechanisms need
to be in place for the recipient of a GRUU to verify the integrity
and authenticity of the GRUU. This is covered in REQ 9.
6. Acknowledgements
The author would like to thank Rohan Mahy, Paul Kyzivat, Alan
Johnston, and Cullen Jennings for their contributions to this work.
Informative 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] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol",
draft-ietf-sipping-conferencing-framework-00 (work in progress),
May 2003.
[3] Rosenberg, J., "Indicating User Agent Capabilities in the
Session Initiation Protocol (SIP)",
draft-ietf-sip-callee-caps-00 (work in progress), June 2003.
[4] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog
Event Package for the Session Initiation Protocol (SIP",
draft-ietf-sipping-dialog-package-02 (work in progress), July
2003.
[5] Fujimoto, S. and H. Sugano, "Presence Information Data Format
(PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May
2003.
[6] Sparks, R. and A. Johnston, "Session Initiation Protocol Call
Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in
progress), February 2003.
Rosenberg Expires April 19, 2004 [Page 7]
Internet-Draft GRUU Requirements October 2003
[7] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work
in progress), January 2003.
[8] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
Author's Address
Jonathan Rosenberg
dynamicsoft
600 Lanidex Plaza
Parsippany, NJ 07054
US
Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net
Rosenberg Expires April 19, 2004 [Page 8]
Internet-Draft GRUU Requirements October 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Rosenberg Expires April 19, 2004 [Page 9]
Internet-Draft GRUU Requirements October 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Rosenberg Expires April 19, 2004 [Page 10]