SIP WG C. Jennings, Ed.
Internet-Draft Cisco Systems
Expires: January 12, 2006 R. Mahy, Ed.
SIP Edge LLC
July 11, 2005
Managing Client Initiated Connections in the Session Initiation Protocol
(SIP)
draft-ietf-sip-outbound-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 January 12, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Session Initiation Protocol (SIP) allows proxy servers to initiate
TCP connections and send asynchronous UDP datagrams to User Agents in
order to deliver requests. However, many practical considerations,
such as the existence of firewalls and NATs, prevent servers from
connecting to User Agents in this way. Even when a proxy server can
open a TCP connection to a User Agent, most User Agents lack a
Jennings & Mahy Expires January 12, 2006 [Page 1]
Internet-Draft Client Initiated Connections in SIP July 2005
certificate suitable to act as a TLS server. This specification
defines behaviors for user agents, registrars and proxy servers that
allow requests to be delivered on existing connections established by
the User Agent. It also defines keep alive behaviors needed to keep
NAT bindings open and specifies the usage of multiple connections for
high availability systems.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Summary of Mechanism . . . . . . . . . . . . . . . . . . . 4
3.2 Single Registrar and UA . . . . . . . . . . . . . . . . . 5
3.3 Multiple Connections from a User Agent . . . . . . . . . . 6
3.4 Edge Proxies . . . . . . . . . . . . . . . . . . . . . . . 7
3.5 Keep Alive Techniques . . . . . . . . . . . . . . . . . . 8
4. User Agent Mechanisms . . . . . . . . . . . . . . . . . . . . 9
4.1 Forming Flows . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1 Instance-ID Selection . . . . . . . . . . . . . . . . 10
4.2 Detecting Flow Failure . . . . . . . . . . . . . . . . . . 10
4.3 Flow Failure Recovery . . . . . . . . . . . . . . . . . . 11
4.4 Registration by other other instances . . . . . . . . . . 11
5. Registrar Mechanisms . . . . . . . . . . . . . . . . . . . . . 12
5.1 Processing Register Requests . . . . . . . . . . . . . . . 12
5.2 Forwarding Requests . . . . . . . . . . . . . . . . . . . 12
6. Edge Proxy Mechanisms . . . . . . . . . . . . . . . . . . . . 13
6.1 Processing Register Requests . . . . . . . . . . . . . . . 13
6.2 Forwarding Requests . . . . . . . . . . . . . . . . . . . 14
7. Mechanisms for All Servers . . . . . . . . . . . . . . . . . . 14
8. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 15
9. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18
11. Security Considerations . . . . . . . . . . . . . . . . . . 19
12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 20
13. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 20
14. Changes from 01 Version . . . . . . . . . . . . . . . . . . 20
15. Changes from 00 Version . . . . . . . . . . . . . . . . . . 20
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
17.1 Normative References . . . . . . . . . . . . . . . . . . . 21
17.2 Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 24
Jennings & Mahy Expires January 12, 2006 [Page 2]
Internet-Draft Client Initiated Connections in SIP July 2005
1. Introduction
There are many environments for SIP deployments in which the User
Agent (UA) can form a connection to a Registrar or Proxy but in which
the connections in the reverse direction to the UA are not possible.
This can happen for several reasons. Connection to the UA can be
blocked by a firewall device between the UA and the proxy or
registrar, which will only allow new connections in the direction of
the UA to the Proxy. Similarly there may be a NAT, which are only
capable of allowing new connections from the private address side to
the public side. It is worth noting that most UAs in the world are
deployed behind firewalls or NATs.
Most IP phones and personal computers get their network
configurations dynamically via a protocol such as DHCP. These
systems typically do not have a useful name in DNS, and they
definitely do not have a long-term, stable DNS name that is
appropriate for binding to a certificate. It is impractical for them
to have a certificate that can be used as a client-side TLS
certificate for SIP. However, these systems can still form TLS
connections to a proxy or registrar such that the UA authenticates
the server certificate, and the server authenticates the UA using a
shared secret in a digest challenge.
The key idea of this specification is that when a UA sends a REGISTER
request, the proxy can later use this same connection to forward any
requests that need to go to this UA. For a UA to receive incoming
requests, the UA has to connect to the server. Since the server
can't connect to the UA, the UA has to make sure that a connection is
always active. This requires the UA to detect when a connection
fails. Since, such detection takes time and leaves a window of
opportunity for missed incoming requests, this mechanism allows the
UA to use multiple connections, referred to as "flows", to the proxy
or registrar and using a keep alive mechanism on each flow so that
the UA can detect when a flow has failed.
2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2].
2.1 Definitions
Jennings & Mahy Expires January 12, 2006 [Page 3]
Internet-Draft Client Initiated Connections in SIP July 2005
Edge Proxy: An Edge Proxy is any proxy that is located topologically
between the registering user agent and the registrar.
flow: A Flow is a network protocol layer connection between two hosts
that is represented by the network address of both ends and the
protocol. For TCP and UDP this would include the IP addresses and
ports of both ends and the protocol (TCP or UDP). With TCP, a
flow would often have to one to one correspondence with a single
file descriptor in the operating system.
flow-id: This refers to the value of a new header parameter value for
the contact header. When UA register multiple times, each
registration gets a unique flow-id value.
instance-id: This specification uses the word instance-id to refer to
the value of the "sip.instance" media feature tag in the Contact
header field. This is a URN that uniquely identifies the UA.
3. Overview
Several scenarios in which this technique is useful are discussed
below, including the simple collocated registrar and proxy, a user
agent desiring multiple connections to a resource (for redundancy for
example), and an system that uses Edge Proxies.
3.1 Summary of Mechanism
The overall approach is fairly simple. Each UA has a unique
instance-id that stays the same for this UA even if the UA reboots or
is power cycled. Each UA can register multiple times. Each
registration includes the instance-id for the UA and a flow-id label
that is different for each connection.
UAs use a keep alive mechanism to keep their flow to the proxy or
registrar alive. For TCP, TLS, and other connection oriented
protocols this is a burst containing a single CRLF. For UDP it is a
STUN request sent over the flow. A UA can create more than one flow
using multiple registrations for the same AOR. The instance-id
parameter is used by the proxy to identify with which UA a flow is
associated. The flow-id is used by the proxy and registrar to tell
the difference between a UA re-registering and one that is
registering over an additional flow. The proxies keep track of the
flows used for successful registrations.
When a proxy goes to route a message to a UA for which it has a
binding, it can use any one of the flows on which a successful
registration has been completed. A failure on a particular flow can
be tried again on an alternate flow. Proxies can determine which
flows go to the same UA by looking at the instance-id. Proxies can
tell that a flow replaces a previous abandoned flow by looking at the
flow-id.
Jennings & Mahy Expires January 12, 2006 [Page 4]
Internet-Draft Client Initiated Connections in SIP July 2005
3.2 Single Registrar and UA
In this example there is single server acting as both a registrar and
proxy.
+-----------+
| Registrar |
| Proxy |
+-----+-----+
|
|
+----+--+
| User |
| Agent |
+-------+
User Agents forming only a single connection continue to register
normally but include the instance-id as described in the GRUU [1]
specification and can also add a flow-id parameter to the Contact
header field value. The flow-id parameter is used to allow the
registrar to detect and avoid using invalid contacts when a UA
reboots, as described later in this section.
For clarity, here is an example. Bob's UA creates a new TCP flow to
the registrar and sends the following REGISTER request.
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK-bad0ce-11-1036
Max-Forwards: 70
From: Bob <sip:bob@example.com>;tag=d879h76
To: Bob <sip:bob@example.com>
Call-ID: 8921348ju72je840.204
CSeq: 1 REGISTER
Contact: <sip:line1@192.168.0.2>; flow-id=1;
;+sip.instance="<urn:uuid:00000000-0000-0000-0000-000A95A0E128>"
Content-Length: 0
Implementors often ask why the value of the sip.instance is inside
angle brackets. This is a requirement of RFC 3840 [8] which
defines that media feature tags in SIP. Feature tags which are
strings are compared by case sensitive string comparison. To
differentiate these tags from tokens (which are not case
sensitive), case sensitive parameters such as the sip.instance
media feature tag are placed inside angle brackets.
The registrar challenges this registration to authenticate Bob. When
the registrar adds an entry for this contact under the AOR for Bob,
Jennings & Mahy Expires January 12, 2006 [Page 5]
Internet-Draft Client Initiated Connections in SIP July 2005
the registrar also keeps track of the connection over which it
received this registration.
The registrar saves the instance-id (as defined in [1]) and flow-id
(as defined in Section 9) along with the rest of the Contact header.
If the instance-id and flow-id are the same as a previous
registration for the same AOR, the proxy uses the most recently
created registration first. This allows a UA that has rebooted to
replace its previous registration for each flow with minimal impact
on overall system load.
Later when Alice sends a request to Bob, his proxy selects target
set. The proxy forwards the request to elements in the target set
based on the proxies policy. The proxy looks at the the target set
and uses the instance-id to understand that two targets both end up
routing to the same UA. When the proxy goes for forward a request to
a given target, it looks and finds the flows that received this
registrations. The proxy then forwards the request on that flow
instead of trying to form a new flow to that contact. This allows
the proxy to forward a request to a particular contact down the same
flow that did the registration for this AOR. If the proxy had
multiple flows that all went to this UA, it could choose any one of
registration binding that it had for this AOR and had the same
instance-id as the selected UA. In general, if two registrations
have the same flow-id and instance-id, the proxy would favor the most
recently registered flow. This is so that if a UA reboots, the proxy
will prefer to use the most recent flow that goes to this UA instead
of trying one of the old flows which will presumably fail.
3.3 Multiple Connections from a User Agent
In this example system, the logical proxy/registrar for the domain is
running on two hosts that share the appropriate state and can both
provide registrar and proxy functionality for the domain. The UA
will form connections to two of the physical hosts for the domain.
Jennings & Mahy Expires January 12, 2006 [Page 6]
Internet-Draft Client Initiated Connections in SIP July 2005
+-------------------+
| Domain |
| Logical Proxy/Reg |
| |
|+-----+ +-----+|
||Host1| |Host2||
|+-----+ +-----+|
+---\------------/--+
\ /
\ /
\ /
\ /
+------+
| User |
| Agent|
+------+
The UA is configured with a primary and backup registration URI. The
administrative domain that created these URIs MUST insure that the
two URIs resolve to separate hosts. These URI have normal SIP
processing so things like SRV can be used to do load balance across a
proxy farm.
The proxies can all use the Path header (as described in the next
section) to insure that a route to each connection is available to
each host, or the logical proxy can implement its own mechanism.
When a single server fails, all the UAs that have a registration with
it will detect this and try and reconnect. This can cause large
loads on the server and is referred to as the avalanche restart
problem. The multiple flows to many servers help reduce the load
caused by the avalanche restart. If a UA has multiple flows, and one
os the servers fails, it can delay some significant time before
trying to form a new connection to replace the flow to the server
that failed. By spreading out the time used for all the UA to
reconnect to a server, the load on the server is reduced.
3.4 Edge Proxies
Some SIP deployments use edge proxies such that the UA sends the
REGISTER to an edge proxy that then forwards the REGISTER to the
Registrar. The edge proxy includes a Path header [11] so that when
the registrar later forwards a request to this UA, the request is
routed through the edge proxy. There could be a NAT for FW between
the UA and the edge proxy and there could also be one between the
edge proxy and the Registrar. This second case typically happens
when the Edge proxy is in an enterprise the the registrar is at a
service provider.
Jennings & Mahy Expires January 12, 2006 [Page 7]
Internet-Draft Client Initiated Connections in SIP July 2005
+---------+
|Registrar|
|Proxy |
+---------+
/ \
----------------------------NAT/FW
/ \
+-----+ +-----+
|Edge1| |Edge2|
+-----+ +-----+
\ /
\ /
----------------------------NAT/FW
\ /
\ /
+------+
|User |
|Agent |
+------+
These systems can use effectively the same mechanism as described in
the previous sections but need to use the Path header. When the edge
proxy receives a registration, it needs to create an identifier value
that is unique to this flow (and not a subsequent flow with the same
addresses) and put this identifier in the path header. This is done
by putting the value in the user portion of a loose route in the path
header. If the registration succeeds, the edge proxy needs to map
future requests that are routed to the identifier value that was put
in the Path header to the associated flow.
3.5 Keep Alive Techniques
A keep alive mechanism needs to detect both failure of a connection
and changes to the NAT public mapping. When a residential NAT is
rebooted, the UA needs to understand that its bindings are no longer
valid and it needs to re-register. Simply sending keep alive packets
will not detect this failure when using UDP. With connection
oriented transports such as TCP or TLS, the keep alive will detect
failure after a NAT reboot. Connection oriented transport failures
are detected by having the UA periodically sends a CRLF over the
connection; if the connection has failed, a connection level error
will be reported to the UA. A CRLF can be considered the beginning
of the next message that will be sent, and therefore this approach is
backwards compatible with the core SIP specification.
Note: The TCP KEEP_ALIVE mechanism is not used because most
operating systems do not allow the time to be set on a per
connection basis. Linux, Solaris, OS X, and Windows all allow
Jennings & Mahy Expires January 12, 2006 [Page 8]
Internet-Draft Client Initiated Connections in SIP July 2005
KEEP_ALIVEs to be turned on or off on a single socket using the
SO_KEEPALIVE socket options but can not change the duration of the
timer for an individual socket. The length of the timer typically
defaults to 7200 seconds. The length of the timer can be changed
to a smaller value by setting a kernel parameter but that affects
all TCP connections on the host and thus is not appropriate to
use.
The keep alive mechanism for UDP is quite different. The UA needs to
detect when the connection is working but also when the flow
definition has changed. A flow definition could change because a NAT
device in the network path reboots and the resulting public IP
address or port mapping for the UA changes. To detect this, STUN [5]
requests are sent over the connection that is being used for the UDP
SIP traffic. The proxy or registrar acts as a STUN server on the SIP
signaling port.
Note: The STUN mechanism is very robust and allows the detection
of a changed IP address. It may also be possible to do this with
OPTIONS messages and rport; although this approach has the
advantage of being backwards compatible, it also increases the
load on the proxy or registrar server.
If the UA detects that the connection has failed or that the flow
definition has changed, it needs to re-register using a back-off
mechanism described in Section 4 in order to provide congestion
relief when a large number of agents simultaneously reboot.
4. User Agent Mechanisms
The UA behavior is divided up into sections. The first describes
what a client must do when forming a new connection, the second when
detecting failure of a connection, and the third on failure recovery.
4.1 Forming Flows
UAs are configured one of more SIP URIs with which to register. A UA
MUST support sets with at least two URIs (primary and backup) and
SHOULD support sets with up to four URIs. For each URI in the
redundancy set, the UA MUST send a REGISTER with a loose route set to
the URI from the set. The UA MUST include the the instance-id as
described in the [1]. The UA MUST also add a distinct flow-id
parameter to the contact header. The UA SHOULD use a flow-id value
of 1 for the first URI in the set, and a flow-id value of 2 for the
second, and so on. Each one of these registrations will form a new
flow from the UA to the proxy.
Note that the UA needs to honor 503 responses to registrations as
Jennings & Mahy Expires January 12, 2006 [Page 9]
Internet-Draft Client Initiated Connections in SIP July 2005
described in RFC 3261 and RFC 3263. In particular implementers
should note that a 503 with a Retry-After is not considered a failure
to form the connection. The UA should wait the indicated amount of
time and retry the connection. A Retry-After header field value of 0
is valid and indicates the UA should retry the REGISTER immediately.
Implementations need to ensure that when retrying the REGISTER they
redo the DNS resolution process such that if multiple hosts are
reachable from the URI, there is a chance that the UA will select an
alternate host from the one it chose the previous time the URI was
resolved.
4.1.1 Instance-ID Selection
The instance-id needs to be a URN but there are many ways one can be
generated. A particularly simple way for both "hard" phones and
"soft" phones is to use a UUID as defined in [7]. A device like a
soft-phone, when first installed, should generate a UUID [7] and then
save this in persistent storage for all future use. For a device
such as a hard phone, which will only ever have a single SIP UA
present, the UUID can be generated at any time because it is
guaranteed that no other UUID is being generated at the same time on
that physical device. This means the value of the time component of
the UUID can be arbitrarily selected to be any time less than the
time when the device was manufactured. A time of 0 (as shown in the
example in Section 3.2) is perfectly legal as long as the device
knows no other UUIDs were generated at this time.
4.2 Detecting Flow Failure
The UA needs to detect if a given flow has failed, and if it does
fail, follow the procedures in Section 4.1 to form a new flow to
replace the failed one.
User Agents that form flows with stream oriented protocols such as
TCP, TLS, or SCTP SHOULD periodically send a CRLF over the connection
to detect liveness of the flow. If when sending the CRLF, the
transport reports an error, then the connection is considered to have
failed. It is RECOMMENDED that a CRLF be sent if the flow has not
had any data sent or received in the previous 500 to 600 seconds.
The exact time in the 500 to 600 second range SHOULD be randomly
selected. These times MAY be configurable.
User Agents that form flows with datagram oriented protocols such as
UDP SHOULD check if the URI has the "stun" tag (defined in
Section 10) and, if the tag is present, then the UA needs to
periodically perform STUN [5] requests over the flow. The time
between STUN request SHOULD be a random number between 25 and 30
seconds. The times MAY be configurable. If the mapped address in
Jennings & Mahy Expires January 12, 2006 [Page 10]
Internet-Draft Client Initiated Connections in SIP July 2005
the STUN response changes, the UA must treat this as a failure on the
flow.
Any time a SIP message is sent and the proxy does not respond, this
is also considered a failure, the flow is closed and the procedures
in Section 4.1 are followed to form a new flow.
4.3 Flow Failure Recovery
When a flow to a particular URI in the proxy set fails, the UA needs
to form a new flow to replace it. The new flow MUST have the same
flow-id as the flow it is replacing. This is done in much the same
way as the forming flows described in Section 4.1; however, if there
is a failure in forming this flow, the UA needs to wait a certain
amount of time before retrying to form a flow to this particular URI
in the proxy set. The time to wait is computed in the following way.
If all of the flows to every URI in the proxy set have failed, the
base time is set to 30 seconds; otherwise, in the case where at least
one of the flows has not failed, the base time is set to 90 seconds.
The wait time is computed by taking the minimum of 1800 seconds, or
the base time multiplied by two to power of the number of consecutive
registration failures to that URI.
wait-time = min( 1800, (30 * (2 ^ consecutive-failures)))
These three times SHOULD be configurable in the UA. For example if
the base time was 30 seconds, and there had been three failures, then
the wait time would be min(1800,30*(2^3)) or 240 seconds. The delay
time is computed by selecting a uniform random time between 50 and
100 percent of the the wait time. The UA MUST wait for the value of
the delay time before trying another registration to form a new flow
for that URI.
To be explicitly clear on the boundary conditions, when the UA boots
it immediately tries to register. If this fails and no registration
on other flows had succeeded, the first retry would happen somewhere
between 30 and 60 seconds after the failure of the first registration
request.
4.4 Registration by other other instances
A User Agent MUST NOT include an instance-id or flow-id in the
Contact header field of a registration if the registering UA is not
the same instance as the UA referred to by the target Contact. (This
practice is occasionally used to install forwarding policy into
registrars.)
Jennings & Mahy Expires January 12, 2006 [Page 11]
Internet-Draft Client Initiated Connections in SIP July 2005
5. Registrar Mechanisms
5.1 Processing Register Requests
Registrars which implement this specification, processes REGISTER
requests as described in Section 10 of RFC 3261 with the following
change. Any time the registrar checks if a new contact matches an
existing contact in the location database, it MUST also check and see
if both the instance-id and flow-id match. If they do not match,
then the they are not the same contact. The registrar MUST be
prepared to receive some registrations that use instance-id and
flow-id and some that do not, simultaneously for the same AOR.
In addition to the normal information stored in the binding record,
some additional information MUST be stored for any registration that
contains a flow-id header parameter in the Contact header field
value. The registrar MUST store enough information to uniquely
identify the network flow over which the request arrived. For common
operating systems with TCP, this would typically just be the file
descriptor. For common operating systems with UDP this would
typically be the file descriptor for the local socket that received
the request and the IP address and port number of the remote side
that sent the request.
The registrar MUST also store all the Contact header field
information including the flow-id and instance-id and SHOULD also
store the time at which the binding was last updated. If the
registrar receives a re-registration, it MUST update the information
that uniquely identifies the network flow over which the request
arrived and the time the binding was last updated.
5.2 Forwarding Requests
When a proxy uses the location service to look up a registration
binding and then proxies a request to a particular contact, it
selects a contact to use normally, with a few additional rules:
o The proxy MUST NOT populate the target set with more than one
contact with the same AOR and instance-id at a time. If a request
for a particular AOR and instance-id fails with a 410 response,
the proxy SHOULD replace the failed branch with another target
with the same AOR and instance-id, but a different flow-id.
o If two bindings have the same instance-id and flow-id, it MUST
prefer the contact that was most recently updated.
Note that if the request URI is a GRUU, the proxy will only select
contacts with the AOR and instance-id associated with the GRUU. The
rules above still apply to a GRUU. This allows a request routed to a
Jennings & Mahy Expires January 12, 2006 [Page 12]
Internet-Draft Client Initiated Connections in SIP July 2005
GRUU to first try one of the flows to a UA, then if that fails, try
another flow to the same UA instance.
Proxies MUST Record-Route so that mid dialog requests are routed over
the correct flow.
When the proxy forwards a request to a binding that contains a
flow-id, the proxy MUST send the request over the same network flow
that was saved with the binding. For TCP, the request MUST be sent
on the same TCP socket that received the REGISTER request. For UDP,
the request MUST be sent from the same local IP address and port over
which the registration was received to the same IP address and port
from which the REGISTER was received.
If a proxy or registrar receives a network error when sending a SIP
message over a particular flow, it MUST remove all the bindings that
use that flow (regardless of AOR). Similarly, if a proxy closes a
file descriptor, it MUST remove all the bindings that use that flow.
6. Edge Proxy Mechanisms
6.1 Processing Register Requests
When an edge proxy receives a registration request it MUST form a
flow identifier token that is unique to this network flow and use
this token as the user part of the URI that this proxy inserts into
the Path header. A trivial way to satisfy this requirement involves
storing a mapping between an incrementing counter and the connection
information, however this would require the edge proxy to keep an
impractical amount of state. It is unclear when this state could be
removed and the approach would have problems if the proxy crashed and
lost the value of the counter. Two stateless examples are provided
below. A proxy can use any algorithm it wants as long as the flow
token is unique to a flow.
Algorithm 1: The proxy generates a flow token for connection-oriented
transports by concatenating the file descriptor (or equivalent)
with the NTP time the connection was created, and base64 encoding
the result. This results in an approximately 16 octet identifier.
The proxy generates a flow token for UDP by concatenating the file
descriptor and the remote IP address and port, then base64
encoding the result.
Algorithm 2: When the proxy boots it selects a 20 byte crypto random
key called K that only the edge proxy knows. A byte array, called
S, is formed that contains the following information about the
flow the request was received on: an enumeration indicating the
protocol, the local IP address and port, the remote IP address and
port. The HMAC of S is computed using the key K and the HMAC-
Jennings & Mahy Expires January 12, 2006 [Page 13]
Internet-Draft Client Initiated Connections in SIP July 2005
SHA1-80 algorithm, as defined in [9]. The concatenation of the
HMAC and S are base64 encoded, as defined in [10], and used as the
flow identifier. With IPv4 address, this will result in a 32
octet identifier.
6.2 Forwarding Requests
When the edge proxy receives a request that is routed to a URI with a
flow identifier token that this proxy created, then the proxy MUST
forward the request over the flow that received the REGISTER request
that caused the flow identifier token to be created. For connection-
oriented transports, if the flow no longer exists the proxy SHOULD
send a 410 response to the request. The advantage to a stateless
approach to managing the flow information is that there is no state
on the edge proxy that requires clean up that has to be synchronized
with the registrar.
Algorithm 1: The proxy base64 decodes the user part of the Route
header. For TCP, if a connection specified by the file descriptor
is present and the creation time of the file descriptor matches
the creation time encoded in the Route header, then proxy forwards
the request over that connection. For UDP, the proxy forwards the
request from the encoded file descriptor to the source IP address
and port.
Algorithm 2: To decode the flow token take the flow identifier in the
user portion of the URI, and base64 decode it, then verity the
HMAC is correct by recomputing the HMAC and checking it matches.
If the HMAC is not correct, the proxy SHOULD send a 403 response.
If the HMAC was correct then the proxy should forward the request
on the flow that was specified by the information in the flow
identifier. If this flow no longer exists, the proxy SHOULD send
a 410 response to the request.
Edge Proxies MUST Record-Route with the same URI that was used in the
path so that mid dialog requests still are routed over the correct
flow.
7. Mechanisms for All Servers
A SIP device that receives UDP datagrams directly from a UA needs to
behave as specified in this section. Such devices would generally
include a Registrar and an Edge Proxy, as they both receive register
requests directly from a UA.
If the server receives UDP SIP requests on a given interface and
port, it MUST also provide a limited version of the STUN server on
the same interface and port. Specifically it MUST be capable of
receiving and responding to UDP STUN requests with the exception that
Jennings & Mahy Expires January 12, 2006 [Page 14]
Internet-Draft Client Initiated Connections in SIP July 2005
it does not need to support STUN requests with the changed port or
changed address flag set. This allows the STUN server to run with
only one port and IP address.
It is easy to distinguish STUN and SIP packets because the first
octet of a STUN packet has a value of 0 or 1 while the first octet of
a SIP message never a 0 or 1.
When a URI is created that refers to a SIP device that supports STUN
as described in this section, the URI parameter "stun", as defined in
Section 10 SHOULD be added to the URI. This allows a UA to inspect
the URI to decide if it should attempt to send STUN requests to this
location.
8. Example Message Flow
The following call flow shows a basic registration and an incoming
call. Part way through the call, the flow to the Primary proxy is
lost. The BYE message for the call is rerouted to the callee via the
Backup proxy. When connectivity to the primary proxy is established,
the Callee registers again to replace the lost flow as shown in
message 15.
Jennings & Mahy Expires January 12, 2006 [Page 15]
Internet-Draft Client Initiated Connections in SIP July 2005
Caller Backup Primary Callee
| | | (1) REGISTER |
| | |<-----------------|
| | |(2) 200 OK |
| | |----------------->|
| | | (3) REGISTER |
| |<------------------------------------|
| |(4) 200 OK | |
| |------------------------------------>|
|(5) INVITE | | |
|----------------------------------->| |
| | |(6) INVITE |
| | |----------------->|
| | | (7) 200 OK |
| | |<-----------------|
| | (8) 200 OK | |
|<-----------------------------------| |
|(9) ACK | | |
|----------------------------------->| |
| | |(10) ACK |
| | |----------------->|
| | CRASH X |
|(11) BYE | |
|---------------->| |
| | (12) BYE |
| |------------------------------------>|
| | (13) 200 OK |
| |<------------------------------------|
| (14) 200 OK | |
|<----------------| REBOOT | |
| | | (15) REGISTER |
| | |<-----------------|
| | |(16) 200 OK |
| | |----------------->|
This call flow assumes that the Callee has been configured with a
proxy set of that consists of "sip:primary.example.com;lr;stun" and
"sip:backup.example.com;lr;stun". The Callee REGISTER in message (1)
looks like:
Jennings & Mahy Expires January 12, 2006 [Page 16]
Internet-Draft Client Initiated Connections in SIP July 2005
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 10.0.1.1;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Callee <sip:callee@example.com>;tag=a73kszlfl
To: Callee <sip:callee@example.com>
Call-ID: 1j9FpLxk3uxtm8tn@10.0.1.1
CSeq: 1 REGISTER
Route: <sip:primary.example.com;lr>
Contact: <sip:callee@10.0.1.1>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;flow-id=1
Content-Length: 0
In the message, note that the Route is set and the Contact header
field value contains the instance-id and flow-id. The response to
the REGISTER in message (2) would look like:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.1.1;branch=z9hG4bKnashds7
From: Callee <sip:callee@example.com>;tag=a73kszlfl
To: Callee <sip:callee@example.com> ;tag=b88sn
Call-ID: 1j9FpLxk3uxtm8tn@10.0.1.1
CSeq: 1 REGISTER
Contact: <sip:callee@10.0.1.1>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;flow-id=1
;expires=3600
Content-Length: 0
The second registration in message 3 and 4 are similar other than the
Call-ID has changed, the flow-id is 2, and the route is set to the
backup instead of the primary. They look like:
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 10.0.1.1;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Callee <sip:callee@example.com>;tag=a73kszlfl
To: Callee <sip:callee@example.com>
Call-ID: 1j9FpLxk3uxtm8tn-2@10.0.1.1
CSeq: 1 REGISTER
Route: <sip:primary.example.com;lr>
Contact: <sip:callee@10.0.1.1>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;flow-id=2
Jennings & Mahy Expires January 12, 2006 [Page 17]
Internet-Draft Client Initiated Connections in SIP July 2005
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.1.1;branch=z9hG4bKnashds7
From: Callee <sip:callee@example.com>;tag=a73kszlfl
To: Callee <sip:callee@example.com> ;tag=b88sn
Call-ID: 1j9FpLxk3uxtm8tn-2@10.0.1.1
CSeq: 1 REGISTER
Contact: <sip:callee@10.0.1.1>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;flow-id=1
;expires=3600
Contact: <sip:callee@10.0.1.1>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;flow-id=2
;expires=3600
Content-Length: 0
The messages in the call flow are very normal. The only interesting
thing to note is that the INVITE has a:
Record-Route: <sip:example.com;lr>
The registrations in message 15 and 16 are the same as message 1 and
2 other than the Call-ID has changed.
9. Grammar
This specification defines a new Contact header field parameter,
flow-id. The grammar for DIGIT and EQUAL is obtained from RFC 3261
[3].
contact-params = c-p-q / c-p-expires / c-p-flow / contact-extension
c-p-flow = "flow-id" EQUAL 1*DIGIT
The value of the flow-id MUST NOT be 0 and MUST be less than 2**31.
10. IANA Considerations
This specification defines a new Contact header field parameter
called flow-id in the "Header Field Parameters and Parameter Values"
sub-registry as per the registry created by [12] at
http://www.iana.org/assignments/sip-parameters. The required
information is:
Jennings & Mahy Expires January 12, 2006 [Page 18]
Internet-Draft Client Initiated Connections in SIP July 2005
Header Field Parameter Name Predefined Reference
Values
____________________________________________________________________
Contact flow-id Yes [RFC AAAA]
[NOTE TO IANA: Please replace AAAA with
the RFC number of this specification.]
This specification defines a new value in the "SIP/SIPS URI
Parameters" sub-registry as per the registry created by [13] at
http://www.iana.org/assignments/sip-parameters. The required
information is:
Parameter Name Predefined Values Reference
____________________________________________
stun No [RFC AAAA]
[NOTE TO IANA: Please replace AAAA with
the RFC number of this specification.]
11. Security Considerations
One of the key security concerns in this work is making sure that an
attacker cannot hijack the sessions of a valid user and cause all
calls destined to that user to be sent to the attacker.
The simple case is when there are no edge proxies. In this case, the
only time an entry can be added to the routing for a given AOR is
when the registration succeeds. SIP protects against attackers being
able to successfully register, and this scheme relies on that
security. Some implementers have considered the idea of just saving
the instance-id without relating it to the AOR with which it
registered. This idea will not work because an attacker's UA can
impersonate a valid user's instance-id and hijack that user's calls.
The more complex case involves one or more edge proxies. The only
time an edge proxy will route over a particular flow is when it has
received a route header that has the instance-id information it has
created. An incoming request would have gotten this information from
the registrar. The registrar will only save this information for a
given AOR if the registration for the AOR has been successful; and
the registration will only be successful if the UA can correctly
authenticate. Even if an attacker has spoofed some bad information
in the path header sent to the registrar, the attacker will not be
able to get the registrar to accept this information for an AOR that
does not belong to the attacker. The registrar will not hand out
Jennings & Mahy Expires January 12, 2006 [Page 19]
Internet-Draft Client Initiated Connections in SIP July 2005
this bad information to others, and others would not be misled into
contacting the attacker.
12. Open Issues
This specification requires Record Routing to force flows through
proxies. If all UA were required to implement GRUU, and all
deployments were mandated to use GRUU, and there could never be a
proxy behind a NAT or Firewall or deployed without a TLS certificate,
then it would not be necessary to require the Record Routing. Should
we do this?
The two algorithm for edge proxies are nearly identical with the
exception that one integrity protects the identifier so it can not be
tampered with. It is not clear if this integrity protection is
needed. The WG should determine if this integrity is need or not
then refine this specification.
13. Requirements
This specification was developed to meet the following requirements:
1. Must be able to detect that a UA supports these mechanisms.
2. Support UAs behind NATs.
3. Support TLS to a UA without a stable DNS name or IP.
4. Detect failure of connection and be able to correct for this.
5. Support many UAs simultaneously rebooting.
6. Support a NAT rebooting or resetting.
7. Support proxy farms with multiple hosts for scaling and
reliability purposes.
8. Minimize initial startup load on a proxy.
9. Support proxies that provide geographic redundancy.
10. Support architectures with edge proxies.
14. Changes from 01 Version
Changed the algorithm and timing for retries of re-registrations.
Changed to using sigcomp style URI parameter to detect it - UA should
attempt STUN to proxy.
Changed to use a configured set of backup proxies instead of playing
DNS games to try and figure out what backup proxies to use.
15. Changes from 00 Version
Changed the behavior of the proxy so that it does not automatically
remove registrations with the same instance-id and flow-id but
Jennings & Mahy Expires January 12, 2006 [Page 20]
Internet-Draft Client Initiated Connections in SIP July 2005
instead just uses the most recently created registration first.
Changed the connection-id to flow-id.
Fixed expiry of edge proxies and rewrote mechanism section to be
clearer.
16. Acknowledgments
Jonathan Rosenberg provided many comments and useful text. Dave Oran
came up with the idea of using the most recent registration first in
the proxy. Alan Hawrylyshen helped with text on drafts that led to
this one. Additionally, many of the concepts here originated at a
connection reuse meeting at IETF 60 that included the authors, Jon
Peterson, Jonathan Rosenberg, Alan Hawrylyshen, and Paul Kyzivat.
The TCP design team consisting of Chris Boulton, Scott Lawrence,
Rajnish Jain, Vijay K. Gurbani, and Ganesh Jayadevan provided input.
In addition, thanks to the following folks for useful comments:
Francois Audet, Flemming Andreasen, Dan Wing, Srivatsa Srinivasan,
and Lyndsay Campbell.
17. References
17.1 Normative References
[1] Rosenberg, J., "Obtaining and Using Globally Routable User Agent
(UA) URIs (GRUU) in the Session Initiation Protocol (SIP)",
draft-ietf-sip-gruu-04 (work in progress), July 2005.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] 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.
[4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[5] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN -
Simple Traversal of User Datagram Protocol (UDP) Through Network
Address Translators (NATs)", RFC 3489, March 2003.
[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[7] Leach, P., Mealling, M., and R. Salz, "A Universally Unique
IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
Jennings & Mahy Expires January 12, 2006 [Page 21]
Internet-Draft Client Initiated Connections in SIP July 2005
[8] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User
Agent Capabilities in the Session Initiation Protocol (SIP)",
RFC 3840, August 2004.
17.2 Informative References
[9] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[10] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 3548, July 2003.
[11] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
Extension Header Field for Registering Non-Adjacent Contacts",
RFC 3327, December 2002.
[12] Camarillo, G., "The Internet Assigned Number Authority (IANA)
Header Field Parameter Registry for the Session Initiation
Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[13] Camarillo, G., "The Internet Assigned Number Authority (IANA)
Uniform Resource Identifier (URI) Parameter Registry for the
Session Initiation Protocol (SIP)", BCP 99, RFC 3969,
December 2004.
[14] Mahy, R., "Connection Reuse in the Session Initiation Protocol
(SIP)", draft-ietf-sip-connect-reuse-03 (work in progress),
October 2004.
[15] Mahy, R., "Requirements for Connection Reuse in the Session
Initiation Protocol (SIP)",
draft-ietf-sipping-connect-reuse-reqs-00 (work in progress),
October 2002.
Authors' Addresses
Cullen Jennings (editor)
Cisco Systems
170 West Tasman Drive
Mailstop SJC-21/2
San Jose, CA 95134
USA
Phone: +1 408 902-3341
Email: fluffy@cisco.com
Jennings & Mahy Expires January 12, 2006 [Page 22]
Internet-Draft Client Initiated Connections in SIP July 2005
Rohan Mahy (editor)
SIP Edge LLC
5617 Scotts Valley Drive, Suite 200
Scotts Valley, CA 95066
USA
Email: rohan@ekabal.com
Jennings & Mahy Expires January 12, 2006 [Page 23]
Internet-Draft Client Initiated Connections in SIP July 2005
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 (2005). 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.
Jennings & Mahy Expires January 12, 2006 [Page 24]
