Network Working Group C. Jennings, Ed.
Request for Comments: 5626 Cisco Systems
Updates: 3261, 3327 R. Mahy, Ed.
Category: Standards Track Unaffiliated
F. Audet, Ed.
October 2009 Managing Client-Initiated Connections
in the Session Initiation Protocol (SIP)
The Session Initiation Protocol (SIP) allows proxy servers to
initiate TCP connections or to send asynchronous UDP datagrams to
User Agents in order to deliver requests. However, in a large number
of real deployments, many practical considerations, such as the
existence of firewalls and Network Address Translators (NATs) or the
use of TLS with server-provided certificates, prevent servers from
connecting to User Agents in this way. 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 from
the User Agent to its registrar.
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
There are many environments for SIP [RFC3261] deployments in which
the User Agent (UA) can form a connection to a registrar or proxy but
in which connections in the reverse direction to the UA are not
possible. This can happen for several reasons, but the most likely
is a NAT or a firewall in between the SIP UA and the proxy. Many
such devices will only allow outgoing connections. This
specification allows a SIP User Agent behind such a firewall or NAT
to receive inbound traffic associated with registrations or dialogs
that it initiates.
Most IP phones and personal computers get their network
configurations dynamically via a protocol such as the Dynamic Host
Configuration Protocol (DHCP) [RFC2131]. These systems typically do
not have a useful name in the Domain Name System (DNS) [RFC1035], and
they almost never have a long-term, stable DNS name that is
appropriate for use in the subjectAltName of a certificate, as
required by [RFC3261]. However, these systems can still act as a
Transport Layer Security (TLS) [RFC5246] client and form outbound
connections to a proxy or registrar that authenticates with a server
certificate. The server can authenticate the UA using a shared
secret in a digest challenge (as defined in Section 22 of RFC 3261)
over that TLS connection. This specification allows a SIP User Agent
who has to initiate the TLS connection to receive inbound traffic
associated with registrations or dialogs that it initiates.
The key idea of this specification is that when a UA sends a REGISTER
request or a dialog-forming request, the proxy can later use this
same network "flow" -- whether this is a bidirectional stream of UDP
datagrams, a TCP connection, or an analogous concept in another
transport protocol -- to forward any incoming requests that need to
go to this UA in the context of the registration or dialog.
For a UA to receive incoming requests, the UA has to connect to a
server. Since the server can't connect to the UA, the UA has to make
sure that a flow is always active. This requires the UA to detect
when a flow fails. Since such detection takes time and leaves a
window of opportunity for missed incoming requests, this mechanism
allows the UA to register over multiple flows at the same time. This
specification also defines two keep-alive schemes. The keep-alive
mechanism is used to keep NAT bindings fresh, and to allow the UA to
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 [RFC2119].
Authoritative Proxy: A proxy that handles non-REGISTER requests for
a specific Address-of-Record (AOR), performs the logical Location
Server lookup described in [RFC3261], and forwards those requests
to specific Contact URIs. (In [RFC3261], the role that is
authoritative for REGISTER requests for a specific AOR is a
Edge Proxy: An edge proxy is any proxy that is located topologically
between the registering User Agent and the Authoritative Proxy.
The "first" edge proxy refers to the first edge proxy encountered
when a UA sends a request.
Flow: A Flow is a transport-layer association between two hosts that
is represented by the network address and port number of both ends
and by the transport protocol. For TCP, a flow is equivalent to a
TCP connection. For UDP a flow is a bidirectional stream of
datagrams between a single pair of IP addresses and ports of both
peers. With TCP, a flow often has a one-to-one correspondence
with a single file descriptor in the operating system.
Flow Token: An identifier that uniquely identifies a flow which can
be included in a SIP URI (Uniform Resource Identifier [RFC3986]).
reg-id: This refers to the value of a new header field parameter
value for the Contact header field. When a UA registers multiple
times, each for a different flow, each concurrent registration
gets a unique reg-id value.
instance-id: This specification uses the word instance-id to refer
to the value of the "sip.instance" media feature tag which appears
as a "+sip.instance" Contact header field parameter. This is a
Uniform Resource Name (URN) that uniquely identifies this specific
"ob" Parameter: The "ob" parameter is a SIP URI parameter that has a
different meaning depending on context. In a Path header field
value, it is used by the first edge proxy to indicate that a flow
token was added to the URI. In a Contact or Route header field
value, it indicates that the UA would like other requests in the
same dialog to be routed over the same flow.
outbound-proxy-set: A set of SIP URIs (Uniform Resource Identifiers)
that represents each of the outbound proxies (often edge proxies)
with which the UA will attempt to maintain a direct flow. The
first URI in the set is often referred to as the primary outbound
proxy and the second as the secondary outbound proxy. There is no
difference between any of the URIs in this set, nor does the
primary/secondary terminology imply that one is preferred over the
The mechanisms defined in this document are useful in several
scenarios discussed below, including the simple co-located registrar
and proxy, a User Agent desiring multiple connections to a resource
(for redundancy, for example), and a system that uses edge proxies.
This entire section is non-normative.
3.1. Summary of Mechanism
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 over different flows for the same SIP Address of Record (AOR)
to achieve high reliability. Each registration includes the
instance-id for the UA and a reg-id label that is different for each
flow. The registrar can use the instance-id to recognize that two
different registrations both correspond to the same UA. The
registrar can use the reg-id label to recognize whether a UA is
creating a new flow or refreshing or replacing an old one, possibly
after a reboot or a network failure.
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 to deliver a request on a
particular flow can be tried again on an alternate flow. Proxies can
determine which flows go to the same UA by comparing the instance-id.
Proxies can tell that a flow replaces a previously abandoned flow by
looking at the reg-id.
When sending a dialog-forming request, a UA can also ask its first
edge proxy to route subsequent requests in that dialog over the same
flow. This is necessary whether the UA has registered or not.
UAs use a simple periodic message as a keep-alive mechanism to keep
their flow to the proxy or registrar alive. For connection-oriented
transports such as TCP this is based on carriage-return and line-feed
sequences (CRLF), while for transports that are not connection
oriented, this is accomplished by using a SIP-specific usage profile
of STUN (Session Traversal Utilities for NAT) [RFC5389].
3.2. Single Registrar and UA
In the topology shown below, a single server is acting as both a
registrar and proxy.
| Registrar |
| Proxy |
| User |
| Agent |
User Agents that form only a single flow continue to register
normally but include the instance-id as described in Section 4.1.
The UA also includes a "reg-id" Contact header field parameter that
is used to allow the registrar to detect and avoid keeping invalid
contacts when a UA reboots or reconnects after its old connection has
failed for some reason.
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/TCP 192.0.2.2;branch=z9hG4bK-bad0ce-11-1036
From: Bob <sip:email@example.com>;tag=d879h76
To: Bob <sip:firstname.lastname@example.org>
CSeq: 1 REGISTER
Supported: path, outbound
Contact: <sip:email@example.com;transport=tcp>; reg-id=1;
The registrar challenges this registration to authenticate Bob. When
the registrar adds an entry for this contact under the AOR for Bob,
the registrar also keeps track of the connection over which it
received this registration.
The registrar saves the instance-id
("urn:uuid:00000000-0000-1000-8000-000A95A0E128") and reg-id ("1")
along with the rest of the Contact header field. If the instance-id
and reg-id are the same as a previous registration for the same AOR,
the registrar replaces the old Contact URI and flow information.
This allows a UA that has rebooted to replace its previous
registration for each flow with minimal impact on overall system
When Alice sends a request to Bob, his authoritative proxy selects
the target set. The proxy forwards the request to elements in the
target set based on the proxy's policy. The proxy looks at the
target set and uses the instance-id to understand if two targets both
end up routing to the same UA. When the proxy goes to forward a
request to a given target, it looks and finds the flows over which it
received the registration. The proxy then forwards the request over
an existing flow, instead of resolving the Contact URI using the
procedures in [RFC3263] and trying to form a new flow to that
As described in the next section, if the proxy has multiple flows
that all go to this UA, the proxy can choose any one of the
registration bindings for this AOR that has the same instance-id as
the selected UA.
3.3. Multiple Connections from a User Agent
There are various ways to deploy SIP to build a reliable and scalable
system. This section discusses one such design that is possible with
the mechanisms in this specification. Other designs are also
In the example system below, the logical outbound proxy/registrar for
the domain is running on two hosts that share the appropriate state
and can both provide registrar and outbound proxy functionality for
the domain. The UA will form connections to two of the physical
hosts that can perform the authoritative proxy/registrar function for
the domain. Reliability is achieved by having the UA form two TCP
connections to the domain.
| Domain |
| Logical Proxy/Reg |
| User |
The UA is configured with multiple outbound proxy registration URIs.
These URIs are configured into the UA through whatever the normal
mechanism is to configure the proxy address and AOR in the UA. If
the AOR is firstname.lastname@example.org, the outbound-proxy-set might look
something like "sip:primary.example.com" and "sip:
secondary.example.com". Note that each URI in the outbound-proxy-set
could resolve to several different physical hosts. The
administrative domain that created these URIs should ensure that the
two URIs resolve to separate hosts. These URIs are handled according
to normal SIP processing rules, so mechanisms like DNS SRV [RFC2782]
can be used to do load-balancing across a proxy farm. The approach
in this document does not prevent future extensions, such as the SIP
UA configuration framework [CONFIG-FMWK], from adding other ways for
a User Agent to discover its outbound-proxy-set.
The domain also needs to ensure that a request for the UA sent to
Host1 or Host2 is then sent across the appropriate flow to the UA.
The domain might choose to use the Path header approach (as described
in the next section) to store this internal routing information on
Host1 or Host2.
When a single server fails, all the UAs that have a flow through it
will detect a flow failure and try to reconnect. This can cause
large loads on the server. When large numbers of hosts reconnect
nearly simultaneously, this is referred to as the avalanche restart
problem, and is further discussed in Section 4.5. The multiple flows
to many servers help reduce the load caused by the avalanche restart.
If a UA has multiple flows, and one of the servers fails, the UA
delays a recommended amount of 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 UAs to reconnect to a server,
the load on the server farm is reduced.
Scalability is achieved by using DNS SRV [RFC2782] to load-balance
the primary connection across a set of machines that can service the
primary connection, and also using DNS SRV to load-balance across a
separate set of machines that can service the secondary connection.
The deployment here requires that DNS is configured with one entry
that resolves to all the primary hosts and another entry that
resolves to all the secondary hosts. While this introduces
additional DNS configuration, the approach works and requires no
additional SIP extensions to [RFC3263].
Another motivation for maintaining multiple flows between the UA and
its registrar is related to multihomed UAs. Such UAs can benefit
from multiple connections from different interfaces to protect
against the failure of an individual access link.
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. There could be a NAT or firewall between the UA and the
The edge proxy includes a Path header [RFC3327] so that when the
proxy/registrar later forwards a request to this UA, the request is
routed through the edge proxy.
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 URI. This
identifier has two purposes. First, it allows the edge proxy to map
future requests back to the correct flow. Second, because the
identifier will only be returned if the user authenticates with the
registrar successfully, it allows the edge proxy to indirectly check
the user's authentication information via the registrar. The
identifier is placed 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 from the
Path header) to the associated flow.
The term edge proxy is often used to refer to deployments where the
edge proxy is in the same administrative domain as the registrar.
However, in this specification we use the term to refer to any proxy
between the UA and the registrar. For example, the edge proxy may be
inside an enterprise that requires its use, and the registrar could
be from a service provider with no relationship to the enterprise.
Regardless of whether they are in the same administrative domain,
this specification requires that registrars and edge proxies support
the Path header mechanism in [RFC3327].
3.5. Keep-Alive Technique
This document describes two keep-alive mechanisms: a CRLF keep-alive
and a STUN keep-alive. Each of these mechanisms uses a client-to-
server "ping" keep-alive and a corresponding server-to-client "pong"
message. This ping-pong sequence allows the client, and optionally
the server, to tell if its flow is still active and useful for SIP
traffic. The server responds to pings by sending pongs. If the
client does not receive a pong in response to its ping (allowing for
retransmission for STUN as described in Section 4.4.2), it declares
the flow dead and opens a new flow in its place.
This document also suggests timer values for these client keep-alive
mechanisms. These timer values were chosen to keep most NAT and
firewall bindings open, to detect unresponsive servers within 2
minutes, and to mitigate against the avalanche restart problem.
However, the client may choose different timer values to suit its
needs, for example to optimize battery life. In some environments,
the server can also keep track of the time since a ping was received
over a flow to guess the likelihood that the flow is still useful for
delivering SIP messages.
When the UA detects that a flow has failed or that the flow
definition has changed, the UA needs to re-register and will use the
back-off mechanism described in Section 4.5 to provide congestion
relief when a large number of agents simultaneously reboot.
A keep-alive mechanism needs to keep NAT bindings refreshed; for
connections, it also needs to detect failure of a connection; and for
connectionless transports, it needs to detect flow failures including
changes to the NAT public mapping. For connection-oriented
transports such as TCP [RFC0793] and SCTP [RFC4960], this
specification describes a keep-alive approach based on sending CRLFs.
For connectionless transport, such as UDP [RFC0768], this
specification describes using STUN [RFC5389] over the same flow as
the SIP traffic to perform the keep-alive.
UAs and Proxies are also free to use native transport keep-alives;
however, the application may not be able to set these timers on a
per-connection basis, and the server certainly cannot make any
assumption about what values are used. Use of native transport
keep-alives is outside the scope of this document.
3.5.1. CRLF Keep-Alive Technique
This approach can only be used with connection-oriented transports
such as TCP or SCTP. The client periodically sends a double-CRLF
(the "ping") then waits to receive a single CRLF (the "pong"). If
the client does not receive a "pong" within an appropriate amount of
time, it considers the flow failed.
Note: Sending a CRLF over a connection-oriented transport is
backwards compatible (because of requirements in Section 7.5 of
[RFC3261]), but only implementations which support this
specification will respond to a "ping" with a "pong".
3.5.2. STUN Keep-Alive Technique
This approach can only be used for connection-less transports, such
For connection-less transports, 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 requests are sent over the same flow that is being used
for the SIP traffic. The proxy or registrar acts as a limited
Session Traversal Utilities for NAT (STUN) [RFC5389] server on the
SIP signaling port.
Note: The STUN mechanism is very robust and allows the detection
of a changed IP address and port. Many other options were
considered, but the SIP Working Group selected the STUN-based
approach. Approaches using SIP requests were abandoned because
many believed that good performance and full backwards
compatibility using this method were mutually exclusive.