< draft-ietf-mmusic-sip-100rel-00.txt		draft-ietf-mmusic-sip-100rel-01.txt >
	Internet Engineering Task Force MMUSIC WG		Internet Engineering Task Force MMUSIC WG
	Internet Draft J.Rosenberg,H.Schulzrinne		Internet Draft J.Rosenberg,H.Schulzrinne
	draft-ietf-mmusic-sip-100rel-00.txt Bell Laboratories,Columbia U.		draft-ietf-mmusic-sip-100rel-01.txt Bell Laboratories,Columbia U.
	November 18, 1998		May 20, 1999
	Expires: May 1999		Expires: November 20, 1999
	Reliability of Provisional Responses in SIP		Reliability of Provisional Responses in SIP
	STATUS OF THIS MEMO		STATUS OF THIS MEMO
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft and is in full conformance with
	documents of the Internet Engineering Task Force (IETF), its areas,		all provisions of Section 10 of RFC2026.
	and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		Internet-Drafts are working documents of the Internet Engineering
			Task Force (IETF), its areas, and its working groups. Note that
			other groups may also distribute working documents as Internet-
			Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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.
	To learn the current status of any Internet-Draft, please check the		The list of current Internet-Drafts can be accessed at
	``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow		http://www.ietf.org/ietf/1id-abstracts.txt
	Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
	munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
	ftp.isi.edu (US West Coast).
	Distribution of this document is unlimited.		The list of Internet-Draft Shadow Directories can be accessed at
			http://www.ietf.org/shadow.html.
	1 Abstract		Abstract
	This document specifies an extension to the Session Initiation		This document specifies an extension to the Session Initiation
	Protocol (SIP) providing reliable provisional response messages.		Protocol (SIP) providing reliable provisional response messages.
	2 Introduction		1 Introduction
	The Session Initiation Protocol (SIP) [1] is a request-response		The Session Initiation Protocol (SIP) [1] is a request-response
	protocol for initiating, maintaining, and terminating multimedia		protocol for initiating, maintaining, and terminating multimedia
	sessions. Each SIP request is followed by one or more provisional		sessions. Each SIP request is followed by one or more provisional
	responses, followed by a one or more definitive responses. These		responses, followed by a one or more definitive responses. These
	provisional responses, also called informational responses, have		provisional responses, also called informational responses, have
	status codes within the 100-199 range. They provide information on		status codes within the 100-199 range. They are most commonly used
	call progress, such as trying (100), alerting (180), and queuing		for responses to an INVITE request. They provide information on call
	(181). However, when run over UDP, SIP does not guarantee that these		progress, such as trying (100), alerting (180), and queueing (182).
	messages are delivered reliably, or in order. A server simply		However, when run over UDP, SIP does not guarantee that these
	transmits a provisional response. If the client retransmits the		messages are delivered reliably, or in order.
	request, the server retransmits the most recent response, provisional
	or otherwise.
	However, a number of applications require reliability and in-order		However, a number of applications require reliability and in-order
	delivery of provisional responses. These include gateway		delivery of provisional responses to INVITE. These include gateway
	applications, wireless phones, ACD servers, and call queueing		applications, wireless phones, ACD servers, and call queueing
	systems. Generally, these applications make use of the provisional		systems. Generally, these applications make use of the provisional
	responses to drive state machinery. This is especially true for the		responses to drive state machinery. This is especially true for the
	180 Ringing provisional response, which maps to the Q.931 ALERTING		180 Ringing provisional response, which maps to the Q.931 ALERTING
	message.		message.
	This document provides a simple extension to SIP for ensuring that		This document provides a simple extension to SIP for ensuring that
	provisional responses are delivered reliably, independent of the		provisional responses to INVITEs are delivered reliably, independent
	underlying transport mechanism. The extension is simple, requiring		of the underlying transport mechanism. The extension applies only to
	two new header fields, and no new methods. It fits well within the		the INVITE method. Reliability of provisional responses for other
	generic framework of SIP reliability.		methods is not provided. The extension is simple, requiring two new
			header fields, and no new methods. It fits well within the generic
			framework of SIP reliability. It is partly backwards compatible, so
			that a Require header is not needed (it can be included if the UAC
			insists on the feature, of course), although a Proxy-Require header
			is needed.
			2 Terminology
			In this document, the key words "MUST", "MUST NOT", "REQUIRED",
			"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
			and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and
			indicate requirement levels for compliant implementations.
	3 Overview		3 Overview
	The reliability mechanism is based on the standard windowed		The reliability mechanism is based on the standard windowed
	acknowledgement technique. When a server generates a provisional		acknowledgement technique. When a server generates a provisional
	response, it places a sequence number (via the RSeq header field) in		response which is to be delivered reliably, it places a sequence
	the provisional response. The sequence number always starts at zero.		number (via the RSeq header field) in the provisional response. These
	The sequence number space need only be unique within each Call-ID,		sequence numbers always start at zero, since they are defined only
	To, and CSeq tuple. Because of this, there is no need for randomized		within the context of a transaction. This elimiates the need for SYN
	sequence number selection or SYN handshakes as in TCP.		handshakes as in TCP. The provisional response is then retransmitted
			with an exponential backoff.
			The UAC maintains a variable, sn, which is the highest sequence
			number seen in a reliable response. When the client receives a
			provisional response that has been sent reliably, and this response
			has a sequence number one higher than sn, sn is incremented, and the
			request is retransmitted. Otherwise, if the response has a sequence
			number greater than one higher, sn is not incremented. Either way,
			the request is retransmitted, and the value of sn is placed in the
			RAck header in the request.
			When the server sees a request retransmission with an RAck header
			with a value equalling the sequence number in the last reliably
			transmitted response, it stops retransmitting that response, and is
			free to send the next provisional response, with a higher sequence
			number.
			The mechanism is similar to TCP, but with a constant window of one.
			The use of a fixed size window comes at the penalty of reduced
			response throughput. The througput of responses is fairly low (1 per
			RTT without loss, lower with loss). However, as the provisional
			responses are used to signal changes in phone call states, which
			generally occur on timescales on the order of hundreds of
			milliseconds to seconds, such a limited throughput appears
			acceptable. The mechanism can be extended to support larger window
			sizes, if necessary.
			The server can still generate unreliable provisional responses by
			sending them without an RSeq header. A UAC which receives a
			provisional response without a RSeq does not retransmit the request.
			This allows for backwards compatibility; a UAS which doesn't know how
			to transmit reliable responses will never place an RSeq header in a
			response, and so the SIP transaction will proceed normally.
			Similarly, the initial INVITE from the client contains an RAck
			header. This serves as an indicator to the server than the client
			supports the reliability mechanism. A UAS which doesn't see this
			header in a request knows it cannot provide reliable provisional
			responses.
			4 Detailed Protocol Semantics
			A transaction begins when the client sends a request. The client
			sends the INVITE request as per RFC2543 [1]. The RAck header MUST be
			placed in the request, with a value of zero, if the client
			understands and is willing to support this extension for the
			transaction.
			When the initial INVITE is received by the server, it MAY send a 100
			response (depending on whether it is a proxy or not). A 100 response
			is normally sent reliably according to the current SIP specification.
			This is because the client retransmits its request until a response
			(i.e., 100) is received, and the server retransmits the 100 response
			upon request retransmission. As a result, no additional means is
			needed to reliably send a 100 response over a single hop.
			Furthermore, the SIP specification mandates that the 100 response is
			not forwarded through a proxy. For these reasons, 100 responses MUST
			NOT contain an RSeq header.
	The server maintains a window of size 1, which is effectively the		The server maintains a window of size 1, which is effectively the
	value of the highest unacknowledged provisional response that has		value of the highest unacknowledged provisional response that has
	been transmitted, call this rn. The client maintains a single		been transmitted; call this rn. The client maintains a single
	variable, sn, which represents the highest in order provisional		variable, sn, which represents the highest in order provisional
	response received so far. Both sn and rn are initialized to -1.		response received so far. Both sn and rn MUST be initialized to 0.
	When the server wishes to send a provisional response, it increments		The server MAY send a reliable response if the initial INVITE request
	rn, places its value in the RSeq header field, and sends the		from the client contained a RAck header with a value of 0. If the
	response. The provisional response is retransmitted at intervals with		request contained a Require header, and the server is a UAS, the UAS
	an exponential backoff, starting at T1 (default of 500ms), and		SHOULD send all non-100 provisional responses reliably. If the
	doubling after each retransmission. When the client receives the		request contained a Proxy-Require header, and the server is a proxy,
	response, it checks the sequence number. If it is one higher than the		the server SHOULD send all locally generated non-100 provisional
	current value of sn, sn is incremented, otherwise sn is unchanged. It		responses reliably. It also SHOULD reliably send upstream any
	then resends the original request (independently of whether the value		responses received reliably from a downstream server. The server MUST
	of sn has changed), and includes the sequence number sn in the		NOT send a reliable response if the initial INVITE request did not
	request in the header field RAck.		contain an RAck header with a value of zero. When the server decides
			to send a provisional response reliably, it MUST increment rn, and
			MUST place this incremented value in the RSeq header in the response.
			The provisional response SHOULD be retransmitted at intervals with an
			exponential backoff, starting at T1 (default of 500ms), and doubling
			after each retransmission.
	When the request is received at the server, if the sequence number in		When a client receives a provisional response, it checks for the
	the message is equal to the current value of rn, the provisional		presence of the RSeq header. If it is not present, the response was
	response is no longer retransmitted. The server is free to increment		an unreliable provisional response. The client MUST NOT retransmit
	rn and transmit another provisional response. If the value of the		the request. As per [1], the client also ceases exponentially backing
	sequence number in the request is one less than the current value of		off request retransmissions when any response (with or without the
	rn, the response is retransmitted, and the server may not generate an		RSeq header) is received.
	additional provisional response.
	The mechanism is essentially TCP without congestion control, and with		If the server does not understand this extension, it will
	a window of one. The result is a fairly simple mechanism. However,		behave according to the base SIP specification, and
	the penalty is that the throughput of provisional responses is fairly		retransmit responses upon request retransmissions. A client
	low (1 per RTT without loss, lower with loss). However, as the		which retransmits requests upon response retransmissions
	provisional responses are used to signal changes in phone call		would cause a feedback loop of constant request and
	states, which generally occur on timescales on the order of hundreds		response retransmissions. By checking for the RSeq header,
	of milliseconds to seconds, such a limited throughput appears		the client can determine whether the server is supporting
	acceptable. The mechanism can be extended to support larger window		this extension for this response.
	sizes, if necessary.
	4 Header Fields		If, however, the provisional response contains an RSeq header, the
			value is compared against sn. If it is one higher than the current
			value of sn, sn is incremented, otherwise sn is unchanged. The client
			SHOULD then resend the original request (independently of whether the
			value of sn has changed), and MUST include the sequence number sn in
			the request in the header field RAck.
	Two new header fields are defined, RSeq and RAck. The BNF for these		When a request is received at a server, it checks for the presence of
			the RAck header. If it is not present, the server retransmits the
			last response that was sent. If the RAck header is present, and the
			value is lower than the value of rn, the last reliable response is
			retransmitted. If the RAck header was present in the request, and the
			value is equal to the current value of rn, the exponentially backing
			off response retransmissions cease. Additional copies of the request
			with the same or lower value of RAck that are received by the server
			SHOULD NOT cause the server to retransmit any response (as they would
			in the above case if RAck were lower), unless rn is zero. The server
			always retransmits the last response sent (provisional, reliable
			provisional, or otherwise) when a request is received with both RAck
			and rn equal to 0.
			This handles the case where a proxy server doesn't send a
			100 response, but transmits a reliable response as the
			first response. To make sure the initial request is
			transmitted reliably, the server has to retransmit the
			first response upon request retransmissions.
			Once a request has arrived with RAck equal to rn, the server is free
			to increment rn and transmit another provisional response. The server
			MUST NOT ever generate an additional reliable response until it has
			received a request with an RAck header with a value equal to rn.
			When the server is ready to send a final response, it does so
			according to [1]. An ACK request causes retransmissions of the final
			response to cease. The server SHOULD NOT continue to retransmit any
			reliable provisional responses once a final response has been sent.
			5 Header Syntax
			Two new header fields are defined, RSeq and RAck. The BNF for these
	are:		are:
	RSeq = "RSeq" ":" 1*DIGIT		RSeq = "RSeq" ":" 1*DIGIT
	RAck = "RAck" ":" 1*DIGIT		RAck = "RAck" ":" 1*DIGIT
	RSeq is a response header field. It is mandatory when used with this		RSeq is a response header field. RAck is a request header field.
	extension. RAck is a request header field. It is mandatory when used
	with this extension.
	The use of reliable provisional responses is signaled by the UAC to		If a client insists that all provisional responses (those generated
	the UAS through the Requires header field. This document specifies		by proxies and UAS's) be sent reliably, it MUST include both the
	the named extension org.ietf.sip.reliable-100 requests which require		Require and Proxy-Require headers in all requests. A UAC MAY
	reliable 100's must include this name in the Requires header field		alternately send requests only with the Proxy-Require header. This
	and in the Proxy-Require header field, as proxies need to		will cause all non-100 provisional responses generated by proxies to
	participate.		be sent reliably. Responses sent by UAS's may, or may not be sent
			reliably, at the discretion of the UAS.
	5 Operation with Proxies		This document specifies the named extension org.ietf.sip.reliable-
			100.
			6 Operation with Proxies
	A SIP request may pass through any number of proxies, some of which		A SIP request may pass through any number of proxies, some of which
	may fork the request. Furthermore, the SIP specification allows		may fork the request. The reliability mechanism defined here requires
	proxies to pass back provisional responses (except for the 100		proxies to be aware of the extension. Consider what would happen if a
	response) upstream at the discretion of the administrator. If		proxy receives a request with a RSeq header, but no Proxy-Require
	reliability of provisional responses were done end-to-end only, an		header, and the proxy does not know the extension. As per normal SIP
	intermediate proxy which discards provisional responses by default		rules, the proxy would forward the request, with the RSeq header in
	would interfere with the reliability. As such, all intermediate		tact, to the downstream proxy. If that proxy did understand the
	proxies must be aware of the use of the mechanism, and participate.		extension, it might try and send a reliable response to the first
			proxy. The first proxy would see the provisional response
			retransmissions, but never resend the request. This would cause an
			excess of network traffic, and block transmission of other
			provisional responses at the downstream proxy.
	As a result, reliability of provisional responses is done hop-by-hop,		The situation would be even more catastrophic for a forking proxy.
	similar to the way non-200-class final responses are handled in		Consider the case where the first proxy forks the request to
	normal SIP operation. Stateless proxies can simply forward all		downstream proxies A and B. Both A and B understand the extension,
	provisional responses upstream, ignoring the reliability		and each try to send a reliable response. The first proxy forwards
	requirements. A stateful proxy must act as a virtual UAS-UAC in the		both responses upstream. But, since it does not understand the
	algorithm described in the previous section. Once a provisional		extension, it does not remove or change the value of the RSeq header
	response has been received reliably at a proxy, the proxy can		in either response. Thus, the client receiving these requests will
	reliably transmit it upstream towards the next stateful proxy, or may		think they are retransmissions, rather than being two separate
	discard it.		responses.
			Implementation of this extension in a stateless proxy is not done
			according to the rules in section 4. A stateless proxy implementing
			this extension MUST forward all requests it receives downstream, and
			MUST forward all responses it receives upstream, including
			provisional responses. Actual reliability is achieved between the
			first pair of stateful proxies.
			A stateful proxy implementing this extension MUST act as a virtual
			UAS-UAC in the algorithm described in the previous section. When any
			non-100 provisional response is received reliably at a proxy, the
			proxy MUST reliably transmit it upstream towards the next stateful
			proxy. When any non-100 provisional response is received unreliably
			at the proxy, the proxy MUST send the response unreliably upstream.
			Any provisional responses generated by the proxy itself (excepting
			100) MUST be sent reliably upstream.
	Since a proxy may be receiving reliable provisional responses from		Since a proxy may be receiving reliable provisional responses from
	several branches of a forked request, it will need to merge the		several branches of a forked request, it will need to merge the
	provisional response streams together. There are no requirements		provisional response streams together. There are no requirements
	about the ordering of provisional responses across branches. However,		about the ordering of provisional responses across branches. However,
	all provisional responses from a given branch must be transmitted		all provisional responses from a given branch MUST be transmitted
	reliably upstream in the same order they were received along a		reliably upstream in the same order they were received along a
	branch. For example, consider a forking proxy A which sends a request		branch. For example, consider a forking proxy A which sends a request
	to UAS's B and C. B sends provisional response 0 towards A, and once		to UAS's B and C. B sends provisional response 0 towards A, and once
	it has been received, sends response 1. Similarly, B sends		it has been received, sends response 1. Similarly, B sends
	provisional response 2, and once received and acknowledged by A,		provisional response 2, and once received and acknowledged by A,
	sends provisional response 3. Proxy A may forward the provisional		sends provisional response 3. Proxy A may forward the provisional
	responses towards the UAS in any one of the following orders:		responses towards the UAS in any one of the following orders:
	0,1,2,3		0,1,2,3
	0,2,1,3		0,2,1,3
	2,3,0,1		2,3,0,1
	2,0,3,1		2,0,3,1
	0,2,3,1		0,2,3,1
	2,0,1,3		2,0,1,3
	Since responses from several branches may be merged at a forking		Since responses from several branches may be merged at a forking
	proxy, a proxy may need to renumber the provisional responses (always		proxy, a proxy MUST renumber the provisional responses (always
	starting at zero, however) when forwarding them upstream. As this		starting at zero, however) when forwarding them upstream. As this
	requires changing the RSeq value, the RSeq header field cannot be		requires changing the RSeq value, the RSeq header field cannot be
	protected by either end-to-end encryption or authentication.		protected by either end-to-end encryption or authentication.
	Similarly, a stateful proxy will need to insert the RAck header field		Similarly, a stateful proxy will need to remove the RAck header from
	itself in all proxied requests.		all requests it receives, and insert its own value into proxied
			requests.
	6 Example		7 Examples
			7.1 Message Formatting
	In this example, a UAC wishes to send an INVITE message and receive		In this example, a UAC wishes to send an INVITE message and receive
	reliable 100-class responses. Such an INVITE might look like:		reliable 100-class responses. Such an INVITE might look like:
	C->S: INVITE sip:watson@bell-tel.com SIP/2.0		C->S: INVITE sip:watson@bell-tel.com SIP/2.0
	Via: SIP/2.0/UDP saturn.bell-tel.com		Via: SIP/2.0/UDP saturn.bell-tel.com
			RAck: 0
	From: sip:alexander@bell-tel.com		From: sip:alexander@bell-tel.com
	To: sip:watson@bell-tel.com		To: sip:watson@bell-tel.com
	Call-ID: 70710@saturn.bell-tel.com		Call-ID: 70710@saturn.bell-tel.com
	CSeq: 1 INVITE		CSeq: 1 INVITE
	Subject: Come here Watson		Subject: Come here Watson
	Require: org.ietf.sip.reliable-100		Require: org.ietf.sip.reliable-100
	Proxy-Require: org.ietf.sip.reliable-100		Proxy-Require: org.ietf.sip.reliable-100
	The server wishes to send a 180 Ringing provisional response		The server wishes to send a 180 Ringing provisional response
	reliably. The response will look like:		reliably. The response will look like:
	S->C: SIP/2.0 180 Ringing		S->C: SIP/2.0 180 Ringing
	Via: SIP/2.0/UDP saturn.bell-tel.com		Via: SIP/2.0/UDP saturn.bell-tel.com
	RSeq: 0		RSeq: 1
	From: sip:alexander@bell-tel.com		From: sip:alexander@bell-tel.com
	To: sip:watson@bell-tel.com		To: sip:watson@bell-tel.com
	Call-ID: 70710@saturn.bell-tel.com		Call-ID: 70710@saturn.bell-tel.com
	CSeq: 1 INVITE		CSeq: 1 INVITE
	This response is retransmitted with an exponential backoff. When the		This response is retransmitted with an exponential backoff. When the
	UAC receives the response, it retransmits the request, but adds the		UAC receives the response, it retransmits the request, but adds the
	RAck header field:		RAck header field:
	C->S: INVITE sip:watson@bell-tel.com SIP/2.0		C->S: INVITE sip:watson@bell-tel.com SIP/2.0
	RAck: 0		RAck: 1
	Via: SIP/2.0/UDP saturn.bell-tel.com		Via: SIP/2.0/UDP saturn.bell-tel.com
	From: sip:alexander@bell-tel.com		From: sip:alexander@bell-tel.com
	To: sip:watson@bell-tel.com		To: sip:watson@bell-tel.com
	Call-ID: 70710@saturn.bell-tel.com		Call-ID: 70710@saturn.bell-tel.com
	CSeq: 1 INVITE		CSeq: 1 INVITE
	Subject: Come here Watson		Subject: Come here Watson
	Require: org.ietf.sip.reliable-100		Require: org.ietf.sip.reliable-100
	Proxy-Require: org.ietf.sip.reliable-100		Proxy-Require: org.ietf.sip.reliable-100
	7 Open Issues		7.2 Message Flows
	There are a number of open issues:		This section illustrates a number of message flows using this
			extension. We abbreviate an INVITE request with a RAck header value
			of N as "INV N", and a provisional response with a RSeq header value
			of M as "1xx M". Packets which are lost are shown with an "X" in
			front of them.
	1. It is possible to use a list of sequence numbers in the		7.2.1 UAC to UAS, with Require
	RAck header field instead of a single number. This would
	enable a SACK-like mechanism very easily. Is this worth the
	additional complication?
	2. Should we support window sizes greater than one?		In this case, the UAC sends a request directly to a UAS, and includes
			the Require header, naming this extension. The extension is supported
			by the UAS. The UAS sends a 100 response first, and then a 180
			reliably.
	3. Currently, SIP requests with the same values of the To,		UAC UAS
	From, Call-ID and CSeq fields are isomorphic. It is
			-------INV 0-------------->
			X<.......100.........
			-------INV 0--->X
			-------INV 0-------------->
			(request <..........100.............
			retransmissions
			cease)
			X<...180 1............ (180 retransmits start, sn=1)
			(rn inc to 1) <.........180 1............
			-------INV 1---->
			<.........180 1............
			-------INV 1--------------> (180 retransmits cease)
			X<....300............... (300 class retransmits start)
			<........300...............
			-----------ACK------------>
			7.2.2 UAC to UAS, without Require, UAS doesn't understand
			In this case, a UAC sends a request directly to the UAS, and doesn't
			include the Require header in the request. The UAS doesn't support
			the extension. The UAS sends a single 180 before sending a final
			response.
			UAC UAS
			-------INV 0-------------->
			X<.......100.........
			-------INV 0--->X
			-------INV 0-------------->
			(request <..........100.............
			retransmissions
			cease)
			<..........180 ............
			X<....300............... (300 class retransmits start)
			<........300...............
			-----------ACK------------>
			Note that after reception of the 180, the request is not
			retransmitted, since the response did not contain an RSeq header.
			7.2.3 UAC to proxy to UAS
			In this case, a UAC sends a request to a proxy, which forwards it to
			the final UAS. Both the Require and Proxy-Require headers are present
			in the request. The local proxy generates its own provisional
			response (188), and the UAS generates a 180:
			UAC PROXY UAS
			-----INV 0-------------> ----INV 0-->X
			-----INV 0-------------> ----INV 0------------->
			X<....100........
			X<....100........ <....100...............
			<........100............
			X<......188 1.......
			<...........188 1.......
			---------INV 1-->X
			<...........188 1.......
			--------INV 1---------->
			X<....180 1.....
			<......180 1.............
			-------INV 1--->X
			X<....180 2..... <......180 1.............
			-------INV 1------------>
			<...........180 2.....
			-----INV 2------------>
			Note that the proxy renumbers the two provisional responses before
			sending them upstream.
			8 Open Issues
			There are a number of open issues:
			1. Currently, SIP requests with the same values of the To,
			From, Call-ID and CSeq fields are isomorphic. It is
	possible that certain implementations may discard non-		possible that certain implementations may discard non-
	isomorphic requests with identical values for these header		isomorphic requests with identical values for these header
	fields. By adding the RAck header into a request		fields. By adding the RAck header into a request
	retransmission, we break the isomorphism of retransmitted		retransmission, we break the isomorphism of retransmitted
	requests. Is this a problem?		requests. Is this a problem?
	8 Security Considerations		2. The mechanism currently requires proxies to understand it
			to work. It is possible to hack a solution without this
			constraint, by placing the RAck value as a parameter in the
			Via header, rather than its own header. The result would be
			those pairs of proxies which both understand provisional
			reliability would provide it, those that don't, would not.
			Is this useful?
	Since the RSeq value cannot be encrypted or authenticated end-to-		9 Security Considerations
	end, nor can the RAck, man in the middle attacks are possible which
	can cause the provisional responses to be reordered at the UAC. This
	can be alleviated by the use of hop-by-hop encryption and
	authentication mechanisms, such as IPSEC [2,2].
	9 Author's Addresses		Since the RSeq value cannot be encrypted or authenticated end-to-end,
			nor can the RAck, man in the middle attacks are possible which can
			cause the provisional responses to be reordered at the UAC. This can
			be alleviated by the use of hop-by-hop encryption and authentication
			mechanisms, such as IPSEC [3,3].
			10 Acknowledgements
			The authors would like to thank Jonathan Lennox and Adam Roach for
			the comments on this document.
			11 Author's Addresses
	Jonathan Rosenberg		Jonathan Rosenberg
	Lucent Technologies, Bell Laboratories		Lucent Technologies, Bell Laboratories
	101 Crawfords Corner Rd.		101 Crawfords Corner Rd.
	Holmdel, NJ 07733		Holmdel, NJ 07733
	Rm. 4C-526		Rm. 4C-526
	email: jdrosen@bell-labs.com		email: jdrosen@bell-labs.com
	Henning Schulzrinne		Henning Schulzrinne
	Columbia University		Columbia University
	M/S 0401		M/S 0401
	1214 Amsterdam Ave.		1214 Amsterdam Ave.
	New York, NY 10027-7003		New York, NY 10027-7003
	email: schulzrinne@cs.columbia.edu		email: schulzrinne@cs.columbia.edu
	10 Bibliography		12 Bibliography
	[1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:		[1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
	session initiation protocol," Internet Draft, Internet Engineering		session initiation protocol," Request for Comments (Proposed
	Task Force, Sept. 1998. Work in progress.		Standard) 2543, Internet Engineering Task Force, Mar. 1999.
	[2] R. Atkinson, "IP encapsulating security payload (ESP)," Request		[2] S. Bradner, "Key words for use in RFCs to indicate requirement
			levels," Request for Comments (Best Current Practice) 2119, Internet
			Engineering Task Force, Mar. 1997.
			[3] R. Atkinson, "IP encapsulating security payload (ESP)," Request
	for Comments (Proposed Standard) 1827, Internet Engineering Task		for Comments (Proposed Standard) 1827, Internet Engineering Task
	Force, Aug. 1995.		Force, Aug. 1995.
End of changes. 45 change blocks.
	122 lines changed or deleted		357 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/