SIP J. Rosenberg
Internet-Draft Cisco Systems
Expires: April 16, 2007 October 13, 2006
Applying Loose Routing to Session Initiation Protocol (SIP) User Agents
(UA)
draft-rosenberg-sip-ua-loose-route-00
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 16, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
A key part of the behavior of the Session Initiation Protocol (SIP)
is that SIP proxies rewrite the Request-URI as a request moves
throughout the network. Over the years, experience has shown this to
be problematic. It makes it difficult to use Request URI for service
invocation, complicates emergency services, makes it more complex to
support aliases, and so on. Architecturally, it confounds the
concepts of address and route. This document proposes to change this
through a new mechanism called UA loose routing.
Rosenberg Expires April 16, 2007 [Page 1]
Internet-Draft UA Loose Routing October 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Unknown Aliases . . . . . . . . . . . . . . . . . . . . . 3
2.2. Unknown GRUU . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Limited Use Addresses . . . . . . . . . . . . . . . . . . 4
2.4. Sub-Addressing . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Service Invocation . . . . . . . . . . . . . . . . . . . . 6
2.6. Emergency Services . . . . . . . . . . . . . . . . . . . . 6
2.7. Freephone Numbers . . . . . . . . . . . . . . . . . . . . 6
3. Architectural Roots of the Problem . . . . . . . . . . . . . . 7
4. Alternative Solutions . . . . . . . . . . . . . . . . . . . . 8
4.1. What about the To header field? . . . . . . . . . . . . . 8
4.2. History Info . . . . . . . . . . . . . . . . . . . . . . . 9
5. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 10
6. Backwards Compatibility Considerations . . . . . . . . . . . . 11
7. Minting AORs and GRUU . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Rosenberg Expires April 16, 2007 [Page 2]
Internet-Draft UA Loose Routing October 2006
1. Introduction
A key part of the behavior of proxy servers in the Session Initiation
Protocol (SIP) [1] is that they rewrite the Request-URI of requests
as the request moves from the User Agent Client (UAC) to the User
Agent Server (UAS). This is particularly true for requests outside
of a dialog; requests within a dialog have their path dictated
primarily by the Route header fields established by the Record-Routes
when the dialog was initiated.
The most basic instance of this behavior is the processing executed
by the "home proxy" within a domain. The home proxy is the proxy
server within a domain which accesses the location information
generated by REGISTER messages, and uses it to forward a request
towards a UAC. Based on the rules in RFC 3261, when a home proxy
receives a SIP request, it looks up the Request-URI in the location
database, and translates it to the contact(s) that were registered by
the UA. This new contact URI replaces the existing Request URI, and
causes the request to be forwarded towards the target UA.
Consequently, the original contents of the Request URI are lost.
In addition to routing of SIP requests based on the contents of the
location database, proxies can employ other techniques. It is common
in practice to have proxies which perform prefix and number analysis
on the Request URI against configured tables in order to do routing.
It is also common practice to rewrite the Request-URI to point to an
application server, again based on configured mappings.
Over the years, this practice of rewriting the Request-URI has proven
problematic. Section 2 describes the problems with this mechanism.
Section 3 analyzes the architectural issues which drive these
problems. Section 4 discusses alternative solutions. Section 5
describes a proposed solution to this problem, a technique coined 'UA
loose routing'. [[OPEN ISSUE: A better name is needed here, since
the mechanism applies equally well to targeting proxies.]]
2. Problem Statement
Several problems arise from the practice of rewriting the request
URI.
2.1. Unknown Aliases
SIP user agents are associated with an address-of-record (AOR). It
is possible for a single UA to actually have multiple AOR associated
with it. One common usage for this is aliases. For example, a user
might have an AOR of sip:john@example.com but also have the AORs
Rosenberg Expires April 16, 2007 [Page 3]
Internet-Draft UA Loose Routing October 2006
sip:john.smith@example.com and sip:jsmith@example.com. Rather than
registering against each of these AORs individually, the user would
register against just one of them, and the home proxy would
automatically accept incoming calls for any of the aliases, treating
them identically and ultimately forwarding them towards the UA. This
is common practice in the Internet Multimedia Subsystem (IMS), where
it is called implicit registrations and each alias is called a public
identity.
It is a common requirement for a UAS, on receipt of a call, to desire
to know which of its aliases was used to reach it. This knowledge
can be used to choose ringtones to play, determine call treatment,
and so on. For example, a user might give out one alias to friends
and family only, resulting in a special ring that alerts the user to
the importance of the call.
However, based on the procedures in RFC 3261, when an incoming call
hits the home proxy, the request URI (which contains the alias) is
rewritten to the registered contact(s). Consequently, the alias that
was used is lost, and cannot be known to the UAS.
2.2. Unknown GRUU
A variation on the problem in Section 2.1 occurs with Globally
Routable User Agent URI (GRUU) [5]. A GRUU is a URI assigned to a UA
instance which has many of the same properties as the AOR, but causes
requests to be routed only to that specific instance. It is
desirable for a UA to know whether it was reached because a
correspondent sent a request to its GRUU or to its AOR. This can be
used to drive differing authorization policies on whether the request
should be accepted or rejected, for example. However, like the AOR
itself, the GRUU is lost in translation at the home proxy. Thus, the
UAS cannot know whether it was contacted via the GRUU or its AOR.
2.3. Limited Use Addresses
A limited use address is an SIP URI that is minted on-demand, and
passed out to a small number (usually one) remote correspondent.
Incoming calls targeted to that limited use address are accepted as
long as the UA still desires communications from the remote target.
Should they no longer wish to be bothered by that remote
correspondent, the URI is invalidated so that future requests
targeted to it are rejected.
Limited use addresses are used in battling voice spam [6]. The
easiest way to provide them would be for a UA to be able to take its
AOR, and "mint" a limited use address by appending additional
parameters to the URI. It could then give out the URI to a
Rosenberg Expires April 16, 2007 [Page 4]
Internet-Draft UA Loose Routing October 2006
particular correspondent, and remember that URI locally. When an
incoming call arrives, the UAS would examine the parameter in the URI
and determine whether or not the call should be accepted.
Alternatively, the UA could push authorization rules into the
network, so that it need not even see incoming requests that are to
be rejected.
This approach, especially when executed on the UA, requires that
parameters attached to the AOR, but not used by the home proxy in
processing the request, will survive the translation at the home
proxy and be presented to the UA. This will not be the case with the
logic in RFC 3261, since the Request-URI is replaced by the
registered contact, and any such parameters are lost.
2.4. Sub-Addressing
Sub-Addressing is very similar to limited use addresses. Sub-
addresses are addresses within a subdomain that are multiplexed into
a single address within a parent domain. The concept is best
illustrated by example. Consider a VoIP service provided to
consumers. A consumer obtains a single address from its provider,
say sip:family@example.com. However, Joe is the patriarch of a
family with four members, and would like to be able to have a
separate identifier for each member of his family. One way to do
that, without requiring Joe to purchase new addresses for each member
from the provider, is for Joe to mint additional URI by adding a
parameter to the AOR. For example, his wife Judy with have the URI
sip:family@example.com;member=judy, and Joe himself would have the
URI sip:family@example.com;member=joe. The SIP server provider would
receive requests to these URI, and ignoring the unknown parameters
(as required by RFC 3261) route the request to the registered
contact, which corresponds to a SIP server in Joes home. That
server, in turn, can examine the URI parameters and determine which
phone in the home to route the call to.
This feature is not specific to VoIP, and has existing in Integrated
Services Digital Networking (ISDN) for some time. It is particularly
useful for small enterprises, in addition to families. It is also
similar in spirit (though not mechanism) to the ubiquitous home
routers used by consumers, which allow multiple computers in the home
to "hide" behind the single IP address provided by the service
provider, by using the TCP and UDP port as a sub-address.
The sub-addressing feature is not currently feasible in SIP because
of the fact that any SIP URI parameter used to convey the sub-address
would be lost at the home proxy, due to the fact that the Request-URI
is rewritten there.
Rosenberg Expires April 16, 2007 [Page 5]
Internet-Draft UA Loose Routing October 2006
2.5. Service Invocation
Several SIP specifications have been developed which make use of
complex URIs to address services within the network rather than
subscribers. The URIs are complex because they contain numerous
parameters that control the behavior of the service. Examples of
this include the specification which first introduced the concept,
RFC 3087 [15], control of network announcements and IVR with SIP URI
[16], and control of voicemail access with SIP URI [17].
A common problem with all of these mechanisms is that once a proxy
has decided to rewrite the Request-URI to point to the service, it
cannot be sure that the Request-URI will not be destroyed by a
downstream proxy which decides to forward the request in some way,
and does so by rewriting the Request-URI.
2.6. Emergency Services
Another problem that arises from Request-URI rewriting is with
emergency services for VoIP. A key requirement of systems supporting
emergency calling is that the SIP INVITE request for an emergency
call be 'marked' in some way that makes it clear that it is an
emergency call, so that it can receive priority treatment [7].
However, such a marking needs to be done in a way that it cannot be
abused by attackers seeking to get special treatment for non-
emergency calls. The solution for this is that the marking needs to
be the target address of the request itself, which would
unambiguously identify an emergency services calltaker as the target.
The solution that has been agreed upon is the SOS URN [8] which takes
the form urn:service:sos. This URI appears the in the Request-URI of
the request emitted by the UA making the emergency services call, and
needs to remain in the Request-URI as the request is routed towards
the correct emergency services center (ESC) and eventually the target
call taker [9].
This mechanism will not work if any of the proxies along the way try
to rewrite the Request-URI for the purposes of directing the call to
a proxy or UA that will handle the call.
2.7. Freephone Numbers
Freephone numbers, also known as 800 or 8xx numbers in the United
States, are telephone numbers that are free for users to call
(although the author will note that such notions are becoming less
important as billing models evolve, and harken back to an era where
phone service depended on global agreement on such billing concepts).
In the telephone network, freephone numbers are just aliases to
actual numbers which are used for routing of the call. In order to
Rosenberg Expires April 16, 2007 [Page 6]
Internet-Draft UA Loose Routing October 2006
process the call in the PSTN, a switch will perform a query (using a
protocol called TCAP), which will return either a phone number or the
identity of a carrier which can handle the call.
There has been recent work on allowing such PSTN translation services
to be accessed by SIP proxy servers through IP querying mechanisms.
ENUM, for example [14] has already been proposed as a mechanism for
performing Local Number Portability (LNP) queries [10], and recently
been proposed for performing calling name queries [11]. Using it for
8xx number translations is a logical next-step.
Once such a translation has been performed, the call needs to be
routed towards the target of the request. Normally, this would
happen by selecting a PSTN gateway which is a good route towards the
translated number. However, one can imagine all-IP systems where the
8xx numbers are SIP endpoints on an IP network, in which case the
translation of the 8xx number would actually be a SIP URI and not a
phone number. Assuming for the moment it is a PSTN connected entity,
the call would be routed towards a PSTN gateway. Proper treatment of
the call in the PSTN (and in particular, correct reconciliation of
billing records) requires that the call be marked with both the
original 8xx number AND the target number for the call. However, in
our example here, since the translation was performed by a SIP proxy
upstream from the gateway, the original 8xx number would have been
lost, and the call will not interwork properly with the PSTN.
Similar problems arise with other "special" numbers and services used
in the PSTN, such as operator services, pay numbers (9xx numbers in
the U.S), and short service codes such as 311.
3. Architectural Roots of the Problem
There is a common theme across all of the problems in Section 2, and
this theme is the confounding of names, routes, and addresses.
A name is a moniker for an entity which refers to it in a way which
reveals nothing about where it is in a network. On the Internet,
names are ideally provided through Universal Resource Names (URNs).
In the problem cases above, the SOS URN and 8xx numbers are examples
of names. An address is an identifier for an entity which describes
it by its location on the network. In SIP, the SIP URI itself is a
form of address because the host part of the URI, the only mandatory
part of the URI besides the scheme itself, indicates the location of
a SIP server that can be used to handle the request. Finally, a
route is a sequence of SIP entities (including the UA itself!) which
are traversed in order to forward a request to an address or name.
Rosenberg Expires April 16, 2007 [Page 7]
Internet-Draft UA Loose Routing October 2006
SIP, unfortunately, uses the Request-URI as a mechanism for routing
of the request in addition to using it as the mechanism for
identifying the name or address to which the request was targeted. A
home proxy rewrites the Request-URI because that rewriting is the
vehicle by which the request is forwarded to the target of the
request. However, this rewritten URI (the contact from the
register), is not in any way a meaningful name or address for the UA.
Indeed, with specifications like SIP outbound [4], even the IP
address within the registered contact is meaningless since the flow
on which the REGISTER is sent is used rather than the IP address.
Consequently, the home proxy is fundamentally replacing the address
in the Request-URI with a route to reach that UA. This architectural
mistake is the cause of the problems described above.
Interestingly, this same mistake was present in RFC 2543 [13] for the
handling of mid-dialog requests. It was fixed through the loose
routing mechanism in RFC 3261, which used Route header fields to
identify each hop to visit for a mid-dialog request, and separated
this from the Request-URI, which identified the ultimate target of
the request (the remote UA), and remained unmodified in the
processing of the request. It is also interesting to note that in
RFC 3261, the Request-URI in a mid-dialog request is the contact
provided in the INVITE or 2xx, and identifies the UA itself. This is
typically a SIP URI containing an IP address and, as has been argued
above, its not an address per se, but a SIP hop. That too has proven
to be an error, and has been fixed by the GRUU specification [5],
which will cause the Contact in INVITE and 2xx to be the GRUU
instead. This, in turn, means that mid-dialog requests will contain
the GRUU in the request-URI. The GRUU is, in fact, an address.
However, the loose routing fix made in RFC 3261 was not extended to
the handling of requests outside of a dialog. There, proxies retain
the practice of rewriting the Request-URI when accessing the location
service.
4. Alternative Solutions
There are several existing mechanisms which might be employed to
solve this problem.
4.1. What about the To header field?
When a UA sends a request, it typically populates the To header field
and the Request-URI with the target URI. Consequently, when the
request arrives at the terminating network, the Request-URI will be
rewritten, but the To header field is retained. Thus, when the
request arrives at the UA, the To header field identifies the
Rosenberg Expires April 16, 2007 [Page 8]
Internet-Draft UA Loose Routing October 2006
original target. Could that serve as the obvious solution to the
problem?
Unfortunately, it cannot. When a SIP call is forwarded (also known
as retargeting), the actual target of the address changes completely,
but the To field does not. When a retargeting operation happens, the
URI that needs to be delivered to the UAS is the SIP address or name
after the most recent retargeting operation. Consider the case of
Alice making a call to Bob (sip:bob@example.com). This arrives at
Bob's proxy, which has logic programmed in it to forward the call to
Jane, a user in a completely different network
(sip:jane@example.edu). When this arrive at Jane's proxy, the
Request URI is rewritten to her registered contact. In this case,
the To header field contains the original target of the request
(sip:bob@example.com), but this is not an identifier for Jane. Thus,
the SIP URI for which she was targeted (sip:jane@example.edu). Is
lost. Another example of this would be a call to one address or
number which is later forwarded to an 8xx number.
4.2. History Info
Another candidate solution is the History Info specification [18].
This specification defines a new header field, History-Info, which
records a history of redirection and retargeting operations. One
solution to this problem is to require every proxy that rewrites the
request URI to implement this specification. As a consequence of
that, a UAS could examine the History-Info header field and determine
the URI used to reach it.
Functionally, this can work. However, we would argue that there are
some major architectural problems with it.
Firstly, it would cause the Request-URI to be relegated to nothing
more than an indicator of the next hop for the request, identical
exactly to the purpose of the Route header field. This results in
two things in the SIP specification which do exactly the same thing.
Worse still, this is not just for some small feature of SIP (where
such duplication might not be a big deal), but rather, it would be a
duplication of SIP's primary function - routing of a call towards a
target.
Secondly, it would require the UA to look through the history info
and figure out which of the URI in there represent the target by
which it was reached, and which represent hops that were used along
the way. The UA may have no easy way to know this, especially if
there were many hops within the domain in which the UA resides.
Thirdly, the history specification is fairly complex and has seen
Rosenberg Expires April 16, 2007 [Page 9]
Internet-Draft UA Loose Routing October 2006
limited industry adoption. This should never be a reason to not use
a mechanism when its the right choice, but its a consideration that
warrants mentioning.
5. Proposed Solution
The proposed solution is simple. When handling a request, a proxy
only rewrites the Request-URI when performing a retargeting
operation. If, instead, the proxy is trying to route the request via
some entity (whether its a proxy or UA) to reach the target, the
Request-URI is retained, and Route header fields are pushed into the
request to reach the target.
This introduces an important question: what is a retargeting
operation compared to a routing operation? Is a translation of a
name (such as an SOS URN) to an address (like a SIP AOR) a
retargeting or a routing operation? We propose that the distinction
be determined by means of identity, and in particular the type of
assertions provided by [12]. An operation is considered to be a
retargeting operation if the entity to which the request is
ultimately delivered could not, based on the policies of the domain
of that entity, place the URI prior to translation in the From header
field, and have an identity service in its domain sign it. The
inverse is not true however. If an entity can legitimately claim the
identity prior to the translation operation, it may still be a
retargeting. In this case, it is a matter of domain policy about
whether it is or not.
From this basic rule, several sub-cases can be derived:
1. When a home proxy receives a request and accesses a location
service, the resulting contact(s) obtained from the location
service are considered the last hop in the route towards the
entity addressed by the Request-URI. Since that target, almost
by definition, can claim the identity of the URI prior to
translation, the operation is one of routing and not retargeting.
Consequently, the home proxy would retain the Request-URI, place
the contents of any Path headers from the registration into the
request as Route header field values [3], and insert the
registered contact as the last Route header field value.
2. When a proxy receives a request whose contents are a name and not
an address (for example, a tel URI or an SOS URN), and the proxy
determines through some means an address for that name, this
operation is not retargeting. The presumption is that the entity
managing the database that provides the translation will only
translation the name to an address if the SIP resource identified
Rosenberg Expires April 16, 2007 [Page 10]
Internet-Draft UA Loose Routing October 2006
by that address could claim the name as an identity.
Consequently, the proxy would push that address as a Route header
field value and retain the Request-URI.
3. When a proxy receiving a request identifies a next hop server
that is needed to process the request, that next hop server is a
route. A next hop server is not a UA and would never be able to
claim its identity. Its URI is pushed into a Route header field
and the Request-URI is retained. An important use case for this
are proxies that select PSTN gateways for call egress to the
PSTN. Such selection would place the SIP URI of the gateway into
the topmost Route header field value and retain the Request-URI.
4. When a proxy receives a request whose Request-URI is a SIP URI
matching the domain of the proxy, and the proxy decides that the
call needs to be terminated at a resource in another domain, this
is fundamentally a retargeting operation, and the Request-URI is
rewritten. It is fundamentally retargeting because an entity in
one domain couldn't claim the identity of an entity in another
based on the procedures in [12]
This definition also lends clarity to how and when History-Info gets
used. In particular, a History-Info header field would get added
when a request is retargeted, but not when it is routed. That is,
only operations which would cause a Request-URI to be rewritten would
cause a History-Info header field to be added.
6. Backwards Compatibility Considerations
The principal problem to be resolved is how to make this mechanism
backwards compatible. There are several solutions that can be used.
The simplest case is the location service case. When a UA registers,
it places the "ua-loose" option tag into the Supported header field
of its REGISTER request. If the registrar and home proxy support the
UA loose routing procedure described here, it adds a Require header
field to the response, indicating to the UA that loose routing
procedures will be used. This mechanism would permit different UA
for the same AOR to be a mix of ua-loose capable and ua-loose
incapable.
There are additional complications with the REGISTER case, however.
It is possible that the outbound proxy between the UA and the home
proxy will be confused by a new request towards the UA. It will now
have a Route header field in it pointing to the UA. Based on the
procedures in RFC 3261 and RFC 3263 [2], it should work fine, and
even an outbound proxy implementing [4] will properly route the
Rosenberg Expires April 16, 2007 [Page 11]
Internet-Draft UA Loose Routing October 2006
request towards the UA (that routing being based on the received
Route header field, in fact). There is some question about whether a
P-CSCF based on the IMS specifications will properly work in this
case. Being RFC 3261 compliant it ought to; but it requires further
investigation.
The more troubling cases are for translations not based on the
registration operation, such as name to address or gateway routing
operations. One idea is to use the existing ;lr URI parameter to
indicate that a URI is a loose route, and needs to be placed into a
Route header field and not cause replacement of the Request-URI.
This would work well when configuring proxies compliant with this
specification. A URI with the ;lr parameter indicates a routing next
hop, and without indicates a retargeting.
Redirection also poses an interesting problem. Consider a client X
which sends a request to server Y. Server Y redirects the request.
The redirection could have three meanings:
1. The server is asking the client to retarget, so that the recursed
request generated by the client replaces the Request-URI with the
contents of the redirection.
2. The server is asking the client to route through a different
server instead, so that the recursed request generated by the
client replaces the topmost Route header with the contents of the
redirection.
3. The server is asking the client to route through an additional
proxy prior to visiting it, so that the recursed request
generated by the client pushes an additional Route onto the Route
set.
Today, a 3xx always has the first semantic. To allow redirects to
result in a change in the route header field, an additional mechanism
is needed. The proposal for handling this is as follows. A client
which is capable of supporting this mechanism (whether its a proxy or
UA), adds a field to the SIP request indicating that. This can be
done in one of two ways:
1. A Via header field extension which indicates that this hop
supports the mechanism.
2. A separate header field whose contents equal the value of the Via
header inserted by the proxy. If a server receives a request and
this header field is not equal to the topmost Via, the server
knows the previous hop does not support the mechanism.
Rosenberg Expires April 16, 2007 [Page 12]
Internet-Draft UA Loose Routing October 2006
The first option appears to be the simplest. With that in place, the
three different redirect behaviors can be achieved. If a server
redirects, and the contact in the redirect contains the ;lr
parameter, this is a request for the previous hop to ovveride, for
this transaction only, the topmost Route header field value with the
value of the contact. If the redirect omits the ;lr parameter, it is
a normal redirect that replaces the Request-URI (a retarget). A new
response code can be defined, used only when the previous hop
supports this specification, for telling the upstream client to
append the contact to the existing route set (again for this
transaction only).
It is important to note that this mechanism will allow for a mid-
dialog request to be redirected to a different hop (i.e., a redirect
with an ;lr parameter in the contact), and that this will persist
just for the duration of the transaction. This mechanism is used in
the failover techniques described in [19].
For external services that provide next hops, such as ENUM [14],
implementations would assume that any contents received are not loose
routes, but rather retargets. Such services would need to define new
fields specifically for loose routes.
7. Minting AORs and GRUU
With loose routing in place, a UA can mint additional URI that are
processed by the SIP proxies identically to their AOR or GRUU. This
is done by adding a URI parameter, chosen by the UA, to the AOR or
GRUU, and handing that out to UA to use.
Strictly speaking, there is no need to even standardize a specific
URI parameter. The parameter is inserted by the UA, and used only by
the UA. However, it does need to avoid conflicting with any other
URI parameters which might have other meaning by the home proxy,
unbeknownst to the UA. This would argue for either one or more IANA
registered parameters, use of a vendor namespace, or
cryptographically random URI parameter names. It does make sense to
allow for more than one URI parameter however. This would allow for
infinitely nested sub-addressing capabilities, which is highly
desirable.
8. Security Considerations
The UA loose routing mechanism reveals to the UA the address by which
it was contacted. Previously, this was hidden from the UA. It may
be possible that a UA is not permitted to know the address at which
Rosenberg Expires April 16, 2007 [Page 13]
Internet-Draft UA Loose Routing October 2006
it was contacted. In such cases, the home proxy SHOULD treat such
calls as retargets and rewrite the Request-URI.
9. IANA Considerations
TODO.
10. Example
Consider the most basic case of a single proxy P and two user agents,
UA1 and UA2. A basic flow for registration and call setup is shown
in Figure 1.
UA 1 Proxy UA 2
| |(1) REGISTER |
| |<-------------|
| |(2) 200 OK |
| |------------->|
|(3) INVITE | |
|------------->| |
| |(4) INVITE |
| |------------->|
| |(5) 200 OK |
| |<-------------|
|(6) 200 OK | |
|<-------------| |
|(7) ACK | |
|------------->| |
| |(8) ACK |
| |------------->|
|(9) BYE | |
|------------->| |
| |(10) BYE |
| |------------->|
| |(11) 200 OK |
| |<-------------|
|(12) 200 OK | |
|<-------------| |
Figure 1
First, UA registers (message 1). It indicates support for loose
routing via a Supported header field parameter and also includes an
;lr parameter in its Contact header field. This message would look
Rosenberg Expires April 16, 2007 [Page 14]
Internet-Draft UA Loose Routing October 2006
like, in part (note the usage of both GRUU and sip-outbound; they are
not required with UA loose routing but is illustrative of a likely
use case):
REGISTER sip:example.com SIP/2.0
From: sip:user2@example.com;tag=9asd7d
To: sip:user2@example.com
Supported: gruu, ua-loose
Contact: <sip:ua2@192.0.2.1;lr>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
The response to the REGISTER (message 2) provides a GRUU to the UA
and also indicates that loose routing is to be used:
REGISTER sip:example.com SIP/2.0
From: sip:user2@example.com;tag=9asd7d
To: sip:user2@example.com
Require: ua-loose
Contact: <sip:ua2@192.0.2.1;lr>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
;expires=3600
;pub-gruu="sip:user2@example.com;gr;
aor-qual=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
Next, UA1 generates an INVITE towards UA2 (message 3):
INVITE sip:user2@example.com SIP/2.0
From: sip:user1@example.com;tag=555af9g7
To: sip:user2@example.com
This arrives at the proxy, which looks up the Request-URI. It finds
a single registered contact which is marked as loose routing.
Therefore, the request it generates towards UA2 looks like (message
4):
INVITE sip:user2@example.com SIP/2.0
Route: <sip:ua2@192.0.2.1;lr>
From: sip:user1@example.com;tag=555af9g7
To: sip:user2@example.com
Note that the Request-URI is unmodified and a Route header field has
Rosenberg Expires April 16, 2007 [Page 15]
Internet-Draft UA Loose Routing October 2006
been pushed. The UAS generates a 200 OK (message 5):
SIP/2.0 200 OK
From: sip:user1@example.com;tag=555af9g7
To: sip:user2@example.com;tag=6566565
Contact: <sip:user2@example.com;gr;
aor-qual=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>
Note the presence of the GRUU in the 200 OK. When the BYE comes
later on (message 9), it is sent to the GRUU:
BYE sip:user2@example.com;gr;
aor-qual=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 SIP/2.0
From: sip:user1@example.com;tag=555af9g7
To: sip:user2@example.com;tag=6566565
When this arrives at the home proxy, the same thing happens as
before. The registered contact bound to the GRUU is a loose route,
and so the BYE sent to the UAS would look like (message 10):
BYE sip:user2@example.com;gr;
aor-qual=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 SIP/2.0
Route: <sip:ua2@192.0.2.1;lr>
From: sip:user1@example.com;tag=555af9g7
To: sip:user2@example.com;tag=6566565
11. References
11.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] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
Extension Header Field for Registering Non-Adjacent Contacts",
RFC 3327, December 2002.
Rosenberg Expires April 16, 2007 [Page 16]
Internet-Draft UA Loose Routing October 2006
11.2. Informative References
[4] Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-04 (work in progress), June 2006.
[5] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-10 (work in progress), August 2006.
[6] Rosenberg, J., "The Session Initiation Protocol (SIP) and
Spam", draft-ietf-sipping-spam-02 (work in progress),
March 2006.
[7] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-12 (work in progress),
August 2006.
[8] Schulzrinne, H., "A Uniform Resource Name (URN) for Services",
draft-ietf-ecrit-service-urn-05 (work in progress),
August 2006.
[9] Rosen, B., "Framework for Emergency Calling in Internet
Multimedia", draft-rosen-ecrit-framework-00 (work in progress),
June 2006.
[10] Livingood, J. and R. Shockey, "IANA Registration for an
Enumservice Containing PSTN Signaling Information",
draft-ietf-enum-pstn-05 (work in progress), August 2006.
[11] Shockey, R., "IANA Registration for an Enumservice Calling Name
Delivery (CNAM) Information and IANA Registration for Media
type 'application/cnam'", draft-ietf-enum-cnam-04 (work in
progress), September 2006.
[12] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[13] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
[14] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
[15] Campbell, B. and R. Sparks, "Control of Service Context using
Rosenberg Expires April 16, 2007 [Page 17]
Internet-Draft UA Loose Routing October 2006
SIP Request-URI", RFC 3087, April 2001.
[16] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media
Services with SIP", RFC 4240, December 2005.
[17] Jennings, C., Audet, F., and J. Elwell, "Session Initiation
Protocol (SIP) URIs for Applications such as Voicemail and
Interactive Voice Response (IVR)", RFC 4458, April 2006.
[18] Barnes, M., "An Extension to the Session Initiation Protocol
(SIP) for Request History Information", RFC 4244,
November 2005.
[19] Rosenberg, J., "Discovering Outbound Proxies and Providing High
Availability with Client Initiated Connections in the Session
Initiation Protocol (SIP)",
draft-rosenberg-sip-outbound-discovery-mid-dialog-00.txt (work
in progress), October 2006.
Rosenberg Expires April 16, 2007 [Page 18]
Internet-Draft UA Loose Routing October 2006
Author's Address
Jonathan Rosenberg
Cisco Systems
600 Lanidex Plaza
Parsippany, NJ 07054
US
Phone: +1 973 952-5000
Email: jdrosen@cisco.com
URI: http://www.jdrosen.net
Rosenberg Expires April 16, 2007 [Page 19]
Internet-Draft UA Loose Routing October 2006
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 (2006). 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.
Rosenberg Expires April 16, 2007 [Page 20]