< draft-rosenberg-sip-ua-loose-route-01.txt   draft-rosenberg-sip-ua-loose-route-02.txt >
SIP J. Rosenberg SIP J. Rosenberg
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track June 12, 2007 Intended status: Standards Track January 25, 2008
Expires: December 14, 2007 Expires: July 28, 2008
Applying Loose Routing to Session Initiation Protocol (SIP) User Agents Applying Loose Routing to Session Initiation Protocol (SIP) User Agents
(UA) (UA)
draft-rosenberg-sip-ua-loose-route-01 draft-rosenberg-sip-ua-loose-route-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 14, 2007. This Internet-Draft will expire on July 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
A key part of the behavior of the Session Initiation Protocol (SIP) A key part of the behavior of the Session Initiation Protocol (SIP)
is that SIP proxies rewrite the Request-URI as a request moves is that SIP proxies rewrite the Request-URI as a request moves
throughout the network. Over the years, experience has shown this to throughout the network. Over the years, experience has shown this to
be problematic. It makes it difficult to use Request URI for service be problematic. It makes it difficult to use Request URI for service
invocation, complicates emergency services, makes it more complex to invocation, complicates emergency services, makes it more complex to
support aliases, and so on. Architecturally, it confounds the support aliases, and so on. Architecturally, it confounds the
concepts of address and route. This document proposes to change this concepts of address and route. This document proposes to change this
skipping to change at page 2, line 19 skipping to change at page 2, line 19
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Unknown Aliases . . . . . . . . . . . . . . . . . . . . . 3 2.1. Unknown Aliases . . . . . . . . . . . . . . . . . . . . . 3
2.2. Unknown GRUU . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Unknown GRUU . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Limited Use Addresses . . . . . . . . . . . . . . . . . . 4 2.3. Limited Use Addresses . . . . . . . . . . . . . . . . . . 4
2.4. Sub-Addressing . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Sub-Addressing . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Service Invocation . . . . . . . . . . . . . . . . . . . . 6 2.5. Service Invocation . . . . . . . . . . . . . . . . . . . . 6
2.6. Emergency Services . . . . . . . . . . . . . . . . . . . . 6 2.6. Emergency Services . . . . . . . . . . . . . . . . . . . . 6
2.7. Freephone Numbers . . . . . . . . . . . . . . . . . . . . 6 2.7. Freephone Numbers . . . . . . . . . . . . . . . . . . . . 6
3. Architectural Roots of the Problem . . . . . . . . . . . . . . 7 3. Architectural Roots of the Problem . . . . . . . . . . . . . . 7
4. Alternative Solutions . . . . . . . . . . . . . . . . . . . . 8 4. Alternative Solutions . . . . . . . . . . . . . . . . . . . . 8
4.1. What about the To header field? . . . . . . . . . . . . . 8 4.1. What about the To header field? . . . . . . . . . . . . . 9
4.2. History Info . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. History Info . . . . . . . . . . . . . . . . . . . . . . . 9
5. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 10 5. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 10
6. Backwards Compatibility Considerations . . . . . . . . . . . . 12 6. Backwards Compatibility Considerations . . . . . . . . . . . . 12
7. Minting AORs and GRUU . . . . . . . . . . . . . . . . . . . . 13 7. Minting AORs and GRUU . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
A key part of the behavior of proxy servers in the Session Initiation 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 Protocol (SIP) [RFC3261] is that they rewrite the Request-URI of
as the request moves from the User Agent Client (UAC) to the User requests as the request moves from the User Agent Client (UAC) to the
Agent Server (UAS). This is particularly true for requests outside User Agent Server (UAS). This is particularly true for requests
of a dialog; requests within a dialog have their path dictated outside of a dialog; requests within a dialog have their path
primarily by the Route header fields established by the Record-Routes dictated primarily by the Route header fields established by the
when the dialog was initiated. Record-Routes when the dialog was initiated.
The most basic instance of this behavior is the processing executed The most basic instance of this behavior is the processing executed
by the "home proxy" within a domain. The home proxy is the proxy by the "home proxy" within a domain. The home proxy is the proxy
server within a domain which accesses the location information server within a domain which accesses the location information
generated by REGISTER messages, and uses it to forward a request 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 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 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 database, and translates it to the contact(s) that were registered by
the UA. This new contact URI replaces the existing Request URI, and the UA. This new contact URI replaces the existing Request URI, and
causes the request to be forwarded towards the target UA. causes the request to be forwarded towards the target UA.
skipping to change at page 4, line 28 skipping to change at page 4, line 28
the importance of the call. the importance of the call.
However, based on the procedures in RFC 3261, when an incoming 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 hits the home proxy, the request URI (which contains the alias) is
rewritten to the registered contact(s). Consequently, the alias that rewritten to the registered contact(s). Consequently, the alias that
was used is lost, and cannot be known to the UAS. was used is lost, and cannot be known to the UAS.
2.2. Unknown GRUU 2.2. Unknown GRUU
A variation on the problem in Section 2.1 occurs with Globally 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 Routable User Agent URI (GRUU) [I-D.ietf-sip-gruu]. A GRUU is a URI
instance which has many of the same properties as the AOR, but causes assigned to a UA instance which has many of the same properties as
requests to be routed only to that specific instance. It is the AOR, but causes requests to be routed only to that specific
desirable for a UA to know whether it was reached because a instance. It is desirable for a UA to know whether it was reached
correspondent sent a request to its GRUU or to its AOR. This can be because a correspondent sent a request to its GRUU or to its AOR.
used to drive differing authorization policies on whether the request This can be used to drive differing authorization policies on whether
should be accepted or rejected, for example. However, like the AOR the request should be accepted or rejected, for example. However,
itself, the GRUU is lost in translation at the home proxy. Thus, the like the AOR itself, the GRUU is lost in translation at the home
UAS cannot know whether it was contacted via the GRUU or its AOR. proxy. Thus, the UAS cannot know whether it was contacted via the
GRUU or its AOR.
2.3. Limited Use Addresses 2.3. Limited Use Addresses
A limited use address is an SIP URI that is minted on-demand, and A limited use address is an SIP URI that is minted on-demand, and
passed out to a small number (usually one) remote correspondent. passed out to a small number (usually one) remote correspondent.
Incoming calls targeted to that limited use address are accepted as Incoming calls targeted to that limited use address are accepted as
long as the UA still desires communications from the remote target. long as the UA still desires communications from the remote target.
Should they no longer wish to be bothered by that remote Should they no longer wish to be bothered by that remote
correspondent, the URI is invalidated so that future requests correspondent, the URI is invalidated so that future requests
targeted to it are rejected. targeted to it are rejected.
Limited use addresses are used in battling voice spam [6]. The Limited use addresses are used in battling voice spam
easiest way to provide them would be for a UA to be able to take its [I-D.ietf-sipping-spam]. The easiest way to provide them would be
AOR, and "mint" a limited use address by appending additional for a UA to be able to take its AOR, and "mint" a limited use address
parameters to the URI. It could then give out the URI to a by appending additional parameters to the URI. It could then give
particular correspondent, and remember that URI locally. When an out the URI to a particular correspondent, and remember that URI
incoming call arrives, the UAS would examine the parameter in the URI locally. When an incoming call arrives, the UAS would examine the
and determine whether or not the call should be accepted. parameter in the URI and determine whether or not the call should be
Alternatively, the UA could push authorization rules into the accepted. Alternatively, the UA could push authorization rules into
network, so that it need not even see incoming requests that are to the network, so that it need not even see incoming requests that are
be rejected. to be rejected.
This approach, especially when executed on the UA, requires that This approach, especially when executed on the UA, requires that
parameters attached to the AOR, but not used by the home proxy in parameters attached to the AOR, but not used by the home proxy in
processing the request, will survive the translation at the home 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 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 logic in RFC 3261, since the Request-URI is replaced by the
registered contact, and any such parameters are lost. registered contact, and any such parameters are lost.
2.4. Sub-Addressing 2.4. Sub-Addressing
skipping to change at page 6, line 12 skipping to change at page 6, line 12
would be lost at the home proxy, due to the fact that the Request-URI would be lost at the home proxy, due to the fact that the Request-URI
is rewritten there. is rewritten there.
2.5. Service Invocation 2.5. Service Invocation
Several SIP specifications have been developed which make use of Several SIP specifications have been developed which make use of
complex URIs to address services within the network rather than complex URIs to address services within the network rather than
subscribers. The URIs are complex because they contain numerous subscribers. The URIs are complex because they contain numerous
parameters that control the behavior of the service. Examples of parameters that control the behavior of the service. Examples of
this include the specification which first introduced the concept, this include the specification which first introduced the concept,
RFC 3087 [15], control of network announcements and IVR with SIP URI RFC 3087 [RFC3087], control of network announcements and IVR with SIP
[16], and control of voicemail access with SIP URI [17]. URI [RFC4240], and control of voicemail access with SIP URI
[RFC4458].
A common problem with all of these mechanisms is that once a proxy 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 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 cannot be sure that the Request-URI will not be destroyed by a
downstream proxy which decides to forward the request in some way, downstream proxy which decides to forward the request in some way,
and does so by rewriting the Request-URI. and does so by rewriting the Request-URI.
2.6. Emergency Services 2.6. Emergency Services
Another problem that arises from Request-URI rewriting is with Another problem that arises from Request-URI rewriting is with
emergency services for VoIP. A key requirement of systems supporting emergency services for VoIP. A key requirement of systems supporting
emergency calling is that the SIP INVITE request for an emergency 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 call be 'marked' in some way that makes it clear that it is an
emergency call, so that it can receive priority treatment [7]. emergency call, so that it can receive priority treatment
However, such a marking needs to be done in a way that it cannot be [I-D.ietf-ecrit-requirements]. However, such a marking needs to be
abused by attackers seeking to get special treatment for non- done in a way that it cannot be abused by attackers seeking to get
emergency calls. The solution for this is that the marking needs to special treatment for non-emergency calls. The solution for this is
be the target address of the request itself, which would that the marking needs to be the target address of the request
unambiguously identify an emergency services calltaker as the target. itself, which would unambiguously identify an emergency services
The solution that has been agreed upon is the SOS URN [8] which takes calltaker as the target. The solution that has been agreed upon is
the form urn:service:sos. This URI appears the in the Request-URI of the SOS URN [I-D.ietf-ecrit-service-urn] which takes the form
the request emitted by the UA making the emergency services call, and 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 needs to remain in the Request-URI as the request is routed towards
the correct emergency services center (ESC) and eventually the target the correct emergency services center (ESC) and eventually the target
call taker [9]. call taker [I-D.ietf-ecrit-framework].
This mechanism will not work if any of the proxies along the way try 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 to rewrite the Request-URI for the purposes of directing the call to
a proxy or UA that will handle the call. a proxy or UA that will handle the call.
2.7. Freephone Numbers 2.7. Freephone Numbers
Freephone numbers, also known as 800 or 8xx numbers in the United Freephone numbers, also known as 800 or 8xx numbers in the United
States, are telephone numbers that are free for users to call States, are telephone numbers that are free for users to call
(although the author will note that such notions are becoming less (although the author will note that such notions are becoming less
skipping to change at page 6, line 51 skipping to change at page 7, line 4
to rewrite the Request-URI for the purposes of directing the call to to rewrite the Request-URI for the purposes of directing the call to
a proxy or UA that will handle the call. a proxy or UA that will handle the call.
2.7. Freephone Numbers 2.7. Freephone Numbers
Freephone numbers, also known as 800 or 8xx numbers in the United Freephone numbers, also known as 800 or 8xx numbers in the United
States, are telephone numbers that are free for users to call States, are telephone numbers that are free for users to call
(although the author will note that such notions are becoming less (although the author will note that such notions are becoming less
important as billing models evolve, and harken back to an era where important as billing models evolve, and harken back to an era where
phone service depended on global agreement on such billing concepts). phone service depended on global agreement on such billing concepts).
In the telephone network, freephone numbers are just aliases to In the telephone network, freephone numbers are just aliases to
actual numbers which are used for routing of the call. In order 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 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 protocol called TCAP), which will return either a phone number or the
identity of a carrier which can handle the call. identity of a carrier which can handle the call.
There has been recent work on allowing such PSTN translation services There has been recent work on allowing such PSTN translation services
to be accessed by SIP proxy servers through IP querying mechanisms. to be accessed by SIP proxy servers through IP querying mechanisms.
ENUM, for example [14] has already been proposed as a mechanism for ENUM, for example [RFC3761] has already been proposed as a mechanism
performing Local Number Portability (LNP) queries [10], and recently for performing Local Number Portability (LNP) queries [RFC4769], and
been proposed for performing calling name queries [11]. Using it for recently been proposed for performing calling name queries
8xx number translations is a logical next-step. [I-D.ietf-enum-cnam]. Using it for 8xx number translations is a
logical next-step.
Once such a translation has been performed, the call needs to be Once such a translation has been performed, the call needs to be
routed towards the target of the request. Normally, this would routed towards the target of the request. Normally, this would
happen by selecting a PSTN gateway which is a good route towards the happen by selecting a PSTN gateway which is a good route towards the
translated number. However, one can imagine all-IP systems where 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 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 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, 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 would be routed towards a PSTN gateway. Proper treatment of
the call in the PSTN (and in particular, correct reconciliation of the call in the PSTN (and in particular, correct reconciliation of
skipping to change at page 8, line 12 skipping to change at page 8, line 14
route is a sequence of SIP entities (including the UA itself!) which 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. are traversed in order to forward a request to an address or name.
SIP, unfortunately, uses the Request-URI as a mechanism for routing SIP, unfortunately, uses the Request-URI as a mechanism for routing
of the request in addition to using it as the mechanism for of the request in addition to using it as the mechanism for
identifying the name or address to which the request was targeted. A identifying the name or address to which the request was targeted. A
home proxy rewrites the Request-URI because that rewriting is the home proxy rewrites the Request-URI because that rewriting is the
vehicle by which the request is forwarded to the target of the vehicle by which the request is forwarded to the target of the
request. However, this rewritten URI (the contact from the request. However, this rewritten URI (the contact from the
register), is not in any way a meaningful name or address for the UA. register), is not in any way a meaningful name or address for the UA.
Indeed, with specifications like SIP outbound [4], even the IP Indeed, with specifications like SIP outbound
address within the registered contact is meaningless since the flow [I-D.ietf-sip-outbound], even the IP address within the registered
on which the REGISTER is sent is used rather than the IP address. contact is meaningless since the flow on which the REGISTER is sent
Consequently, the home proxy is fundamentally replacing the address is used rather than the IP address. Consequently, the home proxy is
in the Request-URI with a route to reach that UA. This architectural fundamentally replacing the address in the Request-URI with a route
mistake is the cause of the problems described above. 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 Interestingly, this same mistake was present in RFC 2543 [RFC2543]
handling of mid-dialog requests. It was fixed through the loose for the handling of mid-dialog requests. It was fixed through the
routing mechanism in RFC 3261, which used Route header fields to loose routing mechanism in RFC 3261, which used Route header fields
identify each hop to visit for a mid-dialog request, and separated to identify each hop to visit for a mid-dialog request, and separated
this from the Request-URI, which identified the ultimate target of this from the Request-URI, which identified the ultimate target of
the request (the remote UA), and remained unmodified in the the request (the remote UA), and remained unmodified in the
processing of the request. It is also interesting to note that in 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 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 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 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 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], to be an error, and has been fixed by the GRUU specification
which will cause the Contact in INVITE and 2xx to be the GRUU [I-D.ietf-sip-gruu], which will cause the Contact in INVITE and 2xx
instead. This, in turn, means that mid-dialog requests will contain to be the GRUU instead. This, in turn, means that mid-dialog
the GRUU in the request-URI. The GRUU is, in fact, an address. 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 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 handling of requests outside of a dialog. There, proxies retain
the practice of rewriting the Request-URI when accessing the location the practice of rewriting the Request-URI when accessing the location
service. service.
4. Alternative Solutions 4. Alternative Solutions
There are several existing mechanisms which might be employed to There are several existing mechanisms which might be employed to
solve this problem. solve this problem.
skipping to change at page 9, line 25 skipping to change at page 9, line 33
(sip:jane@example.edu). When this arrive at Jane's proxy, the (sip:jane@example.edu). When this arrive at Jane's proxy, the
Request URI is rewritten to her registered contact. In this case, Request URI is rewritten to her registered contact. In this case,
the To header field contains the original target of the request the To header field contains the original target of the request
(sip:bob@example.com), but this is not an identifier for Jane. Thus, (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 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 lost. Another example of this would be a call to one address or
number which is later forwarded to an 8xx number. number which is later forwarded to an 8xx number.
4.2. History Info 4.2. History Info
Another candidate solution is the History Info specification [18]. Another candidate solution is the History Info specification
This specification defines a new header field, History-Info, which [RFC4244]. This specification defines a new header field, History-
records a history of redirection and retargeting operations. One Info, which records a history of redirection and retargeting
solution to this problem is to require every proxy that rewrites the operations. One solution to this problem is to require every proxy
request URI to implement this specification. As a consequence of that rewrites the request URI to implement this specification. As a
that, a UAS could examine the History-Info header field and determine consequence of that, a UAS could examine the History-Info header
the URI used to reach it. field and determine the URI used to reach it.
Functionally, this can work. However, we would argue that there are Functionally, this can work. However, we would argue that there are
some major architectural problems with it. some major architectural problems with it.
Firstly, it would cause the Request-URI to be relegated to nothing Firstly, it would cause the Request-URI to be relegated to nothing
more than an indicator of the next hop for the request, identical more than an indicator of the next hop for the request, identical
exactly to the purpose of the Route header field. This results in exactly to the purpose of the Route header field. This results in
two things in the SIP specification which do exactly the same thing. 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 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 such duplication might not be a big deal), but rather, it would be a
skipping to change at page 10, line 19 skipping to change at page 10, line 25
operation. If, instead, the proxy is trying to route the request via 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 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-URI is retained, and Route header fields are pushed into the
request to reach the target. request to reach the target.
This introduces an important question: what is a retargeting This introduces an important question: what is a retargeting
operation compared to a routing operation? Is a translation of a 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 name (such as an SOS URN) to an address (like a SIP AOR) a
retargeting or a routing operation? We propose that the distinction retargeting or a routing operation? We propose that the distinction
be determined by means of identity, and in particular the type of be determined by means of identity, and in particular the type of
assertions provided by [12]. An operation is considered to be a assertions provided by [RFC4474]. An operation is considered to be a
retargeting operation if the entity to which the request is retargeting operation if the entity to which the request is
ultimately delivered could not, based on the policies of the domain ultimately delivered could not, based on the policies of the domain
of that entity, place the URI prior to translation in the From header 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 field, and have an identity service in its domain sign it. The
inverse is not true however. If an entity can legitimately claim the inverse is not true however. If an entity can legitimately claim the
identity prior to the translation operation, it may still be a identity prior to the translation operation, it may still be a
retargeting. In this case, it is a matter of domain policy about retargeting. In this case, it is a matter of domain policy about
whether it is or not. whether it is or not.
From this basic rule, several sub-cases can be derived: From this basic rule, several sub-cases can be derived:
1. When a home proxy receives a request and accesses a location 1. When a home proxy receives a request and accesses a location
service, the resulting contact(s) obtained from the location service, the resulting contact(s) obtained from the location
service are considered the last hop in the route towards the service are considered the last hop in the route towards the
entity addressed by the Request-URI. Since that target, almost entity addressed by the Request-URI. Since that target, almost
by definition, can claim the identity of the URI prior to by definition, can claim the identity of the URI prior to
translation, the operation is one of routing and not retargeting. translation, the operation is one of routing and not retargeting.
Consequently, the home proxy would retain the Request-URI, place Consequently, the home proxy would retain the Request-URI, place
the contents of any Path headers from the registration into the the contents of any Path headers from the registration into the
request as Route header field values [3], and insert the request as Route header field values [RFC3327], and insert the
registered contact as the last Route header field value. registered contact as the last Route header field value.
2. When a proxy receives a request whose contents are a name and not 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 an address (for example, a tel URI or an SOS URN), and the proxy
determines through some means an address for that name, this determines through some means an address for that name, this
operation is not retargeting. The presumption is that the entity operation is not retargeting. The presumption is that the entity
managing the database that provides the translation will only managing the database that provides the translation will only
translation the name to an address if the SIP resource identified translation the name to an address if the SIP resource identified
by that address could claim the name as an identity. by that address could claim the name as an identity.
Consequently, the proxy would push that address as a Route header Consequently, the proxy would push that address as a Route header
skipping to change at page 11, line 20 skipping to change at page 11, line 25
are proxies that select PSTN gateways for call egress to the are proxies that select PSTN gateways for call egress to the
PSTN. Such selection would place the SIP URI of the gateway into PSTN. Such selection would place the SIP URI of the gateway into
the topmost Route header field value and retain the Request-URI. 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 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 matching the domain of the proxy, and the proxy decides that the
call needs to be terminated at a resource in another domain, this call needs to be terminated at a resource in another domain, this
is fundamentally a retargeting operation, and the Request-URI is is fundamentally a retargeting operation, and the Request-URI is
rewritten. It is fundamentally retargeting because an entity in rewritten. It is fundamentally retargeting because an entity in
one domain couldn't claim the identity of an entity in another one domain couldn't claim the identity of an entity in another
based on the procedures in [12] based on the procedures in [RFC4474]
This definition also lends clarity to how and when History-Info gets This definition also lends clarity to how and when History-Info gets
used. In particular, a History-Info header field would get added used. In particular, a History-Info header field would get added
when a request is retargeted, but not when it is routed. That is, 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 only operations which would cause a Request-URI to be rewritten would
cause a History-Info header field to be added. cause a History-Info header field to be added.
Redirection can then have several different meanings. Consider a Redirection can then have several different meanings. Consider a
client X which sends a request to server Y. Server Y redirects the client X which sends a request to server Y. Server Y redirects the
request. The redirection could have three meanings: request. The redirection could have three meanings:
skipping to change at page 12, line 17 skipping to change at page 12, line 23
a normal redirect that replaces the Request-URI (a retarget). A new a normal redirect that replaces the Request-URI (a retarget). A new
response code can be defined, used only when the previous hop response code can be defined, used only when the previous hop
supports this specification, for telling the upstream client to supports this specification, for telling the upstream client to
append the contact to the existing route set (again for this append the contact to the existing route set (again for this
transaction only). transaction only).
It is important to note that this mechanism will allow for a mid- 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 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 with an ;lr parameter in the contact), and that this will persist
just for the duration of the transaction. This mechanism is used in just for the duration of the transaction. This mechanism is used in
the failover techniques described in [19]. the failover techniques described in
[I-D.rosenberg-sip-outbound-discovery-mid-dialog].
6. Backwards Compatibility Considerations 6. Backwards Compatibility Considerations
The principal problem to be resolved is how to make this mechanism The principal problem to be resolved is how to make this mechanism
backwards compatible. There are several solutions that can be used. backwards compatible. There are several solutions that can be used.
The simplest case is the location service case. When a UA registers, The simplest case is the location service case. When a UA registers,
it places the "ua-loose" option tag into the Supported header field it places the "ua-loose" option tag into the Supported header field
of its REGISTER request. If the registrar and home proxy support the of its REGISTER request. If the registrar and home proxy support the
UA loose routing procedure described here, it adds a Require header UA loose routing procedure described here, it adds a Require header
field to the response, indicating to the UA that loose routing field to the response, indicating to the UA that loose routing
procedures will be used. This mechanism would permit different UA 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 for the same AOR to be a mix of ua-loose capable and ua-loose
incapable. incapable.
There are additional complications with the REGISTER case, however. There are additional complications with the REGISTER case, however.
It is possible that the outbound proxy between the UA and the home 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 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 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 procedures in RFC 3261 and RFC 3263 [RFC3263], it should work fine,
even an outbound proxy implementing [4] will properly route the and even an outbound proxy implementing [I-D.ietf-sip-outbound] will
request towards the UA (that routing being based on the received properly route the request towards the UA (that routing being based
Route header field, in fact). There is some question about whether a on the received Route header field, in fact). There is some question
P-CSCF based on the IMS specifications will properly work in this about whether a P-CSCF based on the IMS specifications will properly
case. Being RFC 3261 compliant it ought to; but it requires further work in this case. Being RFC 3261 compliant it ought to; but it
investigation. requires further investigation.
The more troubling cases are for translations not based on the The more troubling cases are for translations not based on the
registration operation, such as name to address or gateway routing registration operation, such as name to address or gateway routing
operations. One idea is to use the existing ;lr URI parameter to 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 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. Route header field and not cause replacement of the Request-URI.
This would work well when configuring proxies compliant with this This would work well when configuring proxies compliant with this
specification. A URI with the ;lr parameter indicates a routing next specification. A URI with the ;lr parameter indicates a routing next
hop, and without indicates a retargeting. hop, and without indicates a retargeting.
For external services that provide next hops, such as ENUM [14], For external services that provide next hops, such as ENUM [RFC3761],
implementations would assume that any contents received are not loose implementations would assume that any contents received are not loose
routes, but rather retargets. Such services would need to define new routes, but rather retargets. Such services would need to define new
fields specifically for loose routes. fields specifically for loose routes.
7. Minting AORs and GRUU 7. Minting AORs and GRUU
With loose routing in place, a UA can mint additional URI that are 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 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 is done by adding a URI parameter, chosen by the UA, to the AOR or
GRUU, and handing that out to UA to use. GRUU, and handing that out to UA to use.
skipping to change at page 16, line 4 skipping to change at page 16, line 18
Contact: <sip:user2@example.com;gr; Contact: <sip:user2@example.com;gr;
aor-qual=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6> aor-qual=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>
Note the presence of the GRUU in the 200 OK. When the BYE comes Note the presence of the GRUU in the 200 OK. When the BYE comes
later on (message 9), it is sent to the GRUU: later on (message 9), it is sent to the GRUU:
BYE sip:user2@example.com;gr; BYE sip:user2@example.com;gr;
aor-qual=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 SIP/2.0 aor-qual=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 SIP/2.0
From: sip:user1@example.com;tag=555af9g7 From: sip:user1@example.com;tag=555af9g7
To: sip:user2@example.com;tag=6566565 To: sip:user2@example.com;tag=6566565
When this arrives at the home proxy, the same thing happens as When this arrives at the home proxy, the same thing happens as
before. The registered contact bound to the GRUU is a loose route, 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): and so the BYE sent to the UAS would look like (message 10):
BYE sip:user2@example.com;gr; BYE sip:user2@example.com;gr;
aor-qual=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 SIP/2.0 aor-qual=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 SIP/2.0
Route: <sip:ua2@192.0.2.1;lr> Route: <sip:ua2@192.0.2.1;lr>
From: sip:user1@example.com;tag=555af9g7 From: sip:user1@example.com;tag=555af9g7
To: sip:user2@example.com;tag=6566565 To: sip:user2@example.com;tag=6566565
11. References 11. References
11.1. Normative References 11.1. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: A., Peterson, J., Sparks, R., Handley, M., and E.
Session Initiation Protocol", RFC 3261, June 2002. Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
(SIP): Locating SIP Servers", RFC 3263, June 2002. Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
[3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol
Extension Header Field for Registering Non-Adjacent Contacts", (SIP) Extension Header Field for Registering Non-Adjacent
RFC 3327, December 2002. Contacts", RFC 3327, December 2002.
11.2. Informative References 11.2. Informative References
[4] Jennings, C. and R. Mahy, "Managing Client Initiated [I-D.ietf-sip-outbound]
Connections in the Session Initiation Protocol (SIP)", Jennings, C. and R. Mahy, "Managing Client Initiated
draft-ietf-sip-outbound-07 (work in progress), January 2007. Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-10 (work in progress), July 2007.
[5] Rosenberg, J., "Obtaining and Using Globally Routable User [I-D.ietf-sip-gruu]
Agent (UA) URIs (GRUU) in the Session Initiation Protocol Rosenberg, J., "Obtaining and Using Globally Routable User
(SIP)", draft-ietf-sip-gruu-11 (work in progress), Agent (UA) URIs (GRUU) in the Session Initiation Protocol
October 2006. (SIP)", draft-ietf-sip-gruu-15 (work in progress),
October 2007.
[6] Jennings, C. and J. Rosenberg, "The Session Initiation Protocol [I-D.ietf-sipping-spam]
(SIP) and Spam", draft-ietf-sipping-spam-04 (work in progress), Rosenberg, J. and C. Jennings, "The Session Initiation
February 2007. Protocol (SIP) and Spam", draft-ietf-sipping-spam-05 (work
in progress), July 2007.
[7] Schulzrinne, H. and R. Marshall, "Requirements for Emergency [I-D.ietf-ecrit-requirements]
Context Resolution with Internet Technologies", Schulzrinne, H. and R. Marshall, "Requirements for
draft-ietf-ecrit-requirements-12 (work in progress), Emergency Context Resolution with Internet Technologies",
August 2006. draft-ietf-ecrit-requirements-13 (work in progress),
March 2007.
[8] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", [I-D.ietf-ecrit-service-urn]
draft-ietf-ecrit-service-urn-05 (work in progress), Schulzrinne, H., "A Uniform Resource Name (URN) for
August 2006. Emergency and Other Well-Known Services",
draft-ietf-ecrit-service-urn-07 (work in progress),
August 2007.
[9] Rosen, B., "Framework for Emergency Calling in Internet [I-D.ietf-ecrit-framework]
Multimedia", draft-ietf-ecrit-framework-00 (work in progress), Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
October 2006. "Framework for Emergency Calling using Internet
Multimedia", draft-ietf-ecrit-framework-03 (work in
progress), September 2007.
[10] Livingood, J. and R. Shockey, "IANA Registration for an [RFC4769] Livingood, J. and R. Shockey, "IANA Registration for an
Enumservice Containing Public Switched Telephone Network (PSTN) Enumservice Containing Public Switched Telephone Network
Signaling Information", RFC 4769, November 2006. (PSTN) Signaling Information", RFC 4769, November 2006.
[11] Shockey, R., "IANA Registration for an Enumservice Calling Name [I-D.ietf-enum-cnam]
Delivery (CNAM) Information and IANA Registration for Media Shockey, R., "IANA Registration for an Enumservice Calling
type 'application/cnam'", draft-ietf-enum-cnam-04 (work in Name Delivery (CNAM) Information and IANA Registration
progress), September 2006. for URI type 'pstndata' URI type 'pstn'",
draft-ietf-enum-cnam-07 (work in progress), October 2007.
[12] Peterson, J. and C. Jennings, "Enhancements for Authenticated [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Identity Management in the Session Initiation Protocol (SIP)", Authenticated Identity Management in the Session
RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[13] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J.
"SIP: Session Initiation Protocol", RFC 2543, March 1999. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
March 1999.
[14] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Resource Identifiers (URI) Dynamic Delegation Discovery
Application (ENUM)", RFC 3761, April 2004. System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[15] Campbell, B. and R. Sparks, "Control of Service Context using [RFC3087] Campbell, B. and R. Sparks, "Control of Service Context
SIP Request-URI", RFC 3087, April 2001. using SIP Request-URI", RFC 3087, April 2001.
[16] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
Services with SIP", RFC 4240, December 2005. Media Services with SIP", RFC 4240, December 2005.
[17] Jennings, C., Audet, F., and J. Elwell, "Session Initiation [RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session
Protocol (SIP) URIs for Applications such as Voicemail and Initiation Protocol (SIP) URIs for Applications such as
Interactive Voice Response (IVR)", RFC 4458, April 2006. Voicemail and Interactive Voice Response (IVR)", RFC 4458,
April 2006.
[18] Barnes, M., "An Extension to the Session Initiation Protocol [RFC4244] Barnes, M., "An Extension to the Session Initiation
(SIP) for Request History Information", RFC 4244, Protocol (SIP) for Request History Information", RFC 4244,
November 2005. November 2005.
[19] Rosenberg, J., "Discovering Outbound Proxies and Providing High [I-D.rosenberg-sip-outbound-discovery-mid-dialog]
Availability with Client Initiated Connections in the Session Rosenberg, J., "Discovering Outbound Proxies and Providing
Initiation Protocol (SIP)", High Availability with Client Initiated Connections in
draft-rosenberg-sip-outbound-discovery-mid-dialog-00 (work in the Session Initiation Protocol (SIP)",
progress), October 2006. draft-rosenberg-sip-outbound-discovery-mid-dialog-00 (work
in progress), October 2006.
Author's Address Author's Address
Jonathan Rosenberg Jonathan Rosenberg
Cisco Cisco
Edison, NJ Edison, NJ
US US
Email: jdrosen@cisco.com Email: jdrosen@cisco.com
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 45 change blocks. 
140 lines changed or deleted 163 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/