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
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 31 skipping to change at page 46, line 31
to now. UTF-8 is described in Annex R, published as Amendment 2. to now. UTF-8 is described in Annex R, published as Amendment 2.
[8] D. Goldsmith and M. Davis, ``Using Unicode with MIME'', RFC1641, [8] D. Goldsmith and M. Davis, ``Using Unicode with MIME'', RFC1641,
[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.
 End of changes. 51 change blocks. 
80 lines changed or deleted 90 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/