draft-ietf-sip-outbound-13.txt   draft-ietf-sip-outbound-14.txt 
Network Working Group C. Jennings, Ed. Network Working Group C. Jennings, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 3261,3327 R. Mahy, Ed. Updates: 3261,3327 R. Mahy, Ed.
(if approved) Plantronics (if approved) Plantronics
Intended status: Standards Track March 21, 2008 Intended status: Standards Track May 25, 2008
Expires: September 22, 2008 Expires: November 26, 2008
Managing Client Initiated Connections in the Session Initiation Protocol Managing Client Initiated Connections in the Session Initiation Protocol
(SIP) (SIP)
draft-ietf-sip-outbound-13 draft-ietf-sip-outbound-14
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 37 skipping to change at page 1, line 37
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 22, 2008. This Internet-Draft will expire on November 26, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
The Session Initiation Protocol (SIP) allows proxy servers to The Session Initiation Protocol (SIP) allows proxy servers to
initiate TCP connections and send asynchronous UDP datagrams to User initiate TCP connections and send asynchronous UDP datagrams to User
Agents in order to deliver requests. However, many practical Agents in order to deliver requests. However, many practical
skipping to change at page 2, line 28 skipping to change at page 2, line 28
3.2. Single Registrar and UA . . . . . . . . . . . . . . . . . 6 3.2. Single Registrar and UA . . . . . . . . . . . . . . . . . 6
3.3. Multiple Connections from a User Agent . . . . . . . . . 8 3.3. Multiple Connections from a User Agent . . . . . . . . . 8
3.4. Edge Proxies . . . . . . . . . . . . . . . . . . . . . . 10 3.4. Edge Proxies . . . . . . . . . . . . . . . . . . . . . . 10
3.5. Keep alive Technique . . . . . . . . . . . . . . . . . . 11 3.5. Keep alive Technique . . . . . . . . . . . . . . . . . . 11
3.5.1. CRLF Keep alive Technique . . . . . . . . . . . . . . 12 3.5.1. CRLF Keep alive Technique . . . . . . . . . . . . . . 12
3.5.2. STUN Keep alive Technique . . . . . . . . . . . . . . 12 3.5.2. STUN Keep alive Technique . . . . . . . . . . . . . . 12
4. User Agent Mechanisms . . . . . . . . . . . . . . . . . . . . 12 4. User Agent Mechanisms . . . . . . . . . . . . . . . . . . . . 12
4.1. Instance ID Creation . . . . . . . . . . . . . . . . . . 12 4.1. Instance ID Creation . . . . . . . . . . . . . . . . . . 12
4.2. Registrations . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Registrations . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Initial Registrations . . . . . . . . . . . . . . . . 14 4.2.1. Initial Registrations . . . . . . . . . . . . . . . . 14
4.2.2. Subsequent REGISTER requests . . . . . . . . . . . . . 15 4.2.2. Subsequent REGISTER requests . . . . . . . . . . . . . 16
4.2.3. Non Outbound Registrations . . . . . . . . . . . . . . 16 4.2.3. Non Outbound Registrations . . . . . . . . . . . . . . 16
4.3. Sending Non-REGISTER Requests . . . . . . . . . . . . . . 16 4.3. Sending Non-REGISTER Requests . . . . . . . . . . . . . . 16
4.4. Keep-alives and Detecting Flow Failure . . . . . . . . . 17 4.4. Keep-alives and Detecting Flow Failure . . . . . . . . . 17
4.4.1. Keep alive with CRLF . . . . . . . . . . . . . . . . . 18 4.4.1. Keep alive with CRLF . . . . . . . . . . . . . . . . . 18
4.4.2. Keep alive with STUN . . . . . . . . . . . . . . . . . 19 4.4.2. Keep alive with STUN . . . . . . . . . . . . . . . . . 19
4.5. Flow Recovery . . . . . . . . . . . . . . . . . . . . . . 20 4.5. Flow Recovery . . . . . . . . . . . . . . . . . . . . . . 20
5. Edge Proxy Mechanisms . . . . . . . . . . . . . . . . . . . . 21 5. Edge Proxy Mechanisms . . . . . . . . . . . . . . . . . . . . 21
5.1. Processing Register Requests . . . . . . . . . . . . . . 21 5.1. Processing Register Requests . . . . . . . . . . . . . . 21
5.2. Generating Flow Tokens . . . . . . . . . . . . . . . . . 21 5.2. Generating Flow Tokens . . . . . . . . . . . . . . . . . 21
5.3. Forwarding Non-REGISTER Requests . . . . . . . . . . . . 22 5.3. Forwarding Non-REGISTER Requests . . . . . . . . . . . . 22
5.3.1. Processing Incoming Requests . . . . . . . . . . . . . 22 5.3.1. Processing Incoming Requests . . . . . . . . . . . . . 22
5.3.2. Processing Outgoing Requests . . . . . . . . . . . . . 23 5.3.2. Processing Outgoing Requests . . . . . . . . . . . . . 23
5.4. Edge Proxy Keep alive Handling . . . . . . . . . . . . . 23 5.4. Edge Proxy Keep alive Handling . . . . . . . . . . . . . 23
6. Registrar Mechanisms . . . . . . . . . . . . . . . . . . . . . 23 6. Registrar Mechanisms . . . . . . . . . . . . . . . . . . . . . 23
7. Authoritative Proxy Mechanisms: Forwarding Requests . . . . . 25 7. Authoritative Proxy Mechanisms: Forwarding Requests . . . . . 25
8. STUN Keep alive Processing . . . . . . . . . . . . . . . . . . 26 8. STUN Keep alive Processing . . . . . . . . . . . . . . . . . . 26
8.1. Use with Sigcomp . . . . . . . . . . . . . . . . . . . . 27 8.1. Use with Sigcomp . . . . . . . . . . . . . . . . . . . . 28
9. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 28 9. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 28
9.1. Subscription to configuration package . . . . . . . . . . 28 9.1. Subscription to configuration package . . . . . . . . . . 28
9.2. Registration . . . . . . . . . . . . . . . . . . . . . . 30 9.2. Registration . . . . . . . . . . . . . . . . . . . . . . 30
9.3. Incoming call and proxy crash . . . . . . . . . . . . . . 33 9.3. Incoming call and proxy crash . . . . . . . . . . . . . . 33
9.4. Re-registration . . . . . . . . . . . . . . . . . . . . . 35 9.4. Re-registration . . . . . . . . . . . . . . . . . . . . . 36
9.5. Outgoing call . . . . . . . . . . . . . . . . . . . . . . 36 9.5. Outgoing call . . . . . . . . . . . . . . . . . . . . . . 36
10. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
11.1. Flow-Timer Header Field . . . . . . . . . . . . . . . . . 38 11.1. Flow-Timer Header Field . . . . . . . . . . . . . . . . . 38
11.2. 'reg-id' Contact Header Field Parameter . . . . . . . . . 39 11.2. 'reg-id' Contact Header Field Parameter . . . . . . . . . 39
11.3. SIP/SIPS URI Parameters . . . . . . . . . . . . . . . . . 39 11.3. SIP/SIPS URI Parameters . . . . . . . . . . . . . . . . . 39
11.4. SIP Option Tag . . . . . . . . . . . . . . . . . . . . . 39 11.4. SIP Option Tag . . . . . . . . . . . . . . . . . . . . . 39
11.5. 430 (Flow Failed) Response Code . . . . . . . . . . . . . 39 11.5. 430 (Flow Failed) Response Code . . . . . . . . . . . . . 39
11.6. 439 (First Hop Lacks Outbound Support) Response Code . . 40 11.6. 439 (First Hop Lacks Outbound Support) Response Code . . 40
11.7. Media Feature Tag . . . . . . . . . . . . . . . . . . . . 40 11.7. Media Feature Tag . . . . . . . . . . . . . . . . . . . . 40
skipping to change at page 4, line 42 skipping to change at page 4, line 42
datagrams, a TCP connection, or an analogous concept in another datagrams, a TCP connection, or an analogous concept in another
transport protocol--to forward any incoming requests that need to go transport protocol--to forward any incoming requests that need to go
to this UA in the context of the registration or dialog. 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 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 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 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 when a flow fails. Since such detection takes time and leaves a
window of opportunity for missed incoming requests, this mechanism window of opportunity for missed incoming requests, this mechanism
allows the UA to register over multiple flows at the same time. This allows the UA to register over multiple flows at the same time. This
specification also defines multiple keep alive schemes. The keep specification also defines two keep alive schemes. The keep alive
alive mechanism is used to keep NAT bindings fresh, and to allow the mechanism is used to keep NAT bindings fresh, and to allow the UA to
UA to detect when a flow has failed. detect when a 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 [RFC2119]. document are to be interpreted as described in [RFC2119].
2.1. Definitions 2.1. Definitions
Authoritative Proxy: A proxy that handles non-REGISTER requests for Authoritative Proxy: A proxy that handles non-REGISTER requests for
a specific Address-of-Record (AOR), performs the logical Location a specific Address-of-Record (AOR), performs the logical Location
Server lookup described in RFC 3261, and forwards those requests Server lookup described in RFC 3261, and forwards those requests
to specific Contact URIs. (In RFC 3261, the role which is to specific Contact URIs. (In RFC 3261, the role which is
authoritative for REGISTER requests for a specific AOR is a authoritative for REGISTER requests for a specific AOR is a
Registration Server.) Registration Server.)
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 Authoritative Proxy. between the registering User Agent and the Authoritative Proxy.
The "first" edge proxy refers to the first edge proxy encountered The "first" edge proxy refers to the first edge proxy encountered
when a UA sends a request. when a UA sends a request.
Flow: A Flow is a network protocol layer (layer 4) association Flow: A Flow is a network transport layer association between two
between two hosts that is represented by the network address and hosts that is represented by the network address and port number
port number of both ends and by the protocol. For TCP, a flow is of both ends and by the protocol. For TCP, a flow is equivalent
equivalent to a TCP connection. For UDP a flow is a bidirectional to a TCP connection. For UDP a flow is a bidirectional stream of
stream of datagrams between a single pair of IP addresses and datagrams between a single pair of IP addresses and ports of both
ports of both peers. With TCP, a flow often has a one to one peers. With TCP, a flow often has a one to one correspondence
correspondence with a single file descriptor in the operating with a single file descriptor in the operating system.
system.
Flow Token: An identifier which uniquely identifies a flow which can Flow Token: An identifier which uniquely identifies a flow which can
be included in a SIP URI (Uniform Resource Identifier). be included in a SIP URI (Uniform Resource Identifier).
reg-id: This refers to the value of a new header field parameter reg-id: This refers to the value of a new header field parameter
value for the Contact header field. When a UA registers multiple value for the Contact header field. When a UA registers multiple
times, each concurrent registration gets a unique reg-id value. 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 instance-id: This specification uses the word instance-id to refer
to the value of the "sip.instance" media feature tag in the to the value of the "sip.instance" media feature tag in the
Contact header field. This is a Uniform Resource Name (URN) that Contact header field. This is a Uniform Resource Name (URN) that
uniquely identifies this specific UA instance. uniquely identifies this specific UA instance.
'ob' Parameter: The 'ob' parameter is a SIP URI parameter which has 'ob' Parameter: The 'ob' parameter is a SIP URI parameter which has
different meaning depending on context. In a Path header field different meaning depending on context. In a Path header field
value it is used by the first edge proxy to indicate that a flow 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 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 value it indicates that the UA would like other requests in the
same dialog routed over the same flow. same dialog routed over the same flow.
skipping to change at page 11, line 41 skipping to change at page 11, line 41
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.5 to provide congestion back-off mechanism described in Section 4.5 to provide congestion
relief when a large number of agents simultaneously reboot. relief when a large number of agents simultaneously reboot.
A keep alive mechanism needs to keep NAT bindings refreshed; for A keep alive mechanism needs to keep NAT bindings refreshed; for
connections, it also needs to detect failure of a connection; and for connections, it also needs to detect failure of a connection; and for
connectionless transports, it needs to detect flow failures including connectionless transports, it needs to detect flow failures including
changes to the NAT public mapping. For connection oriented changes to the NAT public mapping. For connection oriented
transports such as TCP [RFC0793] and SCTP [RFC4966], this transports such as TCP [RFC0793] and SCTP [RFC4960], this
specification describes a keep alive approach based on sending CRLFs. specification describes a keep alive approach based on sending CRLFs.
For connectionless transport, such as UDP [RFC0768], this For connectionless transport, such as UDP [RFC0768], this
specification describes using STUN [I-D.ietf-behave-rfc3489bis] over specification describes using STUN [I-D.ietf-behave-rfc3489bis] over
the same flow as the SIP traffic to perform the keepalive. the same flow as the SIP traffic to perform the keepalive.
UAs and Proxies are also free to use native transport keep alives, 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- however the application may not be able to set these timers on a per-
connection basis, and the server certainly cannot make any assumption connection basis, and the server certainly cannot make any assumption
about what values are used. Use of native transport keep alives is about what values are used. Use of native transport keep alives is
outside the scope of this document. outside the scope of this document.
skipping to change at page 12, line 27 skipping to change at page 12, line 27
3.5.2. STUN Keep alive Technique 3.5.2. STUN Keep alive Technique
This approach can only be used for connection-less transports, such This approach can only be used for connection-less transports, such
as UDP. as UDP.
For connection-less transports, a flow definition could change For connection-less transports, a flow definition could change
because a NAT device in the network path reboots and the resulting because a NAT device in the network path reboots and the resulting
public IP address or port mapping for the UA changes. To detect 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 this, STUN requests are sent over the same flow that is being used
for the SIP traffic. The proxy or registrar acts as a Session for the SIP traffic. The proxy or registrar acts as a limited
Traversal Utilities for NAT (STUN) [I-D.ietf-behave-rfc3489bis] Session Traversal Utilities for NAT (STUN)
server on the SIP signaling port. [I-D.ietf-behave-rfc3489bis] 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, but of a changed IP address and port. Many other options were
the SIP Working Group selected the STUN-based approach. considered, but the SIP Working Group selected the STUN-based
Approaches using SIP requests were abandoned because many believed approach. Approaches using SIP requests were abandoned because
that good performance and full backwards compatibility using this many believed that good performance and full backwards
method were mutually exclusive. compatibility using this method were mutually exclusive.
4. User Agent Mechanisms 4. User Agent Mechanisms
4.1. Instance ID Creation 4.1. Instance ID Creation
Each UA MUST have an Instance Identifier Uniform Resource Name (URN) Each UA MUST have an Instance Identifier Uniform Resource Name (URN)
[RFC2141] that uniquely identifies the device. Usage of a URN [RFC2141] that uniquely identifies the device. Usage of a URN
provides a persistent and unique name for the UA instance. It also provides a persistent and unique name for the UA instance. It also
provides an easy way to guarantee uniqueness within the AOR. This provides an easy way to guarantee uniqueness within the AOR. This
URN MUST be persistent across power cycles of the device. The URN MUST be persistent across power cycles of the device. The
skipping to change at page 13, line 25 skipping to change at page 13, line 25
in Section 3.2) is perfectly legal as long as the device knows no in Section 3.2) is perfectly legal as long as the device knows no
other UUIDs were generated at this time on this device. other UUIDs were generated at this time on this device.
If a URN scheme other than UUID is used, the UA MUST only use URNs If a URN scheme other than UUID is used, the UA MUST only use URNs
for which an IETF consensus RFC defines how the specific URN needs to for which an IETF consensus RFC defines how the specific URN needs to
be constructed and used in the sip.instance Contact parameter for be constructed and used in the sip.instance Contact parameter for
outbound behavior. outbound behavior.
To convey its instance-id in both requests and responses, the UA To convey its instance-id in both requests and responses, the UA
includes a "sip.instance" media feature tag as a UA characteristic includes a "sip.instance" media feature tag as a UA characteristic
[RFC3840] . As described in [RFC3840], this media feature tag will [RFC3840] . This media feature tag is encoded in the Contact header
be encoded in the Contact header field as the "+sip.instance" Contact field as the "+sip.instance" Contact header field parameter. One
header field parameter. One case where a UA may not want to include case where a UA may not want to include the sip.instance media
the sip.instance media feature tag at all is when it is making an feature tag at all is when it is making an anonymous request or some
anonymous request or some other privacy concern requires that the UA other privacy concern requires that the UA not reveal its identity.
not reveal its identity.
[RFC3840] defines equality rules for callee capabilities [RFC3840] defines equality rules for callee capabilities
parameters, and according to that specification, the parameters, and according to that specification, the
"sip.instance" media feature tag will be compared by case- "sip.instance" media feature tag will be compared by case-
sensitive string comparison. This means that the URN will be sensitive string comparison. This means that the URN will be
encapsulated by angle brackets ("<" and ">") when it is placed encapsulated by angle brackets ("<" and ">") when it is placed
within the quoted string value of the +sip.instance Contact header within the quoted string value of the +sip.instance Contact header
field parameter. The case-sensitive matching rules apply only to field parameter. The case-sensitive matching rules apply only to
the generic usages defined in the callee capabilities [RFC3841] the generic usages defined in the callee capabilities [RFC3841]
and the caller preferences [RFC3841] specifications. When the and the caller preferences [RFC3841] specifications. When the
skipping to change at page 14, line 23 skipping to change at page 14, line 22
At configuration time, UAs obtain one or more SIP URIs representing At configuration time, UAs obtain one or more SIP URIs representing
the default outbound-proxy-set. This specification assumes the set the default outbound-proxy-set. This specification assumes the set
is determined via any of a number of configuration mechanisms, and is determined via any of a number of configuration mechanisms, and
future specifications can define additional mechanisms such as using future specifications can define additional mechanisms such as using
DNS to discover this set. How the UA is configured is outside the DNS to discover this set. How the UA is configured is outside the
scope of this specification. However, a UA MUST support sets with at scope of this specification. However, a UA MUST support sets with at
least two outbound proxy URIs and SHOULD support sets with up to four least two outbound proxy URIs and SHOULD support sets with up to four
URIs. URIs.
For each outbound proxy URI in the set, the UAC SHOULD send a For each outbound proxy URI in the set, the UAC SHOULD send a
REGISTER request using this URI as the default outbound proxy. (The REGISTER request using this URI as the default outbound proxy.
UA could limit the number of flows formed to conserve battery power, (Alternatively, the UA could limit the number of flows formed to
for example). UAs that support this specification MUST include the conserve battery power, for example). If the set has more than one
outbound option tag in a Supported header field in a REGISTER URI, the UAC MUST send a REGISTER request to at least two of the
request. Each of these REGISTER requests will use a unique Call-ID. default outbound proxies from the set. UAs that support this
Forming the route set for the request is outside the scope of this specification MUST include the outbound option tag in a Supported
document, but typically results in sending the REGISTER such that the header field in a REGISTER request. Each of these REGISTER requests
topmost Route header field contains a loose route to the outbound will use a unique Call-ID. Forming the route set for the request is
proxy URI. outside the scope of this document, but typically results in sending
the REGISTER such that the topmost Route header field contains a
loose route to the outbound proxy URI.
Registration requests, other than those described in Section 4.2.3, Registration requests, other than those described in Section 4.2.3,
MUST include an instance-id media feature tag as specified in MUST include an instance-id media feature tag as specified in
Section 4.1. Section 4.1.
These registration requests include a distinct reg-id parameter in For registration requests in accordance to this specification, the UA
the Contact header field. Each one of these registrations will form MUST include a distinct reg-id parameter in the Contact header field.
a new flow from the UA to the proxy. The sequence of reg-id values Each one of these registrations will form a new flow from the UA to
does not have to be sequential but MUST be exactly the same sequence the proxy. The sequence of reg-id values does not have to be
of reg-id values each time the UA instance power cycles or reboots so sequential but MUST be exactly the same sequence of reg-id values
that the reg-id values will collide with the previously used reg-id each time the UA instance power cycles or reboots so that the reg-id
values. This is so the registrar can replace the older values will collide with the previously used reg-id values. This is
registrations. so the registrar can replace the older registrations.
The UAC can situationally decide whether to request outbound The UAC can situationally decide whether to request outbound
behavior by including or omitting the 'reg-id' parameter. For behavior by including or omitting the 'reg-id' parameter. For
example, imagine the outbound-proxy-set contains two proxies in example, imagine the outbound-proxy-set contains two proxies in
different domains, EP1 and EP2. If an outbound-style registration different domains, EP1 and EP2. If an outbound-style registration
succeeded for a flow through EP1, the UA might decide to include succeeded for a flow through EP1, the UA might decide to include
'outbound' in its Require header field when registering with EP2, 'outbound' in its Require header field when registering with EP2,
in order to insure consistency. Similarly, if the registration in order to insure consistency. Similarly, if the registration
through EP1 did not support outbound, the UA might not register through EP1 did not support outbound, the UA might not register
with EP2 at all. with EP2 at all.
skipping to change at page 15, line 42 skipping to change at page 15, line 43
UA is expected to wait the indicated amount of time and retry the UA is expected to wait the indicated amount of time and retry the
registration. A Retry-After header field value of 0 is valid and registration. A Retry-After header field value of 0 is valid and
indicates the UA is expected to retry the REGISTER immediately. indicates the UA is expected to 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.
If the registering UA receives a 439 (First Hop Lacks Outbound If the registering UA receives a 439 (First Hop Lacks Outbound
Support) response to a REGISTER request, it MAY re-attempt Support) response to a REGISTER request, it MAY re-attempt
registration without an outbound proxy (subject to local policy at registration without using the outbound mechanism (subject to local
the client). If the client has one or more alternate outbound policy at the client). If the client has one or more alternate
proxies available, it MAY re-attempt registration through such outbound proxies available, it MAY re-attempt registration through
outbound proxies. See Section 11.6 for more information on the 439 such outbound proxies. See Section 11.6 for more information on the
response code. 439 response code.
4.2.2. Subsequent REGISTER requests 4.2.2. Subsequent REGISTER requests
Re-registrations and single Contact de-registrations use the same Re-registrations and single Contact de-registrations use the same
instance-id and reg-id values as the corresponding initial instance-id and reg-id values as the corresponding initial
registration. Re-registrations which merely refresh an existing registration. Re-registrations which merely refresh an existing
valid registration are sent over the same flow as the original valid registration are sent over the same flow as the original
registration. registration.
If a re-registration is rejected with a recoverable error response, If a re-registration is rejected with a recoverable error response,
skipping to change at page 17, line 30 skipping to change at page 17, line 35
NATs rebooting and Edge Proxies crashing. NATs rebooting and Edge Proxies crashing.
As described in Section 4.2, a UA that registers will begin sending As described in Section 4.2, a UA that registers will begin sending
keepalives after an appropriate registration response. A UA that keepalives after an appropriate registration response. A UA that
does not register (for example, a PSTN gateway behind a firewall) can does not register (for example, a PSTN gateway behind a firewall) can
also send keepalives under certain circumstances. also send keepalives under certain circumstances.
Under specific circumstances, a UAC might be allowed to send STUN Under specific circumstances, a UAC might be allowed to send STUN
keep alives even if the procedures in Section 4.2 were not completed, keep alives even if the procedures in Section 4.2 were not completed,
provided that there is an explicit indication that the target first provided that there is an explicit indication that the target first
hop SIP note supports STUN keep alives. This applies for example to hop SIP node supports STUN keep alives. This applies for example to
a non-registering UA or to a case where the UA registration a non-registering UA or to a case where the UA registration
succeeded, but the response did not include the outbound option-tag succeeded, but the response did not include the outbound option-tag
in the Require header field. in the Require header field.
Note that a UA can "always" send a double CRLF (a "ping") over Note that a UA can "always" send a double CRLF (a "ping") over
connection-oriented transports as this is already allowed by connection-oriented transports as this is already allowed by Section
[RFC3261]. Section 7.5, however a UA that did not register using 7.5/[RFC3261], However a UA that did not register using outbound
outbound registration cannot expect a CRLF in response (a "pong") registration cannot expect a CRLF in response (a "pong") unless the
unless the UA has an explicit indication that CRLF keepalives are UA has an explicit indication that CRLF keepalives are supported as
supported as described in this section. Likewise, a UA that did not described in this section. Likewise, a UA that did not successfully
successfully register with outbound procedures needs explicit register with outbound procedures needs explicit indication that the
indication that the target first hop SIP node supports STUN target first hop SIP node supports STUN keepalives before it can send
keepalives before it can send any STUN messages. any STUN messages.
Configuration indicating keepalive support for a specific target is A configuration option indicating keepalive support for a specific
considered an explicit indication. If these conditions are target is considered an explicit indication. If these conditions are
satisfied, the UA sends its keepalives according to the same satisfied, the UA sends its keepalives according to the same
guidelines described in the rest of this section as UAs which guidelines described in the rest of this section as UAs which
register. register.
The UA needs to detect when a specific flow fails. The UA actively The UA needs to detect when a specific flow fails. The UA actively
tries to detect failure by periodically sending keep alive messages tries to detect failure by periodically sending keep alive messages
using one of the techniques described in Section 4.4.1 or using one of the techniques described in Section 4.4.1 or
Section 4.4.2. If a flow with a registration has failed, the UA Section 4.4.2. If a flow with a registration has failed, the UA
follows the procedures in Section 4.2 to form a new flow to replace follows the procedures in Section 4.2 to form a new flow to replace
the failed one. the failed one.
skipping to change at page 18, line 37 skipping to change at page 18, line 41
the URI from the outbound-proxy-set to pick a transport. Once a the URI from the outbound-proxy-set to pick a transport. Once a
transport is selected, the UA selects the keep alive approach that is transport is selected, the UA selects the keep alive approach that is
recommended for that transport. recommended for that transport.
4.4.1. Keep alive with CRLF 4.4.1. Keep alive with CRLF
This approach MUST only be used with connection oriented transports This approach MUST only be used with connection oriented transports
such as TCP or SCTP. such as TCP or SCTP.
A User Agent that forms flows, checks if the configured URI to which A User Agent that forms flows, checks if the configured URI to which
the UA is connecting resolves to a stream-based transport (ex: TCP the UA is connecting resolves to a connection-oriented transport (ex:
and TLS over TCP). TCP and TLS over TCP).
For this mechanism, the client "ping" is a double-CRLF sequence, and For this mechanism, the client "ping" is a double-CRLF sequence, and
the server "pong" is a single CRLF, as defined in the ABNF below: the server "pong" is a single CRLF, as defined in the ABNF below:
CRLF = CR LF CRLF = CR LF
double-CRLF = CR LF CR LF double-CRLF = CR LF CR LF
CR = 0x0d CR = 0x0d
LF = 0x0a LF = 0x0a
The ping and pong need to be sent between SIP messages and cannot be The ping and pong need to be sent between SIP messages and cannot be
sent in the middle of a SIP message. If sending over TLS, the CRLFs sent in the middle of a SIP message. If sending over TLS, the CRLFs
are sent inside the TLS protected channel. If sending over a SigComp are sent inside the TLS protected channel. If sending over a SigComp
[RFC3320] compressed data stream, the CRLF keep alives are sent [RFC3320] compressed data stream, the CRLF keep alives are sent
inside the compressed stream. The double CRLF is considered a single inside the compressed stream. The double CRLF is considered a single
SigComp message. The specific mechanism for representing these SigComp message. The specific mechanism for representing these
characters is an implementation specific matter to be handled by the characters is an implementation specific matter to be handled by the
SigComp compressor at the sending end. SigComp compressor at the sending end.
If a pong is not received within 10 seconds then the client MUST If a pong is not received within 10 seconds then the client MUST
skipping to change at page 19, line 13 skipping to change at page 19, line 17
[RFC3320] compressed data stream, the CRLF keep alives are sent [RFC3320] compressed data stream, the CRLF keep alives are sent
inside the compressed stream. The double CRLF is considered a single inside the compressed stream. The double CRLF is considered a single
SigComp message. The specific mechanism for representing these SigComp message. The specific mechanism for representing these
characters is an implementation specific matter to be handled by the characters is an implementation specific matter to be handled by the
SigComp compressor at the sending end. SigComp compressor at the sending end.
If a pong is not received within 10 seconds then the client MUST If a pong is not received within 10 seconds then the client MUST
treat the flow as failed. Clients MUST support this CRLF keep alive. treat the flow as failed. Clients MUST support this CRLF keep alive.
The proper selection of keepalive frequency is primarily a trade-off The proper selection of keepalive frequency is primarily a trade-off
between battery usage and availability. For devices where power is between battery usage and availability. The UA MUST select a random
not a significant concern, the UA SHOULD select a random number number between a fixed or configurable upper bound and a lower bound,
between 95 and 120 seconds between keepalives. When battery power is where the lower bound is 20% less then the upper bound. The fixed
a concern, the UA SHOULD select a random number between 672 and 840 upper bound or the default configurable upper bound SHOULD be 120
seconds (14 minutes). These times MAY be configurable. To clarify, seconds (95 seconds lower bound) where battery power is not a concern
the random number will be different for each keepalive ping. and 840 seconds (672 seconds lower bound) where battery power is a
concern. The random number will be different for each keepalive
ping.
Note on selection of time values: the 120 seconds upper bound was Note on selection of time values: the 120 seconds upper bound was
chosen based on the idea that for a good user experience, failures chosen based on the idea that for a good user experience, failures
normally will be detected in this amount of time and a new normally will be detected in this amount of time and a new
connection set up. The 14 minute upper-bound for battery-powered connection set up. The 14 minute upper-bound for battery-powered
devices was selected based on NATs with TCP timeouts as low as 15 devices was selected based on NATs with TCP timeouts as low as 15
minutes. Operators that wish to change the relationship between minutes. Operators that wish to change the relationship between
load on servers and the expected time that a user might not load on servers and the expected time that a user might 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
skipping to change at page 20, line 33 skipping to change at page 20, line 39
The amount of time to wait depends if the previous attempt at The amount of time to wait depends if the previous attempt at
establishing a flow was successful. For the purposes of this establishing a flow was successful. For the purposes of this
section, a flow is considered successful if outbound registration section, a flow is considered successful if outbound registration
succeeded, and if keep alives are in use on this flow, at least one succeeded, and if keep alives are in use on this flow, at least one
subsequent keep alive response was received. subsequent keep alive response was received.
The number of seconds to wait is computed in the following way. If The number of seconds to wait is computed in the following way. If
all of the flows to every URI in the outbound proxy set have failed, all of the flows to every URI in the outbound proxy set have failed,
the base-time is set to 30 seconds; otherwise, in the case where at the base-time is set to 30 seconds; otherwise, in the case where at
least one of the flows has not failed, the base-time is set to 90 least one of the flows has not failed, the base-time is set to 90
seconds. The wait time is computed by taking two raised to the power seconds. The upper-bound wait time (W) is computed by taking two
of the number of consecutive registration failures for that URI, and raised to the power of the number of consecutive registration
multiplying this by the base time, up to a maximum of 1800 seconds. failures for that URI, and multiplying this by the base time, up to a
maximum of 1800 seconds.
wait-time = min( max-time, (base-time * (2 ^ consecutive-failures))) W = min( max-time, (base-time * (2 ^ consecutive-failures)))
These times MAY be configurable in the UA. The three times are: These times MAY be configurable in the UA. The three times are:
o max-time with a default of 1800 seconds o max-time with a default of 1800 seconds
o base-time (if all failed) with a default of 30 seconds o base-time (if all failed) with a default of 30 seconds
o base-time (if all have not failed) with a default of 90 seconds o base-time (if all have not failed) with a default of 90 seconds
For example, if the base time is 30 seconds, and there were three For example, if the base time is 30 seconds, and there were three
failures, then the wait time is min(1800,30*(2^3)) or 240 seconds. failures, then the upper-bound wait time is min(1800,30*(2^3)) or 240
The delay time is computed by selecting a uniform random time between seconds. The actual amount of time the UA waits before retrying
50 and 100 percent of the wait time. The UA MUST wait for the value registration (the retry delay time) is computed by selecting a
of the delay time before trying another registration to form a new uniform random time between 50 and 100 percent of the upper-bound
flow for that URI. wait time. The UA MUST wait for the value of the retry delay time
before trying another registration to form a new flow for that URI.
To be explicitly clear on the boundary conditions: when the UA boots 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 maximum of 1800 seconds is reached, the UA will keep trying
indefinitely with a random time of 15 to 30 minutes between each indefinitely with a random time of 15 to 30 minutes between each
attempt. attempt.
skipping to change at page 24, line 8 skipping to change at page 24, line 16
Registrars which implement this specification MUST support the Path Registrars which implement this specification MUST support the Path
header mechanism [RFC3327]. header mechanism [RFC3327].
When receiving a REGISTER request, the registrar MUST check from its When receiving a REGISTER request, the registrar MUST check from its
Via header field if the registrar is the first hop or not. If the Via header field if the registrar is the first hop or not. If the
registrar is not the first hop, it MUST examine the Path header of registrar is not the first hop, it MUST examine the Path header of
the request. If the Path header field is missing or it exists but the request. If the Path header field is missing or it exists but
the first URI does not have an 'ob' URI parameter, then outbound the first URI does not have an 'ob' URI parameter, then outbound
processing MUST NOT be applied to the registration. In this case, processing MUST NOT be applied to the registration. In this case,
the following processing applies: if the REGISTER request contains the following processing applies: if the REGISTER request contains
the "outbound" option tag in a "Require" header field, then the the a 'reg-id' and the 'outbound' option tag in a 'Supported' header
registrar MUST respond to the REGISTER request with a 439 (First Hop field, then the registrar MUST respond to the REGISTER request with a
Lacks Outbound Support) response; otherwise, the registrar MUST 439 (First Hop Lacks Outbound Support) response; otherwise, the
ignore the reg-id parameter of the Contact header. See Section 11.6 registrar MUST ignore the reg-id parameter of the Contact header.
for more information on the 439 response code. See Section 11.6 for more information on the 439 response code.
A Contact header field value with an instance-id but no reg-id is A Contact header field value with an instance-id but no reg-id is
valid (this combination can be used in the GRUU [I-D.ietf-sip-gruu] valid (this combination can be used in the GRUU [I-D.ietf-sip-gruu]
specification), but one with a reg-id but no instance-id is not. If specification), but one with a reg-id but no instance-id is not. If
the registrar processes a Contact header field value with a reg-id the registrar processes a Contact header field value with a reg-id
but no instance-id, it simply ignores the reg-id parameter. but no instance-id, it simply ignores the reg-id parameter.
A registration containing a reg-id parameter and a non-zero A registration containing a reg-id parameter and a non-zero
expiration is used to register a single UA instance over a single expiration is used to register a single UA instance over a single
flow, and can also de-register any Contact header fields with zero flow, and can also de-register any Contact header fields with zero
skipping to change at page 24, line 45 skipping to change at page 25, line 5
The registrar MUST be prepared to receive, simultaneously for the The registrar MUST be prepared to receive, simultaneously for the
same AOR, some registrations that use instance-id and reg-id and some same AOR, some registrations that use instance-id and reg-id and some
registrations that do not. The Registrar MAY be configured with registrations that do not. The Registrar MAY be configured with
local policy to reject any registrations that do not include the local policy to reject any registrations that do not include the
instance-id and reg-id, or with Path header field values that do not instance-id and reg-id, or with Path header field values that do not
contain the 'ob' parameter. If the Contact header field does not contain the 'ob' parameter. If the Contact header field does not
contain a '+sip.instance' media feature parameter, the registrar contain a '+sip.instance' media feature parameter, the registrar
processes the request using the Contact binding rules in [RFC3261]. processes the request using the Contact binding rules in [RFC3261].
When a '+sip.instance' media feature parameter is present in a When a '+sip.instance' media feature parameter and a reg-id parameter
Contact header field of a REGISTER request (after the Contact header are present in a Contact header field of a REGISTER request (after
validation as described above), the corresponding binding is between the Contact header validation as described above), the corresponding
an AOR and the combination of the instance-id (from the +sip.instance binding is between an AOR and the combination of the instance-id
media feature parameter) and the value of reg-id parameter if it is (from the +sip.instance media feature parameter) and the value of
present. The registrar MUST store in the binding the Contact URI, reg-id parameter. The registrar MUST store in the binding the
all the Contact head field parameters, and any Path header field Contact URI, all the Contact head field parameters, and any Path
values. (Even though the Contact URI is not used for binding header field values. (Even though the Contact URI is not used for
comparisons, it is still needed by the authoritative proxy to form binding comparisons, it is still needed by the authoritative proxy to
the target set.) The Registrar MUST include the 'outbound' option- form the target set.) The Registrar MUST include the 'outbound'
tag (defined in Section 11.2) in a Require header field value in its option-tag (defined in Section 11.2) in a Require header field value
response to the REGISTER request. in its response to the REGISTER request.
If the UAC has a direct flow with the registrar, the registrar MUST If the UAC has a direct flow with the registrar, the registrar MUST
store enough information to uniquely identify the network flow over store enough information to uniquely identify the network flow over
which the request arrived. For common operating systems with TCP, which the request arrived. For common operating systems with TCP,
this would typically just be the handle to the file descriptor where this would typically just be the handle to the file descriptor where
the handle would become invalid if the TCP session was closed. For the handle would become invalid if the TCP session was closed. For
common operating systems with UDP this would typically be the file common operating systems with UDP this would typically be the file
descriptor for the local socket that received the request, the local descriptor for the local socket that received the request, the local
interface, and the IP address and port number of the remote side that interface, and the IP address and port number of the remote side that
sent the request. The registrar MAY store this information by adding sent the request. The registrar MAY store this information by adding
skipping to change at page 29, line 19 skipping to change at page 29, line 19
2)| |---SUBSCRIBE Event: ua-profile ->| 2)| |---SUBSCRIBE Event: ua-profile ->|
3)| |<--200 OK -----------------------| 3)| |<--200 OK -----------------------|
4)|<--200 OK--| | | | 4)|<--200 OK--| | | |
5)| |<--NOTIFY------------------------| 5)| |<--NOTIFY------------------------|
6)|<--NOTIFY--| | | | 6)|<--NOTIFY--| | | |
7)|---200 OK->| | | | 7)|---200 OK->| | | |
8)| |---200 OK ---------------------->| 8)| |---200 OK ---------------------->|
| | | | | | | | | |
Example Message #1: Example Message #1:
SUBSCRIBE sip:00000000-0000-1000-8000-AABBCCDDEEFF@example.com SIP/2.0
SUBSCRIBE sip:00000000-0000-1000-8000-AABBCCDDEEFF@example.com
SIP/2.0
Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnlsdkdj2 Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnlsdkdj2
Max-Forwards: 70 Max-Forwards: 70
From: <anonymous@example.com>;tag=23324 From: <anonymous@example.com>;tag=23324
To: <sip:00000000-0000-1000-8000-AABBCCDDEEFF@example.com> To: <sip:00000000-0000-1000-8000-AABBCCDDEEFF@example.com>
Call-ID: nSz1TWN54x7My0GvpEBj Call-ID: nSz1TWN54x7My0GvpEBj
CSeq: 1 SUBSCRIBE CSeq: 1 SUBSCRIBE
Event: ua-profile ;profile-type=device Event: ua-profile ;profile-type=device
;vendor="example.com";model="uPhone";version="1.1" ;vendor="example.com";model="uPhone";version="1.1"
Expires: 0 Expires: 0
Supported: path, outbound Supported: path, outbound
skipping to change at page 32, line 7 skipping to change at page 32, line 8
and includes the 'ob' parameter. and includes the 'ob' parameter.
Path: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob> Path: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob>
Since the response to the REGISTER (message #11) contains the Since the response to the REGISTER (message #11) contains the
outbound option-tag in the Require header field, Bob's UA will know outbound option-tag in the Require header field, Bob's UA will know
that the registrar used outbound binding rules. The response also that the registrar used outbound binding rules. The response also
contains the currently active Contacts, the Path for the current contains the currently active Contacts, the Path for the current
registration. registration.
Message #11
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.0.2.15;branch=z9hG4bKnuiqisi Via: SIP/2.0/TCP 192.0.2.15;branch=z9hG4bKnuiqisi
Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7 Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7
From: Bob <sip:bob@example.com>;tag=7F94778B653B From: Bob <sip:bob@example.com>;tag=7F94778B653B
To: Bob <sip:bob@example.com>;tag=6AF99445E44A To: Bob <sip:bob@example.com>;tag=6AF99445E44A
Call-ID: 16CB75F21C70 Call-ID: 16CB75F21C70
CSeq: 1 REGISTER CSeq: 1 REGISTER
Supported: path, outbound Supported: path, outbound
Require: outbound Require: outbound
Contact: <sip:bob@192.168.1.2;transport=tcp>;reg-id=1;expires=3600 Contact: <sip:bob@192.168.1.2;transport=tcp>;reg-id=1;expires=3600
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>" ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Path: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob> Path: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob>
Content-Length: 0 Content-Length: 0
The second registration through EP2 (message #13) is similar other The second registration through EP2 (message #13) is similar other
than the Call-ID has changed, the reg-id is 2, and the Route header than the Call-ID has changed, the reg-id is 2, and the Route header
goes through EP2. goes through EP2.
Message #13
REGISTER sip:example.com SIP/2.0 REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnqr9bym Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnqr9bym
Max-Forwards: 70 Max-Forwards: 70
From: Bob <sip:bob@example.com>;tag=755285EABDE2 From: Bob <sip:bob@example.com>;tag=755285EABDE2
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
Call-ID: E05133BD26DD Call-ID: E05133BD26DD
CSeq: 1 REGISTER CSeq: 1 REGISTER
Supported: path, outbound Supported: path, outbound
Route: <sip:ep2.example.com;lr> Route: <sip:ep2.example.com;lr>
Contact: <sip:bob@192.168.1.2;transport=tcp>;reg-id=2 Contact: <sip:bob@192.168.1.2;transport=tcp>;reg-id=2
skipping to change at page 33, line 5 skipping to change at page 33, line 5
Likewise in message #14, EP2 adds a Path header with flow token and Likewise in message #14, EP2 adds a Path header with flow token and
'ob' parameter. 'ob' parameter.
Path: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr;ob> Path: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr;ob>
Message #16 tells Bob's UA that outbound registration was successful, Message #16 tells Bob's UA that outbound registration was successful,
and shows both Contacts. Note that only the Path corresponding to and shows both Contacts. Note that only the Path corresponding to
the current registration is returned. the current registration is returned.
Message #16
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnqr9bym Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnqr9bym
From: Bob <sip:bob@example.com>;tag=755285EABDE2 From: Bob <sip:bob@example.com>;tag=755285EABDE2
To: Bob <sip:bob@example.com>;tag=49A9AD0B3F6A To: Bob <sip:bob@example.com>;tag=49A9AD0B3F6A
Call-ID: E05133BD26DD Call-ID: E05133BD26DD
Supported: path, outbound Supported: path, outbound
Require: outbound Require: outbound
CSeq: 1 REGISTER CSeq: 1 REGISTER
Contact: <sip:bob@192.168.1.2;transport=tcp>;reg-id=1;expires=3600 Contact: <sip:bob@192.168.1.2;transport=tcp>;reg-id=1;expires=3600
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>" ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
skipping to change at page 35, line 4 skipping to change at page 35, line 7
Call-ID: klmvCxVWGp6MxJp2T2mb Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE CSeq: 1 INVITE
Route: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr;ob> Route: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr;ob>
In message #25, EP2 needs to add a Record-Route header field value, In message #25, EP2 needs to add a Record-Route header field value,
so that any subsequent in-dialog messages from Alice's UA arrive at so that any subsequent in-dialog messages from Alice's UA arrive at
Bob's UA. EP2 can determine it needs to Record-Route since the Bob's UA. EP2 can determine it needs to Record-Route since the
request is a dialog-forming request and the Route header contained a request is a dialog-forming request and the Route header contained a
flow token and an 'ob' parameter. This Record-Route information is flow token and an 'ob' parameter. This Record-Route information is
passed back to Alice's UA in the responses (messages #26, 27, and 28) passed back to Alice's UA in the responses (messages #26, 27, and 28)
Message #25 Message #25
INVITE sip:bob@192.168.1.2;transport=tcp SIP/2.0 INVITE sip:bob@192.168.1.2;transport=tcp SIP/2.0
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
From: Alice <sip:alice@a.example>;tag=02935 From: Alice <sip:alice@a.example>;tag=02935
Call-ID: klmvCxVWGp6MxJp2T2mb Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE CSeq: 1 INVITE
Record-Route: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr> Record-Route:
<sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr>
Message #26 Message #26
SIP/2.0 200 OK SIP/2.0 200 OK
To: Bob <sip:bob@example.com>;tag=skduk2 To: Bob <sip:bob@example.com>;tag=skduk2
From: Alice <sip:alice@a.example>;tag=02935 From: Alice <sip:alice@a.example>;tag=02935
Call-ID: klmvCxVWGp6MxJp2T2mb Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE CSeq: 1 INVITE
Record-Route: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr> Record-Route:
<sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr>
At this point, both UAs have the correct route-set for the dialog. At this point, both UAs have the correct route-set for the dialog.
Any subsequent requests in this dialog will route correctly. For Any subsequent requests in this dialog will route correctly. For
example, the ACK request in message #29 is sent form Alice's UA example, the ACK request in message #29 is sent form Alice's UA
directly to EP2. The BYE request in message #31 uses the same route- directly to EP2. The BYE request in message #31 uses the same route-
set. set.
Message #29 Message #29
ACK sip:bob@192.168.1.2;transport=tcp SIP/2.0 ACK sip:bob@192.168.1.2;transport=tcp SIP/2.0
To: Bob <sip:bob@example.com>;tag=skduk2 To: Bob <sip:bob@example.com>;tag=skduk2
From: Alice <sip:alice@a.example>;tag=02935 From: Alice <sip:alice@a.example>;tag=02935
Call-ID: klmvCxVWGp6MxJp2T2mb Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 ACK CSeq: 1 ACK
Route: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr> Route: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr>
Message #31 Message #31
BYE sip:bob@192.168.1.2;transport=tcp SIP/2.0 BYE sip:bob@192.168.1.2;transport=tcp SIP/2.0
To: Bob <sip:bob@example.com>;tag=skduk2 To: Bob <sip:bob@example.com>;tag=skduk2
From: Alice <sip:alice@a.example>;tag=02935 From: Alice <sip:alice@a.example>;tag=02935
Call-ID: klmvCxVWGp6MxJp2T2mb Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 2 BYE CSeq: 2 BYE
Route: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr> Route: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr>
9.4. Re-registration 9.4. Re-registration
Somewhat later, Bob's UA sends keepalives to both its edge proxies, Somewhat later, Bob's UA sends keepalives to both its edge proxies,
skipping to change at page 37, line 33 skipping to change at page 37, line 34
INVITE sip:alice@a.example SIP/2.0 INVITE sip:alice@a.example SIP/2.0
From: Bob <sip:bob@example.com>;tag=ldw22z From: Bob <sip:bob@example.com>;tag=ldw22z
To: Alice <sip:alice@a.example> To: Alice <sip:alice@a.example>
Call-ID: 95KGsk2V/Eis9LcpBYy3 Call-ID: 95KGsk2V/Eis9LcpBYy3
CSeq: 1 INVITE CSeq: 1 INVITE
Route: <sip:ep1.example.com;lr> Route: <sip:ep1.example.com;lr>
Contact: <sip:bob@192.168.1.2;transport=tcp;ob> Contact: <sip:bob@192.168.1.2;transport=tcp;ob>
In message #43, EP1 adds the following Record-Route header. In message #43, EP1 adds the following Record-Route header.
Record-Route: <sip:3yJEbr1GYZK9cPYk5Snocez6DzO7w+AX@ep1.example.com;lr> Record-Route:
<sip:3yJEbr1GYZK9cPYk5Snocez6DzO7w+AX@ep1.example.com;lr>
When EP1 receives the BYE (message #50) from Bob's UA, it can tell When EP1 receives the BYE (message #50) from Bob's UA, it can tell
that the request is an "outgoing" request (since the source of the that the request is an "outgoing" request (since the source of the
request matches the flow in the flow token) and simply deletes its request matches the flow in the flow token) and simply deletes its
Route header field value and forwards the request on to Alice's UA. Route header field value and forwards the request on to Alice's UA.
Message #50 Message #50
BYE sip:alice@a.example SIP/2.0 BYE sip:alice@a.example SIP/2.0
From: Bob <sip:bob@example.com>;tag=ldw22z From: Bob <sip:bob@example.com>;tag=ldw22z
To: Alice <sip:alice@a.example>;tag=plqus8 To: Alice <sip:alice@a.example>;tag=plqus8
Call-ID: 95KGsk2V/Eis9LcpBYy3 Call-ID: 95KGsk2V/Eis9LcpBYy3
CSeq: 2 BYE CSeq: 2 BYE
Route: <sip:3yJEbr1GYZK9cPYk5Snocez6DzO7w+AX@ep1.example.com;lr> Route: <sip:3yJEbr1GYZK9cPYk5Snocez6DzO7w+AX@ep1.example.com;lr>
Contact: <sip:bob@192.168.1.2;transport=tcp;ob> Contact: <sip:bob@192.168.1.2;transport=tcp;ob>
10. Grammar 10. Grammar
skipping to change at page 40, line 21 skipping to change at page 40, line 21
11.6. 439 (First Hop Lacks Outbound Support) Response Code 11.6. 439 (First Hop Lacks Outbound Support) Response Code
This document registers a new SIP response code (439 First Hop Lacks This document registers a new SIP response code (439 First Hop Lacks
Outbound Support), as per the guidelines in Section 27.4 of Outbound Support), as per the guidelines in Section 27.4 of
[RFC3261]. This response code is used by a registrar to indicate [RFC3261]. This response code is used by a registrar to indicate
that it supports the 'outbound' feature described in this that it supports the 'outbound' feature described in this
specifcation, but that the first outbound proxy that the user is specifcation, but that the first outbound proxy that the user is
attempting to register through does not. Note that this response attempting to register through does not. Note that this response
code is only appropriate in the case that the registering user agent code is only appropriate in the case that the registering user agent
is mandating outbound processing by including the 'outbound' option advertises support for outbound processing by including the
tag in a 'Require' header field. Proxies MUST NOT send a 439 'outbound' option tag in a 'Supported' header field. Proxies MUST
response to any requests that don't contain an 'outbound' option tag NOT send a 439 response to any requests that do not contain a
in a 'Require' header field. This response code is defined by the 'reg-id' parameter and an 'outbound' option tag in a 'Supported'
following information, which has been added to the method and header field. This response code is defined by the following
response-code sub-registry under information, which has been added to the method and response-code
http://www.iana.org/assignments/sip-parameters. sub-registry under http://www.iana.org/assignments/sip-parameters.
Response Code Number: 439 Response Code Number: 439
Default Reason Phrase: First Hop Lacks Outbound Support Default Reason Phrase: First Hop Lacks Outbound Support
11.7. Media Feature Tag 11.7. 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 [RFC2506]. The tag is placed into the sip tree, which is defined in [RFC2506]. The tag is placed into the sip tree, which is
defined in [RFC3840]. defined in [RFC3840].
Media feature tag name: sip.instance Media feature tag name: sip.instance
skipping to change at page 48, line 11 skipping to change at page 48, line 11
Additionally, many of the concepts here originated at a connection Additionally, many of the concepts here originated at a connection
reuse meeting at IETF 60 that included the authors, Jon Peterson, reuse meeting at IETF 60 that included the authors, Jon Peterson,
Jonathan Rosenberg, Alan Hawrylyshen, and Paul Kyzivat. The TCP Jonathan Rosenberg, Alan Hawrylyshen, and Paul Kyzivat. The TCP
design team consisting of Chris Boulton, Scott Lawrence, Rajnish design team consisting of Chris Boulton, Scott Lawrence, Rajnish
Jain, Vijay K. Gurbani, and Ganesh Jayadevan provided input and text. Jain, Vijay K. Gurbani, and Ganesh Jayadevan provided input and text.
Nils Ohlmeier provided many fixes and initial implementation Nils Ohlmeier provided many fixes and initial implementation
experience. In addition, thanks to the following folks for useful experience. In addition, thanks to the following folks for useful
comments: Francois Audet, Flemming Andreasen, Mike Hammer, Dan Wing, comments: Francois Audet, Flemming Andreasen, Mike Hammer, Dan Wing,
Srivatsa Srinivasan, Dale Worely, Juha Heinanen, Eric Rescorla, Srivatsa Srinivasan, Dale Worely, Juha Heinanen, Eric Rescorla,
Lyndsay Campbell, Christer Holmberg, Kevin Johns, Jeroen van Bemmel, Lyndsay Campbell, Christer Holmberg, Kevin Johns, Jeroen van Bemmel,
and Derek MacDonald. Derek MacDonald and Dean Willis.
17. References 17. References
17.1. Normative References 17.1. Normative References
[I-D.ietf-behave-rfc3489bis] [I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for (NAT) (STUN)", "Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-15 (work in progress), draft-ietf-behave-rfc3489bis-15 (work in progress),
February 2008. February 2008.
skipping to change at page 50, line 6 skipping to change at page 50, line 6
(SIP)", draft-ietf-sip-gruu-15 (work in progress), (SIP)", draft-ietf-sip-gruu-15 (work in progress),
October 2007. October 2007.
[I-D.ietf-sipping-config-framework] [I-D.ietf-sipping-config-framework]
Channabasappa, S., "A Framework for Session Initiation Channabasappa, S., "A Framework for Session Initiation
Protocol User Agent Profile Delivery", Protocol User Agent Profile Delivery",
draft-ietf-sipping-config-framework-15 (work in progress), draft-ietf-sipping-config-framework-15 (work in progress),
February 2008. February 2008.
[I-D.ietf-sipping-nat-scenarios] [I-D.ietf-sipping-nat-scenarios]
Boulton, C., "Best Current Practices for NAT Traversal for Boulton, C., Rosenberg, J., and G. Camarillo, "Best
SIP", draft-ietf-sipping-nat-scenarios-07 (work in Current Practices for NAT Traversal for SIP",
progress), July 2007. draft-ietf-sipping-nat-scenarios-08 (work in progress),
April 2008.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. February 1997.
skipping to change at page 50, line 34 skipping to change at page 50, line 35
[RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H.,
Liu, Z., and J. Rosenberg, "Signaling Compression Liu, Z., and J. Rosenberg, "Signaling Compression
(SigComp)", RFC 3320, January 2003. (SigComp)", RFC 3320, January 2003.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
Address Translator - Protocol Translator (NAT-PT) to RFC 4960, September 2007.
Historic Status", RFC 4966, July 2007.
Appendix A. Default Flow Registration Backoff Times Appendix A. Default Flow Registration Backoff Times
The base-time used for the flow re-registration backoff times The base-time used for the flow re-registration backoff times
described in Section 4.5 are configurable. If the base-time-all-fail described in Section 4.5 are configurable. If the base-time-all-fail
value is set to the default of 30 seconds and the base-time-not- value is set to the default of 30 seconds and the base-time-not-
failed value is set to the default of 90 seconds, the following table failed value is set to the default of 90 seconds, the following table
shows the resulting delay values. shows the resulting amount of time the UA will wait to retry
registration.
+-------------------+--------------------+--------------------+ +-------------------+--------------------+--------------------+
| # of reg failures | all flows unusable | >1 non-failed flow | | # of reg failures | all flows unusable | >1 non-failed flow |
+-------------------+--------------------+--------------------+ +-------------------+--------------------+--------------------+
| 0 | 0 secs | 0 secs | | 0 | 0 secs | 0 secs |
| 1 | 30-60 secs | 90-180 secs | | 1 | 30-60 secs | 90-180 secs |
| 2 | 1-2 mins | 3-6 mins | | 2 | 1-2 mins | 3-6 mins |
| 3 | 2-4 mins | 6-12 mins | | 3 | 2-4 mins | 6-12 mins |
| 4 | 4-8 mins | 12-24 mins | | 4 | 4-8 mins | 12-24 mins |
| 5 | 8-16 mins | 15-30 mins | | 5 | 8-16 mins | 15-30 mins |
 End of changes. 45 change blocks. 
121 lines changed or deleted 143 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/