draft-ietf-sip-outbound-09.txt   draft-ietf-sip-outbound-10.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 June 25, 2007 Intended status: Standards Track July 5, 2007
Expires: December 27, 2007 Expires: January 6, 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-09 draft-ietf-sip-outbound-10
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 December 27, 2007. This Internet-Draft will expire on January 6, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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 16 skipping to change at page 2, line 16
delivered on existing connections established by the User Agent. It delivered on existing connections established by the User Agent. It
also defines keep alive behaviors needed to keep NAT bindings open also defines keep alive behaviors needed to keep NAT bindings open
and specifies the usage of multiple connections. and specifies the usage of multiple connections.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Summary of Mechanism . . . . . . . . . . . . . . . . . . . 5 3.1. Summary of Mechanism . . . . . . . . . . . . . . . . . . 5
3.2. Single Registrar and UA . . . . . . . . . . . . . . . . . 6 3.2. Single Registrar and UA . . . . . . . . . . . . . . . . . 6
3.3. Multiple Connections from a User Agent . . . . . . . . . . 7 3.3. Multiple Connections from a User Agent . . . . . . . . . 7
3.4. Edge Proxies . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Edge Proxies . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Keepalive Technique . . . . . . . . . . . . . . . . . . . 11 3.5. Keepalive Technique . . . . . . . . . . . . . . . . . . . 11
3.5.1. CRLF Keepalive Technique . . . . . . . . . . . . . . . 11 3.5.1. CRLF Keepalive Technique . . . . . . . . . . . . . . . 11
3.5.2. TCP Keepalive Technique . . . . . . . . . . . . . . . 12 3.5.2. TCP Keepalive Technique . . . . . . . . . . . . . . . 12
3.5.3. STUN Keepalive Technique . . . . . . . . . . . . . . . 12 3.5.3. STUN Keepalive Technique . . . . . . . . . . . . . . . 12
4. User Agent Mechanisms . . . . . . . . . . . . . . . . . . . . 13 4. User Agent Mechanisms . . . . . . . . . . . . . . . . . . . . 13
4.1. Instance ID Creation . . . . . . . . . . . . . . . . . . . 13 4.1. Instance ID Creation . . . . . . . . . . . . . . . . . . 13
4.2. Registrations . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Registrations . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Registration by Other Instances . . . . . . . . . . . 16 4.2.1. Registration by Other Instances . . . . . . . . . . . 16
4.3. Sending Requests . . . . . . . . . . . . . . . . . . . . . 16 4.3. Sending Requests . . . . . . . . . . . . . . . . . . . . 16
4.4. Detecting Flow Failure . . . . . . . . . . . . . . . . . . 17 4.4. Detecting Flow Failure . . . . . . . . . . . . . . . . . 17
4.4.1. Keepalive with TCP KEEPALIVE . . . . . . . . . . . . . 18 4.4.1. Keepalive with TCP KEEPALIVE . . . . . . . . . . . . . 18
4.4.2. Keepalive with CRLF . . . . . . . . . . . . . . . . . 18 4.4.2. Keepalive with CRLF . . . . . . . . . . . . . . . . . 18
4.4.3. Keepalive with STUN . . . . . . . . . . . . . . . . . 18 4.4.3. Keepalive with STUN . . . . . . . . . . . . . . . . . 18
4.5. Flow Recovery . . . . . . . . . . . . . . . . . . . . . . 19 4.5. Flow Recovery . . . . . . . . . . . . . . . . . . . . . . 19
5. Edge Proxy Mechanisms . . . . . . . . . . . . . . . . . . . . 20 5. Edge Proxy Mechanisms . . . . . . . . . . . . . . . . . . . . 20
5.1. Processing Register Requests . . . . . . . . . . . . . . . 20 5.1. Processing Register Requests . . . . . . . . . . . . . . 20
5.2. Generating Flow Tokens . . . . . . . . . . . . . . . . . . 20 5.2. Generating Flow Tokens . . . . . . . . . . . . . . . . . 20
5.3. Forwarding Requests . . . . . . . . . . . . . . . . . . . 21 5.3. Forwarding Requests . . . . . . . . . . . . . . . . . . . 21
5.4. Edge Proxy Keepalive Handling . . . . . . . . . . . . . . 22 5.4. Edge Proxy Keepalive Handling . . . . . . . . . . . . . . 22
6. Registrar Mechanisms: Processing REGISTER Requests . . . . . . 22 6. Registrar Mechanisms: Processing REGISTER Requests . . . . . . 22
7. Authoritative Proxy Mechanisms: Forwarding Requests . . . . . 24 7. Authoritative Proxy Mechanisms: Forwarding Requests . . . . . 24
8. STUN Keepalive Processing . . . . . . . . . . . . . . . . . . 24 8. STUN Keepalive Processing . . . . . . . . . . . . . . . . . . 24
8.1. Use with Sigcomp . . . . . . . . . . . . . . . . . . . . . 26 8.1. Use with Sigcomp . . . . . . . . . . . . . . . . . . . . 26
9. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 26 9. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 26
10. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
11. Definition of 430 Flow Failed response code . . . . . . . . . 30 11. Definition of 430 Flow Failed response code . . . . . . . . . 30
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
12.1. Contact Header Field . . . . . . . . . . . . . . . . . . . 30 12.1. Contact Header Field . . . . . . . . . . . . . . . . . . 30
12.2. SIP/SIPS URI Parameters . . . . . . . . . . . . . . . . . 31 12.2. SIP/SIPS URI Parameters . . . . . . . . . . . . . . . . . 31
12.3. SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . 31 12.3. SIP Option Tag . . . . . . . . . . . . . . . . . . . . . 31
12.4. Response Code . . . . . . . . . . . . . . . . . . . . . . 31 12.4. Response Code . . . . . . . . . . . . . . . . . . . . . . 31
12.5. Media Feature Tag . . . . . . . . . . . . . . . . . . . . 31 12.5. Media Feature Tag . . . . . . . . . . . . . . . . . . . . 31
13. Security Considerations . . . . . . . . . . . . . . . . . . . 32 13. Security Considerations . . . . . . . . . . . . . . . . . . . 32
14. Operational Notes on Transports . . . . . . . . . . . . . . . 33 14. Operational Notes on Transports . . . . . . . . . . . . . . . 33
15. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 34 15. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 34
16. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 16. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
16.1. Changes from 08 Version . . . . . . . . . . . . . . . . . 34 16.1. Changes from 09 Version . . . . . . . . . . . . . . . . . 34
16.2. Changes from 07 Version . . . . . . . . . . . . . . . . . 34 16.2. Changes from 08 Version . . . . . . . . . . . . . . . . . 34
16.3. Changes from 06 Version . . . . . . . . . . . . . . . . . 35 16.3. Changes from 07 Version . . . . . . . . . . . . . . . . . 35
16.4. Changes from 05 Version . . . . . . . . . . . . . . . . . 35 16.4. Changes from 06 Version . . . . . . . . . . . . . . . . . 35
16.5. Changes from 04 Version . . . . . . . . . . . . . . . . . 35 16.5. Changes from 05 Version . . . . . . . . . . . . . . . . . 35
16.6. Changes from 03 Version . . . . . . . . . . . . . . . . . 36 16.6. Changes from 04 Version . . . . . . . . . . . . . . . . . 36
16.7. Changes from 02 Version . . . . . . . . . . . . . . . . . 37 16.7. Changes from 03 Version . . . . . . . . . . . . . . . . . 37
16.8. Changes from 01 Version . . . . . . . . . . . . . . . . . 37 16.8. Changes from 02 Version . . . . . . . . . . . . . . . . . 37
16.9. Changes from 00 Version . . . . . . . . . . . . . . . . . 38 16.9. Changes from 01 Version . . . . . . . . . . . . . . . . . 38
16.10. Changes from 00 Version . . . . . . . . . . . . . . . . . 38
17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38
Appendix A. Default Flow Registration Backoff Times . . . . . . . 38 Appendix A. Default Flow Registration Backoff Times . . . . . . . 38
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
18.1. Normative References . . . . . . . . . . . . . . . . . . . 39 18.1. Normative References . . . . . . . . . . . . . . . . . . 39
18.2. Informative References . . . . . . . . . . . . . . . . . . 40 18.2. Informative References . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . . . . 42 Intellectual Property and Copyright Statements . . . . . . . . . . 42
1. Introduction 1. Introduction
There are many environments for SIP [1] deployments in which the User There are many environments for SIP [1] deployments in which the User
Agent (UA) can form a connection to a Registrar or Proxy but in which Agent (UA) can form a connection to a Registrar or Proxy but in which
connections in the reverse direction to the UA are not possible. connections in the reverse direction to the UA are not possible.
This can happen for several reasons. Connections to the UA can be This can happen for several reasons. Connections to the UA can be
blocked by a firewall device between the UA and the proxy or blocked by a firewall device between the UA and the proxy or
skipping to change at page 6, line 21 skipping to change at page 6, line 21
registration has been completed. A failure on a particular flow can registration has been completed. A failure on a particular flow can
be tried again on an alternate flow. Proxies can determine which be tried again on an alternate flow. Proxies can determine which
flows go to the same UA by comparing the instance-id. Proxies can flows go to the same UA by comparing the instance-id. Proxies can
tell that a flow replaces a previously abandoned flow by looking at tell that a flow replaces a previously abandoned flow by looking at
the reg-id. the reg-id.
UAs can use a simple periodic message as a keepalive mechanism to UAs can use a simple periodic message as a keepalive mechanism to
keep their flow to the proxy or registrar alive. For connection keep their flow to the proxy or registrar alive. For connection
oriented transports such as TCP this is based on CRLF or a transport oriented transports such as TCP this is based on CRLF or a transport
specific keepalive while for transports that are not connection specific keepalive while for transports that are not connection
oriented this is accomplished by using the keepalive usage profile of oriented this is accomplished by using a SIP-specific usage profile
STUN (Session Traversal Utilities for NAT) [3]. of STUN (Session Traversal Utilities for NAT) [3].
3.2. Single Registrar and UA 3.2. Single Registrar and UA
In the topology shown below, a single server is acting as both a In the topology shown below, a single server is acting as both a
registrar and proxy. registrar and proxy.
+-----------+ +-----------+
| Registrar | | Registrar |
| Proxy | | Proxy |
+-----+-----+ +-----+-----+
skipping to change at page 22, line 8 skipping to change at page 22, line 8
requests are routed over an existing flow are not part of this requests are routed over an existing flow are not part of this
specification. However, an approach such as having the Edge Proxy specification. However, an approach such as having the Edge Proxy
Record-Route with a flow token is one way to ensure that mid-dialog Record-Route with a flow token is one way to ensure that mid-dialog
requests are routed over the correct flow. The Edge Proxy can use requests are routed over the correct flow. The Edge Proxy can use
the presence of the "ob" parameter in the UAC's Contact URI to the presence of the "ob" parameter in the UAC's Contact URI to
determine if it should add a flow token. determine if it should add a flow token.
5.4. Edge Proxy Keepalive Handling 5.4. Edge Proxy Keepalive Handling
All edge proxies compliant with this specification MUST implement All edge proxies compliant with this specification MUST implement
support for the STUN NAT Keepalive usage on its SIP UDP ports as support for STUN NAT Keepalives on its SIP UDP ports as described in
described in Section 8. Section 8.
When a server receives a double CRLF sequence on a connection When a server receives a double CRLF sequence on a connection
oriented transport such as TCP or SCTP, it MUST immediately respond oriented transport such as TCP or SCTP, it MUST immediately respond
with a single CRLF over the same connection. with a single CRLF over the same connection.
6. Registrar Mechanisms: Processing REGISTER Requests 6. Registrar Mechanisms: Processing REGISTER Requests
This specification updates the definition of a binding in RFC 3261 This specification updates the definition of a binding in RFC 3261
[1] Section 10 and RFC 3327 [5] Section 5.3. [1] Section 10 and RFC 3327 [5] Section 5.3.
skipping to change at page 23, line 45 skipping to change at page 23, line 45
outbound processing by ignoring the reg-id parameter as described in outbound processing by ignoring the reg-id parameter as described in
this specification. Note that the requirements in this section this specification. Note that the requirements in this section
applies to both REGISTER requests received from an Edge Proxy as well applies to both REGISTER requests received from an Edge Proxy as well
as requests received directly from the UAC. The Registrar MAY be as requests received directly from the UAC. The Registrar MAY be
configured with local policy to reject any registrations that do not configured with local policy to reject any registrations that do not
include the instance-id and reg-id, or with Path header field values include the instance-id and reg-id, or with Path header field values
that do not contain the 'ob' parameter. that do not contain the 'ob' parameter.
To be compliant with this specification, registrars which can receive To be compliant with this specification, registrars which can receive
SIP requests directly from a UAC without intervening edge proxies SIP requests directly from a UAC without intervening edge proxies
MUST implement the STUN NAT Keepalive usage on its SIP UDP ports as MUST implement STUN NAT Keepalives on its SIP UDP ports as described
described in Section 8 and when it receives a double-CRLF sequence on in Section 8 and when it receives a double-CRLF sequence on a
a connection oriented transport such as TCP or SCTP, it MUST 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.
7. Authoritative Proxy Mechanisms: Forwarding Requests 7. Authoritative Proxy Mechanisms: Forwarding Requests
When a proxy uses the location service to look up a registration When a proxy uses the location service to look up a registration
binding and then proxies a request to a particular contact, it binding and then proxies a request to a particular contact, it
selects a contact to use normally, with a few additional rules: selects a contact to use normally, with a few additional rules:
o The proxy MUST NOT populate the target set with more than one o The proxy MUST NOT populate the target set with more than one
contact with the same AOR and instance-id at a time. contact with the same AOR and instance-id at a time.
skipping to change at page 24, line 50 skipping to change at page 24, line 50
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.
8. STUN Keepalive Processing 8. STUN Keepalive Processing
This section describes changes to the SIP transport layer that allow This section describes changes to the SIP transport layer that allow
SIP and the STUN [3] NAT Keepalive usage to be mixed over the same SIP and the STUN [3] Binding Requests to be mixed over the same flow.
flow. The STUN messages are used to verify that connectivity is This constitues a new STUN usage. The STUN messages are used to
still available over a UDP flow, and to provide periodic keepalives. verify that connectivity is still available over a UDP flow, and to
Note that these STUN keepalives are always sent to the next SIP hop. provide periodic keepalives. Note that these STUN keepalives are
STUN messages are not delivered end-to-end. always sent to the next SIP hop. STUN messages are not delivered
end-to-end.
The only STUN messages required by this usage are Binding Requests, The only STUN messages required by this usage are Binding Requests,
Binding Responses, and Binding Error Responses. The UAC sends Binding Responses, and Binding Error Responses. The UAC sends
Binding Requests over the same UDP flow that is used for sending SIP Binding Requests over the same UDP flow that is used for sending SIP
messages. These Binding Requests do not require any STUN attributes. messages. These Binding Requests do not require any STUN attributes
The UAS responds to a valid Binding Request with a Binding Response and never use any form of authentication. The UAS responds to a
which MUST include the XOR-MAPPED-ADDRESS attribute. valid Binding Request with a Binding Response 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 port, it MUST also provide a limited version of a given interface and port, it MUST also provide a limited version of a
STUN server on the same interface and port as described in Section STUN server on the same interface and port as described in Section
12.3 of [3]. 12.3 of [3].
It is easy to distinguish STUN and SIP packets sent over UDP, It is easy to distinguish STUN and SIP packets sent over UDP,
because the first octet of a STUN packet has a value of 0 or 1 because the first octet of a STUN packet has a value of 0 or 1
while the first octet of a SIP message is never a 0 or 1. while the first octet of a SIP message is never a 0 or 1.
skipping to change at page 26, line 12 skipping to change at page 26, line 17
to a new target destination, before sending any STUN messages. to a new target destination, before sending any STUN messages.
When scheduled for the next NAT refresh, the SIP node sends a STUN When scheduled for the next NAT refresh, the SIP node sends a STUN
request to the target. request to the 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.
The SIP keepalive STUN usage requires no backwards compatibility.
8.1. Use with Sigcomp 8.1. Use with Sigcomp
When STUN is used together with SigComp [24] compressed SIP messages When STUN is used together with SigComp [24] compressed SIP messages
over the same flow, how the STUN messages are sent depends on the over the same flow, how the STUN messages are sent depends on the
transport protocol. For UDP flows, the STUN messages are simply sent transport protocol. For UDP flows, 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.
skipping to change at page 34, line 22 skipping to change at page 34, line 22
4. Detect failure of a connection and be able to correct for this. 4. Detect failure of a connection and be able to correct for this.
5. Support many UAs simultaneously rebooting. 5. Support many UAs simultaneously rebooting.
6. Support a NAT rebooting or resetting. 6. Support a NAT rebooting or resetting.
7. Minimize initial startup load on a proxy. 7. Minimize initial startup load on a proxy.
8. Support architectures with edge proxies. 8. Support architectures with edge proxies.
16. Changes 16. Changes
Note to RFC Editor: Please remove this whole section. Note to RFC Editor: Please remove this whole section.
16.1. Changes from 08 Version 16.1. Changes from 09 Version
Make outbound consistent with the latest version of STUN 3489bis
draft. The STUN keepalive section of outbound is now a STUN usage
(much less formal).
Fixed references.
16.2. Changes from 08 Version
UAs now include the 'ob' parameter in their Contact header for non- UAs now include the 'ob' parameter in their Contact header for non-
REGISTER requests, as a hint to the Edge Proxy (so the EP can Record- REGISTER requests, as a hint to the Edge Proxy (so the EP can Record-
Route with a flow-token for example). Route with a flow-token for example).
Switched to CRLF for keepalives of connection-oriented transports Switched to CRLF for keepalives of connection-oriented transports
after brutal consensus at IETF 68. after brutal consensus at IETF 68.
Added timed-keepalive parameter and removed the unnecessary keep-tcp Added timed-keepalive parameter and removed the unnecessary keep-tcp
param, per consensus at IETF68. param, per consensus at IETF68.
skipping to change at page 34, line 45 skipping to change at page 35, line 5
consensus at IETF68. consensus at IETF68.
Deleted text about probing and validating with options, per consensus Deleted text about probing and validating with options, per consensus
at IETF68. at IETF68.
Deleted provision for waiting 120 secs before declaring flow stable, Deleted provision for waiting 120 secs before declaring flow stable,
per consensus at IETF68. per consensus at IETF68.
fixed example UUIDs fixed example UUIDs
16.2. Changes from 07 Version 16.3. Changes from 07 Version
Add language to show the working group what adding CRLF keepalives Add language to show the working group what adding CRLF keepalives
would look like. would look like.
Changed syntax of keep-alive=stun to keep-stun so that it was easier Changed syntax of keep-alive=stun to keep-stun so that it was easier
to support multiple tags in the same URI. to support multiple tags in the same URI.
16.3. Changes from 06 Version 16.4. Changes from 06 Version
Added the section on operational selection of transports. Added the section on operational selection of transports.
Fixed various editorial typos. Fixed various editorial typos.
Put back in requirement flow token needs to be unique to flow as it Put back in requirement flow token needs to be unique to flow as it
had accidentally been dropped in earlier version. This did not had accidentally been dropped in earlier version. This did not
change any of the flow token algorithms. change any of the flow token algorithms.
Reordered some of the text on STUN keepalive validation to make it Reordered some of the text on STUN keepalive validation to make it
clearer to implementors. Did not change the actual algorithm or clearer to implementors. Did not change the actual algorithm or
requirements. Added note to explain how if the proxy changes, the requirements. Added note to explain how if the proxy changes, the
revalidation will happen. revalidation will happen.
16.4. Changes from 05 Version 16.5. Changes from 05 Version
Mention the relevance of the 'rport' parameter. Mention the relevance of the 'rport' parameter.
Change registrar verification so that only first-hop proxy and the Change registrar verification so that only first-hop proxy and the
registrar need to support outbound. Other intermediaries in between registrar need to support outbound. Other intermediaries in between
do not any more. do not any more.
Relaxed flow-token language slightly. Instead of flow-token saving Relaxed flow-token language slightly. Instead of flow-token saving
specific UDP address/port tuples over which the request arrived, make specific UDP address/port tuples over which the request arrived, make
language fuzzy to save token which points to a 'logical flow' that is language fuzzy to save token which points to a 'logical flow' that is
skipping to change at page 35, line 43 skipping to change at page 36, line 5
Added comment that keep-stun could be added to Path. Added comment that keep-stun could be added to Path.
Added comment that battery concerns could motivate longer TCP Added comment that battery concerns could motivate longer TCP
keepalive intervals than the defaults. keepalive intervals than the defaults.
Scrubbed document for avoidable lowercase may, should, and must. Scrubbed document for avoidable lowercase may, should, and must.
Added text about how Edge Proxies could determine they are the first Added text about how Edge Proxies could determine they are the first
hop. hop.
16.5. Changes from 04 Version 16.6. Changes from 04 Version
Moved STUN to a separate section. Reference this section from within Moved STUN to a separate section. Reference this section from within
the relevant sections in the rest of the document. the relevant sections in the rest of the document.
Add language clarifying that UA MUST NOT send STUN without an Add language clarifying that UA MUST NOT send STUN without an
explicit indication the server supports STUN. explicit indication the server supports STUN.
Add language describing that UA MUST stop sending STUN if it appears Add language describing that UA MUST stop sending STUN if it appears
the server does not support it. the server does not support it.
skipping to change at page 36, line 49 skipping to change at page 37, line 11
Added text about the 'ob' parameter which is used in Path header Added text about the 'ob' parameter which is used in Path header
field URIs to make sure that the previous proxy that added a Path field URIs to make sure that the previous proxy that added a Path
understood outbound processing. The registrar doesn't include understood outbound processing. The registrar doesn't include
Supported: outbound unless it could actually do outbound processing Supported: outbound unless it could actually do outbound processing
(ex: any Path headers have to have the 'ob' parameter). (ex: any Path headers have to have the 'ob' parameter).
Added some text describing what a registration means when there is an Added some text describing what a registration means when there is an
instance-id, but no reg-id. instance-id, but no reg-id.
16.6. Changes from 03 Version 16.7. Changes from 03 Version
Added non-normative text motivating STUN vs. SIP PING, OPTIONS, and Added non-normative text motivating STUN vs. SIP PING, OPTIONS, and
Double CRLF. Added discussion about why TCP Keepalives are not Double CRLF. Added discussion about why TCP Keepalives are not
always available. always available.
Explained more clearly that outbound-proxy-set can be "configured" Explained more clearly that outbound-proxy-set can be "configured"
using any current or future, manual or automatic configuration/ using any current or future, manual or automatic configuration/
discovery mechanism. discovery mechanism.
Added a sentence which prevents an Edge Proxy from forwarding back Added a sentence which prevents an Edge Proxy from forwarding back
skipping to change at page 37, line 32 skipping to change at page 37, line 43
by Bill Fenner. by Bill Fenner.
Added a table in an appendix expanding the default flow recovery Added a table in an appendix expanding the default flow recovery
timers. timers.
Incorporated numerous clarifications and rewordings for better Incorporated numerous clarifications and rewordings for better
comprehension. comprehension.
Fixed many typos and spelling steaks. Fixed many typos and spelling steaks.
16.7. Changes from 02 Version 16.8. Changes from 02 Version
Removed Double CRLF Keepalive Removed Double CRLF Keepalive
Changed ;sip-stun syntax to ;keepalive=stun Changed ;sip-stun syntax to ;keepalive=stun
Fixed incorrect text about TCP keepalives. Fixed incorrect text about TCP keepalives.
16.8. Changes from 01 Version 16.9. Changes from 01 Version
Moved definition of instance-id from GRUU[25] draft to this draft. Moved definition of instance-id from GRUU[25] draft to this draft.
Added tentative text about Double CRLF Keepalive Added tentative text about Double CRLF Keepalive
Removed pin-route stuff Removed pin-route stuff
Changed the name of "flow-id" to "reg-id" Changed the name of "flow-id" to "reg-id"
Reorganized document flow Reorganized document flow
skipping to change at page 38, line 4 skipping to change at page 38, line 16
Moved definition of instance-id from GRUU[25] draft to this draft. Moved definition of instance-id from GRUU[25] draft to this draft.
Added tentative text about Double CRLF Keepalive Added tentative text about Double CRLF Keepalive
Removed pin-route stuff Removed pin-route stuff
Changed the name of "flow-id" to "reg-id" Changed the name of "flow-id" to "reg-id"
Reorganized document flow Reorganized document flow
Described the use of STUN as a proper STUN usage Described the use of STUN as a proper STUN usage
Added 'outbound' option-tag to detect if registrar supports outbound Added 'outbound' option-tag to detect if registrar supports outbound
16.9. Changes from 00 Version 16.10. Changes from 00 Version
Moved TCP keepalive to be STUN. Moved TCP keepalive to be STUN.
Allowed SUBSCRIBE to create flow mappings. Added pin-route option Allowed SUBSCRIBE to create flow mappings. Added pin-route option
tags to support this. tags to support this.
Added text about updating dialog state on each usage after a Added text about updating dialog state on each usage after a
connection failure. connection failure.
17. Acknowledgments 17. Acknowledgments
skipping to change at page 39, line 29 skipping to change at page 39, line 33
18.1. Normative References 18.1. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Rosenberg, J., "Simple Traversal Underneath Network Address [3] Rosenberg, J., "Simple Traversal Underneath Network Address
Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-05 Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-07
(work in progress), October 2006. (work in progress), July 2007.
[4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol [4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002. (SIP): Locating SIP Servers", RFC 3263, June 2002.
[5] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) [5] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
Extension Header Field for Registering Non-Adjacent Contacts", Extension Header Field for Registering Non-Adjacent Contacts",
RFC 3327, December 2002. RFC 3327, December 2002.
[6] Leach, P., Mealling, M., and R. Salz, "A Universally Unique [6] Leach, P., Mealling, M., and R. Salz, "A Universally Unique
IDentifier (UUID) URN Namespace", RFC 4122, July 2005. IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
skipping to change at page 40, line 40 skipping to change at page 40, line 44
Uniform Resource Identifier (URI) Parameter Registry for the Uniform Resource Identifier (URI) Parameter Registry for the
Session Initiation Protocol (SIP)", BCP 99, RFC 3969, Session Initiation Protocol (SIP)", BCP 99, RFC 3969,
December 2004. December 2004.
[18] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag [18] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag
Registration Procedure", BCP 31, RFC 2506, March 1999. Registration Procedure", BCP 31, RFC 2506, March 1999.
18.2. Informative References 18.2. Informative References
[19] Petrie, D., "A Framework for Session Initiation Protocol User [19] Petrie, D., "A Framework for Session Initiation Protocol User
Agent Profile Delivery", draft-ietf-sipping-config-framework-09 Agent Profile Delivery", draft-ietf-sipping-config-framework-12
(work in progress), October 2006. (work in progress).
[20] Hakala, J., "Using National Bibliography Numbers as Uniform [20] Hakala, J., "Using National Bibliography Numbers as Uniform
Resource Names", RFC 3188, October 2001. Resource Names", RFC 3188, October 2001.
[21] Rosenberg, J., "Construction of the Route Header Field in the [21] Rosenberg, J., "Construction of the Route Header Field in the
Session Initiation Protocol (SIP)", Session Initiation Protocol (SIP)",
draft-rosenberg-sip-route-construct-02 (work in progress), draft-rosenberg-sip-route-construct-02 (work in progress).
October 2006.
[22] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) [22] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
Extension Header Field for Service Route Discovery During Extension Header Field for Service Route Discovery During
Registration", RFC 3608, October 2003. Registration", RFC 3608, October 2003.
[23] Boulton, C., "Best Current Practices for NAT Traversal for [23] Boulton, C., "Best Current Practices for NAT Traversal for
SIP", draft-ietf-sipping-nat-scenarios-05 (work in progress), SIP", draft-ietf-sipping-nat-scenarios-06 (work in progress).
June 2006.
[24] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, [24] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu,
Z., and J. Rosenberg, "Signaling Compression (SigComp)", Z., and J. Rosenberg, "Signaling Compression (SigComp)",
RFC 3320, January 2003. RFC 3320, January 2003.
[25] Rosenberg, J., "Obtaining and Using Globally Routable User [25] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-11 (work in progress), (SIP)", draft-ietf-sip-gruu-14 (work in progress).
October 2006.
Authors' Addresses Authors' Addresses
Cullen Jennings (editor) Cullen Jennings (editor)
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
Mailstop SJC-21/2 Mailstop SJC-21/2
San Jose, CA 95134 San Jose, CA 95134
USA USA
 End of changes. 34 change blocks. 
60 lines changed or deleted 71 lines changed or added

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