One document matched: draft-rosenberg-sip-ua-loose-route-02.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="std">
  <front>
    <title abbrev="UA Loose Routing">Applying Loose Routing to Session
    Initiation Protocol (SIP) User Agents (UA)</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 month="January" year="2008" />
    
    <area>RAI</area>
    <workgroup>SIP</workgroup>

    <abstract>
      <t>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.</t>
    </abstract>
  </front>

  <middle>

<!-- dealing with 305 loops - say you don't go to a route you saw
previously. Also a count on the maximum number of iterations -->

<!-- add use case of a 3xx when client sent a request seomwhere but
there wasn't a route header for it, it just sent it there -->

<!-- add use case in aliasing, where an enterprise user has multiple
numbers within the enterprise. Add as a new section. -->

<!-- what about a UA that doesn't know all of its aliases? How should
it authorize incoming requests?? -->


<section title="Introduction">

<t>
A key part of the behavior of proxy servers 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>
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. 
</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-alts"/> discusses alternative solutions. <xref
target="sec-solution"/> 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.]]
</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 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. 
</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="I-D.ietf-sipping-spam"/>. 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 title="Emergency Services">

<t>
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 <xref
target="I-D.ietf-ecrit-requirements"/>. 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 <xref
target="I-D.ietf-ecrit-service-urn"/> 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 <xref target="I-D.ietf-ecrit-framework"/>. 
</t>

<t>
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. 
</t>

</section>

<section title="Freephone Numbers">

<t>
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 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.
</t>

<t>
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 <xref target="RFC3761"/> has already
been proposed as a mechanism for performing Local Number Portability
(LNP) queries <xref target="RFC4769"/>, and recently been
proposed for performing calling name queries <xref
target="I-D.ietf-enum-cnam"/>. Using it for 8xx number translations is
a logical next-step.
</t>

<t>
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.
</t>

<t>
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.
</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). 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.
</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. 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 <xref target="I-D.ietf-sip-gruu"/>, 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. 
</t>

<t>
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.
</t>

</section>

<section anchor="sec-alts" title="Alternative Solutions">

<t>
There are several existing mechanisms which might be employed to solve
this problem.
</t>

<section title="What about the To header field?">

<t>
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 original
target. Could that serve as the obvious solution to the problem?
</t>

<t>
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.
</t>

</section>

<section title="History Info">

<t>
Another candidate solution is the History Info specification <xref
target="RFC4244"/>. 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.
</t>

<t>
Functionally, this can work. However, we would argue that there are
some major architectural problems with it.
</t>

<t>
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. 
</t>

<t>
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. 
</t>


</section>

</section>

<section anchor="sec-solution" title="Proposed Solution">

<t>
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.
</t>

<t>
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 <xref
target="RFC4474"/>. 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. 
</t>

<t>
From this basic rule, several sub-cases can be derived:
</t>

<t><list style="numbers">

<t>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 <xref
target="RFC3327"/>, and insert the registered contact as the last
Route header field value. 
</t>

<t>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 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.
</t>

<t>
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.
</t>

<t>
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 <xref target="RFC4474"/> 
</t>
</list>

<t>
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.
</t>

<t>
Redirection can then have several different meanings. Consider a client X
which sends a request to server Y. Server Y redirects the request. The
redirection could have three meanings:
</t>

<t><list style="numbers">

<t>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.
</t>

<t>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.
</t>

<t>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.
</t>
</list></t>

<t>
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. A client
which is capable of supporting this mechanism (whether its a proxy or
UA), adds a field to the Via header field which indicates that this
hop supports the mechanism.</t>

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). 
</t>

<t>
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 <xref
target="I-D.rosenberg-sip-outbound-discovery-mid-dialog"/>. 
</t>


</section>

<section title="Backwards Compatibility Considerations">

<t>
The principal problem to be resolved is how to make this mechanism
backwards compatible. There are several solutions that can be used.
</t>

<t>
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. 
</t>

<t>
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 <xref target="RFC3263"/>, it should work
fine, and even an outbound proxy implementing <xref
target="I-D.ietf-sip-outbound"/> will properly route the 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.
</t>

<t>
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. 
</t>


<t>
For external services that provide next hops, such as ENUM <xref
target="RFC3761"/>, 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.
</t>

</section>

<section title="Minting AORs and GRUU">

<t>
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. 
</t>

<t>
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.
</t>

</section>

<section title="Security Considerations">

<t>
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 it
was contacted. In such cases, the home proxy SHOULD treat such calls
as retargets and rewrite the Request-URI.
</t>

</section>

<section title="IANA Considerations">

<t>
TODO.
</t>

</section>

<section title="Example">

<t>
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
<xref target="fig-flow"/>. 
</t>

<figure anchor="fig-flow"><artwork>
<![CDATA[
        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   |              |
          |<-------------|              |

]]></artwork></figure>

<t>
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 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):
</t>

<figure><artwork>
<![CDATA[
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
]]></artwork></figure>

<t>
The response to the REGISTER (message 2) provides a GRUU to the UA and also
indicates that loose routing is to be used:
</t>

<figure><artwork>
<![CDATA[
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" 

]]></artwork></figure>

<t>
Next, UA1 generates an INVITE towards UA2 (message 3):
</t>

<figure><artwork>
<![CDATA[
INVITE sip:user2@example.com SIP/2.0
From: sip:user1@example.com;tag=555af9g7
To: sip:user2@example.com
]]></artwork></figure>

<t>
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):
</t>

<figure><artwork>
<![CDATA[
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
]]></artwork></figure>

<t>
Note that the Request-URI is unmodified and a Route header field has
been pushed. The UAS generates a 200 OK (message 5):
</t>

<figure><artwork>
<![CDATA[
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>
]]></artwork></figure>

<t>
Note the presence of the GRUU in the 200 OK. When the BYE comes later
on (message 9), it is sent to the GRUU:
</t>

<figure><artwork>
<![CDATA[
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
]]></artwork></figure>

<t>
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):
</t>

<figure><artwork>
<![CDATA[
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
]]></artwork></figure>

</section>


  </middle>

<back>
<references title="Normative References">
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.RFC.3263"?>
<?rfc include="reference.RFC.3327"?>
</references>

<references title="Informative References">
<?rfc include="reference.I-D.ietf-sip-outbound"?>
<?rfc include="reference.I-D.ietf-sip-gruu"?>
<?rfc include="reference.I-D.ietf-sipping-spam"?>
<?rfc include="reference.I-D.ietf-ecrit-requirements"?>
<?rfc include="reference.I-D.ietf-ecrit-service-urn"?>
<?rfc include="reference.I-D.ietf-ecrit-framework"?>
<?rfc include="reference.RFC.4769"?>
<?rfc include="reference.I-D.ietf-enum-cnam"?>
<?rfc include="reference.RFC.4474"?>
<?rfc include="reference.RFC.2543"?>
<?rfc include="reference.RFC.3761"?>
<?rfc include="reference.RFC.3087"?>
<?rfc include="reference.RFC.4240"?>
<?rfc include="reference.RFC.4458"?>
<?rfc include="reference.RFC.4244"?>
<?rfc include="reference.I-D.rosenberg-sip-outbound-discovery-mid-dialog"?>
</references>

</back>
</rfc>