< draft-ietf-sip-outbound-19.txt   draft-ietf-sip-outbound-20.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) Unaffiliated (if approved) Unaffiliated
Intended status: Standards Track June 1, 2009 Intended status: Standards Track June 9, 2009
Expires: December 3, 2009 Expires: December 11, 2009
Managing Client Initiated Connections in the Session Initiation Protocol Managing Client Initiated Connections in the Session Initiation Protocol
(SIP) (SIP)
draft-ietf-sip-outbound-19 draft-ietf-sip-outbound-20
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 December 3, 2009. This Internet-Draft will expire on December 11, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 25 skipping to change at page 3, line 25
3.5. Keep alive Technique . . . . . . . . . . . . . . . . . . . 12 3.5. Keep alive Technique . . . . . . . . . . . . . . . . . . . 12
3.5.1. CRLF Keep alive Technique . . . . . . . . . . . . . . 13 3.5.1. CRLF Keep alive Technique . . . . . . . . . . . . . . 13
3.5.2. STUN Keep alive Technique . . . . . . . . . . . . . . 13 3.5.2. STUN Keep alive Technique . . . . . . . . . . . . . . 13
4. User Agent Procedures . . . . . . . . . . . . . . . . . . . . 13 4. User Agent Procedures . . . . . . . . . . . . . . . . . . . . 13
4.1. Instance ID Creation . . . . . . . . . . . . . . . . . . . 13 4.1. Instance ID Creation . . . . . . . . . . . . . . . . . . . 13
4.2. Registrations . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Registrations . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1. Initial Registrations . . . . . . . . . . . . . . . . 15 4.2.1. Initial Registrations . . . . . . . . . . . . . . . . 15
4.2.2. Subsequent REGISTER requests . . . . . . . . . . . . . 17 4.2.2. Subsequent REGISTER requests . . . . . . . . . . . . . 17
4.2.3. Third Party Registrations . . . . . . . . . . . . . . 17 4.2.3. Third Party Registrations . . . . . . . . . . . . . . 17
4.3. Sending Non-REGISTER Requests . . . . . . . . . . . . . . 17 4.3. Sending Non-REGISTER Requests . . . . . . . . . . . . . . 17
4.4. Keep-alives and Detecting Flow Failure . . . . . . . . . . 18 4.4. Keep alives and Detecting Flow Failure . . . . . . . . . . 18
4.4.1. Keep alive with CRLF . . . . . . . . . . . . . . . . . 20 4.4.1. Keep alive with CRLF . . . . . . . . . . . . . . . . . 20
4.4.2. Keep alive with STUN . . . . . . . . . . . . . . . . . 21 4.4.2. Keep alive with STUN . . . . . . . . . . . . . . . . . 21
4.5. Flow Recovery . . . . . . . . . . . . . . . . . . . . . . 22 4.5. Flow Recovery . . . . . . . . . . . . . . . . . . . . . . 22
5. Edge Proxy Procedures . . . . . . . . . . . . . . . . . . . . 23 5. Edge Proxy Procedures . . . . . . . . . . . . . . . . . . . . 23
5.1. Processing Register Requests . . . . . . . . . . . . . . . 23 5.1. Processing Register Requests . . . . . . . . . . . . . . . 23
5.2. Generating Flow Tokens . . . . . . . . . . . . . . . . . . 23 5.2. Generating Flow Tokens . . . . . . . . . . . . . . . . . . 23
5.3. Forwarding Non-REGISTER Requests . . . . . . . . . . . . . 24 5.3. Forwarding Non-REGISTER Requests . . . . . . . . . . . . . 24
5.3.1. Processing Incoming Requests . . . . . . . . . . . . . 24 5.3.1. Processing Incoming Requests . . . . . . . . . . . . . 24
5.3.2. Processing Outgoing Requests . . . . . . . . . . . . . 25 5.3.2. Processing Outgoing Requests . . . . . . . . . . . . . 25
5.4. Edge Proxy Keep alive Handling . . . . . . . . . . . . . . 25 5.4. Edge Proxy Keep alive Handling . . . . . . . . . . . . . . 25
skipping to change at page 4, line 14 skipping to change at page 4, line 14
11.6. 439 (First Hop Lacks Outbound Support) Response Code . . . 42 11.6. 439 (First Hop Lacks Outbound Support) Response Code . . . 42
11.7. Media Feature Tag . . . . . . . . . . . . . . . . . . . . 42 11.7. Media Feature Tag . . . . . . . . . . . . . . . . . . . . 42
12. Security Considerations . . . . . . . . . . . . . . . . . . . 43 12. Security Considerations . . . . . . . . . . . . . . . . . . . 43
13. Operational Notes on Transports . . . . . . . . . . . . . . . 44 13. Operational Notes on Transports . . . . . . . . . . . . . . . 44
14. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 45 14. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 45
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
16.1. Normative References . . . . . . . . . . . . . . . . . . . 46 16.1. Normative References . . . . . . . . . . . . . . . . . . . 46
16.2. Informational References . . . . . . . . . . . . . . . . . 47 16.2. Informational References . . . . . . . . . . . . . . . . . 47
Appendix A. Default Flow Registration Backoff Times . . . . . . . 48 Appendix A. Default Flow Registration Backoff Times . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
There are many environments for SIP [RFC3261] deployments in which There are many environments for SIP [RFC3261] deployments in which
the User Agent (UA) can form a connection to a Registrar or Proxy but the User Agent (UA) can form a connection to a Registrar or Proxy but
in which connections in the reverse direction to the UA are not in which connections in the reverse direction to the UA are not
possible. This can happen for several reasons, but the most likely possible. This can happen for several reasons, but the most likely
is a NAT or a firewall in between the SIP UA and the proxy. Many is a NAT or a firewall in between the SIP UA and the proxy. Many
such devices will only allow outgoing connections. This such devices will only allow outgoing connections. This
specification allows a SIP User Agent behind such a firewall or NAT specification allows a SIP User Agent behind such a firewall or NAT
to receive inbound traffic associated with registrations or dialogs to receive inbound traffic associated with registrations or dialogs
that it initiates. that it initiates.
Most IP phones and personal computers get their network Most IP phones and personal computers get their network
configurations dynamically via a protocol such as DHCP (Dynamic Host configurations dynamically via a protocol such as Dynamic Host
Configuration Protocol). These systems typically do not have a Configuration Protocol (DHCP) [RFC2131]. These systems typically do
useful name in the Domain Name System (DNS), and they almost never not have a useful name in the Domain Name System (DNS) [RFC1035], and
have a long-term, stable DNS name that is appropriate for use in the they almost never have a long-term, stable DNS name that is
subjectAltName of a certificate, as required by [RFC3261]. However, appropriate for use in the subjectAltName of a certificate, as
these systems can still act as a Transport Layer Security (TLS) required by [RFC3261]. However, these systems can still act as a
[RFC5246] client and form outbound connections to a proxy or Transport Layer Security (TLS) [RFC5246] client and form outbound
registrar which authenticates with a server certificate. The server connections to a proxy or registrar which authenticates with a server
can authenticate the UA using a shared secret in a digest challenge certificate. The server can authenticate the UA using a shared
(as defined in Section 22 of RFC 3261) over that TLS connection. secret in a digest challenge (as defined in Section 22 of RFC 3261)
This specification allows a SIP User Agent who has to initiate the over that TLS connection. This specification allows a SIP User Agent
TLS connection to receive inbound traffic associated with who has to initiate the TLS connection to receive inbound traffic
registrations or dialogs that it initiates. associated with registrations or dialogs that it initiates.
The key idea of this specification is that when a UA sends a REGISTER The key idea of this specification is that when a UA sends a REGISTER
request or a dialog-forming request, the proxy can later use this request or a dialog-forming request, the proxy can later use this
same network "flow"--whether this is a bidirectional stream of UDP same network "flow"--whether this is a bidirectional stream of UDP
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
skipping to change at page 6, line 28 skipping to change at page 6, line 28
when a UA sends a request. when a UA sends a request.
Flow: A Flow is a network transport layer association between two Flow: A Flow is a network transport layer association between two
hosts that is represented by the network address and port number hosts that is represented by the network address and port number
of both ends and by the transport protocol. For TCP, a flow is of both ends and by the transport protocol. For TCP, a flow is
equivalent to a TCP connection. For UDP a flow is a bidirectional 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.
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 [RFC3986]).
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 for a different flow, each concurrent registration times, each for a different flow, each concurrent registration
gets a unique reg-id value. 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
skipping to change at page 13, line 15 skipping to change at page 13, line 15
outside the scope of this document. outside the scope of this document.
3.5.1. CRLF Keep alive Technique 3.5.1. CRLF Keep alive Technique
This approach can only be used with connection-oriented transports This approach can only be used with connection-oriented transports
such as TCP or SCTP. The client periodically sends a double-CRLF such as TCP or SCTP. The client periodically sends a double-CRLF
(the "ping") then waits to receive a single CRLF (the "pong"). If (the "ping") then waits to receive a single CRLF (the "pong"). If
the client does not receive a "pong" within an appropriate amount of the client does not receive a "pong" within an appropriate amount of
time, it considers the flow failed. time, it considers the flow failed.
Sending a CRLF over a connection-oriented transport is backwards Note: Sending a CRLF over a connection-oriented transport is
compatible (because of requirements in Section 7.5 of [RFC3261]), backwards compatible (because of requirements in Section 7.5 of
but only implementations which support this specification will [RFC3261]), but only implementations which support this
respond to a "ping" with a "pong". specification will respond to a "ping" with a "pong".
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
skipping to change at page 14, line 9 skipping to change at page 14, line 9
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
Instance ID MUST NOT change as the device moves from one network to Instance ID MUST NOT change as the device moves from one network to
another. another.
A UA SHOULD create a UUID URN [RFC4122] as its instance-id. The UUID A UA SHOULD create a UUID URN [RFC4122] as its instance-id. The UUID
URN allows for non-centralized computation of a URN based on time, URN allows for non-centralized computation of a URN based on time,
unique names (such as a MAC address), or a random number generator. unique names (such as a MAC address), or a random number generator.
A device like a soft-phone, when first installed, can generate a Note: A device like a soft-phone, when first installed, can
UUID [RFC4122] and then save this in persistent storage for all generate a UUID [RFC4122] and then save this in persistent storage
future use. For a device such as a hard phone, which will only for all future use. For a device such as a hard phone, which will
ever have a single SIP UA present, the UUID can include the MAC only ever have a single SIP UA present, the UUID can include the
address and be generated at any time because it is guaranteed that MAC address and be generated at any time because it is guaranteed
no other UUID is being generated at the same time on that physical that no other UUID is being generated at the same time on that
device. This means the value of the time component of the UUID physical device. This means the value of the time component of
can be arbitrarily selected to be any time less than the time when the UUID can be arbitrarily selected to be any time less than the
the device was manufactured. A time of 0 (as shown in the example time when the device was manufactured. A time of 0 (as shown in
in Section 3.2) is perfectly legal as long as the device knows no the example in Section 3.2) is perfectly legal as long as the
other UUIDs were generated at this time on this device. device knows no 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 RFC defines how the specific URN needs to be for which an IETF RFC defines how the specific URN needs to be
constructed and used in the sip.instance Contact parameter for 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]. This media feature tag is encoded in the Contact header [RFC3840]. This media feature tag is encoded in the Contact header
field as the "+sip.instance" Contact header field parameter. One field as the "+sip.instance" Contact header field parameter. One
case where a UA could prefer to omit the sip.instance media feature case where a UA could prefer to omit the sip.instance media feature
tag is when it is making an anonymous request or some other privacy tag is when it is making an anonymous request or some other privacy
concern requires that the UA not reveal its identity. concern requires that the UA not reveal its identity.
[RFC3840] defines equality rules for callee capabilities Note: [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 [RFC3840]
and the caller preferences [RFC3841] specifications. When the and the caller preferences [RFC3841] specifications. When the
instance ID is used in this specification, it is "extracted" from instance ID is used in this specification, it is "extracted" from
the value in the "sip.instance" media feature tag. Thus, equality the value in the "sip.instance" media feature tag. Thus, equality
comparisons are performed using the rules for URN equality that comparisons are performed using the rules for URN equality that
are specific to the scheme in the URN. If the element performing are specific to the scheme in the URN. If the element performing
the comparisons does not understand the URN scheme, it performs the comparisons does not understand the URN scheme, it performs
the comparisons using the lexical equality rules defined in the comparisons using the lexical equality rules defined in
[RFC2141]. Lexical equality could result in two URNs being [RFC2141]. Lexical equality could 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
skipping to change at page 16, line 5 skipping to change at page 16, line 5
MUST include reg-id parameter in the Contact header field that is MUST include reg-id parameter in the Contact header field that is
distinct from other reg-id parameters used from the same distinct from other reg-id parameters used from the same
+sip.instance and AOR. Each one of these registrations will form a +sip.instance and AOR. Each one of these registrations will form a
new flow from the UA to the proxy. The sequence of reg-id values new flow from the UA to the proxy. The sequence of reg-id values
does not have to be sequential but MUST be exactly the same sequence does not have to be sequential but MUST be exactly the same sequence
of reg-id values each time the UA instance power cycles or reboots so of reg-id values each time the UA instance power cycles or reboots so
that the reg-id values will collide with the previously used reg-id that the reg-id values will collide with the previously used reg-id
values. This is so the registrar can replace the older values. This is so the registrar can replace the older
registrations. registrations.
The UAC can situationally decide whether to request outbound Note: The UAC can situationally decide whether to request
behavior by including or omitting the reg-id Contact header field outbound behavior by including or omitting the reg-id Contact
parameter. For example, imagine the outbound-proxy-set contains header field parameter. For example, imagine the outbound-proxy-
two proxies in different domains, EP1 and EP2. If an outbound- set contains two proxies in different domains, EP1 and EP2. If an
style registration succeeded for a flow through EP1, the UA might outbound-style registration succeeded for a flow through EP1, the
decide to include 'outbound' in its Require header field when UA might decide to include 'outbound' in its Require header field
registering with EP2, in order to insure consistency. Similarly, when registering with EP2, in order to insure consistency.
if the registration through EP1 did not support outbound, the UA Similarly, if the registration through EP1 did not support
might not register with EP2 at all. outbound, the UA might not register with EP2 at all.
The UAC MUST support the Path header [RFC3327] mechanism, and The UAC MUST support the Path header [RFC3327] mechanism, and
indicate its support by including the 'path' option-tag in a indicate its support by including the 'path' option-tag in a
Supported header field value in its REGISTER requests. Other than Supported header field value in its REGISTER requests. Other than
optionally examining the Path vector in the response, this is all optionally examining the Path vector in the response, this is all
that is required of the UAC to support Path. that is required of the UAC to support Path.
The UAC examines successful registration responses for the presence The UAC examines successful registration responses for the presence
of an outbound option-tag in a Require header field value. Presence of an outbound option-tag in a Require header field value. Presence
of this option-tag indicates that the registrar is compliant with of this option-tag indicates that the registrar is compliant with
skipping to change at page 16, line 35 skipping to change at page 16, line 35
participate are also compliant. If the registrar did not support participate are also compliant. If the registrar did not support
outbound, the UA has potentially registered an un-routable contact. outbound, the UA has potentially registered an un-routable contact.
It is the responsibility of the UA to remove any inappropriate It is the responsibility of the UA to remove any inappropriate
Contacts. Contacts.
If outbound registration succeeded, as indicated by the presence of If outbound registration succeeded, as indicated by the presence of
the outbound option-tag in the Require header field of a successful the outbound option-tag in the Require header field of a successful
registration response, the UA begins sending keep alives as described registration response, the UA begins sending keep alives as described
in Section 4.4. in Section 4.4.
Note that the UA needs to honor 503 (Service Unavailable) responses Note: The UA needs to honor 503 (Service Unavailable) responses
to registrations as described in [RFC3261] and [RFC3263]. In to registrations as described in [RFC3261] and [RFC3263]. In
particular, implementors should note that when receiving a 503 particular, implementors should note that when receiving a 503
(Service Unavailable) response with a Retry-After header field, the (Service Unavailable) response with a Retry-After header field,
UA is expected to wait the indicated amount of time and retry the the UA is expected to wait the indicated amount of time and retry
registration. A Retry-After header field value of 0 is valid and the registration. A Retry-After header field value of 0 is valid
indicates the UA is expected to retry the REGISTER request and indicates the UA is expected to retry the REGISTER request
immediately. Implementations need to ensure that when retrying the immediately. Implementations need to ensure that when retrying
REGISTER request, they revisit the DNS resolution results such that the REGISTER request, they revisit the DNS resolution results such
the UA can select an alternate host from the one chosen the previous that the UA can select an alternate host from the one chosen the
time the URI was resolved. previous time the URI was 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 using the outbound mechanism (subject to local registration without using the outbound mechanism (subject to local
policy at the client). If the client has one or more alternate policy at the client). If the client has one or more alternate
outbound proxies available, it MAY re-attempt registration through outbound proxies available, it MAY re-attempt registration through
such outbound proxies. See Section 11.6 for more information on the such outbound proxies. See Section 11.6 for more information on the
439 response code. 439 response code.
4.2.2. Subsequent REGISTER requests 4.2.2. Subsequent REGISTER requests
skipping to change at page 18, line 12 skipping to change at page 18, line 12
URIs contained in the subjectAltName in the peer certificate. If the URIs contained in the subjectAltName in the peer certificate. If the
UAC cannot use one of the existing flows, then it SHOULD form a new UAC 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 flow by sending a datagram or opening a new connection to the next
hop, as appropriate for the transport protocol. hop, as appropriate for the transport protocol.
Typically, a UAC using the procedures of this document and sending a Typically, a UAC using the procedures of this document and sending a
dialog-forming request will want all subsequent requests in the dialog-forming request will want all subsequent requests in the
dialog to arrive over the same flow. If the UAC is using a GRUU dialog to arrive over the same flow. If the UAC is using a GRUU
[I-D.ietf-sip-gruu] that was instantiated using a Contact header [I-D.ietf-sip-gruu] that was instantiated using a Contact header
field value that included an "ob" parameter, the UAC sends the field value that included an "ob" parameter, the UAC sends the
request over the flow used for registration and susequent requests request over the flow used for registration and subsequent requests
will arrive over that same flow. If the UAC is not using such a will arrive over that same flow. If the UAC is not using such a
GRUU, then the UAC adds an "ob" parameter to its Contact header field GRUU, then the UAC adds an "ob" parameter to its Contact header field
value. This will cause all subsequent requests in the dialog to value. This will cause all subsequent requests in the dialog to
arrive over the flow instantiated by the dialog-forming request. arrive over the flow instantiated by the dialog-forming request.
This case is typical when the request is sent prior to registration, This case is typical when the request is sent prior to registration,
such as in the the initial subcription dialog for the configuration such as in the the initial subcription dialog for the configuration
framework [I-D.ietf-sipping-config-framework]. framework [I-D.ietf-sipping-config-framework].
Note that if the UAC wants a UDP flow to work through NATs or Note: If the UAC wants a UDP flow to work through NATs or
firewalls it still needs to put the 'rport' parameter [RFC3581] in firewalls it still needs to put the 'rport' parameter [RFC3581] in
its Via header field value, and send from the port it is prepared its Via header field value, and send from the port it is prepared
to receive on. More general information about NAT traversal in to receive on. More general information about NAT traversal in
SIP is described in [I-D.ietf-sipping-nat-scenarios]. SIP is described in [I-D.ietf-sipping-nat-scenarios].
4.4. Keep-alives and Detecting Flow Failure 4.4. Keep alives and Detecting Flow Failure
Keep alives are used for refreshing NAT/firewall bindings and Keep alives are used for refreshing NAT/firewall bindings and
detecting flow failure. Flows can fail for many reasons including detecting flow failure. Flows can fail for many reasons including
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
keep alives after an appropriate registration response. A UA that keep alives 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 keep alives under certain circumstances. also send keep alives 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 node 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: 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 7.5/[RFC3261], However a UA that did not register using Section 7.5/[RFC3261], However a UA that did not register using
outbound registration cannot expect a CRLF in response (a "pong") outbound registration cannot expect a CRLF in response (a "pong")
unless the UA has an explicit indication that CRLF keep alives are unless the UA has an explicit indication that CRLF keep alives are
supported as described in this section. Likewise, a UA that did supported as described in this section. Likewise, a UA that did
not successfully register with outbound procedures needs explicit not successfully register with outbound procedures needs explicit
indication that the target first hop SIP node supports STUN keep indication that the target first hop SIP node supports STUN keep
alives before it can send any STUN messages. alives before it can send any STUN messages.
A configuration option indicating keep alive support for a specific A configuration option indicating keep alive support for a specific
skipping to change at page 20, line 8 skipping to change at page 20, line 8
Section Section 4.4.1 describes a keep alive mechanism for connection Section Section 4.4.1 describes a keep alive mechanism for connection
oriented transports such as TCP or SCTP. Section Section 4.4.2 oriented transports such as TCP or SCTP. Section Section 4.4.2
describes a keep alive mechanism for connection-less transports such describes a keep alive mechanism for connection-less transports such
as UDP. Support for other transports such as DCCP [RFC4340] is for as UDP. Support for other transports such as DCCP [RFC4340] is for
further study. further study.
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; it MUST NOT be used with connection-less
transports such as UDP.
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 connection-oriented transport (ex: the UA is connecting resolves to a connection-oriented transport (ex:
TCP 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
skipping to change at page 21, line 24 skipping to change at page 21, line 26
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
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.2. Keep alive with STUN 4.4.2. Keep alive with STUN
This approach MUST only be used with connection-less transports, such This approach MUST only be used with connection-less transports, such
as UDP. as UDP; it MUST NOT be used for connection oriented transports such
as TCP and 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 use the UDP transport. The UA can the UA is connecting resolves to use the UDP transport. The UA can
periodically perform keep alive checks by sending STUN [RFC5389] periodically perform keep alive checks by sending STUN [RFC5389]
Binding Requests over the flow as described in Section 8. Clients Binding Requests over the flow as described in Section 8. Clients
MUST support STUN based keep alives. MUST support STUN based keep alives.
When a Flow-Timer header field is not included in a successful When a Flow-Timer header field is not included in a successful
registration response, the time between each keep alive request registration response, the time between each keep alive request
SHOULD be a random number between 24 and 29 seconds. SHOULD be a random number between 24 and 29 seconds.
skipping to change at page 22, line 25 skipping to change at page 22, line 25
particular next hop. particular next hop.
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 a lower value (with a default of 30 seconds);
least one of the flows has not failed, the base-time is set to 90 otherwise, in the case where at least one of the flows has not
seconds. The upper-bound wait time (W) is computed by taking two failed, the base-time is set to a higher value (with a default of 90
seconds). The upper-bound wait time (W) is computed by taking two
raised to the power of the number of consecutive registration raised to the power of the number of consecutive registration
failures for that URI, and multiplying this by the base time, up to a failures for that URI, and multiplying this by the base time, up to a
maximum of 1800 seconds. configurable maximum time (with a default of 1800 seconds).
W = 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 upper-bound wait time is min(1800,30*(2^3)) or 240 failures, then the upper-bound wait time is min(1800,30*(2^3)) or 240
seconds. The actual amount of time the UA waits before retrying seconds. The actual amount of time the UA waits before retrying
registration (the retry delay time) is computed by selecting a registration (the retry delay time) is computed by selecting a
uniform random time between 50 and 100 percent of the upper-bound uniform random time between 50 and 100 percent of the upper-bound
wait time. The UA MUST wait for at least the value of the retry wait time. The UA MUST wait for at least the value of the retry
delay time before trying another registration to form a new flow for delay time before trying another registration to form a new flow for
that URI (a 503 response to an earlier failed registration attempt that URI (a 503 response to an earlier failed registration attempt
with a Retry-After header field value may cause the UA to wait with a Retry-After header field value may cause the UA to wait
longer).. longer)..
skipping to change at page 23, line 45 skipping to change at page 23, line 46
A trivial but impractical way to satisfy the flow token requirement A trivial but impractical way to satisfy the flow token requirement
in Section 5.1 involves storing a mapping between an incrementing in 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 infeasible amount of state. It is unclear the Edge Proxy to keep an infeasible 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. A stateless if the proxy crashed and lost the value of the counter. A stateless
example is provided below. A proxy can use any algorithm it wants as example is provided below. A proxy can use any algorithm it wants as
long as the flow token is unique to a flow, the flow can be recovered long as the flow token is unique to a flow, the flow can be recovered
from the token, and the token cannot be modified by attackers. from the token, and the token cannot be modified by attackers.
Example Algorithm: When the proxy boots it selects a 20-octet crypto Example Algorithm: When the proxy boots it selects a 20-octet
random key called K that only the Edge Proxy knows. A byte array, crypto random key called K that only the Edge Proxy knows. A byte
called S, is formed that contains the following information about array, called S, is formed that contains the following information
the flow the request was received on: an enumeration indicating about the flow the request was received on: an enumeration
the protocol, the local IP address and port, the remote IP address indicating the protocol, the local IP address and port, the remote
and port. The HMAC of S is computed using the key K and the HMAC- IP address and port. The HMAC of S is computed using the key K
SHA1-80 algorithm, as defined in [RFC2104]. The concatenation of and the HMAC-SHA1-80 algorithm, as defined in [RFC2104]. The
the HMAC and S are base64 encoded, as defined in [RFC4648], and concatenation of the HMAC and S are base64 encoded, as defined in
used as the flow identifier. When using IPv4 addresses, this will [RFC4648], and used as the flow identifier. When using IPv4
result in a 32-octet identifier. addresses, this will result in a 32-octet identifier.
5.3. Forwarding Non-REGISTER Requests 5.3. Forwarding Non-REGISTER Requests
When an Edge Proxy receives a request, it applies normal routing When an Edge Proxy receives a request, it applies normal routing
procedures with the following additions. If the Edge Proxy receives procedures with the following additions. If the Edge Proxy receives
a request where the edge proxy is the host in the topmost Route a request where the edge proxy is the host in the topmost Route
header field value, and the Route header field value contains a flow header field value, and the Route header field value contains a flow
token, the proxy follows the procedures of this section. Otherwise token, the proxy follows the procedures of this section. Otherwise
the edge proxy skips the procedures in this section, removes itself the edge proxy skips the procedures in this section, removes itself
from the Route header field, and continues processing the request. from the Route header field, and continues processing the request.
skipping to change at page 24, line 37 skipping to change at page 24, line 39
5.3.1. Processing Incoming Requests 5.3.1. Processing Incoming Requests
If the Route header value contains an ob URI parameter, the Route If the Route header value contains an ob URI parameter, the Route
header was probably copied from the Path header in a registration. header was probably copied from the Path header in a registration.
If the Route header value contains an ob URI parameter, and the If the Route header value contains an ob URI parameter, and the
request is a new dialog-forming request, the proxy needs to adjust request is a new dialog-forming request, the proxy needs to adjust
the route set to insure that subsequent requests in the dialog can be the route set to insure that subsequent requests in the dialog can be
delivered over a valid flow to the UA instance identified by the flow delivered over a valid flow to the UA instance identified by the flow
token. token.
A simple approach to satisfy this requirement is for the proxy to Note: A simple approach to satisfy this requirement is for the
add a Record-Route header field value that contains the flow- proxy to add a Record-Route header field value that contains the
token, by copying the URI in the Route header minus the 'ob' flow-token, by copying the URI in the Route header minus the 'ob'
parameter. parameter.
Next, whether the Route header field contained an ob URI parameter or Next, whether the Route header field contained an ob URI parameter or
not, the proxy removes the Route header field value and forwards the not, the proxy removes the Route header field value and forwards the
request over the 'logical flow' identified by the flow token, that is request over the 'logical flow' identified by the flow token, that is
known to deliver data to the specific target UA instance. If the known to deliver data to the specific target UA instance. If the
flow token has been tampered with, the proxy SHOULD send a 403 flow token has been tampered with, the proxy SHOULD send a 403
(Forbidden) response. If the flow no longer exists the proxy SHOULD (Forbidden) response. If the flow no longer exists the proxy SHOULD
send a 430 (Flow Failed) response to the request. send a 430 (Flow Failed) response to the request.
skipping to change at page 25, line 18 skipping to change at page 25, line 21
5.3.2. Processing Outgoing Requests 5.3.2. Processing Outgoing Requests
For mid-dialog requests to work with outbound UAs, the requests need For mid-dialog requests to work with outbound UAs, the requests need
to be forwarded over some valid flow to the appropriate UA instance. to be forwarded over some valid flow to the appropriate UA instance.
If the Edge Proxy receives an outgoing dialog-forming request, the If the Edge Proxy receives an outgoing dialog-forming request, the
Edge Proxy can use the presence of the ob URI parameter in the UAC's Edge Proxy can use the presence of the ob URI parameter in the UAC's
Contact URI (or topmost Route header field) to determine if the Edge Contact URI (or topmost Route header field) to determine if the Edge
Proxy needs to assist in mid-dialog request routing. Proxy needs to assist in mid-dialog request routing.
Implementation note: Specific procedures at the edge proxy to ensure Implementation note: Specific procedures at the edge proxy to
that mid-dialog requests are routed over an existing flow are not ensure that mid-dialog requests are routed over an existing flow
part of this specification. However, an approach such as having are not part of this specification. However, an approach such as
the Edge Proxy add a Record-Route header with a flow token is one having the Edge Proxy add a Record-Route header with a flow token
way to ensure that mid-dialog requests are routed over the correct is one way to ensure that mid-dialog requests are routed over the
flow. correct flow.
5.4. Edge Proxy Keep alive Handling 5.4. Edge Proxy Keep alive Handling
All edge proxies compliant with this specification MUST implement All edge proxies compliant with this specification MUST implement
support for STUN NAT Keep alives on its SIP UDP ports as described in support for STUN NAT Keep alives on its SIP UDP ports as described in
Section 8. Section 8.
When a server receives a double CRLF sequence between SIP messages on When a server receives a double CRLF sequence between SIP messages on
a connection oriented transport such as TCP or SCTP, it MUST a connection oriented transport such as TCP or SCTP, it MUST
immediately respond with a single CRLF over the same connection. immediately respond with a single CRLF over the same connection.
skipping to change at page 28, line 26 skipping to change at page 28, line 26
The proxy uses the next-hop target of the message and the value of The proxy uses the next-hop target of the message and the value of
any stored Path header field vector in the registration binding to any stored Path header field vector in the registration binding to
decide how to forward and populate the Route header in the request. decide how to forward and populate the Route header in the request.
If the proxy is colocated with the registrar and stored information If the proxy is colocated with the registrar and stored information
about the flow to the UA that created the binding, then the proxy about the flow to the UA that created the binding, then the proxy
MUST send the request over the same 'logical flow' saved with the MUST send the request over the same 'logical flow' saved with the
binding, since that flow is known to deliver data to the specific binding, since that flow is known to deliver data to the specific
target UA instance's network flow that was saved with the binding. target UA instance's network flow that was saved with the binding.
Implementation Note: Typically this means that for TCP, the request Implementation note: Typically this means that for TCP, the
is sent on the same TCP socket that received the REGISTER request. request is sent on the same TCP socket that received the REGISTER
For UDP, the request is sent from the same local IP address and request. For UDP, the request is sent from the same local IP
port over which the registration was received, to the same IP address and port over which the registration was received, to the
address and port from which the REGISTER was received. same IP address and port from which the REGISTER was received.
If a proxy or registrar receives information from the network that If a proxy or registrar receives information from the network that
indicates that no future messages will be delivered on a specific indicates that no future messages will be delivered on a specific
flow, then the proxy MUST invalidate all the bindings in the target flow, then the proxy MUST invalidate all the bindings in the target
set that use that flow (regardless of AOR). Examples of this are a set that use that flow (regardless of AOR). Examples of this are a
TCP socket closing or receiving a destination unreachable ICMP error TCP socket closing or receiving a destination unreachable ICMP error
on a UDP flow. Similarly, if a proxy closes a file descriptor, it on a UDP flow. Similarly, if a proxy closes a file descriptor, it
MUST invalidate all the bindings in the target set with flows that MUST invalidate all the bindings in the target set with flows that
use that file descriptor. use that file descriptor.
skipping to change at page 29, line 16 skipping to change at page 29, line 16
messages. These Binding Requests do not require any STUN attributes. messages. These Binding Requests do not require any STUN attributes.
The corresponding Binding Responses do not require any STUN The corresponding Binding Responses do not require any STUN
attributes except the XOR-MAPPED-ADDRESS. The UAS, proxy, or attributes except the XOR-MAPPED-ADDRESS. The UAS, proxy, or
registrar responds to a valid Binding Request with a Binding Response registrar responds to a valid Binding Request with a Binding Response
which MUST include the XOR-MAPPED-ADDRESS attribute. which MUST include the XOR-MAPPED-ADDRESS attribute.
If a server compliant to this section receives SIP requests on a If a server compliant to this section receives SIP requests on a
given interface and UDP port, it MUST also provide a limited version given interface and UDP port, it MUST also provide a limited version
of a STUN server on the same interface and UDP port. of a STUN server on the same interface and UDP port.
It is easy to distinguish STUN and SIP packets sent over UDP, Note: It is easy to distinguish STUN and SIP packets sent over
because the first octet of a STUN Binding method has a value of 0 UDP, because the first octet of a STUN Binding method has a value
or 1 while the first octet of a SIP message is never a 0 or 1. of 0 or 1 while the first octet of a SIP message is never a 0 or
1.
Because sending and receiving binary STUN data on the same ports used Because sending and receiving binary STUN data on the same ports used
for SIP is a significant and non-backwards compatible change to RFC for SIP is a significant and non-backwards compatible change to RFC
3261, this section requires a number of checks before sending STUN 3261, this section requires a number of checks before sending STUN
messages to a SIP node. If a SIP node sends STUN requests (for messages to a SIP node. If a SIP node sends STUN requests (for
example due to incorrect configuration) despite these warnings, the example due to incorrect configuration) despite these warnings, the
node could be blacklisted for UDP traffic. node could be blacklisted for UDP traffic.
A SIP node MUST NOT send STUN requests over a flow unless it has an A SIP node MUST NOT send STUN requests over a flow unless it has an
explicit indication that the target next hop SIP server claims to explicit indication that the target next hop SIP server claims to
support this specification. UACs MUST NOT use an ambiguous support this specification. UACs MUST NOT use an ambiguous
configuration option such as "Work through NATs?" or "Do Keep configuration option such as "Work through NATs?" or "Do Keep
alives?" to imply next hop STUN support. A UAC MAY use the presence alives?" to imply next hop STUN support. A UAC MAY use the presence
of an ob URI parameter in the Path header in a registration response of an ob URI parameter in the Path header in a registration response
as an indication that its first edge proxy supports the keep alives as an indication that its first edge proxy supports the keep alives
defined in this document. defined in this document.
Typically, a SIP node first sends a SIP request and waits to Note: Typically, a SIP node first sends a SIP request and waits
receive a 2XX class response over a flow to a new target to receive a 2XX class response over a flow to a new target
destination, before sending any STUN messages. When scheduled for destination, before sending any STUN messages. When scheduled for
the next NAT refresh, the SIP node sends a STUN request to the the next NAT refresh, the SIP node sends a STUN request to the
target. target.
Once a flow is established, failure of a STUN request (including its Once a flow is established, failure of a STUN request (including its
retransmissions) is considered a failure of the underlying flow. For retransmissions) is considered a failure of the underlying flow. For
SIP over UDP flows, if the XOR-MAPPED-ADDRESS returned over the flow SIP over UDP flows, if the XOR-MAPPED-ADDRESS returned over the flow
changes, this indicates that the underlying connectivity has changed, changes, this indicates that the underlying connectivity has changed,
and is considered a flow failure. and is considered a flow failure.
skipping to change at page 30, line 14 skipping to change at page 30, line 14
8.1. Use with Sigcomp 8.1. Use with Sigcomp
When STUN is used together with SigComp [RFC3320] compressed SIP When STUN is used together with SigComp [RFC3320] compressed SIP
messages over the same flow, the STUN messages are simply sent messages over the same flow, the STUN messages are simply sent
uncompressed, "outside" of SigComp. This is supported by uncompressed, "outside" of SigComp. This is supported by
multiplexing STUN messages with SigComp messages by checking the two multiplexing STUN messages with SigComp messages by checking the two
topmost bits of the message. These bits are always one for SigComp, topmost bits of the message. These bits are always one for SigComp,
or zero for STUN. or zero for STUN.
All SigComp messages contain a prefix (the five most-significant Note: All SigComp messages contain a prefix (the five most-
bits of the first byte are set to one) that does not occur in significant bits of the first byte are set to one) that does not
UTF-8 [RFC3629] encoded text messages, so for applications which occur in UTF-8 [RFC3629] encoded text messages, so for
use this encoding (or ASCII encoding) it is possible to multiplex applications which use this encoding (or ASCII encoding) it is
uncompressed application messages and SigComp messages on the same possible to multiplex uncompressed application messages and
UDP port. SigComp messages on the same UDP port. The most significant two
The most significant two bits of every STUN Binding method are bits of every STUN Binding method are both zeroes. This, combined
both zeroes. This, combined with the magic cookie, aids in with the magic cookie, aids in differentiating STUN packets from
differentiating STUN packets from other protocols when STUN is other protocols when STUN is multiplexed with other protocols on
multiplexed with other protocols on the same port. the same port.
9. Example Message Flow 9. Example Message Flow
Below is an example message flow illustrating most of the concepts Below is an example message flow illustrating most of the concepts
discussed in this specification. In many cases, Via, Content-Length discussed in this specification. In many cases, Via, Content-Length
and Max-Forwards headers are omitted for brevity and readability. and Max-Forwards headers are omitted for brevity and readability.
In these examples, "EP1" and "EP2" are outbound proxies, and "Proxy" In these examples, "EP1" and "EP2" are outbound proxies, and "Proxy"
is the authoritativeProxy. is the authoritativeProxy.
skipping to change at page 30, line 48 skipping to change at page 30, line 48
9.1. Subscription to configuration package 9.1. Subscription to configuration package
If the outbound proxy set is already configured on Bob's UA, then If the outbound proxy set is already configured on Bob's UA, then
this subsection can be skipped. Otherwise, if the outbound proxy set this subsection can be skipped. Otherwise, if the outbound proxy set
is learned through the configuration package, Bob's UA sends a is learned through the configuration package, Bob's UA sends a
SUBSCRIBE request for the UA profile configuration package SUBSCRIBE request for the UA profile configuration package
[I-D.ietf-sipping-config-framework]. This request is a poll (Expires [I-D.ietf-sipping-config-framework]. This request is a poll (Expires
is zero). After receiving the NOTIFY request, Bob's UA fetches the is zero). After receiving the NOTIFY request, Bob's UA fetches the
external configuration using HTTPS (not shown) and obtains a external configuration using HTTPS (not shown) and obtains a
configuration file which contains the outbound-proxy-set "sip: configuration file which contains the outbound-proxy-set "sip:
ep1.example.com;lr" and "sip:ep2.example.com;lr. ep1.example.com;lr" and "sip:ep2.example.com;lr".
[----example.com domain-------------------------] [----example.com domain-------------------------]
Bob EP1 EP2 Proxy Config Bob EP1 EP2 Proxy Config
| | | | | | | | | |
1)|SUBSCRIBE->| | | | 1)|SUBSCRIBE->| | | |
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--| | | |
skipping to change at page 40, line 9 skipping to change at page 40, line 9
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.0.2.2;transport=tcp;ob> Contact: <sip:bob@192.0.2.2;transport=tcp;ob>
10. Grammar 10. Grammar
This specification defines a new header field "Flow-Timer", new This specification defines a new header field "Flow-Timer", new
Contact header field parameters, reg-id and +sip.instance. The Contact header field parameters, reg-id and +sip.instance. The
grammar includes the definitions from [RFC3261] and includes the grammar includes the definitions from [RFC3261]. Flow-Timer is an
definition of uric from [RFC3986]. Flow-Timer is an extension-header extension-header from the message-header in the [RFC3261] ABNF.
from the message-header in the [RFC3261] ABNF.
The ABNF[RFC5234] is: The ABNF[RFC5234] is:
Flow-Timer = "Flow-Timer" HCOLON 1*DIGIT Flow-Timer = "Flow-Timer" HCOLON 1*DIGIT
contact-params =/ c-p-reg / c-p-instance contact-params =/ c-p-reg / c-p-instance
c-p-reg = "reg-id" EQUAL 1*DIGIT ; 1 to (2**31 - 1) c-p-reg = "reg-id" EQUAL 1*DIGIT ; 1 to (2**31 - 1)
c-p-instance = "+sip.instance" EQUAL c-p-instance = "+sip.instance" EQUAL
DQUOTE "<" instance-val ">" DQUOTE DQUOTE "<" instance-val ">" DQUOTE
instance-val = *uric ; defined in RFC 3986 instance-val = 1*uric ; defined in RFC 3261
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.
11. IANA Considerations 11. IANA Considerations
11.1. Flow-Timer Header Field 11.1. Flow-Timer Header Field
This specification defines a new SIP header field "Flow-Timer" whose This specification defines a new SIP header field "Flow-Timer" whose
syntax is defined in Section 10. syntax is defined in Section 10.
skipping to change at page 43, line 5 skipping to change at page 43, line 5
defined in [RFC3840]. defined in [RFC3840].
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
contains a string containing a URN that indicates a unique identifier contains a string containing a URN that indicates a unique identifier
associated with the UA instance registering the Contact. associated with the UA instance registering the Contact.
Values appropriate for use with this feature tag: String. Values appropriate for use with this feature tag: String (equality
relationship).
The feature tag is intended primarily for use in the following The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms: This applications, protocols, services, or negotiation mechanisms: This
feature tag is most useful in a communications application, for feature tag is most useful in a communications application, for
describing the capabilities of a device, such as a phone or PDA. describing the capabilities of a device, such as a phone or PDA.
Examples of typical use: Routing a call to a specific device. Examples of typical use: Routing a call to a specific device.
Related standards or documents: RFC XXXX Related standards or documents: RFC XXXX
skipping to change at page 47, line 5 skipping to change at page 47, line 5
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority [RFC3968] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Header Field Parameter Registry for the Session (IANA) Header Field Parameter Registry for the Session
Initiation Protocol (SIP)", BCP 98, RFC 3968, Initiation Protocol (SIP)", BCP 98, RFC 3968,
December 2004. December 2004.
[RFC3969] Camarillo, G., "The Internet Assigned Number Authority [RFC3969] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Uniform Resource Identifier (URI) Parameter (IANA) Uniform Resource Identifier (URI) Parameter
Registry for the Session Initiation Protocol (SIP)", Registry for the Session Initiation Protocol (SIP)",
BCP 99, RFC 3969, December 2004. BCP 99, RFC 3969, December 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
July 2005. July 2005.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
skipping to change at page 47, line 46 skipping to change at page 47, line 42
"Best Current Practices for NAT Traversal for Client- "Best Current Practices for NAT Traversal for Client-
Server SIP", draft-ietf-sipping-nat-scenarios-09 (work in Server SIP", draft-ietf-sipping-nat-scenarios-09 (work in
progress), September 2008. progress), September 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.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[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.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[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.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP) "STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489, Through Network Address Translators (NATs)", RFC 3489,
March 2003. March 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006. Congestion Control Protocol (DCCP)", RFC 4340, March 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.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
 End of changes. 37 change blocks. 
116 lines changed or deleted 128 lines changed or added

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