One document matched: draft-rosenberg-sip-target-uri-delivery-00.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc='yes'?>
<?rfc tocdepth='5'?>
<?rfc compact='yes'?>
<?rfc subcompact='no'?>
<?rfc symrefs='yes'?>
<rfc ipr="full3978" category="info">
<front>
<title abbrev="Target URI">
Delivery of Request-URI Targets to User Agents</title>
<author initials="J.R." surname="Rosenberg"
fullname="Jonathan Rosenberg">
<organization>Cisco</organization>
<address>
<postal>
<city>Edison</city> <region>NJ</region>
<country>US</country>
</postal>
<email>jdrosen@cisco.com</email>
<uri>http://www.jdrosen.net</uri>
</address>
</author>
<date year="2008" />
<area>RAI</area>
<workgroup>SIPPING</workgroup>
<keyword>SIP</keyword>
<keyword>IMS</keyword>
<abstract>
<t>When a Session Initiation Protocol (SIP) proxy receives
a request targeted at a URI identifying a user or resource it
is responsible for, the proxy translates the URI to a
registered contact URI of an agent representing that user
or resource. In the process, the original URI is removed
from the request. Numerous use cases have arisen which
require this information to be delivered to the user
agent. This document describes these use cases and defines
an extension to the History-Info header field which allows
it to be used to support those cases.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
A key part of the behavior of proxy servers and B2BUA in the Session
Initiation Protocol (SIP) <xref target="RFC3261"/> 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.
</t>
<t>
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.
</t>
<t>
Over the years, this practice of rewriting the Request-URI has proven
problematic. <xref target="sec-problems"/> describes the problems with
this mechanism. <xref target="sec-arch"/> analyzes the
architectural issues which drive these problems. <xref
target="sec-solution"/> overviews a mechanism to solve this problem by
extending the History-Info header field. <xref target="sec-details"/>
describes detailed procedures for user agents and proxies.
</t>
</section>
<section anchor="sec-problems" title="Problem Statement">
<t>
Several problems arise from the practice of rewriting the request URI.
</t>
<section anchor="sec-alias" title="Unknown Aliases">
<t>
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
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.
</t>
<t>
It is a common requirement for a UAS, on receipt of a call,
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.
</t>
<t>
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.
</t>
</section>
<section title="Unknown GRUU">
<t>
A variation on the problem in <xref target="sec-alias"/> occurs with
Globally Routable User Agent URI (GRUU) <xref
target="I-D.ietf-sip-gruu"/>. 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.
</t>
</section>
<section title="Limited Use Addresses">
<t>
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.
</t>
<t>
Limited use addresses are used in battling voice spam <xref
target="RFC5039"/>. 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 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.
</t>
<t>
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.
</t>
</section>
<section title="Sub-Addressing">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Service Invocation">
<t>
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
<xref target="RFC3087"/>, control of network announcements and IVR
with SIP URI <xref target="RFC4240"/>, and control of voicemail access
with SIP URI <xref target="RFC4458"/>.
</t>
<t>
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.
</t>
</section>
</section>
<section anchor="sec-arch" title="Architectural Roots of the Problem">
<t>
There is a common theme across all of the problems in <xref
target="sec-problems"/>, and this theme is the confounding of names,
routes, and addresses.
</t>
<t>
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). 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.
</t>
<t>
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 <xref target="I-D.ietf-sip-outbound"/>, 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.
</t>
<t>
Interestingly, this same mistake was present in RFC 2543 <xref
target="RFC2543"/> 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.
</t>
<t>
Unfortunately, application of this same technique to address the
problem at hand cannot be done in a backwards compatible
manner. Consequently, some other means is needed to clearly identify
which URIs are addresses, and which are routes. To avoid confusion, we
refer to a SIP URI that is an address for a user or resource as a
"target" and a SIP URI that is a hop for reaching that user as a
"hop".
</t>
</section>
<section anchor="sec-solution" title="Solution Overview">
<t>
The History-Info header field, defined in <xref target="RFC4244"/>,
defines a mechanism by which an enumeration of the URIs traversed can
be passed to both the UAC and UAS. History-Info was designed to
provide a general purpose mechanism which can support the needs of
many applications, including diagnostics and traditional telephony
features like voicemail. Were a home proxy to implement History-Info,
it would provide a means for that proxy to deliver the target URI to
the UAS.
</t>
<t>
Unfortunately, History-Info makes no distinction between URIs that are
targets and URIs that are hops. Consequently, if there were additional
proxies downstream of the home proxy which modified the Request-URI in
any way, the UA would have no way to know which URI in the list of
History-Info values was actually the target. To remedy that, this
document defines an extension to the History-Info header field which
indicates whether the URI is a target or not.
</t>
<t>
When a home proxy receives a request for a user or resource for which
it has a registration, the proxy adds two History-Info header field
values. The first is the incoming request URI. Since the
Request-URI identifies a user or resource for which it has a
registration, the Request-URI is an AOR and thus an address for the
user. The proxy adds a History-Info header field parameter, "target",
which indicates this. Next, the proxy inserts the contact URI it used
in the outgoing Request-URI. No target parameter is included in this
History-Info value.
</t>
<t>
For a UA to determine the URI target, it need only walk backwards
through the list of HI values, and take the first one containing the
"target" parameter.
</t>
<t>
For example, consider the architecture in
<xref target="fig-turi"/>. In the example user A calls user B. User B
is in example.com. The call from A to B passes through A's outbound
proxy, their home proxy, B's home proxy, and B's outbound proxy, prior
to reaching B. B's home proxy, H-B, performs the translation of the
R-URI to the registered contact based on the registration
database. Consequently, it adds two History-Info header fields, the
first of which represents the incoming R-URI and includes the "target"
parameter.
</t>
<figure title="Target URI Example" anchor="fig-turi"><artwork>
<![CDATA[
+-------+ +-------+ +-------+ +-------+
//--\\ | | | | | | | | //--\\
| A |--- | OB-A |----| H-A |---| H-B |---| OB-B |--| B |
| | | | | | | | | | | |
\\--// +-------+ +-------+ +-------+ +-------+ \\--//
INVITE
sip:B@example.com
------------>
INVITE
sip:B@example.com
------------>
INVITE
sip:B@example.com
------------>
INVITE
sip:B@example.com
HI: <sip:B@example.com>index=1;target,
<sip:B@1.2.3.4>;index=1.1
------------>
]]></artwork></figure>
</section>
<section anchor="sec-details" title="Detailed Semantics">
<t>
The "target" parameter in the History-Info header field indicates that
the URI that it parameterizes was subject to a lookup in a location
service created through the registration process of the
UA. Furthermore, if that URI had an 'index' of N, the URIs with
indices N.M for all M, are the registered contacts to that URI.
</t>
<section title="Proxy Behavior">
<t>
A proxy compliant to this specification SHOULD add a History-Info
header field value to a request under the following conditions:
</t>
<list style="symbols">
<t>
The proxy is responsible for the domain in AOR in the Request-URI</t>
<t>The proxy will be translating the contents of the Request-URI to
one or more registered contacts based on a location database
populated through REGISTER requests from user agents.
</t>
<t>The R-URI exists in the location database.</t>
</list>
<t>
The proxy SHOULD populate the History-Info header field regardless of
whether there is a Supported header field with value 'histinfo'. If
the incoming request already contains a History-Info header field, and
the last value of that header field is identical to the Request-URI of
the received request, the proxy MUST add a "target" attribute to that
History-Info value. If the request did not contain a History-Info
header field, or if it did, but the last value is not identical to the
Request-URI of the received request, the proxy MUST add another
History-Info header field value. The URI MUST be equal to the incoming
Request-URI, and MUST contain a "target" attribute. The index is set
as defined in RFC 4244.
</t>
<t>
Once the proxy has translated the Request-URI into a registered
contact, it MUST add an additional History-Info header field value
containing the Contact URI for each request to be forwarded. The
"target" attribute MUST NOT be present. The index is set
as defined in RFC 4244.
</t>
<t>
Since the principal purpose of the "target" parameter is to indicate,
to a UAS, the target URI by which it was reached, there is no need for
the History-Info header field values to be passed outside of the
domain which inserted them. There may be other applications of
History-Info which require it, however.
</t>
<t>
If the proxy is actually redirecting and not forwarding the request,
it SHOULD include a History-Info URI in the response for the
target. That URI, if present, MUST contain the 'target' attribute. It
SHOULD NOT add a History-Info URI for the registered contact; the
previous hop proxy will do that. Note that, this rule violates a
SHOULD-strength rule in Section 4.3.4 of RFC 4244. That section
indicates that redirections "SHOULD NOT" contain any new History-Info
header fields, as those will be added by the upstream server. For this
application however, only the downstream server knows that the R-URI
was a target, and thus the History-Info header field and the "target"
attribute must be added by the downstream server.
</t>
</section>
<section title="UA Behavior">
<t>
A UAS receiving a request, and wishing to determine the original
target dialog, takes the values in the History-Info header field, and
traverses through them in reverse order. Note that, the value of the
"index" attribute is not relevant; the traversal is in order of the
header fields values themselves. The UAS finds the first header field
value containing the "target" parameter. If such a value does not
exist, the target URI cannot be reliably determined. If it does exist,
the URI is examined. If the domain of the URI matches the domain of
the UA, based on the UA's configured awareness of its own domain, that
URI is the target URI. If the domains do not match, the target URI
cannot be reliably determined. This domain check is present to handle
cases where a request is forwarded through two separate domains, and
the domain of the actual UAS didn't support this specification, but
the previous domain did.
</t>
<t>
Beyond this, there is no special UA processing associated with the
"target" parameter.
</t>
</section>
</section>
<section title="Syntax">
<t>
This specification extends the syntax of hi-param in Section 4.1 of
RFC 4244:
</t>
<figure><artwork>
<![CDATA[
hi-param = hi-index / hi-target / hi-extension
hi-target = "target"
]]></artwork></figure>
</section>
<section title="Security Considerations">
<t>
The "target" parameter indicates that a URI was subject to translation
by a home proxy, and consequently, acts as an explicit indicator that
a particular URI was an AOR for a user. This might be useful for
attackers wishing to farm requests for targettable URIs for purposes
of spamming. Of course, such attackers can utilize URIs in
History-Info even if they lack the "target" attribute, so "target"
does not really exacerbate this. Nonetheless, since the princpal
application of the "target" parameter is delivery of a URI to a UAS
within the same domain, History-Info values inserted solely for this
purpose SHOULD be removed at the domain boundary.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.3261'?>
<?rfc include='reference.RFC.4244'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-sip-gruu'?>
<?rfc include='reference.RFC.5039'?>
<?rfc include='reference.RFC.3087'?>
<?rfc include='reference.RFC.4240'?>
<?rfc include='reference.RFC.4458'?>
<?rfc include='reference.I-D.ietf-sip-outbound'?>
<?rfc include='reference.RFC.2543'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:37:40 |