< 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 14 ¶		skipping to change at page 2, line 14 ¶
	Agents in this way. This specification defines behaviors for User		Agents in this way. This specification defines behaviors for User
	Agents, registrars and proxy servers that allow requests to be		Agents, registrars and proxy servers that allow requests to be
	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.
	70 lines changed or deleted		81 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/