< draft-manyfolks-sip-resource-00.txt		draft-manyfolks-sip-resource-01.txt >
	SIP Working Group W. Marshall		SIP Working Group W. Marshall
	Internet Draft K. Ramakrishnan		Internet Draft K. Ramakrishnan
	Document: <draft-manyfolks-sip-resource-00.txt> AT&T		Document: <draft-manyfolks-sip-resource-01.txt> AT&T
	Category: Informational		Category: Informational
	E. Miller		E. Miller
	G. Russell		G. Russell
	CableLabs		CableLabs
	B. Beser		B. Beser
	M. Mannette		M. Mannette
	K. Steinbrenner		K. Steinbrenner
	3Com		3Com
	D. Oran		D. Oran
	F. Andreasen		F. Andreasen
			M. Ramalho
	Cisco		Cisco
	J. Pickens		J. Pickens
	Com21		Com21
	P. Lalwaney		P. Lalwaney
			Nokia
	J. Fellows		J. Fellows
	Motorola		Motorola
	D. Evans		D. Evans
	Secure Cable Solutions		Secure Cable Solutions
	K. Kelly		K. Kelly
	NetSpeak		NetSpeak
	A. Roach		A. Roach
	Ericsson		Ericsson
	J. Rosenberg		J. Rosenberg
			D. Willis
	dynamicsoft		dynamicsoft
	H. Schulzrinne		H. Schulzrinne
	Columbia University		Columbia University
	S. Donovan		S. Donovan
	MCI Worldcom		MCI Worldcom
	March, 2000		June, 2000
	Integration of Resource Management and SIP for IP Telephony
			Integration of Resource Management and SIP
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is NOT offered in accordance		This document is an Internet-Draft and is in full conformance with
	with Section 10 of RFC2026[1], and the author does not provide the		all provisions of Section 10 of RFC2026[1].
	IETF with any rights other than to publish as an Internet-Draft.
	Category Informational - Expiration 9/30/00 1
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts. Internet-Drafts are draft documents valid for a maximum of		Drafts. Internet-Drafts are draft documents valid for a maximum of
	six months and may be updated, replaced, or obsoleted by other		six months and may be updated, replaced, or obsoleted by other
	documents at any time. It is inappropriate to use Internet- Drafts		documents at any time. It is inappropriate to use Internet- Drafts
	as reference material or to cite them other than as "work in		as reference material or to cite them other than as "work in
	progress."		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.
	The distribution of this memo is unlimited. It is filed as <draft-		The distribution of this memo is unlimited. It is filed as <draft-
	manyfolks-sip-resource-00.txt>, and expires September 30, 2000.		manyfolks-sip-resource-01.txt>, and expires December 31, 2000.
	Please send comments to the authors.		Please send comments to the authors.
	1. Abstract		1. Abstract
	This document discusses how network QoS and security establishment		This document discusses how network QoS and security establishment
	can be made a precondition to sessions initiated by the Session		can be made a precondition to sessions initiated by the Session
	Initiation Protocol (SIP)[2], and described by SDP [3]. These		Initiation Protocol (SIP), and described by SDP. These preconditions
	preconditions require that the participant reserve network resources		require that the participant reserve network resources (or establish
	(or establish a secure media channel) before continuing with the		a secure media channel) before continuing with the session. We do
	session. We do not define new QoS reservation or security		not define new QoS reservation or security mechanisms; these pre-
	mechanisms; these pre-conditions simply require a participant to use		conditions simply require a participant to use existing resource
	existing resource reservation and security mechanisms before		reservation and security mechanisms before beginning the session.
	beginning the session.
	This results in a multi-phase call-setup mechanism, with the		This results in a multi-phase call-setup mechanism, with the
	resource management protocol interleaved between two phases of call		resource management protocol interleaved between two phases of call
	signaling. The objective of such a mechanism is to enable deployment		signaling. The objective of such a mechanism is to enable deployment
	of robust IP Telephony services, by ensuring that resources are made		of robust IP Telephony services, by ensuring that resources are made
	available before the phone rings and the participants of the call		available before the phone rings and the participants of the call
	are "invited" to participate.		are "invited" to participate.
	This document also proposes an extension to the Session Initiation		This document also proposes an extension to the Session Initiation
	Protocol (SIP) to add a new PRECONDITION-MET method, which is used		Protocol (SIP) to add a new COMET method, which is used to confirm
	to confirm the completion of all pre-conditions by the call		the completion of all pre-conditions by the session originator.
	originator.
	2. Conventions used in this document		2. Conventions used in this document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
	this document are to be interpreted as described in RFC-2119[4].		this document are to be interpreted as described in RFC-2119[4].
	Category Informational - Expiration 9/30/00 2
	3. Introduction		3. Introduction
	For an Internet Telephony service to be successfully used by a large		For an Internet Telephony service to be successfully used by a large
	number of subscribers, it must offer few surprises to those		number of subscribers, it must offer few surprises to those
	accustomed to the behavior of existing telephony services. One		accustomed to the behavior of existing telephony services. One
	expectation is that of connection quality, implying resources must		expectation is that of connection quality, implying resources must
	be set aside for each call.		be set aside for each call.
	A key contribution of the DCS architecture, as described in [5], is		A key contribution of the DCS architecture, as described in [5], is
	a recognition of the need for coordination between call signaling,		a recognition of the need for coordination between call signaling,
	skipping to change at line 127 ¶		skipping to change at line 125 ¶
	coordination is designed to meet the user expectations and human		coordination is designed to meet the user expectations and human
	factors associated with telephony.		factors associated with telephony.
	While customers may expect, during times of heavy load, to receive a		While customers may expect, during times of heavy load, to receive a
	"fast busy" or an announcement saying "all circuits are busy now,"		"fast busy" or an announcement saying "all circuits are busy now,"
	the general expectation is that once the destination phone rings		the general expectation is that once the destination phone rings
	that the connection can be made. Blocking a call after ringing the		that the connection can be made. Blocking a call after ringing the
	destination is considered a "call defect" and is a very undesirable		destination is considered a "call defect" and is a very undesirable
	exception condition.		exception condition.
	We consider the case where a provider may choose to block a call		This draft addresses both "QoS-Assured" and "QoS-Enabled" sessions.
	when adequate resources for the call are not available. It may be		A "QoS-Assured" session will complete only if all the required
	argued that best-effort connections may be an alternative in such a		resources are available and assigned to the session. A provider may
	case. However, public policy demands that the phone system provide		choose to block a call when adequate resources for the call are not
			available. Public policy demands that the phone system provide
	adequate quality at least in certain cases: e.g., for emergency		adequate quality at least in certain cases: e.g., for emergency
	communications during times of disasters. Call blocking enables a		communications during times of disasters. Call blocking enables a
	provider to meet such requirements. This draft and the overall DCS		provider to meet such requirements.
	architecture assumes that the provider blocks calls when resources
	are unavailable.
	It is often the case that calls into a disaster area are blocked, to		A "QoS-Enabled" session allows the endpoints to complete the session
	ensure resources are available for calls out of the disaster area.		establishment either with or without the desired resources. Such
	Such policy-level controls also need to be available for the service		session will use dedicated resources if available, and use a best-
	provider.		effort connection as an alternative if resources can not be
			dedicated. In cases where resources are not available, the
			originating and/or terminating User Agent might consult with the
			customer to obtain guidance on whether the session should complete.
	Coordination between call signaling and resource management is also		Coordination between call signaling and resource management is also
	needed to prevent fraud and theft of service. The coordination		needed to prevent fraud and theft of service. The coordination
	between call-signaling and QoS setup protocols ensures that users		between call-signaling and QoS setup protocols ensures that users
	are authenticated and authorized before receiving access to the		are authenticated and authorized before receiving access to the
	enhanced QoS associated with the telephony service.		enhanced QoS associated with the telephony service.
	This coordination, referred to in this draft as "preconditions,"		This coordination, referred to in this draft as "preconditions,"
	require that the participant reserve network resources (or establish		require that the participant reserve network resources (or establish
	a secure media channel) before continuing with the session. We do		a secure media channel) before continuing with the session. We do
	not define new QoS reservation or security mechanisms; these pre-		not define new QoS reservation or security mechanisms; these pre-
	conditions simply require a participant to use existing resource		conditions simply require a participant to use existing resource
	reservation and security mechanisms before beginning the session.		reservation and security mechanisms before beginning the session.
	In the case of SIP [2], this effectively means that the "phone won't		In the case of SIP [2], this effectively means that the "phone won't
	ring" until the preconditions are met. These preconditions are		ring" until the preconditions are met. These preconditions are
	described by new SDP parameters, defined in this document. The		described by new SDP parameters, defined in this document. The
	Category Informational - Expiration 9/30/00 3
	parameters can mandate end-to-end QoS reservations based on RSVP [6]		parameters can mandate end-to-end QoS reservations based on RSVP [6]
	or any other end-to-end reservation mechanism (such as YESSIR [7],		or any other end-to-end reservation mechanism (such as YESSIR [7],
	or PacketCable's Dynamic Quality of Service (D-QoS) [8]), and		or PacketCable's Dynamic Quality of Service (D-QoS) [8]), and
	security based on IPSEC [9]. The preconditions can be defined		security based on IPSEC [9]. The preconditions can be defined
	independently for each media stream.		independently for each media stream.
	The QoS architecture of the Internet separates QoS signaling from		The QoS architecture of the Internet separates QoS signaling from
	application level signaling. Application layer devices (such as web		application level signaling. Application layer devices (such as web
	proxies and SIP servers) are not well suited for participation in		proxies and SIP servers) are not well suited for participation in
	network admission control or QoS management, as this is		network admission control or QoS management, as this is
	skipping to change at line 213 ¶		skipping to change at line 211 ¶
	security association is needed for the application to execute.		security association is needed for the application to execute.
	To solve both of these problems, we propose an extension to SDP		To solve both of these problems, we propose an extension to SDP
	which allows indication of pre-conditions for sessions. These		which allows indication of pre-conditions for sessions. These
	preconditions indicate that participation in the session should not		preconditions indicate that participation in the session should not
	proceed until the preconditions are met. The preconditions we define		proceed until the preconditions are met. The preconditions we define
	are (1) success of end-to-end resource reservation, and (2) success		are (1) success of end-to-end resource reservation, and (2) success
	of end- to-end security establishment. We chose to implement these		of end- to-end security establishment. We chose to implement these
	extensions in SDP, rather than SIP [2] or SAP [11], since they are		extensions in SDP, rather than SIP [2] or SAP [11], since they are
	fundamentally a media session issue. SIP is session agnostic;		fundamentally a media session issue. SIP is session agnostic;
	Category Informational - Expiration 9/30/00 4
	information about codecs, ports, and RTP [10] are outside the scope		information about codecs, ports, and RTP [10] are outside the scope
	of SIP. Since it is the media sessions that the reservations and		of SIP. Since it is the media sessions that the reservations and
	security refer to, SDP is the appropriate venue for the extensions.		security refer to, SDP is the appropriate venue for the extensions.
	Furthermore, placement of the extensions in SDP rather than SIP or		Furthermore, placement of the extensions in SDP rather than SIP or
	SAP allows specification of preconditions for individual media		SAP allows specification of preconditions for individual media
	streams. For example, a multimedia lecture might require reservation		streams. For example, a multimedia lecture might require reservation
	for the audio, but not the video (which is less important).		for the audio, but not the video (which is less important).
	Our extensions are completely backward compatible. If a recipient		Our extensions are completely backward compatible. If a recipient
	does not understand them, normal SIP or SAP processing will occur,		does not understand them, normal SIP or SAP processing will occur,
	skipping to change at line 267 ¶		skipping to change at line 263 ¶
	of a packet classifier (source IP, destination IP, source port,		of a packet classifier (source IP, destination IP, source port,
	destination port, protocol) to be available for resource allocation.		destination port, protocol) to be available for resource allocation.
	3.2 Overview		3.2 Overview
	For acceptable interactive voice communication it is important to		For acceptable interactive voice communication it is important to
	achieve end-to-end QoS. The end-to-end QoS assurance implies		achieve end-to-end QoS. The end-to-end QoS assurance implies
	achieving low packet delay and packet loss. End-to-end packet delay		achieving low packet delay and packet loss. End-to-end packet delay
	must be small enough that it does not interfere with normal voice		must be small enough that it does not interfere with normal voice
	conversations. The ITU recommends no greater than 300 ms roundtrip		conversations. The ITU recommends no greater than 300 ms roundtrip
	Category Informational - Expiration 9/30/00 5
	delay for telephony service. Packet loss must be small enough to		delay for telephony service. Packet loss must be small enough to
	not perceptibly impede voice quality or the performance of fax and		not perceptibly impede voice quality or the performance of fax and
	voice band modems.		voice band modems.
	If it is found that the network cannot guarantee end-to-end QoS		If it is found that the network cannot guarantee end-to-end QoS
	resources, there are two alternatives: either (1) allow call		resources, there are two alternatives: either (1) allow call
	signaling to proceed with high probability of excessive delay and		signaling to proceed with high probability of excessive delay and
	packet loss which could impair any interactive real-time		packet loss which could impair any interactive real-time
	communication between the participants, or (2) block the call prior		communication between the participants, or (2) block the call prior
	to the called party being alerted. When calls are blocked because		to the called party being alerted. When calls are blocked because
	skipping to change at line 298 ¶		skipping to change at line 292 ¶
	a way that the post-dial-delay must be minimized without increasing		a way that the post-dial-delay must be minimized without increasing
	the probability of call defects. This means that the number of		the probability of call defects. This means that the number of
	round-trip messages must be kept at an absolute minimum and messages		round-trip messages must be kept at an absolute minimum and messages
	must be sent directly end-system to end-system if possible.		must be sent directly end-system to end-system if possible.
	The general idea behind the extension is simple. We define two new		The general idea behind the extension is simple. We define two new
	SDP attributes, "qos" and "security". The "qos" attribute indicates		SDP attributes, "qos" and "security". The "qos" attribute indicates
	whether end-to-end resource reservation is optional or mandatory,		whether end-to-end resource reservation is optional or mandatory,
	and in which direction (send, recv, or sendrecv). When the attribute		and in which direction (send, recv, or sendrecv). When the attribute
	indicates mandatory, this means that the participant who has		indicates mandatory, this means that the participant who has
	received the SDP MUST NOT proceed with participation in the session		received the SDP does not proceed with participation in the session
	until resource reservation has completed in the direction indicated.		until resource reservation has completed in the direction indicated.
	In this case, "not proceeding" means that the participant behaves as		In this case, "not proceeding" means that the participant behaves as
	if they had not received the SDP at all. If the attribute indicates		if they had not received the SDP at all. If the attribute indicates
	that QoS for the stream is optional, then the participant SHOULD		that QoS for the stream is optional, then the participant proceeds
	proceed normally with the session, but SHOULD reserve network		normally with the session, but should reserve network resources in
	resources in the direction indicated, if they are capable. Absence		the direction indicated, if they are capable. Absence of the "qos"
	of the "qos" attribute means the participant MAY reserve resources		attribute means the participant reserves resources for this stream,
	for this stream, and SHOULD proceed normally with the session. This		and proceeds normally with the session. This behavior is the normal
	behavior is the normal behavior for SDP.		behavior for SDP.
	Resource reservation takes place using whatever protocols		Resource reservation takes place using whatever protocols
	participants must use, based on support by their service provider.		participants must use, based on support by their service provider.
	If the ISP's of the various participants are using differing		If the ISP's of the various participants are using differing
	resource reservation protocols, translation is necessary, but this		resource reservation protocols, translation is necessary, but this
	is done within the network, without knowledge of the participants.		is done within the network, without knowledge of the participants.
	The direction attribute indicates which direction reservations		The direction attribute indicates which direction reservations
	should be reserved in. If "send", it means reservations should be		should be reserved in. If "send", it means reservations should be
	made in the direction of media flow from the session originator to		made in the direction of media flow from the session originator to
	participants. If "recv", it means reservations should be made in the		participants. If "recv", it means reservations should be made in the
	direction of media flow from participants to the session originator.		direction of media flow from participants to the session originator.
	In the case of "sendrecv", it means reservations should be made in		In the case of "sendrecv", it means reservations should be made in
	both directions.		both directions.
	Category Informational - Expiration 9/30/00 6
	In the case of security, the same attributes are defined -		In the case of security, the same attributes are defined -
	optional/mandatory, and send/recv/sendrecv. Their meaning is		optional/mandatory, and send/recv/sendrecv. Their meaning is
	identical to the one above, except that a security association		identical to the one above, except that a security association
	should be established in the given direction. The details of the		should be established in the given direction. The details of the
	security association are not signaled by SDP; these depend on the		security association are not signaled by SDP; these depend on the
	Security Policy Database of the participant.		Security Policy Database of the participant.
	Either party MAY include a "confirm" attribute in the SDP. When the		Either party can include a "confirm" attribute in the SDP. When the
	"Confirm" attribute is present, the recipient MUST send a		"Confirm" attribute is present, the recipient sends a COMET message
	PRECONDITION-MET message to the sender, with SDP attached, telling		to the sender, with SDP attached, telling the status of each
	the status of each precondition as "success" or "failure." If the		precondition as "success" or "failure." If the "confirm" attribute
	"confirm" attribute is present in the SDP sent by the session		is present in the SDP sent by the session originator to the
	originator to the participant (e.g. in the SIP INVITE message), then		participant (e.g. in the SIP INVITE message), then the participant
	the participant MUST send the PRECONDITION-MET message to the		sends the COMET message to the originator. If the "confirm"
	originator. If the "confirm" attribute is present in the SDP sent		attribute is present in the SDP sent by the recipient to the
	by the recipient to the originator (e.g. in a SIP response message),		originator (e.g. in a SIP response message), then the originator
	then the originator MUST send the PRECONDITION-MET message to the		sends the COMET message to the participant.
	participant.
	When the "Confirm" attribute is present in both the SDP sent by the		When the "Confirm" attribute is present in both the SDP sent by the
	session originator to the participant (e.g. in the SIP INVITE		session originator to the participant (e.g. in the SIP INVITE
	message), and in the SDP sent by the recipient back to the		message), and in the SDP sent by the recipient back to the
	originator (e.g. in a SIP response message), the session originator		originator (e.g. in a SIP response message), the session originator
	MAY wait for the PRECONDITION-MET message with the success/failure		would wait for the COMET message with the success/failure
	notification before responding with a PRECONDITION-MET message, and		notification before responding with a COMET message, and responds
	MAY respond instead with a CANCEL if a mandatory precondition is not		instead with a CANCEL if a mandatory precondition is not met, or if
	met, or if an insufficient combination of optional preconditions are		a sufficient combination of optional preconditions are not met. The
	not met. The recipient MUST NOT wait for the PRECONDITION-MET		recipient does not wait for the COMET message from the originator
	message from the originator before sending its PRECONDITION-MET		before sending its COMET message.
	message.
	4. SDP Syntax		4. SDP Extension
	The formatting of the qos attribute in the Session Description		The formatting of the qos attribute in the Session Description
	Protocol (SDP) is described by the following BNF:		Protocol (SDP)[3] is described by the following BNF:
	qos-attribute = "a=qos:" strength-tag SP direction-tag		qos-attribute = "a=qos:" strength-tag SP direction-tag
	[SP confirmation-tag]		[SP confirmation-tag]
	strength-tag = ("mandatory" | "optional" | "success" |		strength-tag = ("mandatory" | "optional" | "success" |
	"failure")		"failure")
	direction-tag = ("send" | "recv" | "sendrecv")		direction-tag = ("send" | "recv" | "sendrecv")
	confirmation-tag = "confirm"		confirmation-tag = "confirm"
	and the security attribute:		and the security attribute:
	security-attribute = "a=secure:" SP strength-tag SP direction-tag		security-attribute = "a=secure:" SP strength-tag SP direction-tag
	[SP confirmation-tag]		[SP confirmation-tag]
	Category Informational - Expiration 9/30/00 7
	4.1 SDP Example		4.1 SDP Example
	The following example shows an SDP description carried in a SIP		The following example shows an SDP description carried in a SIP
	INVITE message from A to B:		INVITE message from A to B:
	v=0		v=0
	o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4		o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
	s=SDP Seminar		s=SDP Seminar
	i=A Seminar on the session description protocol		i=A Seminar on the session description protocol
	u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps		u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
	skipping to change at line 427 ¶		skipping to change at line 417 ¶
	both parties.		both parties.
	B: response		B: response
	A: request send recv sendrecv none		A: request send recv sendrecv none
	send N/A A->B N/A --		send N/A A->B N/A --
	recv B->A N/A N/A --		recv B->A N/A N/A --
	sendrecv A->B B<-A A<->B --		sendrecv A->B B<-A A<->B --
	none -- -- -- --		none -- -- -- --
	Table 1: Allowed values of coupling		Table 1: Allowed values of coupling
	Category Informational - Expiration 9/30/00 8
	Table 2 illustrates the allowed values for the strength tag in the		Table 2 illustrates the allowed values for the strength tag in the
	request and response. A "Y" means the combination is allowed, and a		request and response. A "Y" means the combination is allowed, and a
	"N" means it is not. The value in the response is the one used by		"N" means it is not. The value in the response is the one used by
	both parties.		both parties.
	B: response		B: response
	A: request mandatory optional none		A: request mandatory optional none
	mandatory Y Y Y		mandatory Y Y Y
	optional N Y Y		optional N Y Y
	none N N Y		none N N Y
	Table 2: Allowed values of strength parameter		Table 2: Allowed values of strength parameter
			5. SIP Extension: The COMET Method
	5. SIP Extension: The PRECONDITION-MET Method		The COMET method is used for communicating successful completion of
			preconditions from the calling to called user agents.
	The PRECONDITION-MET method is used for communicating successful
	completion of preconditions from the calling to called user agents.
	The signaling path for the PRECONDITION-MET method is the signaling		The signaling path for the COMET method is the signaling path
	path established as a result of the call setup. This can be either		established as a result of the call setup. This can be either
	direct signaling between the calling and called user agents or a		direct signaling between the calling and called user agents or a
	signaling path involving SIP proxy servers that were involved in the		signaling path involving SIP proxy servers that were involved in the
	call setup and added themselves to the Record-Route header on the		call setup and added themselves to the Record-Route header on the
	initial INVITE message.		initial INVITE message.
	The precondition information is communicated in the message body,		The precondition information is communicated in the message body,
	which MUST contain an SDP. For every agreed precondition, the		which MUST contain an SDP. For every agreed precondition, the
	strength-tag MUST indicate "success" or "failure".		strength-tag MUST indicate "success" or "failure".
	If the initial request contained Record-Route headers, the		If the initial request contained Record-Route headers, the
	provisional response MUST contain a copy of those headers, as if the		provisional response MUST contain a copy of those headers, as if the
	response were a 200 OK to the initial request. Since provisional		response were a 200 OK to the initial request. Since provisional
	responses MAY contain Record-Route and Contact headers, the		responses MAY contain Record-Route and Contact headers, the COMET
	PRECONDITION-MET request MUST contain Route headers if the Record-		request MUST contain Route headers if the Record-Route headers were
	Route headers were present in the provisional response. The Route		present in the provisional response. The Route header is constructed
	header is constructed as specified in [2]. The Route header that is		as specified in [2]. The Route header that is constructed from some
	constructed from some provisional response MUST NOT be placed in any		provisional response MUST NOT be placed in any other request except
	other request except for the PRECONDITION-MET for that provisional		for the COMET for that provisional response.
	response.
	A UAC MUST NOT insert a Route header into a PRECONDITION-MET request
	if no Record-Route header was present in the response.
	If the initial request was sent with credentials, the PRECONDITION-		A UAC MUST NOT insert a Route header into a COMET request if no
	MET request SHOULD contain those credentials as well.		Record-Route header was present in the response.
	The Call-ID in the PRECONDITION-MET MUST match that of the		If the initial request was sent with credentials, the COMET request
	provisional response. The CSeq in this request MUST be larger than		SHOULD contain those credentials as well.
	the last request sent by this UAC for this call leg. The To, From,
	Category Informational - Expiration 9/30/00 9		The Call-ID in the COMET MUST match that of the provisional
	and Via headers MUST be present, and MUST be constructed as they		response. The CSeq in this request MUST be larger than the last
	would be for a re-INVITE or BYE as specified in [2]. In particular,		request sent by this UAC for this call leg. The To, From, and Via
	if the provisional response contained a tag in the To field, this		headers MUST be present, and MUST be constructed as they would be
	tag MUST be mirrored in the To field of the PRECONDITION-MET.		for a re-INVITE or BYE as specified in [2]. In particular, if the
			provisional response contained a tag in the To field, this tag MUST
			be mirrored in the To field of the COMET.
	Once the PRECONDITION-MET request is created, it is sent by the UAC.		Once the COMET request is created, it is sent by the UAC. It is sent
	It is sent as would any other non-INVITE request for a call. In		as would any other non-INVITE request for a call. In particular,
	particular, when sent over UDP, the PRECONDITION-MET request is		when sent over UDP, the COMET request is retransmitted with an
	retransmitted with an exponentially increasing interval, starting at		exponentially increasing interval, starting at 500 milliseconds and
	500 milliseconds and increasing to 4 seconds. Note that a UAC SHOULD		increasing to 4 seconds. Note that a UAC SHOULD NOT retransmit the
	NOT retransmit the PRECONDITION-MET request when it receives a		COMET request when it receives a retransmission of the provisional
	retransmission of the provisional response being acknowledged,		response being acknowledged, although doing so does not create a
	although doing so does not create a protocol error. As with any		protocol error. As with any other non-INVITE request, the UAC
	other non-INVITE request, the UAC continues to retransmit the		continues to retransmit the COMET request until it receives a final
	PRECONDITION-MET request until it receives a final response.		response.
	A PRECONDITION-MET request MAY be cancelled. However, whilst allowed		A COMET request MAY be cancelled. However, whilst allowed for
	for purposes of generality, usage of CANCEL with PRECONDITION-MET is		purposes of generality, usage of CANCEL with COMET is NOT
	NOT RECOMMENDED.		RECOMMENDED.
	5.1 Header Field Support for PRECONDITION-MET Method		5.1 Header Field Support for COMET Method
	Tables 3 and 4 are extensions of tables 4 and 5 in the SIP		Tables 3 and 4 are extensions of tables 4 and 5 in the SIP
	specification[2]. Refer to Section 6 of [2] for a description of		specification[2]. Refer to Section 6 of [2] for a description of
	the content of the tables.		the content of the tables.
	5.2 Responses to the PRECONDITION-MET Request Method		5.2 Responses to the COMET Request Method
	If a server receives a PRECONDITION-MET request it MUST send a final		If a server receives a COMET request it MUST send a final response.
	response.
	A 200 OK response MUST be sent by a UAS for a PRECONDITION-MET		A 200 OK response MUST be sent by a UAS for a COMET request if the
	request if the PRECONDITION-MET request was successfully received		COMET request was successfully received for an existing call.
	for an existing call. Beyond that, no additional operations are		Beyond that, no additional operations are required.
	required.
	A 481 Call Leg/Transaction Does Not Exist message MUST be sent by a		A 481 Call Leg/Transaction Does Not Exist message MUST be sent by a
	UAS if the PRECONDITION-MET request does not match any existing call		UAS if the COMET request does not match any existing call leg.
	leg.
	Category Informational - Expiration 9/30/00 10		Header Where COMET
	Header Where PRECONDITION-MET
	------ ----- ----		------ ----- ----
	Accept R o		Accept R o
	Accept-Encoding R o		Accept-Encoding R o
	Accept-Language R o		Accept-Language R o
	Allow 200 -		Allow 200 -
	Allow 405 o		Allow 405 o
	Authorization R o		Authorization R o
	Call-ID gc m		Call-ID gc m
	Contact R o		Contact R o
	Contact 1xx -		Contact 1xx -
	skipping to change at line 546 ¶		skipping to change at line 527 ¶
	Content-Type e *		Content-Type e *
	CSeq gc m		CSeq gc m
	Date g o		Date g o
	Encryption g o		Encryption g o
	Expires g o		Expires g o
	From gc m		From gc m
	Hide R o		Hide R o
	Max-Forwards R o		Max-Forwards R o
	Organization g o		Organization g o
	Table 3 Summary of header fields, A-0		Table 3 Summary of header fields, A-0
			Header Where COMET
	Header Where PRECONDITION-MET
	------ ----- ----		------ ----- ----
	Priority R o		Priority R o
	Proxy-Authenticate 407 o		Proxy-Authenticate 407 o
	Proxy-Authorization R o		Proxy-Authorization R o
	Proxy-Require R o		Proxy-Require R o
	Require R o		Require R o
	Retry-After R -		Retry-After R -
	Retry-After 404,480,486 o		Retry-After 404,480,486 o
	Retry-After 503 o		Retry-After 503 o
	Retry-After 600,603 o		Retry-After 600,603 o
	skipping to change at line 574 ¶		skipping to change at line 554 ¶
	Timestamp g o		Timestamp g o
	To gc(1) m		To gc(1) m
	Unsupported 420 o		Unsupported 420 o
	User-Agent g o		User-Agent g o
	Via gc(2) m		Via gc(2) m
	Warning r o		Warning r o
	WWW-Authenticate 401 o		WWW-Authenticate 401 o
	Table 4 Summary of header fields, P-Z		Table 4 Summary of header fields, P-Z
	Category Informational - Expiration 9/30/00 11
	Other request failure (4xx), Server Failure (5xx) and Global Failure		Other request failure (4xx), Server Failure (5xx) and Global Failure
	(6xx) responses MAY be sent for the PRECONDITION-MET Request.		(6xx) responses MAY be sent for the COMET Request.
	5.3 Message Body Inclusion		5.3 Message Body Inclusion
	The PRECONDITION-MET request MUST contain a message body.		The COMET request MUST contain a message body.
	5.4 Behavior of SIP User Agents		5.4 Behavior of SIP User Agents
	Unless stated otherwise, the protocol rules for the PRECONDITION-MET		Unless stated otherwise, the protocol rules for the COMET request
	request governing the usage of tags, Route and Record-Route,		governing the usage of tags, Route and Record-Route, retransmission
	retransmission and reliability, CSeq incrementing and message		and reliability, CSeq incrementing and message formatting follow
	formatting follow those in [2] as defined for the BYE request.		those in [2] as defined for the BYE request.
	A PRECONDITION-MET request MAY be cancelled. A UAS receiving a		A COMET request MAY be cancelled. A UAS receiving a CANCEL for an
	CANCEL for an PRECONDITION-MET request SHOULD respond to the		COMET request SHOULD respond to the COMET with a "487 Request
	PRECONDITION-MET with a "487 Request Cancelled" response if a final		Cancelled" response if a final response has not been sent to the
	response has not been sent to the PRECONDITION-MET and then behave		COMET and then behave as if the request were never received.
	as if the request were never received.
	5.5 Behavior of SIP Proxy and Redirect Servers		5.5 Behavior of SIP Proxy and Redirect Servers
	5.5.1 Proxy Server		5.5.1 Proxy Server
	Unless stated otherwise, the protocol rules for the PRECONDITION-MET		Unless stated otherwise, the protocol rules for the COMET request at
	request at a proxy are identical to those for a BYE request as		a proxy are identical to those for a BYE request as specified in
	specified in [2].		[2].
	5.5.2 Forking Proxy Server		5.5.2 Forking Proxy Server
			Unless stated otherwise, the protocol rules for the COMET request at
	Unless stated otherwise, the protocol rules for the PRECONDITION-MET		a proxy are identical to those for a BYE request as specified in
	request at a proxy are identical to those for a BYE request as		[2].
	specified in [2].
	5.5.3 Redirection Server		5.5.3 Redirection Server
	Unless stated otherwise, the protocol rules for the PRECONDITION-MET		Unless stated otherwise, the protocol rules for the COMET request at
	request at a proxy are identical to those for a BYE request as		a proxy are identical to those for a BYE request as specified in
	specified in [2].		[2].
	6. SIP Extension: The 580-Precondition-Failure Response		6. SIP Extension: The 580-Precondition-Failure Response
	An additional error response is defined by this draft, which is		An additional error response is defined by this draft, which is
	returned by a UAS if it is unable to perform the mandatory		returned by a UAS if it is unable to perform the mandatory
	preconditions for the session.		preconditions for the session.
	6.1 Status Code and Reason Phrase		6.1 Status Code and Reason Phrase
	The following is to be added to Figure 8, Server error status codes		The following is to be added to Figure 8, Server error status codes
	Server-Error = "580" ;Precondition-Failure		Server-Error = "580" ;Precondition-Failure
	Category Informational - Expiration 9/30/00 12
	6.2 Status Code Definition		6.2 Status Code Definition
	The following is to be added to a new section 7.5.7.		The following is to be added to a new section 7.5.7.
	7.5.7 580 Precondition Failure		7.5.7 580 Precondition Failure
	The server was unable to establish the qos or security association		The server was unable to establish the qos or security association
	mandated by the SDP precondition.		mandated by the SDP precondition.
	7. SIP Usage Rules		7. SIP Usage Rules
	skipping to change at line 660 ¶		skipping to change at line 636 ¶
	The recipient of the INVITE (UAS) returns a 183-Session-Progress		The recipient of the INVITE (UAS) returns a 183-Session-Progress
	provisional response containing SDP, along with the qos/security		provisional response containing SDP, along with the qos/security
	attribute for each stream having a precondition, and would typically		attribute for each stream having a precondition, and would typically
	include a confirmation request. This SDP is a subset of the		include a confirmation request. This SDP is a subset of the
	preconditions indicated in the INVITE. Unlike normal SIP processing,		preconditions indicated in the INVITE. Unlike normal SIP processing,
	the UAS MUST NOT alert the called user at this point. The UAS now		the UAS MUST NOT alert the called user at this point. The UAS now
	attempts to reserve the qos resources and establish the security		attempts to reserve the qos resources and establish the security
	associations.		associations.
	The 183-Session-Progress is received by the UAC. If the 183		The 183-Session-Progress is received by the UAC. If the 183
	contained SDP with mandatory qos/security parameters, the UAC SHOULD		contained SDP with mandatory qos/security parameters, the UAC does
	NOT generate local ringback until the mandatory preconditions are		not generate local ringback until the mandatory preconditions are
	met. The UAC attempts to reserve the needed resources and establish		met. The UAC attempts to reserve the needed resources and establish
	the security associations.		the security associations.
	If either party requests a confirmation, a PRECONDITION-MET message		If either party requests a confirmation, a COMET message is sent to
	MUST be sent to that party. The PRECONDITION-MET message contains		that party. The COMET message contains the success/failure
	the success/failure indication for each precondition. Upon receipt		indication for each precondition. Upon receipt of the COMET message,
	of the PRECONDITION-MET message, the UAC/UAS continues normal SIP		the UAC/UAS continues normal SIP call handling, by (for a UAS)
	call handling, by (for a UAS) alerting the user and sending either a		alerting the user and sending either a 180-Ringing or 183-Early-
	180-Ringing or 183-Early-Media provisional response. The UAC either		Media provisional response. The UAC either provides ringback (in
	provides ringback (in the case that a 180 was received) or plays		the case that a 180 was received) or plays media from the remote
	media from the remote party (in the case of 183), and the SIP		party (in the case of 183), and the SIP transaction completes
	transaction completes normally.		normally.
	Note that this extension requires usage of reliable provisional		Note that this extension requires usage of reliable provisional
	responses [12]. This is because the 183 contains SDP with		responses [12]. This is because the 183 contains SDP with
	information required for the session originator to initiate		information required for the session originator to initiate
	reservations from it towards the participant.		reservations from it towards the participant.
	7.2 Behavior of Originator (UAC)		7.2 Behavior of Originator (UAC)
	Category Informational - Expiration 9/30/00 13
	The session originator (UAC) MAY include QoS and security		The session originator (UAC) MAY include QoS and security
	preconditions (including the desired direction) for each media flow		preconditions (including the desired direction) for each media flow
	in the SDP sent with the INVITE. The token value "send" means the		in the SDP sent with the INVITE. The token value "send" means the
	direction of media from originator (whichever entity created the		direction of media from originator (whichever entity created the
	SDP) to recipient (whichever entity received the SDP in a SIP		SDP) to recipient (whichever entity received the SDP in a SIP
	message), and "recv" is from recipient to originator.		message), and "recv" is from recipient to originator. If
			preconditions are included in the INVITE request, the UAC MUST
			indicate support for reliable provisional responses [12].
	If the UAC receives a 183-Session-Progress without SDP, or with SDP		If the UAC receives a 183-Session-Progress without SDP, or with SDP
	but without any qos/security preconditions in any stream, UAC treats		but without any qos/security preconditions in any stream, UAC treats
	it as an indication that the UAS is unable or unwilling to perform		it as an indication that the UAS is unable or unwilling to perform
	the preconditions requested. As such, the UAC SHOULD proceed with		the preconditions requested. As such, the UAC SHOULD proceed with
	normal call setup procedures. If the 183 contained SDP with		normal call setup procedures. If the INVITE or 183-Session-Progress
	mandatory qos/security parameters, the UAC SHOULD NOT generate local		contained SDP with mandatory qos/security parameters, the UAC SHOULD
	ringback until the mandatory preconditions are met.		NOT generate local ringback until the mandatory preconditions are
			met.
			If the 183-Session-Progress response requested an acknowledgement
			(using the methods of [12]), the UAC MUST include an updated SDP in
			the PRACK if the UAC modified the original SDP based on the response
			from the UAS. Such a modification MAY be due to negotiation of
			compatible CODECs, or MAY be due to negotiation of mandatory
			preconditions.
	Upon receipt of the 183-Session-Progress with SDP, the UAC MUST		Upon receipt of the 183-Session-Progress with SDP, the UAC MUST
	initiate the qos reservations and establish the security		initiate the qos reservations and establish the security
	associations required. If the UAC had requested confirmation in the		associations required. If the UAC had requested confirmation in the
	initial SDP, it MAY wait for the PRECONDITION-MET message from the		initial SDP, it MAY wait for the COMET message from the UAS
	UAS containing the success/failure status of each precondition. The		containing the success/failure status of each precondition. The UAC
	UAC MAY set a local timer to limit the time waiting for		MAY set a local timer to limit the time waiting for preconditions to
	preconditions to complete.		complete.
	If any of the mandatory preconditions cannot be met, the UAC MUST		If any of the mandatory preconditions cannot be met, the UAC MUST
	send a CANCEL and terminate the session.		send a CANCEL and terminate the session. If any of the optional
			preconditions cannot be met, the UAC MAY consult with the
			originating customer for guidance on whether to complete the
			session.
	When the optional preconditions have either been met or have failed,		When all the preconditions have either been met or have failed, and
	and the SDP received from the UAS included a confirmation request,		the SDP received from the UAS included a confirmation request, the
	the UAC MUST send a PRECONDITION-MET message to the UAS with SDP,		UAC MUST send a COMET message to the UAS with SDP, where each
	where each precondition is updated to indicate success/failure.		precondition is updated to indicate success/failure.
	The session now completes normally, as per [2].		The session now completes normally, as per [2].
	7.3 Behavior of Destination (UAS)		7.3 Behavior of Destination (UAS)
	On receipt of an INVITE request containing preconditions, the UAS		On receipt of an INVITE request containing preconditions, the UAS
	MUST generate a 183-Session-Progress response containing a subset of		MUST generate a 183-Session-Progress response containing a subset of
	the preconditions supported by the UAS. In the response, the token		the preconditions supported by the UAS. In the response, the token
	value "send" means the direction of the media from the UAS to the		value "send" means the direction of the media from the UAS to the
	originator, and "recv" is from the originator to the recipient.		originator, and "recv" is from the originator to the recipient.
	This is reversed from the SDP in the initial INVITE. The 183		This is reversed from the SDP in the initial INVITE. The 183
	provisional response MUST include a Session: header with parameter		provisional response MUST include a Session: header with parameter
	"qos" and/or "security" and MUST NOT include the session parameter		"qos" and/or "security" and MUST NOT include the session parameter
	"Media."		"Media."
	Unlike normal SIP processing, the UAS MUST NOT alert the called user		If the INVITE request did not contain any preconditions, but did
	at this point (unless the SDP in the 183 indicated no mandatory		indicate support for reliable provisional responses[12], the UAS MAY
	preconditions and no confirmation requests). The UAS now attempts		include preconditions in a 183-Session-Progress response to the
	to reserve the qos resources and establish the security		INVITE. The 183 provisional response MUST include a Session: header
	associations. The UAS MAY set a local timer to limit the time		with the parameter "qos" and/or "security" and MUST NOT include the
	waiting for preconditions to complete.		session parameter "Media." The 183 provisional response MUST
			request an acknowledgement using the mechanism of [12]. If the
			PRACK includes an SDP without any preconditions, the UAS MAY
			complete the session without the preconditions, or MAY reject the
			INVITE request.
			The UAS SHOULD request an acknowledgement to the 183 provisional
			response, using the mechanism of [12]. The UAS SHOULD wait for the
			PRACK message before initiating resource reservation to allow the
			resource reservation to reflect 3-way SDP negotiation, or other
			information available only through receipt of the PRACK.
			If the INVITE request or PRACK message contained mandatory
			preconditions, or requested a confirmation of preconditions, the UAS
			MUST NOT alert the called user.
			The UAS now attempts to reserve the qos resources and establish the
			security associations. The UAS MAY set a local timer to limit the
			time waiting for preconditions to complete.
	Category Informational - Expiration 9/30/00 14
	If the UAS is unable to perform any mandatory precondition, it MUST		If the UAS is unable to perform any mandatory precondition, it MUST
	send a 580-Precondition-Failure response to the UAC.		send a 580-Precondition-Failure response to the UAC. If the UAS is
			unable to perform any optional precondition, it MAY consult with the
			customer to obtain guidance regarding completion of the session.
	When processing of all preconditions is complete, if a precondition		When processing of all preconditions is complete, if a precondition
	in the initial INVITE specified a confirmation request, the UAS MUST		in the initial INVITE specified a confirmation request, the UAS MUST
	send a PRECONDITION-MET message to the originator containing SDP,		send a COMET message to the originator containing SDP, along with
	along with the qos/security result of success/failure for each		the qos/security result of success/failure for each precondition.
	precondition. The Request-URI, call-leg identification, and other		The Request-URI, call-leg identification, and other headers of this
	headers of this PRECONDITION-MET message is to be constructed		COMET message is to be constructed identically to a BYE.
	identically to a BYE.
	If the UAS had requested confirmation of a precondition in the		If the UAS had requested confirmation of a precondition in the
	response SDP, it SHOULD wait for the PRECONDITION-MET message from		response SDP, it SHOULD wait for the COMET message from the
	the originator containing the success/failure indication of each		originator containing the success/failure indication of each
	precondition from the originator's point of view. If that		precondition from the originator's point of view. If that
	confirmation indicates a failure for a mandatory precondition, the		confirmation indicates a failure for a mandatory precondition, the
	UAS MUST send a 415-Precondition-Failure response to the UAC.		UAS MUST send a 580-Precondition-Failure response to the UAC.
	Once the preconditions are met, the UAS alerts the user, and the SIP		Once the preconditions are met, the UAS alerts the user, and the SIP
	transaction completes normally.		transaction completes normally.
	8. Examples		8. Examples
	8.1 Basic (Single-Media) Call Flow		8.1 Basic (Single-Media) Call Flow
	Figure 1 presents a high-level overview of a basic end-point to end-		Figure 1 presents a high-level overview of a basic end-point to end-
	point (UAC-UAS) call flow. This example is appropriate for a		point (UAC-UAS) call flow. This example is appropriate for a
	skipping to change at line 784 ¶		skipping to change at line 790 ¶
	each stream having a precondition, and requesting a confirmation		each stream having a precondition, and requesting a confirmation
	when the preconditions are met. The UAS now attempts to reserve the		when the preconditions are met. The UAS now attempts to reserve the
	qos resources and establish the security associations.		qos resources and establish the security associations.
	The 183-Session-Progress provisional response is sent using the		The 183-Session-Progress provisional response is sent using the
	reliability mechanism of [12]. UAC sends the appropriate PRACK and		reliability mechanism of [12]. UAC sends the appropriate PRACK and
	UAS responds with a 200-OK to the PRACK.		UAS responds with a 200-OK to the PRACK.
	The 183-Session-Progress is received by the UAC, and the UAC		The 183-Session-Progress is received by the UAC, and the UAC
	requests the resources needed and establishes the security		requests the resources needed and establishes the security
	associations. Once the preconditions are met, the UAS sends a		associations. Once the preconditions are met, the UAS sends a COMET
	PRECONDITION-MET message as requested by the confirmation token.		message as requested by the confirmation token.
	Category Informational - Expiration 9/30/00 15
	Originating (UAC) Terminating (UAS)		Originating (UAC) Terminating (UAS)
	| SIP-Proxy(s) |		| SIP-Proxy(s) |
	| INVITE | |		| INVITE | |
	|---------------------->|---------------------->|		|---------------------->|---------------------->|
	| | |		| | |
	| 183 w/SDP | 183 w/SDP |		| 183 w/SDP | 183 w/SDP |
	|<----------------------|<----------------------|		|<----------------------|<----------------------|
	| |		| |
	| PRACK |		| PRACK |
	|---------------------------------------------->|		|---------------------------------------------->|
	| 200 OK (of PRACK) |		| 200 OK (of PRACK) |
	|<----------------------------------------------|		|<----------------------------------------------|
	| Reservation Reservation |		| Reservation Reservation |
	===========> <===========		===========> <===========
	| |		| |
	| |		| |
	| PRECONDITION-MET |		| COMET |
	|---------------------------------------------->|		|---------------------------------------------->|
	| 200 OK (of PRECONDITION-MET) |		| 200 OK (of COMET) |
	|<----------------------------------------------|		|<----------------------------------------------|
	|		|
	|		|
	| SIP-Proxy(s) User Alerted		| SIP-Proxy(s) User Alerted
	| | |		| | |
	| 180 Ringing | 180 Ringing |		| 180 Ringing | 180 Ringing |
	|<----------------------|<----------------------|		|<----------------------|<----------------------|
	| |		| |
	| PRACK |		| PRACK |
	|---------------------------------------------->|		|---------------------------------------------->|
	skipping to change at line 832 ¶		skipping to change at line 837 ¶
	| | |		| | |
	| 200 OK | 200 OK |		| 200 OK | 200 OK |
	|<----------------------|<----------------------|		|<----------------------|<----------------------|
	| | |		| | |
	| |		| |
	| ACK |		| ACK |
	|---------------------------------------------->|		|---------------------------------------------->|
	Figure 1: Basic Call FLow		Figure 1: Basic Call FLow
	On receipt of the PRECONDITION-MET message, the UAS knows all		On receipt of the COMET message, the UAS knows all preconditions
	preconditions have been met, and continues with session		have been met, and continues with session establishment. At this
	establishment. At this point it alerts the user, and sends a 180-		point it alerts the user, and sends a 180-Ringing provisional
	Ringing provisional response. This provisional response is also		response. This provisional response is also sent using the
	sent using the reliability mechanism of [12], resulting in a PRACK		reliability mechanism of [12], resulting in a PRACK message and 200-
	message and 200-OK of the PRACK.		OK of the PRACK.
	Category Informational - Expiration 9/30/00 16
	When the destination party answers, the normal SIP 200-OK final		When the destination party answers, the normal SIP 200-OK final
	response is sent through the proxies to the originator, and the		response is sent through the proxies to the originator, and the
	originator responds with an ACK message.		originator responds with an ACK message.
	Either party can terminate the call. An endpoint that detects an		Either party can terminate the call. An endpoint that detects an
	"on-hook" (request to terminate the call) releases the QoS resources		"on-hook" (request to terminate the call) releases the QoS resources
	held for the connection, and sends a SIP BYE message to the remote		held for the connection, and sends a SIP BYE message to the remote
	endpoint, which is acknowledged with a 200-OK.		endpoint, which is acknowledged with a 200-OK.
	8.2 Advanced (Multiple-Media) Call Flow		8.2 Advanced (Multiple-Media) Call Flow
	skipping to change at line 870 ¶		skipping to change at line 874 ¶
	The session originator (UAC) prepares an SDP message body for the		The session originator (UAC) prepares an SDP message body for the
	INVITE describing the desired QoS and security preconditions for		INVITE describing the desired QoS and security preconditions for
	each media flow, and the desired directions. UAC also requests		each media flow, and the desired directions. UAC also requests
	confirmation of the preconditions. The UAS receiving the INVITE		confirmation of the preconditions. The UAS receiving the INVITE
	message responds with 183-Session-Progress, as in the previous		message responds with 183-Session-Progress, as in the previous
	example.		example.
	When the UAS has completed the resource reservations and security		When the UAS has completed the resource reservations and security
	session establishment, it sends a confirmation to the UAC in the		session establishment, it sends a confirmation to the UAC in the
	form of a PRECONDITION-MET message, with each precondition marked in		form of a COMET message, with each precondition marked in the SDP as
	the SDP as either success or failure. Note that if UAS was not		either success or failure. Note that if UAS was not satisfied with
	satisfied with the combination of successful preconditions, it could		the combination of successful preconditions, it could instead have
	instead have responded with 580-Precondition-Failure, and ended the		responded with 580-Precondition-Failure, and ended the INVITE
	INVITE transaction.		transaction.
	If the UAC has satisfied its preconditions, and is satisfied with		If the UAC has satisfied its preconditions, and is satisfied with
	the preconditions achieved by the UAS, it responds with the		the preconditions achieved by the UAS, it responds with the COMET
	PRECONDITION-MET message. The PRECONDITION-MET message contains the		message. The COMET message contains the SDP with the
	SDP with the success/failure results of each precondition attempted		success/failure results of each precondition attempted by UAC. If
	by UAC. If UAC is not satisfied with the combination of successful		UAC is not satisfied with the combination of successful
	preconditions, it could instead have sent a CANCEL message.		preconditions, it could instead have sent a CANCEL message.
	On receipt of the PRECONDITION-MET message, UAS examines the		On receipt of the COMET message, UAS examines the combination of
	combination of satisfied preconditions reported by UAC, and makes a		satisfied preconditions reported by UAC, and makes a final decision
	final decision whether to proceed with the session. If sufficient		whether to proceed with the session. If sufficient preconditions
	preconditions are not satisfied, the UAS responds with 580-		are not satisfied, the UAS responds with 580-Precondition-Failure.
	Precondition-Failure. Otherwise, the session proceeds as in the		Otherwise, the session proceeds as in the previous example.
	previous example.
	Category Informational - Expiration 9/30/00 17
	Originating (UAC) Terminating (UAS)		Originating (UAC) Terminating (UAS)
	| SIP-Proxy(s) |		| SIP-Proxy(s) |
	| INVITE | |		| INVITE | |
	|---------------------->|---------------------->|		|---------------------->|---------------------->|
	| | |		| | |
	| 183 w/SDP | 183 w/SDP |		| 183 w/SDP | 183 w/SDP |
	|<----------------------|<----------------------|		|<----------------------|<----------------------|
	| |		| |
	| Reservation Reservation |		| Reservation Reservation |
	===========> <===========		===========> <===========
	| |		| |
	| PRECONDITION-MET |		| COMET |
	|<----------------------------------------------|		|<----------------------------------------------|
	| 200 OK (of PRECONDITION-MET) |		| 200 OK (of COMET) |
	|---------------------------------------------->|		|---------------------------------------------->|
	| |		| |
	| PRECONDITION-MET |		| COMET |
	|---------------------------------------------->|		|---------------------------------------------->|
	| 200 OK (of PRECONDITION-MET) |		| 200 OK (of COMET) |
	|<----------------------------------------------|		|<----------------------------------------------|
	|		|
	|		|
	| SIP-Proxy(s) User Alerted		| SIP-Proxy(s) User Alerted
	| | |		| | |
	| 180 Ringing | 180 Ringing |		| 180 Ringing | 180 Ringing |
	|<----------------------|<----------------------|		|<----------------------|<----------------------|
	| |		| |
	| |		| |
	| User Picks-Up		| User Picks-Up
	skipping to change at line 940 ¶		skipping to change at line 942 ¶
	9. Advantages of the Proposed Approach		9. Advantages of the Proposed Approach
	The use of two-phase call signaling makes it possible for SIP to		The use of two-phase call signaling makes it possible for SIP to
	meet user expectations that come from the telephony services.		meet user expectations that come from the telephony services.
	The reservation of resources before the user is alerted makes sure		The reservation of resources before the user is alerted makes sure
	that the network resources are assured before the destination end-		that the network resources are assured before the destination end-
	point is informed about the call.		point is informed about the call.
	Category Informational - Expiration 9/30/00 18
	The number of messages and the total delay introduced by these		The number of messages and the total delay introduced by these
	messages is kept to a minimum without sacrificing compatibility with		messages is kept to a minimum without sacrificing compatibility with
	SIP servers that do not implement preconditions.		SIP servers that do not implement preconditions.
	10. Security Considerations		10. Security Considerations
	If the contents of the SDP contained in the 183-Session-Progress are		If the contents of the SDP contained in the 183-Session-Progress are
	private then end-to-end encryption of the message body can be used		private then end-to-end encryption of the message body can be used
	to prevent unauthorized access to the content.		to prevent unauthorized access to the content.
	The security considerations given in the SIP specification apply to		The security considerations given in the SIP specification apply to
	the PRECONDITION-MET method. No additional security considerations		the COMET method. No additional security considerations specific to
	specific to the PRECONDITION-MET method are necessary.		the COMET method are necessary.
	11. References		11. Notice Regarding Intellectual Property Rights
			AT&T may seek patent or other intellectual property protection for
			some or all of the technologies disclosed in the document. If any
			standards arising from this disclosure are or become protected by
			one or more patents assigned to AT&T, AT&T intends to disclose those
			patents and license them on reasonable and non-discriminatory terms.
			Future revisions of this draft may contain additional information
			regarding specific intellectual property protection sought or
			received.
			3COM may seek patent or other intellectual property protection for
			some or all of the technologies disclosed in the document. If any
			standards arising from this disclosure are or become protected by
			one or more patents assigned to 3COM, 3COM intends to disclose those
			patents and license them on reasonable and non-discriminatory terms.
			Future revisions of this draft may contain additional information
			regarding specific intellectual property protection sought or
			received.
			12. References
	1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP		1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP
	9, RFC 2026, October 1996.		9, RFC 2026, October 1996.
	2. M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:		2. M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
	Session Initiation Protocol," RFC 2543, March 1999.		Session Initiation Protocol," RFC 2543, March 1999.
	3. M. Handley and V. Jacobson, "SDP: Session Description Protocol,"		3. M. Handley and V. Jacobson, "SDP: Session Description Protocol,"
	RFC 2327, April 1998.		RFC 2327, April 1998.
	skipping to change at line 992 ¶		skipping to change at line 1013 ¶
	Technical Report TC20967. Available at		Technical Report TC20967. Available at
	http://www.cs.columbia.edu/~hgs/papers/Pan98_YESSIR.ps.gz.		http://www.cs.columbia.edu/~hgs/papers/Pan98_YESSIR.ps.gz.
	8. PacketCable, Dynamic Quality of Service Specification, pkt-sp-		8. PacketCable, Dynamic Quality of Service Specification, pkt-sp-
	dqos-i01-991201, December 1, 1999. Available at		dqos-i01-991201, December 1, 1999. Available at
	http://www.packetcable.com/specs/pkt-sp-dqos-i01-991202.pdf.		http://www.packetcable.com/specs/pkt-sp-dqos-i01-991202.pdf.
	9. S. Kent and R. Atkinson, "Security architecture for the internet		9. S. Kent and R. Atkinson, "Security architecture for the internet
	protocol," RFC 2401, November 1998.		protocol," RFC 2401, November 1998.
	Category Informational - Expiration 9/30/00 19
	10. H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP:		10. H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP:
	a Transport Protocol for Real-Time Applications," RFC 1889,		a Transport Protocol for Real-Time Applications," RFC 1889,
	January 1996.		January 1996.
	11. M. Handley, C. Perkins, and E. Whelan, "Session Announcement		11. M. Handley, C. Perkins, and E. Whelan, "Session Announcement
	Protocol," Internet Draft, <draft-ietf-mmusic-sap-v2-06.txt>,		Protocol," Internet Draft, <draft-ietf-mmusic-sap-v2-06.txt>,
	March 2000, Work in Progress.		March 2000, Work in Progress.
	12. "Reliability of Provisional Responses in SIP," Internet Draft		12. "Reliability of Provisional Responses in SIP," Internet Draft
	<draft-ietf-sip-100rel-00.txt>, January 2000, Work in Progress.		<draft-ietf-sip-100rel-00.txt>, January 2000, Work in Progress.
	12. Acknowledgments		13. Acknowledgments
	The Distributed Call Signaling work in the PacketCable project is		The Distributed Call Signaling work in the PacketCable project is
	the work of a large number of people, representing many different		the work of a large number of people, representing many different
	companies. The authors would like to recognize and thank the		companies. The authors would like to recognize and thank the
	following for their assistance: John Wheeler, Motorola; David		following for their assistance: John Wheeler, Motorola; David
	Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows,		Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jay Strater,
	Jay Strater, Jeff Ollis, Clive Holborow, General Instruments; Doug		Jeff Ollis, Clive Holborow, General Instruments; Doug Newlin, Guido
	Newlin, Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay		Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; Farzi
	Networks; Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael		Khazai, Nortel; John Chapman, Bill Guckel, Cisco; Chuck Kalmanek,
	Ramalho, Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James		Doug Nortz, John Lawser, James Cheng, Tung-Hai Hsiao, Partho Mishra,
	Cheng, Tung-Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies;		AT&T; Telcordia Technologies; and Lucent Cable Communications.
	and Lucent Cable Communications.
	13. Author's Addresses		14. Author's Addresses
	Bill Marshall		Bill Marshall
	AT&T		AT&T
	Florham Park, NJ 07932		Florham Park, NJ 07932
	Email: wtm@research.att.com		Email: wtm@research.att.com
	K. K. Ramakrishnan		K. K. Ramakrishnan
	AT&T		AT&T
	Florham Park, NJ 07932		Florham Park, NJ 07932
	Email: kkrama@research.att.com		Email: kkrama@research.att.com
	skipping to change at line 1042 ¶		skipping to change at line 1061 ¶
	Louisville, CO 80027		Louisville, CO 80027
	Email: E.Miller@Cablelabs.com		Email: E.Miller@Cablelabs.com
	Glenn Russell		Glenn Russell
	CableLabs		CableLabs
	Louisville, CO 80027		Louisville, CO 80027
	Email: G.Russell@Cablelabs.com		Email: G.Russell@Cablelabs.com
	Burcak Beser		Burcak Beser
	3Com		3Com
	Category Informational - Expiration 9/30/00 20
	Rolling Meadows, IL 60008		Rolling Meadows, IL 60008
	Email: Burcak_Beser@3com.com		Email: Burcak_Beser@3com.com
	Mike Mannette		Mike Mannette
	3Com		3Com
	Rolling Meadows, IL 60008		Rolling Meadows, IL 60008
	Email: Michael_Mannette@3com.com		Email: Michael_Mannette@3com.com
	Kurt Steinbrenner		Kurt Steinbrenner
	3Com		3Com
	skipping to change at line 1067 ¶		skipping to change at line 1084 ¶
	Dave Oran		Dave Oran
	Cisco		Cisco
	Acton, MA 01720		Acton, MA 01720
	Email: oran@cisco.com		Email: oran@cisco.com
	Flemming Andreasen		Flemming Andreasen
	Cisco		Cisco
	Edison, NJ		Edison, NJ
	Email: fandreas@cisco.com		Email: fandreas@cisco.com
			Michael Ramalho
			Cisco
			Wall Township, NJ
			Email: mramalho@cisco.com
	John Pickens		John Pickens
	Com21		Com21
	San Jose, CA		San Jose, CA
	Email: jpickens@com21.com		Email: jpickens@com21.com
	Poornima Lalwaney		Poornima Lalwaney
	Motorola		Nokia
	San Diego, CA 92121		San Diego, CA 92121
	Email: plalwaney@gi.com		Email: poornima.lalwaney@nokia.com
	Jon Fellows		Jon Fellows
	Motorola		Motorola
	San Diego, CA 92121		San Diego, CA 92121
	Email: jfellows@gi.com		Email: jfellows@gi.com
	Doc Evans		Doc Evans
	Secure Cable Solutions		Secure Cable Solutions
	Westminster, CO 30120		Westminster, CO 30120
	Email: drevans@securecable.com		Email: drevans@securecable.com
	skipping to change at line 1097 ¶		skipping to change at line 1119 ¶
	Keith Kelly		Keith Kelly
	NetSpeak		NetSpeak
	Boca Raton, FL 33587		Boca Raton, FL 33587
	Email: keith@netspeak.com		Email: keith@netspeak.com
	Adam Roach		Adam Roach
	Ericsson		Ericsson
	Richardson, TX 75081		Richardson, TX 75081
	Email: adam.roach@ericsson.com		Email: adam.roach@ericsson.com
	Category Informational - Expiration 9/30/00 21
	Jonathan Rosenberg		Jonathan Rosenberg
	dynamicsoft		dynamicsoft
	West Orange, NJ 07052		West Orange, NJ 07052
	Email: jdrosen@dynamicsoft.com		Email: jdrosen@dynamicsoft.com
			Dean Willis
			Dynamicsoft
			West Orange, NJ 07052
			Email: dwillis@dynamicsoft.com
	Henning Schulzrinne		Henning Schulzrinne
	Columbia University		Columbia University
	New York, NY		New York, NY
	Email: schulzrinne@cs.columbia.edu		Email: schulzrinne@cs.columbia.edu
	Steve Donovan		Steve Donovan
	MCI Worldcom		MCI Worldcom
	Richardson, Texas 75081		Richardson, Texas 75081
	Email: steven.r.donovan@wcom.com		Email: steven.r.donovan@wcom.com
	Category Informational - Expiration 9/30/00 22
	Full Copyright Statement		Full Copyright Statement
	"Copyright (C) The Internet Society (date). All Rights Reserved.		"Copyright (C) The Internet Society (date). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implmentation may be prepared, copied, published		or assist in its implmentation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph		kind, provided that the above copyright notice and this paragraph
	are included on all such copies and derivative works. However, this		are included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	skipping to change at line 1139 ¶		skipping to change at line 1163 ¶
	English. The limited permissions granted above are perpetual and		English. The limited permissions granted above are perpetual and
	will not be revoked by the Internet Society or its successors or		will not be revoked by the Internet Society or its successors or
	assigns. This document and the information contained herein is		assigns. This document and the information contained herein is
	provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE		provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
	INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR		INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
	IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
	Expiration Date This memo is filed as <draft-manyfolks-sip-resource-		Expiration Date This memo is filed as <draft-manyfolks-sip-resource-
	00.txt>, and expires September 30, 2000.		01.txt>, and expires December 31, 2000.
	Category Informational - Expiration 9/30/00 23
End of changes. 95 change blocks.
	237 lines changed or deleted		261 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/