draft-ietf-mmusic-sdp-offer-answer-00.txt		draft-ietf-mmusic-sdp-offer-answer-01.txt
	Internet Engineering Task Force MMUSIC WG		Internet Engineering Task Force MMUSIC WG
	Internet Draft J.Rosenberg,H.Schulzrinne		Internet Draft J.Rosenberg
	draft-ietf-mmusic-sdp-offer-answer-00.txt dynamicsoft,Columbia U.		dynamicsoft
	January 31, 2002		H.Schulzrinne
	Expires: July 2002		Columbia U.
			draft-ietf-mmusic-sdp-offer-answer-01.txt
			February 21, 2002
			Expires: August 2002
	An Offer/Answer Model with SDP		An Offer/Answer Model with SDP
	STATUS OF THIS MEMO		STATUS OF THIS MEMO
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 44		skipping to change at page 2, line 5
	This document defines a mechanism by which two entities can make use		This document defines a mechanism by which two entities can make use
	of SDP to arrive at a common view of a multimedia session between		of SDP to arrive at a common view of a multimedia session between
	them. In the model, one participant offers the other a description of		them. In the model, one participant offers the other a description of
	the desired session from their perspective, and the other participant		the desired session from their perspective, and the other participant
	answers with the desired session from their perspective. This		answers with the desired session from their perspective. This
	offer/answer model is most useful in unicast sessions where		offer/answer model is most useful in unicast sessions where
	information from both participants is needed for the complete view of		information from both participants is needed for the complete view of
	the session. The offer/answer model is used by protocols like the		the session. The offer/answer model is used by protocols like the
	Session Initiation Protocol (SIP).		Session Initiation Protocol (SIP).
	J.Rosenberg,H.Schulzrinne [Page a]
	Table of Contents		Table of Contents
	1 Introduction ........................................ 2		1 Introduction ........................................ 3
	2 Terminology ......................................... 3		2 Terminology ......................................... 4
	3 Definitions ......................................... 3		3 Definitions ......................................... 4
	4 Protocol Operation .................................. 3		4 Protocol Operation .................................. 4
	5 Generating the initial offer ........................ 4		5 Generating the initial offer ........................ 5
	5.1 Unicast Streams ..................................... 5		5.1 Unicast Streams ..................................... 6
	5.2 Multicast Streams ................................... 8		5.2 Multicast Streams ................................... 9
	6 Generating the answer ............................... 8		6 Generating the answer ............................... 9
	6.1 Unicast Streams ..................................... 8		6.1 Unicast Streams ..................................... 10
	6.2 Multicast Streams ................................... 11		6.2 Multicast Streams ................................... 12
	7 Offerer Processing of the Answer .................... 11		7 Offerer Processing of the Answer .................... 13
	8 Modifying the session ............................... 11		8 Modifying the session ............................... 13
	8.1 Adding a media stream ............................... 12		8.1 Adding a Media Stream ............................... 14
	8.2 Removing a media stream ............................. 13		8.2 Removing a Media Stream ............................. 14
	8.3 Modifying a Media Stream ............................ 13		8.3 Modifying a Media Stream ............................ 15
	8.3.1 Modifying Address, Port or Transport ................ 13		8.3.1 Modifying Address, Port or Transport ................ 15
	8.3.2 Changing the Set of Media Formats ................... 14		8.3.2 Changing the Set of Media Formats ................... 16
	8.3.3 Changing Media Types ................................ 15		8.3.3 Changing Media Types ................................ 17
	8.3.4 Changing Attributes ................................. 15		8.3.4 Changing Attributes ................................. 17
	8.4 Putting a media stream on hold ...................... 16		8.4 Putting a Unicast Media Stream on Hold .............. 17
	9 Indicating Capabilities ............................. 16		9 Indicating Capabilities ............................. 18
	10 Example Offer/Answer Exchanges ...................... 17		10 Example Offer/Answer Exchanges ...................... 19
	10.1 Basic Exchange ...................................... 17		10.1 Basic Exchange ...................................... 19
	10.2 One of N Codec Selection ............................ 19		10.2 One of N Codec Selection ............................ 21
	11 Changes since draft-rosenberg-mmusic-sdp-offer-		11 Security Considerations ............................. 23
	answer-00 ...................................................... 21		12 IANA Considerations ................................. 23
	12 Author's Addresses .................................. 22		13 Acknowledgements .................................... 24
	13 Bibliography ........................................ 23		14 Author's Addresses .................................. 24
			15 Normative References ................................ 24
			16 Non-Normative References ............................ 25
	1 Introduction		1 Introduction
	The Session Description Protocol (SDP) [1] was originally conceived		The Session Description Protocol (SDP) [1] was originally conceived
	as a way to describe multicast sessions carried on the Mbone. The		as a way to describe multicast sessions carried on the Mbone. The
	Session Announcement Protocol (SAP) [2] was devised as a multicast		Session Announcement Protocol (SAP) [6] was devised as a multicast
	mechanism to carry SDP messages. Although the SDP specification		mechanism to carry SDP messages. Although the SDP specification
	allows for unicast operation, it is not complete. Unlike multicast,		allows for unicast operation, it is not complete. Unlike multicast,
	where there is a global view of the session that is used by all		where there is a global view of the session that is used by all
	participants, unicast sessions involve two participants, and a		participants, unicast sessions involve two participants, and a
	complete view of the session requires information from both		complete view of the session requires information from both
	participants, and agreement on parameters between them.		participants, and agreement on parameters between them.
	As an example, a multicast session requires conveying a single		As an example, a multicast session requires conveying a single
	multicast address for a particular media stream. However, for a		multicast address for a particular media stream. However, for a
	unicast session, two addresses are needed - one for each participant.		unicast session, two addresses are needed - one for each participant.
	skipping to change at page 2, line 35		skipping to change at page 3, line 35
	As a result, even though SDP has the expressiveness to describe		As a result, even though SDP has the expressiveness to describe
	unicast sessions, it is missing the semantics and operational details		unicast sessions, it is missing the semantics and operational details
	of how it is actually done. In this document, we remedy that by		of how it is actually done. In this document, we remedy that by
	defining a simple offer/answer model based on SDP. In this model, one		defining a simple offer/answer model based on SDP. In this model, one
	participant in the session generates an SDP that constitutes the		participant in the session generates an SDP that constitutes the
	offer - the set of media streams and codecs the offerer wishes to		offer - the set of media streams and codecs the offerer wishes to
	use, along with the IP addresses and ports the offer would like to		use, along with the IP addresses and ports the offer would like to
	use to receive the media. The offer is conveyed to the other		use to receive the media. The offer is conveyed to the other
	participant, called the answerer. The answerer generates an answer,		participant, called the answerer. The answerer generates an answer,
	which is an SDP that responds to the offer provided it. The answer		which is an SDP that responds to the offer provided it. The answer
	has a matching media stream for each one in the offer, indicating		has a matching media stream for each stream in the offer, indicating
	whether the stream is accepted or not, along with the codecs that		whether the stream is accepted or not, along with the codecs that
	will be used and the IP addresses and ports that the answerer wants		will be used and the IP addresses and ports that the answerer wants
	to use to receive media.		to use to receive media.
	It is also possible for a multicast session to work similarly to a		It is also possible for a multicast session to work similarly to a
	unicast one; its parameters are negotiation between a pair of users		unicast one; its parameters are negotiated between a pair of users as
	as in the unicast case, but both sides send packets to the same		in the unicast case, but both sides send packets to the same
	multicast address, rather than unicast ones. This document also		multicast address, rather than unicast ones. This document also
	discusses the application of the offer/answer model to multicast		discusses the application of the offer/answer model to multicast
	streams.		streams.
	We also define guidelines for how the offer/answer model is used to		We also define guidelines for how the offer/answer model is used to
	update a session once it has begun.		update a session after an initial offer/answer exchange.
	The means by which the offers and answers are conveyed are outside		The means by which the offers and answers are conveyed are outside
	the scope of this document. The offer/answer model defined here is		the scope of this document. The offer/answer model defined here is
	the mandatory baseline mechanism used by the Session Initiation		the mandatory baseline mechanism used by the Session Initiation
	Protocol (SIP) [3].		Protocol (SIP) [7].
	2 Terminology		2 Terminology
	In this document, the key words "MUST", "MUST NOT", "REQUIRED",		In this document, the key words "MUST", "MUST NOT", "REQUIRED",
	"SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",		"SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and		and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and
	indicate requirement levels for compliant implementations.		indicate requirement levels for compliant implementations.
	3 Definitions		3 Definitions
	The following terms are used throughout this document:		The following terms are used throughout this document:
	Agent: An agent is the protocol implementation involved in the		Agent: An agent is the protocol implementation involved in the
	offer/answer exchange. There are two agents involved in an		offer/answer exchange. There are two agents involved in an
	offer/answer exchange.		offer/answer exchange.
	Answer: An SDP message sent by an answerer in response to an		Answer: An SDP message sent by an answerer in response to an
	offer received from an offerer.		offer received from an offerer.
	Answerer: An agent capable of sending and/or receiving media,		Answerer: An agent which receives a session description from
	which receives a session description from another agent		another agent describing aspects of desired media
	describing aspects of desired media communication, and then		communication, and then responds to that with its own
	responds to that with its own session description.		session description.
	Media Stream: From RTSP [5], a media stream is a single media		Media Stream: From RTSP [8], a media stream is a single media
	instance, e.g., an audio stream or a video stream as well		instance, e.g., an audio stream or a video stream as well
	as a single whiteboard or shared application group. In SDP,		as a single whiteboard or shared application group. In SDP,
	a media stream is described by an m-line and its associated		a media stream is described by an "m=" line and its
	attributes.		associated attributes.
	Offer: An SDP message sent by an offerer.		Offer: An SDP message sent by an offerer.
	Offerer: An agent capable of sending and/or receiving media,		Offerer: An agent which generates a session description in order
	which generates a session description in order to create or		to create or modify a session.
	modify a session.
	4 Protocol Operation		4 Protocol Operation
	The offer/answer exchange assumes the existence of a higher layer		The offer/answer exchange assumes the existence of a higher layer
	protocol (such as SIP) which is capable of exchanging SDP for the		protocol (such as SIP) which is capable of exchanging SDP for the
	purposes of communication establishment between agents.		purposes of session establishment between agents.
	Protocol operation begins when one agent sends an initial offer to		Protocol operation begins when one agent sends an initial offer to
	another agent. An offer is initial if it is outside of any context		another agent. An offer is initial if it is outside of any context
	that may have already been established through the higher layer		that may have already been established through the higher layer
	protocol. It is assumed that the higher layer protocol provides		protocol. It is assumed that the higher layer protocol provides
	maintenance of some kind of context which allows the various SDP		maintenance of some kind of context which allows the various SDP
	exchanges to be associated together.		exchanges to be associated together.
	The agent receiving the offer MAY generate an answer, or it MAY		The agent receiving the offer MAY generate an answer, or it MAY
	reject the offer. The means for rejecting an offer are dependent on		reject the offer. The means for rejecting an offer are dependent on
	the higher layer protocol. The offer/answer exchange is atomic; if		the higher layer protocol. The offer/answer exchange is atomic; if
	the answer is rejected, the session reverts to the state prior to the		the answer is rejected, the session reverts to the state prior to the
	offer (which may be absence of a session).		offer (which may be absence of a session).
	At any time, either agent MAY generate a new offer that updates the		At any time, either agent MAY generate a new offer that updates the
	communications session. However, it MUST NOT generate a new offer if		session. However, it MUST NOT generate a new offer if it has received
	it has received an offer which it has not yet answered or reject.		an offer which it has not yet answered or rejected. Furthermore, it
	Furthermore, it MUST NOT generate a new offer if it has generated a		MUST NOT generate a new offer if it has generated a prior offer for
	prior offer for which it has not yet received an answer or a		which it has not yet received an answer or a rejection. If an agent
	rejection. The higher layer protocol will need to provide a means for		receives an offer after having sent one, but before receiving an
	ordering of messages in each direction.		answer to it, this is considered a "glare" condition.
			The term glare was originally used in circuit switched
			telecommunications networks to describe the condition where
			two switches both attempt to seize the same available
			circuit on the same trunk at the same time. Here, it means
			both agents have attempted to send an updated offer at the
			same time.
			The higher layer protocol needs to provide a means for resolving such
			conditions. The higher layer protocol will need to provide a means
			for ordering of messages in each direction.
	5 Generating the initial offer		5 Generating the initial offer
	The offer (and answer) MUST be a valid SDP, as defined by RFC 2327		The offer (and answer) MUST be a valid SDP, as defined by RFC 2327
	[1], with one exception. RFC2327 mandates that either an e or a p		[1], with one exception. RFC2327 mandates that either an e or a p
	line is present in the SDP. This specification relaxes that		line is present in the SDP. This specification relaxes that
	constraint; an SDP formulated for an offer/answer application MAY		constraint; an SDP formulated for an offer/answer application MAY
	omit both the e and p lines. The numeric value of the session id and		omit both the e and p lines. The numeric value of the session id and
	version in the o line MUST be representable with a 64 bit signed		version in the o line MUST be representable with a 64 bit signed
	integer. Although the SDP specification allows for multiple session		integer. Although the SDP specification allows for multiple session
	descriptions to be concatenated together into a large SDP message, an		descriptions to be concatenated together into a large SDP message, an
	SDP message used in the offer/answer model MUST contain only a single		SDP message used in the offer/answer model MUST contain exactly one
	session description.		session description.
	The SDP "s=" line conveys the subject of the media stream, which is		The SDP "s=" line conveys the subject of the media stream, which is
	reasonably defined for multicast, but ill defined for unicast. For		reasonably defined for multicast, but ill defined for unicast. For
	unicast streams, it is RECOMMENDED that it consist of a single space		unicast streams, it is RECOMMENDED that it consist of a single space
	character (0x20).		character (0x20).
	Unfortunately, SDP does not allow the "s=" line to be		Unfortunately, SDP does not allow the "s=" line to be
	empty.		empty.
	The SDP "t=" line conveys the time of the session. Generally, streams		The SDP "t=" line conveys the time of the session. Generally, streams
	for unicast sessions are created and destroyed through external		for unicast sessions are created and destroyed through external
	signaling means, such as SIP. In that case, the "t=" line SHOULD have		signaling means, such as SIP. In that case, the "t=" line SHOULD have
	a value of "0 0".		a value of "0 0".
	The offer MAY contain zero or more media streams (each media stream		The offer will contain zero or more media streams (each media stream
	is described by an m line and its associated attributes). Zero media		is described by an "m=" line and its associated attributes). Zero
	streams implies that the offerer wishes to communicate, but that the		media streams implies that the offerer wishes to communicate, but
	streams for the session will be added at a later time through a		that the streams for the session will be added at a later time
	modified offer. The streams MAY be for a mix unicast and multicast;		through a modified offer. The streams MAY be for a mix of unicast and
	the latter obviously implies a multicast address in the c line.		multicast; the latter obviously implies a multicast address in the
			relevant "c=" line(s).
	Construction of each offered stream depends on whether the stream is		Construction of each offered stream depends on whether the stream is
	multicast or unicast.		multicast or unicast.
	5.1 Unicast Streams		5.1 Unicast Streams
	If the offerer wishes to only send media on a stream to its peer, it		If the offerer wishes to only send media on a stream to its peer, it
	MUST include an a=sendonly attribute as part of the media		MUST mark the stream as sendonly with the "a=sendonly" attribute. We
	description. If the offerer wishes to only receive media from its		refer to a stream as being marked with a certain direction if a
	peer, it MUST include an a=recvonly attribute as part of the media		direction attribute was present as either a media stream attribute or
	description. If the offerer wishes to communicate, but wishes to		a session attribute. If the offerer wishes to only receive media from
	neither send nor receive media at this time, it MUST include an		its peer, it MUST mark the stream as recvonly. If the offerer wishes
	a=inactive attribute as part of the media description. The inactive		to communicate, but wishes to neither send nor receive media at this
	direction attribute is specified in RFC 3108 [6]. Note that in the		time, it MUST mark the stream with an "a=inactive" attribute. The
	case of the Real Time Transport Protocol (RTP) [7], RTCP is still		inactive direction attribute is specified in RFC 3108 [3]. Note that
	sent and received for sendonly, recvonly and inactive streams. That		in the case of the Real Time Transport Protocol (RTP) [4], RTCP is
	is, the directionality of the media stream has no impact on the RTCP		still sent and received for sendonly, recvonly and inactive streams.
	usage. If the offerer wishes to both send and receive media with its		That is, the directionality of the media stream has no impact on the
	peer, it MAY include an a=sendrecv attribute, or MAY omit it, since		RTCP usage. If the offerer wishes to both send and receive media with
	it is the default.		its peer, it MAY include an "a=sendrecv" attribute, or it MAY omit
			it, since sendrecv is the default.
	For recvonly and sendrecv streams, the port number and address in the		For recvonly and sendrecv streams, the port number and address in the
	offer indicate where the offer would like to receive the media		offer indicate where the offerer would like to receive the media
	stream. For sendonly RTP streams, the address and port number		stream. For sendonly RTP streams, the address and port number
	indirectly indicate where RTCP reports are to be sent to.		indirectly indicate where the offerer wants to receive RTCP reports.
	Specifically, RTCP reports are sent to the port number one higher		Unless there is an explicit indication otherwise, reports are sent to
	than the number indicated. The IP address and port present in the		the port number one higher than the number indicated. The IP address
	offer indicate nothing about the source IP address and source port of		and port present in the offer indicate nothing about the source IP
	RTP and RTCP packets that will be sent by the offerer. A port number		address and source port of RTP and RTCP packets that will be sent by
	of zero in the offer indicates that the stream is offered but should		the offerer. A port number of zero in the offer indicates that the
	never be used. This has no useful semantics in an initial offer, but		stream is offered but MUST NOT be used. This has no useful semantics
	is allowed for reasons of completeness, since the response can		in an initial offer, but is allowed for reasons of completeness,
	contain a zero port indicating a rejected stream (Section 6).		since the answer can contain a zero port indicating a rejected stream
	Furthermore, existing streams can be terminated by setting the port		(Section 6). Furthermore, existing streams can be terminated by
	to zero (Section 8). In general, a port number of zero indicates that		setting the port to zero (Section 8). In general, a port number of
	the media stream is not wanted.		zero indicates that the media stream is not wanted.
	The list of media formats for each media stream conveys two pieces of		The list of media formats for each media stream conveys two pieces of
	information, namely the set of formats (codecs and any parameters		information, namely the set of formats (codecs and any parameters
	associated with the codec, in the case of RTP) that the offerer is		associated with the codec, in the case of RTP) that the offerer is
	capable of sending and/or receiving (depending on the direction		capable of sending and/or receiving (depending on the direction
	attributes), and, in the case of RTP, the RTP payload type numbers		attributes), and, in the case of RTP, the RTP payload type numbers
	used to identify those formats. If multiple formats are listed, it		used to identify those formats. If multiple formats are listed, it
	means that the offerer is capable of making use of any of those		means that the offerer is capable of making use of any of those
	formats during the session. In other words, the answerer MAY change		formats during the session. In other words, the answerer MAY change
	formats in the middle of the session, without sending a new offer, to		formats in the middle of the session, without sending a new offer, to
	make use of any of those listed. For a sendonly stream, the offer		make use of any of the formats listed. For a sendonly stream, the
	SHOULD indicate those formats the offerer is willing to send for this		offer SHOULD indicate those formats the offerer is willing to send
	stream. For a recvonly stream, the offer SHOULD indicate those		for this stream. For a recvonly stream, the offer SHOULD indicate
	formats the offerer is willing to receive for this stream. For a		those formats the offerer is willing to receive for this stream. For
	sendrecv stream, the offer SHOULD indicate those codecs that the		a sendrecv stream, the offer SHOULD indicate those codecs that the
	offerer is willing to send and receive with.		offerer is willing to send and receive with.
	For recvonly RTP streams, the payload type numbers indicate the value		For recvonly RTP streams, the payload type numbers indicate the value
	of the payload type field in RTP packets the offerer is expecting to		of the payload type field in RTP packets the offerer is expecting to
	receive for that codec. For sendonly RTP streams, the payload type		receive for that codec. For sendonly RTP streams, the payload type
	numbers indicate the value of the payload type field in RTP packets		numbers indicate the value of the payload type field in RTP packets
	the offerer is planning to send for that codec type. For sendrecv RTP		the offerer is planning to send for that codec. For sendrecv RTP
	streams, the payload type numbers indicate the value of the payload		streams, the payload type numbers indicate the value of the payload
	type field the offerer expects to receive, and would prefer to send.		type field the offerer expects to receive, and would prefer to send.
	However, for sendonly and sendrecv streams, the answer might indicate		However, for sendonly and sendrecv streams, the answer might indicate
	different payload type numbers for the same codecs, in which case,		different payload type numbers for the same codecs, in which case,
	the offerer MUST send with the payload type numbers from the answer.		the offerer MUST send with the payload type numbers from the answer.
	Different payload type numbers may be needed in each		Different payload type numbers may be needed in each
	direction because of interoperability concerns with H.323.		direction because of interoperability concerns with H.323.
	As per RFC 2327, fmtp parameters MAY be present to provide additional		As per RFC 2327, fmtp parameters MAY be present to provide additional
	parameters of the media format.		parameters of the media format.
	In the case of RTP streams, all media descriptions SHOULD contain		In the case of RTP streams, all media descriptions SHOULD contain
	"a=rtpmap" mappings from RTP payload types to encodings. If there is		"a=rtpmap" mappings from RTP payload types to encodings. If there is
	no "a=rtpmap", the static payload type table from RFC 1890 [8] is to		no "a=rtpmap", the default payload type mapping, as defined by the
	be used.		current profile in use (for example, RFC 1890 [5]) is to be used.
	This allows easier migration away from static payload		This allows easier migration away from static payload
	types.		types.
	In all cases, the formats in the m line MUST be listed in order of		In all cases, the formats in the "m=" line MUST be listed in order of
	preference, with the first format listed being preferred. In this		preference, with the first format listed being preferred. In this
	case, preferred means that the recipient of the offer SHOULD use the		case, preferred means that the recipient of the offer SHOULD use the
	format with the highest preference that is acceptable to it.		format with the highest preference that is acceptable to it.
	If the ptime attribute is present for a stream, it indicates the		If the ptime attribute is present for a stream, it indicates the
	desired packetization interval that the offerer would like to		desired packetization interval that the offerer would like to
	receive.		receive. The ptime attribute MUST be greater than zero.
	If the bandwidth attribute is present for a stream, it indicates the		If the bandwidth attribute is present for a stream, it indicates the
	desired bandwidth that the offerer would like to receive. A value of		desired bandwidth that the offerer would like to receive. A value of
	zero is allowed, but discouraged. It indicates that no media should		zero is allowed, but discouraged. It indicates that no media should
	be sent. In the case of RTP, it would also disable all RTCP.		be sent. In the case of RTP, it would also disable all RTCP.
	If multiple media streams of different types are present, it means		If multiple media streams of different types are present, it means
	that the offerer wishes to use those streams at the same time. A		that the offerer wishes to use those streams at the same time. A
	typical case is an audio and video stream as part of a		typical case is an audio and a video stream as part of a
	videoconference.		videoconference.
	If multiple media streams of the same type are present in an offer,		If multiple media streams of the same type are present in an offer,
	it means that the offerer wishes to send (and/or receive) multiple		it means that the offerer wishes to send (and/or receive) multiple
	streams of that type at the same time. When sending multiple streams		streams of that type at the same time. When sending multiple streams
	of the same type, it is a matter of local policy as to how each media		of the same type, it is a matter of local policy as to how each media
	source of that type (for example, a video camera and VCR in the case		source of that type (for example, a video camera and VCR in the case
	of video) is mapped to each stream. When a user has a single source		of video) is mapped to each stream. When a user has a single source
	for a particular media type, only one policy makes sense - that		for a particular media type, only one policy makes sense: the source
	source is sent to each stream of the same type. Each stream MAY use		is sent to each stream of the same type. Each stream MAY use
	different encodings. When receiving multiple streams of the same		different encodings. When receiving multiple streams of the same
	type, it is a matter of local policy as to how each stream is mapped		type, it is a matter of local policy as to how each stream is mapped
	to the various media sinks for that particular type (for example,		to the various media sinks for that particular type (for example,
	speakers or a recording device in the case of audio). There are a few		speakers or a recording device in the case of audio). There are a few
	constraints on the policies, however. First, when receiving multiple		constraints on the policies, however. First, when receiving multiple
	streams of the same type, each stream MUST be mapped to at least one		streams of the same type, each stream MUST be mapped to at least one
	sink for the purpose of presentation to the user. In other words, the		sink for the purpose of presentation to the user. In other words, the
	intent of receiving multiple streams of the same type is that they		intent of receiving multiple streams of the same type is that they
	should all be presented in parallel, rather than choosing just one.		should all be presented in parallel, rather than choosing just one.
	Another constraint is that when multiple streams are received and		Another constraint is that when multiple streams are received and
	skipping to change at page 7, line 40		skipping to change at page 9, line 6
	combining operation would be to present all of them to the user		combining operation would be to present all of them to the user
	interface. The third constraint is that if multiple sources are		interface. The third constraint is that if multiple sources are
	mapped to the same stream, those sources MUST be combined in some		mapped to the same stream, those sources MUST be combined in some
	media specific way before they are sent on the stream. Although		media specific way before they are sent on the stream. Although
	policies beyond these constraints are flexible, an agent won't		policies beyond these constraints are flexible, an agent won't
	generally want a policy that will copy media from its sinks to its		generally want a policy that will copy media from its sinks to its
	sources unless it is a conference server (i.e., don't copy received		sources unless it is a conference server (i.e., don't copy received
	media on one stream to another stream).		media on one stream to another stream).
	A typical usage example for multiple media streams of the same type		A typical usage example for multiple media streams of the same type
	is a pre-paid calling card application, where the user can enter in a		is a pre-paid calling card application, where the user can press and
	"long pound" at any time during a call to hangup and make a new call		hold the pound ("#") key at any time during a call to hangup and make
	on the same card. This requires media from the user to two		a new call on the same card. This requires media from the user to two
	destinations - the remote gateway, and to DTMF processing application		destinations - the remote gateway, and the DTMF processing
	which looks for the long pound. This would be accomplished with two		application which looks for the pound. This could be accomplished
	media streams, one sendrecv to the gateway, and the other sendonly		with two media streams, one sendrecv to the gateway, and the other
	(from the perspective of the user) to the DTMF application.		sendonly (from the perspective of the user) to the DTMF application.
	Once the offerer has sent the offer, it MUST be prepared to receive		Once the offerer has sent the offer, it MUST be prepared to receive
	media for any recvonly streams described by that offer. It MUST be		media for any recvonly streams described by that offer. It MUST be
	prepared to send and receive media for any sendrecv streams in the		prepared to send and receive media for any sendrecv streams in the
	offer (of course, it cannot actually send until the peer provides an		offer, and send media for any sendonly streams in the offer (of
	answer with the needed address and port information). It MUST be		course, it cannot actually send until the peer provides an answer
	prepared to receive media for recvonly or sendrecv streams using any		with the needed address and port information). In the case of RTP,
	media formats listed for those streams in the offer. In the case of		even though it may receive media before the answer arrives, it will
	RTP, even though it may receive media before the answer arrives, it		not be able to send RTCP receiver reports until the answer arrives.
	will not be able to send RTCP receiver reports until the answer
	arrives.
	5.2 Multicast Streams		5.2 Multicast Streams
	If a session description contains a multicast media stream which is		If a session description contains a multicast media stream which is
	listed as send (receive) only, it means that the answerer can only		listed as receive (send) only, it means that the participants,
	send (receive) on that stream. The reversal of semantics for		including the offerer and answerer, can only receive (send) on that
	multicast is an artifact of the strong multicast bias of RFC 2327.		stream. This differs from the unicast view, where the directionality
			refers to the flow of media between offerer and answerer.
	Beyond that clarification, the semantics of an offered multicast		Beyond that clarification, the semantics of an offered multicast
	stream are exactly as described in RFC 2327 [1].		stream are exactly as described in RFC 2327 [1].
	6 Generating the answer		6 Generating the answer
	The answer to an offered SDP is based on the offered SDP. If the		The answer to an offered SDP is based on the offered SDP. If the
	answer is different from the offer in any way (different IP		answer is different from the offer in any way (different IP
	addresses, ports, etc.), the origin line MUST be different in the		addresses, ports, etc.), the origin line MUST be different in the
	answer, since the answer is generated by a different entity. In that		answer, since the answer is generated by a different entity. In that
	case, the version number in the o line of the answer is unrelated to		case, the version number in the "o=" line of the answer is unrelated
	the version number in the o line of the offer.		to the version number in the o line of the offer.
	For each m line in the offer, there MUST be a corresponding m line in		For each "m=" line in the offer, there MUST be a corresponding "m="
	the answer. The answer MUST contain exactly the same number of m		line in the answer. The answer MUST contain exactly the same number
	lines as the offer. This allows for streams to be matched up based on		of "m=" lines as the offer. This allows for streams to be matched up
	their order. This implies that if the offer contained zero m lines,		based on their order. This implies that if the offer contained zero
	the answer MUST contain zero m lines.		"m=" lines, the answer MUST contain zero "m=" lines.
	The t line in the answer MUST equal that of the offer. The time of		The "t=" line in the answer MUST equal that of the offer. The time of
	the session cannot be negotiated.		the session cannot be negotiated.
	An offered stream MAY be rejected in the answer, for any reason. If a		An offered stream MAY be rejected in the answer, for any reason. If a
	stream is rejected, the offerer and answerer MUST NOT generate media		stream is rejected, the offerer and answerer MUST NOT generate media
	(or RTCP packets) for that stream. To reject an offered stream, the		(or RTCP packets) for that stream. To reject an offered stream, the
	port number in the corresponding stream in the answer is set to zero.		port number in the corresponding stream in the answer MUST be set to
	Any media formats listed are ignored. At least one MUST be present,		zero. Any media formats listed are ignored. At least one MUST be
	as specified by SDP.		present, as specified by SDP.
	Constructing an answer for each offered stream differs for unicast		Constructing an answer for each offered stream differs for unicast
	and multicast.		and multicast.
	6.1 Unicast Streams		6.1 Unicast Streams
	If a stream is offered with a unicast address, the answer MUST		If a stream is offered with a unicast address, the answer for that
	contain a unicast address. The media type of the stream in the answer		stream MUST contain a unicast address. The media type of the stream
	MUST match that of the offer.		in the answer MUST match that of the offer.
	If a stream is offered as sendonly, the corresponding stream MUST be		If a stream is offered as sendonly, the corresponding stream MUST be
	marked as recvonly or inactive in the answer. If a media stream is		marked as recvonly or inactive in the answer. If a media stream is
	listed as recvonly in the offer, the answer MUST be marked as		listed as recvonly in the offer, the answer MUST be marked as
	sendonly or inactive in the answer. If an offered media stream is		sendonly or inactive in the answer. If an offered media stream is
	listed as sendrecv (or contains no direction attribute, in which case		listed as sendrecv (or if there is no direction attribute at the
	it is sendrecv by default), the corresponding stream in the answer		media or session level, in which case the stream is sendrecv by
	MAY be marked as sendonly, recvonly, sendrecv, or inactive in the		default), the corresponding stream in the answer MAY be marked as
	answer. If an offered media stream is listed as inactive, it MUST be		sendonly, recvonly, sendrecv, or inactive in the answer. If an
	marked as inactive in the answer.		offered media stream is listed as inactive, it MUST be marked as
			inactive in the answer.
	For streams marked as recvonly in the answer, the m line MUST contain		For streams marked as recvonly in the answer, the "m=" line MUST
	at least one media format the answerer is willing to receive with		contain at least one media format the answerer is willing to receive
	from amongst those listed in the offer. The stream MAY indicate		with from amongst those listed in the offer. The stream MAY indicate
	additional media formats, not listed in the corresponding stream in		additional media formats, not listed in the corresponding stream in
	the offer, that the answerer is willing to receive with. For streams		the offer, that the answerer is willing to receive with. For streams
	marked as sendonly in the answer, the m line MUST contain at least		marked as sendonly in the answer, the "m=" line MUST contain at least
	one media format the answerer is willing to send with from amongst		one media format the answerer is willing to send with from amongst
	those listed in the offer. For streams marked as sendrecv in the		those listed in the offer. For streams marked as sendrecv in the
	answer, the m line MUST contain at least one codec the answerer is		answer, the "m=" line MUST contain at least one codec the answerer is
	willing to both send and receive with, from amongst those listed in		willing to both send and receive with, from amongst those listed in
	the offer. For streams marked as inactive in the answer, the list of		the offer. The stream MAY indicate additional media formats, not
	media formats is constructed based on the offer. If the offer was		listed in the corresponding stream in the offer, that the answerer is
	sendonly, the list is constructed as if the answer were recvonly.		willing to send or receive with (of course, it not be able to send
	Similarly, if the offer was recvonly, the list is constructed as if		with them at this time, since it was not listed in the offer). For
	the answer were sendonly, and if the offer was sendrecv, the list is		streams marked as inactive in the answer, the list of media formats
	constructed as if the answer were sendrecv. If the offer was		is constructed based on the offer. If the offer was sendonly, the
	inactive, the list is constructed as if the offer were actually		list is constructed as if the answer were recvonly. Similarly, if the
	sendrecv and the answer were sendrecv.		offer was recvonly, the list is constructed as if the answer were
			sendonly, and if the offer was sendrecv, the list is constructed as
			if the answer were sendrecv. If the offer was inactive, the list is
			constructed as if the offer were actually sendrecv and the answer
			were sendrecv.
	The connection address and port in the answer indicate the address		The connection address and port in the answer indicate the address
	where the answerer wishes to receive media (in the case of RTP, RTCP		where the answerer wishes to receive media (in the case of RTP, RTCP
	will be received on the port which is one higher). This address and		will be received on the port which is one higher unless there is an
	port MUST be present even for sendonly streams; in the case of RTP,		explicit indication otherwise). This address and port MUST be present
	the port one higher is still used to receive RTCP.		even for sendonly streams; in the case of RTP, the port one higher is
			still used to receive RTCP.
	In the case of RTP, if a particular codec was referenced with a		In the case of RTP, if a particular codec was referenced with a
	specific payload type number in the offer, that same payload type		specific payload type number in the offer, that same payload type
	number SHOULD be used for that codec in the answer. Even if the same		number SHOULD be used for that codec in the answer. Even if the same
	payload type number is used, the answer MUST contain rtpmap		payload type number is used, the answer MUST contain rtpmap
	attributes to define the payload type mappings for dynamic types, and		attributes to define the payload type mappings for dynamic payload
	SHOULD contain mappings for static payload types. The media formats		types, and SHOULD contain mappings for static payload types. The
	in the m line MUST be listed in order of preference, with the first		media formats in the "m=" line MUST be listed in order of preference,
	format listed being preferred. In this case, preferred means that the		with the first format listed being preferred. In this case, preferred
	offerer SHOULD use the format with the highest preference from the		means that the offerer SHOULD use the format with the highest
	answer.		preference from the answer.
	Although the answerer MAY list the formats in their desired order of		Although the answerer MAY list the formats in their desired order of
	preference, it is RECOMMENDED that unless there is a specific reason,		preference, it is RECOMMENDED that unless there is a specific reason,
	the answer list formats in the same relative order they were present		the answerer list formats in the same relative order they were
	in the offer. In other words, if a stream in the offer lists audio		present in the offer. In other words, if a stream in the offer lists
	codecs 8, 22 and 48, in that order, and the answerer only supports		audio codecs 8, 22 and 48, in that order, and the answerer only
	codecs 8 and 48, it is RECOMMENDED that, if the answerer has no		supports codecs 8 and 48, it is RECOMMENDED that, if the answerer has
	reason to change it, the ordering of codecs in the answer be 8, 48,		no reason to change it, the ordering of codecs in the answer be 8,
	and not 48, 8. This helps assure that the same codec is used in both		48, and not 48, 8. This helps assure that the same codec is used in
	directions.		both directions.
	The interpretation of fmtp parameters in an offer depends on the		The interpretation of fmtp parameters in an offer depends on the
	parameters. In many cases, those parameters describe specific		parameters. In many cases, those parameters describe specific
	configurations of the media format, and should therefore be processed		configurations of the media format, and should therefore be processed
	as the media format value itself would be. This means that the same		as the media format value itself would be. This means that the same
	fmtp parameters with the same values MUST be present in the answer if		fmtp parameters with the same values MUST be present in the answer if
	the media format they describe is present in the answer. Other fmtp		the media format they describe is present in the answer. Other fmtp
	parameters are more like parameters, for which is is perfectly		parameters are more like parameters, for which it is perfectly
	acceptable for each agent to use different values. In that case, the		acceptable for each agent to use different values. In that case, the
	answer MAY contain fmtp parameters, and those MAY have the same		answer MAY contain fmtp parameters, and those MAY have the same
	values as those in the offer, or MAY be different.		values as those in the offer, or they MAY be different. SDP
			extensions that define new parameters SHOULD specify the proper
			interpretation in offer/answer.
	The answerer MAY include a ptime attribute for any media stream; this		The answerer MAY include a non-zero ptime attribute for any media
	indicates the packetization interval that the answerer would like to		stream; this indicates the packetization interval that the answerer
	receive. There is no requirement that the packetization interval be		would like to receive. There is no requirement that the packetization
	the same in each direction for a particular stream.		interval be the same in each direction for a particular stream.
	The answerer MAY include a bandwidth attribute for any media stream;		The answerer MAY include a bandwidth attribute for any media stream;
	this indicates the banwdith that the answerer would like the offerer		this indicates the banwdith that the answerer would like the offerer
	to use when sending media. The value of zero is allowed, interpreted		to use when sending media. The value of zero is allowed, interpreted
	as described in Section 5.		as described in Section 5.
	If the answerer has no media formats in common for a particular		If the answerer has no media formats in common for a particular
	offered stream, the answerer MUST reject that media stream by setting		offered stream, the answerer MUST reject that media stream by setting
	the port to zero.		the port to zero.
	If there are no media formats in common for all streams, the entire		If there are no media formats in common for all streams, the entire
	offered session is rejected.		offered session is rejected.
	Once the answerer has sent the answer, it MUST be prepared to receive		Once the answerer has sent the answer, it MUST be prepared to receive
	media for any recvonly streams described by that answer. It MUST be		media for any recvonly streams described by that answer. It MUST be
	prepared to send and receive media for any sendrecv streams in the		prepared to send and receive media for any sendrecv streams in the
	answer, and MAY send media immediately. It MUST be prepared to		answer, and it MAY send media immediately. The answerer MUST be
	receive media for recvonly or sendrecv streams using any media		prepared to receive media for recvonly or sendrecv streams using any
	formats listed for those streams in the answer, and MAY send media		media formats listed for those streams in the answer, and it MAY send
	immediately. When sending media, it SHOULD use a packetization		media immediately. When sending media, it SHOULD use a packetization
	interval equal to the valueof the ptime attribute in the offer, if		interval equal to the valueof the ptime attribute in the offer, if
	any was present. It SHOULD send media using a banwdith no higher than		any was present. It SHOULD send media using a bandwidth no higher
	the value of the bandwidth attribute in the offer, if any was		than the value of the bandwidth attribute in the offer, if any was
	present. The answerer SHOULD send using the most preferred codec in		present. The answerer SHOULD send using the most preferred media
	the offer supported by the answerer.		format in the offer that is also listed in the answer. In the case of
			RTP, it MUST use the payload type numbers from the offer, even if
			they differ from those in the answer.
	6.2 Multicast Streams		6.2 Multicast Streams
	Unlike unicast, where there is a two-sided view of the stream, there		Unlike unicast, where there is a two-sided view of the stream, there
	is only a single view of the stream for multicast. As such,		is only a single view of the stream for multicast. As such,
	generating an answer to a multicast offer generally involves		generating an answer to a multicast offer generally involves
	modifying a limited set of aspects of the stream.		modifying a limited set of aspects of the stream.
	If a multicast stream is accepted, the address and port information		If a multicast stream is accepted, the address and port information
	in the answer MUST match that of the offer. Similarly, the		in the answer MUST match that of the offer. Similarly, the
	directionality information in the answer (sendonly, recvonly, or		directionality information in the answer (sendonly, recvonly, or
	sendrecv) MUST equal that of the offer.		sendrecv) MUST equal that of the offer. This is because all
			participants in a multicast session need to have equivalent views of
			the parameters of the session, and underlying assumption of the
			multicast bias of RFC 2327.
	The set of media formats in the answer MUST be equal to or be a		The set of media formats in the answer MUST be equal to or be a
	subset of those in the offer. Removing a format is a way for the		subset of those in the offer. Removing a format is a way for the
	answerer to indicate that the format is not supported.		answerer to indicate that the format is not supported.
	The ptime and bandwidth attributes in the answer MUST equal the ones		The ptime and bandwidth attributes in the answer MUST equal the ones
	in the offer, if present. If not present, one MAY be added to the		in the offer, if present. If not present, a non-zero ptime MAY be
	answer.		added to the answer.
	7 Offerer Processing of the Answer		7 Offerer Processing of the Answer
	When the offerer receives the answerer, it MAY send media on that		When the offerer receives the answer, it MAY send media on the
	stream (assuming it is listed as sendrecv or recvonly in the answer).		accepted stream(s) (assuming it is listed as sendrecv or recvonly in
	It SHOULD use the first media format listed in the answer when it		the answer). It MUST send using a media format listed in the answer,
			and it SHOULD use the first media format listed in the answer when it
	does send.		does send.
	The reason this is a SHOULD, and not a MUST, is because		The reason this is a SHOULD, and not a MUST, is because
	there will oftentimes be a need to change codecs on the		there will oftentimes be a need to change codecs on the
	fly. For example, during silence periods, an agent might		fly. For example, during silence periods, an agent might
	like to switch to a comfort noise codec. Or, if the user		like to switch to a comfort noise codec. Or, if the user
	presses a number on the keypad, the agent might like to		presses a number on the keypad, the agent might like to
	send that using RFC 2833 [9]. Congestion control might		send that using RFC 2833 [9]. Congestion control might
	necessitate changing to a lower rate codec based on		necessitate changing to a lower rate codec based on
	feedback.		feedback.
	The offerer SHOULD send media according to the value of any ptime and		The offerer SHOULD send media according to the value of any ptime and
	bandwidth attribute in the answer.		bandwidth attribute in the answer.
			The offerer MAY immediately cease listening for media formats that
			were listed in the initial offer, but not present in the answer.
	8 Modifying the session		8 Modifying the session
	At any point during the session, either participant MAY issue a new		At any point during the session, either participant MAY issue a new
	offer to modify characteristics of the session. It is fundamental to		offer to modify characteristics of the session. It is fundamental to
	the operation of the offer/answer model that the exact same		the operation of the offer/answer model that the exact same
	offer/answer procedure defined above is used for modifying parameters		offer/answer procedure defined above is used for modifying parameters
	of an existing session.		of an existing session.
	The offer MAY be identical to the last SDP provided to the other		The offer MAY be identical to the last SDP provided to the other
	party (which may have been provided in an offer or an answer), or it		party (which may have been provided in an offer or an answer), or it
	MAY be different. We refer to the last SDP provided as the "previous		MAY be different. We refer to the last SDP provided as the "previous
	SDP". If the offer is the same, the answer MAY be the same as the		SDP". If the offer is the same, the answer MAY be the same as the
	previous SDP from the answerer, or it MAY be different. If the		previous SDP from the answerer, or it MAY be different. If the
	offered SDP is different from the previous SDP, some constraints are		offered SDP is different from the previous SDP, some constraints are
	placed on its construction, discussed below.		placed on its construction, discussed below.
	Nearly all aspects of the session can be modified. New streams can be		Nearly all aspects of the session can be modified. New streams can be
	added, existing streams can be deleted, and parameters of existing		added, existing streams can be deleted, and parameters of existing
	streams can change. When issuing an offer that modifies the session,		streams can change. When issuing an offer that modifies the session,
	the o line of the new SDP MUST be identical to that in the previous		the "o=" line of the new SDP MUST be identical to that in the
	SDP, except that the version in the origin field MUST increment from		previous SDP, except that the version in the origin field MUST
	the previous SDP by one. If the version in the origin line does not		increment from the previous SDP by one. If the version in the origin
	increment, the SDP MUST be identical to the SDP with that version		line does not increment, the SDP MUST be identical to the SDP with
	number. The answerer MUST be prepared to receive an offer that		that version number. The answerer MUST be prepared to receive an
	contains SDP with a version that has not changed; this is effectively		offer that contains SDP with a version that has not changed; this is
	a no-op. However, the answerer MUST generate a valid answer (which		effectively a no-op. However, the answerer MUST generate a valid
	MAY be the same as the previous SDP from the answerer, or MAY be		answer (which MAY be the same as the previous SDP from the answerer,
	different), according to the procedures defined in Section 6.		or MAY be different), according to the procedures defined in Section
			6.
	If an SDP is offered which is different from the previous SDP, the		If an SDP is offered, which is different from the previous SDP, the
	new SDP MUST have a matching media section for each media section in		new SDP MUST have a matching media stream for each media stream in
	the previous SDP. In other words, if the previous SDP had N media		the previous SDP. In other words, if the previous SDP had N "m="
	lines, the new SDP MUST have at least N media lines. The ith media		lines, the new SDP MUST have at least N "m=" lines. The i-th media
	stream in the previous SDP, counting from the top, matches the ith		stream in the previous SDP, counting from the top, matches the i-th
	media stream in the new SDP, counting from the top. This matching is		media stream in the new SDP, counting from the top. This matching is
	necessary in order for the answerer to determine which stream in the		necessary in order for the answerer to determine which stream in the
	new SDP corresponds to a stream in the previous SDP. Because of these		new SDP corresponds to a stream in the previous SDP. Because of these
	requirements, the number of m lines in a stream never decreases, but		requirements, the number of "m=" lines in a stream never decreases,
	only increases. Deleted media streams from a previous SDP MUST NOT be		but either stays the same or increases. Deleted media streams from a
	removed from a new SDP.		previous SDP MUST NOT be removed in a new SDP; however, attributes
			for these streams need not be present.
	8.1 Adding a media stream		8.1 Adding a Media Stream
	New media streams are created by new additional media descriptions		New media streams are created by new additional media descriptions
	below the existing ones, or by reusing the "slot" used by an old		below the existing ones, or by reusing the "slot" used by an old
	media stream which had been disabled by setting its port to zero. New		media stream which had been disabled by setting its port to zero. New
	media descriptions MUST appear below any existing media sections. The		media descriptions MUST appear below any existing media sections. The
	rules for formatting this media section are identical to those		rules for formatting these media descriptions are identical to those
	described in Section 5.		described in Section 5.
	When the answerer receives an SDP with more media descriptions than		When the answerer receives an SDP with more media descriptions than
	the previous SDP from the offerer, or it receives an SDP with a media		the previous SDP from the offerer, or it receives an SDP with a media
	stream in a slot where the port was previously zero, the answerer		stream in a slot where the port was previously zero, the answerer
	knows that new media streams are being added. These can be rejected		knows that new media streams are being added. These can be rejected
	or accepted by placing a matching media description in the answer.		or accepted by placing a matching media description in the answer.
	The procedures for constructing the new media description in the		The procedures for constructing the new media description in the
	answer are described in Section 6.		answer are described in Section 6.
	8.2 Removing a media stream		8.2 Removing a Media Stream
	Existing media streams are removed by creating a new SDP with the		Existing media streams are removed by creating a new SDP with the
	port number for that stream set to zero. Otherwise, the media		port number for that stream set to zero. The stream description MAY
	description SHOULD be formatted identically to the corresponding		omit all attributes present previously, and MAY list just a single
	stream in the previous SDP.		media format.
	A stream that is offered with a port of zero MUST be marked with port		A stream that is offered with a port of zero MUST be marked with port
	zero in the answer. Otherwise, the media description for the removed		zero in the answer. Like the offer, the answer MAY omit all
	stream SHOULD be formatted identically to the corresponding stream in		attributes present previously, and MAY list just a single media
	the previous SDP.		format from amongst those in the offer.
	Removal of a media stream implies that media is no longer sent for		Removal of a media stream implies that media is no longer sent for
	that stream. Any resources associated with it can be released. The		that stream, and any media that is received is discarded. In the case
	user interface might indicate that the stream has terminated, by		of RTP, RTCP transmission also ceases, as does processing of any
	closing the associated window on a PC, for example.		received RTCP packets. Any resources associated with it can be
			released. The user interface might indicate that the stream has
			terminated, by closing the associated window on a PC, for example.
	8.3 Modifying a Media Stream		8.3 Modifying a Media Stream
	Nearly all characteristics of a media stream can be modified.		Nearly all characteristics of a media stream can be modified.
	8.3.1 Modifying Address, Port or Transport		8.3.1 Modifying Address, Port or Transport
	The port number for a stream MAY be changed. To do this, the offerer		The port number for a stream MAY be changed. To do this, the offerer
	creates a new media description, with the port number in the m line		creates a new media description, with the port number in the m line
	different from the corresponding stream in the previous SDP. If only		different from the corresponding stream in the previous SDP. If only
	the port number is to be changed, the rest of the media stream		the port number is to be changed, the rest of the media stream
	description SHOULD remain unchanged. The offerer MUST be prepared to		description SHOULD remain unchanged. The offerer MUST be prepared to
	receive media on both the old and new ports as soon as the offer is		receive media on both the old and new ports as soon as the offer is
	sent. The offerer MUST NOT cease listening for media on the old port		sent. The offerer SHOULD NOT cease listening for media on the old
	until the answer is received and media arrives on the new port.		port until the answer is received and media arrives on the new port.
	Received, in this case, means that the media is passed to an audio		Doing so could result in loss of media during the transition.
	sink. This means that if there is an audio playout buffer, the agent		Received, in this case, means that the media is passed to a media
	would continue to listen on the old port until the media on the new		sink. This means that if there is a playout buffer, the agent would
	port reached the top of the playout buffer. At that time, it MAY		continue to listen on the old port until the media on the new port
	cease listening for media on the old port.		reached the top of the playout buffer. At that time, it MAY cease
			listening for media on the old port.
	The corresponding media stream in the answer MAY be the same as the		The corresponding media stream in the answer MAY be the same as the
	stream in the previous SDP from the answerer, or MAY be different.		stream in the previous SDP from the answerer, or it MAY be different.
	If the updated stream is accepted by the answerer, the answerer		If the updated stream is accepted by the answerer, the answerer
	SHOULD begin sending traffic for that stream to the new port		SHOULD begin sending traffic for that stream to the new port
	immediately. If the answerer changes the port from the previous SDP,		immediately. If the answerer changes the port from the previous SDP,
	it MUST be prepared to receive media on both the old and new ports as		it MUST be prepared to receive media on both the old and new ports as
	soon as the answer is sent. The answerer MUST NOT cease listening for		soon as the answer is sent. The answerer MUST NOT cease listening for
	media on the old port until media arrives on the new port. At that		media on the old port until media arrives on the new port. At that
	time, it MAY cease listening for media on the old port.		time, it MAY cease listening for media on the old port. The same is
			true for an offerer that sends an updated offer with a new port; it
			MUST NOT cease listening for media on the old port until media
			arrives on the new port.
	Of course, if the offered stream is rejected, the offer can cease		Of course, if the offered stream is rejected, the offerer can cease
	being prepared to receive using the new port as soon as the rejection		being prepared to receive using the new port as soon as the rejection
	is received.		is received.
	To change the IP address where media is sent to, the same procedure		To change the IP address where media is sent to, the same procedure
	is followed for changing the port number. The only difference is that		is followed for changing the port number. The only difference is that
	the connection line is updated, not the port number.		the connection line is updated, not the port number.
	The transport for a stream MAY be changed. The process for doing this		The transport for a stream MAY be changed. The process for doing this
	is identical to changing the port, excepting the transport is		is identical to changing the port, except the transport is updated,
	updated, not the port.		not the port.
	8.3.2 Changing the Set of Media Formats		8.3.2 Changing the Set of Media Formats
	The list of media formats used in the session MAY be changed. To do		The list of media formats used in the session MAY be changed. To do
	this, the offerer creates a new media description, with the list of		this, the offerer creates a new media description, with the list of
	media formats in the m line different from the corresponding stream		media formats in the "m=" line different from the corresponding media
	in the previous SDP. This list MAY include new formats, and MAY		stream in the previous SDP. This list MAY include new formats, and
	remove formats present from the previous SDP. However, in the case of		MAY remove formats present from the previous SDP. However, in the
	RTP, the mapping from a particular dynamic payload type number to a		case of RTP, the mapping from a particular dynamic payload type
	particular codec MUST NOT change for the duration of a session. For		number to a particular codec within that media stream MUST NOT change
	example, if A generates an offer with G.711 assigned to dynamic		for the duration of a session. For example, if A generates an offer
	payload type number 46, payload type number 46 MUST refer to G.711		with G.711 assigned to dynamic payload type number 46, payload type
	from that point forward in any offers or answers for that session.		number 46 MUST refer to G.711 from that point forward in any offers
	However, it is acceptable for multiple payload type numbers to be		or answers for that media stream within the session. However, it is
	mapped to the same codec, so that an updated offer could also use		acceptable for multiple payload type numbers to be mapped to the same
	payload type number 72 for G.711. The mappings need to remain fixed		codec, so that an updated offer could also use payload type number 72
	for the duration of the session because of the loose synchronization		for G.711.
	between signaling exchanges of SDP and the media stream.
			The mappings need to remain fixed for the duration of the
			session because of the loose synchronization between
			signaling exchanges of SDP and the media stream.
	The corresponding media stream in the answer is formulated as		The corresponding media stream in the answer is formulated as
	described in Section 6, and may result in a change in media formats		described in Section 6, and may result in a change in media formats
	as well. Similarly, as described in Section 6, as soon as it sends		as well. Similarly, as described in Section 6, as soon as it sends
	its answer, the answerer MAY begin sending media using any new codecs		its answer, the answerer MAY begin sending media using any new codecs
	in the offer (assuming the stream allows for sending), and MUST NOT		in the offer (assuming the stream allows for sending), and MUST NOT
	send using any formats that are not in the offer, even if they were		send using any formats that are not in the offer, even if they were
	present in a previous SDP from the peer. Similarly, when the offerer		present in a previous SDP from the peer. Similarly, when the offerer
	receives the answer, it MAY begin sending media using any new codecs		receives the answer, it MAY begin sending media using any new codecs
	in the answer (assuming the stream allows for sending), and MUST NOT		in the answer (assuming the stream allows for sending), and MUST NOT
	skipping to change at page 16, line 5		skipping to change at page 17, line 45
	answerer SHOULD begin sending with the new media type and codecs as		answerer SHOULD begin sending with the new media type and codecs as
	soon as it receives the offer.		soon as it receives the offer.
	8.3.4 Changing Attributes		8.3.4 Changing Attributes
	Any other attributes in a media description MAY be updated in an		Any other attributes in a media description MAY be updated in an
	offer or answer. Generally, an agent MUST send media (if the		offer or answer. Generally, an agent MUST send media (if the
	directionality of the stream allows) using the new parameters once		directionality of the stream allows) using the new parameters once
	the SDP with the change is received.		the SDP with the change is received.
	8.4 Putting a media stream on hold		8.4 Putting a Unicast Media Stream on Hold
	If a party in a call wants to put the other party "on hold", i.e.,		If a party in a call wants to put the other party "on hold", i.e.,
	request that it temporarily stops sending one or more media streams,		request that it temporarily stops sending one or more unicast media
	a party offers the other an updated SDP.		streams, a party offers the other an updated SDP.
	If the stream to be placed on hold was previously a sendrecv media		If the stream to be placed on hold was previously a sendrecv media
	stream, it is placed on hold by marking it as sendonly. If the stream		stream, it is placed on hold by marking it as sendonly. If the stream
	to be placed on hold was previously a recvonly media stream, it is		to be placed on hold was previously a recvonly media stream, it is
	placed on hold by marking it inactive.		placed on hold by marking it inactive.
	This means that a stream is placed "on hold" separately in each		This means that a stream is placed "on hold" separately in each
	direction. Each stream is placed "on hold" independently. The		direction. Each stream is placed "on hold" independently. The
	recipient of an offer for a stream on-hold SHOULD NOT automatically		recipient of an offer for a stream on-hold SHOULD NOT automatically
	return an answer with the corresponding stream on hold. An SDP with		return an answer with the corresponding stream on hold. An SDP with
	all streams "on hold" is referred to as held SDP		all streams "on hold" is referred to as held SDP
	Certain third party call control scenarios do not work when		Certain third party call control scenarios do not work when
	a UA responds to held SDP with held SDP.		an answerer responds to held SDP with held SDP.
	Typically, when a user "presses" hold, the UA will generate an offer		Typically, when a user "presses" hold, the agent will generate an
	with all streams in the SDP indicating a direction of sendonly, and		offer with all streams in the SDP indicating a direction of sendonly,
	it will also locally mute, so that no media is sent to the far end,		and it will also locally mute, so that no media is sent to the far
	and no media is played out.		end, and no media is played out.
	RFC 2543 specified that placing a user on hold was accomplished by		RFC 2543 [10] specified that placing a user on hold was accomplished
	setting the connection address to 0.0.0.0. This has been deprecated,		by setting the connection address to 0.0.0.0. Its usage for putting a
	since it doesn't allow for RTCP to be used with held streams, and		call on hold is no longer recommended, since it doesn't allow for
	breaks with connection oriented media. However, a UA MUST be capable		RTCP to be used with held streams, doesn't work with IPv6, and breaks
	of receiving SDP with a connection address of 0.0.0.0, in which case		with connection oriented media. However, it can be useful in an
	it means that neither RTP nor RTCP should be sent to the peer.		initial offer when the offerer knows it wants to use a particular set
			of media streams and formats, but doesn't know the addresses and
			ports at the time of the offer. An agent MUST be capable of receiving
			SDP with a connection address of 0.0.0.0, in which case it means that
			neither RTP nor RTCP should be sent to the peer.
	9 Indicating Capabilities		9 Indicating Capabilities
	Before an agent sends an offer, it is helpful to know if the media		Before an agent sends an offer, it is helpful to know if the media
	formats in that offer would be acceptable to the answerer. Certain		formats in that offer would be acceptable to the answerer. Certain
	protocols, like SIP, provide a means to query for such capabilities.		protocols, like SIP, provide a means to query for such capabilities.
	SDP can be used in responses to such queries to indicate		SDP can be used in responses to such queries to indicate
	capabilities. This section describes how such an SDP message is		capabilities. This section describes how such an SDP message is
	formatted. The ability of baseline SDP to indicate capabilities is		formatted. Since SDP has no way to indicate that the message is for
	very limited. It cannot express allowed parameter ranges or values,		the purpose of capability indication, this is determined from the
	and can not be done in parallel with an offer/answer itself.		context of the higher layer protocol. The ability of baseline SDP to
	Extensions might address such limitations in the future.		indicate capabilities is very limited. It cannot express allowed
			parameter ranges or values, and can not be done in parallel with an
			offer/answer itself. Extensions might address such limitations in the
			future.
	An SDP constructed to indicate media capabilities is structured as		An SDP constructed to indicate media capabilities is structured as
	follows. It MUST be a valid SDP, except that it MAY omit both e and p		follows. It MUST be a valid SDP, except that it MAY omit both "e="
	lines. The t line MUST be equal to "0 0". For each media type		and "p=" lines. The "t=" line MUST be equal to "0 0". For each media
	supported by the agent, there must be a corresponding media		type supported by the agent, there MUST be a corresponding media
	description of that type. The port and connection address have no		description of that type. The session ID in the origin field MUST be
	meaning, and their values are arbitrary. The transport component of		unique for each SDP constructed to indicate media capabilities. The
	the m line indicates the preferred transport for that media type. For		port MUST be set to zero, but the connection address is arbitrary.
	each media format of that type supported by the agent, there SHOULD		The usage of port zero makes sure that an SDP formatted for
	be a media format listed in the m line. In the case of RTP, if		capabilities does not cause media streams to be established if it is
	dynamic payload types are used, an rtpmap attribute MUST be present		interpreted as an offer or answer.
	to bind the type to a specific format. There is no way to indicate
	constraints, such as how many simultaneous streams can be supported		The transport component of the "m=" line indicates the transport for
	for a particular codec, and so on.		that media type. For each media format of that type supported by the
			agent, there SHOULD be a media format listed in the "m=" line. In the
			case of RTP, if dynamic payload types are used, an rtpmap attribute
			MUST be present to bind the type to a specific format. There is no
			way to indicate constraints, such as how many simultaneous streams
			can be supported for a particular codec, and so on.
	v=0		v=0
	o=carol 28908764872 28908764872 IN IP4 100.3.6.6		o=carol 28908764872 28908764872 IN IP4 100.3.6.6
	s=-		s=-
	t=0 0		t=0 0
	c=IN IP4 192.0.2.4		c=IN IP4 192.0.2.4
	m=audio 0 RTP/AVP 0 1 3		m=audio 0 RTP/AVP 0 1 3
	a=rtpmap:0 PCMU/8000		a=rtpmap:0 PCMU/8000
	a=rtpmap:1 1016/8000		a=rtpmap:1 1016/8000
	a=rtpmap:3 GSM/8000		a=rtpmap:3 GSM/8000
	skipping to change at page 18, line 15		skipping to change at page 20, line 18
	c=IN IP4 host.anywhere.com		c=IN IP4 host.anywhere.com
	t=0 0		t=0 0
	m=audio 49170 RTP/AVP 0		m=audio 49170 RTP/AVP 0
	a=rtpmap:0 PCMU/8000		a=rtpmap:0 PCMU/8000
	m=video 51372 RTP/AVP 31		m=video 51372 RTP/AVP 31
	a=rtpmap:31 H261/90000		a=rtpmap:31 H261/90000
	m=video 53000 RTP/AVP 32		m=video 53000 RTP/AVP 32
	a=rtpmap:32 MPV/90000		a=rtpmap:32 MPV/90000
	The callee, Bob, does not want to receive or send the first video		The callee, Bob, does not want to receive or send the first video
	stream, so it returns the media description below as the answer:		stream, so he returns the SDP below as the answer:
	v=0		v=0
	o=bob 2890844730 2890844730 IN IP4 host.example.com		o=bob 2890844730 2890844730 IN IP4 host.example.com
	s=		s=
	c=IN IP4 host.example.com		c=IN IP4 host.example.com
	t=0 0		t=0 0
	m=audio 47920 RTP/AVP 0		m=audio 49920 RTP/AVP 0
	a=rtpmap:0 PCMU/8000		a=rtpmap:0 PCMU/8000
	m=video 0 RTP/AVP 31		m=video 0 RTP/AVP 31
	m=video 53000 RTP/AVP 32		m=video 53000 RTP/AVP 32
	a=rtpmap:32 MPV/90000		a=rtpmap:32 MPV/90000
	At some point later, Bob decides to change the port where he will		At some point later, Bob decides to change the port where he will
	receive the audio stream (from 47920 to 6400), and at the same time,		receive the audio stream (from 49920 to 65422), and at the same time,
	add an additional audio stream as receive only, using the RTP payload		add an additional audio stream as receive only, using the RTP payload
	format for events [9]. Bob offers the following SDP in the offer:		format for events [9]. Bob offers the following SDP in the offer:
	v=0		v=0
	o=bob 2890844730 2890844731 IN IP4 host.example.com		o=bob 2890844730 2890844731 IN IP4 host.example.com
	s=		s=
	c=IN IP4 host.example.com		c=IN IP4 host.example.com
	t=0 0		t=0 0
	m=audio 6400 RTP/AVP 0		m=audio 65422 RTP/AVP 0
	a=rtpmap:0 PCMU/8000		a=rtpmap:0 PCMU/8000
	m=video 0 RTP/AVP 31		m=video 0 RTP/AVP 31
	m=video 53000 RTP/AVP 32		m=video 53000 RTP/AVP 32
	a=rtpmap:32 MPV/90000		a=rtpmap:32 MPV/90000
	m=audio 8864 RTP/AVP 110		m=audio 51434 RTP/AVP 110
	a=rtpmap:110 telephone-events		a=rtpmap:110 telephone-events/8000
	a=recvonly		a=recvonly
	Alice accepts the additional media stream, and so generates the		Alice accepts the additional media stream, and so generates the
	following answer:		following answer:
	v=0		v=0
	o=alice 2890844526 2890844527 IN IP4 host.anywhere.com		o=alice 2890844526 2890844527 IN IP4 host.anywhere.com
	s=		s=
	c=IN IP4 host.anywhere.com		c=IN IP4 host.anywhere.com
	t=0 0		t=0 0
	m=audio 49170 RTP/AVP 0		m=audio 49170 RTP/AVP 0
	a=rtpmap:0 PCMU/8000		a=rtpmap:0 PCMU/8000
	m=video 51372 RTP/AVP 31		m=video 51372 RTP/AVP 31
	a=rtpmap:31 H261/90000		a=rtpmap:31 H261/90000
	m=video 53000 RTP/AVP 32		m=video 53000 RTP/AVP 32
	a=rtpmap:32 MPV/90000		a=rtpmap:32 MPV/90000
	m=audio 4520 RTP/AVP 110		m=audio 53122 RTP/AVP 110
	a=rtpmap:110 telephone-events		a=rtpmap:110 telephone-events/8000
	a=sendonly		a=sendonly
	10.2 One of N Codec Selection		10.2 One of N Codec Selection
	A common occurence in embedded phones is that the DSP used for		A common occurence in embedded phones is that the Digital Signal
	compression can support multiple codecs at a time, but once that		Processor (DSP) used for compression can support multiple codecs at a
	codec is selected, it cannot be readily changed on the fly. This		time, but once that codec is selected, it cannot be readily changed
	example shows how a session can be set up using an initial		on the fly. This example shows how a session can be set up using an
	offer/answer exchange, followed immediately by a second one to lock		initial offer/answer exchange, followed immediately by a second one
	down the set of codecs.		to lock down the set of codecs.
	The initial offer from Alice to Bob indicates a single audio stream		The initial offer from Alice to Bob indicates a single audio stream
	with the three audio codecs that are available in the DSP. The stream		with the three audio codecs that are available in the DSP. The stream
	is marked as inactive, since media cannot be received until a codec		is marked as inactive, since media cannot be received until a codec
	is locked down:		is locked down:
	v=0		v=0
	o=alice 2890844526 2890844526 IN IP4 host.anywhere.com		o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
	s=		s=
	c=IN IP4 host.anywhere.com		c=IN IP4 host.anywhere.com
	t=0 0		t=0 0
	m=audio 6400 RTP/AVP 0 4 18		m=audio 62986 RTP/AVP 0 4 18
	a=rtpmap:0 PCMU/8000		a=rtpmap:0 PCMU/8000
	a=rtpmap:4 G723/8000		a=rtpmap:4 G723/8000
	a=rtpmap:18 G729/8000		a=rtpmap:18 G729/8000
	a=inactive		a=inactive
	Bob can support PCMU and G.723 simultaneously. So, he sends the		Bob can dynamic switching between PCMU and G.723. So, he sends the
	following answer:		following answer:
	v=0		v=0
	o=bob 2890844730 2890844731 IN IP4 host.example.com		o=bob 2890844730 2890844731 IN IP4 host.example.com
	s=		s=
	c=IN IP4 host.example.com		c=IN IP4 host.example.com
	t=0 0		t=0 0
	m=audio 6400 RTP/AVP 0 4		m=audio 54344 RTP/AVP 0 4
	a=rtpmap:0 PCMU/8000		a=rtpmap:0 PCMU/8000
	a=rtpmap:4 G723/8000		a=rtpmap:4 G723/8000
	a=inactive		a=inactive
	Alice can then select any one of these two codecs. So, she sends an		Alice can then select any one of these two codecs. So, she sends an
	updated offer with a sendrecv stream:		updated offer with a sendrecv stream:
	v=0		v=0
	o=alice 2890844526 2890844527 IN IP4 host.anywhere.com		o=alice 2890844526 2890844527 IN IP4 host.anywhere.com
	s=		s=
	c=IN IP4 host.example.com		c=IN IP4 host.anywhere.com
	t=0 0		t=0 0
	m=audio 6400 RTP/AVP 4		m=audio 62986 RTP/AVP 4
	a=rtpmap:4 G723/8000		a=rtpmap:4 G723/8000
	a=sendrecv		a=sendrecv
	Bob accepts the single codec:		Bob accepts the single codec:
	v=0		v=0
	o=bob 2890844730 2890844732 IN IP4 host.example.com		o=bob 2890844730 2890844732 IN IP4 host.example.com
	s=		s=
	c=IN IP4 host.example.com		c=IN IP4 host.example.com
	t=0 0		t=0 0
	m=audio 6400 RTP/AVP 4		m=audio 54344 RTP/AVP 4
	a=rtpmap:4 G723/8000		a=rtpmap:4 G723/8000
	a=sendrecv		a=sendrecv
	As an alternative to using a=inactive in the first exchange, Alice		As an alternative to using "a=inactive" in the first exchange, Alice
	can list all codecs, and as soon as she receives media from Bob,		can list all codecs, and as soon as she receives media from Bob,
	generate an updated offer locking down the codec to the one just		generate an updated offer locking down the codec to the one just
	recevied.		recevied. There is a potential race condition, however. If both Bob
			and Alice do this (Alice in her offer, Bob in his answer), both may
	11 Changes since draft-rosenberg-mmusic-sdp-offer-answer-00		attempt to issue updated offers at the same time. The protocol which
			carries offers and answers has to provide a means to resolve these
	o Examples had the wrong ordering of c and t lines		glare conditions, so that only one offer will be used.
	o Eliminated repitions of rfc2327 requirements in section 2.
	o Changed e/p line handling, so that the MAY be omitted from an
	SDP used for offer/answer applications. Removed from the
	examples.
	o When modifying the ports/addresses for a media stream, you
	have to listen on the old port until media arrives at the new
	port, AND the answer arrives.
	o Clarified how transitioning of codecs works when an offer
	updates the codec set.
	o Added text defining how the transitioning of codecs/ports
	reverts when the offered stream is rejected.
	o Finished extraction of SIP specific text to make this
	orthogonal to SIP.
	o Generalized the text in 2.1 on sending streams of the same
	media type.
	o Made multicast/unicast treatment at the stream level, rather
	than the SDP level, to handle cases of SDP with mixed unicast
	and multicast streams.
	o Removed text on rfc2833 hack of adding receive only codecs to
	the answer for a sendrecv stream.
	o Added a terminology section.
	o Added discussion of t line usage.
	o Added text on the source/sink/stream mapping policies agreed
	at IETF 52.
	o Added text allowing for reuse of media slots previously set to		11 Security Considerations
	zero.
	o Added text describing the three possible approaches for		There are numerous attacks possible if an attacker can modify offers
	synchronizing changes in media formats.		or answers in transit. Generally, these include diversion of media
			streams (enabling eavesdropping), disabling of calls, and injection
			of unwanted media streams. If a passive listener can construct fake
			offers, and inject those into an exchange, similar attacks are
			possible. Even if an attacker can simply observe offers and answers,
			they can inject media streams into an existing conversation.
	o Allow for the dynamic payload type numbers to change in each		Offer/answer relies an transport within an application signaling
	direction, but its a SHOULD to use the same ones. Explicitly		protocol, such as SIP. It also relies on that protocol for security
	called out the H.323 interop issue.		capabilities. Because of the attacks described above, that protocol
			MUST provide a means for end-to-end authentication and integrity
			protection of offers and answers. It SHOULD offer encryption of
			bodies to prevent eavesdropping. However, media injection attacks can
			alternatively be resolved through authenticated media exchange, and
			therefore the encryption requirement is a SHOULD instead of a MUST.
	o Added capabilities format.		Replay attacks are also problematic. An attacker can replay an old
			offer, perhaps one that had put media on hold, and thus disable media
			streams in a conversation. Therefore, the application protocol MUST
			provide a secure way to sequence offers and answers, and to detect
			and reject old offers or answers.
	o Added example showing 1 of N codec selection.		12 IANA Considerations
	o Clarified that transitions occur not when new media is		There are no IANA considerations with this specification.
	received, but when it is played out.
	o Added protocol operation section.		13 Acknowledgements
	o Added discussion on usage of the bandwidth modifier.		The authors would like to thank Allison Mankin, Rohan Mahy, Joerg
			Ott, and Flemming Andreasen for their detailed comments.
	12 Author's Addresses		14 Author's Addresses
	Jonathan Rosenberg		Jonathan Rosenberg
	dynamicsoft		dynamicsoft
	72 Eagle Rock Avenue		72 Eagle Rock Avenue
	First Floor		First Floor
	East Hanover, NJ 07936		East Hanover, NJ 07936
	email: jdrosen@dynamicsoft.com		email: jdrosen@dynamicsoft.com
	Henning Schulzrinne		Henning Schulzrinne
	Dept. of Computer Science		Dept. of Computer Science
	Columbia University		Columbia University
	1214 Amsterdam Avenue		1214 Amsterdam Avenue
	New York, NY 10027		New York, NY 10027
	USA		USA
	email: schulzrinne@cs.columbia.edu		email: schulzrinne@cs.columbia.edu
	13 Bibliography		15 Normative References
	[1] M. Handley and V. Jacobson, "SDP: session description protocol,"		[1] M. Handley and V. Jacobson, "SDP: session description protocol,"
	Request for Comments 2327, Internet Engineering Task Force, Apr.		Request for Comments 2327, Internet Engineering Task Force, Apr.
	1998.		1998.
	[2] M. Handley, C. Perkins, and E. Whelan, "Session announcement		[2] S. Bradner, "Key words for use in RFCs to indicate requirement
	protocol," Request for Comments 2974, Internet Engineering Task
	Force, Oct. 2000.
	[3] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation
	protocol," Internet Draft, Internet Engineering Task Force, Oct.
	2001. Work in progress.
	[4] S. Bradner, "Key words for use in RFCs to indicate requirement
	levels," Request for Comments 2119, Internet Engineering Task Force,		levels," Request for Comments 2119, Internet Engineering Task Force,
	Mar. 1997.		Mar. 1997.
	[5] H. Schulzrinne, A. Rao, and R. Lanphier, "Real time streaming		[3] R. Kumar and M. Mostafa, "Conventions for the use of the session
	protocol (RTSP)," Request for Comments 2326, Internet Engineering
	Task Force, Apr. 1998.
	[6] R. Kumar and M. Mostafa, "Conventions for the use of the session
	description protocol (SDP) for ATM bearer connections," Request for		description protocol (SDP) for ATM bearer connections," Request for
	Comments 3108, Internet Engineering Task Force, May 2001.		Comments 3108, Internet Engineering Task Force, May 2001.
	[7] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a		[4] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a
	transport protocol for real-time applications," Request for Comments		transport protocol for real-time applications," Request for Comments
	1889, Internet Engineering Task Force, Jan. 1996.		1889, Internet Engineering Task Force, Jan. 1996.
	[8] H. Schulzrinne, "RTP profile for audio and video conferences with		[5] H. Schulzrinne, "RTP profile for audio and video conferences with
	minimal control," Request for Comments 1890, Internet Engineering		minimal control," Request for Comments 1890, Internet Engineering
	Task Force, Jan. 1996.		Task Force, Jan. 1996.
			16 Non-Normative References
			[6] M. Handley, C. Perkins, and E. Whelan, "Session announcement
			protocol," Request for Comments 2974, Internet Engineering Task
			Force, Oct. 2000.
			[7] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation
			protocol," Internet Draft, Internet Engineering Task Force, Oct.
			2001. Work in progress.
			[8] H. Schulzrinne, A. Rao, and R. Lanphier, "Real time streaming
			protocol (RTSP)," Request for Comments 2326, Internet Engineering
			Task Force, Apr. 1998.
	[9] H. Schulzrinne and S. Petrack, "RTP payload for DTMF digits,		[9] H. Schulzrinne and S. Petrack, "RTP payload for DTMF digits,
	telephony tones and telephony signals," Request for Comments 2833,		telephony tones and telephony signals," Request for Comments 2833,
	Internet Engineering Task Force, May 2000.		Internet Engineering Task Force, May 2000.
			[10] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
			session initiation protocol," Request for Comments 2543, Internet
			Engineering Task Force, Mar. 1999.
	Full Copyright Statement		Full Copyright Statement
	Copyright (c) The Internet Society (2002). All Rights Reserved.		Copyright (c) The Internet Society (2002). 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 implementation may be prepared, copied, published		or assist in its implementation 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 are		kind, provided that the above copyright notice and this paragraph are
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/