draft-ietf-mmusic-sdp-new-08.txt		draft-ietf-mmusic-sdp-new-09.txt
	Internet Engineering Task Force MMUSIC WG		Internet Engineering Task Force MMUSIC WG
	INTERNET-DRAFT Mark Handley/ACIRI		INTERNET-DRAFT Mark Handley/ACIRI
	draft-ietf-mmusic-sdp-new-08.txt Van Jacobson/Packet Design		draft-ietf-mmusic-sdp-new-09.txt Van Jacobson/Packet Design
	Colin Perkins/ISI		Colin Perkins/ISI
	19 April 2002		17 May 2002
	Expires: October 2002		Expires: November 2002
	SDP: Session Description Protocol		SDP: Session Description Protocol
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with all		This document is an Internet-Draft and is in full conformance with all
	provisions of Section 10 of RFC2026.		provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering Task		Internet-Drafts are working documents of the Internet Engineering Task
	Force (IETF), its areas, and its working groups. Note that other groups		Force (IETF), its areas, and its working groups. Note that other groups
	skipping to change at page 2, line 9		skipping to change at page 2, line 9
	This memo defines the Session Description Protocol (SDP). SDP		This memo defines the Session Description Protocol (SDP). SDP
	is intended for describing multimedia sessions for the		is intended for describing multimedia sessions for the
	purposes of session announcement, session invitation, and		purposes of session announcement, session invitation, and
	other forms of multimedia session initiation.		other forms of multimedia session initiation.
	1. Introduction		1. Introduction
	On the Internet multicast backbone (Mbone), a session directory tool is		On the Internet multicast backbone (Mbone), a session directory tool is
	used to advertise multimedia conferences and communicate the conference		used to advertise multimedia conferences and communicate the conference
	addresses and conference tool-specific information necessary for		addresses and media-specific information necessary for participation.
	participation. This document defines a session description protocol for		This memo defines a session description protocol for this purpose, and
	this purpose, and for general real-time multimedia session description		for general real-time multimedia session description purposes; it does
	purposes. This memo does not describe multicast address allocation or		not describe multicast address allocation or the distribution of SDP
	the distribution of SDP messages. These are described in accompanying		messages.
	drafts. SDP is not intended for negotiation of media encodings.
	2. Background		2. Background
	The Mbone is the part of the Internet that supports IP multicast, and		The Mbone is the part of the Internet that supports IP multicast, and
	thus permits efficient many-to-many communication. It is used		thus permits efficient many-to-many communication. It is used
	extensively for multimedia conferencing. Such conferences usually have		extensively for multimedia conferencing. Such conferences usually have
	the property that tight coordination of conference membership is not		the property that tight coordination of conference membership is not
	necessary; to receive a conference, a user at an Mbone site only has to		necessary; to receive a conference, a user at an Mbone site only has to
	know the conference's multicast group address and the UDP ports for the		know the conference's multicast group address and the UDP ports for the
	conference data streams.		conference data streams.
	skipping to change at page 4, line 13		skipping to change at page 4, line 13
	session description format for such announcements.		session description format for such announcements.
	4.2. Session Initiation		4.2. Session Initiation
	The Session Initiation Protocol, SIP [11] is an application-layer		The Session Initiation Protocol, SIP [11] is an application-layer
	control protocol for creating, modifying and terminating sessions such		control protocol for creating, modifying and terminating sessions such
	as Internet multimedia conferences, Internet telephone calls and		as Internet multimedia conferences, Internet telephone calls and
	multimedia distribution. The SIP messages used to create sessions carry		multimedia distribution. The SIP messages used to create sessions carry
	session descriptions which allow participants to agree on a set of		session descriptions which allow participants to agree on a set of
	compatible media types. These session descriptions are commonly		compatible media types. These session descriptions are commonly
	formatted using SDP.		formatted using SDP. When used with SIP, the offer/answer model [14]
			provides a framework for negotiation using SDP.
	4.3. Streaming media		4.3. Streaming media
	The Real Time Streaming Protocol, RTSP [12], is an application-level		The Real Time Streaming Protocol, RTSP [12], is an application-level
	protocol for control over the delivery of data with real-time		protocol for control over the delivery of data with real-time
	properties. RTSP provides an extensible framework to enable controlled,		properties. RTSP provides an extensible framework to enable controlled,
	on-demand delivery of real-time data, such as audio and video. It is		on-demand delivery of real-time data, such as audio and video. An RTSP
	necessary for RTSP to convey a description of the session to be		client and server negotiate an appropriate set of parameters for media
	controlled. SDP is often used for this purpose.		delivery, partially using SDP syntax to describe those parameters.
	4.4. Email and the World Wide Web		4.4. Email and the World Wide Web
	Alternative means of conveying session descriptions include electronic		Alternative means of conveying session descriptions include electronic
	mail and the World Wide Web. For both email and WWW distribution, the		mail and the World Wide Web. For both email and WWW distribution, the
	use of the MIME content type ``application/sdp'' MUST be used. This		use of the MIME content type ``application/sdp'' MUST be used. This
	enables the automatic launching of applications for participation in the		enables the automatic launching of applications for participation in the
	session from the WWW client or mail reader in a standard manner.		session from the WWW client or mail reader in a standard manner.
	Note that announcements of multicast sessions made only via email or the		Note that announcements of multicast sessions made only via email or the
	skipping to change at page 4, line 48		skipping to change at page 5, line 4
	5. Requirements and Recommendations		5. Requirements and Recommendations
	The purpose of SDP is to convey information about media streams in		The purpose of SDP is to convey information about media streams in
	multimedia sessions to allow the recipients of a session description to		multimedia sessions to allow the recipients of a session description to
	participate in the session. SDP is primarily intended for use in an		participate in the session. SDP is primarily intended for use in an
	internetwork, although it is sufficiently general that it can describe		internetwork, although it is sufficiently general that it can describe
	conferences in other network environments.		conferences in other network environments.
	A multimedia session, for these purposes, is defined as a set of media		A multimedia session, for these purposes, is defined as a set of media
	streams that exist for some duration of time. Media streams can be
			streams that exist for some duration of time. Media streams can be
	many-to-many. The times during which the session is active need not be		many-to-many. The times during which the session is active need not be
	continuous.		continuous.
	Thus far, multicast based sessions on the Internet have differed from		Thus far, multicast based sessions on the Internet have differed from
	many other forms of conferencing in that anyone receiving the traffic		many other forms of conferencing in that anyone receiving the traffic
	can join the session (unless the session traffic is encrypted). In such		can join the session (unless the session traffic is encrypted). In such
	an environment, SDP serves two primary purposes. It is a means to		an environment, SDP serves two primary purposes. It is a means to
	communicate the existence of a session, and is a means to convey		communicate the existence of a session, and is a means to convey
	sufficient information to enable joining and participating in the		sufficient information to enable joining and participating in the
	session. In a unicast environment, only the latter purpose is likely to		session. In a unicast environment, only the latter purpose is likely to
	skipping to change at page 5, line 35		skipping to change at page 5, line 36
	o Information to receive those media (addresses, ports, formats and so		o Information to receive those media (addresses, ports, formats and so
	on)		on)
	As resources necessary to participate in a session may be limited, some		As resources necessary to participate in a session may be limited, some
	additional information may also be desirable:		additional information may also be desirable:
	o Information about the bandwidth to be used by the conference		o Information about the bandwidth to be used by the conference
	o Contact information for the person responsible for the session		o Contact information for the person responsible for the session
	In general, SDP must convey sufficient information to be able to join a		In general, SDP must convey sufficient information to enable
	session (with the possible exception of encryption keys) and to announce		applications to join a session (with the possible exception of
	the resources to be used to non-participants that may need to know.		encryption keys) and to announce the resources to be used to non-
			participants that may need to know.
	5.1. Media Information		5.1. Media Information
	SDP includes:		SDP includes:
	o The type of media (video, audio, etc)		o The type of media (video, audio, etc)
	o The transport protocol (RTP/UDP/IP, H.320, etc)		o The transport protocol (RTP/UDP/IP, H.320, etc)
	o The format of the media (H.261 video, MPEG video, etc)		o The format of the media (H.261 video, MPEG video, etc)
	For an IP multicast session, the following are also conveyed:		For an IP multicast session, the following are also conveyed:
	o Multicast address for media		o Multicast address for media
	o Transport Port for media		o Transport port for media
	This address and port are the destination address and destination port		This address and port are the destination address and destination port
	of the multicast stream, whether being sent, received, or both.		of the multicast stream, whether being sent, received, or both.
	For an IP unicast session, the following are conveyed:		For an IP unicast session, the following are conveyed:
	o Remote address for media		o Remote address for media
	o Transport port for contact address		o Transport port for media
	The semantics of this address and port depend on the media and transport		The semantics of this address and port depend on the media and transport
	protocol defined. By default, this is the remote address and remote		protocol defined. By default, this is the remote address and remote port
	port to which data is sent, and the remote address and local port on		to which data is sent, however some media types may redefine this
	which to receive data. However, some media may define to use these to		behaviour.
	establish a control channel for the actual media flow.
	5.2. Timing Information		5.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.		they are bounded, they may be only active at specific times.
	SDP can convey:		SDP can convey:
	o An arbitrary list of start and stop times bounding the session		o An arbitrary list of start and stop times bounding the session
	skipping to change at page 6, line 50		skipping to change at page 7, line 4
	It is possible to create both public sessions and private sessions. SDP		It is possible to create both public sessions and private sessions. SDP
	itself does not distinguish between these: private sessions are		itself does not distinguish between these: private sessions are
	typically conveyed by encrypting the session description during		typically conveyed by encrypting the session description during
	distribution. The details of how encryption is performed are dependent		distribution. The details of how encryption is performed are dependent
	on the mechanism used to convey SDP - e.g. mechanisms are defined for		on the mechanism used to convey SDP - e.g. mechanisms are defined for
	SDP transported using SAP [4] and SIP [11].		SDP transported using SAP [4] and SIP [11].
	If a session announcement is private it is possible to use that private		If a session announcement is private it is possible to use that private
	announcement to convey encryption keys necessary to decode each of the		announcement to convey encryption keys necessary to decode each of the
	media in a conference, including enough information to know which
			media in a conference, including enough information to know which
	encryption scheme is used for each media.		encryption scheme is used for each media.
	5.4. Obtaining Further Information about a Session		5.4. Obtaining Further Information about a Session
	A session description should convey enough information to decide whether		A session description should convey enough information to decide whether
	or not to participate in a session. SDP may include additional pointers		or not to participate in a session. SDP may include additional pointers
	in the form of Universal Resources Identifiers (URIs) for more		in the form of Universal Resources Identifiers (URIs) for more
	information about the session.		information about the session.
	5.5. Categorisation		5.5. Categorisation
	skipping to change at page 7, line 37		skipping to change at page 7, line 38
	allows other character sets such as ISO 8859-1 to be used when desired.		allows other character sets such as ISO 8859-1 to be used when desired.
	Internationalization only applies to free-text fields (session name and		Internationalization only applies to free-text fields (session name and
	background information), and not to SDP as a whole.		background information), and not to SDP as a whole.
	6. SDP Specification		6. SDP Specification
	SDP session descriptions are entirely textual using the ISO 10646		SDP session descriptions are entirely textual using the ISO 10646
	character set in UTF-8 encoding. SDP field names and attribute names		character set in UTF-8 encoding. SDP field names and attribute names
	use only the US-ASCII subset of UTF-8, but textual fields and attribute		use only the US-ASCII subset of UTF-8, but textual fields and attribute
	values MAY use the full ISO 10646 character set. The textual form, as		values MAY use the full ISO 10646 character set. The textual form, as
	opposed to a binary encoding such as ASN/1 or XDR, was chosen to enhance		opposed to a binary encoding such as ASN.1 or XDR, was chosen to enhance
	portability, to enable a variety of transports to be used (e.g, session		portability, to enable a variety of transports to be used (e.g, session
	description in a MIME email message) and to allow flexible, text-based		description in a MIME email message) and to allow flexible, text-based
	toolkits (e.g., Tcl/Tk ) to be used to generate and to process session		toolkits (e.g., Tcl/Tk ) to be used to generate and to process session
	descriptions. However, since SDP may be used in environments where the		descriptions. However, since SDP may be used in environments where the
	maximum permissable size of a session description is limited (e.g. SAP		maximum permissable size of a session description is limited (e.g. SAP
	announcements; SIP transported in UDP), the encoding is deliberately		announcements; SIP transported in UDP), the encoding is deliberately
	compact. Also, since announcements may be transported via very		compact. Also, since announcements may be transported via very
	unreliable means or damaged by an intermediate caching server, the		unreliable means or damaged by an intermediate caching server, the
	encoding was designed with strict order and formatting rules so that		encoding was designed with strict order and formatting rules so that
	most errors would result in malformed announcements which could be		most errors would result in malformed announcements which could be
	detected easily and discarded. This also allows rapid discarding of
			detected easily and discarded. This also allows rapid discarding of
	encrypted announcements for which a receiver does not have the correct		encrypted announcements for which a receiver does not have the correct
	key.		key.
	An SDP session description consists of a number of lines of text of the		An SDP session description consists of a number of lines of text of the
	form		form:
	<type>=<value>		<type>=<value>
	<type> is always exactly one character and is case-significant. <value>
	is a structured text string whose format depends on <type>. It also		where <type> MUST be exactly one case-significant character and <value>
	will be case-significant unless a specific field defines otherwise.		is structured text whose format depends on <type>. In general <value>
	Whitespace MUST NOT be used either side of the `=' sign. In general		is either a number of fields delimited by a single space character, or a
	<value> is either a number of fields delimited by a single space		free format string. Whitespace MUST NOT be used either side of the `='
	character or a free format string.		sign.
	A session description consists of a session-level section followed by		A session description consists of a session-level section followed by
	zero or more media-level sections. The session-level part starts with a		zero or more media-level sections. The session-level part starts with a
	`v=' line and continues to the first media-level section. The media		`v=' line and continues to the first media-level section. The media
	description starts with an `m=' line and continues to the next media		description starts with an `m=' line and continues to the next media
	description or end of the whole session description. In general,		description or end of the whole session description. In general,
	session-level values are the default for all media unless overridden by		session-level values are the default for all media unless overridden by
	an equivalent media-level value.		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
	skipping to change at page 10, line 6		skipping to change at page 10, line 6
	The connection (`c=') and attribute (`a=') information in the session-		The connection (`c=') and attribute (`a=') information in the session-
	level section applies to all the media of that session unless overridden		level section applies to all the media of that session unless overridden
	by connection information or an attribute of the same name in the media		by connection information or an attribute of the same name in the media
	description. For instance, in the example below, each media behaves as		description. For instance, in the example below, each media behaves as
	if it were given a `recvonly' attribute.		if it were given a `recvonly' attribute.
	An example SDP description is:		An example SDP description is:
	v=0		v=0
	o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4		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.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps		u=http://www.example.com/seminars/sdp.pdf
	e=mjh@isi.edu (Mark Handley)		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 31
	m=application 32416 udp wb		m=application 32416 udp wb
	a=orient:portrait		a=orient:portrait
	Text records such as the session name and information are octet strings		Text records such as the session name and information are octet strings
	which may contain any octet with the exceptions of 0x00 (Nul), 0x0a		which may contain any octet with the exceptions of 0x00 (Nul), 0x0a
	skipping to change at page 10, line 39		skipping to change at page 10, line 39
	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.
	There is no minor version number.		There is no minor version number.
	Origin		Origin
	o=<username> <session id> <version> <network type> <address type>		o=<username> <session id> <version> <network type> <address type>
	<address>		<address>
	The ``o='' field gives the originator of the session (their username and		The ``o='' field gives the originator of the session (her username and
	the address of the user's host) plus a session id and session version		the address of the user's host) plus a session id and session version
	number. <username> is the user's login on the originating host, or it		number. <username> is the user's login on the originating host, or it
	is ``-'' if the originating host does not support the concept of user		is ``-'' if the originating host does not support the concept of user
	ids. <username> MUST NOT contain spaces. <session id> is a numeric		ids. <username> MUST NOT contain spaces. <session id> is a numeric
	string such that the tuple of <username>, <session id>, <network type>,		string such that the tuple of <username>, <session id>, <network type>,
	<address type> and <address> form a globally unique identifier for the		<address type> and <address> form a globally unique identifier for the
	session. The method of session id allocation is up to the creating		session. The method of session id allocation is up to the creating
	tool, but it has been suggested that a Network Time Protocol (NTP)		tool, but it has been suggested that a Network Time Protocol (NTP)
	timestamp be used to ensure uniqueness [1]. <version> is a version		timestamp be used to ensure uniqueness [1]. <version> is a version
	number for this announcement. It is needed for proxy announcements to		number for this announcement. It is needed for proxy announcements to
	skipping to change at page 12, line 18		skipping to change at page 12, line 18
	for feedback and questions.		for feedback and questions.
	URI		URI
	u=<URI>		u=<URI>
	A URI is a Universal Resource Identifier as used by WWW clients. The URI		A URI is a Universal Resource Identifier as used by WWW clients. The URI
	should be a pointer to additional information about the conference. This		should be a pointer to additional information about the conference. This
	field is OPTIONAL, but if it is present it MUST be specified before the		field is OPTIONAL, but if it is present it MUST be specified before the
	first media field. No more than one URI field is allowed per session		first media field. No more than one URI field is allowed per session
	description		description.
	Email Address and Phone Number		Email Address and Phone Number
	e=<email address>		e=<email address>
	p=<phone number>		p=<phone number>
	These specify contact information for the person responsible for the		These specify contact information for the person responsible for the
	conference. This is not necessarily the same person that created the		conference. This is not necessarily the same person that created the
	conference announcement.		conference announcement.
	Inclusion of an email address or phone number is OPTIONAL. Note that the		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 phone		previous version of SDP specified that either an email field or a phone
	field MUST be specified, but this was widely ignored. The change brings		field MUST be specified, but this was widely ignored. The change brings
	the specification into line with common usage.		the specification into line with common usage.
	If these are present, they MUST be specified before the first media		If these are present, they MUST be specified before the first media
	field. More than one email or phone field can be given for a session		field. More than one email or phone field can be given for a session
	description.		description.
	Phone numbers should be given in the conventional international format -		Phone numbers SHOULD be given in the conventional international format -
	preceded by a ``+'' and the international country code. There must be a		preceded by a ``+'' and the international country code. There must be a
	space or a hyphen (``-'') between the country code and the rest of the		space or a hyphen (``-'') between the country code and the rest of the
	phone number. Spaces and hyphens may be used to split up a phone field		phone number. Spaces and hyphens may be used to split up a phone field
	to aid readability if desired. For example:		to aid readability if desired. For example:
	p=+44-171-380-7777 or p=+1 617 253 6011		p=+44-171-380-7777 or p=+1 617 555 6011
	Both email addresses and phone numbers can have an optional free text		Both email addresses and phone numbers can have an optional free text
	string associated with them, normally giving the name of the person who		string associated with them, normally giving the name of the person who
	may be contacted. This should be enclosed in parenthesis if it is		may be contacted. This should be enclosed in parenthesis if it is
	present. For example:		present. For example:
	e=mjh@isi.edu (Mark Handley)		e=j.doe@example.com (Jane Doe)
	The alternative RFC822 name quoting convention is also allowed for both		The alternative RFC822 name quoting convention is also allowed for both
	email addresses and phone numbers. For example,		email addresses and phone numbers. For example,
	e=Mark Handley <mjh@isi.edu>		e=Jane Doe <j.doe@example.com>
	The free text string SHOULD be in the ISO-10646 character set with UTF-8		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 the		encoding, or alternatively in ISO-8859-1 or other encodings if the
	appropriate charset session-level attribute is set.		appropriate charset session-level attribute is set.
	Connection Data		Connection Data
	c=<network type> <address type> <connection address>		c=<network type> <address type> <connection address>
	The ``c='' field contains connection data.		The ``c='' field contains connection data.
	A session announcement MUST contain either one ``c='' field in each		A session announcement MUST contain either one ``c='' field in each
	media description (see below) or a ``c='' field at the session-level.		media description (see below) or a ``c='' field at the session-level.
	It MAY contain a session-level ``c='' field and one additional ``c=''		It MAY contain a session-level ``c='' field and one additional ``c=''
	field per media description, in which case the per-media values override		field per media description, in which case the per-media values override
	the session-level settings for the relevant media.		the session-level settings for the respective media.
	The first sub-field is the network type, which is a text string giving		The first sub-field is the network type, which is a text string giving
	the type of network. Initially ``IN'' is defined to have the meaning		the type of network. Initially ``IN'' is defined to have the meaning
	``Internet''.		``Internet''.
	The second sub-field is the address type. This allows SDP to be used		The second sub-field is the address type. This allows SDP to be used
	for sessions that are not IP based. Currently only IP4 and IP6 are		for sessions that are not IP based. Currently only IP4 and IP6 are
	defined.		defined.
	The third sub-field is the connection address. Optional extra sub-		The third sub-field is the connection address. Optional extra sub-
	fields may be added after the connection address depending on the value		fields MAY be added after the connection address depending on the value
	of the <address type> field.		of the <address type> field.
	For IP4 and IP6 addresses, the connection address is defined as follows:		For IP4 and IP6 addresses, the connection address is defined 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 conference is not multicast, then		multicast group address. If the conference 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
	skipping to change at page 15, line 11		skipping to change at page 15, line 11
	c=IN IP6 FF15::101/3		c=IN IP6 FF15::101/3
	which is semantically equivalent to:		which is semantically equivalent to:
	c=IN IP6 FF15::101		c=IN IP6 FF15::101
	c=IN IP6 FF15::102		c=IN IP6 FF15::102
	c=IN IP6 FF15::103		c=IN IP6 FF15::103
	(remembering that the TTL field is not present in IPv6 multicast).		(remembering that the TTL field is not present in IPv6 multicast).
	Multiple addresses or ``c='' lines can only be specified on a per-		Multiple addresses or ``c='' lines MAY be specified on a per-media
	media basis, and not for a session-level ``c='' field.		basis. They MUST NOT be specified for a session-level ``c='' field.
	The slash notation described above MUST NOT be used for IP unicast		The slash notation described above MUST NOT be used for IP unicast
	addresses.		addresses.
	Bandwidth		Bandwidth
	b=<modifier>:<bandwidth-value>		b=<modifier>:<bandwidth-value>
	o This specifies the proposed bandwidth to be used by the session or		o This specifies the proposed bandwidth to be used by the session or
	media, and is OPTIONAL.		media, and is OPTIONAL.
	o <bandwidth-value> is in kilobits per second by default. Modifiers		o <bandwidth-value> is in kilobits per second by default. Modifiers
	may specify that alternative units are to be used (the modifiers		MAY specify that alternative units are to be used (the modifiers
	defined in this memo use the default units).		defined in this memo use the default units).
	o <modifier> is a single alphanumeric word giving the meaning of the		o <modifier> is a single alphanumeric word giving the meaning of the
	bandwidth figure.		bandwidth figure.
	o Two modifiers are initially defined:		o Two modifiers are initially defined:
	CT Conference Total: If the bandwidth of a session or media in a		CT Conference Total: If the bandwidth of a session or media in a
	session is different from the bandwidth implicit from the scope, a		session is different from the bandwidth implicit from the scope, a
	`b=CT:...' line should be supplied for the session giving the		`b=CT:...' line should be supplied for the session giving the
	skipping to change at page 18, line 9		skipping to change at page 18, line 9
	r=7d 1h 0 25h		r=7d 1h 0 25h
	Monthly and yearly repeats cannot be directly specified with a		Monthly and yearly repeats cannot be directly specified with a
	single SDP repeat time - instead separate "t" fields should be used		single SDP repeat time - instead separate "t" fields should be used
	to explicitly list the session times.		to explicitly list the session times.
	z=<adjustment time> <offset> <adjustment time> <offset> ....		z=<adjustment time> <offset> <adjustment time> <offset> ....
	o To schedule a repeated session which spans a change from daylight-		o To schedule a repeated session which spans a change from daylight-
	saving time to standard time or vice-versa, it is necessary to		saving time to standard time or vice-versa, it is necessary to
	specify offsets from the base repeat times. This is required because		specify offsets from the base time. This is required because
	different time zones change time at different times of day,		different time zones change time at different times of day,
	different countries change to or from daylight time on different		different countries change to or from daylight time on different
	dates, and some countries do not have daylight saving time at all.		dates, and some countries do not have daylight saving time at all.
	Thus in order to schedule a session that is at the same time winter		Thus in order to schedule a session that is at the same time winter
	and summer, it must be possible to specify unambiguously by whose		and summer, it must be possible to specify unambiguously by whose
	time zone a session is scheduled. To simplify this task for		time zone a session is scheduled. To simplify this task for
	receivers, we allow the sender to specify the NTP time that a time		receivers, we allow the sender to specify the NTP time that a time
	zone adjustment happens and the offset from the time when the		zone adjustment happens and the offset from the time when the
	session was first scheduled. The ``z'' field allows the sender to		session was first scheduled. The ``z'' field allows the sender to
	skipping to change at page 18, line 31		skipping to change at page 18, line 31
	time.		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		that at time 2898848070 the session's original time base is
	restored. Adjustments are always relative to the specified start		restored. Adjustments are always relative to the specified start
	time - they are not cumulative.		time - they are not cumulative. Adjustments apply to all ``t='' and
			``r='' lines in a session description.
	o If a session is likely to last several years, it is expected that		o If a session is likely to last several years, it is expected that
	the session announcement will be modified periodically rather than		the session announcement will be modified periodically rather than
	transmit several years worth of adjustments in one announcement.		transmit several years worth of adjustments in one announcement.
	Encryption Keys		Encryption Keys
	k=<method>		k=<method>
	k=<method>:<encryption key>		k=<method>:<encryption key>
	skipping to change at page 21, line 13		skipping to change at page 21, line 13
	and ``data'' is that the former is a media flow such as whiteboard		and ``data'' is that the former is a media flow such as whiteboard
	information, and the latter is bulk-data transfer such as		information, and the latter is bulk-data transfer such as
	multicasting of program executables which will not typically be		multicasting of program executables which will not typically be
	displayed to the user. ``control'' is used to specify an additional		displayed to the user. ``control'' is used to specify an additional
	conference control channel for the session.		conference control channel for the session.
	o The second sub-field is the transport port to which the media stream		o The second sub-field is the transport port to which the media stream
	will be sent. The meaning of the transport port depends on the		will be sent. The meaning of the transport port depends on the
	network being used as specified in the relevant ``c'' field and on		network being used as specified in the relevant ``c'' field and on
	the transport protocol defined in the third sub-field. Other ports		the transport protocol defined in the third sub-field. Other ports
	used by the media application (such as the RTCP port, see [2])		used by the media application (such as the RTCP port, see [2]) MAY
	should be derived algorithmically from the base media port.		be derived algorithmically from the base media port or MAY be
			specified in a separate attribute (e.g. ``a=rtcp:'' as defined in
			[15]).
	Note: For transports based on UDP, the value should be in the range		Note: For transports based on UDP, the value should be in the range
	1024 to 65535 inclusive. For RTP compliance it SHOULD be an even		1024 to 65535 inclusive. For RTP compliance it SHOULD be an even
	number.		number.
	For applications where hierarchically encoded streams are being sent		For applications where hierarchically encoded streams are being sent
	to a unicast address, it may be necessary to specify multiple		to a unicast address, it may be necessary to specify multiple
	transport ports. This is done using a similar notation to that used		transport ports. This is done using a similar notation to that used
	for IP multicast addresses in the ``c='' field:		for IP multicast addresses in the ``c='' field:
	skipping to change at page 22, line 7		skipping to change at page 22, line 10
	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.
	o The third sub-field is the transport protocol. The transport		o The third sub-field is the transport protocol. The transport
	protocol values are dependent on the address-type field in the		protocol values are dependent on the address-type field in the
	``c='' fields. Thus a ``c='' field of IP4 defines that the		``c='' fields. Thus a ``c='' field of IP4 defines that the
	transport protocol runs over IP4. For IP4, it is normally expected		transport protocol runs over IP4. For IP4, it is normally expected
	that most media traffic will be carried as RTP over UDP. The		that most media traffic will be carried as RTP over UDP. The
	following transport protocols are preliminarily defined, but may be		following transport protocols are defined, but may be extended
	extended through registration of new protocols with IANA:		through registration of new protocols with IANA (see Appendix B):
	- 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
	If an application uses a single combined proprietary media format		If an application uses a single combined proprietary media format
	and transport protocol over UDP, then simply specifying the		and transport protocol over UDP, then simply specifying the
	transport protocol as udp and using the format field to distinguish		transport protocol as udp and using the format field to distinguish
	the combined protocol is recommended. If a transport protocol is		the combined protocol is recommended. If a transport protocol is
	skipping to change at page 22, line 45		skipping to change at page 22, line 48
	be defined in the future, their profiles will be specified in the		be defined in the future, their profiles will be specified in the
	same way. For example, the protocol field ``RTP/XYZ'' would specify		same way. For example, the protocol field ``RTP/XYZ'' would specify
	RTP operating under a profile whose short name is ``XYZ''.		RTP operating under a profile whose short name is ``XYZ''.
	o The fourth and subsequent sub-fields are media formats. For audio		o The fourth and subsequent sub-fields are media formats. For audio
	and video, these SHOULD reference a MIME sub-type describing the		and video, these SHOULD reference a MIME sub-type describing the
	format under the `audio' and `video' top-level MIME types.		format under the `audio' and `video' top-level MIME types.
	When a list of payload formats is given, this implies that all of		When a list of payload formats is given, this implies that all of
	these formats may be used in the session, but the first of these		these formats may be used in the session, but the first of these
	formats is the default format for the session.		formats SHOULD be used as the default format for the session.
	For media whose transport protocol is not RTP or UDP the format		For media whose transport protocol is not RTP or UDP the format
	field is protocol specific. Such formats should be defined in an		field is protocol specific. Such formats should be defined in an
	additional specification document.		additional specification document.
	For media whose transport protocol is RTP, SDP can be used to		For media whose transport protocol is RTP, SDP can be used to
	provide a dynamic binding of media encoding to RTP payload type.		provide a dynamic binding of media encoding to RTP payload type. The
	The encoding names in the RTP AV Profile do not specify unique audio		encoding names in the RTP AV Profile do not specify unique audio
	encodings (in terms of clock rate and number of audio channels), and		encodings (in terms of clock rate and number of audio channels), and
	so they are not used directly in SDP format fields. Instead, the		so they are not used directly in SDP format fields. Instead, the
	payload type number should be used to specify the format for static		payload type number should be used to specify the format for static
	payload types and the payload type number along with additional		payload types and the payload type number along with additional
	encoding information should be used for dynamically allocated		encoding information should be used for dynamically allocated
	payload types.		payload types.
	An example of a static payload type is u-law PCM coded single		An example of a static payload type is u-law PCM coded single
	channel audio sampled at 8kHz. This is completely defined in the		channel audio sampled at 8kHz. This is completely defined in the
	RTP Audio/Video profile as payload type 0, so the media field for		RTP Audio/Video profile as payload type 0, so the media field for
	skipping to change at page 23, line 40		skipping to change at page 23, line 40
	The general form of an rtpmap attribute is:		The general form of an rtpmap attribute is:
	a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding parameters>]		a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding parameters>]
	For audio streams, <encoding parameters> may specify the number of		For audio streams, <encoding parameters> may specify the number of
	audio channels. This parameter may be omitted if the number of		audio channels. This parameter may be omitted if the number of
	channels is one provided no additional parameters are needed.		channels is one provided no additional parameters are needed.
	For video streams, no encoding parameters are currently specified.		For video streams, no encoding parameters are currently specified.
	Additional parameters may be defined in the future, but codec-		Additional parameters may be defined in the future, but codec-
	specific parameters should not be added. Parameters added to an		specific parameters SHOULD NOT be added. Parameters added to an
	rtpmap attribute should only be those required for a session		rtpmap attribute SHOULD only be those required for a session
	directory to make the choice of appropriate media too to participate		directory to make the choice of appropriate media to participate in
	in a session. Codec-specific parameters should be added in other		a session. Codec-specific parameters should be added in other
	attributes.		attributes (for example, ``a=fmtp:'').
	Up to one rtpmap attribute can be defined for each media format		Up to one rtpmap attribute can be defined for each media format
	specified. Thus we might have:		specified. Thus we might have:
	m=audio 49230 RTP/AVP 96 97 98		m=audio 49230 RTP/AVP 96 97 98
	a=rtpmap:96 L8/8000		a=rtpmap:96 L8/8000
	a=rtpmap:97 L16/8000		a=rtpmap:97 L16/8000
	a=rtpmap:98 L16/11025/2		a=rtpmap:98 L16/11025/2
	RTP profiles that specify the use of dynamic payload types MUST		RTP profiles that specify the use of dynamic payload types MUST
	skipping to change at page 26, line 11		skipping to change at page 26, line 11
	is not dependent on charset. Note that recvonly applies to the media		is not dependent on charset. Note that recvonly applies to the media
	only, not to any associated control protocol (e.g. an RTP based		only, not to any associated control protocol (e.g. an RTP based
	system in recvonly mode SHOULD still send RTCP packets).		system in recvonly mode SHOULD still send RTCP packets).
	a=sendrecv		a=sendrecv
	This specifies that the tools should be started in send and receive		This specifies that the tools should be started in send and receive
	mode. This is necessary for interactive conferences with tools such		mode. This is necessary for interactive conferences with tools such
	as wb which defaults to receive only mode. It can be either a		as wb which defaults to receive only mode. 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.
			If none of the attributes "sendonly", "recvonly", "inactive", and
			"sendrecv" is present, "sendrecv" SHOULD be assumed as the default
			for sessions which are not of the conference type "broadcast" or
			"H332" (see below).
	a=sendonly		a=sendonly
	This specifies that the tools should be started in send-only mode.		This specifies that the tools should be started in send-only mode.
	An example may be where a different unicast address is to be used		An example may be where a different unicast address is to be used
	for a traffic destination than for a traffic source. In such a case,		for a traffic destination than for a traffic source. In such a case,
	two media descriptions may be use, one sendonly and one recvonly. It		two media descriptions may be use, one sendonly and one recvonly. It
	can be either a session or media attribute, but would normally only		can be either a session or media attribute, but would normally only
	be used as a media attribute, and is not dependent on charset. Note		be used as a media attribute, and is not dependent on charset. Note
	that sendonly applies only to the media, and any associated control		that sendonly applies only to the media, and any associated control
	protocol (e.g. RTCP) SHOULD still be received and processed as		protocol (e.g. RTCP) SHOULD still be received and processed as
	normal.		normal.
	skipping to change at page 26, line 34		skipping to change at page 26, line 39
	This is necessary for interactive conferences where users can put		This is necessary for interactive conferences where users can put
	other users on hold. No media is sent over an inactive media stream.		other users on hold. No media is sent over an inactive media stream.
	Note that an RTP based system SHOULD still send RTCP, even if		Note that an RTP based system SHOULD still send RTCP, even if
	started inactive. It can be either a session or media attribute, and		started inactive. It can be either a session or media attribute, and
	is not dependent on charset.		is not dependent on charset.
	a=orient:<whiteboard orientation>		a=orient:<whiteboard orientation>
	Normally this is only used in a whiteboard media specification. It		Normally this is only used in a whiteboard media specification. It
	specifies the orientation of a the whiteboard on the screen. It is		specifies the orientation of a the whiteboard on the screen. It is
	a media attribute. Permitted values are `portrait', `landscape' and		a media attribute. Permitted values are `portrait', `landscape' and
	`seascape' (upside down landscape). It is not dependent on charset		`seascape' (upside down landscape). It is not dependent on charset.
	a=type:<conference type>		a=type:<conference type>
	This specifies the type of the conference. Suggested values are		This specifies the type of the conference. Suggested values are
	`broadcast', `meeting', `moderated', `test' and `H332'. `recvonly'		`broadcast', `meeting', `moderated', `test' and `H332'. `recvonly'
	should be the default for `type:broadcast' sessions, `type:meeting'		should be the default for `type:broadcast' sessions, `type:meeting'
	should imply `sendrecv' and `type:moderated' should indicate the use		should imply `sendrecv' and `type:moderated' should indicate the use
	of a floor control tool and that the media tools are started so as		of a floor control tool and that the media tools are started so as
	to ``mute'' new sites joining the conference.		to ``mute'' new sites joining the conference.
	Specifying the attribute type:H332 indicates that this loosely		Specifying the attribute type:H332 indicates that this loosely
	skipping to change at page 27, line 42		skipping to change at page 27, line 48
	session description. As a media level attribute, it specifies the		session description. As a media level attribute, it specifies the
	language for any media-level SDP information field associated with		language for any media-level SDP information field associated with
	that media. Multiple sdplang attributes can be provided either at		that media. Multiple sdplang attributes can be provided either at
	session or media level if multiple languages in the session		session or media level if multiple languages in the session
	description or media use multiple languages, in which case the order		description or media use multiple languages, in which case the order
	of the attributes indicates the order of importance of the various		of the attributes indicates the order of importance of the various
	languages in the session or media from most important to least		languages in the session or media from most important to least
	important.		important.
	In general, sending session descriptions consisting of multiple		In general, sending session descriptions consisting of multiple
	languages should be discouraged. Instead, multiple descriptions		languages is discouraged. Instead, multiple descriptions SHOULD be
	should be sent describing the session, one in each language.		sent describing the session, one in each language. However this is
	However this is not possible with all transport mechanisms, and so		not possible with all transport mechanisms, and so multiple sdplang
	multiple sdplang attributes are allowed although not recommended.		attributes are allowed although NOT RECOMMENDED.
	The sdplang attribute value must be a single RFC 1766 language tag		The sdplang attribute value must be a single RFC 1766 language tag
	in US-ASCII. It is not dependent on the charset attribute. An		in US-ASCII. It is not dependent on the charset attribute. An
	sdplang attribute SHOULD be specified when a session is of		sdplang attribute SHOULD be specified when a session is of
	sufficient scope to cross geographic boundaries where the language		sufficient scope to cross geographic boundaries where the language
	of recipients cannot be assumed, or where the session is in a		of recipients cannot be assumed, or where the session is in a
	different language from the locally assumed norm.		different language from the locally assumed norm.
	a=lang:<language tag>		a=lang:<language tag>
	This can be a session level attribute or a media level attribute.		This can be a session level attribute or a media level attribute.
	skipping to change at page 35, line 37		skipping to change at page 35, line 37
	; sub-rules of 'p='		; sub-rules of 'p='
	phone-number = phone *SP "(" 1*email-safe ")" /		phone-number = phone *SP "(" 1*email-safe ")" /
	1*email-safe "<" phone ">" /		1*email-safe "<" phone ">" /
	phone		phone
	phone = "+" POS-DIGIT 1*(SP / "-" / DIGIT)		phone = "+" POS-DIGIT 1*(SP / "-" / DIGIT)
	;there must be a space or hyphen between the		;there must be a space or hyphen between the
	;international code and the rest of the number.		;international code and the rest of the number.
	; Should this use the tel: URL syntax?
	; sub-rules of 'c='		; sub-rules of 'c='
	connection-address = multicast-address / unicast-address		connection-address = multicast-address / unicast-address
	; sub-rules of 'b='		; sub-rules of 'b='
	bwtype = token		bwtype = token
	bandwidth = 1*DIGIT		bandwidth = 1*DIGIT
	; sub-rules of 't='		; sub-rules of 't='
	start-time = time / "0"		start-time = time / "0"
	skipping to change at page 37, line 26		skipping to change at page 37, line 23
	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" or "udp" for IP4		;typically "RTP/AVP" or "udp" for IP4
	port = 1*DIGIT		port = 1*DIGIT
	;should in the range "1024" to "65535" inclusive		;should be either "0" or in the range "1024" to "65535"
	;for UDP based media		;inclusive for UDP based media (a value "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 / extension-addr		unicast-address = IP4-address / IP6-address / FQDN / extension-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 ))
	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
	IP4-address = b1 3*("." decimal-uchar) / "0.0.0.0"		IP4-address = b1 3("." decimal-uchar) / "0.0.0.0"
	b1 = decimal-uchar		b1 = decimal-uchar
	; less than "224"; not "0" or "127"		; less than "224"; not "0" or "127"
	; 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 ]
	skipping to change at page 45, line 12		skipping to change at page 45, line 12
	o Define relation between the m= line and MIME types		o Define relation between the m= line and MIME types
	o Note use of s= in sessions with no meaningful name		o Note use of s= in sessions with no meaningful name
	o Note that a=rtpmap is a media level attribute		o Note that a=rtpmap is a media level attribute
	Appendix D: Authors' Addresses		Appendix D: Authors' Addresses
	Mark Handley		Mark Handley
	AT&T Center for Internet Research at ICSI,
	International Computer Science Institute,		International Computer Science Institute,
	1947 Center Street, Suite 600,		1947 Center Street, Suite 600,
	Berkeley, CA 94704, USA		Berkeley, CA 94704
	Email: mjh@aciri.org		United States
			Email: mjh@icir.org
	Van Jacobson		Van Jacobson
	MS 46a-1121		Packet Design
	Lawrence Berkeley Laboratory		2465 Latham Street
	Berkeley, CA 94720		Mountain View, CA 94040
	United States		United States
	Email: van@ee.lbl.gov		Email: van@packetdesign.com
	Colin Perkins		Colin Perkins
	USC Information Sciences Institute		USC Information Sciences Institute
	3811 N. Fairfax Drive, Suite 200		3811 N. Fairfax Drive, Suite 200
	Arlington, VA 22203		Arlington, VA 22203
	United States		United States
	Email: csp@isi.edu		Email: csp@isi.edu
	Acknowledgments		Acknowledgments
	skipping to change at page 46, line 32		skipping to change at page 46, line 32
	[8] D. Goldsmith and M. Davis, ``Using Unicode with MIME'', RFC1641,		[8] D. Goldsmith and M. Davis, ``Using Unicode with MIME'', RFC1641,
	July 1994		July 1994
	[9] F. Yergeau, ``UTF-8, a transformation format of Unicode and ISO		[9] F. Yergeau, ``UTF-8, a transformation format of Unicode and ISO
	10646'', RFC 2044, October 1996		10646'', RFC 2044, October 1996
	[10] ITU-T Recommendation H.332 (1998): "Multimedia Terminal for		[10] ITU-T Recommendation H.332 (1998): "Multimedia Terminal for
	Receiving Internet-based H.323 Conferences", ITU, Geneva.		Receiving Internet-based H.323 Conferences", ITU, Geneva.
	[11] M. Handley, H. Schulzrinne, E. Scholler and J. Rosenberg ``SIP:		[11] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston,
	Session Initiation Protocol'', RFC 2543, March 1999.		J. Peterson, R. Sparks, M. Handley, E. Schooler ``SIP: Session
			Initiatation Protocol'', RFC 3261, May 2002.
	[12] H. Schulzrinne, A. Rao and R. Lanphier, ``Real Time Streaming		[12] H. Schulzrinne, A. Rao and R. Lanphier, ``Real Time Streaming
	Protocol (RTSP)'' RFC 2326, April 1998.		Protocol (RTSP)'' RFC 2326, April 1998.
	[13] S. Bradner, ``Key words for use in RFCs to Indicate Requirement		[13] S. Bradner, ``Key words for use in RFCs to Indicate Requirement
	Levels'', RFC 2119, March 1997.		Levels'', RFC 2119, March 1997.
			[14] J. Rosenberg and H. Schulzrinne, ``An Offer/Answer Model with
			SDP'', RFC 3264, May 2002.
			[15] C. Huitama, ``RTCP Attribute in SDP'', RFC XXXX, May 2002
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/