SIP J. Rosenberg
Internet-Draft Cisco Systems
Expires: April 16, 2007 October 13, 2006
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
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 16, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
In many deployment configurations, Session Initiation Protocol (SIP)
clients are capable of initiating connection requests towards their
SIP server, but the SIP server cannot open connections towards the
client. Specifications have been developed which allow for a client-
initiated connection to be used for incoming requests towards the
client. This outbound connection involves the use of a SIP proxy,
called an outbound proxy, that the client connects to. However, the
specification does not provide a means to discover the outbound
Rosenberg Expires April 16, 2007 [Page 1]
Internet-Draft Outbound Discovery and HA October 2006
proxy, nor does it support high availability for failures of the
outbound proxy mid-dialog. This specification fills those gaps. The
resulting mechanism additionally provides solutions for inter-proxy
connection reuse and usage of certificates with SIP.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7
4. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Choosing a Flow for Sending a Request . . . . . . . . . . 12
4.2. Associating URI with Flows . . . . . . . . . . . . . . . . 13
5. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 14
6. Connection Management . . . . . . . . . . . . . . . . . . . . 15
7. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 15
8. Outbound Proxy Behavior . . . . . . . . . . . . . . . . . . . 16
8.1. Receipt of Initial REGISTER . . . . . . . . . . . . . . . 16
8.2. Receipt of REGISTER Refresh . . . . . . . . . . . . . . . 17
8.3. Record-Routing Dialog Forming Requests . . . . . . . . . . 17
8.4. Additional Flow Selection Rule . . . . . . . . . . . . . . 17
8.5. Mid-Dialog Request Handling . . . . . . . . . . . . . . . 18
9. Home Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 18
10. Impacts to SIP Outbound . . . . . . . . . . . . . . . . . . . 18
11. Backwards Compatibility Considerations . . . . . . . . . . . . 19
12. Interactions with Connection Reuse . . . . . . . . . . . . . . 20
13. Security Considerations . . . . . . . . . . . . . . . . . . . 20
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
15. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
17.1. Normative References . . . . . . . . . . . . . . . . . . . 28
17.2. Informative References . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 31
Rosenberg Expires April 16, 2007 [Page 2]
Internet-Draft Outbound Discovery and HA October 2006
1. Introduction
The Session Initiation Protocol (SIP), RFC 3261 [1] allows a client,
called a user agent (UA) to initiate and receive communications
sessions. In order to receive an incoming SIP request, which may
arrive at any time, a SIP proxy will need to send a SIP request
towards a UA. In RFC 3261, this was done by having the proxy resolve
the domain name of the Request-URI [2] (if it had a hostname), and
then sending a request towards the resulting IP address, or opening a
TCP connection towards that address. In environments where there are
no NATs or firewalls between the UA and the proxy, this approach
works well. However, most modern deployments have NAT and firewall
devices between the UA and their proxy.
To resolve this, a specification, generally called sip-outbound [3]
was developed. This specification has the UA create a "flow" towards
its outbound proxy at the time of registration. A flow is equivalent
to a TCP connection in the case of TCP, and in the case of UDP, the
flow represents the 5-tuple used to send the UDP packet. Once the
flow is created, it is held open by the UA and the outbound proxy.
When an incoming request arrives from the network towards the UA, it
is routed to the outbound proxy. The outbound proxy then routes the
request over the existing flow created by the client. SIP-outbound
also provides a keepalive mechanism, utilizing the Simple Traversal
Underneath NAT (STUN) [5], generated by the client, which keeps any
bindings allocated by the NAT fresh. The keepalive also allows the
client to detect failures of its outbound proxy, and initiate a new
connection when this happens. SIP-outbound also allows a client to
open multiple flows to different outbound proxies, which provides
high availability. In case of proxy failure, a new incoming request
can get routed over the second connection, and the UA can eventually
re-establish a second connection.
However, sip-outbound does not address two issues that are key to
deployment. Firstly, it does not specify how a client discovers its
outbound proxy. In many deployments, a domain will separate the
outbound proxy from the home proxy; the latter being the proxy which
provides registration processing and location service functions. A
UA will initially only have its address-of-record. A DNS lookup of
its AOR using RFC 3263 [2] will necessarily return the IP address of
the home proxy, since that is the proxy that needs to be contacted by
clients that direct calls towards the UA. However, a UA nedes to
direct its initial registration towards its outbound proxy.
The second issue is that of mid-dialog failover. SIP-outbound
explicitly states that it does not support mid-dialog failover.
Specifically, if a UA has flows to a multiplicity of outbound
proxies, and in the middle of a dialog, the proxy through which
Rosenberg Expires April 16, 2007 [Page 3]
Internet-Draft Outbound Discovery and HA October 2006
requests within that dialog are flowing should fail, any mid-dialog
requests will not be delivered. Supporting mid-dialog failover
requires three properties which currently are not present in SIP-
outbound, as illustrated in Figure 1. There are three outbound
proxies, and the UA has established flows through numbers 2 and 3.
Proxy 2 fails. For a mid-dialog request to be delivered, the
following must happen:
+---------+ +---------+
| | | |
| Home | | Home |
| Proxy | | Proxy |
| | | |
+---------+ +---------+
*
*
* (1)
/ *
\ // *
\\ // V
+---------+ +\-------/+ +---------+
| | | \\ // | | |
| Outbound| | Ou\b/und| | Outbound|
| Proxy | | Pr/X\ | | Proxy |
| 1 | | // 2 \ | | 3 |
+---------+ +/------\\+ +---------+
// \ *
/ ** ^
** **
(2) ** **
** **
** ** (3)
V **
**
+---------+ **
| | *
| UA |
| |
| |
+---------+
Figure 1
1. When a mid-dialog request arrives at the home proxy (any home
proxy), it has to know to deliver the request to another outbound
proxy, and specifically, the outbound proxy to which the UA has
another flow (proxy 3)
Rosenberg Expires April 16, 2007 [Page 4]
Internet-Draft Outbound Discovery and HA October 2006
2. When the request arrives at the backup outbound proxy, it has to
know to deliver it over an existing flow towards the UA.
3. When the UA originates a request, it needs to know to deliver it
through the backup proxy.
Currently, sip-outbound will not result in these three behaviors.
When the original dialog-forming request passes through outbound
proxy 2, it will record-route with a URI which routes back to itself.
Thus, mid-dialog requests would not be delivered to the backup proxy.
Should proxy two instead record-route with a cluster URI (one that
identifies all three outbound proxies), there is no way for the home
proxy to know that outbound proxy 1 could not be used for delivering
message 1.
2. Requirements
We believe that there are several key requirements to the solution:
REQ 1: The solution should ensure that, if a proxy inserted a URI
into a Record-Route header field, that it should continue to see
that URI in the Route header fields of mid-dialog requests, even
if the mid-dialog request is sent to a backup proxy. Many
implementations place state and other critical information into
the user part of the Record-Route header field, and use that
information in all mid-dialog requests for proper processing of
the call. Consequently, this property has to be retained for
existing implementations to continue to rely on this feature of
SIP.
REQ 2: The solution should not require that edge proxies have to
replicate any kind of dynamic state between them. However, it is
acceptable that the solution be limited to failover cases where
the proxies in a cluster which back each other up are all from the
same vendor, and thus can share common proprietary algorithms,
such as those for construction of URIs.
REQ 3: The solution shall work in cases where the outbound proxy is
in the same domain as the home proxy, and ones where it is not in
the same domain.
REQ 4: The solution shall not require that there are no further
proxies between the outbound proxy and the home proxy. For
example, in 3gpp IMS, the outbound proxy would be the P-CSCF, and
the home proxy the S-CSCF. There can be an additional proxy, the
I-CSCF, between the two.
Rosenberg Expires April 16, 2007 [Page 5]
Internet-Draft Outbound Discovery and HA October 2006
REQ 5: The solution shall not require any non-standard uses to DNS,
nor shall it require any unduly complication DNS configurations to
be supported. In particular, it shall not introduce any
additional DNS configuration requirements beyond those already
specified in RFC 3263. Coordination of DNS and SIP network
configurations is a common source of operational difficulty, and
this solution should not exacerbate it.
REQ 6: The solution shall work even for clients with no DNS, which
have only a static mapping between their AOR and a set of IP
addresses for the home proxy it maps to. Unfortunately, some
deployments support very thin clients which do not rely on DNS at
all.
REQ 7: The solution shall support failures of the outbound proxy,
failures of the NAT between the client and its outbound proxy, and
transient errors and network problems which cause loss or
disconnection of TCP connections between the client and its
outbound proxy.
Rosenberg Expires April 16, 2007 [Page 6]
Internet-Draft Outbound Discovery and HA October 2006
3. Overview of Operation
example.com
.....................................
. .
. +---------+ +---------+ .
. | | | | .
. | Home | | Home | .
. | Proxy | | Proxy | .
. | 1 | | 2 | .
. +---------+ +---------+ .
. .
.....................................
outbound.example.com
......................................................
. .
. +---------+ +---------+ +---------+ .
. | | | | | | .
. | Outbound| | Outbound| | Outbound| .
. | Proxy | | Proxy | | Proxy | .
. | 1 | | 2 | | 3 | .
. +---------+ +---------+ +---------+ .
. .
......................................................
+---------+
| |
| UA |
| |
| X |
+---------+
Figure 2
We explain operation of the system using the network model of
Figure 2. This figure shows a UA, X, with an AOR of
sip:X@example.com. There are three outbound proxies, and two home
proxies. The home proxies share registration state through some
database mechanism, not shown.
Rosenberg Expires April 16, 2007 [Page 7]
Internet-Draft Outbound Discovery and HA October 2006
The mechanism is best explained by example. Though the algorithm
itself is simple and relatively easy to specify, the rationale of why
it works is less clear and requires a call flow to best understand.
The mechanism assumes that the UA starts with knowledge of its AOR
(sip:x@example.com) and credentials for authenticating itself to that
AOR. The mechanism also assumes that the UA is aware of zero or one
domain names for an outbound proxy farm. In cases where the SIP
server DHCP option [7] is used, this will provide the client with a
domain name with which it can construct a SIP URI of the form sip:
domain-name. In such a case, this will give the client a single
outbound proxy URI. In this example, DHCP would return
outbound.example.com, which points to the cluster of three outbound
proxies. If DHCP is not used, proprietary link-layer technologies,
such as those used in IMS, can provide the client with an IP address
or port for its outbound proxy. If no such mechanism is used, the
client starts with zero outbound proxy URIs.
If the UA has no outbound proxy learned from DHCP, it sends its
REGISTER request to the home proxy. The home proxy redirects the
request with a 305, pointing towards the outbound proxy farm.
The REGISTER is then processed by a proxy in the outbound proxy farm
(say, proxy 1), and a home proxy (say proxy 1). Prior to forwarding
the 200 OK response to the initial REGISTER request, outbound proxy 1
will add an Alternative-Proxies header field, which contains a URI
for each additional proxy that A would like to client to use as an
outbound proxy. The UA will add those URIs to its outbound proxy
set, and proceed to REGISTER through them. This provides a dynamic
discovery mechanism, whereby a client can start with zero outbound
proxies and learn a set of N outbound proxies, selected by the
provider at the time of registration. This dynamic selection gives
great flexibility into the set used for any particular UA.
Furthermore, since the selection is done by the proxies themselves,
high availability is facilitated.
To achieve high availability, new rules for determining where to send
a request are defined. The idea is that each flow is associated with
URI learned through SIP transactions passing over that flow. When a
client (whether its a UA or a proxy) goes to send a request, it
chooses the flow that is associated with the URI which is a 'longest
match' to the URI that the request is to be sent to. This causes a
form of 'stickiness', whereby once a request for a particular URI has
been sent through a flow, it tends to stay on that flow. To take
advantage of this for HA, the outbound proxies insert a URI into the
Path header field of the REGISTER (which is in turn echoed in the
Service-Route) which points to the entire cluster
(outbound.example.com) but contains a user part that is distinct for
Rosenberg Expires April 16, 2007 [Page 8]
Internet-Draft Outbound Discovery and HA October 2006
the user performing the registration and identifies the proxies that
have been selected for that user. This stickiness applies to both
the flow between the UA and outbound proxies, and between the
outbound proxies and the home proxy which processed the each
registration. This is shown in Figure 3. The Path URI used for the
registration from UA X (which we denote as "X-Path") is associated by
the UA with the flows to outbound proxies 2 and 3. The same URI is
linked to the flow from home proxy 1 to outbound proxy 2 and home
proxy 2 to outbound proxy 3 (we assume each home proxy processed one
of the two registrations).
example.com
.....................................
. .
. +---------+ +---------+ .
. | | | | .
. | Home | | Home | .
. | Proxy | | Proxy | .
. | 1 | | 2 | .
. +---------+ +---------+ .
. X-Path \ X-Path \ .
.............\...............\.......
\ \
\ outbou\d.example.com
......................\...............\...............
. \ \ .
. +---------+ +---------+ +---------+ .
. | | | | | | .
. | Outbound| | Outbound| | Outbound| .
. | Proxy | | Proxy | | Proxy | .
. | 1 | | 2 | | 3 | .
. +---------+ +---------+ +---------+ .
. | -- .
..........................|.............--............
| --
| --
| --
| --
| --
X-Path| -- X-Path
+---------+
| |
| UA |
| |
| X |
+---------+
Rosenberg Expires April 16, 2007 [Page 9]
Internet-Draft Outbound Discovery and HA October 2006
Figure 3
When the UA initiates a call, the topmost Route will be the Service
Route (which is identical to the Path URI), causing the request to
'stick' to one of the two existing flows. Similarly, when an
incoming request arrives at home proxy 1, the resulting Path will
produce a Route who's URI is an exact match for the flow to outbound
proxy 2, causing the request to go to the 'right' place. Had the
initial two registrations both been handled by home proxy 2, and an
incoming request was delivered to home proxy 1, home proxy 1 would
not have the Path URI associated with a flow to the right outbound
proxies. Thus, it will choose one of the three proxies arbitrarily
(based on RFC 3263 [2]. If it should pick the wrong one (outbound
proxy 2), the remedy is simple. The user part of the Path URI
contains information about which of the outbound proxies were used
for UA X. Outbound proxy 1 would see that it was not one of the
proxies, and use a 305 [6] to redirect home proxy 1 towards home
proxy 2 or 3. This request would then be delivered, and also cause
home proxy 1 to now have a cached 'stickiness' from the Path URI to
the right outbound proxy. This would avoid the need for future
redirections as long as the home proxy retains this association.
As the call setup request passes through the outbound proxy, it
record-routes with the same URI that was used in the Path, but with
an additional dialog-specific URI parameter. This parameter can be
used to contain additional dialog state (if needed). This causes
both the home proxy and the UA to associate this URI to the flow
through the proxy used for the dialog. This is shown pictorially in
Figure 4. In this example, the call was setup through outbound proxy
2 and home proxy 1. The outbound proxy record-routed with URI
"2-RR", which is identical to "X-Path" but with the addition of an
additional parameter. This URI is therefore the most specific match
to "2-RR" but is also a less-specific match to "X-Path". This is the
key to mid-dialog HA.
Rosenberg Expires April 16, 2007 [Page 10]
Internet-Draft Outbound Discovery and HA October 2006
example.com
.....................................
. .
. +---------+ +---------+ .
. | | | | .
. | Home | | Home | .
. | Proxy | | Proxy | .
. | 1 | | 2 | .
. +---------+ +---------+ .
. X-Path \ X-Path \ .
......2-RR...\...............\.......
\ \
\ outbou\d.example.com
......................\...............\...............
. \ \ .
. +---------+ +---------+ +---------+ .
. | | | | | | .
. | Outbound| | Outbound| | Outbound| .
. | Proxy | | Proxy | | Proxy | .
. | 1 | | 2 | | 3 | .
. +---------+ +---------+ +---------+ .
. | -- .
..........................|.............--............
| --
| --
| --
| --
2-RR | --
X-Path| -- X-Path
+---------+
| |
| UA |
| |
| X |
+---------+
Figure 4
Consider once more the failure of outbound proxy 2. The remote UA in
the dialog sends a mid-dialog request, such as a BYE. This arrives
at home proxy 2. The next Route header is "2-RR". Home proxy 1
finds this to be the most specific match to the flow to outbound
proxy 2. However, this proxy has crashed (a fact that is discovered
by home proxy 1 through any number of means). "2-RR" is a less
specific match for X-Path, and thus the request goes on that flow
next, arriving correctly at the backup proxy, outbound proxy 3.
Outbound proxy 3 has access to any state or state references that
Rosenberg Expires April 16, 2007 [Page 11]
Internet-Draft Outbound Discovery and HA October 2006
outbound proxy 2 placed into the Record-Route URI. It extracts
information from the user part of the record-route, which identifies
that this is a URI for user X, and thus is can be handled by sending
the request over the flow that the proxy has towards UA X.
Similar processing happens for requests initiated by UA X. A mid-
dialog request will have a topmost Route header field with a value of
"2-RR" and thus be the most specific match for outbound proxy 2, but
fall back to outbound proxy 3 should number 2 be unavailable.
When outbound proxy 2 recovers it will immediately begin receiving
mid-dialog traffic for the dialogs. If it likes, it can redirect
such requests towards outbound proxy 3, using a URI which will
'stick' future mid-dialog requests to outbound proxy 3 instead.
The association of URI to flows has to be maintained by proxies and
the UA. This requires them to track dialog state in order to be most
effective. However, if this state is lost, it is gracefully
recovered through subsequent signaling, at the cost of additional
redirects that cause it to be re-built. For this reason, this state
does not need to be replicated between components in a cluster.
4. Client Behavior
The rules defined here apply to any client, whether its a user agent
client or proxy. Two sets of rules are defined. One is for
associating URIs with flows, and the other for choosing a flow for
sending a request.
All clients compliant with this specification MUST support the 305
redirect mechanism and the revised Service-Route semantics described
in [6]. This mechanism will cause a UA, if it receives a 305, to use
the URI in the Contact of the 305 in a Route header of the redirect,
rather than populating the Request-URI.
4.1. Choosing a Flow for Sending a Request
When a client sends a request, that request will always be directed
towards a SIP URI. This would be the topmost Route header field in
the request if Route was present, else the Request-URI. Call this
the target URI. The client will need to decide whether to send a
request for a particular target URI on an existing flow or a new
flow, and if on an existing flow, which one. This is done by
comparing the target URI to the URIs associated with each existing
flow. The essential idea is to pick a flow that is the 'most
specific' match for a URI. A match is called "most specific" when
the two URI are strongly equivalent [4], which means that they have
Rosenberg Expires April 16, 2007 [Page 12]
Internet-Draft Outbound Discovery and HA October 2006
the same set of URI parameters with the same values. A match is
called "partly specific" when the two URI are equal based on RFC 3261
rules for equality. This requires the user part and domains to
match, but allows one URI to contain URI parameters while the other
does not. Finally, a match is called "least specific" when the only
thing that matches is the domain part of the URI. When a client
wants to send a request to a target URI, it MUST choose a flow which
is a most specific match. If there are no most specific matches, it
MUST choose one that is partly specific. If none are partly
specific, it MUST perform an RFC 3263 [2] resolution of the hostname.
If the resulting IP address and port match that of an existing
connection which is a least specific match for the URI, that
connection MUST be used. Otherwise, the agent MUST initiate a new
connection. The usage of RFC 3263 here allows for load balancing to
still occur. If, in any of the previous steps, more than one flow is
a match, the UA chooses one randomly.
4.2. Associating URI with Flows
Once a request is sent on a flow, it is possible that the request
will result in further URI being associated with the flow. Whether
this happens depends on the method and the response code.
If the request was a REGISTER request that generated a successful
response (2xx), the client searches for the Service-Route header
field in the response. If the client is a UA, it takes the topmost
value in the Service-Route header field. If the client is a proxy,
the proxy takes the URI it inserted into the Path header field of the
request, assuming it had inserted one. It searches the values in the
Service-Route header field for that URI. When it finds it, it
selects the next URI in the Service-Route header field. The client
MUST associate that URI with the flow on which the request was sent.
The client MAY unassociate the URI with the flow at the time of
registration expiry. Note that this requires clients compliant to
this mechanism to track registration lifetimes in order to expire
these associations.
If the request was a dialog-forming request, such as INVITE or
SUBSCRIBE, which generated a successful response, the client searches
for the Record-Route header field in the response. If the client is
a UA, it takes the topmost value in the Record-Route header field.
If the client is a proxy, the proxy takes the URI it inserted into
the Record-Route header field of the request, assuming it had
inserted one. It searches the values in the Record-Route header
field for that URI. When it finds it, it selects the next URI in the
Record-Route header field. The client MUST associate that URI with
the flow on which the request was sent. The client MAY unassociate
the URI with the flow at the time of termination of the dialog. Note
Rosenberg Expires April 16, 2007 [Page 13]
Internet-Draft Outbound Discovery and HA October 2006
that this requires clients compliant to this mechanism to track
dialog states in order to expire these associations.
If the result of a request is 305, the client MUST follow the
procedures in [6], which will cause the client to recurse and send
the request to the Contacts. If, prior to the redirection, the
target URI was associated with the flow on which the request was
sent, the client SHOULD unassociate the URI with the flow upon
receipt of a 305. This provides a way for a server to unstick itself
from a particular URI, and is useful for redirecting traffic after
recovery from a failure. If, after recursion, the result of the
request is a success, the rules described above are used to associate
URI with the flow on which the recursed request was sent.
If the response to a request is a 5xx, the client SHOULD retry the
request by re-running the selection algorithm described here, but
acting as if the flow that was just described (and its associated
URI) do not exist. This will have the effect of causing failover
across flows. A successful response to a retried request, based on
the results above, may cause the association of URI with other flows.
Note that a 5xx response will not unstick the URI to the flow on
which the first request was sent.
5. Server Behavior
When a server, which is either a UAS or proxy server, receives a
request, it performs the processing in this section.
If the server is on the receiving side of a TLS connection open, and
the client offered a TLS certificate, the server MUST create a SIP
URI of the form sip:domain, where the domain is identical to the
domain in the subjectAltName of the client-provided certificate.
This URI MUST be associated with the connection that was just
established. This processing is specified to TLS. [[OPEN ISSUE: In
principle, this mechanism could be applied to UDP or other transports
as long as there was some way to securely bind the sender with an
identity. However the only defined way in SIP is TLS]].
If the server receives a REGISTER request, the server examines the
topmost Path header field value in the request. If the Path header
field is present, and the domain in the topmost URI matches the
domain of the URIs associated with the flow, the URI is added to the
list of URI associated with the flow if the server generates a
successful response. If, when the request was received, no URI were
assocaited with the flow, the topmost Path URI MUST NOT be associated
with the flow.
Rosenberg Expires April 16, 2007 [Page 14]
Internet-Draft Outbound Discovery and HA October 2006
If the server receives a dialog-forming request, the server examines
the topmost Record-Route header field value in the request. If there
is a Record-Route header field present, and the domain in the topmost
URI matches the domain of the URIs associated with the flow, the URI
is added to the list of URI associated with the flow if the server
generates a successful response. If, when the request was received,
no URI were associated with the flow, the topmost Record-Route URI
MUST NOT be associated with the flow.
6. Connection Management
The procedures in this section apply to all clients and servers.
Once a connection has been established and becomes associated with
URI, the connection SHOULD be retained as long as any URI remain
associated with the connection. Even if there are no URI associated
with a connection, it is RECOMMENDED that connections be retained in
order to avoid the delays associating with re-establishing them at a
later time. Should a connection close as a result of error, or be
closed by a peer, the agent SHOULD retain the list of associated URI
and also the IP address, port and protocol that the connection had
been established to. If a request is to be sent which matches one of
those URI, the agent SHOULD attempt to re-open the connection to the
IP address and port and protocol [[OPEN ISSUE: if the IP address is
owned by another host now, this won't work. May need to add some
text on checking resulting TLS certs against the domain names]]. If,
after 10 seconds, the connection could not be re-established, the
agent SHOULD discard the list of associated URI. Caching the list of
associated URI helps proxies and user agents be robust against
temporary disconnections due to transient conditions. It takes time
to rebuild the set of associated URI, and this state should not be
lightly discarded.
7. User Agent Behavior
A UA compliant to this specification MUST include a Supported header
field in its REGISTER requests with the "alt-proxies" option tag.
A UA MUST, upon receipt of a REGISTER response containing an
Alternative-Proxies header field, process that header field. For
each URI in the header field value, it MUST add that URI as a new
additional outbound proxy. Furthermore, when generating a REGISTER
request for that outbound proxy, it MUST create a new flow towards
the URI, regardless of whether an existing flow matches the URI.
Often these URI will use the maddr parameter in order to cause the UA
to use a specific host as an outbound proxy. Note that, in the case
Rosenberg Expires April 16, 2007 [Page 15]
Internet-Draft Outbound Discovery and HA October 2006
of TLS, the server certificate is matched against the domain of the
URI, rather than any value in the maddr parameter. [[OPEN ISSUE:
still mildly uncomfortable on this; need to consider whether there is
a real issue here or not. I can't think of a problem per se.]].
8. Outbound Proxy Behavior
Beyond the general rules for clients and servers defined in Section 4
and Section 5, an outbound proxy follows the rules defined here.
8.1. Receipt of Initial REGISTER
An outbound proxy identifies an initial REGISTER by the topmost Route
header field in the REGISTER request. If this URI has no user part,
and the hostname matches the hostname for the server cluster for that
proxy, the request is an initial REGISTER request.
An proxy MUST add a Path header field to the request. The host
portion of the URI MUST match the hostname for the server cluster for
that proxy, which will in turn be equal to the hostname in the Route
header field of the received REGISTER request. The user part is
encoded as a matter of local policy. However, it MUST have the
following properties. It MUST encode the identity of the other
proxies that have been selected as the outbound proxy set for this
user. It MUST encode the instance ID and reg ID of the request in
such a way that any other proxy in the cluster can understand it
(this is assuming the usage of SIP outbound, where there will always
be just one contact). Furthermore, it MUST contain the authenticated
identity of the sender of the request [[TODO: need to describe
procedures when this is not present]]. This identity, in the case of
SIP digest, is obtained from the username field of the Authorization
or Proxy-Authorization header field. Note that the outbound proxy
doesn't actually have to perform the authentication. If it does not,
but rather it is done by a downstream proxy trusted by the outbound
proxy, that username is used. If an outbound proxy does not
authenticate, and has no trust relationship with the downstream proxy
performing the authentication, the mechanism in this specification
cannot be applied.
OPEN ISSUE: this seems moderately brittle. In theory at least its
hard for an outbound proxy to know what downstream element
performed the authentication exchange. However in nearly all real
deployments, including ones where the proxies are in different
domains, there is knowledge as a consequence of the deployment
topology. Is this acceptable?
When the 200 OK to the REGISTER is received, the outbound proxy
Rosenberg Expires April 16, 2007 [Page 16]
Internet-Draft Outbound Discovery and HA October 2006
selects which other proxies it desires the client to initiate an
outbound connection to. This MUST be the same set that was used
during the encoding of the Path header field. For each additional
outbound proxy that is to be used, the proxy MUST add a value to the
Alternative-Proxies header field. This value MUST be identical to
the URI inserted into the Path header field, with the exception of
the removal of the keepalive=stun parameter and the addition of the
maddr parameter, which identifies the specific proxy or farm of
proxies from which the additional outbound proxy is to be selected.
The proxy MUST associate the username, instance ID and reg-ID with
the flow that the request arrived on. It MUST maintain this
association for the duration of the registration. It MUST retain the
chosen Path URI for the duration of the registration and associate it
with the username/realm and instance ID.
TODO: add text on handling case of a second flow on the same proxy.
8.2. Receipt of REGISTER Refresh
A proxy can distinguish an initial REGISTER from a request by the
topmost URI. If the topmost URI matches a Path URI it, or another
proxy in the cluster, had previously associated with a registration,
it is a refresh. The outbound proxy MUST insert the same URI into
the Path header field of the REGISTER request. It MUST NOT insert
the Alternative-Proxies header field into the response.
8.3. Record-Routing Dialog Forming Requests
A proxy can detect a request as out of dialog based on the topmost
Route URI. If it equals the Path URI of an existing registration,
and the request method is not REGISTER, and the To tag is absent, it
is a non-dialog request.
If the request is a dialog forming request, an outbound proxy MUST
record-route. The URI used for record-routing MUST be "partly equal"
to the Path URI (which will be present in the topmost URI). The
proxy MAY add additional URI parameters which would cause the record-
routed URI to not be strongly equal to the Path URI.
8.4. Additional Flow Selection Rule
Outbound proxies follow the general client and server processing
rules defined in Section 4 and Section 5, with one very important
addition. If, when trying to send a request towards a UA, the
procedures in Section 4 instruct the outbound proxy to open a new
flow, the outbound proxy performs one additional check to see if it
can reuse an existing flow. If the Route header field in the request
Rosenberg Expires April 16, 2007 [Page 17]
Internet-Draft Outbound Discovery and HA October 2006
that was received had a structure indicates that it contains a
username, instance ID and reg-ID, and it was not received over a flow
from a client (in other words, it came from the home proxy or another
proxy before it) the outbound proxy checks to see if it has any flows
associated with that username and instance ID, with any reg-ID. If
it finds a match, the request is sent on that flow.
If there is no match, the proxy decodes the user part of the Route
URI in the request it received. This user part encodes the
identities of the outbound proxies assigned to this user. The proxy
MUST generate a 305 redirect, and include a single Contact header
field value for each outbound proxy. Each value MUST be equal to the
Path URI (based on RFC 3261 equivalence rules), but MUST contain an
maddr parameter that points the request to the specific outbound
proxy that was selected.
8.5. Mid-Dialog Request Handling
There are no additional behaviors required for mid-dialog request
processing, beyond those specified in Section 4 and Section 5 and the
additional flow selection rule defined above. These rules, when
combined together, produce the desired high availability effect.
9. Home Proxy Behavior
Home proxies follow the procedures defined for all clients and
servers as described above.
Additionally, if a home proxy receives a REGISTER request, and this
request didn't arrive from a proxy that is a valid edge proxy, the
home proxy MUST redirect the request, and include a SIP URI in the
Contact header field which identifies the outbound proxy farm for its
own domain. This redirect MUST follow the procedures of [6].
10. Impacts to SIP Outbound
At this time, SIP outbound is still under specification. Though it
is not an objective of SIP outbound to specify the mid-dialog HA
mechanisms described here, it is preferable that SIP outbound be
specified in such a way that a UA compliant only to SIP-outbound
would still get high availability, once the network is upgraded with
the mecahnisms defiend here.
The following changes are suggested to SIP outbound to accomplish
this:
Rosenberg Expires April 16, 2007 [Page 18]
Internet-Draft Outbound Discovery and HA October 2006
Firstly, the client algorithm described above needs to be moved into
sip-outbound and trimmed to apply only to UA. This provides the
essential HA mechanism for the client.
The additional behavior defined here for user agents is the discovery
mechanism afforded by the Alternative-Proxies header field and the
modified Service-Route semantics in [6]. Without these mechanisms,
the client can either be configured with its outbound proxies or it
can learn local ones via DHCP. If configured ones are used, as long
as they are configured as URI and present in the topmost Route header
of all requests that are not part of a dialog (in which case the
record-route set is used), HA will work from the client. In the case
of proxies learned by DHCP, only a hostname is provided, and just a
single one. The recommendation here is that sip-outbound recommend
several DNS queries to obtain two IP addresses, and then to use sip:
<hostname>;maddr=<IP-addr> as the URI for each outbound proxy. This
will also allow for HA to work without further client change.
However, lack of Service-Route support will require the outbound
proxies to perform state replication to compensate.
Subsequent support of the remainder of this specification (including
the modified Service-Route mechanism) would eliminate the need for
state replication in the outbound proxies, provide more dynamic HA
mechanisms (such that each agent can have a different proxy assigned
to it), and allow for different numbers of outbound proxies on a UA-
by-UA basis.
11. Backwards Compatibility Considerations
This specification defines two fairly separable mechanisms, and each
has its own backwards compatibility consideration. The first is the
Alternative-Proxies header field, and the second is the 'stickiness'
behavior defined for clients and servers.
Backwards compatibility for the Alternative-Proxies header field is
readily accomplished with an option tag. A UA includes the "alt-
proxies" option tag in the Supported header field of its
registrations, indicating support for this header. An outbound proxy
inserting an Alternative-Proxies header field into a REGISTER
response would add a Require header field with that option tag,
informing the UA that the mechanism must be used.
The connection stickiness is more problematic. A proxy will want to
know whether its neighbors support the mechanism prior to
construction of a URI for a Record-Route or Path header field. For
peers which support the mechanism, the URIs would have the structure
described here, which has the important property that the host part
Rosenberg Expires April 16, 2007 [Page 19]
Internet-Draft Outbound Discovery and HA October 2006
identifies the entire cluster and not a specific proxy. However,
this will not work as well with peers which don't support the
stickiness, since requests targeted to that URI would go anywhere in
the cluster (based on RFC 3263 processing alone). There are several
ways to handle this.
Firstly, a proxy MAY prod a specific peer with an OPTIONS request to
determine support for this mechanism. A proxy compliant to the
client and server stickines rules described above will indicate such
with a "sticky" option tag in the Supported header field of an
OPTIONS response.
Alternatively, a proxy can simply assume all peers support the
mechanism. If they do not, the worse case is that requests get
routed to the wrong proxy in the cluster. As long as all proxies in
a cluster support the mechanism here, the mis-targeted proxy can
either redirect the request to the right proxy (assuming the upstream
element supports the new 305 semantics; backwards compatibility for
THAT mechanism is discussed in [6]). If the upstream element doesn't
support the new 305 semantics, the mistargeted element can literally
proxy the request to the correct place. Consequently, lack of
backwards compatibility still allows the system to function - it just
adds additional costs of an extra proxy hop to get requests to the
correct place. Finally, in some deployments it is simply known what
the topology is, and support for this specification can be a
configured property of an element that a proxy communicates with.
12. Interactions with Connection Reuse
The mechanism defined in this specification has an important and
unintended side effect. When two proxies are communicating with
mutual TLS, it results in connection reuse of that TLS connection.
This connection reuse mechanism works regardless of the presence of
NAT between a pair of proxies. It also results in load balancing,
though with less control than is normally afforded by the priority
and preference fields in DNS.
Consequently, it is an open question as to whether this specification
would serve as an alternative mechanism to the one defined in [8].
It is worth pointing out that the connection reuse described here is,
to a large degree, a proxy-to-proxy generalization of the SIP
outbound specification.
13. Security Considerations
This specification provides an alternative way for proxies to
Rosenberg Expires April 16, 2007 [Page 20]
Internet-Draft Outbound Discovery and HA October 2006
construct the URI that they use in Path and Record-Route header
fields, compared to the algorithms in [3]. One of the central
security issues there is construction of the flow token (the user
part of the Path header field) such that another UA cannot steal
calls targeted to another UA. The algorithm described here deals
with this problem by encoding the authenticated identity of the
client into the flow token. Consequently, as long as a client
authenticates itself, it cannot cause the proxy to generate a flow
token that would be identical to the one constructed for a different
UA. This avoids the attack, but comes at the cost of requiring the
proxy to perform and/or track the authentication procedures in a
downstream proxy.
Another potential attack is to generate requests with Record-Route or
Path header fields which are intended to 'stick' subsequent requests
to connections that they would never normally go to based on RFC 3263
procedures. For example, a malicious proxy in bad.example.com might
try to fool a proxy into thinking requests for good.example.com
should go to it. It would do this by including a Record-Route in an
INVITE which contains good.example.com. This attack is mitigated by
MUST strength processing for servers, which says that they cannot
'stick' a URI to a connection unless there was already a URI stuck to
the connection with the same domain. The first URI gets stuck to a
connection either because an element learned the target of the
connection through DNS (which was then verified through TLS), or
because the incoming connection was received from an element that
presented a domain certificate that created a URI that got stuck to
the connection. In either case, this implies that the domain of all
URI that get stuck to a connection are always equal to the identity
presented in a certificate from the entity on the other side of that
connection. This provides a robust mechanism that avoids the attack
in question, even in cases where the DNS has been subverted.
Indeed, the 'stickiness' algorithm described here addresses some of
the questions and issues raised in the domain certificates
specification [9]. In particular, because proxies always "path" and
"record-route" with URI whose domain parts match their TLS
certificates, there are no complicates with record-routing. No
additional certificates need to be obtained for individual elements.
All that is required is the same thing that is required for web
servers - a common certificate for all proxies in a cluster.
14. IANA Considerations
TODO.
Rosenberg Expires April 16, 2007 [Page 21]
Internet-Draft Outbound Discovery and HA October 2006
15. Example
This section builds on the basic example used in the introduction,
and fills in the blanks on how each URI is constructed and how each
request is routed to the next hop.
Consider once again the deployment topology of Figure 2. Let us
assume that UA X does not learn a SIP server via DHCP, and thus
starts with nothing but its AOR and credentials. Let us further
assume that the domain would like the UA to use two flows. Finally,
the example assumes TLS on all links. The mechanism works in absence
of TLS as well, but works better with (fewer messages). The flow
considers only a single home proxy, home proxy 1.
X OB Proxy 2 OB Proxy 3 Home Proxy 1 Correspondent
|(1) TLS Connect | | |
|------------------------------------------->| |
|(2) REGISTER | | | |
|------------------------------------------->| |
|(3) 305 | | | |
|<-------------------------------------------| |
|(4) TLS Connect | | |
|------------->| | | |
|(5) REGISTER | | | |
|------------->| | | |
| |(6) TLS Connect | |
| |---------------------------->| |
| |(7) REGISTER | | |
| |---------------------------->| |
| |(8) 401 | | |
| |<----------------------------| |
|(9) 401 | | | |
|<-------------| | | |
|(10) REGISTER | | | |
|------------->| | | |
| |(11) REGISTER | | |
| |---------------------------->| |
| |(12) 200 OK | | |
| |<----------------------------| |
|(13) 200 OK | | | |
|<-------------| | | |
|(14) TLS Connect | | |
|---------------------------->| | |
|(15) REGISTER | | | |
|---------------------------->| | |
| | |(16) TLS Connect |
| | |------------->| |
Rosenberg Expires April 16, 2007 [Page 22]
Internet-Draft Outbound Discovery and HA October 2006
| | |(17) REGISTER | |
| | |------------->| |
| | |(18) 401 | |
| | |<-------------| |
|(19) 401 | | | |
|<----------------------------| | |
|(20) REGISTER | | | |
|---------------------------->| | |
| | |(21) REGISTER | |
| | |------------->| |
| | |(22) 200 OK | |
| | |<-------------| |
|(23) 200 OK | | | |
|<----------------------------| | |
|(24) INVITE | | | |
|------------->| | | |
| |(25) INVITE | | |
| |---------------------------->| |
| | | |(26) TLS Connect
| | | |------------->|
| | | |(27) INVITE |
| | | |------------->|
| | | |(28) 200 OK |
| | | |<-------------|
| |(29) 200 OK | | |
| |<----------------------------| |
|(30) 200 OK | | | |
|<-------------| | | |
|(31) ACK | | | |
|------------->| | | |
| |(32) ACK | | |
| |---------------------------->| |
| | | |(33) ACK |
| | | |------------->|
| |failure | | |
| | | |(34) BYE |
| | | |<-------------|
| |(35) BYE | | |
| |<----------------------------| |
| | | |timeout |
| | |(36) BYE | |
| | |<-------------| |
|(37) BYE | | | |
|<----------------------------| | |
|(38) 200 OK | | | |
|---------------------------->| | |
| | |(39) 200 OK | |
| | |------------->| |
Rosenberg Expires April 16, 2007 [Page 23]
Internet-Draft Outbound Discovery and HA October 2006
| | | |(40) 200 OK |
| | | |------------->|
Figure 5
The basic call flow is shown in Figure 5.
UA X starts with only its AOR. It generates a REGISTER request with
no Route header fields and a Request-URI of sip:example.com. This
causes the client to perform a DNS query (not shown) and find the
address of one of the home proxies (only one is shown). It opens a
TLS connection towards that proxy (message 1), and then sends the
REGISTER (message 2). The home proxy, seeing that the request came
from neither outbound proxy, redirects it with a 305 (message 3). It
includes a Contact header field in the redirect whose value is sip:
outbound.example.com.
The client still has no outbound proxies configured per se. It looks
up outbound.example.com in the DNS and finds three A records, one for
each of the three outbound proxies. It selects the one for proxy 2,
and then proceeds to open a TLS connection towards it (message 4).
It then generates a REGISTER request whose Request-URI is sip:
example.com but that contains a Route header field of sip:
outbound.example.com (message 5). The server certificate provided by
the proxy will cause the SIP URI sip:outbound.example.com to be
associated with this TLS connection. The REGISTER arrives at proxy
2. Proxy 2 recognizes it as an initial REGISTER due to its lack of a
user part in the Route header field. Consequently, it notes the
instance ID and reg-ID but finds no username since the request
doesn't (yet) contain an Authorization header field. It selects a
backup proxy (proxy 3). It constructs a Path URI and adds it to the
REGISTER request. The Path URI has a user part that encodes the
identity of proxy 3, and the instance ID and reg ID. It then opens a
TLS connection to the home proxy (discovered by a DNS lookup of the
Request-URI sip:example.com) (message 6), and sends the request there
(message 7). Proxy 2 now associates the SIP URI sip:example.com to
the connection to the example.com proxy, as a consequence of the
certificate provided by the home proxy. In addition, proxy 2
utilizes mutual TLS authentication. When the home proxy receives the
TLS connect in message 6, the home proxy notes the subjectAltName of
the client certificate, which will be outbound.example.com, and
associates the SIP URI sip:outbound.example.com with the TLS
connection just created by proxy 2.
The home proxy will reject the request with a 401 in order to
challenge for credentials (message 8). This is forwarded to the UA
(message 9). Since the request was rejected, no URI get stuck to any
Rosenberg Expires April 16, 2007 [Page 24]
Internet-Draft Outbound Discovery and HA October 2006
flows by any element. The UA applies its credentials. It generates
a new REGISTER message, whose Route header field is sip:example.com.
This bounces off of the home proxy and is redirected once more (not
shown). It recurses on the 305 and now generates a REGISTER (still
with credentials) towards sip:outbound.example.com. The UA notes
that it has a TLS connection with an associated URI with the same
value, so that existing TLS connection to proxy 2 is reused. The
REGISTER message is sent there (message 10).
Now, proxy 2 sees an initial REGISTER request once more. This time,
the request contains a username (x) in the Authorization header
field, along with an instance ID (urn:instanceID) in the Contact
header field and a reg-id (1) as well. It constructs a Path URI of
the form
sip:proxy2+proxy3+x+instanceID+1@outbound.example.com;keepalive=stun
and inserts it into the request. This URI encodes the address of the
two proxies being used for this user (proxies 2 and 3), along with
the instance ID and reg-ID. It associates the instance ID, username
and reg-ID with the TLS connection. Since it is forwarding the
request to example.com, it finds a matching TLS connection and sends
the request there (message 11). The home proxy processes the
registration as per sip-outbound. It then copies the Path URI into a
Service-Route header field and places that into the REGISTER response
(message 12). It adds itself to the Service-Route by adding the URI
sip:example.com as the second Service-Route.
Since the REGISTER is successful, the home proxy examines the topmost
Path from the REGISTER request. Since its domain,
outbound.example.com, matches the domain of the URI already
associated with the TLS connection, the home proxy adds that URI to
the list of URI bound to that connection. Consequently, its
connection table looks like:
TLS connection to proxy 2:
sip:outbound.example.com
sip:proxy2+proxy3+x+instanceID+1@outbound.example.com;keepalive=stun
The 200 OK is received at proxy 2. Following the procedures in
Section 4, it finds its own Path URI in the Service-Route, and looks
at the next URI, which is sip:example.com. This URI is already
associated with the TLS connection to the home proxy, so nothing more
is done. Proxy 2 adds an Alternative-Proxies header field to the
REGISTER response, with a value of sip:proxy2+proxy3+x+instanceID+1@
outbound.example.com;maddr=192.0.2.1. Proxy A then forwards the 200
OK to the UA (message 13).
UA X now does several things. Firstly, since the response contains a
Rosenberg Expires April 16, 2007 [Page 25]
Internet-Draft Outbound Discovery and HA October 2006
Service-Route, it updates its outbound proxy to the URI in the
Service-Route (sip:proxy2+proxy3+x+instanceID+1@
outbound.example.com;keepalive=stun). This is now the first outbound
proxy. Note how it has a keepalive=stun parameter inserted by the
proxy, which validates that it supports the keepalive mechanism.
Next, the UA associates the connection towards A with this URI, so
that its connection table looks like:
TLS connection to 2:
sip:outbound.example.com
sip:proxy2+proxy3+x+instanceID+1@outbound.example.com;keepalive=stun
Finally, it extracts the URI from the Alternative-Proxies header
field, which points to proxy 3. It runs through an identical
registration procedure with proxy 3. This procedure will leave the
UA with two outbound proxies, both of which have exactly the same
URI. Its connection table will look like:
TLS connection to 2:
sip:outbound.example.com
sip:proxy2+proxy3+x+instanceID+1@outbound.example.com;keepalive=stun
TCP connection to 3:
sip:proxy2+proxy3+x+instanceID+1@outbound.example.com;maddr=192.0.2.1
sip:proxy2+proxy3+x+instanceID+1@outbound.example.com;keepalive=stun
The connection table at the home proxy will look like:
TLS connection to 2:
sip:outbound.example.com
sip:proxy2+proxy3+x+instanceID+1@outbound.example.com;keepalive=stun
TLS connection to 3:
sip:outbound.example.com
sip:proxy2+proxy3+x+instanceID+1@outbound.example.com;keepalive=stun
Next, the UA decides to make a call. It generates a SIP INVITE
(message 24). This INVITE contains the full service route in the
Route haeder field. The topmost Route is
sip:proxy2+proxy3+x+instanceID+1@outbound.example.com;keepalive=stun.
The Request-URI identifies the called party. The client matches that
URI against the URI associated with TLS connections and finds a match
for both the TLS connection to 2 and 3. Thus, either connection can
be used. The client arbitrarily chooses the connection to proxy 2,
Rosenberg Expires April 16, 2007 [Page 26]
Internet-Draft Outbound Discovery and HA October 2006
and sends the request.
This request is received at proxy 2, which record-routes. It does so
by using a URI of the form
sip:proxy2+proxy3+x+instanceID+1@outbound.example.com;
keepalive=stun;aor-qual=abc. The aor-qual URI parameter contains
some state that is specific to the SIP dialog. Proxy 2 strips its
URI from the topmost Route, finding sip:example.com as the next
Route. It has a TLS connection to the home proxy, and so sends the
request there (message 25). The home proxy itself record-routes
(with any URI it chooses) and forwards the request to the terminating
domain (message 27) after opening a TLS connection there (message
26). A 200 OK is received (message 28), which is forwarded to proxy
2 (message 29). This next step is important. Following the
procedures of Section 5, the home proxy adds the topmost Record-Route
value that was present in the request to the URI list associated with
the TLS connection to proxy 2. Consequently, its connection table
now looks like (lines folded for readability):
TLS connection to 2:
sip:outbound.example.com
sip:proxy2+proxy3+x+instanceID+1@outbound.example.com
;keepalive=stun
sip:proxy2+proxy3+x+instanceID+1@outbound.example.com
;keepalive=stun;aor-qual=abc
TLS connection to 3:
sip:outbound.example.com
sip:proxy2+proxy3+x+instanceID+1@outbound.example.com;keepalive=stun
The 200 OK is received by proxy 2. It adds the home proxy's record-
route URI to the list of URI associated with its TLS connection to
the home proxy (assuming the URI hostname is example.com). The
response is then forwarded to the UA (message 30). The ACKs are then
sent (messages 31 to 33).
Now something interesting happens. Proxy 2 fails. Its TLS
connection to the home proxy and the UA are severed. Let us assume
that neither the UA or the home proxy have yet detected this. The
called party sends a BYE at this very moment to terminate the call
(message 34), which arrives at the home proxy. The next Route header
field will have the value
sip:proxy2+proxy3+x+instanceID+1@outbound.example.com;keepalive=stun
;aor-qual=abc. The most specific match is for the connection to
proxy 2. The request is sent there (message 35). This will quickly
timeout due to TCP connection failures. This causes the home proxy
to try the next best TLS connection, to proxy 3. It sends the
Rosenberg Expires April 16, 2007 [Page 27]
Internet-Draft Outbound Discovery and HA October 2006
request thre (message 36).
This BYE request arrives at proxy 3. There are no further Route
headers. Thus, proxy 3 attempts to route the request using the
requst URI, which will be the private IP address of the UA and thus
match no existing TLS connection. Before attempting this anyway, the
proxy examines the Route header field in the request it received. It
recognizes the structure, and extracts the username and instance ID.
These do in fact match an existing TLS connection to UA X, and so the
request is sent over that connection and delivered to the UA (message
37).
16. Acknowledgements
Thanks to Cullen Jennings for reviewing and commenting on earlier
versions of this document. His ideas led to substantial improvements
in the mechanism. Paul Kyzivat provided helpful feedback.
17. References
17.1. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[3] Jennings, C. and R. Mahy, "Managing Client Initiated Connections
in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-04 (work in progress), June 2006.
[4] Rosenberg, J., "Obtaining and Using Globally Routable User Agent
(UA) URIs (GRUU) in the Session Initiation Protocol (SIP)",
draft-ietf-sip-gruu-10 (work in progress), August 2006.
[5] Rosenberg, J., "Simple Traversal Underneath Network Address
Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-04 (work
in progress), July 2006.
[6] Rosenberg, J., "Construction of the Route Header Field in the
Session Initiation Protocol (SIP)",
draft-rosenberg-sip-route-construct-01 (work in progress),
March 2006.
Rosenberg Expires April 16, 2007 [Page 28]
Internet-Draft Outbound Discovery and HA October 2006
17.2. Informative References
[7] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP-for-
IPv4) Option for Session Initiation Protocol (SIP) Servers",
RFC 3361, August 2002.
[8] Mahy, R., "Connection Reuse in the Session Initiation Protocol
(SIP)", draft-ietf-sip-connect-reuse-06 (work in progress),
August 2006.
[9] Gurbani, V., "Domain Certificates in the Session Initiation
Protocol (SIP)", draft-gurbani-sip-domain-certs-03 (work in
progress), August 2006.
Rosenberg Expires April 16, 2007 [Page 29]
Internet-Draft Outbound Discovery and HA October 2006
Author's Address
Jonathan Rosenberg
Cisco Systems
600 Lanidex Plaza
Parsippany, NJ 07054
US
Phone: +1 973 952-5000
Email: jdrosen@cisco.com
URI: http://www.jdrosen.net
Rosenberg Expires April 16, 2007 [Page 30]
Internet-Draft Outbound Discovery and HA October 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Rosenberg Expires April 16, 2007 [Page 31]