< draft-rosenberg-sip-route-construct-01.txt   draft-rosenberg-sip-route-construct-02.txt >
SIP J. Rosenberg SIP J. Rosenberg
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: September 7, 2006 March 6, 2006 Expires: April 20, 2007 October 17, 2006
Construction of the Route Header Field in the Session Initiation Construction of the Route Header Field in the Session Initiation
Protocol (SIP) Protocol (SIP)
draft-rosenberg-sip-route-construct-01 draft-rosenberg-sip-route-construct-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 34 skipping to change at page 1, line 34
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 September 7, 2006. This Internet-Draft will expire on April 20, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
The Route header field in the Session Initiation Protocol (SIP) is The Route header field in the Session Initiation Protocol (SIP) is
used to cause a request to visit a set of hops on its way towards the used to cause a request to visit a set of hops on its way towards the
final destination. Several specifications have defined rules for how final destination. Several specifications have defined rules for how
a user agent obtains and then uses a set of Route header fields in a user agent obtains and then uses a set of Route header fields in
the transmission of a request. These include the SIP specification the transmission of a request. These include the SIP specification
itself, the Service-Route header field specification, the SIP server itself, the Service-Route header field specification, the SIP server
option in the Dynamic Host Configuration Protocol (DHCP), and others. option in the Dynamic Host Configuration Protocol (DHCP), and others.
Unfortunately, these specifications are not consistent and the Unfortunately, these specifications are not consistent and the
resulting behavior at clients and servers is not clear or complete. resulting behavior at clients and servers is not clear or complete.
This document resolves this problem by defining a consistent set of This document resolves this problem by defining a consistent set of
logic. logic, and in the process, serves as an update to the Service-Route
specification.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Existing Sources . . . . . . . . . . . . . . . . . . . . . . 3 2. Existing Sources . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Default Outbound Proxies . . . . . . . . . . . . . . . . . 3 2.1. Default Outbound Proxies . . . . . . . . . . . . . . . . . 3
2.2 Service Route . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Service Route . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Record-Routes . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Record-Routes . . . . . . . . . . . . . . . . . . . . . . 4
2.4 305 Use Proxy . . . . . . . . . . . . . . . . . . . . . . 4 2.4. Loose Routes . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problems with Current Specifications . . . . . . . . . . . . 5 3. Problems with Current Specifications . . . . . . . . . . . . . 5
4. Overview of Operation . . . . . . . . . . . . . . . . . . . 7 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Detailed Processing Rules . . . . . . . . . . . . . . . . . 9 5. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7
5.1 Registrar Behavior . . . . . . . . . . . . . . . . . . . . 9 6. Detailed Processing Rules . . . . . . . . . . . . . . . . . . 7
5.2 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Registrar Behavior . . . . . . . . . . . . . . . . . . . . 8
5.3 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 10
5.4 Client Behavior . . . . . . . . . . . . . . . . . . . . . 13 6.3. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 10
5.5 Server Behavior . . . . . . . . . . . . . . . . . . . . . 14 6.3.1. REGISTER Processing . . . . . . . . . . . . . . . . . 10
6. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.3.2. Request Origination . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . 15 7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 9.1. SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.2. Header Field Parameter . . . . . . . . . . . . . . . . . . 13
11.1 Normative References . . . . . . . . . . . . . . . . . . 15 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.2 Informative References . . . . . . . . . . . . . . . . . 16 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . 17 12.1. Normative References . . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
1. Introduction 1. Introduction
The Route header field in the Session Initiation Protocol (SIP) The Route header field in the Session Initiation Protocol (SIP)
protocol is used to cause a request to visit a set of hops on its way protocol is used to cause a request to visit a set of hops on its way
towards the final destination. RFC 3261 [2] discusses how a client towards the final destination. RFC 3261 [2] discusses how a client
constructs the Route header field for requests. However, this logic constructs the Route header field for requests. However, this logic
is restricted to mid-dialog requests, where the route set was learned is restricted to mid-dialog requests, where the route set was learned
as a result of record-routing. as a result of record-routing.
However, additional sources of routes can exist for a UA. These However, additional sources of routes can exist for a UA. These
include default outbound proxies, a service route learned from the include default outbound proxies, a service route learned from the
Service-Route header field [3], and a redirection coming from a 305 Service-Route header field [3], and a redirection utilizing loose
response. In total, there are four sources of potential route routing [7]. In total, there are four sources of potential route
headers. The way in which these various sources are reconciled is headers. The way in which these various sources are reconciled is
unclear. Furthermore, the various specifications are unclear about unclear. Furthermore, the various specifications are unclear about
which requests these Route headers are applicable to. Do they apply which requests these Route headers are applicable to. Do they apply
to REGISTER? Do they apply to mid-dialog requests? Finally, the to REGISTER? Do they apply to mid-dialog requests? Finally, RFC
existing specifications are incomplete and inconsistent. 3608 is underspecified, which can result in interoperability
problems.
Section 2 reviews the existing sources of route sources. Section 3 Section 2 reviews the existing sources of route sources. Section 3
discusses problems with the existing specifications. Section 4 discusses problems with the existing specifications. Section 5
overviews the proposed changes in behavior. Section 5 provides a overviews the proposed changes in behavior. Section 6 provides a
detailed description of element behavior, and Section 6 defines the detailed description of element behavior, and Section 7 defines the
grammar for the new headers specified here. grammar for the new parameters specified here.
2. Existing Sources 2. Existing Sources
This section examines the current set of route header field sources. This section examines the current set of route header field sources.
2.1 Default Outbound Proxies 2.1. Default Outbound Proxies
RFC 3261 discusses default outbound proxies. In Section 8.1.1.1, it RFC 3261 discusses default outbound proxies. In Section 8.1.1.1, it
makes reference to its interaction with Route header fields: makes reference to its interaction with Route header fields:
In some special circumstances, the presence of a pre-existing In some special circumstances, the presence of a pre-existing
route set can affect the Request-URI of the message. A pre- route set can affect the Request-URI of the message. A pre-
existing route set is an ordered set of URIs that identify a chain existing route set is an ordered set of URIs that identify a chain
of servers, to which a UAC will send outgoing requests that are of servers, to which a UAC will send outgoing requests that are
outside of a dialog. Commonly, they are configured on the UA by a outside of a dialog. Commonly, they are configured on the UA by a
user or service provider manually, or through some other non-SIP user or service provider manually, or through some other non-SIP
mechanism. When a provider wishes to configure a UA with an mechanism. When a provider wishes to configure a UA with an
outbound proxy, it is RECOMMENDED that this be done by providing outbound proxy, it is RECOMMENDED that this be done by providing
it with a pre-existing route set with a single URI, that of the it with a pre-existing route set with a single URI, that of the
outbound proxy. outbound proxy.
When a pre-existing route set is present, the procedures for When a pre-existing route set is present, the procedures for
populating the Request-URI and Route header field detailed in populating the Request-URI and Route header field detailed in
Section 12.2.1.1 MUST be followed (even though there is no Section 12.2.1.1 MUST be followed (even though there is no
dialog), using the desired Request-URI as the remote target URI. dialog), using the desired Request-URI as the remote target URI.
The default outbound proxy can be learned either through DHCP [6], The default outbound proxy can be learned either through DHCP [8],
through configuration (such as the SIP configuration framework [8]), through configuration (such as the SIP configuration framework [9]),
or through other means. In the IP Multimedia Subsystem (IMS), the or through other means. In the IP Multimedia Subsystem (IMS), the
default outbound proxy is the P-CSCF and is learned through GPRS default outbound proxy is the P-CSCF and is learned through GPRS
specific techniques. specific techniques.
RFC 3261 does not explicitly say the set of messages to which this RFC 3261 does not explicitly say the set of messages to which this
route set applies. However, the text above implies that it is for route set applies. However, the text above implies that it is for
all requests outside of a dialog. all requests outside of a dialog.
2.2 Service Route 2.2. Service Route
RFC 3608 specifies the Service-Route header field. This header field RFC 3608 specifies the Service-Route header field. This header field
is provided to the UA in a 2xx response to a REGISTER request. The is provided to the UA in a 2xx response to a REGISTER request. The
client uses this to populate its Route header fields for outgoing client uses this to populate its Route header fields for outgoing
requests. However, RFC 3608 explicitly says that the decision a UA requests. However, RFC 3608 explicitly says that the decision a UA
makes about how it combines the service route with other outbound makes about how it combines the service route with other outbound
routes is a matter of local policy. Furthermore, RFC 3608 does not routes is a matter of local policy. Furthermore, RFC 3608 does not
clearly define to which requests the service route applies, and in clearly define to which requests the service route applies, and in
particular, whether or not it applies to a REGISTER request or a mid- particular, whether or not it applies to a REGISTER request or a mid-
dialog request. dialog request.
Furthermore, RFC 3608 specifies that a service-route is associated Furthermore, RFC 3608 specifies that a service-route is associated
with an Address-of-Record (AOR), and is shared by all contacts with an Address-of-Record (AOR), and is shared by all contacts
associated with the same AOR. It also specifies that the Service- associated with the same AOR. It also specifies that the Service-
Route URI can only be ones known to the registrar apriori, as opposed Route URI can only be ones known to the registrar apriori, as opposed
to learned through the registration itself. to learned through the registration itself.
2.3 Record-Routes 2.3. Record-Routes
RFC 3261 provides a detailed description of the record-routing RFC 3261 provides a detailed description of the record-routing
mechanism, and how the user agents in a dialog construct route sets mechanism, and how the user agents in a dialog construct route sets
from the Record-Route header field values. RFC 3261 is also clear from the Record-Route header field values. RFC 3261 is also clear
that the resulting route set applies to mid-dialog requests. It that the resulting route set applies to mid-dialog requests. It
implies (though does not explicitly say) that the resulting route set implies (though does not explicitly say) that the resulting route set
overrides any default outbound proxies (which represent a pre-loaded overrides any default outbound proxies (which represent a pre-loaded
route set). route set).
2.4 305 Use Proxy 2.4. Loose Routes
RFC 3261 defines the 305 "Use Proxy" response code, but says
extremely little about exactly how it is used. It has this to say:
The requested resource MUST be accessed through the proxy given by
the Contact field. The Contact field gives the URI of the proxy.
The recipient is expected to repeat this single request via the
proxy. 305 (Use Proxy) responses MUST only be generated by UASs.
It is unclear how the Contact in the redirect is used. Does it
populate the request URI of the resulting request? Or, does it get
used to populate the Route header field? The restriction to UASs is
also not explained.
Historically, the reason for the restriction to UAs was to avoid
routing loops. Consider an outbound proxy that generates a 305,
instead of proxying the request. The concern was that the client
would then recurse on the response, populate the Contact into a new
request URI, and send the request to its default outbound proxy,
which redirects once more. To avoid this, the RFC says that only a
UAS can redirect with a 305, not a proxy.
However, this design decision on 305 handling was made prior to the Loose routing, introduced in [7], defines mechanisms for using Route
conception of loose routing, although both ended up in RFC 3261. The header fields to address and invoke services in a user agent. It
design of the 305 mechanism, unfortunately, was not revisited after also specifies a redirection mechanism whereby a server can redirect
loose routing was specified. As such, the draft is not clear about a client, and ask it to either modify the topmost Route header field
whether or not the contact gets utilized as a Route header field of its request, or add a new Route header field to the topmost
value or whether it replaces the Request URI. The assumption, request. The specification indicates that it is applicable to both
unstated, is that it populates the Request-URI, since redirection mid-dialog and out-of-dialog requests. Since the client can be a
works that way in general. user agent, this forms another potential source of a Route header
field for user agents.
3. Problems with Current Specifications 3. Problems with Current Specifications
Numerous problems have arisen as a consequence of the combination of Numerous problems have arisen as a consequence of the combination of
these specifications. These problems fit into two categories. The these specifications. These problems fit into two categories. The
first are interoperability problems, and the second are missing first are interoperability problems, and the second are missing
capabilities. capabilities.
An interoperability problem that has arisen is keeping an outbound An interoperability problem that has arisen is keeping an outbound
proxy on the path for outbound requests. Consider a proxy in a hotel proxy on the path for outbound requests. Consider a proxy in a hotel
skipping to change at page 6, line 6 skipping to change at page 5, line 37
the client abandons its default proxy in favor of the service route, the client abandons its default proxy in favor of the service route,
the hotel proxy would fall off the path of subsequent requests unless the hotel proxy would fall off the path of subsequent requests unless
it inserted a Service-Route into the response of a REGISTER request. it inserted a Service-Route into the response of a REGISTER request.
Interestingly, the latter is illegal behavior according to RFC 3608, Interestingly, the latter is illegal behavior according to RFC 3608,
but is the only mechanism available for ensuring that a proxy stay on but is the only mechanism available for ensuring that a proxy stay on
the request path. Since RFC 3608 does not provide any normative the request path. Since RFC 3608 does not provide any normative
behavior for combining service routes and outbound proxies, the hotel behavior for combining service routes and outbound proxies, the hotel
proxy cannot know what to do, thus causing the interoperability proxy cannot know what to do, thus causing the interoperability
problem. problem.
This points to the first major functional gap with the existing This points to the first major functional gap with RFC 3608. There
specifications. There is no standards-based way for keeping an is no standards-based way for keeping an outbound proxy on the path
outbound proxy on the path for outbound requests, when it is not the for outbound requests, when it is not the default outbound proxy.
default outbound proxy. Consider a proxy in a hotel, PH-1 which a Consider a proxy in a hotel, PH-1 which a client discovers via DHCP
client discovers via DHCP and uses as its outbound proxy. When the and uses as its outbound proxy. When the client sends a REGISTER to
client sends a REGISTER to this proxy, it forwards it to a second this proxy, it forwards it to a second proxy in the hotel, PH-2,
proxy in the hotel, PH-2, which then forwards it to the home proxy of which then forwards it to the home proxy of the user, PA. PH-2 needs
the user, PA. PH-2 needs to be on the outbound path for all requests to be on the outbound path for all requests leaving the hotel. PA
leaving the hotel. PA includes itself in a Service-Route header includes itself in a Service-Route header field in the response. The
field in the response. The client receives this Service-Route. For client receives this Service-Route. For an initial INVITE request,
an initial INVITE request, the client constructs a route set which the client constructs a route set which includes its outbound proxy
includes its outbound proxy PH-1 followed by the URI from the PH-1 followed by the URI from the Service-Route, PA. This request
Service-Route, PA. This request will traverse PH-1, which now will traverse PH-1, which now follows the next Route header, sending
follows the next Route header, sending it to PA. This is not the it to PA. This is not the desired behavior. The problem is that the
desired behavior. The problem is that the Service-Route URI has Service-Route URI has provided a route that overrides the default
provided a route that overrides the default outbound route behavior outbound route behavior at PH-1.
at PH-1.
Similarly, there is no way in the current specifications to change Similarly, there is no way in RFC 3608 to change the outbound proxy,
the outbound proxy, outside of an update in the client configuration. outside of an update in the client configuration. Such changes are
Such changes are extremely useful for many operational reasons. One extremely useful for many operational reasons. One example is
example is movement of subscribers between geographically distributed movement of subscribers between geographically distributed sites in
sites in cases where a site must be gracefully taken out of service, cases where a site must be gracefully taken out of service, and the
and the subscribers using it need to be moved gracefully, over a subscribers using it need to be moved gracefully, over a period of an
period of an hour or two, from one site to the other. Since, at hour or two, from one site to the other. Since, at best, the impact
best, the impact of Service-Route on the outbound proxy is ambiguous, of Service-Route on the outbound proxy is ambiguous, there is
there is generally no way to affect it excepting configuration generally no way to affect it excepting configuration change. Using
change. Using configuration updates as the only way to alter the configuration updates as the only way to alter the outbound proxy is
outbound proxy is problematic. In practice, systems providing problematic. In practice, systems providing automated updates to
automated updates to client configuration (when they exist, as they client configuration (when they exist, as they often do not) are
often do not) are decoupled from the operational systems that manage decoupled from the operational systems that manage subscriber
subscriber capacity and software upgrades of sites, making the change capacity and software upgrades of sites, making the change hard to
hard to affect through configuration. Furthermore, configuration affect through configuration. Furthermore, configuration updates are
updates are typically passed to clients once they are made. Here, typically passed to clients once they are made. Here, however, the
however, the objective is to gracefully move subscribers. Using the objective is to gracefully move subscribers. Using the randomized
randomized nature of REGISTER timings helps provide that; such a nature of REGISTER timings helps provide that; such a function is
function is difficult to accomplish through configuration updates. difficult to accomplish through configuration updates. Finally, many
Finally, many deployments use mechanisms other than [8] for updating deployments use mechanisms other than [9] for updating client
client configurations. As a consequence, there is no common way configurations. As a consequence, there is no common way across
across deployments to provide this very basic operational feature. deployments to provide this very basic operational feature.
Finally, it is important to note that there is an architectural Another problem that has come up with RFC 3608 is that it will not
inconsistency between record-routing and service route. With record- work well with mid-dialog failover techniques identified for SIP
route, each proxy on the path of the request inserts a Record-Route Outbound [10]. These techniques require that the outbound proxy
header field, and this dictates the path of subsequent messages construct a URI for the Service-Route that is used by the UA for new
within a dialog both to and from the UA. With REGISTER, each proxy requests outside of a dialog.
on the path of the request inserts a Path [4] header field to receive
requests directed towards the client. However, the Service-Route is
not the inverse of the Path, and is instead created through
proprietary means by the registrar.
4. Overview of Operation Finally, RFC 3608 is defined such that the service route is identical
for all contacts registered to a specific AOR. This makes it
applicable only for selecting a set of configured, well-known servers
to use, and only ones within the domain of the owner of that AOR.
This is a fairly narrow scope of applicability, and introduces a
configuration burden on the registrar.
Firstly, new behavior for generation and processing of the 305 Use Architecturally, there is an inconsistency between record-routing and
Proxy is specified. Any element in the network, proxy or UAS, can service route. With record-route, each proxy on the path of the
generate a 305, not just a UAS as specified in RFC3261. The 305 is request inserts a Record-Route header field, and this dictates the
directed towards a specific upstream element, whether it is a proxy path of subsequent messages within a dialog both to and from the UA.
or UAC, through the inclusion of the Redirect-Target header field in With REGISTER, each proxy on the path of the request inserts a Path
the response. This header field contains a counter that is [4] header field to receive requests directed towards the client.
decremented as the response is forwarded upstream. When it hits However, the Service-Route is not the inverse of the Path, and is
zero, that element recurses on it. instead created through proprietary means by the registrar.
This only works if the server that sends the 305 can be sure that all 4. Terminology
of the upstream elements between it and the target of the redirect
support this mechanism. To make this determination, the Target-Range
header field is used. This header field contains a pair of integers,
start-range and end-range. These integers correspond to the values
of the Max-Forwards header field across a set of compliant elements.
When the first element in a compliant chain (for example, a UAC
supporting this mechanism) emits a request, it sets both start-range
and end-range to the value of Max-Forwards in the request it emits.
A compliant element decrements both Max-Forwards and end-range before
forwarding the request if its policy says that downstream elements
are permitted to redirect elements upstream from it. If this is not
permitted, the element sets both start-range and end-range to Max-
Forwards in the outbound request, effectively starting the chain
afresh. However, a non-compliant element will only decrement the
value of Max-Forwards. As such, a compliant server can determine
whether the previous hop was compliant by comparing the value of Max-
Forwards in the received request with the value of end-range. If
they are identical, it means the previous hop supports the mechanism.
Therefore, this proxy is is extended an existing chain of compliant
elements, and it decrements both end-range and Max-Forwards before
sending the request. However, if the values of Max-Forwards and end-
range in the received request were not identical, it means that the
previous upstream element (and possibly ones upstream from that) were
not compliant. Therefore, this proxy is the first in a chain of
compliant elements. It therefore resets start-range and end-range to
the value of Max-Forwards in the request it emits.
Now, when a server receives a request, if Max-Forwards equals end- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
range, the server knows some number of upstream elements support this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
mechanism. Indeed, the exact number of such elements will be start- document are to be interpreted as described in RFC 2119 [1].
range minus end-range plus one. Thus, the server can insert the
Redirect-Target header field into the response with a value between 0
(directing the immediate upstream element to recurse) and start-range
minus end-range.
MF:70 MF:69 MF:68 MF:67 + 5. Overview of Operation
+-----+SR:70 .......SR:70 +-----+SR:68 +-----+SR:68 |-----+
| |ER:70 . .ER:70 | |ER:68 | |ER:67 | |
| |----->. .----->| |----->| |----->| |
| UAC | . P-1 . | P-2 | | P-3 | | P-4 |
| | . . | |<-----| |<-----| |
| | . . | |RT:0 | |RT:1 + |
+-----+ ....... +-----+ +-----+ -----+
|
|
V
Figure 1 This specification updates the behaviors in RFC 3608. In particular,
a registrar, upon receipt of a REGISTER, uses the Path header field
values to construct the Service-Route in the response. In addition,
the registrar retains an instance of the Path (and resulting Service
Route) for each registered contact. The Path and Service-Route
remain valid for the duration of the registration, and are updated
for each registration refresh.
This procedure is shown pictorially in Figure 1. The figure shows a In order to retain backwards compatibility with systems based on RFC
UAC and four proxies, P-1 through P-4. The UAC and proxies P-2 3608, proxies compliant to this specification include a flag, "p2sr",
through P-4 support the mechanism, but P-1 does not. The UAC emits in their Path header field values. When the registrar receives the
an INVITE request. It populates Max-Forwards (shown as MF in the REGISTER request, it examines the sequence of Path header field URI.
figure) with the initial value of 70. It also adds a Target-Range If it sees that one or more contiguous proxies at the end of the Path
header field to the request, with a start-range value (SR in the sequence do not support this mechanism, the registrar omits those URI
figure) of 70, and an end-range value (ER in the figure) of 70. This from the Service-Route, and omits the Require header field parameter
request is received by P-1. Since P-1 does not understand Target- indicating support for this specification in the response. This
Range, it only decrements Max-Forwards. The request is now received causes the UA to revert to existing behavior, augmenting the route
by P-2. P-2 sees that the value of Max-Forwards in the received set with the outbound proxy [[OPEN ISSUE: well, thats true for IMS at
request (69) does not match the value of end-range (70). Thus, it least. UA behavior isn't defined at all in this area in RFC 3608.
knows that its immediately upstream neighbor didn't support the Alternative is to have two option tags - one that says to augment,
mechanism. As such, when it emits its request, it sets the value of and one that says don't.]] If, however, all of the Path URI include
both start-range and end-range to the value of Max-Forwards, 68. the "p2sr" flag, an option tag is placed into the Require header
This request arrives at P-3. P-3 sees that the value of Max-Forwards field is placed in the response, indicating that the Service-Route
matches end-range. So, it decrements both in the request it emits. overrides the outbound proxy.
This request arrives at P-4. Again, the value of Max-Forwards equals
end-range. It subtracts end-range from start-range (68-67) and adds
1, which results in 2. This means that the 2 upstream elements
support the redirect targeting mechanism, and P-4 generates a 305
response with a Redirect-Target value of 1. This is received by P-3,
which decrements Redirect-Target to zero. This is received by P-2,
which sees that the value is zero. This means that it is the
intended target of the redirect. It therefore recurses on the
redirect and emits a new request.
[[OPEN ISSUE: This backwards compatibility mechanism could actually The rules for constructing the Route for a request at the UA follow
be used for all redirects; providing a mechanism to know and control in a straightforward manner from this. Mid-dialog requests always
where and when recursion is done. Indeed, the mechanism could use the set of URI learned from the Record-Route. A request outside
provide a general framework for allowing downstream servers to of the scope of a dialog, including a REGISTER refresh, uses the
determine whether a sequence of upstream servers supports some Service-Route, and based on the Require flag, may or may not override
extension. If one uses a sequence of ranges instead of a single the outbound proxy. Finally, in all cases, if a request generates a
range, full proxy support information can be delivered to the UAS. redirect response that contains a loose route, the Route set is
Is there a need for such a thing?]] further modified or augmented based on the redirection.
In addition to specifying new rules for generation and processing of 6. Detailed Processing Rules
the 305, this specification updates the behaviors in RFC 3608. In 6.1. Registrar Behavior
particular, a registrar, upon receipt of a REGISTER, uses the Path
header field values to construct the Service-Route in the response.
The values from the Path are copied into the Service-Route, and the
registrar can then add some additional ones if they are within the
domain of the provider. By allowing the registrar to add values, the
mechanism defined here is made a superset of the behaviors defined in
RFC 3608. There, the registrar can only add URI in its own domain.
Here, the registrar can add such URI, but also reflects Path headers
from the request, which may have come from other domains. In
addition, RFC 3608 defined the service route to be associated with an
AOR, rather than a registered contact. This specification modifies
that behavior. Instead, the service route will be associated with
each registered contact. Note that the registrar never needs to
store the service-route; it is computed as a function of the Path
header in the REGISTER request.
5. Detailed Processing Rules This specification updates the procedures from RFC 3608.
5.1 Registrar Behavior The procedures in this specification MUST NOT be followed unless the
REGISTER request contains a Supported header field with the "sr"
option tag.
This specification updates the procedures from RFC 3608. Assuming the REGISTER request contains this option tag, the registrar
examines the set of Path header field values, starting from the top
(the proxy closes to, but not including the registrar itself) towards
the bottom (the proxy farthest away from the registrar). If the
registrar is planning on adding itself to the Service-Route, it adds
itself to the top of the list. Its own URI MUST include the "p2sr"
Path header field parameter.
The registrar MUST construct the Service-Route in the registration If the resulting list is such that there are 0 or more contiguous
response by taking each URI from the Path header field in the values starting at the top which contain the "p2sr" Path header field
REGISTER request, and inverting the order. After inversion, the parameter, followed by 0 or more contiguous values which do not
registrar MAY add additional URIs at the end of the list (that is, contain this parameter, the registrar SHOULD follow the remaining
the right hand side of the list, corresponding to proxy elements that procedures of this specification in the construction of the Service-
will be the farthest away from the UA). Route header field in the response. If not, the procedures defined
here MUST NOT be used. In addition, if none of the Path header field
values contain the "p2sr" Path header field parameters, the
procedures defined here MUST NOT be used.
Furthermore, the registrar MAY replace or remove any URIs that are Consider the example network of Figure 1. The UAC is separated from
within a domain under the control of the registrar. When replacing a the registrar by three proxies, P1, P2 and P3. The UAC supports the
URI, one or more new ones can take its place. If the registrar is in mechanism in this specification and indicates this through the "sr"
example.com, this would include any URIs whose domain part is option tag in the Supported header field of its REGISTER request.
example.com. It would also include any URIs whose domain is a
subdomain of example.com, as long as that subdomain is under the
control of example.com. It could also include URIs whose domain part
is unrelated to example.com, as long as those are within the control
of example.com. It is difficult to provide a concise definition of
"under the control", but generally it means that the administrative
policies for the subservient domain are completely defined by the
controlling domain.
This behavior ensures that proxies outside of the domain of the +------+ +------+ +------+ +------+ +------+
registrar have a way to appear on the service route, but provides a | | | | | | | | | |
way, within a domain, to provide service routes that are not coupled | UAC |---->| P1 |----->| P2 |----->| P3 |----->| Reg |
to the Path. | | | | | | | | | |
+------+ +------+ +------+ +------+ +------+
[[OPEN ISSUE: Its unclear whether this mechanism is backwards Figure 1
compatible with current IMS procedures. The P-CSCF will insert Path,
but not expect for its URI to be in the outbound Route set. The
procedures here, for a UA compliant to this specification, will
result in an outgoing INVITE being delivered to the P-CSCF as a
consequence of it being the default outbound proxy, but the request
will arrive with the topmost route equal to the outbound proxy URI,
and the next route will be the Path URI. The route after that will
be the S-CSCF (or I-CSCF in the home domain if added to the service
route). Not clear that this will work. If it doesn't, it is easily
remedied by including a flag in the Path header which indicates
whether it needs to be reflected into Service-Route.]]
5.2 Proxy Behavior When the UAC registers, each of the proxies inserts itself onto the
Path header field of the REGISTER. Each of the proxies either
supports this extension (and thus inserts a "ps2r" parameter into its
Path header field value) or it does not (in which case no parameter
is inserted). The following table shows, for various Path sequences,
whether or not the modified Service-Route procedures of this
specification would be used.
When a proxy receives a request that contains the Target-Range header Path Header Field | Use New SR | Notes
field, it examines the value of end-range. If end-range is not equal | Procedures? |
to the value of Max-Forwards in the received request, the proxy MUST --------------------------------------------------------------------
set both end-range and start-range equal to the value of the Max- P3;p2sr, | |
Forwards header field in the request it emits. If they are equal, P2;p2sr, | Y | All proxies support it
the proxy MAY extend the chain of compliant elements, or MAY reset P1;p2sr | |
it, starting with itself. The decision depends on whether the proxy --------------------------------------------------------------------
wishes downstream elements to be able to generate redirects towards P3;p2sr, | | Proxies closest to registrar
upstream elements, and is a matter of local policy. If the proxy P2;p2sr, | Y | support, followed by ones
decides to reset it, it sets both end-range and start-range equal to P1 | | that don't
the value of the Max-Forwards header field in the request it emits. --------------------------------------------------------------------
If it decides to extend it, it sets end-range equal to the value of P3;p2sr, | | Proxies closest to registrar
the Max-Forwards header field in the request it emits and retains the P2 | Y | support, followed by ones
value of start-range. P1 | | that don't
--------------------------------------------------------------------
P3, | |
P2, | N | No proxies support it
P1 | |
--------------------------------------------------------------------
reg;p2sr | |
P3, | |Registrar planning on inserting
P2, | Y |itself onto the Service-Route
P1 | |
--------------------------------------------------------------------
P3, | | Set of proxies that support
P2;p2sr, | N | it must be contiguous and
P1 | | closest to registrar
--------------------------------------------------------------------
P3;p2sr, | | Set of proxies that support
P2, | N | it must be contiguous and
P1;p2sr | | closest to registrar
--------------------------------------------------------------------
When a proxy receives a 305 response, it MUST check the value of the Figure 2
Redirect-Target header field. If this value is non-zero, the proxy
MUST decrement it by one before forwarding the 305 upstream, and MUST This constraint basically says that the Path has to be built
NOT recurse on the 305. If the value is zero, the proxy follows the either by a proxy chain which all support this spec, or by a chain
procedures in Section 5.4. whereby a bunch didn't support it, followed by a bunch that did.
This works well in IMS deployments where the visited network
doesn't support the mechanism, but the home network does.
If the mechanisms in this specification are to be used, the registrar
MUST construct the Service-Route in the registration response by
taking each URI from the list which contained the "p2sr" header field
parameter, and inverting the order. The registrar MUST add an option
tag to the Require header field in the response (adding the header
field if necessary) with the value "sr". The URI in the Service-
Route header field values SHOULD NOT contain the "p2sr" parameter;
that parameter is a Path header field value and is not needed in the
Service-Route.
The resulting Service-Route MUST be recomputed for each registration
refresh, and for each new registration. The server MAY store the
values associated with it, though this is not necessary for proper
operation of this specification.
In addition, the registrar MUST only return in a 200 OK response to
the REGISTER request, the Contact header field associated with the
registration which was just performed. [[OPEN ISSUE: This is really
orthogonal, and it is probably controversial. Basically it proposes
to use this new service route mechanism as a vehicle for eliminating
query registers and third party registrations.]]. A UA compliant to
this specification will never generate a registration with anything
except for a single Contact.
If the mechanisms in this specification are not used, the registrar
MUST follow the procedures of RFC 3608 and construct the Service-
Route as it would otherwise. It MUST omit the "sr" option tag from a
Require header field in the response.
6.2. Proxy Behavior
This specification updates the proxy processing rules in RFC 3608. This specification updates the proxy processing rules in RFC 3608.
In particular, if a proxy inserts a Path header field in a REGISTER
request, it means that a compliant registrar will echo the Path
header field back into the REGISTER response as a Service-Route
header field value. The proxy MAY remove its value from the Service-
Route in the response, or MAY modify it. If the REGISTER response
does not contain a Service-Route value that includes the Path URI
inserted by the proxy, it means that the registrar is not compliant
to this specification. [[OPEN ISSUE: and then it does what??]
[[OPEN ISSUE: not sure if the following belongs here or not; its not A proxy compliant to this specification which inserts a Path header
elaborated on anywhere else and is just a placeholder]] field value into a REGISTER request MUST include a "p2sr" Path header
field parameter with its value. If the response to the REGISTER
request includes the Require header field that includes the "sr"
option tag, it means that the UA will be using that URI (which will
be echoed in the Service-Route) as a Route header field value for
requests outside of a dialog. In this case, the proxy MAY remove its
value from the Service-Route in the response, or MAY modify it.
If the proxy receives a request destined for the AOR of a subscriber, When the UA initiates a request outside of a dialog, that request
and the proxy is the responsible proxy for that domain, it looks up will contain a route set which includes the URIs learned from the
the AOR in the location database, and retrieves the Path URI and the Service-Route. Consequently, a proxy MUST be prepared to receive
registered Contact. However, instead of rewriting the request-URI to such a request, in which case the topmost Route header will be the
be equal to the registered contact, if that contact contains the URI URI the proxy passed to the UA in the 200 OK response to REGISTER.
loose-route parameter, the proxy retains the request URI, and instead
uses that registered contact URI as the last Route header field
value. In this way, the UAS will receive new requests with the AOR
retained in the request URI, and a topmost Route header field
present, with a URI containing the registered contact.
5.3 UAC Behavior 6.3. UAC Behavior
A UAC which supports the 305 recursion mechanism, including the 6.3.1. REGISTER Processing
Response-Target and Target-Range header fields, MUST include the
Target-Range header field in all requests it emits, excepting CANCEL
and ACK. This header field MUST have the start range and end range
values equal to the value of Max-Forwards in the request emitted by
the UAC.
Determination of the route set for a request is done in two steps. A UA compliant to this specification MUST include the "sr" option tag
The first is the determination of a baseline route set. This set is in the Supported header field of its REGISTER request. Such a UA
the route set determined strictly by protocol mechanisms, and has not MUST include only a single Contact in each REGISTER request, which
yet been subject to UA policies which might require alteration of the points to the UA performing the registration. It MUST NOT generate a
route set. Those policies are then applied, and the result is the "query REGISTER" which contains no contacts, MUST NOT include
final route set for the request. multiple Contact header field values in its registration, and MUST
NOT register a Contact which does not directly point to the UA
itself.
For a request sent by a UAC that is not the result of recursion on a When the REGISTER response arrives, and it is a 2xx response, the UA
305, the following logic MUST be used to compute the baseline route looks for the presence of a Supported header field in the response
set: with the "sr" option tag. If present, the UA is operating in
"override" mode, as described below. If not present, the UA is
operating in "augment" mode, as described below. In either case, the
UA MUST cache the contents of the Service-Route header field for the
duration of its registration.
A single UA may still be performing multiple registrations, for
purposes of high availability, as a consequence of the procedures
defined in SIP outbound [6]. In this case, the UA will end up with
multiple sets of Service-Route, each of which is bound to the
particular flow that was registered (and its associated Contact).
6.3.2. Request Origination
It is RECOMMENDED that a UA compliant to this specification also be
compliant to UA loose routing [7]. This allows proxies to utilize a
redirection to further augment the way in which the route set for a
request is constructed.
The primary question addressed by this specification is how the UA
constructs the route set for a request.
Determination of the route set for a request depends on whether the
request is generated as a consequence of a redirection. If the UA
indicated support for loose routing in its request (as described in
[7], the Route set for the recursed request is generated from the
request which generated the recursion, as described there.
This specification assumes that a UA may have one or more configured
outbound proxies, each in the form of a SIP URI. Each of these will
either be a loose route (in which case the request would contain that
URI in the Route header field) or not (in which case the UA will just
send the request to that target without including its URI in the
topmost Route request).
For a request sent by a UAC that is not the result loose route
recursion, the following logic MUST be used to compute the route set:
o If the request is a mid-dialog request, the route set is computed o If the request is a mid-dialog request, the route set is computed
per the procedures in Section 12.2.1.1 of RFC 3261. The baseline per the procedures in Section 12.2.1.1 of RFC 3261. The route set
route set will not contain any routes learned from configuration, will not contain any routes learned from configuration, DHCP,
DHCP, Service-Route or any other mechanism. Service-Route or any other mechanism.
o If the request is not a mid-dialog request, the client checks to o If the request is not a mid-dialog request, the client checks to
see if it has learned a service route as a result of registration. see if it has learned a service route as a result of registration.
The UAC may have learned numerous service routes, one for each The UAC may have learned numerous service routes, one for each
unique AOR/Contact that it registered. In the case of unique AOR/Contact that it registered. In the case of
registrations using the mechanisms of [5], the Contact includes registrations using the mechanisms of [6], the Contact includes
the flow ID and instance ID, so that the client may have a the flow ID and instance ID, so that the client may have a
distinct service route for each unique AOR/Flow ID/Instance ID distinct service route for each unique AOR/Flow ID/Instance ID
combination. As such, when sending a request, the client selects combination. As such, when sending a request, the client selects
the service route corresponding to the contact which is sending the service route corresponding to the contact which is sending
the request. [[OPEN ISSUE: Need to say more about this the request. [[OPEN ISSUE: Need to say more about this
selection.]]. Once a service route has been selected, the URIs selection.]]. If the UA is operating in "override" mode for this
from this service route become the baseline route set. Here too, route set, the URIs from this service route become the route set.
the baseline route set will not contain any routes learned from If the UA is operating in the "augment" mode for this route set,
configuration, DHCP, or other service routes. the UA takes the outbound proxy URI it used for the REGISTER
request which created the route set, and appends that URI to the
top of the service route.
o If the request is not a mid-dialog request, and there are are no o If the request is not a mid-dialog request, and there are are no
service routes associated with the contact generating the request, service routes associated with the contact generating the request,
the UAC uses the route set learned through configuration. [[OPEN the UAC uses the route set learned through configuration. [[OPEN
ISSUE: Do we need to specify how to reconcile route sources ISSUE: Do we need to specify how to reconcile route sources
learned across disparate configuration sources? For example DHCP learned across disparate configuration sources? For example DHCP
and a config file? These can come from different providers.]] and a config file? These can come from different providers.]]
If the request is being generated as a consequence of a 305, the If the topmost URI in the resulting route set is not a loose route
baseline route set is computed as described in Section 5.4. (which can happen when there is a configured outbound proxy that is
not a loose route), the UA MUST remove that URI from the Route set,
but still use it for purposes of sending the request.
With the baseline route set computed, the UAC applies policy to 7. Grammar
determine whether this route set needs to be modified. The primary
factor involved is whether or not the client needs to send this
request through its outbound proxy or not. The following logic is
RECOMMENDED. If the topmost URI in the baseline route set equals the
configured default outbound proxy for the UAC, then the baseline
route set is used unmodified, and used as the final route set. If,
however, it does not, the UAC checks a white list of URI that it
maintains. If the topmost URI appears on that white list, the
baseline route set is used as the final route set. If it is not
present, the default outbound proxy URI is appended to the top of the
route set.
The white list represents destinations that the UA has confidence are This specification defines an option tag and a Path header field
ones permitted to be used. Here, this implies that the provider of parameter. Their syntax is as follows:
the default outbound proxy allows that URI to be used in its place.
This white list can be provided by configuration, but this is
cumbersome and NOT RECOMMENDED. Instead, the following algorithm is
RECOMMENDED. Initially, the white list is empty when a UA starts up.
If a UA receives a 305 to a REGISTER request it generates, the URI in
the Contact header field of the redirect are added to the white list.
This will cause the REGISTER to be sent with one of these URI as the
topmost URI in the route set. If that registration succeeds, the URI
are retained in the white list for the duration of the registration.
The client maintains a separate white list for each registered
contact.
This algorithm works because of two factors. Firstly, registrations option-tag \= "sr"
are always targeted towards the domain of the subscriber, and are rr-param \= "p2sr"
never delivered to user agents. As such, the mechanism relies on
trust between the provider of the outbound proxy and provider of the
AOR for the subscriber to follow the 305 mechanism described here
correctly. However, if that trust doesn't exist, basic call
processing is not possible in any case. The second factor is the 305
mechanism itself. If the outbound proxy doesn't support this
specification, or the provider of the outbound proxy doesn't wish the
provider of the AOR to bypass the outbound proxy, the 305 mechanism
allows this to be known to the provider of the AOR. Thus, the
provider of the AOR can only bypass the outbound proxy if permitted
by the provider of the outbound proxy. Typically, this would only be
allowed when they are the same provider. The 305 mechanism allows
the outbound proxy to bypass itself, since the outbound proxy can
generate a 305 as long as the client supports the mechanism in this
specification.
5.4 Client Behavior 8. Security Considerations
The following logic defined here applies to all clients, both UAC and The route set used by a user agent for generating initial requests
proxies, and applies to the processing of a 305 response. into the network is very sensitive information. If this information
is manipulated by an attacker, it can cause calls to be directed
towards intermediaries, which can then observe call patterns,
intercept communications, and so on. Consequently, a UA using this
specification SHOULD use sips when performing a registration. This
makes sure that only entities along the request path can modify the
route set used by the UA.
When a client receives a 305 response, it MUST check for the presence Even with sips, it is possible that a malicious home proxy could
of the Response-Target header field. If this header field is absent, modify the route set used by the UA, eliminating the outbound proxy
the client MAY recurse on the request. However, in this case, the that would otherwise be used by it. This kind of attack is only
recursion MUST be accomplished by replacing the request URI of the meaningful in environments where the outbound proxy is in a different
request it generates with the value of the Contact header field in domain than the home proxy. However, presumably the outbound proxy
the 305 response. This provides backwards compatibility with the is present to authorize access to services, and removing it will only
existing usage of 305, since all redirection defined in RFC 3261 result in denial of service to the user, which would appear to
updates the Request-URI. If the Response-Target header field is provide no benefit.
present, but has a non-zero value, the client MUST NOT recurse on the
redirect. If the Response-Target header field is present and has a
value of zero, the client MUST recurse on the redirect.
To compute the request that is sent as a result of the recursion, the 9. IANA Considerations
client MUST take the route set used for the request that generated
the 305 response. If that request had a Route header field, the
first value MUST be replaced with the value of the Contact header
field in the 305 with the highest q-value. If there are multiple
such Contacts with the same q-value, one is chosen at random. The
result is used as the route set for the new request. If the client
is a UAC, it follows the procedures defined in Section 5.3. If the
client is a proxy, it follows the procedures definde in Section 5.2.
[[ISSUE: There are three choices about how to process the contact in This specification registers a new option tag and a new Path header
the 305. The URI there can replace the route set at the client field parameter.
completely, they can be appended to the route set, or they can
replace the topmost route. This draft employs the latter technique.
Further consideration is needed to determine whether or not this is
the right thing. Since the contact can contain multiple URI, we
could actually have it contain the entire route set that should
replace the one from the request.]]
If a 305 response had multiple Contact header field values, and the 9.1. SIP Option Tag
recursed request generated a 503 response, and the client had
exhausted all alternative servers learned from DNS [7] for the
previous Contact header field value, the client SHOULD choose the
Contact from the 305 with the next highest q-value, and construct
another recursed request using the procedures defined above. In the
event the 305 had multiple Contact header field values with
equivalent q-values, the next highest one might have a q-value equal
to the one that was just tried.
5.5 Server Behavior This specification registers a new SIP option tag, as per the
guidelines in Section 27.1 of RFC 3261.
Any server, either a UAS or a proxy, MAY generate a 305 in response Name: sr
to a request. However, it MUST NOT do so unless the request contains
a Target-Range header field, and the value of end-range in that
header field equals the value of Max-Forwards in the received
request. If the server generates a 305, it MUST direct that redirect
to a specific upstream element. To do so, it includes a Redirect-
Target header field in the response. That header field identifies a
specific element that is the target of the redirect. A value of 0
indicates that the element immediately upstream is the target, 1
indicates that the target is the second upstream element, and so on.
The value of Redirect-Target MUST be between 0 and start range minus
end range.
6. Grammar Description: This option tag is used to identify the usage of Path
reflected Service-Route, as defined by RFC XXXX [[NOTE TO IANA:
Please replace XXXX with the RFC number of this specification]]
This specification defines two new header fields - the Target-Range 9.2. Header Field Parameter
and Redirect-Target header fields. Their syntax is as follows:
Target-Range = "Target-Range" HCOLON start-range SWS "-" SWS end-range This specification defines the "p2sr" header field parameter, as per
Redirect-Target = "Redirect-Target" HCOLON target-val the registry created by [5]. The required information is as follows:
start-range = 1*DIGIT
end-range = 1*DIGIT
target-val = 1*DIGIT
7. Security Considerations Header field in which the parameter can appear: Path
The route set used by a user agent for generating initial requests Name of the Parameter: p2sr
into the network is very sensitive information. If this information
is manipulated by an attacker, it can cause calls to be directed
towards intermediaries, which can then observe call patterns,
intercept communications, and so on. As a consequence, the
mechanisms in this specification to take care that this route set can
only be updated on very specific conditions. Furthermore, the 305
mechanism defined here gives service providers policy hooks that
allow them to control whether such redirection can be employed by
exteranl service providers.
[[ISSUE: needs more verbiage here]] RFC Reference: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the
RFC number of this specification.]]
8. IANA Considerations 10. Examples
9. Examples TODO.
10. Acknowledgements 11. Acknowledgements
The author would like to thank Paul Kyzivat and Anders Kristensen for The author would like to thank Paul Kyzivat and Anders Kristensen for
their comments. their comments.
11. References 12. References
11.1 Normative References 12.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) [3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
Extension Header Field for Service Route Discovery During Extension Header Field for Service Route Discovery During
Registration", RFC 3608, October 2003. Registration", RFC 3608, October 2003.
[4] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) [4] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
Extension Header Field for Registering Non-Adjacent Contacts", Extension Header Field for Registering Non-Adjacent Contacts",
RFC 3327, December 2002. RFC 3327, December 2002.
[5] Jennings, C. and R. Mahy, "Managing Client Initiated Connections [5] Camarillo, G., "The Internet Assigned Number Authority (IANA)
Header Field Parameter Registry for the Session Initiation
Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[6] Jennings, C. and R. Mahy, "Managing Client Initiated Connections
in the Session Initiation Protocol (SIP)", in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-02 (work in progress), March 2006. draft-ietf-sip-outbound-04 (work in progress), June 2006.
11.2 Informative References [7] Rosenberg, J., "User Agent Loose Routing in the Session
Initiation Protocol (SIP)",
draft-rosenberg-sip-ua-loose-route-00 (work in progress),
October 2006.
[6] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP-for- 12.2. Informative References
IPv4) Option for Session Initiation Protocol (SIP) Servers",
RFC 3361, August 2002.
[7] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol [8] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP-
(SIP): Locating SIP Servers", RFC 3263, June 2002. for-IPv4) Option for Session Initiation Protocol (SIP)
Servers", RFC 3361, August 2002.
[8] Petrie, D., "A Framework for Session Initiation Protocol User [9] Petrie, D., "A Framework for Session Initiation Protocol User
Agent Profile Delivery", draft-ietf-sipping-config-framework-07 Agent Profile Delivery", draft-ietf-sipping-config-framework-09
(work in progress), July 2005. (work in progress), October 2006.
[10] Rosenberg, J., "Discovering Outbound Proxies and Providing High
Availability with Client Initiated Connections in the Session
Initiation Protocol (SIP)",
draft-rosenberg-sip-outbound-discovery-mid-dialog-00 (work in
progress), October 2006.
Author's Address Author's Address
Jonathan Rosenberg Jonathan Rosenberg
Cisco Systems Cisco Systems
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, NJ 07054 Parsippany, NJ 07054
US US
Phone: +1 973 952-5000 Phone: +1 973 952-5000
 End of changes. 75 change blocks. 
458 lines changed or deleted 401 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/