draft-ietf-mmusic-sdp-new-16.txt		draft-ietf-mmusic-sdp-new-17.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: November 2, 2004 C. Perkins		Expires: November 30, 2004 C. Perkins
	University of Glasgow		University of Glasgow
	May 4, 2004		June 1, 2004
	SDP: Session Description Protocol		SDP: Session Description Protocol
	draft-ietf-mmusic-sdp-new-16.txt		draft-ietf-mmusic-sdp-new-17.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, I certify that any applicable
	patent or other IPR claims of which I am aware have been disclosed,		patent or other IPR claims of which I am aware have been disclosed,
	and any of which I become aware will be disclosed, in accordance with		and any of which I become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	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 other		Task Force (IETF), its areas, and its working groups. Note that other
	skipping to change at page 1, line 36		skipping to change at page 1, line 36
	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 http://		The list of current Internet-Drafts can be accessed at http://
	www.ietf.org/ietf/1id-abstracts.txt.		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 November 2, 2004.		This Internet-Draft will expire on November 30, 2004.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	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 22		skipping to change at page 2, line 22
	3.3 Streaming media . . . . . . . . . . . . . . . . . . . . . 4		3.3 Streaming media . . . . . . . . . . . . . . . . . . . . . 4
	3.4 Email and the World Wide Web . . . . . . . . . . . . . . . 4		3.4 Email and the World Wide Web . . . . . . . . . . . . . . . 4
	4. Requirements and Recommendations . . . . . . . . . . . . . . 5		4. Requirements and Recommendations . . . . . . . . . . . . . . 5
	4.1 Media Information . . . . . . . . . . . . . . . . . . . . 5		4.1 Media Information . . . . . . . . . . . . . . . . . . . . 5
	4.2 Timing Information . . . . . . . . . . . . . . . . . . . . 6		4.2 Timing Information . . . . . . . . . . . . . . . . . . . . 6
	4.3 Private Sessions . . . . . . . . . . . . . . . . . . . . . 6		4.3 Private Sessions . . . . . . . . . . . . . . . . . . . . . 6
	4.4 Obtaining Further Information about a Session . . . . . . 6		4.4 Obtaining Further Information about a Session . . . . . . 6
	4.5 Categorisation . . . . . . . . . . . . . . . . . . . . . . 6		4.5 Categorisation . . . . . . . . . . . . . . . . . . . . . . 6
	4.6 Internationalization . . . . . . . . . . . . . . . . . . . 7		4.6 Internationalization . . . . . . . . . . . . . . . . . . . 7
	5. SDP Specification . . . . . . . . . . . . . . . . . . . . . 7		5. SDP Specification . . . . . . . . . . . . . . . . . . . . . 7
	5.1 Protocol Version ("v=") . . . . . . . . . . . . . . . . . 9		5.1 Protocol Version ("v=") . . . . . . . . . . . . . . . . .
	5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 10		9
	5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . . 11		5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . .
	5.4 Session Information ("i=") . . . . . . . . . . . . . . . . 11		10
	5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 11		5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . .
	5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . 11		11
	5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . 12		5.4 Session Information ("i=") . . . . . . . . . . . . . . . .
	5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 14		11
	5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 15		5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . .
	5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . 16		11
	5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . 17		5.6 Email Address and Phone Number ("e=" and "p=") . . . . . .
	5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 18		11
	5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . 19		5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . .
	5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . . 21		12
			5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . .
			14
			5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . .
			15
			5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . .
			16
			5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . .
			17
			5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . .
			18
			5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . .
			19
			5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . .
			21
	6. Suggested Attributes . . . . . . . . . . . . . . . . . . . . 24		6. Suggested Attributes . . . . . . . . . . . . . . . . . . . . 24
	7. Communicating Conference Control Policy . . . . . . . . . . 29		7. Communicating Conference Control Policy . . . . . . . . . . 29
	8. Security Considerations . . . . . . . . . . . . . . . . . . 30		8. Security Considerations . . . . . . . . . . . . . . . . . . 30
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31
	9.1 The "application/sdp" media type . . . . . . . . . . . . . 31		9.1 The "application/sdp" media type . . . . . . . . . . . . . 31
	9.2 Registration of Parameters . . . . . . . . . . . . . . . . 32		9.2 Registration of Parameters . . . . . . . . . . . . . . . . 32
	9.3 Encryption Key Access Methods . . . . . . . . . . . . . . 36		9.3 Encryption Key Access Methods . . . . . . . . . . . . . . 36
	A. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 37		A. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 37
	B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 42		B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 42
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 42		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
	skipping to change at page 9, line 50		skipping to change at page 9, line 50
	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).
	5.1 Protocol Version ("v=")		5.1 Protocol Version ("v=")
	v=0		v=0
	The "v=" field gives the version of the Session Description Protocol.		The "v=" field gives the version of the Session Description
			Protocol.
	This memo defines version 0. There is no minor version number.		This memo defines version 0. There is no minor version number.
	5.2 Origin ("o=")		5.2 Origin ("o=")
	o=<username> <sess-id> <sess-version> <nettype> <addrtype>		o=<username> <sess-id> <sess-version> <nettype> <addrtype>
	<unicast-address>		<unicast-address>
	The "o=" field gives the originator of the session (her username and		The "o=" field gives the originator of the session (her username
			and
	the address of the user's host) plus a session identifier and version		the address of the user's host) plus a session identifier and version
	number:		number:
	<username> is the user's login on the originating host, or it is "-"		<username> is the user's login on the originating host, or it is "-"
	if the originating host does not support the concept of user ids.		if the originating host does not support the concept of user ids.
	The <username> MUST NOT contain spaces.		The <username> MUST NOT contain spaces.
	<sess-id> is a numeric string such that the tuple of <username>,		<sess-id> is a numeric string such that the tuple of <username>,
	<sess-id>, <nettype>, <addrtype> and <unicast-address> form a		<sess-id>, <nettype>, <addrtype> and <unicast-address> form a
	globally unique identifier for the session. The method of		globally unique identifier for the session. The method of
	<sess-id> allocation is up to the creating tool, but it has been		<sess-id> allocation is up to the creating tool, but it has been
	skipping to change at page 10, line 46		skipping to change at page 10, line 47
	dotted-decimal representation of the IP version 4 address of the		dotted-decimal representation of the IP version 4 address of the
	machine. For an address type of IP6, this is either the		machine. For an address type of IP6, this is either the
	fully-qualified domain name of the machine, or the compressed		fully-qualified domain name of the machine, or the compressed
	textual representation of the IP version 6 address of the machine.		textual representation of the IP version 6 address of the machine.
	For both IP4 and IP6, the fully-qualified domain name is the form		For both IP4 and IP6, the fully-qualified domain name is the form
	that SHOULD be given unless this is unavailable, in which case the		that SHOULD be given unless this is unavailable, in which case the
	globally unique address MAY be substituted. A local IP address		globally unique address MAY be substituted. A local IP address
	MUST NOT be used in any context where the SDP description might		MUST NOT be used in any context where the SDP description might
	leave the scope in which the address is meaningful.		leave the scope in which the address is meaningful.
	In general, the "o=" field serves as a globally unique identifier for		In general, the "o=" field serves as a globally unique identifier
			for
	this version of this session description, and the subfields excepting		this version of this session description, and the subfields excepting
	the version taken together identify the session irrespective of any		the version taken together identify the session irrespective of any
	modifications.		modifications.
	5.3 Session Name ("s=")		5.3 Session Name ("s=")
	s=<session name>		s=<session name>
	The "s=" field is the textual session name. There MUST be one and		The "s=" field is the textual session name. There MUST be one and
	only one "s=" field per session description. The "s=" field MUST NOT		only one "s=" field per session description. The "s=" field MUST
			NOT
	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 name).		value "s= " SHOULD be used (i.e. a single space as the session
			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.
	may be at most one session-level "i=" field per session description,		There
	and at most one "i=" field per media. If the "a=charset" attribute is		may be at most one session-level "i=" field per session
			description,
			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. If		present, it specifies the character set used in the "i=" field. If
	the "a=charset" attribute is not present, the "i=" field MUST contain		the "a=charset" attribute is not present, the "i=" field MUST
			contain
	ISO 10646 characters in UTF-8 encoding.		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
	slides and one for feedback and questions.		slides and one for feedback and questions.
	5.5 URI ("u=")		5.5 URI ("u=")
	skipping to change at page 11, line 48		skipping to change at page 11, line 54
	The URI should be a pointer to additional information about the		The URI should be a pointer to additional information about the
	conference. This field is OPTIONAL, but if it is present it MUST be		conference. This field is OPTIONAL, but if it is present it MUST be
	specified before the first media field. No more than one URI field is		specified before the first media field. No more than one URI field is
	allowed per session description.		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
	person that created the conference announcement.		person that created the conference announcement.
	Inclusion of an email address or phone number is OPTIONAL. Note that		Inclusion of an email address or phone number is OPTIONAL. Note that
	the previous version of SDP specified that either an email field or a		the previous version of SDP specified that either an email field or a
	phone field MUST be specified, but this was widely ignored. The		phone field MUST be specified, but this was widely ignored. The
	change brings the specification into line with common usage.		change brings the specification into line with common usage.
	If the email addres or phone number are present, they MUST be		If the email addres or phone number are present, they MUST be
	specified before the first media field. More than one email or phone		specified before the first media field. More than one email or phone
	skipping to change at page 12, line 41		skipping to change at page 12, line 41
	The free text string SHOULD be in the ISO-10646 character set with		The free text string SHOULD be in the ISO-10646 character set with
	UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if		UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if
	the appropriate session-level "a=charset" attribute is set.		the appropriate session-level "a=charset" attribute is set.
	5.7 Connection Data ("c=")		5.7 Connection Data ("c=")
	c=<nettype> <addrtype> <connection-address>		c=<nettype> <addrtype> <connection-address>
	The "c=" field contains connection data.		The "c=" field contains connection data.
	A session description MUST contain either at least one "c=" field in		A session description MUST contain either at least one "c=" field
			in
	each media description or a single "c=" field at the session level.		each media description or a single "c=" field at the session level.
	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 9).		the future (see Section 9).
	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 IP4		SDP to be used for sessions that are not IP based. Currently only IP4
	skipping to change at page 15, line 42		skipping to change at page 15, line 42
	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)
	should be used in addition to, and following, a "t=" line - in which		should be used in addition to, and following, a "t=" line - in
			which
	case the "t=" line specifies the start and stop times of the repeat		case the "t=" line specifies the start and stop times of the repeat
	sequence.		sequence.
	The first and second sub-fields give the start and stop times for the		The first and second sub-fields give the start and stop times for the
	session respectively. These values are the decimal representation of		session respectively. These values are the decimal representation of
	Network Time Protocol (NTP) time values in seconds [7]. To convert		Network Time Protocol (NTP) time values in seconds [7]. To convert
	these values to UNIX time, subtract decimal 2208988800.		these values to UNIX time, subtract decimal 2208988800.
	NTP timestamps are 64 bit values which wrap sometime in the year		NTP timestamps are 64 bit values which wrap sometime in the year
	2036. Since SDP uses an arbitrary length decimal representation,		2036. Since SDP uses an arbitrary length decimal representation,
	skipping to change at page 16, line 44		skipping to change at page 16, line 44
	r=<repeat-interval> <active duration> <offsets from start-time>		r=<repeat-interval> <active duration> <offsets from start-time>
	"r=" fields specify repeat times for a session. For example, if a		"r=" fields specify repeat times for a session. For example, if a
	session is active at 10am on Monday and 11am on Tuesday for one hour		session is active at 10am on Monday and 11am on Tuesday for one hour
	each week for three months, then the <start-time> in the		each week for three months, then the <start-time> in the
	corresponding "t=" field would be the NTP representation of 10am on		corresponding "t=" field would be the NTP representation of 10am on
	the first Monday, the <repeat interval> would be 1 week, the <active		the first Monday, the <repeat interval> would be 1 week, the <active
	duration> would be 1 hour, and the offsets would be zero and 25		duration> would be 1 hour, and the offsets would be zero and 25
	hours. The corresponding "t=" field stop time would be the NTP		hours. The corresponding "t=" field stop time would be the NTP
	representation of the end of the last session three months later. By		representation of the end of the last session three months later. By
	default all fields are in seconds, so the "r=" and "t=" fields might		default all fields are in seconds, so the "r=" and "t=" fields
			might
	be:		be:
	t=3034423619 3042462419		t=3034423619 3042462419
	r=604800 3600 0 90000		r=604800 3600 0 90000
	To make description more compact, times may also be given in units of		To make description more compact, times may also be given in units of
	days, hours or minutes. The syntax for these is a number immediately		days, hours or minutes. The syntax for these is a number immediately
	followed by a single case-sensitive character. Fractional units are		followed by a single case-sensitive character. Fractional units are
	not allowed - a smaller unit should be used instead. The following		not allowed - a smaller unit should be used instead. The following
	unit specification characters are allowed:		unit specification characters are allowed:
	skipping to change at page 17, line 48		skipping to change at page 17, line 48
	list of these adjustment times and offsets from the base time.		list of these adjustment times and offsets from the base time.
	An example might be:		An example might be:
	z=2882844526 -1h 2898848070 0		z=2882844526 -1h 2898848070 0
	This specifies that at time 2882844526 the time base by which the		This specifies that at time 2882844526 the time base by which the
	session's repeat times are calculated is shifted back by 1 hour, and		session's repeat times are calculated is shifted back by 1 hour, and
	that at time 2898848070 the session's original time base is restored.		that at time 2898848070 the session's original time base is restored.
	Adjustments are always relative to the specified start time - they		Adjustments are always relative to the specified start time - they
	are not cumulative. Adjustments apply to all "t=" and "r=" lines in		are not cumulative. Adjustments apply to all "t=" and "r=" lines
			in
	a session description.		a session description.
	If a session is likely to last several years, it is expected that the		If a session is likely to last several years, it is expected that the
	session announcement will be modified periodically rather than		session announcement will be modified periodically rather than
	transmit several years worth of adjustments in one session		transmit several years worth of adjustments in one session
	announcement.		announcement.
	5.12 Encryption Keys ("k=")		5.12 Encryption Keys ("k=")
	k=<method>		k=<method>
	skipping to change at page 21, line 16		skipping to change at page 21, line 16
	m=<media> <port> <proto> <fmt>		m=<media> <port> <proto> <fmt>
	A session description may contain a number of media descriptions.		A session description may contain a number of media descriptions.
	Each media description starts with an "m=" field, and is terminated		Each media description starts with an "m=" field, and is terminated
	by either the next "m=" field or by the end of the session		by either the next "m=" field or by the end of the session
	description. A media field has several sub-fields.		description. A media field has several sub-fields.
	The first sub-field ("<media>") is the media type. Currently defined		The first sub-field ("<media>") is the media type. Currently defined
	media are "audio", "video", "text", "application", "data" and		media are "audio", "video", "text", "application", "data" and
	"control", though this list may be extended in future. The		"control", though this list may be extended in future (see Section
	difference between "application" and "data" is that the former is a		9). The difference between "application" and "data" is that the
	media flow such as whiteboard information, and the latter is		former is a media flow such as whiteboard information, and the latter
	bulk-data transfer such as multicasting of program executables which		is bulk-data transfer such as multicasting of program executables
	will not typically be displayed to the user. "control" is used to		which will not typically be displayed to the user. "control" is used
	specify an additional conference control channel for the session.		to specify an additional conference control channel for the session.
	The second sub-field ("<port>") is the transport port to which the		The second sub-field ("<port>") is the transport port to which the
	media stream is sent. The meaning of the transport port depends on		media stream is sent. The meaning of the transport port depends on
	the network being used as specified in the relevant "c=" field, and		the network being used as specified in the relevant "c=" field, and
	on the transport protocol defined in the third sub-field. Other		on the transport protocol defined in the third sub-field. Other
	ports used by the media application (such as the RTCP port [12]) MAY		ports used by the media application (such as the RTCP port [12]) MAY
	be derived algorithmically from the base media port or MAY be		be derived algorithmically from the base media port or MAY be
	specified in a separate attribute (e.g. "a=rtcp:" as defined in		specified in a separate attribute (e.g. "a=rtcp:" as defined in
	[14]).		[14]).
	skipping to change at page 22, line 6		skipping to change at page 22, line 6
	m=video 49170/2 RTP/AVP 31		m=video 49170/2 RTP/AVP 31
	would specify that ports 49170 and 49171 form one RTP/RTCP pair and		would specify that ports 49170 and 49171 form one RTP/RTCP pair and
	49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the		49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the
	transport protocol and 31 is the format (see below). If non-		transport protocol and 31 is the format (see below). If non-
	contiguous ports are required, they must be signalled using a		contiguous ports are required, they must be signalled using a
	separate attribute (e.g. "a=rtcp:" as defined in [14]).		separate attribute (e.g. "a=rtcp:" as defined in [14]).
	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 port		ports are specified in the "m=" field, a one-to-one mapping from
			port
	to the corresponding address is implied. For example:		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 third sub-field ("<proto>") is the transport protocol. The		The third sub-field ("<proto>") is the transport protocol. The
	transport protocol values are dependent on the address type field in		transport protocol values are dependent on the address type field in
	the "c=" fields. Thus a "c=" field of IP4 defines that the transport		the "c=" fields. Thus a "c=" field of IP4 defines that the
			transport
	protocol runs over IP4. For IP4, it is normally expected that most		protocol runs over IP4. For IP4, it is normally expected that most
	media traffic will be carried as RTP over UDP. The following		media traffic will be carried as RTP over UDP. The following
	transport protocols are defined, but may be extended through		transport protocols are defined, but may be extended through
	registration of new protocols with IANA (see Section 9):		registration of new protocols with IANA (see Section 9):
	RTP/AVP - the IETF's Realtime Transport Protocol using the		RTP/AVP - the IETF's Realtime Transport Protocol using the
	Audio/Video profile carried over UDP.		Audio/Video profile carried over UDP.
	udp - User Datagram Protocol		udp - User Datagram Protocol
	TCP - Transmission Control Protocol
	If an application uses a single combined proprietary media format and		If an application uses a single combined proprietary media format and
	transport protocol over UDP, then simply specifying the transport		transport protocol over UDP, then simply specifying the transport
	protocol as udp and using the format field to distinguish the		protocol as udp and using the format field to distinguish the
	combined protocol is recommended. If a transport protocol is used		combined protocol is recommended. If a transport protocol is used
	over UDP to carry several distinct media types that need to be		over UDP to carry several distinct media types that need to be
	distinguished by a session directory, then specifying the transport		distinguished by a session directory, then specifying the transport
	protocol and media format separately is necessary. RTP is an example		protocol and media format separately is necessary. RTP is an example
	of a transport-protocol that carries multiple payload formats that		of a transport-protocol that carries multiple payload formats that
	must be distinguished by the session directory for it to know how to		must be distinguished by the session directory for it to know how to
	skipping to change at page 25, line 43		skipping to change at page 25, line 42
	size. This attribute is probably only meaningful for audio		size. This attribute is probably only meaningful for audio
	data, but may be used with other media types if it makes		data, but may be used with other media types if it makes
	sense. It is a media attribute, and is not dependent on		sense. It is a media attribute, and is not dependent on
	charset. Note that this attribute was introduced after RFC		charset. Note that this attribute was introduced after RFC
	2327, and non updated implementations will ignore this		2327, and non updated implementations will ignore this
	attribute.		attribute.
	a=rtpmap:<payload type> <encoding name>/<clock rate>		a=rtpmap:<payload type> <encoding name>/<clock rate>
	[/<encoding parameters>]		[/<encoding parameters>]
	See Section 5.14. This may be a session or media attribute		See Section 5.14. This is a media level attribute that is not
	and is not dependent on charset.		dependent on charset.
	a=recvonly		a=recvonly
	This specifies that the tools should be started in receive		This specifies that the tools should be started in receive
	only mode where applicable. It can be either a session or		only mode where applicable. It can be either a session or
	media attribute, and is not dependent on charset. Note that		media attribute, and is not dependent on charset. Note that
	recvonly applies to the media only, not to any associated		recvonly applies to the media only, not to any associated
	control protocol (e.g. an RTP based system in recvonly mode		control protocol (e.g. an RTP based system in recvonly mode
	SHOULD still send RTCP packets).		SHOULD still send RTCP packets).
	skipping to change at page 31, line 50		skipping to change at page 31, line 50
	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.
	9. IANA Considerations		9. IANA Considerations
	9.1 The "application/sdp" media type		9.1 The "application/sdp" media type
	One new MIME type is to be registered, as defined below. This updates		One MIME type is to be registered, as defined below. This updates the
	the previous definition from RFC 2327.		previous definition from RFC 2327.
	To: ietf-types@iana.org		To: ietf-types@iana.org
	Subject: Registration of MIME media type application/sdp		Subject: Registration of MIME media type application/sdp
	MIME media type name: application		MIME media type name: application
	MIME subtype name: sdp		MIME subtype name: sdp
	Required parameters: None.		Required parameters: None.
	skipping to change at page 33, line 19		skipping to change at page 33, line 19
	The set of media types is intended to be small and SHOULD NOT be		The set of media types is intended to be small and SHOULD NOT be
	extended except under rare circumstances. The same rules should		extended except under rare circumstances. The same rules should
	apply for media names as for top-level MIME content types, and where		apply for media names as for top-level MIME content types, and where
	possible the same name should be registered for SDP as for MIME. For		possible the same name should be registered for SDP as for MIME. For
	media other than existing MIME top-level content types, a		media other than existing MIME top-level content types, a
	standards-track RFC MUST be produced for a new top-level content type		standards-track RFC MUST be produced for a new top-level content type
	to be registered, and the registration MUST provide good		to be registered, and the registration MUST provide good
	justification why no existing media name is appropriate (the		justification why no existing media name is appropriate (the
	"Standards Action" policy of RFC 2434 [5].		"Standards Action" policy of RFC 2434 [5].
			This memo registers the media types "audio", "video", "text",
			"application", "data" and "control".
	9.2.2 Transport protocols ("proto")		9.2.2 Transport protocols ("proto")
	The "proto" field describes the transport protocol used. This SHOULD		The "proto" field describes the transport protocol used. This SHOULD
	reference a standards-track protocol RFC. This memo registers three		reference a standards-track protocol RFC. This memo registers three
	values: "RTP/AVP" is a reference to RTP [12] used under the RTP		values: "RTP/AVP" is a reference to RTP [12] used under the RTP
	Profile for Audio and Video Conferences with Minimal Control [13]		Profile for Audio and Video Conferences with Minimal Control [13]
	running over UDP/IP; "TCP" denotes an unspecified format over TCP;		running over UDP/IP and "udp" indicates an unspecified format over
	and "udp" indicates an unspecified format over UDP.		UDP.
	New transport protocols MAY be registered with IANA. Registrations		New transport protocols MAY be registered with IANA. Registrations
	MUST reference an RFC describing the protocol. Such an RFC MAY be		MUST reference an RFC describing the protocol. Such an RFC MAY be
	Experimental or Informational, although it is preferable if it is		Experimental or Informational, although it is preferable if it is
	Standards-Track. Registrations MUST also define the rules by which		Standards-Track. Registrations MUST also define the rules by which
	their "fmt" namespace is managed (see below).		their "fmt" namespace is managed (see below).
	9.2.3 Media formats ("fmt")		9.2.3 Media formats ("fmt")
	Each transport protocol, defined by the "proto" field, has an		Each transport protocol, defined by the "proto" field, has an
	skipping to change at page 33, line 49		skipping to change at page 34, line 5
	that might want to be transported in a multimedia session.		that might want to be transported in a multimedia session.
	RTP payload formats under the "RTP/AVP" protocol that have been		RTP payload formats under the "RTP/AVP" protocol that have been
	assigned static payload types MUST use the static payload type as		assigned static payload types MUST use the static payload type as
	their "fmt" value. For payload formats under "RTP/AVP" that have a		their "fmt" value. For payload formats under "RTP/AVP" that have a
	dynamic payload type number, the dynamic payload type number is given		dynamic payload type number, the dynamic payload type number is given
	as the "fmt" and an additional "rtpmap" attribute specifies the		as the "fmt" and an additional "rtpmap" attribute specifies the
	format name and parameters as defined by the MIME type registration		format name and parameters as defined by the MIME type registration
	for the payload format.		for the payload format.
	For "TCP" and "udp" protocols, new formats SHOULD be registered. Use		For the "udp" protocol, new formats SHOULD be registered. Use of an
	of an existing MIME subtype for the format is encouraged. If no MIME		existing MIME subtype for the format is encouraged. If no MIME
	subtype exists, it is RECOMMENDED that a suitable one is registered		subtype exists, it is RECOMMENDED that a suitable one is registered
	through the IETF process (RFC 2048) by production of, or reference		through the IETF process (RFC 2048) by production of, or reference
	to, a standards-track RFC. If a MIME subtype is for some reason		to, a standards-track RFC. If a MIME subtype is for some reason
	inappropriate, an RFC publication describing the format MUST be		inappropriate, an RFC publication describing the format MUST be
	referenced in the registration, but it may be Informational or		referenced in the registration, but it may be Informational or
	Experimental if the protocol is not deemed to be of widespread		Experimental if the protocol is not deemed to be of widespread
	deployment.		deployment.
	For other protocols, formats MAY be registered according to the rules		For other protocols, formats MAY be registered according to the rules
	of the associated "proto" specification.		of the associated "proto" specification.
	skipping to change at page 35, line 12		skipping to change at page 35, line 14
	names ("att-field" values), with definitions as in Section 6 of this		names ("att-field" values), with definitions as in Section 6 of this
	memo (these definitions update those in RFC 2327):		memo (these definitions update those in RFC 2327):
	Name | Session or Media level? | Dependent on charset?		Name | Session or Media level? | Dependent on charset?
	----------+-------------------------+----------------------		----------+-------------------------+----------------------
	cat | Session | No		cat | Session | No
	keywds | Session | Yes		keywds | Session | Yes
	tool | Session | No		tool | Session | No
	ptime | Media | No		ptime | Media | No
	maxptime | Media | No		maxptime | Media | No
	rtpmap | Either | No		rtpmap | Media | No
	recvonly | Either | No		recvonly | Either | No
	sendrecv | Either | No		sendrecv | Either | No
	sendonly | Either | No		sendonly | Either | No
	inactive | Either | No		inactive | Either | No
	orient | Media | No		orient | Media | No
	type | Session | No		type | Session | No
	charset | Session | No		charset | Session | No
	sdplang | Either | No		sdplang | Either | No
	lang | Either | No		lang | Either | No
	framerate | Media | No		framerate | Media | No
	skipping to change at page 37, line 28		skipping to change at page 37, line 29
	connection-field		connection-field
	bandwidth-fields		bandwidth-fields
	time-fields		time-fields
	key-field		key-field
	attribute-fields		attribute-fields
	media-descriptions		media-descriptions
	proto-version = "v=" 1*DIGIT CRLF		proto-version = "v=" 1*DIGIT CRLF
	;this memo describes version 0		;this memo describes version 0
	origin-field = "o=" username SP sess-id SP sess-version SP		origin-field = "o=" username SP sess-id SP sess-version
			SP
	nettype SP addrtype SP unicast-address CRLF		nettype SP addrtype SP unicast-address CRLF
	session-name-field = "s=" text CRLF		session-name-field = "s=" text CRLF
	information-field = ["i=" text CRLF]		information-field = ["i=" text CRLF]
	uri-field = ["u=" uri CRLF]		uri-field = ["u=" uri CRLF]
	email-fields = *("e=" email-address CRLF)		email-fields = *("e=" email-address CRLF)
	skipping to change at page 40, line 19		skipping to change at page 40, line 22
	media = token		media = token
	;typically "audio", "video", "text",		;typically "audio", "video", "text",
	;"application" or "data"		;"application" or "data"
	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
	/ token		/ token
	;typically "RTP/AVP", "udp" or "tcp"		;typically "RTP/AVP" or "udp"
	port = 1*DIGIT		port = 1*DIGIT
	;should be either "0" or in the range "1024"		;should be either "0" or in the range "1024"
	;to "65535" inclusive for UDP based media		;to "65535" inclusive for UDP based media
	;(a value of "0" is used to signal special		;(a value of "0" is used to signal special
	;conditions in some uses of SDP)		;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		multicast-address = IP4-multicast / IP6-multicast
	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 )
	skipping to change at page 41, line 31		skipping to change at page 41, line 34
	;default is to interpret this as UTF8 text.		;default is to interpret this as UTF8 text.
	;ISO 8859-1 requires "a=charset:ISO-8859-1"		;ISO 8859-1 requires "a=charset:ISO-8859-1"
	;session-level attribute to be used		;session-level attribute to be used
	byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF)		byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF)
	;any byte except NUL, CR or LF		;any byte except NUL, CR or LF
	non-ws-string = 1*(VCHAR/%x80-FF)		non-ws-string = 1*(VCHAR/%x80-FF)
	;string of visible characters		;string of visible characters
	token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39		token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E /
			%x30-39
	/ %x41-5A / %x5E-7E		/ %x41-5A / %x5E-7E
	token = 1*(token-char)		token = 1*(token-char)
	email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF		email-safe =
			%x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF
	;any byte except NUL, CR, LF, or the quoting		;any byte except NUL, CR, LF, or the quoting
	;characters ()<>		;characters ()<>
	integer = POS-DIGIT *DIGIT		integer = POS-DIGIT *DIGIT
	; generic sub-rules: primitives		; generic sub-rules: primitives
	alpha-numeric = ALPHA / DIGIT		alpha-numeric = ALPHA / DIGIT
	POS-DIGIT = %x31-39 ; 1 - 9		POS-DIGIT = %x31-39 ; 1 - 9
End of changes. 33 change blocks.
	56 lines changed or deleted		93 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/