draft-ietf-sip-outbound-02.txt   draft-ietf-sip-outbound-03.txt 
Network Working Group C. Jennings, Ed. Network Working Group C. Jennings, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 3261,3327 (if approved) R. Mahy, Ed. Updates: 3261,3327 (if approved) R. Mahy, Ed.
Expires: September 6, 2006 Plantronics Expires: September 21, 2006 Plantronics
March 5, 2006 March 20, 2006
Managing Client Initiated Connections in the Session Initiation Protocol Managing Client Initiated Connections in the Session Initiation Protocol
(SIP) (SIP)
draft-ietf-sip-outbound-02 draft-ietf-sip-outbound-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 6, 2006. This Internet-Draft will expire on September 21, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
Session Initiation Protocol (SIP) allows proxy servers to initiate Session Initiation Protocol (SIP) allows proxy servers to initiate
TCP connections and send asynchronous UDP datagrams to User Agents in TCP connections and send asynchronous UDP datagrams to User Agents in
order to deliver requests. However, many practical considerations, order to deliver requests. However, many practical considerations,
skipping to change at page 2, line 15 skipping to change at page 2, line 15
(Transport Layer Security) server. This specification defines (Transport Layer Security) server. This specification defines
behaviors for User Agents, registrars and proxy servers that allow behaviors for User Agents, registrars and proxy servers that allow
requests to be delivered on existing connections established by the requests to be delivered on existing connections established by the
User Agent. It also defines keep alive behaviors needed to keep NAT User Agent. It also defines keep alive behaviors needed to keep NAT
bindings open and specifies the usage of multiple connections. bindings open and specifies the usage of multiple connections.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Summary of Mechanism . . . . . . . . . . . . . . . . . . . 5 3.1 Summary of Mechanism . . . . . . . . . . . . . . . . . . . 5
3.2. Single Registrar and UA . . . . . . . . . . . . . . . . . 6 3.2 Single Registrar and UA . . . . . . . . . . . . . . . . . 6
3.3. Multiple Connections from a User Agent . . . . . . . . . . 7 3.3 Multiple Connections from a User Agent . . . . . . . . . . 7
3.4. Edge Proxies . . . . . . . . . . . . . . . . . . . . . . . 9 3.4 Edge Proxies . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Keep Alive Technique . . . . . . . . . . . . . . . . . . . 10 3.5 Keep Alive Technique . . . . . . . . . . . . . . . . . . . 10
4. User Agent Mechanisms . . . . . . . . . . . . . . . . . . . . 10 4. User Agent Mechanisms . . . . . . . . . . . . . . . . . . . . 10
4.1. Instance ID Creation . . . . . . . . . . . . . . . . . . . 10 4.1 Instance ID Creation . . . . . . . . . . . . . . . . . . . 10
4.2. Initial Registrations . . . . . . . . . . . . . . . . . . 12 4.2 Initial Registrations . . . . . . . . . . . . . . . . . . 12
4.2.1. Registration by Other Instances . . . . . . . . . . . 13 4.2.1 Registration by Other Instances . . . . . . . . . . . 13
4.3. Sending Requests . . . . . . . . . . . . . . . . . . . . . 13 4.3 Sending Requests . . . . . . . . . . . . . . . . . . . . . 13
4.3.1. Selecting the First Hop . . . . . . . . . . . . . . . 13 4.3.1 Selecting the First Hop . . . . . . . . . . . . . . . 13
4.3.2. Forming Flows . . . . . . . . . . . . . . . . . . . . 13 4.3.2 Forming Flows . . . . . . . . . . . . . . . . . . . . 13
4.4. Detecting Flow Failure . . . . . . . . . . . . . . . . . . 14 4.4 Detecting Flow Failure . . . . . . . . . . . . . . . . . . 14
4.4.1. Keep Alive with STUN . . . . . . . . . . . . . . . . . 14 4.4.1 Keep Alive with STUN . . . . . . . . . . . . . . . . . 14
4.4.2. Keep Alive with Double CRLF . . . . . . . . . . . . . 15 4.4.2 Flow Recovery . . . . . . . . . . . . . . . . . . . . 15
4.5. Flow Recovery . . . . . . . . . . . . . . . . . . . . . . 15 5. Edge Proxy Mechanisms . . . . . . . . . . . . . . . . . . . . 15
5. Edge Proxy Mechanisms . . . . . . . . . . . . . . . . . . . . 16 5.1 Processing Register Requests . . . . . . . . . . . . . . . 15
5.1. Processing Register Requests . . . . . . . . . . . . . . . 16 5.2 Generating Flow Tokens . . . . . . . . . . . . . . . . . . 16
5.2. Generating Flow Tokens . . . . . . . . . . . . . . . . . . 16 5.3 Forwarding Requests . . . . . . . . . . . . . . . . . . . 16
5.3. Forwarding Requests . . . . . . . . . . . . . . . . . . . 17
6. Registrar and Location Server Mechanisms . . . . . . . . . . . 17 6. Registrar and Location Server Mechanisms . . . . . . . . . . . 17
6.1. Processing Register Requests . . . . . . . . . . . . . . . 18 6.1 Processing Register Requests . . . . . . . . . . . . . . . 17
6.2. Forwarding Requests . . . . . . . . . . . . . . . . . . . 19 6.2 Forwarding Requests . . . . . . . . . . . . . . . . . . . 18
7. Mechanisms for All Servers (Proxys, Registars, UAS) . . . . . 19 7. Mechanisms for All Servers (Proxys, Registars, UAS) . . . . . 19
7.1. STUN Processing . . . . . . . . . . . . . . . . . . . . . 19 7.1 STUN Processing . . . . . . . . . . . . . . . . . . . . . 19
7.2. Double CRLF Processing . . . . . . . . . . . . . . . . . . 20
8. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 20 8. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 20
9. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24
10.1. Contact Header Field . . . . . . . . . . . . . . . . . . . 24 10.1 Contact Header Field . . . . . . . . . . . . . . . . . . . 24
10.2. SIP/SIPS URI Paramters . . . . . . . . . . . . . . . . . . 24 10.2 SIP/SIPS URI Paramters . . . . . . . . . . . . . . . . . . 24
10.3. SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . 24 10.3 SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . 24
10.4. Media Feature Tag . . . . . . . . . . . . . . . . . . . . 25 10.4 Media Feature Tag . . . . . . . . . . . . . . . . . . . . 25
11. Security Considerations . . . . . . . . . . . . . . . . . . . 26 11. Security Considerations . . . . . . . . . . . . . . . . . . 26
12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 26 12. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 26
13. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 27 13. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 27
14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 13.1 Changes from 02 Version . . . . . . . . . . . . . . . . . 27
14.1. Changes from 01 Version . . . . . . . . . . . . . . . . . 27 13.2 Changes from 01 Version . . . . . . . . . . . . . . . . . 27
14.2. Changes from 00 Version . . . . . . . . . . . . . . . . . 27 13.3 Changes from 00 Version . . . . . . . . . . . . . . . . . 27
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 27
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
16.1. Normative References . . . . . . . . . . . . . . . . . . . 28 15.1 Normative References . . . . . . . . . . . . . . . . . . . 28
16.2. Informative References . . . . . . . . . . . . . . . . . . 29 15.2 Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . . 31
1. Introduction 1. Introduction
There are many environments for SIP [5] deployments in which the User There are many environments for SIP [5] deployments in which the User
Agent (UA) can form a connection to a Registrar or Proxy but in which 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. the connections in the reverse direction to the UA are not possible.
This can happen for several reasons. Connection to the UA can be This can happen for several reasons. Connection to the UA can be
blocked by a firewall device between the UA and the proxy or blocked by a firewall device between the UA and the proxy or
registrar, which will only allow new connections in the direction of 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 the UA to the Proxy. Similarly there may be a NAT, which are only
skipping to change at page 5, line 5 skipping to change at page 4, line 50
multiple flows to the proxy or registrar. This mechanism also uses a multiple flows to the proxy or registrar. This mechanism also uses a
keep alive mechanism over each flow so that the UA can detect when a keep alive mechanism over each flow so that the UA can detect when a
flow has failed. flow has failed.
2. Conventions and Terminology 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4]. document are to be interpreted as described in RFC 2119 [4].
2.1. Definitions 2.1 Definitions
Edge Proxy: An Edge Proxy is any proxy that is located topologically Edge Proxy: An Edge Proxy is any proxy that is located topologically
between the registering User Agent and the registrar. between the registering User Agent and the registrar.
flow: A Flow is a network protocol layer (layer 4) association flow: A Flow is a network protocol layer (layer 4) association
between two hosts that is represented by the network address and between two hosts that is represented by the network address and
port number of both ends and by the protocol. For TCP, a flow is port number of both ends and by the protocol. For TCP, a flow is
equivalent to a TCP connection. For UDP a flow is a bidirectional equivalent to a TCP connection. For UDP a flow is a bidirectional
stream of datagrams between a single pair of IP addresses and 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 ports of both peers. With TCP, a flow often has a one to one
correspondence with a single file descriptor in the operating correspondence with a single file descriptor in the operating
system. system.
skipping to change at page 5, line 36 skipping to change at page 5, line 33
Edge Proxies) with which the UA will attempt to maintain a direct Edge Proxies) with which the UA will attempt to maintain a direct
flow. flow.
3. Overview 3. Overview
Several scenarios in which this technique is useful are discussed Several scenarios in which this technique is useful are discussed
below, including the simple co-located registrar and proxy, a User below, including the simple co-located registrar and proxy, a User
Agent desiring multiple connections to a resource (for redundancy for Agent desiring multiple connections to a resource (for redundancy for
example), and a system that uses Edge Proxies. example), and a system that uses Edge Proxies.
3.1. Summary of Mechanism 3.1 Summary of Mechanism
The overall approach is fairly simple. Each UA has a unique 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 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 is power cycled. Each UA can register multiple times over different
connections for the same SIP Address of Record (AOR) to achieve high connections for the same SIP Address of Record (AOR) to achieve high
reliability. Each registration includes the instance-id for the UA reliability. Each registration includes the instance-id for the UA
and a reg-id label that is different for each flow. The registrar and a reg-id label that is different for each flow. The registrar
can use the instance-id to recognize that two different registrations can use the instance-id to recognize that two different registrations
both reach the same UA. The registrar can use the reg-id label to both reach the same UA. The registrar can use the reg-id label to
recognize that a UA is registering after a reboot. recognize that a UA is registering after a reboot.
skipping to change at page 6, line 12 skipping to change at page 6, line 9
registration has been completed. A failure on a particular flow can registration has been completed. A failure on a particular flow can
be tried again on an alternate flow. Proxies can determine which be tried again on an alternate flow. Proxies can determine which
flows go to the same UA by comparing the instance-id. Proxies can 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 tell that a flow replaces a previously abandoned flow by looking at
the reg-id. the reg-id.
UAs use the STUN (Simple Traversal of UDP through NATs) protocol as UAs use the STUN (Simple Traversal of UDP through NATs) protocol as
the keep alive mechanism to keep their flow to the proxy or registrar the keep alive mechanism to keep their flow to the proxy or registrar
alive. alive.
3.2. Single Registrar and UA 3.2 Single Registrar and UA
In this example, a single server is acting as both a registrar and In this example, a single server is acting as both a registrar and
proxy. proxy.
+-----------+ +-----------+
| Registrar | | Registrar |
| Proxy | | Proxy |
+-----+-----+ +-----+-----+
| |
| |
skipping to change at page 7, line 32 skipping to change at page 7, line 28
request to a particular contact over the same flow that the UA used request to a particular contact over the same flow that the UA used
to register this AOR. If the proxy has multiple flows that all go to to register this AOR. If the proxy has multiple flows that all go to
this UA, it can choose any one of registration bindings for this AOR this UA, it can choose any one of registration bindings for this AOR
that has the same instance-id as the selected UA. In general, if two that has the same instance-id as the selected UA. In general, if two
registrations have the same reg-id and instance-id, the proxy will registrations have the same reg-id and instance-id, the proxy will
favor the most recently registered flow. This is so that if a UA 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 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 would to this UA instead of trying one of the old flows which would
presumably fail. presumably fail.
3.3. Multiple Connections from a User Agent 3.3 Multiple Connections from a User Agent
There are various ways to deploy SIP to build a reliable and scalable There are various ways to deploy SIP to build a reliable and scalable
system. This section discusses one such design that is possible with system. This section discusses one such design that is possible with
the mechanisms in this specification. Other designs are also the mechanisms in this specification. Other designs are also
possible. possible.
In this example system, the logical proxy/registrar for the domain is In this example system, the logical proxy/registrar for the domain is
running on two hosts that share the appropriate state and can both running on two hosts that share the appropriate state and can both
provide registrar and proxy functionality for the domain. The UA provide registrar and proxy functionality for the domain. The UA
will form connections to two of the physical hosts that can perform will form connections to two of the physical hosts that can perform
skipping to change at page 8, line 32 skipping to change at page 8, line 29
\ / \ /
+------+ +------+
| User | | User |
| Agent| | Agent|
+------+ +------+
The UA is configured with a primary and backup registration URI. The UA is configured with a primary and backup registration URI.
These URIs are configured into the UA through whatever the normal These URIs are configured into the UA through whatever the normal
mechanism is to configure the proxy or registrar address in the UA. mechanism is to configure the proxy or registrar address in the UA.
If the AOR is Alice@example.com, the outbound-proxy-set might look If the AOR is Alice@example.com, the outbound-proxy-set might look
something like "sip:primary.example.com;sip-stun" and "sip: something like "sip:primary.example.com;keepalive=stun" and "sip:
backup.example.com;sip-stun". The "sip-stun" tag indicates that a backup.example.com;keepalive=stun". The "keepalive=stun" tag
SIP server supports STUN and SIP muxed over the same flow, as indicates that a SIP server supports STUN and SIP muxed over the same
described later in this specification. Note that each URI in the flow, as described later in this specification. Note that each URI
outbound-proxy-set could resolve to several different physical hosts. in the outbound-proxy-set could resolve to several different physical
The administrative domain that created these URIs should ensure that hosts. The administrative domain that created these URIs should
the two URIs resolve to separate hosts. These URIs are handled ensure that the two URIs resolve to separate hosts. These URIs are
according to normal SIP processing rules, so things like SRV can be handled according to normal SIP processing rules, so things like SRV
used to do load balancing across a proxy farm. can be used to do load balancing across a proxy farm.
The domain also needs to ensure that a request for the UA sent to 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. host1 or host2 is then sent across the appropriate flow to the UA.
The domain might choose to use the Path header (as described in the The domain might choose to use the Path header (as described in the
next section) approach to store this internal routing information on next section) approach to store this internal routing information on
host1 or host2. host1 or host2.
When a single server fails, all the UAs that have a flow through it 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 will detect a flow failure and try to reconnect. This can cause
large loads on the server. When large numbers of hosts reconnect large loads on the server. When large numbers of hosts reconnect
nearly simultaneously, this is referred to as the avalanche restart nearly simultaneously, this is referred to as the avalanche restart
problem, and is further discussed in Section 4.5. The multiple flows problem, and is further discussed in Section 4.4.2. The multiple
to many servers help reduce the load caused by the avalanche restart. flows to many servers help reduce the load caused by the avalanche
If a UA has multiple flows, and one of the servers fails, it can restart. If a UA has multiple flows, and one of the servers fails,
delay some significant time before trying to form a new connection to it can delay some significant time before trying to form a new
replace the flow to the server that failed. By spreading out the connection to replace the flow to the server that failed. By
time used for all the UAs to reconnect to a server, the load on the spreading out the time used for all the UAs to reconnect to a server,
server farm is reduced. the load on the server farm is reduced.
3.4. Edge Proxies 3.4 Edge Proxies
Some SIP deployments use edge proxies such that the UA sends the Some SIP deployments use edge proxies such that the UA sends the
REGISTER to an Edge Proxy that then forwards the REGISTER to the REGISTER to an Edge Proxy that then forwards the REGISTER to the
Registrar. The Edge Proxy includes a Path header [12] so that when Registrar. The Edge Proxy includes a Path header [12] so that when
the registrar later forwards a request to this UA, the request is the registrar later forwards a request to this UA, the request is
routed through the Edge Proxy. There could be a NAT or firewall routed through the Edge Proxy. There could be a NAT or firewall
between the UA and the Edge Proxy. between the UA and the Edge Proxy.
+---------+ +---------+
|Registrar| |Registrar|
|Proxy | |Proxy |
skipping to change at page 10, line 4 skipping to change at page 9, line 48
Proxy receives a registration, it needs to create an identifier value 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 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 can addresses) and put this identifier in the Path header URI. This can
be done by putting the value in the user portion of a loose route in be 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 the path header. If the registration succeeds, the Edge Proxy needs
to map future requests that are routed to the identifier value from to map future requests that are routed to the identifier value from
the Path header, to the associated flow. the Path header, to the associated flow.
The term Edge Proxy is often used to refer to deployments where the The term Edge Proxy is often used to refer to deployments where the
Edge Proxy is in the same administrative domain as the Registrar. Edge Proxy is in the same administrative domain as the Registrar.
However, in this specification we use the term to refer to any proxy 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 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 inside an enterprise that requires its use and the registrar could be
a service provider with no relationship to the enterprise. a service provider with no relationship to the enterprise.
Regardless if they are in the same administrative domain, this Regardless if they are in the same administrative domain, this
specification requires that Registrars and Edge proxies support the specification requires that Registrars and Edge proxies support the
Path header mechanism in RFC 3327 [12]. Path header mechanism in RFC 3327 [12].
3.5. Keep Alive Technique 3.5 Keep Alive Technique
A keep alive mechanism needs to detect failure of a connection and A keep alive mechanism needs to detect failure of a connection and
changes to the NAT public mapping, as well as keeping any NAT changes to the NAT public mapping, as well as keeping any NAT
bindings refreshed. This specification uses STUN [7] over the same bindings refreshed. This specification describes using STUN [7] over
flow as the SIP traffic to perform the keep alive. A flow definition the same flow as the SIP traffic to perform the keep alive. For
could change because a NAT device in the network path reboots and the connection-oriented transports (e.g. TCP and TLS over TCP), the UAC
resulting public IP address or port mapping for the UA changes. To MAY use TCP keep-alives to detect flow failure if the UAC can send
detect this, requests are sent over the same flow that is being used these keep alives and detect a keep alive failure according to the
for the SIP traffic. The proxy or registrar acts as a STUN server on timeframes described in Section 4.4.
the SIP signaling port.
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, requests are sent over the same flow that is being used for the
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 Note: The STUN mechanism is very robust and allows the detection
of a changed IP address. Many other options were considered. It of a changed IP address. Many other options were considered, but
may also be possible to detect a changes flow with OPTIONS the SIP Working Group selected the STUN-based approach, since it
messages and the rport parameter. Although the OPTIONS approach works over any transport. Approaches using SIP requests were
has the advantage of being backwards compatible, it also abandoned because to achieve the required performance, the server
significantly increases the load on the proxy or registrar server. needs to deviate from the SIP specification in significant ways.
The TCP KEEP_ALIVE mechanism was not used because most operating This would result in many undesirable and non-deterministic
systems do not allow the time to be set on a per connection basis. behaviors in some environments. The TCP KEEP_ALIVE mechanism will
Linux, Solaris, OS X, and Windows all allow KEEP_ALIVEs to be not always work, since some operating systems and programming
turned on or off on a single socket using the SO_KEEPALIVE socket environments do not allow the keep alive time to be set on a per
options but can not change the duration of the timer for an connection basis.
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.
When the UA detects that a flow has failed or that the flow 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 definition has changed, the UA needs to re-register and will use the
back-off mechanism described in Section 4 to provide congestion back-off mechanism described in Section 4 to provide congestion
relief when a large number of agents simultaneously reboot. relief when a large number of agents simultaneously reboot.
4. User Agent Mechanisms 4. User Agent Mechanisms
4.1. Instance ID Creation 4.1 Instance ID Creation
Each UA MUST have an Instance Identifer URN that uniquely identifies Each UA MUST have an Instance Identifer URN that uniquely identifies
the device. Usage of a URN provides a persistent and unique name for the device. Usage of a URN provides a persistent and unique name for
the UA instance. It also provides an easy way to guarantee the UA instance. It also provides an easy way to guarantee
uniqueness within the AOR. This URN MUST be persitant across power uniqueness within the AOR. This URN MUST be persitant across power
cylces of the device. cylces of the device.
A UA SHOULD use a UUID URN [9]. The UUID URN allows for non- A UA SHOULD use a UUID URN [9]. The UUID URN allows for non-
centralized computation of a URN based on time, unique names (such as centralized computation of a URN based on time, unique names (such as
a MAC address), or a random number generator. a MAC address), or a random number generator.
skipping to change at page 12, line 20 skipping to change at page 12, line 18
2141 [3]. Lexical equality may result in two URNs being 2141 [3]. Lexical equality may result in two URNs being
considered unequal when they are actually equal. In this specific considered unequal when they are actually equal. In this specific
usage of URNs, the only element which provides the URN is the SIP usage of URNs, the only element which provides the URN is the SIP
UA instance identified by that URN. As a result, the UA instance UA instance identified by that URN. As a result, the UA instance
SHOULD provide lexically equivalent URNs in each registration it SHOULD provide lexically equivalent URNs in each registration it
generates. This is likely to be normal behavior in any case; generates. This is likely to be normal behavior in any case;
clients are not likely to modify the value of the instance ID so clients are not likely to modify the value of the instance ID so
that it remains functionally equivalent yet lexigraphically that it remains functionally equivalent yet lexigraphically
different to previous registrations. different to previous registrations.
4.2. Initial Registrations 4.2 Initial Registrations
UAs are configured with one or more SIP URIs representing the default UAs are configured with one or more SIP URIs representing the default
outbound-proxy-set. The specification assumes the set is determined outbound-proxy-set. The specification assumes the set is determined
via configuration but future specifications may define other via configuration but future specifications may define other
mechanisms such as using DNS to discover this set. How the UA is mechanisms such as using DNS to discover this set. How the UA is
configured is outside the scope of this specification. However, a UA configured is outside the scope of this specification. However, a UA
MUST support sets with at least two outbound proxy URIs (primary and MUST support sets with at least two outbound proxy URIs (primary and
backup) and SHOULD support sets with up to four URIs. For each backup) and SHOULD support sets with up to four URIs. For each
outbound proxy URI in the set, the UA MUST send a REGISTER in the outbound proxy URI in the set, the UA MUST send a REGISTER in the
normal way using this URI as the default outbound proxy. Forming the normal way using this URI as the default outbound proxy. Forming the
skipping to change at page 13, line 23 skipping to change at page 13, line 21
described in RFC 3261 and RFC 3263 [6]. In particular, implementors described in RFC 3261 and RFC 3263 [6]. In particular, implementors
should note that when receiving a 503 response with a Retry-After should note that when receiving a 503 response with a Retry-After
header field, the UA should wait the indicated amount of time and header field, the UA should wait the indicated amount of time and
retry the registration. A Retry-After header field value of 0 is retry the registration. A Retry-After header field value of 0 is
valid and indicates the UA should retry the REGISTER immediately. valid and indicates the UA should retry the REGISTER immediately.
Implementations need to ensure that when retrying the REGISTER they Implementations need to ensure that when retrying the REGISTER they
revisit the DNS resolution results such that the UA can select an revisit the DNS resolution results such that the UA can select an
alternate host from the one chosen the previous time the URI was alternate host from the one chosen the previous time the URI was
resolved. resolved.
4.2.1. Registration by Other Instances 4.2.1 Registration by Other Instances
A User Agent MUST NOT include an instance-id or reg-id in the Contact A User Agent MUST NOT include an instance-id or reg-id in the Contact
header field of a registration if the registering UA is not the same header field of a registration if the registering UA is not the same
instance as the UA referred to by the target Contact header field. instance as the UA referred to by the target Contact header field.
(This practice is occasionally used to install forwarding policy into (This practice is occasionally used to install forwarding policy into
registrars.) registrars.)
Note that a UAC also MUST NOT include an instance-id or reg-id Note that a UAC also MUST NOT include an instance-id or reg-id
parameter in a request to deregister all Contacts (a single Contact parameter in a request to deregister all Contacts (a single Contact
header field value with the value of "*"). header field value with the value of "*").
4.3. Sending Requests 4.3 Sending Requests
As described in Section 4.1, all requests need to include the As described in Section 4.1, all requests need to include the
instance-id media feature tag unless privacy concerns require instance-id media feature tag unless privacy concerns require
otherwise. otherwise.
4.3.1. Selecting the First Hop 4.3.1 Selecting the First Hop
When an UA is about to send a request, it first performs normal When an UA is about to send a request, it first performs normal
processing to select the next hop URI. The UA can use a variety of processing to select the next hop URI. The UA can use a variety of
techniques to compute the route set and accordingly the next hop URI. techniques to compute the route set and accordingly the next hop URI.
Discussion of these techniques is outside the scope of this document Discussion of these techniques is outside the scope of this document
but could include mechanisms specified in RFC 3608 [21] (Service but could include mechanisms specified in RFC 3608 [21] (Service
Route) and [20]. Route) and [20].
4.3.2. Forming Flows 4.3.2 Forming Flows
The UA performs normal DNS resolution on the next hop URI (as The UA performs normal DNS resolution on the next hop URI (as
described in RFC 3263 [6]) to find a protocol, IP address, and port. described in RFC 3263 [6]) to find a protocol, IP address, and port.
For non TLS protocols, if the UA has an existing flow to this IP For non TLS protocols, if the UA has an existing flow to this IP
address, and port with the correct protocol, then the UA MUST use the address, and port with the correct protocol, then the UA MUST use the
existing connection. For TLS protocols, the existing flow is only existing connection. For TLS protocols, the existing flow is only
used if, in addition to matching the IP address, port, and protocol, used if, in addition to matching the IP address, port, and protocol,
the host production in the next hop URI MUST match one of the URIs the host production in the next hop URI MUST match one of the URIs
contained in the subjectAltName in the peer certificate. If the UA contained in the subjectAltName in the peer certificate. If the UA
cannot use one of the existing flows, then it SHOULD form a new flow cannot use one of the existing flows, then it SHOULD form a new flow
by sending a datagram or opening a new connection to the next hop, as by sending a datagram or opening a new connection to the next hop, as
appropriate for the transport protocol. appropriate for the transport protocol.
4.4. Detecting Flow Failure 4.4 Detecting Flow Failure
The UA needs to detect when a specific flow fails. If a flow has The UA needs to detect when a specific flow fails. If a flow has
failed, the UA follows the procedures in Section 4.2 to form a new failed, the UA follows the procedures in Section 4.2 to form a new
flow to replace the failed one. The UA proactively tries to detect flow to replace the failed one. The UA proactively tries to detect
failure by periodically sending keep alive messages using one of the failure by periodically sending keep alive messages using one of the
techniques described in this section. techniques described in this section.
The time between keep alive requests when using UDP based transports The time between keep alive requests when using UDP based transports
SHOULD be a random number between 24 and 29 seconds while for TCP SHOULD be a random number between 24 and 29 seconds while for TCP
based transports it SHOULD be a random number between 95 and 120 based transports it SHOULD be a random number between 95 and 120
skipping to change at page 14, line 45 skipping to change at page 14, line 42
evenly spread the load on the servers. For TCP, the 120 seconds evenly spread the load on the servers. For TCP, the 120 seconds
was chosen based on the idea that for a good user experience, was chosen based on the idea that for a good user experience,
failures should be detected in this amount of time and a new failures should be detected in this amount of time and a new
connection set up. Operators that wish to change the relationship connection set up. Operators that wish to change the relationship
between load on servers and the expected time that a user may not between load on servers and the expected time that a user may not
receive inbound communications will probably adjust this time. receive inbound communications will probably adjust this time.
The 95 seconds lower bound was chosen so that the jitter The 95 seconds lower bound was chosen so that the jitter
introduced will result in a relatively even load on the servers introduced will result in a relatively even load on the servers
after 30 minutes. after 30 minutes.
4.4.1. Keep Alive with STUN 4.4.1 Keep Alive with STUN
User Agents that form flows MUST check if the configured URI they are User Agents that form flows MUST check if the configured URI they are
connecting to has the "sip-stun" URI parameter (defined in connecting to has a 'keepalive' URI parameter (defined in Section 10)
Section 10). If the parameter is present, the UA needs to with the value of 'stun'. If the parameter is present, the UA needs
periodically perform keep alive checks by sending a STUN [7] Binding to periodically perform keep alive checks by sending a STUN [7]
Requests over the flow. Binding Requests over the flow.
If the XOR-MAPPED-ADDRESS in the STUN Binding Response changes, the If the XOR-MAPPED-ADDRESS in the STUN Binding Response changes, the
UA MUST treat this event as a failure on the flow. UA MUST treat this event as a failure on the flow.
4.4.2. Keep Alive with Double CRLF 4.4.2 Flow Recovery
User Agents that form flows MUST check if the configured URI they are
connecting to has the "crlf-ping" URI parameter (defined in
Section 10). If the parameter is present, the UA needs to send keep
alive requests by sending a CRLF over the flow.
If the UA does not receive any data back over the flow within 7
seconds of sending the CRLF, then it MUST consider the lack of
response to be a flow failure.
4.5. Flow Recovery
When a flow to a particular URI in the outbound-proxy-set fails, the When a flow to a particular URI in the outbound-proxy-set fails, the
UA needs to form a new flow to replace the old flow and replace any UA needs to form a new flow to replace the old flow and replace any
registrations that were previously sent over this flow. Each new registrations that were previously sent over this flow. Each new
registration MUST have the same reg-id as the registration it registration MUST have the same reg-id as the registration it
replaces. This is done in much the same way as forming a brand new replaces. This is done in much the same way as forming a brand new
flow as described in Section 4.3.2; however, if there is a failure in flow as described in Section 4.3.2; however, if there is a failure in
forming this flow, the UA needs to wait a certain amount of time forming this flow, the UA needs to wait a certain amount of time
before retrying to form a flow to this particular next hop. before retrying to form a flow to this particular next hop.
skipping to change at page 16, line 4 skipping to change at page 15, line 39
and there had been three failures, then the wait time would be 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 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 selecting a uniform random time between 50 and 100 percent of the
wait time. The UA MUST wait for the value of the delay time before 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. trying another registration to form a new flow for that URI.
To be explicitly clear on the boundary conditions: when the UA boots To be explicitly clear on the boundary conditions: when the UA boots
it immediately tries to register. If this fails and no registration it immediately tries to register. If this fails and no registration
on other flows succeed, the first retry happens somewhere between 30 on other flows succeed, the first retry happens somewhere between 30
and 60 seconds after the failure of the first registration request. and 60 seconds after the failure of the first registration request.
If the number of consecutive-failures is large enough that the If the number of consecutive-failures is large enough that the
maximum of 1800 seconds is reached, the UA will keep trying forever maximum of 1800 seconds is reached, the UA will keep trying forever
with a random time between 900 and 1800 seconds between the attempts. with a random time between 900 and 1800 seconds between the attempts.
5. Edge Proxy Mechanisms 5. Edge Proxy Mechanisms
5.1. Processing Register Requests 5.1 Processing Register Requests
When an Edge Proxy receives a registration request with a When an Edge Proxy receives a registration request with a
sip.instance media feature tag in the Contact header field, it MUST sip.instance media feature tag in the Contact header field, it MUST
form a flow identifier token that is unique to this network flow. form a flow identifier token that is unique to this network flow.
The Edge Proxy MUST insert this token into a URI referring to this The Edge Proxy MUST insert this token into a URI referring to this
proxy and place this URI into a Path header field as described in RFC proxy and place this URI into a Path header field as described in RFC
3327 [12]. The token MAY be placed in the userpart of the URI. 3327 [12]. The token MAY be placed in the userpart of the URI.
5.2. Generating Flow Tokens 5.2 Generating Flow Tokens
A trivial but impractical way to satisfy the flow token requirement A trivial but impractical way to satisfy the flow token requirement
Section 5.1 involves storing a mapping between an incrementing Section 5.1 involves storing a mapping between an incrementing
counter and the connection information; however this would require counter and the connection information; however this would require
the Edge Proxy to keep an impractical amount of state. It is unclear 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 when this state could be removed and the approach would have problems
if the proxy crashed and lost the value of the counter. Two if the proxy crashed and lost the value of the counter. Two
stateless examples are provided below. A proxy can use any algorithm stateless examples are provided below. A proxy can use any algorithm
it wants as long as the flow token is unique to a flow, the flow can it wants as long as the flow token is unique to a flow, the flow can
be recovered from the token, and the token can not be modified by be recovered from the token, and the token can not be modified by
skipping to change at page 17, line 6 skipping to change at page 16, line 39
key called K that only the Edge Proxy knows. A byte array, called key called K that only the Edge Proxy knows. A byte array, called
S, is formed that contains the following information about the S, is formed that contains the following information about the
flow the request was received on: an enumeration indicating the flow the request was received on: an enumeration indicating the
protocol, the local IP address and port, the remote IP address and 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- port. The HMAC of S is computed using the key K and the HMAC-
SHA1-80 algorithm, as defined in [16]. The concatenation of the SHA1-80 algorithm, as defined in [16]. The concatenation of the
HMAC and S are base64 encoded, as defined in [18], and used as the HMAC and S are base64 encoded, as defined in [18], and used as the
flow identifier. When using IPv4 addresses, this will result in a flow identifier. When using IPv4 addresses, this will result in a
32 octet identifier. 32 octet identifier.
5.3. Forwarding Requests 5.3 Forwarding Requests
When the Edge Proxy receives a request, it applies normal routing When the Edge Proxy receives a request, it applies normal routing
procedures with the following addition. If the top-most Route header procedures with the following addition. If the top-most Route header
refers to the Edge Proxy and contains a valid flow identifier token refers to the Edge Proxy and contains a valid flow identifier token
created by this proxy, the proxy MUST forward the request over the created by this proxy, the proxy MUST forward the request over the
flow that received the REGISTER request that caused the flow flow that received the REGISTER request that caused the flow
identifier token to be created. For connection-oriented transports, identifier token to be created. For connection-oriented transports,
if the flow no longer exists the proxy SHOULD send a 410 response to if the flow no longer exists the proxy SHOULD send a 410 response to
the request. the request.
skipping to change at page 18, line 5 skipping to change at page 17, line 34
a 410 response to the request. a 410 response to the request.
Note that techniques to ensure that mid-dialog requests are routed Note that techniques to ensure that mid-dialog requests are routed
over an existing flow are out of scope and therefore not part of this over an existing flow are out of scope and therefore not part of this
specification. However, an approach such as having the Edge Proxy specification. However, an approach such as having the Edge Proxy
Record-Route with a flow token is one way to ensure that mid-dialog Record-Route with a flow token is one way to ensure that mid-dialog
requests are routed over the correct flow. requests are routed over the correct flow.
6. Registrar and Location Server Mechanisms 6. Registrar and Location Server Mechanisms
6.1. Processing Register Requests 6.1 Processing Register Requests
This specification updates the definition of a binding in RFC 3261 This specification updates the definition of a binding in RFC 3261
[5] Section 10 and RFC 3327 [12] Section 5.3. [5] Section 10 and RFC 3327 [12] Section 5.3.
When no instance-id is present in a Contact header field value in a When no instance-id is present in a Contact header field value in a
REGISTER request, the corresponding binding is still between an AOR REGISTER request, the corresponding binding is still between an AOR
and the URI from that Contact header field value. When an and the URI from that Contact header field value. When an
instance-id is present in a Contact header field value in a REGISTER instance-id is present in a Contact header field value in a REGISTER
request, the corresponding binding is between an AOR and the request, the corresponding binding is between an AOR and the
combination of instance-id and reg-id. For a binding with an combination of instance-id and reg-id. For a binding with an
skipping to change at page 19, line 6 skipping to change at page 18, line 37
The Registrar MUST include the 'outbound' option-tag in a Supported The Registrar MUST include the 'outbound' option-tag in a Supported
header field value in its responses to REGISTER requests. The header field value in its responses to REGISTER requests. The
Registrar MAY be configured with local policy to reject any Registrar MAY be configured with local policy to reject any
registrations that do not include the instance-id and reg-id to registrations that do not include the instance-id and reg-id to
eliminate the amplification attack described in [19]. Note that the eliminate the amplification attack described in [19]. Note that the
requirements in this section applies to both REGISTER requests requirements in this section applies to both REGISTER requests
received from an Edge Proxy as well as requests received directly received from an Edge Proxy as well as requests received directly
from the UAC. from the UAC.
6.2. Forwarding Requests 6.2 Forwarding Requests
When a proxy uses the location service to look up a registration When a proxy uses the location service to look up a registration
binding and then proxies a request to a particular contact, it binding and then proxies a request to a particular contact, it
selects a contact to use normally, with a few additional rules: selects a contact to use normally, with a few additional rules:
o The proxy MUST NOT populate the target set with more than one 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 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, for a particular AOR and instance-id fails with a 410 response,
the proxy SHOULD replace the failed branch with another target (if the proxy SHOULD replace the failed branch with another target (if
one is available) with the same AOR and instance-id, but a one is available) with the same AOR and instance-id, but a
skipping to change at page 19, line 48 skipping to change at page 19, line 30
Similarly, if a proxy closes a file descriptor, it MUST invalidate Similarly, if a proxy closes a file descriptor, it MUST invalidate
all the bindings with flows that use that file descriptor. all the bindings with flows that use that file descriptor.
7. Mechanisms for All Servers (Proxys, Registars, UAS) 7. Mechanisms for All Servers (Proxys, Registars, UAS)
A SIP device that receives SIP messages directly from a UA needs to A SIP device that receives SIP messages directly from a UA needs to
behave as specified in this section. Such devices would generally behave as specified in this section. Such devices would generally
include a Registrar and an Edge Proxy, as they both receive register include a Registrar and an Edge Proxy, as they both receive register
requests directly from a UA. requests directly from a UA.
7.1. STUN Processing 7.1 STUN Processing
This document defines a new STUN usage for inband connectivity This document defines a new STUN usage for inband connectivity
checks. The only STUN messages required by this usage are Binding checks. The only STUN messages required by this usage are Binding
Requests, Binding Responses, and Error Responses. The UAC sends Requests, Binding Responses, and Error Responses. The UAC sends
Binding Requests over the same UDP flow, TCP connection, or TLS Binding Requests over the same UDP flow, TCP connection, or TLS
channel used for sending SIP messages, once a SIP registration has channel used for sending SIP messages, once a SIP registration has
been successfully processed on that flow. These Binding Requests do been successfully processed on that flow. These Binding Requests do
not require any STUN attributes. The UAS responds to a valid Binding not require any STUN attributes. The UAS responds to a valid Binding
Request with a Binding Response which MUST include the XOR-MAPPED- Request with a Binding Response which MUST include the XOR-MAPPED-
ADDRESS attribute. After a successful STUN response is received over ADDRESS attribute. After a successful STUN response is received over
skipping to change at page 20, line 25 skipping to change at page 20, line 6
If the server receives SIP requests on a given interface and port, it If the server receives SIP requests on a given interface and port, it
MUST also provide a limited version of a STUN server on the same MUST also provide a limited version of a STUN server on the same
interface and port. Specifically it MUST be capable of receiving and interface and port. Specifically it MUST be capable of receiving and
responding to STUN Binding Requests. responding to STUN Binding Requests.
It is easy to distinguish STUN and SIP packets because the first 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 octet of a STUN packet has a value of 0 or 1 while the first octet
of a SIP message is never a 0 or 1. of a SIP message is never a 0 or 1.
When a URI is created that refers to a SIP device that supports STUN When a URI is created that refers to a SIP device that supports STUN
as described in this section, the URI parameter "sip-stun", as as described in this section, the 'keepalive' URI parameter, as
defined in Section 10 MUST be added to the URI. This allows a UA to defined in Section 10 MUST be added to the URI, with a value of
inspect the URI to decide if it should attempt to send STUN requests 'stun'. This allows a UA to inspect the URI to decide if it should
to this location. The sip-stun tag typically would be present in the attempt to send STUN requests to this location. The 'keepalive' tag
URI in the Route header field value of a REGISTER request and not be typically would be present in the URI in the Route header field value
in the Request URI. of a REGISTER request and not be in the Request URI.
7.2. Double CRLF Processing
If the SIP server is acting as the TCP client and initiated the TCP
connection (meaning that this host did the active open), then the SIP
server MUST NOT perform any of the processing in this section. The
following only applies when the SIP server is acting as the TCP
server (meaning that this host did the passive open).
When the server receives a CRLF before the start line of a message on
a flow, it MUST send some data back on that same flow within 3
seconds. If no message is actively being sent, it SHOULD send back a
CRLF after waiting at least 1 second. The reason for waiting at
least 1 second is that if the other end has an incorrect
implementation and incorrectly echoes the CRLF, this will stop the
flow from going into a live-lock state.
8. Example Message Flow 8. Example Message Flow
The following call flow shows a basic registration and an incoming The following call flow shows a basic registration and an incoming
call. Part way through the call, the flow to the Primary proxy is 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 lost. The BYE message for the call is rerouted to the callee via the
Backup proxy. When connectivity to the primary proxy is established, Backup proxy. When connectivity to the primary proxy is established,
the Callee registers again to replace the lost flow as shown in the Callee registers again to replace the lost flow as shown in
message 15. message 15.
skipping to change at page 21, line 47 skipping to change at page 21, line 42
| | (13) 200 OK | | | (13) 200 OK |
| |<------------------------------------| | |<------------------------------------|
| (14) 200 OK | | | (14) 200 OK | |
|<----------------| REBOOT | | |<----------------| REBOOT | |
| | | (15) REGISTER | | | | (15) REGISTER |
| | |<-----------------| | | |<-----------------|
| | |(16) 200 OK | | | |(16) 200 OK |
| | |----------------->| | | |----------------->|
This call flow assumes that the Callee has been configured with a This call flow assumes that the Callee has been configured with a
proxy set that consists of "sip:primary.example.com;lr;sip-stun" and proxy set that consists of "sip:
"sip:backup.example.com;lr;sip-stun". The Callee REGISTER in message primary.example.com;lr;keepalive=stun" and "sip:
(1) looks like: backup.example.com;lr;keepalive=stun". The Callee REGISTER in
message (1) looks like:
REGISTER sip:example.com SIP/2.0 REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 10.0.1.1;branch=z9hG4bKnashds7 Via: SIP/2.0/UDP 10.0.1.1;branch=z9hG4bKnashds7
Max-Forwards: 70 Max-Forwards: 70
From: Callee <sip:callee@example.com>;tag=a73kszlfl From: Callee <sip:callee@example.com>;tag=a73kszlfl
To: Callee <sip:callee@example.com> To: Callee <sip:callee@example.com>
Call-ID: 1j9FpLxk3uxtm8tn@10.0.1.1 Call-ID: 1j9FpLxk3uxtm8tn@10.0.1.1
CSeq: 1 REGISTER CSeq: 1 REGISTER
Supported: path Supported: path
Route: <sip:primary.example.com;lr;sip-stun> Route: <sip:primary.example.com;lr;keepalive=stun>
Contact: <sip:callee@10.0.1.1> Contact: <sip:callee@10.0.1.1>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>" ;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1 ;reg-id=1
Content-Length: 0 Content-Length: 0
In the message, note that the Route is set and the Contact header In the message, note that the Route is set and the Contact header
field value contains the instance-id and reg-id. The response to the field value contains the instance-id and reg-id. The response to the
REGISTER in message (2) would look like: REGISTER in message (2) would look like:
SIP/2.0 200 OK SIP/2.0 200 OK
skipping to change at page 22, line 48 skipping to change at page 22, line 48
backup instead of the primary. They look like: backup instead of the primary. They look like:
REGISTER sip:example.com SIP/2.0 REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 10.0.1.1;branch=z9hG4bKnashds7 Via: SIP/2.0/UDP 10.0.1.1;branch=z9hG4bKnashds7
Max-Forwards: 70 Max-Forwards: 70
From: Callee <sip:callee@example.com>;tag=a73kszlfl From: Callee <sip:callee@example.com>;tag=a73kszlfl
To: Callee <sip:callee@example.com> To: Callee <sip:callee@example.com>
Call-ID: 1j9FpLxk3uxtm8tn-2@10.0.1.1 Call-ID: 1j9FpLxk3uxtm8tn-2@10.0.1.1
CSeq: 1 REGISTER CSeq: 1 REGISTER
Supported: path Supported: path
Route: <sip:backup.example.com;lr;sip-stun> Route: <sip:backup.example.com;lr;keepalive=stun>
Contact: <sip:callee@10.0.1.1> Contact: <sip:callee@10.0.1.1>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>" ;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=2 ;reg-id=2
Content-Length: 0 Content-Length: 0
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.1.1;branch=z9hG4bKnashds7 Via: SIP/2.0/UDP 10.0.1.1;branch=z9hG4bKnashds7
From: Callee <sip:callee@example.com>;tag=a73kszlfl From: Callee <sip:callee@example.com>;tag=a73kszlfl
To: Callee <sip:callee@example.com> ;tag=b88sn To: Callee <sip:callee@example.com> ;tag=b88sn
Call-ID: 1j9FpLxk3uxtm8tn-2@10.0.1.1 Call-ID: 1j9FpLxk3uxtm8tn-2@10.0.1.1
skipping to change at page 24, line 19 skipping to change at page 24, line 19
c-p-instance = "+sip.instance" EQUAL LDQUOT "<" c-p-instance = "+sip.instance" EQUAL LDQUOT "<"
instance-val ">" RDQUOT instance-val ">" RDQUOT
instance-val = *uric ; defined in RFC 2396 instance-val = *uric ; defined in RFC 2396
The value of the reg-id MUST NOT be 0 and MUST be less than 2**31. The value of the reg-id MUST NOT be 0 and MUST be less than 2**31.
10. IANA Considerations 10. IANA Considerations
10.1. Contact Header Field 10.1 Contact Header Field
This specification defines a new Contact header field parameter This specification defines a new Contact header field parameter
called reg-id in the "Header Field Parameters and Parameter Values" called reg-id in the "Header Field Parameters and Parameter Values"
sub-registry as per the registry created by [13] . The required sub-registry as per the registry created by [13] . The required
information is: information is:
Header Field Parameter Name Predefined Reference Header Field Parameter Name Predefined Reference
Values Values
____________________________________________________________________ ____________________________________________________________________
Contact reg-id Yes [RFC AAAA] Contact reg-id Yes [RFC AAAA]
[NOTE TO RFC Editor: Please replace AAAA with [NOTE TO RFC Editor: Please replace AAAA with
the RFC number of this specification.] the RFC number of this specification.]
10.2. SIP/SIPS URI Paramters 10.2 SIP/SIPS URI Paramters
This specification arguments the "SIP/SIPS URI Parameters" sub- This specification arguments the "SIP/SIPS URI Parameters" sub-
registry as per the registry created by [14] . The required registry as per the registry created by [14] . The required
information is: information is:
Parameter Name Predefined Values Reference Parameter Name Predefined Values Reference
____________________________________________ ____________________________________________
sip-stun No [RFC AAAA] keealive stun [RFC AAAA]
crlf-ping No [RFC AAAA]
[NOTE TO RFC Editor: Please replace AAAA with [NOTE TO RFC Editor: Please replace AAAA with
the RFC number of this specification.] the RFC number of this specification.]
10.3. SIP Option Tag 10.3 SIP Option Tag
This specification registers a new SIP option tag, as per the This specification registers a new SIP option tag, as per the
guidelines in Section 27.1 of RFC 3261. guidelines in Section 27.1 of RFC 3261.
Name: outbound Name: outbound
Description: This option-tag is used to identify Registrars which Description: This option-tag is used to identify Registrars which
support extensions for Client Initiated Connections. A Registrar support extensions for Client Initiated Connections. A Registrar
places this option-tag in a Supported header to communicate to the places this option-tag in a Supported header to communicate to the
registering User Agent the Registrars support for this extension. registering User Agent the Registrars support for this extension.
10.4. Media Feature Tag 10.4 Media Feature Tag
This section registers a new media feature tag, per the procedures This section registers a new media feature tag, per the procedures
defined in RFC 2506 [1]. The tag is placed into the sip tree, which defined in RFC 2506 [1]. The tag is placed into the sip tree, which
is defined in RFC 3840 [10]. is defined in RFC 3840 [10].
Media feature tag name: sip.instance Media feature tag name: sip.instance
ASN.1 Identifier: New assignment by IANA. ASN.1 Identifier: New assignment by IANA.
Summary of the media feature indicated by this tag: This feature tag Summary of the media feature indicated by this tag: This feature tag
skipping to change at page 26, line 42 skipping to change at page 26, line 42
gotten this information from the registrar. The registrar will only gotten this information from the registrar. The registrar will only
save this information for a given AOR if the registration for the AOR save this information for a given AOR if the registration for the AOR
has been successful; and the registration will only be successful if has been successful; and the registration will only be successful if
the UA can correctly authenticate. Even if an attacker has spoofed the UA can correctly authenticate. Even if an attacker has spoofed
some bad information in the path header sent to the registrar, the some bad information in the path header sent to the registrar, the
attacker will not be able to get the registrar to accept this attacker will not be able to get the registrar to accept this
information for an AOR that does not belong to the attacker. The information for an AOR that does not belong to the attacker. The
registrar will not hand out this bad information to others, and registrar will not hand out this bad information to others, and
others will not be misled into contacting the attacker. others will not be misled into contacting the attacker.
12. Open Issues 12. Requirements
Do we want to include the Double CRLF keep alive option?
Are thre any deployments that could use Algorithm 1 and if not can we
remove it?
We should change syntax from "sip-stun" to "keep-alive=sip-stun".
13. Requirements
This specification was developed to meet the following requirements: This specification was developed to meet the following requirements:
1. Must be able to detect that a UA supports these mechanisms. 1. Must be able to detect that a UA supports these mechanisms.
2. Support UAs behind NATs. 2. Support UAs behind NATs.
3. Support TLS to a UA without a stable DNS name or IP address. 3. Support TLS to a UA without a stable DNS name or IP address.
4. Detect failure of connection and be able to correct for this. 4. Detect failure of connection and be able to correct for this.
5. Support many UAs simultaneously rebooting. 5. Support many UAs simultaneously rebooting.
6. Support a NAT rebooting or resetting. 6. Support a NAT rebooting or resetting.
7. Minimize initial startup load on a proxy. 7. Minimize initial startup load on a proxy.
8. Support architectures with edge proxies. 8. Support architectures with edge proxies.
14. Changes 13. Changes
Note to RFC Editor: Please remove this whole section. Note to RFC Editor: Please remove this whole section.
14.1. Changes from 01 Version 13.1 Changes from 02 Version
Removed Double CRLF Keepalive
Changed ;sip-stun syntax to ;keepalive=stun
Fixed incorrect text about TCP keepalives.
13.2 Changes from 01 Version
Moved definition of instance-id from GRUU[17] draft to this draft. Moved definition of instance-id from GRUU[17] draft to this draft.
Added tentative text about Double CRLF Keep Alive Added tentative text about Double CRLF Keep Alive
Removed pin-route stuff Removed pin-route stuff
Changed the name of "flow-id" to "reg-id" Changed the name of "flow-id" to "reg-id"
Reorganized document flow Reorganized document flow
Described the use of STUN as a proper STUN usage Described the use of STUN as a proper STUN usage
Added 'outbound' option-tag to detect if registrar supports outbound Added 'outbound' option-tag to detect if registrar supports outbound
14.2. Changes from 00 Version 13.3 Changes from 00 Version
Moved TCP keep alive to be STUN. Moved TCP keep alive to be STUN.
Allowed SUBSCRIBE to create flow mappings. Added pin-route option Allowed SUBSCRIBE to create flow mappings. Added pin-route option
tags to support this. tags to support this.
Added text about updating dialog state on each usage after a Added text about updating dialog state on each usage after a
connection failure. connection failure.
15. Acknowledgments 14. Acknowledgments
Jonathan Rosenberg provided many comments and useful text. Dave Oran Jonathan Rosenberg provided many comments and useful text. Dave Oran
came up with the idea of using the most recent registration first in came up with the idea of using the most recent registration first in
the proxy. Alan Hawrylyshen co-authored the draft that formed the the proxy. Alan Hawrylyshen co-authored the draft that formed the
initial text of this specification. Additionally, many of the initial text of this specification. Additionally, many of the
concepts here originated at a connection reuse meeting at IETF 60 concepts here originated at a connection reuse meeting at IETF 60
that included the authors, Jon Peterson, Jonathan Rosenberg, Alan that included the authors, Jon Peterson, Jonathan Rosenberg, Alan
Hawrylyshen, and Paul Kyzivat. The TCP design team consisting of Hawrylyshen, and Paul Kyzivat. The TCP design team consisting of
Chris Boulton, Scott Lawrence, Rajnish Jain, Vijay K. Gurbani, and Chris Boulton, Scott Lawrence, Rajnish Jain, Vijay K. Gurbani, and
Ganesh Jayadevan provided input and text. Nils Ohlmeier provided Ganesh Jayadevan provided input and text. Nils Ohlmeier provided
many fixes and initial implementation experience. In addition, many fixes and initial implementation experience. In addition,
thanks to the following folks for useful comments: Francois Audet, thanks to the following folks for useful comments: Francois Audet,
Flemming Andreasen, Mike Hammer, Dan Wing, Srivatsa Srinivasan, and Flemming Andreasen, Mike Hammer, Dan Wing, Srivatsa Srinivasan, and
Lyndsay Campbell. Lyndsay Campbell.
16. References 15. References
16.1. Normative References 15.1 Normative References
[1] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag [1] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag
Registration Procedure", BCP 31, RFC 2506, March 1999. Registration Procedure", BCP 31, RFC 2506, March 1999.
[2] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller [2] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)", Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004. RFC 3841, August 2004.
[3] Moats, R., "URN Syntax", RFC 2141, May 1997. [3] Moats, R., "URN Syntax", RFC 2141, May 1997.
skipping to change at page 29, line 24 skipping to change at page 29, line 20
[13] Camarillo, G., "The Internet Assigned Number Authority (IANA) [13] Camarillo, G., "The Internet Assigned Number Authority (IANA)
Header Field Parameter Registry for the Session Initiation Header Field Parameter Registry for the Session Initiation
Protocol (SIP)", BCP 98, RFC 3968, December 2004. Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[14] Camarillo, G., "The Internet Assigned Number Authority (IANA) [14] Camarillo, G., "The Internet Assigned Number Authority (IANA)
Uniform Resource Identifier (URI) Parameter Registry for the Uniform Resource Identifier (URI) Parameter Registry for the
Session Initiation Protocol (SIP)", BCP 99, RFC 3969, Session Initiation Protocol (SIP)", BCP 99, RFC 3969,
December 2004. December 2004.
16.2. Informative References 15.2 Informative References
[15] Hakala, J., "Using National Bibliography Numbers as Uniform [15] Hakala, J., "Using National Bibliography Numbers as Uniform
Resource Names", RFC 3188, October 2001. Resource Names", RFC 3188, October 2001.
[16] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing [16] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997. for Message Authentication", RFC 2104, February 1997.
[17] Rosenberg, J., "Obtaining and Using Globally Routable User [17] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-04 (work in progress), July 2005. (SIP)", draft-ietf-sip-gruu-04 (work in progress), July 2005.
 End of changes. 56 change blocks. 
171 lines changed or deleted 143 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/