draft-ietf-mmusic-sdp-new-20.txt		draft-ietf-mmusic-sdp-new-21.txt
	Network Working Group M. Handley		Network Working Group M. Handley
	Internet-Draft UCL		Internet-Draft UCL
	Obsoletes: 2327, 3266 (if V. Jacobson		Obsoletes: 2327, 3266 (if V. Jacobson
	approved) Packet Design		approved) Packet Design
	Expires: March 20, 2005 C. Perkins		Expires: April 25, 2005 C. Perkins
	University of Glasgow		University of Glasgow
	September 19, 2004		October 25, 2004
	SDP: Session Description Protocol		SDP: Session Description Protocol
	draft-ietf-mmusic-sdp-new-20.txt		draft-ietf-mmusic-sdp-new-21.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		This document is an Internet-Draft and is subject to all provisions
	of section 3 of RFC 3667. By submitting this Internet-Draft, each		of section 3 of RFC 3667. By submitting this Internet-Draft, each
	author represents that any applicable patent or other IPR claims of		author represents that any applicable patent or other IPR claims of
	which he or she is aware have been or will be disclosed, and any of		which he or she is aware have been or will be disclosed, and any of
	which he or she become aware will be disclosed, in accordance with		which he or she become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	skipping to change at page 1, line 39		skipping to change at page 1, line 39
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on March 20, 2005.		This Internet-Draft will expire on April 25, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004).		Copyright (C) The Internet Society (2004).
	Abstract		Abstract
	This memo defines the Session Description Protocol (SDP). SDP is		This memo defines the Session Description Protocol (SDP). SDP is
	intended for describing multimedia sessions for the purposes of		intended for describing multimedia sessions for the purposes of
	session announcement, session invitation, and other forms of		session announcement, session invitation, and other forms of
	skipping to change at page 2, line 36		skipping to change at page 2, line 36
	5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 12		5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 12
	5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . 12		5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . 12
	5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . 13		5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . 13
	5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 15		5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 15
	5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 16		5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 16
	5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . 17		5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . 17
	5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . 18		5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . 18
	5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 19		5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 19
	5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . 20		5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . 20
	5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . . 21		5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . . 21
	6. Suggested Attributes . . . . . . . . . . . . . . . . . . . . 23		6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 24
	7. Security Considerations . . . . . . . . . . . . . . . . . . 30		7. Security Considerations . . . . . . . . . . . . . . . . . . 30
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32
	8.1 The "application/sdp" media type . . . . . . . . . . . . . 31		8.1 The "application/sdp" media type . . . . . . . . . . . . . 32
	8.2 Registration of Parameters . . . . . . . . . . . . . . . . 32		8.2 Registration of Parameters . . . . . . . . . . . . . . . . 33
	8.3 Encryption Key Access Methods . . . . . . . . . . . . . . 36		8.3 Encryption Key Access Methods . . . . . . . . . . . . . . 37
	A. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 37		A. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 37
	B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 42		B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 42
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 42		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
	9.1 Normative References . . . . . . . . . . . . . . . . . . . . 42		9.1 Normative References . . . . . . . . . . . . . . . . . . . . 42
	9.2 Informative References . . . . . . . . . . . . . . . . . . . 42		9.2 Informative References . . . . . . . . . . . . . . . . . . . 43
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 44		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 44
	Intellectual Property and Copyright Statements . . . . . . . 45		Intellectual Property and Copyright Statements . . . . . . . 46
	1. Introduction		1. Introduction
	When initiating multimedia teleconferences, voice-over-IP calls,		When initiating multimedia teleconferences, voice-over-IP calls,
	streaming video, or other sessions, there is a requirement to convey		streaming video, or other sessions, there is a requirement to convey
	media details, transport addresses, and other session description		media details, transport addresses, and other session description
	metadata to the participants.		metadata to the participants.
	SDP provides a standard representation for such information,		SDP provides a standard representation for such information,
	irrespective of how that information is transported. SDP is purely a		irrespective of how that information is transported. SDP is purely a
	skipping to change at page 6, line 26		skipping to change at page 6, line 26
	o The transport port for media		o The transport port for media
	This address and port are the destination address and destination		This address and port are the destination address and destination
	port of the multicast stream, whether being sent, received, or both.		port of the multicast stream, whether being sent, received, or both.
	For unicast IP sessions, the following are conveyed:		For unicast IP sessions, the following are conveyed:
	o The remote address for media		o The remote address for media
	o The transport port for media		o The remote transport port for media
	The semantics of this address and port depend on the media and		The semantics of this address and port depend on the media and
	transport protocol defined. By default, this SHOULD be the remote		transport protocol defined. By default, this SHOULD be the remote
	address and remote port to which data is sent. Some media types MAY		address and remote port to which data is sent. Some media types MAY
	redefine this behaviour, but this is NOT RECOMMENDED.		redefine this behaviour, but this is NOT RECOMMENDED.
	4.2 Timing Information		4.2 Timing Information
	Sessions may either be bounded or unbounded in time. Whether or not		Sessions may either be bounded or unbounded in time. Whether or not
	they are bounded, they may be only active at specific times. SDP can		they are bounded, they may be only active at specific times. SDP can
	skipping to change at page 9, line 7		skipping to change at page 9, line 7
	description. In general, session-level values are the default for		description. In general, session-level values are the default for
	all media unless overridden by an equivalent media-level value.		all media unless overridden by an equivalent media-level value.
	Some lines in each description are REQUIRED and some are OPTIONAL but		Some lines in each description are REQUIRED and some are OPTIONAL but
	all MUST appear in exactly the order given here (the fixed order		all MUST appear in exactly the order given here (the fixed order
	greatly enhances error detection and allows for a simple parser).		greatly enhances error detection and allows for a simple parser).
	OPTIONAL items are marked with a "*".		OPTIONAL items are marked with a "*".
	Session description		Session description
	v= (protocol version)		v= (protocol version)
	o= (owner/creator and session identifier).		o= (owner/creator and session identifier)
	s= (session name)		s= (session name)
	i=* (session information)		i=* (session information)
	u=* (URI of description)		u=* (URI of description)
	e=* (email address)		e=* (email address)
	p=* (phone number)		p=* (phone number)
	c=* (connection information - not required if included in		c=* (connection information - not required if included in
	all media)		all media)
	b=* (zero or more bandwidth information lines)		b=* (zero or more bandwidth information lines)
	One or more time descriptions ("t=" and "r=" lines, see below)		One or more time descriptions ("t=" and "r=" lines, see below)
	z=* (time zone adjustments)		z=* (time zone adjustments)
	k=* (encryption key)		k=* (encryption key)
	a=* (zero or more session attribute lines)		a=* (zero or more session attribute lines)
	Zero or more media descriptions		Zero or more media descriptions
	Time description		Time description
	t= (time the session is active)		t= (time the session is active)
	r=* (zero or more repeat times)		r=* (zero or more repeat times)
	Media description		Media description, if present
	m= (media name and transport address)		m= (media name and transport address)
	i=* (media title)		i=* (media title)
	c=* (connection information - optional if included at		c=* (connection information - optional if included at
	session-level)		session-level)
	b=* (zero or more bandwidth information lines)		b=* (zero or more bandwidth information lines)
	k=* (encryption key)		k=* (encryption key)
	a=* (zero or more media attribute lines)		a=* (zero or more media attribute lines)
	The set of type letters is deliberately small and not intended to be		The set of type letters is deliberately small and not intended to be
	extensible -- an SDP parser MUST completely ignore any session		extensible -- an SDP parser MUST completely ignore any session
	skipping to change at page 10, line 19		skipping to change at page 10, line 19
	v=0		v=0
	o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5		o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
	s=SDP Seminar		s=SDP Seminar
	i=A Seminar on the session description protocol		i=A Seminar on the session description protocol
	u=http://www.example.com/seminars/sdp.pdf		u=http://www.example.com/seminars/sdp.pdf
	e=j.doe@example.com (Jane Doe)		e=j.doe@example.com (Jane Doe)
	c=IN IP4 224.2.17.12/127		c=IN IP4 224.2.17.12/127
	t=2873397496 2873404696		t=2873397496 2873404696
	a=recvonly		a=recvonly
	m=audio 49170 RTP/AVP 0		m=audio 49170 RTP/AVP 0
	m=video 51372 RTP/AVP 31		m=video 51372 RTP/AVP 99
	m=application 32416 udp wb		a=rtpmap:99 h263-1998/90000
	a=orient:portrait
	Text fields such as the session name and information are octet		Text fields such as the session name and information are octet
	strings which may contain any octet with the exceptions of 0x00		strings which may contain any octet with the exceptions of 0x00
	(Nul), 0x0a (ASCII newline) and 0x0d (ASCII carriage return). The		(Nul), 0x0a (ASCII newline) and 0x0d (ASCII carriage return). The
	sequence CRLF (0x0d0a) is used to end a record, although parsers		sequence CRLF (0x0d0a) is used to end a record, although parsers
	SHOULD be tolerant and also accept records terminated with a single		SHOULD be tolerant and also accept records terminated with a single
	newline character. If the "a=charset" attribute is not present,		newline character. If the "a=charset" attribute is not present,
	these octet strings MUST be interpreted as containing ISO-10646		these octet strings MUST be interpreted as containing ISO-10646
	characters in UTF-8 encoding (the presence of the "a=charset"		characters in UTF-8 encoding (the presence of the "a=charset"
	attribute MAY force some fields to be interpreted differently).		attribute MAY force some fields to be interpreted differently).
	skipping to change at page 12, line 14		skipping to change at page 12, line 10
	be empty and SHOULD contain ISO 10646 characters (but see also the		be empty and SHOULD contain ISO 10646 characters (but see also the
	"a=charset" attribute). If a session has no meaningful name, the		"a=charset" attribute). If a session has no meaningful name, the
	value "s= " SHOULD be used (i.e. a single space as the session		value "s= " SHOULD be used (i.e. a single space as the session
	name).		name).
	5.4 Session Information ("i=")		5.4 Session Information ("i=")
	i=<session description>		i=<session description>
	The "i=" field provides textual information about the session. There		The "i=" field provides textual information about the session. There
	may be at most one session-level "i=" field per session description,		MUST be at most one session-level "i=" field per session description,
	and at most one "i=" field per media. If the "a=charset" attribute		and at most one "i=" field per media. If the "a=charset" attribute
	is present, it specifies the character set used in the "i=" field.		is present, it specifies the character set used in the "i=" field.
	If the "a=charset" attribute is not present, the "i=" field MUST		If the "a=charset" attribute is not present, the "i=" field MUST
	contain ISO 10646 characters in UTF-8 encoding.		contain ISO 10646 characters in UTF-8 encoding.
	A single "i=" field MAY also be used for each media definition. In		A single "i=" field MAY also be used for each media definition. In
	media definitions, "i=" fields are primarily intended for labeling		media definitions, "i=" fields are primarily intended for labeling
	media streams. As such, they are most likely to be useful when a		media streams. As such, they are most likely to be useful when a
	single session has more than one distinct media stream of the same		single session has more than one distinct media stream of the same
	media type. An example would be two different whiteboards, one for		media type. An example would be two different whiteboards, one for
	skipping to change at page 12, line 37		skipping to change at page 12, line 33
	The "i=" field is intended to provide a free-form human readable		The "i=" field is intended to provide a free-form human readable
	description of the session or the purpose of a media stream. It is		description of the session or the purpose of a media stream. It is
	not suitable for parsing by automata.		not suitable for parsing by automata.
	5.5 URI ("u=")		5.5 URI ("u=")
	u=<uri>		u=<uri>
	A URI is a Universal Resource Identifier as used by WWW clients [4],		A URI is a Universal Resource Identifier as used by WWW clients [4],
	[6]. The URI should be a pointer to additional information about the		[6]. The URI should be a pointer to additional information about the
	conference. This field is OPTIONAL, but if it is present it MUST be		session. This field is OPTIONAL, but if it is present it MUST be
	specified before the first media field. No more than one URI field		specified before the first media field. No more than one URI field
	is allowed per session description.		is allowed per session description.
	5.6 Email Address and Phone Number ("e=" and "p=")		5.6 Email Address and Phone Number ("e=" and "p=")
	e=<email-address>		e=<email-address>
	p=<phone-number>		p=<phone-number>
	The "e=" and "p=" lines specify contact information for the person		The "e=" and "p=" lines specify contact information for the person
	responsible for the conference. This is not necessarily the same		responsible for the conference. This is not necessarily the same
	skipping to change at page 14, line 4		skipping to change at page 13, line 47
	It MAY contain a single session-level "c=" field and additional "c="		It MAY contain a single session-level "c=" field and additional "c="
	field(s) per media description, in which case the per-media values		field(s) per media description, in which case the per-media values
	override the session-level settings for the respective media.		override the session-level settings for the respective media.
	The first sub-field ("<nettype>") is the network type, which is a		The first sub-field ("<nettype>") is the network type, which is a
	text string giving the type of network. Initially "IN" is defined to		text string giving the type of network. Initially "IN" is defined to
	have the meaning "Internet", but other values MAY be registered in		have the meaning "Internet", but other values MAY be registered in
	the future (see Section 8).		the future (see Section 8).
	The second sub-field ("<addrtype>") is the address type. This allows		The second sub-field ("<addrtype>") is the address type. This allows
	SDP to be used for sessions that are not IP based. Currently only		SDP to be used for sessions that are not IP based. This memo only
	IP4 and IP6 are defined, but other values MAY be registered in the		defines IP4 and IP6, but other values MAY be registered in the future
	future (see Section 8).		(see Section 8).
	The third sub-field ("<connection-address>") is the connection		The third sub-field ("<connection-address>") is the connection
	address. OPTIONAL sub-fields MAY be added after the connection		address. OPTIONAL sub-fields MAY be added after the connection
	address depending on the value of the <addrtype> field.		address depending on the value of the <addrtype> field.
	When the <addrtype> is IP4 and IP6, the connection address is defined		When the <addrtype> is IP4 and IP6, the connection address is defined
	as follows:		as follows:
	o If the session is multicast, the connection address will be an IP		o If the session is multicast, the connection address will be an IP
	multicast group address. If the session is not multicast, then		multicast group address. If the session is not multicast, then
	the connection address contains the unicast IP address of the		the connection address contains the unicast IP address of the
	expected data source or data relay or data sink as determined by		expected data source or data relay or data sink as determined by
	additional attribute fields. It is not expected that unicast		additional attribute fields. It is not expected that unicast
	addresses will be given in a session description that is		addresses will be given in a session description that is
	communicated by a multicast announcement, though this is not		communicated by a multicast announcement, though this is not
	prohibited.		prohibited.
	o Conferences using an IPv4 multicast connection address MUST also		o Sessions using an IPv4 multicast connection address MUST also have
	have a time to live (TTL) value present in addition to the		a time to live (TTL) value present in addition to the multicast
	multicast address. The TTL and the address together define the		address. The TTL and the address together define the scope with
	scope with which multicast packets sent in this conference will be		which multicast packets sent in this conference will be sent. TTL
	sent. TTL values MUST be in the range 0-255.		values MUST be in the range 0-255. While the TTL MUST be
			specified, its use to scope multicast traffic is deprecated;
			applications SHOULD use an adminstratively scoped address instead.
	The TTL for the session is appended to the address using a slash as a		The TTL for the session is appended to the address using a slash as a
	separator. An example is:		separator. An example is:
	c=IN IP4 224.2.36.42/127		c=IN IP4 224.2.36.42/127
	IPv6 multicast does not use TTL scoping, and hence the TTL value MUST		IPv6 multicast does not use TTL scoping, and hence the TTL value MUST
	NOT be present for IPv6 multicast. It is expected that IPv6 scoped		NOT be present for IPv6 multicast. It is expected that IPv6 scoped
	addresses will be used to limit the scope of conferences.		addresses will be used to limit the scope of conferences.
	skipping to change at page 15, line 51		skipping to change at page 15, line 48
	This OPTIONAL field denotes the proposed bandwidth to be used by the		This OPTIONAL field denotes the proposed bandwidth to be used by the
	session or media. The <bwtype> is an alphanumeric modifier giving		session or media. The <bwtype> is an alphanumeric modifier giving
	the meaning of the <bandwidth> figure. Two values are defined in		the meaning of the <bandwidth> figure. Two values are defined in
	this specification, but other values MAY be registered in future (see		this specification, but other values MAY be registered in future (see
	Section 8 and [22], [16]):		Section 8 and [22], [16]):
	CT If the bandwidth of a session or media in a session is different		CT If the bandwidth of a session or media in a session is different
	from the bandwidth implicit from the scope, a "b=CT:..." line		from the bandwidth implicit from the scope, a "b=CT:..." line
	SHOULD be supplied for the session giving the proposed upper limit		SHOULD be supplied for the session giving the proposed upper limit
	to the bandwidth used. The primary purpose of this is to give an		to the bandwidth used (the "conference total" bandwidth). The
	approximate idea as to whether two or more sessions can co-exist		primary purpose of this is to give an approximate idea as to
	simultaneously. When using the CT modifier with RTP, if several		whether two or more sessions can co-exist simultaneously. When
	RTP sessions are part of the conference, the conference total		using the CT modifier with RTP, if several RTP sessions are part
	refers to total bandwidth of all RTP sessions.		of the conference, the conference total refers to total bandwidth
			of all RTP sessions.
	AS The bandwidth is interpreted to be application-specific (it will		AS The bandwidth is interpreted to be application-specific (it will
	be the application's concept of maximum bandwidth). Normally this		be the application's concept of maximum bandwidth). Normally this
	will coincide with what is set on the application's "maximum		will coincide with what is set on the application's "maximum
	bandwidth" control if applicable. For RTP based applications, AS		bandwidth" control if applicable. For RTP based applications, AS
	gives the RTP "session bandwidth" as defined in section 6.2 of		gives the RTP "session bandwidth" as defined in section 6.2 of
	[14].		[14].
	Note that CT gives a total bandwidth figure for all the media at all		Note that CT gives a total bandwidth figure for all the media at all
	sites. AS gives a bandwidth figure for a single media at a single		sites. AS gives a bandwidth figure for a single media at a single
	skipping to change at page 16, line 30		skipping to change at page 16, line 28
	experimental purposes only. For example:		experimental purposes only. For example:
	b=X-YZ:128		b=X-YZ:128
	Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers		Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers
	SHOULD be registered with IANA in the standard namespace. SDP		SHOULD be registered with IANA in the standard namespace. SDP
	parsers MUST ignore bandwidth fields with unknown modifiers.		parsers MUST ignore bandwidth fields with unknown modifiers.
	Modifiers MUST be alpha-numeric and, although no length limit is		Modifiers MUST be alpha-numeric and, although no length limit is
	given, they are recommended to be short.		given, they are recommended to be short.
	The <bandwidth> is in kilobits per second by default. Modifiers MAY		The <bandwidth> is interpreted as kilobits per second by default.
	specify that alternative units are to be used (the modifiers defined		The definition of a new <bwtype> modifier MAY specify that the
	in this memo use the default units).		bandwidth is to be interpreted in some alternative unit (the "CT" and
			"AS" modifiers defined in this memo use the default units).
	5.9 Timing ("t=")		5.9 Timing ("t=")
	t=<start-time> <stop-time>		t=<start-time> <stop-time>
	The "t=" lines specify the start and stop times for a session.		The "t=" lines specify the start and stop times for a session.
	Multiple "t=" lines MAY be used if a session is active at multiple		Multiple "t=" lines MAY be used if a session is active at multiple
	irregularly spaced times; each additional "t=" lines specifies an		irregularly spaced times; each additional "t=" lines specifies an
	additional period of time for which the session will be active. If		additional period of time for which the session will be active. If
	the session is active at regular times, an "r=" line (see below)		the session is active at regular times, an "r=" line (see below)
	skipping to change at page 17, line 24		skipping to change at page 17, line 22
	User interfaces SHOULD strongly discourage the creation of unbounded		User interfaces SHOULD strongly discourage the creation of unbounded
	and permanent sessions as they give no information about when the		and permanent sessions as they give no information about when the
	session is actually going to terminate, and so make scheduling		session is actually going to terminate, and so make scheduling
	difficult.		difficult.
	The general assumption may be made, when displaying unbounded		The general assumption may be made, when displaying unbounded
	sessions that have not timed out to the user, that an unbounded		sessions that have not timed out to the user, that an unbounded
	session will only be active until half an hour from the current time		session will only be active until half an hour from the current time
	or the session start time, whichever is the later. If behaviour		or the session start time, whichever is the later. If behaviour
	other than this is required, an end-time should be given and modified		other than this is required, an end-time SHOULD be given and modified
	as appropriate when new information becomes available about when the		as appropriate when new information becomes available about when the
	session should really end.		session should really end.
	Permanent sessions may be shown to the user as never being active		Permanent sessions may be shown to the user as never being active
	unless there are associated repeat times which state precisely when		unless there are associated repeat times which state precisely when
	the session will be active. In general, permanent sessions SHOULD		the session will be active. In general, permanent sessions SHOULD
	NOT be created for any session expected to have a duration of less		NOT be created for any session expected to have a duration of less
	than 2 months, and should be discouraged for sessions expected to		than 2 months, and should be discouraged for sessions expected to
	have a duration of less than 6 months.		have a duration of less than 6 months.
	skipping to change at page 20, line 27		skipping to change at page 20, line 27
	media stream referred to by this key field is encrypted. The		media stream referred to by this key field is encrypted. The
	user should be prompted for the key when attempting to join the		user should be prompted for the key when attempting to join the
	session, and this user-supplied key should then be used to		session, and this user-supplied key should then be used to
	decrypt the media streams. The use of user-specified keys is		decrypt the media streams. The use of user-specified keys is
	NOT RECOMMENDED, since such keys tend to have weak security		NOT RECOMMENDED, since such keys tend to have weak security
	properties.		properties.
	The key field MUST NOT be used unless it can be guaranteed that the		The key field MUST NOT be used unless it can be guaranteed that the
	SDP is conveyed over a secure and trusted channel. An example of		SDP is conveyed over a secure and trusted channel. An example of
	such a channel might be SDP embedded inside an S/MIME message or a		such a channel might be SDP embedded inside an S/MIME message or a
	TLS protected HTTP or SIP session. It is important to ensure that		TLS-protected HTTP session. It is important to ensure that the
	the secure channel is with the party that is authorized to join the		secure channel is with the party that is authorized to join the
	session, not an intermediary: if a caching proxy server is used, it		session, not an intermediary: if a caching proxy server is used, it
	is important to ensure that the proxy is either trusted or unable to		is important to ensure that the proxy is either trusted or unable to
	access the SDP. Definition of appropriate security measures is		access the SDP. Definition of appropriate security measures is
	beyond the scope of this specification, and should be defined by the		beyond the scope of this specification, and should be defined by the
	users of SDP.		users of SDP.
	5.13 Attributes ("a=")		5.13 Attributes ("a=")
	a=<attribute>		a=<attribute>
	a=<attribute>:<value>		a=<attribute>:<value>
	Attributes are the primary means for extending SDP. Attributes may		Attributes are the primary means for extending SDP. Attributes may
	be defined to be used as "session-level" attributes, "media-level"		be defined to be used as "session-level" attributes, "media-level"
	attributes, or both.		attributes, or both.
	A media description may have any number of attributes ("a=" fields)		A media description may have any number of attributes ("a=" fields)
	which are media specific. These are referred to as "media-level"		which are media specific. These are referred to as "media-level"
	attributes and add information about the media stream. Attribute		attributes and add information about the media stream. Attribute
	fields can also be added before the first media field; these		fields can also be added before the first media field; these
	"session-level" attributes convey additional information that applies		"session-level" attributes convey additional information that applies
	to the conference as a whole rather than to individual media; an		to the conference as a whole rather than to individual media.
	example might be the conference's floor control policy.
	Attribute fields may be of two forms:		Attribute fields may be of two forms:
	o A property attribute is simply of the form "a=<flag>". These are		o A property attribute is simply of the form "a=<flag>". These are
	binary attributes, and the presence of the attribute conveys that		binary attributes, and the presence of the attribute conveys that
	the attribute is a property of the session. An example might be		the attribute is a property of the session. An example might be
	"a=recvonly".		"a=recvonly".
	o A value attribute is of the form "a=<attribute>:<value>". For		o A value attribute is of the form "a=<attribute>:<value>". For
	example, a whiteboard could have the value attribute		example, a whiteboard could have the value attribute
	skipping to change at page 21, line 28		skipping to change at page 21, line 28
	Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8.		Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8.
	Attribute values are octet strings, and MAY use any octet value		Attribute values are octet strings, and MAY use any octet value
	except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute		except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute
	values are to be interpreted as in ISO-10646 character set with UTF-8		values are to be interpreted as in ISO-10646 character set with UTF-8
	encoding. Unlike other text fields, attribute values are NOT		encoding. Unlike other text fields, attribute values are NOT
	normally affected by the "charset" attribute as this would make		normally affected by the "charset" attribute as this would make
	comparisons against known values problematic. However, when an		comparisons against known values problematic. However, when an
	attribute is defined, it can be defined to be charset-dependent, in		attribute is defined, it can be defined to be charset-dependent, in
	which case it's value should be interpreted in the session charset		which case its value should be interpreted in the session charset
	rather than in ISO-10646.		rather than in ISO-10646.
	Attributes MUST be registered with IANA (see Section 8). If an		Attributes MUST be registered with IANA (see Section 8). If an
	attribute is received that is not understood, it MUST be ignored by		attribute is received that is not understood, it MUST be ignored by
	the receiver.		the receiver.
	5.14 Media Descriptions ("m=")		5.14 Media Descriptions ("m=")
	m=<media> <port> <proto> <fmt> ...		m=<media> <port> <proto> <fmt> ...
	skipping to change at page 22, line 39		skipping to change at page 22, line 39
	If multiple addresses are specified in the "c=" field and multiple		If multiple addresses are specified in the "c=" field and multiple
	ports are specified in the "m=" field, a one-to-one mapping from		ports are specified in the "m=" field, a one-to-one mapping from
	port to the corresponding address is implied. For example:		port to the corresponding address is implied. For example:
	c=IN IP4 224.2.1.1/127/2		c=IN IP4 224.2.1.1/127/2
	m=video 49170/2 RTP/AVP 31		m=video 49170/2 RTP/AVP 31
	would imply that address 224.2.1.1 is used with ports 49170 and		would imply that address 224.2.1.1 is used with ports 49170 and
	49171, and address 224.2.1.2 is used with ports 49172 and 49173.		49171, and address 224.2.1.2 is used with ports 49172 and 49173.
			The combination of ports specified in "m=" lines and IP addresses
			specified in "c=" lines MUST comply with the following rules for
			RTP-based media streams (other protocols SHOULD define similar
			rules):
			1. If two media sessions have the same transport address (i.e.
			identical IP address and port numbers), the associated payload
			types (e.g. given in the "a=rtpmap:" attribute) MUST NOT be
			in conflict, i.e. the same payload type MUST NOT be mapped to
			different media types.
			2. If two media sessions have the same transport address, they
			MUST use compatible media (e.g. both audio or both video).
			3. If two media sessions have the same transport address, they
			SHOULD operate under the same RTP profile. The sessions MAY
			use two different RTP profiles only if those profiles are
			specifically designed to be compatible.
			4. If two media sessions have the same RTP transport address,
			they MUST also use the same RTCP address and vice versa.
			Two media sessions with the same transport address indicate
			alternatives for the same media stream, i.e. all profiles, media
			types, and payload types provided in any of the "m=" lines are
			valid.
	<proto> is the transport protocol. The meaning of the transport		<proto> is the transport protocol. The meaning of the transport
	protocol is dependent on the address type field in the relevant		protocol is dependent on the address type field in the relevant
	"c=" field. Thus a "c=" field of IP4 indicates that the transport		"c=" field. Thus a "c=" field of IP4 indicates that the transport
	protocol runs over IP4. The following transport protocols are		protocol runs over IP4. The following transport protocols are
	defined, but may be extended through registration of new protocols		defined, but may be extended through registration of new protocols
	with IANA (see Section 8):		with IANA (see Section 8):
	* udp: denotes an unspecified protocol running over UDP.		* udp: denotes an unspecified protocol running over UDP.
	* RTP/AVP: denotes RTP [14] used under the RTP Profile for Audio		* RTP/AVP: denotes RTP [14] used under the RTP Profile for Audio
	and Video Conferences with Minimal Control [15] running over		and Video Conferences with Minimal Control [15] running over
	UDP.		UDP.
	* RTP/SAVP: denotes the Secure Real-time Transport Protocol [18]		* RTP/SAVP: denotes the Secure Real-time Transport Protocol [18]
	running over UDP.		running over UDP.
	The main reason to specify the transport-protocol in addition to		The main reason to specify the transport-protocol in addition to
	the media format is that the same standard media formats may be		the media format is that the same standard media formats may be
	carried over different transport protocols even when the network		carried over different transport protocols even when the network
	protocol is the same - a historical example is vat PCM audio and		protocol is the same - a historical example is vat PCM audio and
	RTP PCM audio. In addition, relays and monitoring tools that are		RTP PCM audio, another might be TCP/RTP PCM audio. In addition,
	transport-protocol-specific but format-independent are possible.		relays and monitoring tools that are transport-protocol-specific
			but format-independent are possible.
	<fmt> is a media format description. The fourth and any subsequent		<fmt> is a media format description. The fourth and any subsequent
	sub-fields describe the format of the media. The interpretation		sub-fields describe the format of the media. The interpretation
	of the media format depends on the value of the <proto> sub-field.		of the media format depends on the value of the <proto> sub-field.
	If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP" the <fmt>		If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP" the <fmt>
	sub-fields contain RTP payload type numbers. When a list of		sub-fields contain RTP payload type numbers. When a list of
	payload type numbers is given, this implies that all of these		payload type numbers is given, this implies that all of these
	payload formats MAY be used in the session, but the first of these		payload formats MAY be used in the session, but the first of these
	formats SHOULD be used as the default format for the session. For		formats SHOULD be used as the default format for the session. For
	dynamic payload type assignments the "a=rtpmap:" attribute (see		dynamic payload type assignments the "a=rtpmap:" attribute (see
	Section 6) SHOULD be used to map from an RTP payload type number		Section 6) SHOULD be used to map from an RTP payload type number
	to a media encoding name that identifies the payload format. The		to a media encoding name that identifies the payload format. The
	"a=fmtp:" attribute MAY be used to specify format parameters (see		"a=fmtp:" attribute MAY be used to specify format parameters (see
	Section 6).		Section 6).
	If the <proto> sub-field is "udp" the <fmt> sub-fields MUST		If the <proto> sub-field is "udp" the <fmt> sub-fields MUST
	reference a media type describing the format under the "audio",		reference a media type describing the format under the "audio",
	"text" and "video" top-level MIME types. The media type		"video", "text" and "application" top-level MIME types. The media
	registration SHOULD define the packetization format for use with		type registration SHOULD define the packetization format for use
	UDP transport.		with UDP transport.
	For media using other transport protocols, the <fmt> field is		For media using other transport protocols, the <fmt> field is
	protocol specific. Rules for interpretation of the <fmt>		protocol specific. Rules for interpretation of the <fmt>
	sub-field MUST be defined when registering new protocols (see		sub-field MUST be defined when registering new protocols (see
	section 8.2.2).		section 8.2.2).
	6. Suggested Attributes		6. SDP Attributes
	The following attributes are defined. Since application writers may		The following attributes are defined. Since application writers may
	add new attributes as they are required, this list is not exhaustive.		add new attributes as they are required, this list is not exhaustive.
	Registration procedures for new attributes are defined in Section		Registration procedures for new attributes are defined in Section
	8.2.4.		8.2.4.
	a=cat:<category>		a=cat:<category>
	This attribute gives the dot-separated hierarchical category		This attribute gives the dot-separated hierarchical category
	of the session. This is to enable a receiver to filter		of the session. This is to enable a receiver to filter
	skipping to change at page 24, line 39		skipping to change at page 25, line 21
	sense. It should not be necessary to know ptime to decode RTP		sense. It should not be necessary to know ptime to decode RTP
	or vat audio, and it is intended as a recommendation for the		or vat audio, and it is intended as a recommendation for the
	encoding/packetisation of audio. It is a media attribute, and		encoding/packetisation of audio. It is a media attribute, and
	is not dependent on charset.		is not dependent on charset.
	a=maxptime:<maximum packet time>		a=maxptime:<maximum packet time>
	The maximum amount of media which can be encapsulated in each		The maximum amount of media which can be encapsulated in each
	packet, expressed as time in milliseconds. The time SHALL be		packet, expressed as time in milliseconds. The time SHALL be
	calculated as the sum of the time the media present in the		calculated as the sum of the time the media present in the
	packet represents. The time SHOULD be a multiple of the frame		packet represents. For frame based codecs, the time SHOULD
	size. This attribute is probably only meaningful for audio		be an integer multiple of the frame size. This attribute is
	data, but may be used with other media types if it makes		probably only meaningful for audio data, but may be used with
	sense. It is a media attribute, and is not dependent on		other media types if it makes sense. It is a media attribute,
	charset. Note that this attribute was introduced after RFC		and is not dependent on charset. Note that this attribute was
	2327, and non updated implementations will ignore this		introduced after RFC 2327, and non updated implementations will
	attribute.		ignore this attribute.
	a=rtpmap:<payload type> <encoding name>/<clock rate>		a=rtpmap:<payload type> <encoding name>/<clock rate>
	[/<encoding parameters>]		[/<encoding parameters>]
	This attribute maps from an RTP payload type number (as used in		This attribute maps from an RTP payload type number (as used in
	an "m=" line) to an encoding name denoting the payload format		an "m=" line) to an encoding name denoting the payload format
	to be used. It also provides information on the clock rate and		to be used. It also provides information on the clock rate and
	encoding parameters. It is a media level attribute that is not		encoding parameters. It is a media level attribute that is not
	dependent on charset.		dependent on charset.
	skipping to change at page 26, line 43		skipping to change at page 27, line 23
	If none of the attributes "sendonly", "recvonly", "inactive",		If none of the attributes "sendonly", "recvonly", "inactive",
	and "sendrecv" is present, "sendrecv" SHOULD be assumed as the		and "sendrecv" is present, "sendrecv" SHOULD be assumed as the
	default for sessions which are not of the conference type		default for sessions which are not of the conference type
	"broadcast" or "H332" (see below).		"broadcast" or "H332" (see below).
	a=sendonly		a=sendonly
	This specifies that the tools should be started in send-only		This specifies that the tools should be started in send-only
	mode. An example may be where a different unicast address is		mode. An example may be where a different unicast address is
	to be used for a traffic destination than for a traffic		to be used for a traffic destination than for a traffic
	source. In such a case, two media descriptions may be use,		source. In such a case, two media descriptions may be used,
	one sendonly and one recvonly. It can be either a session or		one sendonly and one recvonly. It can be either a session or
	media attribute, but would normally only be used as a media		media attribute, but would normally only be used as a media
	attribute, and is not dependent on charset. Note that sendonly		attribute. It is not dependent on charset. Note that sendonly
	applies only to the media, and any associated control protocol		applies only to the media, and any associated control protocol
	(e.g. RTCP) SHOULD still be received and processed as normal.		(e.g. RTCP) SHOULD still be received and processed as normal.
	a=inactive		a=inactive
	This specifies that the tools should be started in inactive		This specifies that the tools should be started in inactive
	mode. This is necessary for interactive conferences where		mode. This is necessary for interactive conferences where
	users can put other users on hold. No media is sent over an		users can put other users on hold. No media is sent over an
	inactive media stream. Note that an RTP based system SHOULD		inactive media stream. Note that an RTP based system SHOULD
	still send RTCP, even if started inactive. It can be either a		still send RTCP, even if started inactive. It can be either a
	session or media attribute, and is not dependent on charset.		session or media attribute, and is not dependent on charset.
	a=orient:<whiteboard orientation>		a=orient:<orientation>
	Normally this is only used in a whiteboard media specification.		Normally this is only used for a whiteboard or presentation
	It specifies the orientation of a the whiteboard on the screen.		tool. It specifies the orientation of a the workspace on
	It is a media attribute. Permitted values are "portrait",		the screen. It is a media attribute. Permitted values are
	"landscape" and "seascape" (upside down landscape). It is not		"portrait", "landscape" and "seascape" (upside down landscape).
	dependent on charset.		It is not dependent on charset.
	a=type:<conference type>		a=type:<conference type>
	This specifies the type of the conference. Suggested values		This specifies the type of the conference. Suggested values
	are "broadcast", "meeting", "moderated", "test" and "H332".		are "broadcast", "meeting", "moderated", "test" and "H332".
	"recvonly" should be the default for "type:broadcast"		"recvonly" should be the default for "type:broadcast"
	sessions, "type:meeting" should imply "sendrecv" and		sessions, "type:meeting" should imply "sendrecv" and
	"type:moderated" should indicate the use of a floor control		"type:moderated" should indicate the use of a floor control
	tool and that the media tools are started so as to mute new		tool and that the media tools are started so as to mute new
	sites joining the conference.		sites joining the conference.
	skipping to change at page 30, line 11		skipping to change at page 30, line 41
	formats specified for the media. Format-specific parameters		formats specified for the media. Format-specific parameters
	may be any set of parameters required to be conveyed by SDP		may be any set of parameters required to be conveyed by SDP
	and given unchanged to the media tool that will use this		and given unchanged to the media tool that will use this
	format. At most one instance of this attribute is allowed		format. At most one instance of this attribute is allowed
	for each format.		for each format.
	It is a media attribute, and is not dependent on charset.		It is a media attribute, and is not dependent on charset.
	7. Security Considerations		7. Security Considerations
			SDP is frequently used with the Session Initiation Protocol [10]
			using the offer/answer model [12] to agree parameters for unicast
			sessions. When used in this manner, the security considerations of
			those protocols apply.
	SDP is a session description format that describes multimedia		SDP is a session description format that describes multimedia
	sessions. A session description SHOULD NOT be trusted unless it has		sessions. A session description SHOULD NOT be trusted unless it has
	been obtained by an authenticated transport protocol from a trusted		been obtained by an authenticated transport protocol from a trusted
	source. Many different transport protocols may be used to distribute		source. Many different transport protocols may be used to distribute
	session description, and the nature of the authentication will differ		session description, and the nature of the authentication will differ
	from transport to transport.		from transport to transport.
	One transport that will frequently be used to distribute session		One transport that will frequently be used to distribute session
	descriptions is the Session Announcement Protocol (SAP). SAP		descriptions is the Session Announcement Protocol (SAP). SAP
	provides both encryption and authentication mechanisms but due to the		provides both encryption and authentication mechanisms but due to the
	skipping to change at page 31, line 10		skipping to change at page 31, line 44
	tools in a mode where they default to transmitting. Under some		tools in a mode where they default to transmitting. Under some
	circumstances it might be appropriate to define such attributes. If		circumstances it might be appropriate to define such attributes. If
	this is done an application parsing a session description containing		this is done an application parsing a session description containing
	such attributes SHOULD either ignore them, or inform the user that		such attributes SHOULD either ignore them, or inform the user that
	joining this session will result in the automatic transmission of		joining this session will result in the automatic transmission of
	multimedia data. The default behaviour for an unknown attribute is		multimedia data. The default behaviour for an unknown attribute is
	to ignore it.		to ignore it.
	Session descriptions may be parsed at intermediate systems such as		Session descriptions may be parsed at intermediate systems such as
	firewalls for the purposes of opening a hole in the firewall to allow		firewalls for the purposes of opening a hole in the firewall to allow
	the participation in multimedia sessions. It is considered		participation in multimedia sessions. This SHOULD NOT be done unless
	inappropriate for a firewall to open such holes for unicast data		the SDP is conveyed in a manner that allows proper authentication and
	streams unless the session description comes in a request from inside		authorization checks to ensure that firewall holes are only opened in
	the firewall. For multicast sessions, it is likely that local		accordance with applicable security policy. SDP by itself does not
	administrators will apply their own policies, but the exclusive use		include sufficient information to enable these checks: they depend on
	of "local" or "site-local" administrative scope within the firewall		the encapsulating protocol (e.g. SIP or RTSP).
	and the refusal of the firewall to open a hole for such scopes will
	provide separation of global multicast sessions from local ones.
	Use of the "k=" field poses a significant security risk, since it		Use of the "k=" field poses a significant security risk, since it
	conveys session encryption keys in the clear. SDP MUST NOT be used		conveys session encryption keys in the clear. SDP MUST NOT be used
	to convey key material, unless it can be guaranteed that the channel		to convey key material, unless it can be guaranteed that the channel
	over which the SDP is delivered is both private and authenticated.		over which the SDP is delivered is both private and authenticated.
	8. IANA Considerations		8. IANA Considerations
	8.1 The "application/sdp" media type		8.1 The "application/sdp" media type
	skipping to change at page 38, line 37		skipping to change at page 39, line 10
	; sub-rules of 'o='		; sub-rules of 'o='
	username = non-ws-string		username = non-ws-string
	;pretty wide definition, but doesn't		;pretty wide definition, but doesn't
	;include space		;include space
	sess-id = 1*DIGIT		sess-id = 1*DIGIT
	;should be unique for this username/host		;should be unique for this username/host
	sess-version = 1*DIGIT		sess-version = 1*DIGIT
	;0 is a new session
	nettype = token		nettype = token
	;typically "IN"		;typically "IN"
	addrtype = token		addrtype = token
	;typically "IP4" or "IP6"		;typically "IP4" or "IP6"
	; sub-rules of 'u='		; sub-rules of 'u='
	uri = URI-reference		uri = URI-reference
	; see RFC2396 and RFC2732		; see RFC2396 and RFC2732
	skipping to change at page 40, line 27		skipping to change at page 40, line 47
	;"application"		;"application"
	fmt = token		fmt = token
	;typically an RTP payload type for audio		;typically an RTP payload type for audio
	;and video media		;and video media
	proto = token *("/" token)		proto = token *("/" token)
	;typically "RTP/AVP" or "udp"		;typically "RTP/AVP" or "udp"
	port = 1*DIGIT		port = 1*DIGIT
	;should be either "0" or in the range "1024"
	;to "65535" inclusive for UDP based media
	;(a value of "0" is used to signal special
	;conditions in some uses of SDP)
	; generic sub-rules: addressing		; generic sub-rules: addressing
	unicast-address = IP4-address / IP6-address / FQDN / extn-addr		unicast-address = IP4-address / IP6-address / FQDN / extn-addr
	multicast-address = IP4-multicast / IP6-multicast / extn-addr		multicast-address = IP4-multicast / IP6-multicast / FQDN
			/ extn-addr
	IP4-multicast = m1 3( "." decimal-uchar )		IP4-multicast = m1 3( "." decimal-uchar )
	"/" ttl [ "/" integer ]		"/" ttl [ "/" integer ]
	; IPv4 multicast addresses may be in the		; IPv4 multicast addresses may be in the
	; range 224.0.0.0 to 239.255.255.255		; range 224.0.0.0 to 239.255.255.255
	m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) /		m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) /
	("23" DIGIT )		("23" DIGIT )
	IP6-multicast = hexpart [ "/" integer ]		IP6-multicast = hexpart [ "/" integer ]
	; IPv6 address starting with FF		; IPv6 address starting with FF
	ttl = (POS-DIGIT *2DIGIT) / "0"		ttl = (POS-DIGIT *2DIGIT) / "0"
	FQDN = 4*(alpha-numeric / "-" / ".")		FQDN = 4*(alpha-numeric / "-" / ".")
	; fully qualified domain name as specified		; fully qualified domain name as specified
	; in RFC1035		; in RFC1035 (and updates)
	IP4-address = b1 3("." decimal-uchar) / "0.0.0.0"		IP4-address = b1 3("." decimal-uchar)
	b1 = decimal-uchar		b1 = decimal-uchar
	; less than "224"; not "0" or "127"		; less than "224"
	; The following is from RFC2373 Appendix B. It is a direct copy.		; The following is from RFC2373 Appendix B. It is a direct copy.
	IP6-address = hexpart [ ":" IP4-address ]		IP6-address = hexpart [ ":" IP4-address ]
	hexpart = hexseq / hexseq "::" [ hexseq ] /		hexpart = hexseq / hexseq "::" [ hexseq ] /
	"::" [ hexseq ]		"::" [ hexseq ]
	hexseq = hex4 *( ":" hex4)		hexseq = hex4 *( ":" hex4)
	hex4 = 1*4HEXDIG		hex4 = 1*4HEXDIG
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/