SIPPING J. Rosenberg
Internet-Draft dynamicsoft
Expires: August 13, 2003 February 12, 2003
URI Leasing in the Session Initiation Protocol (SIP)
draft-rosenberg-sipping-lease-00
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 August 13, 2003.
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. An example of such an application is call transfer, based
on the REFER method. To date, a variety of techniques have been
proposed for the contruction of such URI. All of them have fatal
drawbacks. This document proposes that the problem is actually one
of URI leasing - a feature whereby a UA can dynamically request the
creation of an address-of-record (AOR) within a domain. Requirements
for a URI leasing mechanism are outlined.
Rosenberg Expires August 13, 2003 [Page 1]
Internet-Draft URI Leasing February 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Defining a GRUU . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 REFER . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Conferencing . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3 Presence . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . . 8
4.1 Host IP or FQDN . . . . . . . . . . . . . . . . . . . . . . . 8
4.2 User AOR . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3 Caller Preferences . . . . . . . . . . . . . . . . . . . . . . 9
4.4 Embedded Route Header Field . . . . . . . . . . . . . . . . . 9
5. Implications of GRUU . . . . . . . . . . . . . . . . . . . . . 11
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Example Mechanism . . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
Informative References . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . 22
Rosenberg Expires August 13, 2003 [Page 2]
Internet-Draft URI Leasing February 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 [7]. Another application is the usage of
endpoint-hosted conferences within the conferencing framework [2].
We call these URIs Globally Routable UA URIs (GRUU).
To date, a variety of techniques have been proposed for the
contruction of such URI. All of them have fatal drawbacks. Section
2 formally defines a GRUU by three specific properties. Section 3
describes the cases where a GRUU is needed. Section 4 describes the
solutions proposed to date. Section 5 argues that the problem is one
of leasing. Section 6 provides requirements for a leasing mechanism,
and Section 7 discusses a potential solution.
Rosenberg Expires August 13, 2003 [Page 3]
Internet-Draft URI Leasing February 2003
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 decisio 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.
These three properties are guaranteed by the creator of the GRUU.
That means they will be exhibited with 100 percent certainty, within
the bounds of an operational network. They are not probabilistic
guarantees; they don't just work sometimes. They ALWAYS work as
advertised. Such a guarantee is important for reliable service
offerings using a GRUU. As the examples below show, many features
rely on these GRUU properties. If they are not always provided, the
services will not always work.
We believe there is a need to provide reliable versions of these
services, and therefore, there is a need for a mechanism to construct
a GRUU so that it has these properties with complete certainty. It
is very important to understand that it is the responsibility of the
element which constructs the GRUU to do so in a fashion which
Rosenberg Expires August 13, 2003 [Page 4]
Internet-Draft URI Leasing February 2003
guarantees these properties.
Rosenberg Expires August 13, 2003 [Page 5]
Internet-Draft URI Leasing February 2003
3. Use Cases
We have encountered at least three use cases for a GRUU. These are
for REFER, for conferencing, and for presence.
3.1 REFER
Consider a blind transfer application [5]. 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 Contact URI that now holds the conference URI. It
also has a caller preferences [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 August 13, 2003 [Page 6]
Internet-Draft URI Leasing February 2003
3.3 Presence
In a SIP-based presence [6] system, the presence agent (PA) generates
notifications about the state of a user. This state is represented
with the Presence Information Document Format (PIDF) [4]. 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.
Rosenberg Expires August 13, 2003 [Page 7]
Internet-Draft URI Leasing February 2003
4. Proposed Solutions
Several solutions have been proposed for the construction of a GRUU.
Some are documented in the transfer [5] specification. In this
section, we review the four solutions proposed to date and show the
drawbacks of each.
4.1 Host IP or FQDN
The most obvious solution is to construct a URI of the form sip:host,
where host is the FQDN of the host, or its IP address, where the UA
instance is running. However, this solution has many problems:
The UA may be running on a private network. Therefore, a URI
constructed in this fashion will not be usable by anyone on the
public Internet.
Even if the UA is running on a public network, there may be
firewalls preventing direct connection to a host on the inside.
The domain in which the host resides may have policies that
require all calls to it to pass through certain proxies. This may
be needed for logging or features (for example, automatic
recording of all calls). A direct call to the host would bypass
those proxies and therefore violate this policy. A domain would
typically deploy a firewall to enforce the policy.
The URI continues to be valid even if the UA instance un-registers
in its domain. That violates the second property of a GRUU.
For these reasons, it is clear that a host FQDN or IP address will
not work.
4.2 User AOR
Another solution that has been proposed is to use the AOR of the user
on whose behalf the device is registered (sip:B@example.com, for
example). This also has many obvious problems:
Call routing within the example.com network might deliver that
INVITE to a completely separate UA each time a call is made. This
violates the critical third characteristic of a GRUU.
The element constructing the GRUU may not wish to reveal its AOR
to the caller. As an example, consider the REFER case above.
Lets say A called a customer service number. This was routed by a
call center application to an operator, and the operator's cell
phone was rung. The operator needs to provide the caller a GRUU
Rosenberg Expires August 13, 2003 [Page 8]
Internet-Draft URI Leasing February 2003
so that the caller can transfer users to it. However, the
operator does not want the caller to know their identity.
Since the GRUU equals the AOR of the user, it has an unbounded
temporal scope. This violates the second GRUU property.
Therefore, the user's AOR cannot be used as a GRUU.
4.3 Caller Preferences
Another proposed solution is to use the SIP caller preferences [3]
specification. If a user sip:A@example.com has a device running on
the IP address 192.0.2.1, the GRUU would be constructed as
sip:A@example.com?Accept-Contact=*%3Buri-domain=%x22192.0.2.1%x22.
When a UAC sends an INVITE to this URI, it results in a request that
includes the Accept-Contact header field:
INVITE sip:A@example.com SIP/2.0
Accept-Contact: *;uri-domain="192.0.2.1"
This URI will provide the temporal scoping property of a GRUU. If
the UA instance should unregister, the caller preferences mechanism
will result in the rejection of the request with a 480 (not a 404
though), no matter what the internal routing looks like. The URI is
also globally usable because it is based on a user AOR.
However, the UA instance routing property cannot be guaranteed.
Within the example.com domain, this request would be routed to the
correct UA instance if the routing policy were based solely on UA
registrations, coupled with static routing policy before the proxy
which uses the registrations. However, the routing policy at
example.com may be more complex, such that the request is never
forwarded to the UA instance at 192.0.2.1. The call center agent is
a good example of this case.
Therefore, although this mechanism will work in some cases, it is not
a reliable way to guarantee the UA instance routing property.
Because there are no guarantees, this mechanism cannot be used to
create a GRUU.
4.4 Embedded Route Header Field
Another solution that has been proposed is to include embedded route
headers in a URI. Considering once more the case of a user
sip:A@example.com with a UA running at 192.0.2.1, the URI would look
like sip:A@example.com?Route=sip:192.0.2.1;lr.
This solution is very similar to the caller preferences based
Rosenberg Expires August 13, 2003 [Page 9]
Internet-Draft URI Leasing February 2003
solution above. However, it has similar problems. It only works
under the assumption that the domain policy allows a request to be
routed directly to a UA instance once it has been processed by the
first proxy in that domain. This may not be true in large
enterprises that have created sub-domains, for example, and require
the request to pass through a multiplicity of servers.
This solution does not provide the temporal scoping property either.
Even if the UA is unregistered (but still running), the request will
be delivered to it.
However, this mechanism does provide the global usability
characteristic.
Rosenberg Expires August 13, 2003 [Page 10]
Internet-Draft URI Leasing February 2003
5. Implications of GRUU
Although the characteristics of a GRUU are simple, they have
important implications that impact the mechanism that can be used to
obtain them. Because they need to always work, they must be
allocated in a way which is always consistent with the routing rules
and topology of the domain in which the GRUU resides. All of the
mechanisms that have been proposed fail because they are attempts at
constructing a GRUU by an entity which is not authoritative over the
namespace. Only the owner of the namespace (identified by the domain
portion of the GRUU) can create a GRUU and guarantee it has the
desired properties.
This means that the GRUU needs to be constructed in cooperation with
the administrators of the domain. It cannot be "guessed", as most of
the mechanisms above try to do. One must explicitly ask for a GRUU.
Otherwise, there is no way to guarantee that a GRUU always works.
Indeed, the problem with guessing is clear from a read of the call
transfer spec. Since the transferor is creating the GRUU, and is
doing so without acting in concert with the domain in which it
resides, there is no guarantee it will work. Therefore, the transfer
spec is forced to recommend a trial-and-error tactic, having the
transferor cycle through several mechanisms, hoping one will work.
It is possible none of them will work, and even if one does, it may
substantially increase call setup to try several others first.
Furthermore, a GRUU needs to be allocated from a domain to which the
UA is registering, or capable of registering. When a UA successfully
registers, it knows that calls to its AOR will reach it. That is the
service guarantee that is provided by the domain. The implication is
that the UA knows for certain that this domain is capable of
providing a URI that can route to it. Since a GRUU also has to route
to it, it knows that this domain is capable of providing a URI which
has the routing properties of a GRUU.
[[OPEN ISSUE: This is a weak argument. A succesful registration
does not imply that the registration works. I am trying to find a
way to say that you can't just get a GRUU from any domain. If I
work for example.com, and they have lots of firewalls and policies
set up, I can't try to allocate a GRUU from example.org.]]
Therefore, we conclude that the problem of GRUU allocation is that of
URI leasing. An entity that wishes to obtain a GRUU is asking their
domain to allocate them a new address-of-record, which will be used
by the entity to register its UA instance. Its a lease, and not a
purchase, because the URI is temporary. It identifies a UA only. A
GRUU is never placed on a business card or on a web page. They are
Rosenberg Expires August 13, 2003 [Page 11]
Internet-Draft URI Leasing February 2003
handed out through protocol mechanisms, and they always have a
bounded lifetime. Indeed, an enforcement of that lifetime is part of
the lease itself.
Rosenberg Expires August 13, 2003 [Page 12]
Internet-Draft URI Leasing February 2003
6. Requirements
Given that the construction of a GRUU is a leasing operation, the
implication is that there is a protocol between the entity that wants
a GRUU (the acquirer), and the domain which provides it. In this
section, we present requirements for such a protocol.
REQ 1: It must be possible for an acquirer to obtain a URI from
its domain, which is an address-of-record, for which the domain
guarantees the GRUU properties.
REQ 2: It must be possible for an acquirer to specify the desired
duration of the lease.
REQ 3: It must be possible for the domain to indicate a lower
duration for the lease than requested by the client.
. Since the domain is the one expending the effort here, it
should have final say in how long the lease lasts. It is similar
to registrations in that regard.
REQ 4: It must be possible for an acquirer to refresh its lease,
so that it can keep the same URI.
This makes sure that the GRUU is valid for as long as the acquirer
needs it to be. For example, for the duration of the conference
in an endpoint hosted conference.
REQ 5: When the lease expires, requests for that URI will fail
with a 404.
This provides the temporal validity characteristic which is core
to a GRUU.
REQ 6: It must be possible for the domain to specify the format of
the URI.
The domain is the one that needs to make sure that requests for
that AOR are routed properly. So, we need to make sure that the
domain has the flexibility to construct the GRUU in whichever way
it likes.
REQ 7: The mechanism must not require any provisioning overhead in
the domain.
For example, we don't want to mandate the domain administrator to
provision identities for the phones used by its customers.
Rosenberg Expires August 13, 2003 [Page 13]
Internet-Draft URI Leasing February 2003
REQ 8: It should be possible for a domain to create a GRUU without
requiring any additional network state to store it, or any
registrations bound to it. This requirement may be met
conditionally, such that it only applies for certain registration
cases.
. This requires some explanation. In SIP networks today, the
administrator incurs overhead for storing and managing
registration state. Now, if every single UA in the network leases
an additional URI, and registers against it, the domain requires
double the registration state that it did previously. We'd like
to avoid that if possible.
REQ 9: It must be possible for the acquirer to obtain a GRUU which
does not reveal anything about the identity of the acquirer.
This is needed for cases where the called party wishes to remain
anonymous, and yet hand out a GRUU.
REQ 10: It must be possible for features to be associated with a
GRUU, just like a user AOR in the domain.
This covers the case where an enterprise wants to have call
screening turned on for all incoming calls, whether they are made
to the user or their device.
REQ 11: It must be possible for an acquirer to obtain an
infinitely large range of URIs, from which the acquirer can create
specific URIs at will, without protocol operations.
This requirement is important for latency and scale reasons.
Every time a UA makes a call, it will need to insert a GRUU into
the Contact header field of its INVITE, and every time it answers
a call, it places one into the 200 OK of that INVITE. It will
probably want to use a different GRUU in each call, to help limit
the validity of the GRUU to the duration of that call. It is
unacceptable for there to be a protocol operation every time this
happens. Therefore, the UA has to be able to obtain a block of
URIs at one time, and then create URIs out of that block until the
lease on the block expires (it can of course be refreshed).
REQ 12: It must be possible for the domain to authenticate the
identity of the acquirer.
REQ 13: It must be possible for the acquirer to authenticate the
identity of the domain.
Rosenberg Expires August 13, 2003 [Page 14]
Internet-Draft URI Leasing February 2003
REQ 14: It must be possible for the acquirer to verify the
integrity of the message sent by the domain containing the GRUU
which has been leased.
REQ 15: It must be possible for a user to query for the GRUUs
which it has leased, and learn when they expire, and what URI are
registered to them.
Rosenberg Expires August 13, 2003 [Page 15]
Internet-Draft URI Leasing February 2003
7. Example Mechanism
This section presents an example mechanism to illustrate how the
requirements might be met. It is still incomplete, but is a useful
tool for understanding.
One approach is to define a new SIP method called LEASE. It is far
from clear that the mechanism should be based on SIP. It has many of
the same properties of REGISTER, which would argue for a SIP method
(if REGISTER is, why not this). Then again, many argue that REGISTER
should never have been a SIP method in the first place. For example
purposes, SIP is used.
The LEASE method operates much like REGISTER. The request URI
identifies the domain (no user part) from which the lease is desired.
The From field identifies the client who is asking for the lease.
The To field, unlike REGISTER, identifies the domain, just like the
request-URI does. The LEASE request contains an Expires header
field, indicating the desired duration of the lease. The 200 OK
response contains a Lease header field, which contains a URI
template. The URI template is like a SIP URI, but provides a
wildcard character, into which the UA is free to place any URI
characters it wants. Any URI constructed by the client will be
treated as an AOR by the domain.
The LEASE request can also optionally take a Contact header field,
which has to have a single value. When present, the server will
simultaneously create the GRUU, and create a registration which maps
it (in fact, which maps ALL URI constructed by the template) to that
Contact header field. As a result, the LEASE method can also perform
registrations.
The 200 OK to LEASE will contain a Lease header field, whose values
are all the GRUU which have been leased to that user. Each one has a
contact parameter that indicates the contact registered to that GRUU,
if any. These contacts are only those bound to the GRUU through the
LEASE method. If a user performs a normal REGISTER against a GRUU,
and there is a contact already bound to it through the LEASE, the
REGISTER is rejected with a 409.
When the client refreshes its lease, it sends a LEASE request and
includes a Lease header field containing the URI template that is to
be refreshed. If the client already has that GRUU leased, the server
treats the request as a refresh. If not, it treats it as a request
to lease that GRUU. If the server wishes to accept the request, it
generates a 200 OK. Otherwise, it generates an TBD response code to
indicate that that particular GRUU cannot be leased. Figure 3
Rosenberg Expires August 13, 2003 [Page 16]
Internet-Draft URI Leasing February 2003
A Proxy B C
|(1) LEASE | | |
|------------->| | |
|(2) 200 OK | | |
|<-------------| | |
|(3) REGISTER | | |
|------------->| | |
|(4) 200 OK | | |
|<-------------| | |
|(5) INVITE | | |
|------------->| | |
| |(6) INVITE | |
| |------------->| |
| |(7) 200 OK | |
| |<-------------| |
|(8) 200 OK | | |
|<-------------| | |
|(9) ACK | | |
|---------------------------->| |
| | |(10) REFER |
| | |------------->|
| | |(11) 202 |
| | |<-------------|
| |(12) INVITE | |
| |<----------------------------|
|(13) INVITE | | |
|<-------------| | |
|(14) 200 OK | | |
|------------->| | |
| |(15) 200 OK | |
| |---------------------------->|
|(16) ACK | | |
|<-------------------------------------------|
| | |(17) NOTIFY |
| | |<-------------|
| | |(18) 200 OK |
| | |------------->|
|(19) BYE | | |
|<----------------------------| |
|(20) 200 OK | | |
|---------------------------->| |
Figure 3
The LEASE request (message 1) would look like:
Rosenberg Expires August 13, 2003 [Page 17]
Internet-Draft URI Leasing February 2003
LEASE sip:example.com SIP/2.0
From: sip:A@example.com;tag=988asd
To: sip:example.com
Call-ID: asdhh77766as00098
CSeq: 1 LEASE
Contact: sip:192.0.2.1
Via: SIP/2.0/UDP 192.0.2.1
Expires: 30000
and its response:
SIP/2.0 200 OK
From: sip:A@example.com;tag=988asd
To: sip:example.com
Lease: sip:*.dskkia99s88a77dll===00asd887jjja7s@example.com
;contact=sip:192.0.2.1
Call-ID: asdhh77766as00098
CSeq: 1 LEASE
Via: SIP/2.0/UDP 192.0.2.1
Expires: 30000
In this case, the lease is for a template, with the * as the
wildcard. When the client registers, it actually registers the GRUU,
and not its IP address (message 3):
REGISTER sip:example.com SIP/2.0
From: sip:A@example.com;tag=9877asd
To: sip:A@example.com
Call-ID: asdhh77766as00099
CSeq: 1 REGISTER
Contact: sip:XYZ.dskkia99s88a77dll===00asd887jjja7s@example.com
Via: SIP/2.0/UDP 192.0.2.1
Expires: 3600
The client instantiated the template with an XYZ. Next, the client
sends an INVITE. It includes, in the Contact header field of its
INVITE, another GRUU which it creates from the template:
INVITE sip:B@example.com SIP/2.0
From: sip:A@example.com;tag=9877ase
To: sip:B@example.com
Call-ID: asdhh77766as0009a
CSeq: 1 INVITE
Contact: sip:ABC.dskkia99s88a77dll===00asd887jjja7s@example.com
Via: SIP/2.0/UDP 192.0.2.1
After the call is setup, B wishes to transfer A to C. So, it chooses
to send a REFER to C (message 10), which looks like:
Rosenberg Expires August 13, 2003 [Page 18]
Internet-Draft URI Leasing February 2003
REFER sip:C@example.com SIP/2.0
From: sip:B@example.com;tag=9877ase
To: sip:C@example.com
Call-ID: asdhh77766as0009b
Event: refer
CSeq: 1 REFER
Refer-To: sip:ABC.dskkia99s88a77dll===00asd887jjja7s@example.com
Via: SIP/2.0/UDP 192.0.2.1
Notice that the Refer-To URI is taken directly from the Contact URI
of the INVITE. Now, when C calls this URI, it is routed to the
example.com proxy, and from there, to sip:192.0.2.1.
Rosenberg Expires August 13, 2003 [Page 19]
Internet-Draft URI Leasing February 2003
8. Security Considerations
Security requirements are discussed above where relevant.
Rosenberg Expires August 13, 2003 [Page 20]
Internet-Draft URI Leasing February 2003
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-rosenberg-sipping-conferencing-framework-00 (work in
progress), November 2002.
[3] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP) Caller Preferences and Callee Capabilities",
draft-ietf-sip-callerprefs-07 (work in progress), November 2002.
[4] Fujimoto, S. and H. Sugano, "Common Presence and Instant
Messaging (CPIM)Presence Information Data Format",
draft-ietf-impp-cpim-pidf-06 (work in progress), November 2002.
[5] Sparks, R. and A. Johnston, "Session Initiation Protocol Call
Control - Transfer", draft-ietf-sipping-cc-transfer-00 (work in
progress), October 2002.
[6] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", draft-ietf-simple-presence-09 (work
in progress), December 2002.
[7] Sparks, R., "The SIP Refer Method", draft-ietf-sip-refer-07
(work in progress), December 2002.
Author's Address
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
East Hanover, NJ 07936
US
Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net
Rosenberg Expires August 13, 2003 [Page 21]
Internet-Draft URI Leasing February 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 August 13, 2003 [Page 22]
Internet-Draft URI Leasing February 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 August 13, 2003 [Page 23]