draft-ietf-mmusic-sdp-new-11.txt   draft-ietf-mmusic-sdp-new-12.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-11.txt Van Jacobson/Packet Design draft-ietf-mmusic-sdp-new-12.txt Van Jacobson/Packet Design
Colin Perkins/ISI Colin Perkins/ISI
3 November 2002 Expires: September 2003
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
provisions of Section 10 of RFC2026. all 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
Force (IETF), its areas, and its working groups. Note that other groups Task Force (IETF), its areas, and its working groups. Note that
may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference
or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This document is a product of the Multiparty Multimedia Session Control This document is a product of the Multiparty Multimedia Session
(MMUSIC) working group of the Internet Engineering Task Force. Comments Control (MMUSIC) working group of the Internet Engineering Task
are solicited and should be addressed to the working group's mailing Force. Comments are solicited and should be addressed to the working
list at confctrl@isi.edu and/or the authors. group's mailing list at mmusic@ietf.org and/or the authors.
Abstract Copyright Notice
This memo defines the Session Description Protocol (SDP). SDP Copyright (C) The Internet Society (2003). All Rights Reserved.
is intended for describing multimedia sessions for the
purposes of session announcement, session invitation, and
other forms of multimedia session initiation.
1. Introduction Abstract
On the Internet multicast backbone (Mbone), a session directory tool is This memo defines the Session Description Protocol (SDP). SDP is
used to advertise multimedia conferences and communicate the conference intended for describing multimedia sessions for the purposes of
addresses and media-specific information necessary for participation. session announcement, session invitation, and other forms of
This memo defines a session description protocol for this purpose, and multimedia session initiation.
for general real-time multimedia session description purposes; it does
not describe multicast address allocation or the distribution of SDP
messages.
2. Background 1. Introduction
The Mbone is the part of the Internet that supports IP multicast, and When initiating multimedia teleconferences, voice-over-IP calls,
thus permits efficient many-to-many communication. It is used streaming video, or other real-time sessions, there is a requirement
extensively for multimedia conferencing. Such conferences usually have to convey media details, transport addresses, and other session
the property that tight coordination of conference membership is not description metadata to the participants.
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
conference data streams.
Session directories assist the advertisement of conference sessions and SDP provides a standard representation for such information,
communicate the relevant conference setup information to prospective irrespective of how that information is transported. SDP is purely a
participants. SDP is designed to convey such information to recipients. format for session description - it does not incorporate a transport
SDP is purely a format for session description - it does not incorporate protocol, and is intended to use different transport protocols as
a transport protocol, and is intended to use different transport appropriate, including the Session Announcement Protocol [RFC2974],
protocols as appropriate including the Session Announcement Protocol Session Initiation Protocol [RFC3261], Real-Time Streaming Protocol
[4], Session Initiation Protocol [11], Real-Time Streaming Protocol [RFC2326], electronic mail using the MIME extensions, and the
[12], electronic mail using the MIME extensions, and the Hypertext Hypertext Transport Protocol.
Transport Protocol.
SDP is intended to be general purpose so that it can be used for a wider SDP is intended to be general purpose so that it can be used in a
range of network environments and applications than just multicast wide range of network environments and applications. However, it is
session directories. However, it is not intended to support negotiation not intended to support negotiation of session content or media
of session content or media encodings - this is viewed as outside the encodings: this is viewed as outside the scope of session
scope of session description. description.
3. Glossary of Terms 2. Glossary of Terms
The following terms are used in this document, and have specific meaning The following terms are used in this document, and have specific
within the context of this document. meaning within the context of this document.
Conference Conference
A multimedia conference is a set of two or more communicating users A multimedia conference is a set of two or more communicating
along with the software they are using to communicate. users along with the software they are using to communicate.
Session Session
A multimedia session is a set of multimedia senders and receivers A multimedia session is a set of multimedia senders and receivers
and the data streams flowing from senders to receivers. A and the data streams flowing from senders to receivers. A
multimedia conference is an example of a multimedia session. multimedia conference is an example of a multimedia session.
Session Advertisement Session Advertisement
See session announcement. See session announcement.
Session Announcement Session Announcement
A session announcement is a mechanism by which a session description A session announcement is a mechanism by which a session
is conveyed to users in a pro-active fashion, i.e., the session description is conveyed to users in a pro-active fashion, i.e.,
description was not explicitly requested by the user. the session description was not explicitly requested by the user.
Session Description Session Description
A well defined format for conveying sufficient information to A well defined format for conveying sufficient information to
discover and participate in a multimedia session. discover and participate in a multimedia session.
3.1. Terminology 2.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [13]. document are to be interpreted as described in RFC 2119 [RFC2119].
4. Examples of SDP Usage 3. Examples of SDP Usage
4.1. Multicast Announcement 3.1. Multicast Announcement
In order to assist the advertisement of multicast multimedia conferences In order to assist the advertisement of multicast multimedia
and other multicast sessions, and to communicate the relevant session conferences and other multicast sessions, and to communicate the
setup information to prospective participants, a distributed session relevant session setup information to prospective participants, a
directory may be used. An instance of such a session directory distributed session directory may be used. An instance of such a
periodically sends packets containing a description of the session to a session directory periodically sends packets containing a description
well known multicast group. These advertisements are received by other of the session to a well known multicast group. These advertisements
session directories such that potential remote participants can use the are received by other session directories such that potential remote
session description to start the tools required to participate in the participants can use the session description to start the tools
session. required to participate in the session.
One protocol commonly used to implement such a distributed directory is One protocol commonly used to implement such a distributed directory
the Session Announcement Protocol, SAP [4]. SDP provides the recommended is the Session Announcement Protocol, SAP [RFC2974]. SDP provides the
session description format for such announcements. recommended session description format for such announcements.
4.2. Session Initiation 3.2. Session Initiation
The Session Initiation Protocol, SIP [11] is an application-layer The Session Initiation Protocol, SIP [RFC3261] is an application-
control protocol for creating, modifying and terminating sessions such layer control protocol for creating, modifying and terminating
as Internet multimedia conferences, Internet telephone calls and sessions such as Internet multimedia conferences, Internet telephone
multimedia distribution. The SIP messages used to create sessions carry calls and multimedia distribution. The SIP messages used to create
session descriptions which allow participants to agree on a set of sessions carry session descriptions which allow participants to agree
compatible media types. These session descriptions are commonly on a set of compatible media types. These session descriptions are
formatted using SDP. When used with SIP, the offer/answer model [14] commonly formatted using SDP. When used with SIP, the offer/answer
provides a framework for negotiation using SDP. model [RFC3264] provides a framework for negotiation using SDP.
4.3. Streaming media 3.3. Streaming media
The Real Time Streaming Protocol, RTSP [12], is an application-level The Real Time Streaming Protocol, RTSP [RFC2326], is an application-
protocol for control over the delivery of data with real-time level 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
on-demand delivery of real-time data, such as audio and video. An RTSP controlled, on-demand delivery of real-time data, such as audio and
client and server negotiate an appropriate set of parameters for media video. An RTSP client and server negotiate an appropriate set of
delivery, partially using SDP syntax to describe those parameters. parameters for media delivery, partially using SDP syntax to describe
those parameters.
4.4. Email and the World Wide Web 3.4. Email and the World Wide Web
Alternative means of conveying session descriptions include electronic Alternative means of conveying session descriptions include
mail and the World Wide Web. For both email and WWW distribution, the electronic mail and the World Wide Web. For both email and WWW
use of the MIME content type ``application/sdp'' MUST be used. This distribution, the use of the MIME content type "application/sdp" MUST
enables the automatic launching of applications for participation in the be used. This enables the automatic launching of applications for
session from the WWW client or mail reader in a standard manner. participation in the 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
World Wide Web (WWW) do not have the property that the receiver of a the World Wide Web (WWW) do not have the property that the receiver
session announcement can necessarily receive the session because the of a session announcement can necessarily receive the session because
multicast sessions may be restricted in scope, and access to the WWW the multicast sessions may be restricted in scope, and access to the
server or reception of email is possible outside this scope. SAP WWW server or reception of email is possible outside this scope. SAP
announcements do not suffer from this mismatch. announcements do not suffer from this mismatch.
5. Requirements and Recommendations 4. 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
participate in the session. SDP is primarily intended for use in an to participate in the session. SDP is primarily intended for use in
internetwork, although it is sufficiently general that it can describe an internetwork, although it is sufficiently general that it can
conferences in other network environments. describe conferences in other network environments.
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 A multimedia session, for these purposes, is defined as a set of
many-to-many. The times during which the session is active need not be media streams that exist for some duration of time. Media streams
continuous. can be many-to-many. The times during which the session is active
need not be 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
an environment, SDP serves two primary purposes. It is a means to such an environment, SDP serves two primary purposes. It is a means
communicate the existence of a session, and is a means to convey to 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
be relevant. to be relevant.
Thus SDP includes: Thus SDP includes:
o Session name and purpose o Session name and purpose
o Time(s) the session is active o Time(s) the session is active
o The media comprising the session o The media comprising the session
o Information to receive those media (addresses, ports, formats
and so on)
o Information to receive those media (addresses, ports, formats and so As resources necessary to participate in a session may be limited,
on) some additional information may also be desirable:
As resources necessary to participate in a session may be limited, some
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 enable In general, SDP must convey sufficient information to enable
applications to join a session (with the possible exception of applications to join a session (with the possible exception of
encryption keys) and to announce the resources to be used to non- encryption keys) and to announce the resources to be used to non-
participants that may need to know. participants that may need to know.
5.1. Media Information 4.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
of the multicast stream, whether being sent, received, or both. port 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 media 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
protocol defined. By default, this is the remote address and remote port transport protocol defined. By default, this is the remote address
to which data is sent, however some media types may redefine this and remote port to which data is sent, however some media types may
behaviour. redefine this behaviour.
5.2. Timing Information 4.2. Timing Information
Sessions may either be bounded or unbounded in time. Whether or not Sessions may either be bounded or unbounded in time. Whether or not
they are bounded, they may be only active at specific times. 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
o For each bound, repeat times such as "every Wednesday at 10am for o For each bound, repeat times such as "every Wednesday at 10am
one hour" for one hour"
This timing information is globally consistent, irrespective of local This timing information is globally consistent, irrespective of local
time zone or daylight saving time. time zone or daylight saving time.
5.3. Private Sessions 4.3. Private Sessions
It is possible to create both public sessions and private sessions. SDP It is possible to create both public sessions and private sessions.
itself does not distinguish between these: private sessions are SDP 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
on the mechanism used to convey SDP - e.g. mechanisms are defined for dependent on the mechanism used to convey SDP - e.g. mechanisms are
SDP transported using SAP [4] and SIP [11]. defined for SDP transported using SAP [RFC2974] and SIP [RFC3261].
If a session announcement is private it is possible to use that private
announcement to convey encryption keys necessary to decode each of the
media in a conference, including enough information to know which If a session announcement is private it is possible to use that
encryption scheme is used for each media. private announcement to convey encryption keys necessary to decode
each of the media in a conference, including enough information to
know which encryption scheme is used for each media.
5.4. Obtaining Further Information about a Session 4.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
or not to participate in a session. SDP may include additional pointers whether or not to participate in a session. SDP may include
in the form of Universal Resources Identifiers (URIs) for more additional pointers in the form of Universal Resources Identifiers
information about the session. (URIs) for more information about the session.
5.5. Categorisation 4.5. Categorisation
When many session descriptions are being distributed by SAP, or any When many session descriptions are being distributed by SAP, or any
other advertisement mechanism, it may be desirable to filter other advertisement mechanism, it may be desirable to filter
announcements that are of interest from those that are not. SDP announcements that are of interest from those that are not. SDP
supports a categorisation mechanism for sessions that is capable of supports a categorisation mechanism for sessions that is capable of
being automated. being automated.
5.6. Internationalization 4.6. Internationalization
The SDP specification recommends the use of the ISO 10646 character sets The SDP specification recommends the use of the ISO 10646 character
in the UTF-8 encoding (RFC 2279) to allow many different languages to be sets in the UTF-8 encoding (RFC 2279) to allow many different
represented. However, to assist in compact representations, SDP also languages to be represented. However, to assist in compact
allows other character sets such as ISO 8859-1 to be used when desired. representations, SDP also allows other character sets such as ISO
Internationalization only applies to free-text fields (session name and 8859-1 to be used when desired. Internationalization only applies to
background information), and not to SDP as a whole. free-text fields (session name and background information), and not
to SDP as a whole.
6. SDP Specification 5. 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
values MAY use the full ISO 10646 character set. The textual form, as attribute values MAY use the full ISO 10646 character set. The
opposed to a binary encoding such as ASN.1 or XDR, was chosen to enhance textual form, as opposed to a binary encoding such as ASN.1 or XDR,
portability, to enable a variety of transports to be used (e.g, session was chosen to enhance portability, to enable a variety of transports
description in a MIME email message) and to allow flexible, text-based to be used (e.g, session description in a MIME email message) and to
toolkits (e.g., Tcl/Tk ) to be used to generate and to process session allow flexible, text-based toolkits (e.g., Tcl/Tk) to be used to
descriptions. However, since SDP may be used in environments where the generate and to process session descriptions. However, since SDP may
maximum permissable size of a session description is limited (e.g. SAP be used in environments where the maximum permissable size of a
announcements; SIP transported in UDP), the encoding is deliberately session description is limited (e.g. SAP announcements; SIP
compact. Also, since announcements may be transported via very transported in UDP), the encoding is deliberately compact. Also,
unreliable means or damaged by an intermediate caching server, the since announcements may be transported via very unreliable means or
encoding was designed with strict order and formatting rules so that damaged by an intermediate caching server, the encoding was designed
most errors would result in malformed announcements which could be with strict order and formatting rules so that most errors would
result in malformed announcements which could be detected easily and
detected easily and discarded. This also allows rapid discarding of discarded. This also allows rapid discarding of encrypted
encrypted announcements for which a receiver does not have the correct 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
form: the form:
<type>=<value> <type>=<value>
where <type> MUST be exactly one case-significant character and <value> where <type> MUST be exactly one case-significant character and
is structured text whose format depends on <type>. In general <value> <value> is structured text whose format depends on <type>. In
is either a number of fields delimited by a single space character, or a general <value> is either a number of fields delimited by a single
free format string. Whitespace MUST NOT be used either side of the `=' space character, or a free format string. Whitespace MUST NOT be used
sign. either side of the "=" 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
`v=' line and continues to the first media-level section. The media with a "v=" line and continues to the first media-level section. The
description starts with an `m=' line and continues to the next media media description starts with an "m=" line and continues to the next
description or end of the whole session description. In general, media description or end of the whole session description. In
session-level values are the default for all media unless overridden by general, session-level values are the default for all media unless
an equivalent media-level value. overridden by an equivalent media-level value.
Some lines in each description are REQUIRED and some are OPTIONAL but Some lines in each description are REQUIRED and some are OPTIONAL but
all MUST appear in exactly the order given here (the fixed order greatly all MUST appear in exactly the order given here (the fixed order
enhances error detection and allows for a simple parser). OPTIONAL greatly enhances error detection and allows for a simple parser).
items are marked with a `*'. OPTIONAL items are marked with a "*".
Session description Session description
v= (protocol version) v= (protocol version)
o= (owner/creator and session identifier). o= (owner/creator and session identifier).
s= (session name) s= (session name)
i=* (session information) i=* (session information)
u=* (URI of description) u=* (URI of description)
e=* (email address) e=* (email address)
p=* (phone number) p=* (phone number)
c=* (connection information - not required if included in all media) c=* (connection information - not required if included in all media)
skipping to change at page 9, line 33 skipping to change at page 8, line 40
r=* (zero or more repeat times) r=* (zero or more repeat times)
Media description Media description
m= (media name and transport address) m= (media name and transport address)
i=* (media title) i=* (media title)
c=* (connection information - optional if included at session-level) c=* (connection information - optional if included at session-level)
b=* (bandwidth information) b=* (bandwidth information)
k=* (encryption key) k=* (encryption key)
a=* (zero or more media attribute lines) a=* (zero or more media attribute lines)
The set of `type' letters is deliberately small and not intended to be The set of type letters is deliberately small and not intended to be
extensible -- an SDP parser MUST completely ignore any announcement that extensible -- an SDP parser MUST completely ignore any announcement
contains a `type' letter that it does not understand. The `attribute' that contains a type letter that it does not understand. The
mechanism ("a=" described below) is the primary means for extending SDP attribute mechanism ("a=" described below) is the primary means for
and tailoring it to particular applications or media. Some attributes extending SDP and tailoring it to particular applications or media.
(the ones listed in this document) have a defined meaning but others may Some attributes (the ones listed in this document) have a defined
be added on an application-, media- or session-specific basis. An SDP meaning but others may be added on an application-, media- or
parser MUST ignore any attribute it doesn't understand. session-specific basis. An SDP parser MUST ignore any attribute it
doesn't understand.
The connection (`c=') and attribute (`a=') information in the session- The connection ("c=") and attribute ("a=") information in the
level section applies to all the media of that session unless overridden session-level section applies to all the media of that session unless
by connection information or an attribute of the same name in the media overridden by connection information or an attribute of the same name
description. For instance, in the example below, each media behaves as in the media description. For instance, in the example below, each
if it were given a `recvonly' attribute. media behaves as if it were given a "recvonly" attribute.
An example SDP description is: An example SDP description is:
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar s=SDP Seminar
i=A Seminar on the session description protocol i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe) e=j.doe@example.com (Jane Doe)
c=IN IP4 224.2.17.12/127 c=IN IP4 224.2.17.12/127
t=2873397496 2873404696 t=2873397496 2873404696
a=recvonly a=recvonly
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31 m=video 51372 RTP/AVP 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
which may contain any octet with the exceptions of 0x00 (Nul), 0x0a strings which may contain any octet with the exceptions of 0x00
(ASCII newline) and 0x0d (ASCII carriage return). The sequence CRLF (Nul), 0x0a (ASCII newline) and 0x0d (ASCII carriage return). The
(0x0d0a) is used to end a record, although parsers SHOULD be tolerant sequence CRLF (0x0d0a) is used to end a record, although parsers
and also accept records terminated with a single newline character. By SHOULD be tolerant and also accept records terminated with a single
default these byte strings contain ISO-10646 characters in UTF-8 newline character. By default these byte strings contain ISO-10646
encoding, but this default MAY be changed using the `charset' attribute. characters in UTF-8 encoding, but this default MAY be changed using
the "charset" attribute.
Protocol Version Protocol Version
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
There is no minor version number. Protocol. 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 (her username and The "o=" field gives the originator of the session (her username
the address of the user's host) plus a session id and session version and the address of the user's host) plus a session id and session
number. <username> is the user's login on the originating host, or it version number.
is ``-'' if the originating host does not support the concept of user
ids. <username> MUST NOT contain spaces. <session id> is a numeric
string such that the tuple of <username>, <session id>, <network type>,
<address type> and <address> form a globally unique identifier for the
session. The method of session id allocation is up to the creating
tool, but it has been suggested that a Network Time Protocol (NTP)
timestamp be used to ensure uniqueness [1]. <version> is a version
number for this announcement. It is needed for proxy announcements to
detect which of several announcements for the same session is the most
recent. Again its usage is up to the creating tool, so long as <username> is the user's login on the originating host, or it
<version> is increased when a modification is made to the session data. is "-" if the originating host does not support the concept of
Again, it is RECOMMENDED (but not mandatory) that an NTP timestamp is user ids. <username> MUST NOT contain spaces.
used. <network type> is a text string giving the type of network.
Initially ``IN'' is defined to have the meaning ``Internet''. <address
type> is a text string giving the type of the address that follows.
Initially ``IP4'' and ``IP6'' are defined. <address> is the globally
unique address of the machine from which the session was created. For
an address type of IP4, this is either the fully-qualified domain name
of the machine, or the dotted-decimal representation of the IP version 4
address of the machine. For an address type of IP6, this is either the
fully-qualified domain name of the machine, or the compressed textual
representation of the IP version 6 address of the machine. For both IP4
and IP6, the fully-qualified domain name is the form that SHOULD be
given unless this is unavailable, in which case the globally unique
address may be substituted. A local IP address MUST NOT be used in any
context where the SDP description might leave the scope in which the
address is meaningful.
In general, the ``o='' field serves as a globally unique identifier for <session id> is a numeric string such that the tuple of
this version of this session description, and the subfields excepting <username>, <session id>, <network type>, <address type> and
the version taken together identify the session irrespective of any <address> form a globally unique identifier for the session.
modifications. The method of session id allocation is up to the creating tool,
but it has been suggested that a Network Time Protocol (NTP)
format timestamp be used to ensure uniqueness [RFC1305].
<version> is a version number for this announcement. It is
needed for proxy announcements to detect which of several
announcements for the same session is the most recent. Again
its usage is up to the creating tool, so long as <version> is
increased when a modification is made to the session data.
Again, it is RECOMMENDED (but not mandatory) that an NTP format
timestamp is used.
<network type> is a text string giving the type of network.
Initially "IN" is defined to have the meaning "Internet".
<address type> is a text string giving the type of the address
that follows. Initially "IP4" and "IP6" are defined.
<address> is the globally unique address of the machine from
which the session was created. For an address type of IP4,
this is either the fully-qualified domain name of the machine,
or the dotted-decimal representation of the IP version 4
address of the machine. For an address type of IP6, this is
either the fully-qualified domain name of the machine, or the
compressed textual representation of the IP version 6 address
of the machine. For both IP4 and IP6, the fully-qualified
domain name is the form that SHOULD be given unless this is
unavailable, in which case the globally unique address may be
substituted. A local IP address MUST NOT be used in any
context where the SDP description might leave the scope in
which the address is meaningful.
In general, the "o=" field serves as a globally unique identifier
for this version of this session description, and the subfields
excepting the version taken together identify the session
irrespective of any modifications.
Session Name Session Name
s=<session name> s=<session name>
The ``s='' field is the session name. There MUST be one and only one The "s=" field is the session name. There MUST be one and only
``s='' field per session description. The ``s='' field MUST NOT be empty one "s=" field per session description. The "s=" field MUST NOT be
and SHOULD contain ISO 10646 characters (but see also the `charset' empty and SHOULD contain ISO 10646 characters (but see also the
attribute below). If a session has no meaningful name, the value ``s= '' "a=charset" attribute below). If a session has no meaningful name,
SHOULD be used (i.e. a single space as the session name). the value "s= " SHOULD be used (i.e. a single space as the
session name).
Session and Media Information Session and Media Information
i=<session description> i=<session description>
The ``i='' field is information about the session. There may be at most The "i=" field is information about the session. There may be at
one session-level ``i='' field per session description, and at most one most one session-level "i=" field per session description, and at
``i='' field per media. Although it may be omitted, this is NOT most one "i=" field per media. Although it may be omitted, this is
RECOMMENDED for session announcements, and user interfaces for composing NOT RECOMMENDED for session announcements, and user interfaces for
sessions should require text to be entered. If it is present it must composing sessions should require text to be entered. If it is
contain ISO 10646 characters (but see also the `charset' attribute present it must contain ISO 10646 characters (but see also the
below). "a=charset" attribute below).
A single ``i='' field can also be used for each media definition. In
media definitions, ``i='' fields are primarily intended for labeling
media streams. As such, they are most likely to be useful when a single A single "i=" field can also be used for each media definition.
session has more than one distinct media stream of the same media type. In media definitions, "i=" fields are primarily intended for
An example would be two different whiteboards, one for slides and one labeling media streams. As such, they are most likely to be
for feedback and questions. useful when a single session has more than one distinct media
stream of the same media type. An example would be two different
whiteboards, one for slides and one 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.
should be a pointer to additional information about the conference. This The URI should be a pointer to additional information about the
field is OPTIONAL, but if it is present it MUST be specified before the conference. This field is OPTIONAL, but if it is present it MUST
first media field. No more than one URI field is allowed per session be specified before the first media field. No more than one URI
description. field is allowed per session 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
conference. This is not necessarily the same person that created the the conference. This is not necessarily the same person that
conference announcement. created the 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
previous version of SDP specified that either an email field or a phone that the previous version of SDP specified that either an email
field MUST be specified, but this was widely ignored. The change brings field or a phone field MUST be specified, but this was widely
the specification into line with common usage. ignored. The change brings the specification into line with
common usage.
If these are present, they MUST be specified before the first media If the email addres or phone number are present, they MUST be
field. More than one email or phone field can be given for a session specified before the first media field. More than one email or
description. phone field can be given for a session description.
Phone numbers SHOULD be given in the conventional international format - Phone numbers SHOULD be given in the conventional international
preceded by a ``+'' and the international country code. There must be a format: preceded by a "+" and the international country code.
space or a hyphen (``-'') between the country code and the rest of the There must be a space or a hyphen ("-") between the country code
phone number. Spaces and hyphens may be used to split up a phone field and the rest of the phone number. Spaces and hyphens may be used
to aid readability if desired. For example: to split up a phone field to aid readability if desired. For
example:
p=+44-171-380-7777 or p=+1 617 555 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
string associated with them, normally giving the name of the person who text string associated with them, normally giving the name of the
may be contacted. This should be enclosed in parenthesis if it is person who may be contacted. This should be enclosed in
present. For example: parenthesis if it is present. For example:
e=j.doe@example.com (Jane Doe) 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
email addresses and phone numbers. For example, both email addresses and phone numbers. For example,
e=Jane Doe <j.doe@example.com> 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
encoding, or alternatively in ISO-8859-1 or other encodings if the UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings
appropriate charset session-level attribute is set. if the 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 at least one "c=" field
media description (see below) or a ``c='' field at the session-level. in each media description (see below) or a single "c=" field at
It MAY contain a session-level ``c='' field and one additional ``c='' the session-level. It MAY contain a single session-level "c="
field per media description, in which case the per-media values override field and additional "c=" field(s) per media description, in which
the session-level settings for the respective media. case the per-media values override 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
the type of network. Initially ``IN'' is defined to have the meaning giving the type of network. Initially "IN" is defined to have the
``Internet''. meaning "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
for sessions that are not IP based. Currently only IP4 and IP6 are used for sessions that are not IP based. Currently only IP4 and
defined. IP6 are defined.
The third sub-field is the connection address. Optional extra sub- The third sub-field is the connection address. Optional extra
fields MAY be added after the connection address depending on the value sub-fields MAY be added after the connection address depending on
of the <address type> field. the value 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
multicast group address. If the conference is not multicast, then an IP multicast group address. If the conference is not
the connection address contains the unicast IP address of the multicast, then the connection address contains the unicast
expected data source or data relay or data sink as determined by IP address of the expected data source or data relay or data
additional attribute fields. It is not expected that unicast sink as determined by additional attribute fields. It is not
addresses will be given in a session description that is expected that unicast addresses will be given in a session
communicated by a multicast announcement, though this is not description that is communicated by a multicast announcement,
prohibited. though this is not prohibited.
o Conferences using an IPv4 multicast connection address MUST also o Conferences using an IPv4 multicast connection address MUST
have a time to live (TTL) value present in addition to the multicast also have a time to live (TTL) value present in addition to
address. The TTL and the address together define the scope with the multicast address. The TTL and the address together
which multicast packets sent in this conference will be sent. TTL define the scope with which multicast packets sent in this
values MUST be in the range 0-255. conference will be sent. TTL values MUST be in the range
0-255.
The TTL for the session is appended to the address using a slash as The TTL for the session is appended to the address using a slash
a separator. An example is: as a separator. An example is:
c=IN IP4 224.2.36.42/127 c=IN IP4 224.2.36.42/127
IPv6 multicast does not use TTL scoping, and hence the TTL value IPv6 multicast does not use TTL scoping, and hence the TTL value
MUST NOT be present for IPv6 multicast. It is expected that IPv6 MUST NOT be present for IPv6 multicast. It is expected that IPv6
scoped addresses will be used to limit the scope of conferences. scoped addresses will be used to limit the scope of conferences.
Hierarchical or layered encoding schemes are data streams where the Hierarchical or layered encoding schemes are data streams where
encoding from a single media source is split into a number of the encoding from a single media source is split into a number of
layers. The receiver can choose the desired quality (and hence layers. The receiver can choose the desired quality (and hence
bandwidth) by only subscribing to a subset of these layers. Such bandwidth) by only subscribing to a subset of these layers. Such
layered encodings are normally transmitted in multiple multicast layered encodings are normally transmitted in multiple multicast
groups to allow multicast pruning. This technique keeps unwanted groups to allow multicast pruning. This technique keeps unwanted
traffic from sites only requiring certain levels of the hierarchy. traffic from sites only requiring certain levels of the hierarchy.
For applications requiring multiple multicast groups, we allow the For applications requiring multiple multicast groups, we allow the
following notation to be used for the connection address: following notation to be used for the connection address:
<base multicast address>[/<ttl>]/<number of addresses> <base multicast address>[/<ttl>]/<number of addresses>
If the number of addresses is not given it is assumed to be one. If the number of addresses is not given it is assumed to be one.
Multicast addresses so assigned are contiguously allocated above the Multicast addresses so assigned are contiguously allocated above
base address, so that, for example: the base address, so that, for example:
c=IN IP4 224.2.1.1/127/3 c=IN IP4 224.2.1.1/127/3
would state that addresses 224.2.1.1, 224.2.1.2 and 224.2.1.3 are to would state that addresses 224.2.1.1, 224.2.1.2 and 224.2.1.3 are
be used at a ttl of 127. This is semantically identical to to be used at a ttl of 127. This is semantically identical to
including multiple ``c='' lines in a media description: including multiple "c=" lines in a media description:
c=IN IP4 224.2.1.1/127 c=IN IP4 224.2.1.1/127
c=IN IP4 224.2.1.2/127 c=IN IP4 224.2.1.2/127
c=IN IP4 224.2.1.3/127 c=IN IP4 224.2.1.3/127
Similarly, an IPv6 example would be: Similarly, an IPv6 example would be:
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 MAY be specified on a per-media Multiple addresses or "c=" lines MAY be specified on a per-media
basis. They MUST NOT be specified 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 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 The <bandwidth-value> is in kilobits per second by default.
MAY specify that alternative units are to be used (the modifiers Modifiers MAY specify that alternative units are to be used (the
defined in this memo use the default units). modifiers defined in this memo use the default units).
o <modifier> is a single alphanumeric word giving the meaning of the The <modifier> is a single alphanumeric word giving the meaning of
bandwidth figure. the bandwidth figure.
o Two modifiers are initially defined: Two modifiers are initially defined:
CT Conference Total: If the bandwidth of a session or media in a CT Conference Total
session is different from the bandwidth implicit from the scope, a If the bandwidth of a session or media in a session is
`b=CT:...' line should be supplied for the session giving the different from the bandwidth implicit from the scope, a
proposed upper limit to the bandwidth used. The primary purpose "b=CT:..." line should be supplied for the session giving
of this is to give an approximate idea as to whether two or more the proposed upper limit to the bandwidth used. The primary
sessions can co-exist simultaneously. purpose of this is to give an approximate idea as to whether
two or more sessions can co-exist simultaneously.
AS Application-Specific Maximum: The bandwidth is interpreted to be AS Application-Specific Maximum
application-specific, i.e., will be the application's concept of The bandwidth is interpreted to be application-specific (it
maximum bandwidth. Normally this will coincide with what is set will be the application's concept of maximum bandwidth).
on the application's ``maximum bandwidth'' control if applicable. Normally this will coincide with what is set on the
For RTP based applications, AS gives the RTP ``session bandwidth'' application's "maximum bandwidth" control if applicable.
as defined in section 6.2 of [2]. For RTP based applications, AS gives the RTP "session
bandwidth" as defined in section 6.2 of [RFC1889].
Note that CT gives a total bandwidth figure for all the media at all Note that CT gives a total bandwidth figure for all the media at
sites. AS gives a bandwidth figure for a single media at a single all sites. AS gives a bandwidth figure for a single media at a
site, although there may be many sites sending simultaneously. single site, although there may be many sites sending
simultaneously.
o Extension Mechanism: Tool writers can define experimental bandwidth Tool writers MAY define experimental bandwidth modifiers by
modifiers by prefixing their modifier with ``X-''. For example: prefixing their modifier with "X-". For example:
b=X-YZ:128 b=X-YZ:128
Use of the ``X-'' prefix is NOT RECOMMENDED: instead new modifiers Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers
SHOULD be registered with IANA in the standard namespace. SDP SHOULD be registered with IANA in the standard namespace. SDP
parsers MUST ignore bandwidth fields with unknown modifiers. parsers MUST ignore bandwidth fields with unknown modifiers.
Modifiers MUST be alpha-numeric and, although no length limit is Modifiers MUST be alpha-numeric and, although no length limit is
given, they are recommended to be short. given, they are recommended to be short.
Times, Repeat Times and Time Zones Times, Repeat Times and Time Zones
t=<start time> <stop time> t=<start time> <stop time>
o ``t='' fields specify the start and stop times for a session. "t=" fields specify the start and stop times for a session.
Multiple ``t='' fields MAY be used if a session is active at Multiple "t=" fields MAY be used if a session is active at
multiple irregularly spaced times; each additional ``t='' field multiple irregularly spaced times; each additional "t=" field
specifies an additional period of time for which the session will be specifies an additional period of time for which the session will
active. If the session is active at regular times, an ``r='' field be active. If the session is active at regular times, an "r="
(see below) should be used in addition to and following a ``t='' field (see below) should be used in addition to and following a
field - in which case the ``t='' field specifies the start and stop "t=" field - in which case the "t=" field specifies the start and
times of the repeat sequence. stop times of the repeat sequence.
o The first and second sub-fields give the start and stop times for The first and second sub-fields give the start and stop times for
the session respectively. These values are the decimal the session respectively. These values are the decimal
representation of Network Time Protocol (NTP) time values in seconds representation of Network Time Protocol (NTP) time values in
[1]. To convert these values to UNIX time, subtract decimal seconds [RFC1305]. To convert these values to UNIX time, subtract
2208988800. decimal 2208988800.
NTP timestamps are 64 bit values which wrap sometime in the year NTP timestamps are 64 bit values which wrap sometime in the year
2036. Since SDP uses an arbitrary length decimal representation, 2036. Since SDP uses an arbitrary length decimal representation,
this should not cause an issue (SDP timestamps will continue this should not cause an issue (SDP timestamps will continue
counting seconds since 1900, NTP will use the value modulo the 64 counting seconds since 1900, NTP will use the value modulo the 64
bit limit). bit limit).
o If the stop-time is set to zero, then the session is not bounded, If the stop-time is set to zero, then the session is not bounded,
though it will not become active until after the start-time. If the though it will not become active until after the start-time. If
start-time is also zero, the session is regarded as permanent. the start-time is also zero, the session is regarded as permanent.
User interfaces SHOULD strongly discourage the creation of unbounded User interfaces SHOULD strongly discourage the creation of
and permanent sessions as they give no information about when the unbounded and permanent sessions as they give no information about
session is actually going to terminate, and so make scheduling when the session is actually going to terminate, and so make
difficult. scheduling difficult.
The general assumption may be made, when displaying unbounded The general assumption may be made, when displaying unbounded
sessions that have not timed out to the user, that an unbounded sessions that have not timed out to the user, that an unbounded
session will only be active until half an hour from the current time session will only be active until half an hour from the current
or the session start time, whichever is the later. If behaviour time or the session start time, whichever is the later. If
other than this is required, an end-time should be given and behaviour other than this is required, an end-time should be given
modified as appropriate when new information becomes available about and modified as appropriate when new information becomes available
when the session should really end. about when the session should really end.
Permanent sessions may be shown to the user as never being active Permanent sessions may be shown to the user as never being active
unless there are associated repeat times which state precisely when unless there are associated repeat times which state precisely
the session will be active. In general, permanent sessions SHOULD when the session will be active. In general, permanent sessions
NOT be created for any session expected to have a duration of less SHOULD NOT be created for any session expected to have a duration
than 2 months, and should be discouraged for sessions expected to of less than 2 months, and should be discouraged for sessions
have a duration of less than 6 months. expected to have a duration of less than 6 months.
r=<repeat interval> <active duration> <list of offsets from start-time> r=<repeat interval> <active duration> <list of offsets from start-
time>
o ``r='' fields specify repeat times for a session. For example, if "r=" fields specify repeat times for a session. For example, if a
a session is active at 10am on Monday and 11am on Tuesday for one session is active at 10am on Monday and 11am on Tuesday for one
hour each week for three months, then the <start time> in the hour each week for three months, then the <start time> in the
corresponding ``t='' field would be the NTP representation of 10am corresponding "t=" field would be the NTP representation of 10am
on the first Monday, the <repeat interval> would be 1 week, the on the first Monday, the <repeat interval> would be 1 week, the
<active duration> would be 1 hour, and the offsets would be zero and <active duration> would be 1 hour, and the offsets would be zero
25 hours. The corresponding ``t='' field stop time would be the NTP and 25 hours. The corresponding "t=" field stop time would be the
representation of the end of the last session three months later. By NTP representation of the end of the last session three months
default all fields are in seconds, so the ``r='' and ``t='' fields later. By default all fields are in seconds, so the "r=" and "t="
might be: fields might be:
t=3034423619 3042462419 t=3034423619 3042462419
r=604800 3600 0 90000 r=604800 3600 0 90000
To make description more compact, times may also be given in units To make description more compact, times may also be given in units
of days, hours or minutes. The syntax for these is a number of days, hours or minutes. The syntax for these is a number
immediately followed by a single case-sensitive character. immediately followed by a single case-sensitive character.
Fractional units are not allowed - a smaller unit should be used Fractional units are not allowed - a smaller unit should be used
instead. The following unit specification characters are allowed: instead. The following unit specification characters are allowed:
d - days (86400 seconds) d - days (86400 seconds)
h - hours (3600 seconds) h - hours (3600 seconds)
m - minutes (60 seconds) m - minutes (60 seconds)
s - seconds (allowed for completeness but not recommended) s - seconds (allowed for completeness but not recommended)
skipping to change at page 17, line 48 skipping to change at page 17, line 20
d - days (86400 seconds) d - days (86400 seconds)
h - hours (3600 seconds) h - hours (3600 seconds)
m - minutes (60 seconds) m - minutes (60 seconds)
s - seconds (allowed for completeness but not recommended) s - seconds (allowed for completeness but not recommended)
Thus, the above announcement could also have been written: Thus, the above announcement could also have been written:
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
to explicitly list the session times. used 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- 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 time. 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
and summer, it must be possible to specify unambiguously by whose winter and summer, it must be possible to specify unambiguously
time zone a session is scheduled. To simplify this task for by whose time zone a session is scheduled. To simplify this task
receivers, we allow the sender to specify the NTP time that a time for receivers, we allow the sender to specify the NTP time that a
zone adjustment happens and the offset from the time when the time 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
specify a list of these adjustment times and offsets from the base specify a list of these adjustment times and offsets from the base
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,
that at time 2898848070 the session's original time base is and 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. Adjustments apply to all ``t='' and time - they are not cumulative. Adjustments apply to all "t=" and
``r='' lines in a session description. "r=" lines in a session description.
o If a session is likely to last several years, it is expected that 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>
o The session description protocol MAY be used to convey encryption If transported over a secure and trusted channel, the session
keys. A key field is permitted before the first media entry (in description protocol MAY be used to convey encryption keys. A key
which case it applies to all media in the session), or for each field is permitted before the first media entry (in which case it
media entry as required. applies to all media in the session), or for each media entry as
required.
o The format of keys and their usage is outside the scope of this The format of keys and their usage is outside the scope of this
document, but see [3]. document, but see [RFC1890] for an example.
o The method indicates the mechanism to be used to obtain a usable key The method indicates the mechanism to be used to obtain a usable
by external means, or from the encoded encryption key given. The key by external means, or from the encoded encryption key given.
following methods are defined: The following methods are defined:
k=clear:<encryption key> k=clear:<encryption key>
The encryption key (as described in [3] for RTP media streams
under the AV profile) is included untransformed in this key The encryption key is included untransformed in this key field.
field. This method MUST NOT be used unless it can be guaranteed that
the SDP is conveyed over a secure channel.
k=base64:<encoded encryption key> k=base64:<encoded encryption key>
The encryption key (as described in [3] for RTP media streams
under the AV profile) is included in this key field but has been The encryption key is included in this key field but has been
base64 encoded because it includes characters that are base64 encoded because it includes characters that are
prohibited in SDP. prohibited in SDP. This method MUST NOT be used unless it can
be guaranteed that the SDP is conveyed over a secure channel.
k=uri:<URI to obtain key> k=uri:<URI to obtain key>
A Universal Resource Identifier as used by WWW clients is
included in this key field. The URI refers to the data A Universal Resource Identifier is included in the key field.
containing the key, and may require additional authentication The URI refers to the data containing the key, and may require
before the key can be returned. When a request is made to the additional authentication before the key can be returned. When
given URI, the MIME content-type of the reply specifies the a request is made to the given URI, the MIME content-type of
encoding for the key in the reply. The key should not be the reply specifies the encoding for the key in the reply.
obtained until the user wishes to join the session to reduce
synchronisation of requests to the WWW server(s).
k=prompt k=prompt
No key is included in this SDP description, but the session or No key is included in this SDP description, but the session or
media stream referred to by this key field is encrypted. The media stream referred to by this key field is encrypted. The
user should be prompted for the key when attempting to join the user should be prompted for the key when attempting to join the
session, and this user-supplied key should then be used to session, and this user-supplied key should then be used to
decrypt the media streams. decrypt the media streams. The use of user-specified keys is
NOT RECOMMENDED, since such keys tend to have weak security
properties.
The key field MUST NOT be used unless it can be guaranteed that
the SDP is conveyed over a secure and trusted channel. Examples of
such channels might include an SSL encrypted SIP or HTTP session
where any intermediate proxies are trusted, or SDP embedded inside
an encrypted S/MIME message.
Attributes Attributes
a=<attribute> a=<attribute>
a=<attribute>:<value> a=<attribute>:<value>
Attributes are the primary means for extending SDP. Attributes may be Attributes are the primary means for extending SDP. Attributes
defined to be used as "session-level" attributes, "media-level" may be defined to be used as "session-level" attributes, "media-
attributes, or both. level" attributes, or both.
A media description may have any number of attributes (``a='' fields) A media description may have any number of attributes ("a="
which are media specific. These are referred to as "media-level" fields) which are media specific. These are referred to as
attributes and add information about the media stream. Attribute fields "media-level" attributes and add information about the media
can also be added before the first media field; these "session-level" stream. Attribute fields can also be added before the first media
attributes convey additional information that applies to the conference field; these "session-level" attributes convey additional
as a whole rather than to individual media; an example might be the information that applies to the conference as a whole rather than
conference's floor control policy. to individual media; an example might be the conference's floor
control policy.
Attribute fields may be of two forms: Attribute fields may be of two forms:
o property attributes. A property attribute is simply of the form o property attributes:
``a=<flag>''. These are binary attributes, and the presence of the A property attribute is simply of the form "a=<flag>".
attribute conveys that the attribute is a property of the session. These are binary attributes, and the presence of the
An example might be ``a=recvonly''. attribute conveys that the attribute is a property of
the session. An example might be "a=recvonly".
o value attributes. A value attribute is of the form o value attributes:
``a=<attribute>:<value>''. An example might be that a whiteboard A value attribute is of the form "a=<attribute>:<value>".
could have the value attribute ``a=orient:landscape'' For example, a whiteboard could have the value attribute
"a=orient:landscape"
Attribute interpretation depends on the media tool being invoked. Thus Attribute interpretation depends on the media tool being invoked.
receivers of session descriptions should be configurable in their Thus receivers of session descriptions should be configurable in
interpretation of announcements in general and of attributes in their interpretation of announcements in general and of attributes
particular. in particular.
Attribute names MUST be in the US-ASCII subset of ISO-10646/UTF-8. Attribute names MUST be in the US-ASCII subset of ISO-10646/UTF-8.
Attribute values are octet strings, and MAY use any octet value except Attribute values are octet strings, and MAY use any octet value
0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute values are except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default,
to be interpreted as in ISO-10646 character set with UTF-8 encoding. attribute values are to be interpreted as in ISO-10646 character
Unlike other text fields, attribute values are NOT normally affected by set with UTF-8 encoding. Unlike other text fields, attribute
the `charset' attribute as this would make comparisons against known values are NOT normally affected by the "charset" attribute as
values problematic. However, when an attribute is defined, it can be this would make comparisons against known values problematic.
defined to be charset-dependent, in which case it's value should be However, when an attribute is defined, it can be defined to be
interpreted in the session charset rather than in ISO-10646. charset-dependent, in which case it's value should be interpreted
in the session charset rather than in ISO-10646.
Attributes SHOULD be registered with IANA (see Appendix B). Names of Attributes SHOULD be registered with IANA (see Appendix B). Names
unregistered attributes SHOULD begin with "X-" to prevent inadvertent of unregistered attributes SHOULD begin with "X-" to prevent
collision with registered attributes, however the use of unregistered inadvertent collision with registered attributes, however the use
attributes is NOT RECOMMENDED. If an attribute is received that is not of unregistered attributes is NOT RECOMMENDED. If an attribute is
understood, it MUST be ignored by the receiver. received that is not understood, it MUST be ignored by the
receiver.
Media Announcements Media Announcements
m=<media> <port> <transport> <fmt list> m=<media> <port> <transport> <fmt list>
A session description may contain a number of media descriptions. Each A session description may contain a number of media descriptions.
media description starts with an ``m='' field, and is terminated by Each media description starts with an "m=" field, and is
either the next ``m='' field or by the end of the session description. terminated by either the next "m=" field or by the end of the
A media field also has several sub-fields: session description. A media field has several four sub-fields.
o The first sub-field is the media type. Currently defined media are
``audio'', ``video'', ``application'', ``data'' and ``control'',
though this list may be extended as new communication modalities
emerge (e.g., telepresense). The difference between ``application''
and ``data'' is that the former is a media flow such as whiteboard
information, and the latter is bulk-data transfer such as
multicasting of program executables which will not typically be
displayed to the user. ``control'' is used to specify an additional
conference control channel for the session.
o The second sub-field is the transport port to which the media stream The first sub-field is the media type. Currently defined media
will be sent. The meaning of the transport port depends on the are "audio", "video", "application", "data" and "control", though
network being used as specified in the relevant ``c'' field and on this list may be extended in future. The difference between
the transport protocol defined in the third sub-field. Other ports "application" and "data" is that the former is a media flow such
used by the media application (such as the RTCP port, see [2]) MAY as whiteboard information, and the latter is bulk-data transfer
be derived algorithmically from the base media port or MAY be such as multicasting of program executables which will not
specified in a separate attribute (e.g. ``a=rtcp:'' as defined in typically be displayed to the user. "control" is used to specify
[15]). an additional conference control channel for the session.
Note: For transports based on UDP, the value should be in the range The second sub-field is the transport port to which the media
1024 to 65535 inclusive. For RTP compliance it SHOULD be an even stream is sent. The meaning of the transport port depends on the
number. network being used as specified in the relevant "c=" field, and on
the transport protocol defined in the third sub-field. Other
ports used by the media application (such as the RTCP port
[RFC1889]) MAY be derived algorithmically from the base media port
or MAY be specified in a separate attribute (e.g. "a=rtcp:" as
defined in [RTCPSDP]).
For applications where hierarchically encoded streams are being sent For applications where hierarchically encoded streams are being
to a unicast address, it may be necessary to specify multiple sent 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
for IP multicast addresses in the ``c='' field: used for IP multicast addresses in the "c=" field:
m=<media> <port>/<number of ports> <transport> <fmt list> m=<media> <port>/<number of ports> <transport> <fmt list>
In such a case, the ports used depend on the transport protocol. In such a case, the ports used depend on the transport protocol.
For RTP, only the even ports are used for data and the corresponding For RTP, only the even ports are used for data and the
one-higher odd port is used for RTCP. For example: corresponding one-higher odd port is used for RTCP. For example:
m=video 49170/2 RTP/AVP 31 m=video 49170/2 RTP/AVP 31
would specify that ports 49170 and 49171 form one RTP/RTCP pair and would specify that ports 49170 and 49171 form one RTP/RTCP pair
49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the
transport protocol and 31 is the format (see below). transport protocol and 31 is the format (see below).
If multiple addresses are specified in the ``c='' field and multiple If multiple addresses are specified in the "c=" field and multiple
ports are specified in the ``m='' field, a one-to-one mapping from ports are specified in the "m=" field, a one-to-one mapping from
port to the corresponding address is implied. For example: port to the corresponding address is implied. For example:
c=IN IP4 224.2.1.1/127/2 c=IN IP4 224.2.1.1/127/2
m=video 49170/2 RTP/AVP 31 m=video 49170/2 RTP/AVP 31
would imply that address 224.2.1.1 is used with ports 49170 and would imply that address 224.2.1.1 is used with ports 49170 and
49171, and address 224.2.1.2 is used with ports 49172 and 49173. 49171, and address 224.2.1.2 is used with ports 49172 and 49173.
o The third sub-field is the transport protocol. The transport 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
transport protocol runs over IP4. For IP4, it is normally expected protocol runs over IP4. For IP4, it is normally expected that
that most media traffic will be carried as RTP over UDP. The most media traffic will be carried as RTP over UDP. The following
following transport protocols are defined, but may be extended transport protocols are defined, but may be extended through
through registration of new protocols with IANA (see Appendix B): 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 TCP - Transmission Control 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
the combined protocol is recommended. If a transport protocol is distinguish the combined protocol is recommended. If a transport
used over UDP to carry several distinct media types that need to be protocol is used over UDP to carry several distinct media types
distinguished by a session directory, then specifying the transport that need to be distinguished by a session directory, then
protocol and media format separately is necessary. RTP is an specifying the transport protocol and media format separately is
example of a transport-protocol that carries multiple payload necessary. RTP is an example of a transport-protocol that carries
formats that must be distinguished by the session directory for it multiple payload formats that must be distinguished by the session
to know how to start appropriate tools, relays, mixers or recorders. directory for it to know how to start appropriate tools, relays,
mixers or recorders.
The main reason to specify the transport-protocol in addition to the The main reason to specify the transport-protocol in addition to
media format is that the same standard media formats may be carried the media format is that the same standard media formats may be
over different transport protocols even when the network protocol is carried over different transport protocols even when the network
the same - a historical example is vat PCM audio and RTP PCM audio. protocol is the same - a historical example is vat PCM audio and
In addition, relays and monitoring tools that are transport- RTP PCM audio. In addition, relays and monitoring tools that are
protocol-specific but format-independent are possible. transport-protocol-specific but format-independent are possible.
For RTP media streams operating under the RTP Audio/Video Profile For RTP media streams operating under the RTP Audio/Video Profile
[3], the protocol field is ``RTP/AVP''. Should other RTP profiles [RFC1890], the protocol field is "RTP/AVP". Should other RTP
be defined in the future, their profiles will be specified in the profiles be defined in the future, their profiles will be
same way. For example, the protocol field ``RTP/XYZ'' would specify specified in the same way. For example, the protocol field
RTP operating under a profile whose short name is ``XYZ''. "RTP/XYZ" would specify RTP operating under a profile whose short
name is "XYZ".
o The fourth and subsequent sub-fields are media formats. For audio 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 SHOULD be used as 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. The provide a dynamic binding of media encoding to RTP payload type.
encoding names in the RTP AV Profile do not specify unique audio The encoding names in the RTP AV Profile do not specify unique
encodings (in terms of clock rate and number of audio channels), and audio encodings (in terms of clock rate and number of audio
so they are not used directly in SDP format fields. Instead, the channels), and so they are not used directly in SDP format fields.
payload type number should be used to specify the format for static Instead, the payload type number should be used to specify the
payload types and the payload type number along with additional format for static payload types and the payload type number along
encoding information should be used for dynamically allocated with additional encoding information should be used for
payload types. dynamically allocated 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
such a stream sent to UDP port 49232 is: such a stream sent to UDP port 49232 is:
m=audio 49232 RTP/AVP 0 m=audio 49232 RTP/AVP 0
An example of a dynamic payload type is 16 bit linear encoded stereo An example of a dynamic payload type is 16 bit linear encoded
audio sampled at 16 kHz. If we wish to use dynamic RTP/AVP payload stereo audio sampled at 16 kHz. If we wish to use dynamic RTP/AVP
type 98 for such a stream, additional information is required to payload type 98 for such a stream, additional information is
decode it: required to decode it:
m=audio 49232 RTP/AVP 98 m=audio 49232 RTP/AVP 98
a=rtpmap:98 L16/16000/2 a=rtpmap:98 L16/16000/2
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 to participate in directory to make the choice of appropriate media to participate
a session. Codec-specific parameters should be added in other in a session. Codec-specific parameters should be added in other
attributes (for example, ``a=fmtp:''). 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
define the set of valid encoding names and/or a means to register define the set of valid encoding names and/or a means to register
encoding names if that profile is to be used with SDP. encoding names if that profile is to be used with SDP.
Experimental encoding formats can also be specified using rtpmap. Experimental encoding formats can also be specified using rtpmap.
RTP formats that are not registered as standard format names MUST be RTP formats that are not registered as standard format names MUST
preceded by ``X-''. Use of the ``X-'' prefix is deprecated, and all be preceded by "X-". Use of the ``X-'' prefix is deprecated, and
new formats SHOULD be registered with IANA. Thus a new experimental all new formats SHOULD be registered with IANA. Thus a new
redundant audio stream called GSMLPC using dynamic payload type 99 experimental redundant audio stream called GSMLPC using dynamic
could be specified as: payload type 99 could be specified as:
m=audio 49232 RTP/AVP 99 m=audio 49232 RTP/AVP 99
a=rtpmap:99 X-GSMLPC/8000 a=rtpmap:99 X-GSMLPC/8000
Such an experimental encoding requires that any site wishing to Such an experimental encoding requires that any site wishing to
receive the media stream has relevant configured state in its receive the media stream has relevant configured state in its
session directory to know which tools are appropriate. session directory to know which tools are appropriate.
Note that RTP audio formats typically do not include information Note that RTP audio formats typically do not include information
about the number of samples per packet. If a non-default (as about the number of samples per packet. If a non-default (as
defined in the RTP Audio/Video Profile) packetisation is required, defined in the RTP Audio/Video Profile) packetisation is required,
the``ptime'' attribute is used as given below. the"ptime" attribute is used as given below.
For more details on RTP audio and video formats, see [3].
o Predefined formats for UDP protocol non-RTP media are as below.
Application Formats: For more details on RTP audio and video formats, see [RFC1890].
Predefined applicarion formats for the UDP protocol with non-RTP
media are as below:
wb: LBL Whiteboard (transport: udp) wb: LBL Whiteboard (transport: udp)
nt: UCL Network Text Editor (transport: udp) nt: UCL Network Text Editor (transport: udp)
Suggested Attributes Suggested Attributes
The following attributes are suggested. Since application writers may The following attributes are suggested. Since application writers
add new attributes as they are required, this list is not exhaustive. may add new attributes as they are required, this list is not
exhaustive.
a=cat:<category> a=cat:<category>
This attribute gives the dot-separated hierarchical category of the
session. This is to enable a receiver to filter unwanted sessions This attribute gives the dot-separated hierarchical category of
by category. It would probably have been a compulsory separate the session. This is to enable a receiver to filter unwanted
field, except for its experimental nature at this time. It is a sessions by category. It would probably have been a compulsory
session-level attribute, and is not dependent on charset. separate field, except for its experimental nature at this
time. It is a session-level attribute, and is not dependent on
charset.
a=keywds:<keywords> a=keywds:<keywords>
Like the cat attribute, this is to assist identifying wanted Like the cat attribute, this is to assist identifying wanted
sessions at the receiver. This allows a receiver to select sessions at the receiver. This allows a receiver to select
interesting session based on keywords describing the purpose of the interesting session based on keywords describing the purpose of
session. It is a session-level attribute. It is a charset dependent the session. It is a session-level attribute. It is a charset
attribute, meaning that its value should be interpreted in the dependent attribute, meaning that its value should be
charset specified for the session description if one is specified, interpreted in the charset specified for the session
or by default in ISO 10646/UTF-8. description if one is specified, or by default in ISO
10646/UTF-8.
a=tool:<name and version of tool> a=tool:<name and version of tool>
This gives the name and version number of the tool used to create
the session description. It is a session-level attribute, and is This gives the name and version number of the tool used to
not dependent on charset. create the session description. It is a session-level
attribute, and is not dependent on charset.
a=ptime:<packet time> a=ptime:<packet time>
This gives the length of time in milliseconds represented by the
media in a packet. This is probably only meaningful for audio data, This gives the length of time in milliseconds represented by
but may be used with other media types if it makes sense. It should the media in a packet. This is probably only meaningful for
not be necessary to know ptime to decode RTP or vat audio, and it is audio data, but may be used with other media types if it makes
intended as a recommendation for the encoding/packetisation of sense. It should not be necessary to know ptime to decode RTP
audio. It is a media attribute, and is not dependent on charset. or vat audio, and it is intended as a recommendation for the
encoding/packetisation of audio. It is a media attribute, and
is not dependent on charset.
a=maxptime:<maximum packet time> a=maxptime:<maximum packet time>
The maximum amount of media which can be encapsulated in each The maximum amount of media which can be encapsulated in each
packet, expressed as time in milliseconds. The time SHALL be packet, expressed as time in milliseconds. The time SHALL be
calculated as the sum of the time the media present in the packet calculated as the sum of the time the media present in the
represents. The time SHOULD be a multiple of the frame size. This packet represents. The time SHOULD be a multiple of the frame
attribute is probably only meaningful for audio data, but may be size. This attribute is probably only meaningful for audio
used with other media types if it makes sense. It is a media data, but may be used with other media types if it makes sense.
attribute, and is not dependent on charset. Note that this It is a media attribute, and is not dependent on charset. Note
attribute was introduced after RFC 2327, and non updated that this attribute was introduced after RFC 2327, and non
implementations will ignore this attribute. updated implementations will ignore this attribute.
a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding
parameters>] parameters>]
See the section on Media Announcements (the ``m='' field). This may
be either a session or media attribute. See the section on Media Announcements (the "m=" field). This
may be either a session or media attribute.
a=recvonly a=recvonly
This specifies that the tools should be started in receive-only mode
where applicable. It can be either a session or media attribute, and This specifies that the tools should be started in receive-only
is not dependent on charset. Note that recvonly applies to the media mode where applicable. It can be either a session or media
only, not to any associated control protocol (e.g. an RTP based attribute, and is not dependent on charset. Note that recvonly
system in recvonly mode SHOULD still send RTCP packets). applies to the media only, not to any associated control
protocol (e.g. an RTP based 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
mode. This is necessary for interactive conferences with tools such
as wb which defaults to receive only mode. It can be either a
session or media attribute, and is not dependent on charset.
If none of the attributes "sendonly", "recvonly", "inactive", and This specifies that the tools should be started in send and
"sendrecv" is present, "sendrecv" SHOULD be assumed as the default receive mode. This is necessary for interactive conferences
for sessions which are not of the conference type "broadcast" or with tools such as wb which defaults to receive only mode. It
"H332" (see below). can be either a 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.
An example may be where a different unicast address is to be used This specifies that the tools should be started in send-only
for a traffic destination than for a traffic source. In such a case, mode. An example may be where a different unicast address is
two media descriptions may be use, one sendonly and one recvonly. It to be used for a traffic destination than for a traffic source.
can be either a session or media attribute, but would normally only In such a case, two media descriptions may be use, one sendonly
be used as a media attribute, and is not dependent on charset. Note and one recvonly. It can be either a session or media
that sendonly applies only to the media, and any associated control attribute, but would normally only be used as a media
protocol (e.g. RTCP) SHOULD still be received and processed as attribute, and is not dependent on charset. Note that sendonly
normal. applies only to the media, and any associated control protocol
(e.g. RTCP) SHOULD still be received and processed as normal.
a=inactive a=inactive
This specifies that the tools should be started in inactive mode.
This is necessary for interactive conferences where users can put This specifies that the tools should be started in inactive
other users on hold. No media is sent over an inactive media stream. mode. This is necessary for interactive conferences where
Note that an RTP based system SHOULD still send RTCP, even if users can put other users on hold. No media is sent over an
started inactive. It can be either a session or media attribute, and inactive media stream. Note that an RTP based system SHOULD
is not dependent on charset. still send RTCP, even if started inactive. It can be either a
session or media attribute, and is not dependent on charset.
a=orient:<whiteboard orientation> a=orient:<whiteboard orientation>
Normally this is only used in a whiteboard media specification. It
specifies the orientation of a the whiteboard on the screen. It is Normally this is only used in a whiteboard media specification.
a media attribute. Permitted values are `portrait', `landscape' and It specifies the orientation of a the whiteboard on the screen.
`seascape' (upside down landscape). It is not dependent on charset. It is a media attribute. Permitted values are "portrait",
"landscape" and "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
`broadcast', `meeting', `moderated', `test' and `H332'. `recvonly'
should be the default for `type:broadcast' sessions, `type:meeting'
should imply `sendrecv' and `type:moderated' should indicate the use
of a floor control tool and that the media tools are started so as
to ``mute'' new sites joining the conference.
Specifying the attribute type:H332 indicates that this loosely This specifies the type of the conference. Suggested values
coupled session is part of a H.332 session as defined in the ITU are "broadcast", "meeting", "moderated", "test" and "H332".
H.332 specification [10]. Media tools should be started `recvonly'. "recvonly" should be the default for "type:broadcast" sessions,
"type:meeting" should imply "sendrecv" and "type:moderated"
should indicate the use of a floor control tool and that the
media tools are started so as to mute new sites joining the
conference.
Specifying the attribute type:test is suggested as a hint that, Specifying the attribute "type:H332" indicates that this
unless explicitly requested otherwise, receivers can safely avoid loosely coupled session is part of a H.332 session as defined
displaying this session description to users. in the ITU H.332 specification [H.332]. Media tools should be
started "recvonly".
Specifying the attribute "type:test" is suggested as a hint
that, unless explicitly requested otherwise, receivers can
safely avoid displaying this session description to users.
The type attribute is a session-level attribute, and is not The type attribute is a session-level attribute, and is not
dependent on charset. dependent on charset.
a=charset:<character set> a=charset:<character set>
This specifies the character set to be used to display the session This specifies the character set to be used to display the
name and information data. By default, the ISO-10646 character set session name and information data. By default, the ISO-10646
in UTF-8 encoding is used. If a more compact representation is character set in UTF-8 encoding is used. If a more compact
required, other character sets may be used such as ISO-8859-1 for representation is required, other character sets may be used
Northern European languages. In particular, the ISO 8859-1 is such as ISO-8859-1 for Northern European languages. In
specified with the following SDP attribute: particular, the ISO 8859-1 is specified with the following SDP
attribute:
a=charset:ISO-8859-1 a=charset:ISO-8859-1
This is a session-level attribute; if this attribute is present, it This is a session-level attribute; if this attribute is
must be before the first media field. The charset specified MUST be present, it must be before the first media field. The charset
one of those registered with IANA, such as ISO-8859-1. The specified MUST be one of those registered with IANA, such as
character set identifier is a US-ASCII string and MUST be compared ISO-8859-1. The character set identifier is a US-ASCII string
against the IANA identifiers using a case-insensitive comparison. and MUST be compared against the IANA identifiers using a case-
If the identifier is not recognised or not supported, all strings insensitive comparison. If the identifier is not recognised or
that are affected by it SHOULD be regarded as octet strings. not supported, all strings that are affected by it SHOULD be
regarded as octet strings.
Note that a character set specified MUST still prohibit the use of Note that a character set specified MUST still prohibit the use
bytes 0x00 (Nul), 0x0A (LF) and 0x0d (CR). Character sets requiring of bytes 0x00 (Nul), 0x0A (LF) and 0x0d (CR). Character sets
the use of these characters MUST define a quoting mechanism that requiring the use of these characters MUST define a quoting
prevents these bytes appearing within text fields. mechanism that prevents these bytes appearing within text
fields.
a=sdplang:<language tag> a=sdplang:<language tag>
This can be a session level attribute or a media level attribute.
As a session level attribute, it specifies the language for the This can be a session level attribute or a media level
session description. As a media level attribute, it specifies the attribute. As a session level attribute, it specifies the
language for any media-level SDP information field associated with language for the session description. As a media level
that media. Multiple sdplang attributes can be provided either at attribute, it specifies the language for any media-level SDP
session or media level if multiple languages in the session information field associated with that media. Multiple sdplang
description or media use multiple languages, in which case the order attributes can be provided either at session or media level if
of the attributes indicates the order of importance of the various multiple languages in the session description or media use
languages in the session or media from most important to least multiple languages, in which case the order of the attributes
important. indicates the order of importance of the various languages in
the session or media from most important to least important.
In general, sending session descriptions consisting of multiple In general, sending session descriptions consisting of multiple
languages is discouraged. Instead, multiple descriptions SHOULD be languages is discouraged. Instead, multiple descriptions
sent describing the session, one in each language. However this is SHOULD be sent describing the session, one in each language.
not possible with all transport mechanisms, and so multiple sdplang However this is not possible with all transport mechanisms, and
attributes are allowed although NOT RECOMMENDED. so multiple sdplang 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
in US-ASCII. It is not dependent on the charset attribute. An language tag in US-ASCII. It is not dependent on the charset
sdplang attribute SHOULD be specified when a session is of attribute. An "sdplang" attribute SHOULD be specified when a
sufficient scope to cross geographic boundaries where the language session is of sufficient scope to cross geographic boundaries
of recipients cannot be assumed, or where the session is in a where the language of recipients cannot be assumed, or where
different language from the locally assumed norm. the session is in a 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.
As a session level attribute, it specifies the default language for
the session being described. As a media level attribute, it
specifies the language for that media, overriding any session-level
language specified. Multiple lang attributes can be provided either
at session or media level if multiple languages if the session
description or media use multiple languages, in which case the order
of the attributes indicates the order of importance of the various
languages in the session or media from most important to least
important.
The lang attribute value must be a single RFC 1766 language tag in This can be a session level attribute or a media level
US-ASCII. It is not dependent on the charset attribute. A lang attribute. As a session level attribute, it specifies the
attribute SHOULD be specified when a session is of sufficient scope default language for the session being described. As a media
to cross geographic boundaries where the language of recipients level attribute, it specifies the language for that media,
cannot be assumed, or where the session is in a different language overriding any session-level language specified. Multiple lang
from the locally assumed norm. attributes can be provided either at session or media level if
multiple languages if the session description or media use
multiple languages, in which case the order of the attributes
indicates the order of importance of the various languages in
the session or media from most important to least important.
The "lang" attribute value must be a single RFC 1766 language
tag in US-ASCII. It is not dependent on the charset attribute.
A "lang" attribute SHOULD be specified when a session is of
sufficient scope to cross geographic boundaries where the
language of recipients cannot be assumed, or where the session
is in a different language from the locally assumed norm.
a=framerate:<frame rate> a=framerate:<frame rate>
This gives the maximum video frame rate in frames/sec. It is This gives the maximum video frame rate in frames/sec. It is
intended as a recommendation for the encoding of video data. intended as a recommendation for the encoding of video data.
Decimal representations of fractional values using the notation Decimal representations of fractional values using the notation
"<integer>.<fraction>" are allowed. It is a media attribute, is "<integer>.<fraction>" are allowed. It is a media attribute,
only defined for video media, and is not dependent on charset. is only defined for video media, and is not dependent on
charset.
a=quality:<quality> a=quality:<quality>
This gives a suggestion for the quality of the encoding as an
integer value.
The intention of the quality attribute for video is to specify a This gives a suggestion for the quality of the encoding as an
non-default trade-off between frame-rate and still-image quality. integer value. The intention of the quality attribute for
For video, the value in the range 0 to 10, with the following video is to specify a non-default trade-off between frame-rate
suggested meaning: and still-image quality. For video, the value in the range 0
to 10, with the following suggested meaning:
10 - the best still-image quality the compression scheme can give.
10 - the best still-image quality the compression scheme can
give.
5 - the default behaviour given no quality suggestion. 5 - the default behaviour given no quality suggestion.
0 - the worst still-image quality the codec designer thinks
is still usable.
0 - the worst still-image quality the codec designer thinks is
still usable.
It is a media attribute, and is not dependent on charset. It is a media attribute, and is not dependent on charset.
a=fmtp:<format> <format specific parameters> a=fmtp:<format> <format specific parameters>
This attribute allows parameters that are specific to a particular
format to be conveyed in a way that SDP doesn't have to understand This attribute allows parameters that are specific to a
them. The format must be one of the formats specified for the particular format to be conveyed in a way that SDP doesn't have
media. Format-specific parameters may be any set of parameters to understand them. The format must be one of the formats
required to be conveyed by SDP and given unchanged to the media tool specified for the media. Format-specific parameters may be any
that will use this format. set of parameters required to be conveyed by SDP and given
unchanged to the media tool that will use this format.
It is a media attribute, and is not dependent on charset. It is a media attribute, and is not dependent on charset.
6.1. Communicating Conference Control Policy 5.1. Communicating Conference Control Policy
There is some debate over the way conference control policy should be There is some debate over the way conference control policy should be
communicated. In general, the authors believe that an implicit communicated. In general, the authors believe that an implicit
declarative style of specifying conference control is desirable where declarative style of specifying conference control is desirable where
possible. possible.
A simple declarative style uses a single conference attribute field A simple declarative style uses a single conference attribute field
before the first media field, possibly supplemented by properties such before the first media field, possibly supplemented by properties
as `recvonly' for some of the media tools. This conference attribute such as `recvonly' for some of the media tools. This conference
conveys the conference control policy. An example might be: attribute conveys the conference control policy. An example might
be:
a=type:moderated a=type:moderated
In some cases, however, it is possible that this may be insufficient to In some cases, however, it is possible that this may be insufficient
communicate the details of an unusual conference control policy. If to communicate the details of an unusual conference control policy.
this is the case, then a conference attribute specifying external If this is the case, then a conference attribute specifying external
control might be set, and then one or more ``media'' fields might be control might be set, and then one or more "media" fields might be
used to specify the conference control tools and configuration data for used to specify the conference control tools and configuration data
those tools. An example is an ITU H.332 session: for those tools. An example is an ITU H.332 session:
... ...
c=IN IP4 224.5.6.7 c=IN IP4 224.5.6.7
a=type:H332 a=type:H332
m=audio 49230 RTP/AVP 0 m=audio 49230 RTP/AVP 0
m=video 49232 RTP/AVP 31 m=video 49232 RTP/AVP 31
m=application 12349 udp wb m=application 12349 udp wb
m=control 49234 H323 mc m=control 49234 H323 mc
c=IN IP4 134.134.157.81 c=IN IP4 134.134.157.81
In this example, a general conference attribute (type:H332) is specified In this example, a general conference attribute (type:H332) is
stating that conference control will be provided by an external H.332 specified stating that conference control will be provided by an
tool, and a contact addresses for the H.323 session multipoint external H.332 tool, and a contact addresses for the H.323 session
controller is given. multipoint controller is given.
In this document, only the declarative style of conference control In this document, only the declarative style of conference control
declaration is specified. Other forms of conference control should declaration is specified. Other forms of conference control should
specify an appropriate type attribute, and should define the specify an appropriate type attribute, and should define the
implications this has for control media. implications this has for control media.
7. Security Considerations 6. Security Considerations
SDP is a session description format that describes multimedia sessions. SDP is a session description format that describes multimedia
A session description SHOULD NOT be trusted unless it has been obtained sessions. A session description SHOULD NOT be trusted unless it has
by an authenticated transport protocol from a trusted source. Many been obtained by an authenticated transport protocol from a trusted
different transport protocols may be used to distribute session source. Many different transport protocols may be used to distribute
description, and the nature of the authentication will differ from session description, and the nature of the authentication will differ
transport to transport. from transport to transport.
One transport that will frequently be used to distribute session One transport that will frequently be used to distribute session
descriptions is the Session Announcement Protocol (SAP). SAP provides descriptions is the Session Announcement Protocol (SAP). SAP
both encryption and authentication mechanisms but due to the nature of provides both encryption and authentication mechanisms but due to the
session announcements it is likely that there are many occasions where nature of session announcements it is likely that there are many
the originator of a session announcement cannot be authenticated because occasions where the originator of a session announcement cannot be
they are previously unknown to the receiver of the announcement and authenticated because they are previously unknown to the receiver of
because no common public key infrastructure is available. the announcement and because no common public key infrastructure is
available.
On receiving a session description over an unauthenticated transport On receiving a session description over an unauthenticated transport
mechanism or from an untrusted party, software parsing the session mechanism or from an untrusted party, software parsing the session
should take a few precautions. Session descriptions contain information should take a few precautions. Session descriptions contain
required to start software on the receivers system. Software that information required to start software on the receivers system.
parses a session description MUST NOT be able to start other software Software that parses a session description MUST NOT be able to start
except that which is specifically configured as appropriate software to other software except that which is specifically configured as
participate in multimedia sessions. It is normally considered appropriate software to participate in multimedia sessions. It is
inappropriate for software parsing a session description to start, on a normally considered inappropriate for software parsing a session
user's system, software that is appropriate to participate in multimedia description to start, on a user's system, software that is
sessions, without the user first being informed that such software will appropriate to participate in multimedia sessions, without the user
be started and giving their consent. Thus a session description first being informed that such software will be started and giving
arriving by session announcement, email, session invitation, or WWW page their consent. Thus a session description arriving by session
SHOULD NOT deliver the user into an interactive multimedia session announcement, email, session invitation, or WWW page SHOULD NOT
without the user being aware that this will happen. As it is not always deliver the user into an interactive multimedia session without the
simple to tell whether a session is interactive or not, applications user being aware that this will happen. As it is not always simple
that are unsure should assume sessions are interactive. to tell whether a session is interactive or not, applications that
are unsure should assume sessions are interactive.
In this specification, there are no attributes which would allow the In this specification, there are no attributes which would allow the
recipient of a session description to be informed to start multimedia recipient of a session description to be informed to start multimedia
tools in a mode where they default to transmitting. Under some tools in a mode where they default to transmitting. Under some
circumstances it might be appropriate to define such attributes. If circumstances it might be appropriate to define such attributes. If
this is done an application parsing a session description containing this is done an application parsing a session description containing
such attributes SHOULD either ignore them, or inform the user that such attributes SHOULD either ignore them, or inform the user that
joining this session will result in the automatic transmission of joining this session will result in the automatic transmission of
multimedia data. The default behaviour for an unknown attribute is to multimedia data. The default behaviour for an unknown attribute is
ignore it. to ignore it.
Session descriptions may be parsed at intermediate systems such as Session descriptions may be parsed at intermediate systems such as
firewalls for the purposes of opening a hole in the firewall to allow firewalls for the purposes of opening a hole in the firewall to allow
the participation in multimedia sessions. It is considered the participation in multimedia sessions. It is considered
inappropriate for a firewall to open such holes for unicast data streams inappropriate for a firewall to open such holes for unicast data
streams unless the session description comes in a request from inside
the firewall. For multicast sessions, it is likely that local
administrators will apply their own policies, but the exclusive use
of "local" or "site-local" administrative scope within the firewall
and the refusal of the firewall to open a hole for such scopes will
provide separation of global multicast sessions from local ones.
unless the session description comes in a request from inside the Use of the "k=" field poses a significant security risk, since it
firewall. For multicast sessions, it is likely that local conveys session encryption keys in the clear. SDP MUST NOT be used
administrators will apply their own policies, but the exclusive use of to convey key material, unless it can be guaranteed that the channel
"local" or "site-local" administrative scope within the firewall and the over which the SDP is delivered is both private and authenticated.
refusal of the firewall to open a hole for such scopes will provide
separation of global multicast sessions from local ones.
Appendix A: SDP Grammar Appendix A: SDP Grammar
This appendix provides an Augmented BNF grammar for SDP. ABNF is This appendix provides an Augmented BNF grammar for SDP. ABNF is
defined in RFC 2234. defined in RFC 2234.
; SDP Syntax ; SDP Syntax
announcement = proto-version announcement = proto-version
origin-field origin-field
session-name-field session-name-field
skipping to change at page 34, line 29 skipping to change at page 33, line 28
zone-adjustments = "z=" time SP ["-"] typed-time zone-adjustments = "z=" time SP ["-"] typed-time
*(SP time SP ["-"] typed-time) *(SP time SP ["-"] typed-time)
key-field = ["k=" key-type CRLF] key-field = ["k=" key-type CRLF]
attribute-fields = *("a=" attribute CRLF) attribute-fields = *("a=" attribute CRLF)
media-descriptions = *( media-field media-descriptions = *( media-field
information-field information-field
connection-field *connection-field
bandwidth-fields bandwidth-fields
key-field key-field
attribute-fields ) attribute-fields )
media-field = "m=" media SP port ["/" integer] media-field = "m=" media SP port ["/" integer]
SP proto 1*(SP fmt) CRLF SP proto 1*(SP fmt) CRLF
; sub-rules of 'o=' ; sub-rules of 'o='
username = non-ws-string username = non-ws-string
;pretty wide definition, but doesn't include space ;pretty wide definition, but doesn't
;include space
sess-id = 1*DIGIT sess-id = 1*DIGIT
;should be unique for this originating username/host ;should be unique for this username/host
sess-version = 1*DIGIT sess-version = 1*DIGIT
;0 is a new session ;0 is a new session
nettype = token nettype = token
;typically "IN" ;typically "IN"
addrtype = token addrtype = token
;typically "IP4" or "IP6" ;typically "IP4" or "IP6"
skipping to change at page 37, line 23 skipping to change at page 36, line 22
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 be either "0" or in the range "1024" to "65535" ;should be either "0" or in the range "1024" to
;inclusive for UDP based media (a value "0" is used to ;"65535" inclusive for UDP based media (a value
;signal special conditions in some uses of SDP) ;"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
skipping to change at page 38, line 37 skipping to change at page 37, line 38
; generic sub-rules: datatypes ; generic sub-rules: datatypes
text = byte-string text = byte-string
;default is to interpret this as IS0-10646 UTF8 ;default is to interpret this as IS0-10646 UTF8
;ISO 8859-1 requires a "a=charset:ISO-8859-1" ;ISO 8859-1 requires a "a=charset:ISO-8859-1"
;session-level attribute to be used ;session-level attribute to be used
byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF)
;any byte except NUL, CR or LF ;any byte except NUL, CR or LF
non-ws-string = 1*(VCHAR/%x80-FF) non-ws-string = 1*(VCHAR/%x80-FF)
;string of visible US-ASCII, or high-bit, characters ;string of visible characters
token-char = %x21/%x23-27/%x2A-2B/%x2D-2E/%x30-39/%x41-5A/%x5E-7E token-char = %x21/%x23-27/%x2A-2B/%x2D-2E/%x30-39/%x41-5A/%x5E-7E
; definition from RFC 2045 - ; definition from RFC 2045 -
; "any (US-ASCII) CHAR except SPACE, CTLs, ; "any (US-ASCII) CHAR except SPACE, CTLs,
; or tspecials". ; or tspecials".
; the tspecials are ()<>@,;: ; the tspecials are ()<>@,;:
token = 1*(token-char) token = 1*(token-char)
email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF
;any byte except NUL, CR, LF, or the quoting ;any byte except NUL, CR, LF, or the quoting
;characters ()<> ;characters ()<>
integer = POS-DIGIT *DIGIT integer = POS-DIGIT *DIGIT
; generic sub-rules: primitives ; generic sub-rules: primitives
alpha-numeric = ALPHA / DIGIT alpha-numeric = ALPHA / DIGIT
POS-DIGIT = %x31-39 ; 1 - 9 POS-DIGIT = %x31-39 ; 1 - 9
decimal-uchar = DIGIT
/ POS-DIGIT DIGIT
/ ("1" 2*(DIGIT))
/ ("2" ("0"/"1"/"2"/"3"/"4") DIGIT)
/ ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5"))
; external references: ; external references:
; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 2234 ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 2234
; URI-reference: from RFC1630 and RFC2732 ; URI-reference: from RFC1630 and RFC2732
; addr-spec: from RFC 2822 ; addr-spec: from RFC 2822
Appendix B: IANA Considerations Appendix B: IANA Considerations
There are seven field names that may be registered with IANA. Using the There are seven field names that may be registered with IANA. Using
terminology in the SDP specification BNF, they are "media", "proto", the terminology in the SDP specification BNF, they are "media",
"fmt", "att-field", "bwtype", "nettype" and "addrtype". "proto", "fmt", "att-field", "bwtype", "nettype" and "addrtype".
"media" (eg, audio, video, application, data). "media" (e.g., audio, video, application, data).
The set of media is intended to be small and not to be extended The set of media is intended to be small and SHOULD NOT be
except under rare circumstances. The same rules should apply for extended except under rare circumstances. The same rules should
media names as for top-level MIME content types, and where possible apply for media names as for top-level MIME content types, and
the same name should be registered for SDP as for MIME. For media where possible the same name should be registered for SDP as for
other than existing MIME top-level content types, a standards-track MIME. For media other than existing MIME top-level content types,
RFC MUST be produced for a new top-level content type to be a standards-track RFC MUST be produced for a new top-level content
registered, and the registration MUST provide good justification type to be registered, and the registration MUST provide good
why no existing media name is appropriate. justification why no existing media name is appropriate (the
"Standards Action" policy of RFC 2434 [RFC2434]).
"proto" "proto"
In general this should be an IETF standards-track transport The "proto" field describes the transport protocol used. This
protocol identifier such as RTP/AVP (rfc 1889 under the rfc 1890 SHOULD reference a standards-track protocol RFC. This memo
profile). registers three values: "RTP/AVP" is a reference to RTP [RFC1889]
used under the RTP Profile for Audio and Video Conferences with
However, people will want to invent their own proprietary transport Minimal Control [RFC1890]) running over UDP/IP; "TCP" denotes an
protocols. Some of these should be registered as a "fmt" using unspecified format over TCP; and "udp" indicates an unspecified
"udp" as the protocol and some of which probably can't be. format over UDP.
Where the protocol and the application are intimately linked, such New transport protocols MAY be registered with IANA. Registrations
as with the LBL whiteboard wb which used a proprietary and special MUST reference an RFC describing the protocol. Such an RFC MAY be
purpose protocol over UDP, the protocol name should be "udp" and Experimental or Informational, although it is preferable if it is
the format name that should be registered is "wb". The rules for Standards-Track. Registrations MUST also define the rules by which
formats (see below) apply to such registrations. their "fmt" namespace is managed (see below).
Where the proprietary transport protocol really carries many Application-specific proprietary protocols that run over an
different data formats, it is possible to register a new protocol existing transport protocol SHOULD be registered as a "fmt". The
name with IANA. In such a case, an RFC MUST be produced describing rules for formats (see below) apply to such registrations. An
the protocol and referenced in the registration. Such an RFC MAY example is the LBL whiteboard application, which uses the proto
be informational, although it is preferable if it is standards- "udp" with "wb" as the format.
track.
"fmt" "fmt"
The format namespace is dependent on the context of the "proto" Each transport protocol, defined by the "proto" field, has an
field, so a format cannot be registered without specifying one or associated "fmt" namespace that describes the media formats which
more transport protocols that it applies to. may conveyed by that protocol. Formats cover all the possible
encodings that might want to be transported in a multimedia
session.
Formats cover all the possible encodings that might want to be RTP payload formats under the "RTP/AVP" protocol that have been
transported in a multimedia session. assigned static payload types MUST use the static payload type as
their "fmt" value. For payload formats under "RTP/AVP" that have
a dynamic payload type number, the dynamic payload type number is
given as the "fmt" and an additional "rtpmap" attribute specifies
the format name and parameters.
For RTP formats that have been assigned static payload types, the For "TCP" and "udp" protocols, new formats may be registered. If
payload type number is used. For RTP formats using a dynamic there is a suitable mapping from a MIME subtype to the format, it
payload type number, the dynamic payload type number is given as is RECOMMENDED that the MIME subtype name be used as the "fmt"
the format and an additional "rtpmap" attribute specifies the name. If there is no suitable mapping from a MIME subtype, a new
format and parameters. name should be registered. In either case, a standards-track RFC
MUST be produced describing the format and this RFC MUST be
referenced in the registration.
For non-RTP formats, any unregistered format name may be For other protocols, formats MAY be registered according to the
registered. If there is a suitable mapping from a MIME subtype to rules of the associated "proto" specification.
the format, then the MIME subtype name should be registered. If
there is no suitable mapping from a MIME subtype, a new name should Registrations of new formats MUST specify which transport
be registered. In either case, unless there are strong reasons not protocols they apply to.
to do so, a standards-track RFC SHOULD be produced describing the
format and this RFC SHOULD be referenced in the registration.
"att-field" (Attribute names) "att-field" (Attribute names)
Attribute field names SHOULD be registered with IANA, although this Attribute field names MUST be registered with IANA and documented,
is not compulsory, and unknown attributes are simply ignored. because of noticeable issues due to conflicting attributes under
the same name. Unknown attributes in SDP are simply ignored, but
conflicting ones that fragment the protocol are a serious problem.
When an attribute is registered, it must be accompanied by a brief New attributes MAY be registered according to the "Specification
specification stating the following: Required" policy of RFC 2434, provided that the specification
includes the following information:
o contact name, email address and telephone number o contact name, email address and telephone number
o attribute-name (as it will appear in SDP) o attribute-name (as it will appear in SDP)
o long-form attribute name in English o long-form attribute name in English
o type of attribute (session level, media level, or both) o type of attribute (session level, media level, or both)
o whether the attribute value is subject to the charset o whether the attribute value is subject to the charset
attribute. attribute.
o a one paragraph explanation of the purpose of the attribute. o a one paragraph explanation of the purpose of the attribute.
o a specification of appropriate attribute values for this o a specification of appropriate attribute values for this
attribute. attribute.
IANA will not sanity check such attribute registrations except to The above is the minimum that IANA will accept. Attributes that
ensure that they do not clash with existing registrations. are expected to see widespread use and interoperability, SHOULD be
documented with a standards-track RFC that specifies the attribute
Although the above is the minimum that IANA will accept, if the more precisely.
attribute is expected to see widespread use and interoperability is
an issue, authors are encouraged to produce a standards-track RFC
that specifies the attribute more precisely.
Submitters of registrations should ensure that the specification is Submitters of registrations should ensure that the specification
in the spirit of SDP attributes, most notably that the attribute is is in the spirit of SDP attributes, most notably that the
platform independent in the sense that it makes no implicit attribute is platform independent in the sense that it makes no
assumptions about operating systems and does not name specific implicit assumptions about operating systems and does not name
pieces of software in a manner that might inhibit interoperability. specific pieces of software in a manner that might inhibit
interoperability.
"bwtype" (bandwidth specifiers) "bwtype" (bandwidth specifiers)
A proliferation of bandwidth specifiers is strongly discouraged. A proliferation of bandwidth specifiers is strongly discouraged.
New bandwidth specifiers may be registered with IANA. The New bandwidth specifiers MUST be registered with IANA. The
submission MUST reference a standards-track RFC specifying the submission MUST reference a standards-track RFC specifying the
semantics of the bandwidth specifier precisely, and indicating when semantics of the bandwidth specifier precisely, and indicating
it should be used, and why the existing registered bandwidth when it should be used, and why the existing registered bandwidth
specifiers do not suffice. specifiers do not suffice.
"nettype" (Network Type) "nettype" (Network Type)
New network types may be registered with IANA if SDP needs to be New network types may be registered with IANA if SDP needs to be
used in the context of non-Internet environments. Whilst these are used in the context of non-Internet environments. Whilst these
not normally the preserve of IANA, there may be circumstances when are not normally the preserve of IANA, there may be circumstances
an Internet application needs to interoperate with a non-Internet when an Internet application needs to interoperate with a non-
application, such as when gatewaying an Internet telephony call Internet application, such as when gatewaying an Internet
into the PSTN. The number of network types should be small and telephony call into the PSTN. The number of network types should
should be rarely extended. A new network type cannot be registered be small and should be rarely extended. A new network type cannot
without registering at least one address type to be used with that be registered without registering at least one address type to be
network type. A new network type registration MUST reference an used with that network type. A new network type registration MUST
RFC which gives details of the network type and address type and reference an RFC which gives details of the network type and
specifies how and when they would be used. Such an RFC MAY be address type and specifies how and when they would be used. Such
Informational. an RFC MAY be Informational.
"addrtype" (Address Type) "addrtype" (Address Type)
New address types may be registered with IANA. An address type is New address types may be registered with IANA. An address type is
only meaningful in the context of a network type, and any only meaningful in the context of a network type, and any
registration of an address type MUST specify a registered network registration of an address type MUST specify a registered network
type, or be submitted along with a network type registration. A type, or be submitted along with a network type registration. A
new address type registration MUST reference an RFC giving details new address type registration MUST reference an RFC giving details
of the syntax of the address type. Such an RFC MAY be of the syntax of the address type. Such an RFC MAY be
Informational. Address types are not expected to be registered Informational. Address types are not expected to be registered
frequently. frequently.
Registration Procedure Registration Procedure
To register a name the above guidelines should be followed regarding the In the RFC documentation that registers SDP "media", "proto", "fmt",
required level of documentation that is required. The registration "bwtype", "nettype" and "addrtype" fields, the authors MUST include
itself should be sent to IANA. Attribute registrations should include the following information for IANA to place in the appropriate
the information given above. Other registrations should include the registry:
following additional information:
o contact name, email address and telephone number o contact name, email address and telephone number
o name being registered (as it will appear in SDP) o name being registered (as it will appear in SDP)
o long-form name in English o long-form name in English
o type of name ("media", "proto", "fmt", "bwtype", "nettype", or o type of name ("media", "proto", "fmt", "bwtype", "nettype", or
"addrtype") "addrtype")
o a one paragraph explanation of the purpose of the registered name. o a one paragraph explanation of the purpose of the registered
o a reference to the specification (eg RFC number) of the registered
name. name.
IANA may refer any registration to the IESG or to any appropriate IETF o a reference to the specification (e.g. RFC number) of the
working group for review, and may request revisions to be made before a registered name.
IANA may refer any registration to the IESG Transport Area Directors
for review, and may request revisions to be made before a
registration will be made. registration will be made.
Appendix C: Changes from RFC 2327 Appendix C: Changes from RFC 2327
o Clarify that a=recvonly does NOT mean that you don't send RTCP, and o Deprecate X- notation for experimental parameters
similarly for sendonly and inactive. These only effect the RTP
stream.
o Rewrite the ABNF syntax (thanks to Jonathan Lennox) o Clarify that a=recvonly does NOT mean that you don't send
RTCP, and similarly for sendonly and inactive. These only
effect the RTP stream.
o Rewrite and correct the ABNF syntax (thanks to Jonathan Lennox)
o Update BNF to support IPv6.
o Add a=inactive attribute. o Add a=inactive attribute.
o Add a=maxptime attribute. o Add a=maxptime attribute.
o RFC 2327 mandated that either e= or p= was required. Both are now o RFC 2327 mandated that either e= or p= was required. Both are
optional, to reflect actual usage. now optional, to reflect actual usage.
o Removed references to "conference" from the description of the t= o Removed references to "conference" from the description of
line, to make it less SAP oriented. the t= line, to make it less SAP oriented.
o Note about wrap-around of NTP timestamps in t= o Note about wrap-around of NTP timestamps in t=
o Update BNF to support IPv6. o References have been updated and split into normative and
informative sections.
o References have been updated.
o Section 3.1 was replaced with a reference to RFC 2119, and the memo o Section 3.1 was replaced with a reference to RFC 2119, and
has been updated to use the RFC 2119 terminology (MUST, SHOULD, the memo has been updated to use the RFC 2119 terminology
etc). (MUST, SHOULD, etc).
o Use of "application/sdp" as MIME a type for SDP files is now "MUST" o Use of "application/sdp" as MIME a type for SDP files is now
rather than "SHOULD". "MUST" rather than "SHOULD".
o A number of sections have been updated to be less SAP specific, and o Many sections have been updated to be less SAP specific, and
to reference other current uses of SDP such as RTSP and SIP. to reference other current uses of SDP such as RTSP and SIP.
o The section on concatenation of session descriptions (which was not o The introduction and background has been rewritten, to remove
allowed in SAP, but allowed in other cases) has been removed. It is references to the Mbone, reflecting current use of SDP.
assumed that transports of SDP specify will specify this.
o The description of the c= line has been updated to reflect common o The section on concatenation of session descriptions (which
usage of SDP, rather than Mbone conferencing with SAP. was not allowed in SAP, but allowed in other cases) has been
removed. It is assumed that transports of SDP specify will
specify this.
o The b= line no longer makes a normative reference to the Mbone FAQ o The description of the c= line has been updated to reflect
for bandwidth limits at various TTLs. The AS modifier to b= is common usage of SDP, rather than Mbone conferencing with SAP.
noted as being the RTP session bandwidth.
o The b= line no longer makes a normative reference to the
Mbone FAQ for bandwidth limits at various TTLs. The AS
modifier to b= is noted as being the RTP session bandwidth.
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 Allow a=rtpmap to be a session level attribute, in addition
to a media level attribute
Appendix D: Authors' Addresses o Clarify the limitations of the k= field
o Clarify IANA considerations
Appendix D: Authors' Addresses
Mark Handley Mark Handley
International Computer Science Institute, International Computer Science Institute,
1947 Center Street, Suite 600, 1947 Center Street, Suite 600,
Berkeley, CA 94704 Berkeley, CA 94704
United States United States
Email: mjh@icir.org Email: mjh@icir.org
Van Jacobson Van Jacobson
Packet Design Packet Design
2465 Latham Street 2465 Latham Street
skipping to change at page 45, line 35 skipping to change at page 44, line 28
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@csperkins.org Email: csp@csperkins.org
Acknowledgments Acknowledgments
Many people in the IETF MMUSIC working group have made comments and Many people in the IETF MMUSIC working group have made comments and
suggestions contributing to this document. In particular, we would like suggestions contributing to this document. In particular, we would
to thank Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross like to thank Eve Schooler, Steve Casner, Bill Fenner, Allison
Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna and Mankin, Ross Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann,
Jonathan Lennox. Steve Hanna and Jonathan Lennox.
References Full Copyright Statement
[1] D. Mills, ``Network Time Protocol (version 3) specification and Copyright (C) The Internet Society 2003. All Rights Reserved.
implementation", RFC 1305, March 1992.
[2] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, ``RTP: A This document and translations of it may be copied and furnished to
Transport Protocol for Real-Time Applications'', RFC 1889, January others, and derivative works that comment on or otherwise explain it
1996. or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
[3] H. Schulzrinne, ``RTP Profile for Audio and Video Conferences with The limited permissions granted above are perpetual and will not be
Minimal Control'', RFC 1890, January 1996. revoked by the Internet Society or its successors or assigns.
[4] M. Handley, C. Perkins and E. Whelan, ``Session Announcement This document and the information contained herein is provided on an
Protocol'', RFC 2974, October 2000. "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
[5] V. Jacobson and S. McCanne, ``vat - X11-based audio teleconferencing Intellectual Property
tool'' vat manual page, Lawrence Berkeley Laboratory, 1994.
[6] The Unicode Consortium, "The Unicode Standard -- Version 2.0", The IETF takes no position regarding the validity or scope of any
Addison-Wesley, 1996. intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
[7] ISO/IEC 10646-1:1993. International Standard -- Information The IETF invites any interested party to bring to its attention any
technology -- Universal Multiple-Octet Coded Character Set (UCS) copyrights, patents or patent applications, or other proprietary
-- Part 1: Architecture and Basic Multilingual Plane. Five rights which may cover technology that may be required to practice
amendments and a technical corrigendum have been published up this standard. Please address the information to the IETF Executive
to now. UTF-8 is described in Annex R, published as Amendment 2. Director.
[8] D. Goldsmith and M. Davis, ``Using Unicode with MIME'', RFC1641, Normative References
[9] F. Yergeau, ``UTF-8, a transformation format of ISO 10646'', [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
RFC 2279, January 1998 Requirement Levels", RFC 2119, March 1997.
[10] ITU-T Recommendation H.332 (1998): "Multimedia Terminal for [RFC2434] T. Narten and H. Alvestrand, "Guidelines for Writing an
Receiving Internet-based H.323 Conferences", ITU, Geneva. IANA Considerations Section in RFCs", RFC 2434, October
1998.
[11] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, Informative References
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 [RFC1305] D. Mills, "Network Time Protocol (version 3) specification
Protocol (RTSP)'' RFC 2326, April 1998. and implementation", RFC 1305, March 1992.
[13] S. Bradner, ``Key words for use in RFCs to Indicate Requirement [RFC1889] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson,
Levels'', RFC 2119, March 1997. "RTP: A Transport Protocol for Real-Time Applications",
RFC 1889, January 1996.
[14] J. Rosenberg and H. Schulzrinne, ``An Offer/Answer Model with [RFC1890] H. Schulzrinne, "RTP Profile for Audio and Video
SDP'', RFC 3264, May 2002. Conferences with Minimal Control", RFC 1890, January
1996.
[RFC2974] M. Handley, C. Perkins and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000.
[H.332] ITU-T Recommendation H.332 (1998): "Multimedia Terminal for
Receiving Internet-based H.323 Conferences", ITU, Geneva.
[RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, E. Schooler "SIP: Session
Initiatation Protocol", RFC 3261, May 2002.
[RFC2326] H. Schulzrinne, A. Rao and R. Lanphier, "Real Time
Streaming Protocol (RTSP)" RFC 2326, April 1998.
[RFC3264] J. Rosenberg and H. Schulzrinne, "An Offer/Answer Model
with SDP", RFC 3264, May 2002.
 End of changes. 261 change blocks. 
914 lines changed or deleted 1019 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/