draft-ietf-mmusic-sdp-new-13.txt   draft-ietf-mmusic-sdp-new-14.txt 
Internet Engineering Task Force MMUSIC WG Network Working Group M. Handley
INTERNET-DRAFT Mark Handley/ICSI Internet-Draft UCL
draft-ietf-mmusic-sdp-new-13.txt Van Jacobson/Packet Design Obsoletes: 2327, 3266 (if V. Jacobson
Colin Perkins/ISI approved) Packet Design
22 May 2003 Expires: March 4, 2004 C. Perkins
Expires: November 2003 University of Glasgow
September 4, 2003
SDP: Session Description Protocol SDP: Session Description Protocol
draft-ietf-mmusic-sdp-new-14.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that other
other groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-Drafts.
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 time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at http://
http://www.ietf.org/ietf/1id-abstracts.txt www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This document is a product of the Multiparty Multimedia Session This Internet-Draft will expire on March 4, 2004.
Control (MMUSIC) working group of the Internet Engineering Task
Force. Comments are solicited and should be addressed to the working
group's mailing list at mmusic@ietf.org and/or the authors.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This memo defines the Session Description Protocol (SDP). SDP is This memo defines the Session Description Protocol (SDP). SDP is
intended for describing multimedia sessions for the purposes of intended for describing multimedia sessions for the purposes of
session announcement, session invitation, and other forms of session announcement, session invitation, and other forms of
multimedia session initiation. multimedia session initiation.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . 5
3.1 Multicast Announcement . . . . . . . . . . . . . . . . . . . 5
3.2 Session Initiation . . . . . . . . . . . . . . . . . . . . . 5
3.3 Streaming media . . . . . . . . . . . . . . . . . . . . . . 5
3.4 Email and the World Wide Web . . . . . . . . . . . . . . . . 5
4. Requirements and Recommendations . . . . . . . . . . . . . . 6
4.1 Media Information . . . . . . . . . . . . . . . . . . . . . 7
4.2 Timing Information . . . . . . . . . . . . . . . . . . . . . 7
4.3 Private Sessions . . . . . . . . . . . . . . . . . . . . . . 8
4.4 Obtaining Further Information about a Session . . . . . . . 8
4.5 Categorisation . . . . . . . . . . . . . . . . . . . . . . . 8
4.6 Internationalization . . . . . . . . . . . . . . . . . . . . 8
5. SDP Specification . . . . . . . . . . . . . . . . . . . . . 8
5.1 Protocol Version ("v=") . . . . . . . . . . . . . . . . . . 11
5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . . 11
5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . . . 12
5.4 Session and Media Information ("i=") . . . . . . . . . . . . 12
5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . . 13
5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . . 14
5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . . 16
5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . . 17
5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . . 18
5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . . . 18
5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . . . 19
5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . . . 20
5.14 Media Announcements ("m=") . . . . . . . . . . . . . . . . . 21
6. Suggested Attributes . . . . . . . . . . . . . . . . . . . . 25
7. Communicating Conference Control Policy . . . . . . . . . . 30
8. Security Considerations . . . . . . . . . . . . . . . . . . 31
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32
9.1 Media types ("media") . . . . . . . . . . . . . . . . . . . 32
9.2 Transport protocols ("proto") . . . . . . . . . . . . . . . 32
9.3 Media formats ("fmt") . . . . . . . . . . . . . . . . . . . 33
9.4 Attribute names ("att-field") . . . . . . . . . . . . . . . 33
9.5 Bandwidth specifiers ("bwtype") . . . . . . . . . . . . . . 34
9.6 Network types ("nettype") . . . . . . . . . . . . . . . . . 34
9.7 Address types ("addrtype") . . . . . . . . . . . . . . . . . 35
9.8 Registration Procedure . . . . . . . . . . . . . . . . . . . 35
A. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 35
B. Changes from RFC 2327 . . . . . . . . . . . . . . . . . . . 41
C. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 42
Normative References . . . . . . . . . . . . . . . . . . . . 42
Informative References . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 43
Intellectual Property and Copyright Statements . . . . . . . 45
1. Introduction 1. Introduction
When initiating multimedia teleconferences, voice-over-IP calls, When initiating multimedia teleconferences, voice-over-IP calls,
streaming video, or other real-time sessions, there is a requirement streaming video, or other real-time sessions, there is a requirement
to convey media details, transport addresses, and other session to convey media details, transport addresses, and other session
description metadata to the participants. description metadata to the participants.
SDP provides a standard representation for such information, SDP provides a standard representation for such information,
irrespective of how that information is transported. SDP is purely a irrespective of how that information is transported. SDP is purely a
format for session description - it does not incorporate a transport format for session description - it does not incorporate a transport
skipping to change at page 2, line 34 skipping to change at page 4, line 32
wide range of network environments and applications. However, it is wide range of network environments and applications. However, it is
not intended to support negotiation of session content or media not intended to support negotiation of session content or media
encodings: this is viewed as outside the scope of session encodings: this is viewed as outside the scope of session
description. description.
2. Glossary of Terms 2. Glossary of Terms
The following terms are used in this document, and have specific The following terms are used in this document, and have specific
meaning 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
A multimedia conference is a set of two or more communicating communicating users along with the software they are using to
users along with the software they are using to communicate. communicate.
Session
A multimedia session is a set of multimedia senders and receivers
and the data streams flowing from senders to receivers. A
multimedia conference is an example of a multimedia session.
Session Advertisement Session: A multimedia session is a set of multimedia senders and
See session announcement. receivers and the data streams flowing from senders to receivers.
A multimedia conference is an example of a multimedia session.
Session Announcement Session Advertisement: See session announcement.
A session announcement is a mechanism by which a session
description is conveyed to users in a pro-active fashion, i.e.,
the session description was not explicitly requested by the user.
Session Description Session Announcement: A session announcement is a mechanism by which
A well defined format for conveying sufficient information to a session description is conveyed to users in a pro-active
discover and participate in a multimedia session. fashion, i.e., the session description was not explicitly
requested by the user.
2.1. Terminology Session Description: A well defined format for conveying sufficient
information to discover and participate in a multimedia session.
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 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Examples of SDP Usage 3. Examples of SDP Usage
3.1. Multicast Announcement 3.1 Multicast Announcement
In order to assist the advertisement of multicast multimedia In order to assist the advertisement of multicast multimedia
conferences and other multicast sessions, and to communicate the conferences and other multicast sessions, and to communicate the
relevant session setup information to prospective participants, a relevant session setup information to prospective participants, a
distributed session directory may be used. An instance of such a distributed session directory may be used. An instance of such a
session directory periodically sends packets containing a description session directory periodically sends packets containing a description
of the session to a well known multicast group. These advertisements of the session to a well known multicast group. These advertisements
are received by other session directories such that potential remote are received by other session directories such that potential remote
participants can use the session description to start the tools participants can use the session description to start the tools
required to participate in the session. required to participate in the session.
One protocol commonly used to implement such a distributed directory One protocol commonly used to implement such a distributed directory
is the Session Announcement Protocol, SAP [RFC2974]. SDP provides the is the Session Announcement Protocol, SAP [RFC2974]. SDP provides the
recommended session description format for such announcements. recommended session description format for such announcements.
3.2. Session Initiation 3.2 Session Initiation
The Session Initiation Protocol, SIP [RFC3261] is an application- The Session Initiation Protocol, SIP [RFC3261] is an application
layer control protocol for creating, modifying and terminating layer control protocol for creating, modifying and terminating
sessions such as Internet multimedia conferences, Internet telephone sessions such as Internet multimedia conferences, Internet telephone
calls and multimedia distribution. The SIP messages used to create calls and multimedia distribution. The SIP messages used to create
sessions carry session descriptions which allow participants to agree sessions carry session descriptions which allow participants to agree
on a set of compatible media types. These session descriptions are on a set of compatible media types. These session descriptions are
commonly formatted using SDP. When used with SIP, the offer/answer commonly formatted using SDP. When used with SIP, the offer/answer
model [RFC3264] provides a framework for negotiation using SDP. model [RFC3264] provides a limited framework for negotiation using
SDP.
3.3. Streaming media 3.3 Streaming media
The Real Time Streaming Protocol, RTSP [RFC2326], is an application- The Real Time Streaming Protocol, RTSP [RFC2326], is an application-
level 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 properties. RTSP provides an extensible framework to enable
controlled, on-demand delivery of real-time data, such as audio and controlled, on-demand delivery of real-time data, such as audio and
video. An RTSP client and server negotiate an appropriate set of video. An RTSP client and server negotiate an appropriate set of
parameters for media delivery, partially using SDP syntax to describe parameters for media delivery, partially using SDP syntax to describe
those parameters. those parameters.
3.4. Email and the World Wide Web 3.4 Email and the World Wide Web
Alternative means of conveying session descriptions include Alternative means of conveying session descriptions include
electronic mail and the World Wide Web. For both email and WWW electronic mail and the World Wide Web. For both email and WWW
distribution, the use of the MIME content type "application/sdp" MUST distribution, the use of the MIME content type "application/sdp" MUST
be used. This enables the automatic launching of applications for be used. This enables the automatic launching of applications for
participation in the session from the WWW client or mail reader in a participation in the session from the WWW client or mail reader in a
standard manner. standard manner.
Note that announcements of multicast sessions made only via email or Note that announcements of multicast sessions made only via email or
the World Wide Web (WWW) do not have the property that the receiver the World Wide Web (WWW) do not have the property that the receiver
skipping to change at page 5, line 4 skipping to change at page 6, line 41
session. In a unicast environment, only the latter purpose is likely session. In a unicast environment, only the latter purpose is likely
to 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 needed to receive those media (addresses, ports,
formats and so on)
As resources necessary to participate in a session may be limited, As resources necessary to participate in a session may be limited,
some additional information may also be desirable: 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.
4.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:
skipping to change at page 6, line 5 skipping to change at page 7, line 38
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 The semantics of this address and port depend on the media and
transport protocol defined. By default, this is the remote address transport protocol defined. By default, this is the remote address
and remote port to which data is sent, however some media types may and remote port to which data is sent, however some media types may
redefine this behaviour. redefine this behaviour.
4.2. Timing Information 4.2 Timing Information
Sessions may either be bounded or unbounded in time. Whether or not Sessions may either be bounded or unbounded in time. Whether or not
they are bounded, they may be only active at specific times. 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 o For each bound, repeat times such as "every Wednesday at 10am for
for one hour" 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.
4.3. Private Sessions 4.3 Private Sessions
It is possible to create both public sessions and private sessions. It is possible to create both public sessions and private sessions.
SDP 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 distribution. The details of how encryption is performed are
dependent on the mechanism used to convey SDP - e.g. mechanisms are dependent on the mechanism used to convey SDP - e.g. mechanisms are
defined for SDP transported using SAP [RFC2974] and SIP [RFC3261]. defined for SDP transported using SAP [RFC2974] and SIP [RFC3261].
If a session announcement is private it is possible to use that If a session announcement is private it is possible to use that
private announcement to convey encryption keys necessary to decode private announcement to convey encryption keys necessary to decode
each of the media in a conference, including enough information to each of the media in a conference, including enough information to
know which encryption scheme is used for each media. know which encryption scheme is used for each media.
4.4. Obtaining Further Information about a Session 4.4 Obtaining Further Information about a Session
A session description should convey enough information to decide A session description should convey enough information to decide
whether or not to participate in a session. SDP may include whether or not to participate in a session. SDP may include
additional pointers in the form of Universal Resources Identifiers additional pointers in the form of Universal Resources Identifiers
(URIs) for more information about the session. (URIs) for more information about the session.
4.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.
4.6. Internationalization 4.6 Internationalization
The SDP specification recommends the use of the ISO 10646 character The SDP specification recommends the use of the ISO 10646 character
sets in the UTF-8 encoding [RFC2279] to allow many different sets in the UTF-8 encoding [RFC2279] to allow many different
languages to be represented. However, to assist in compact languages to be represented. However, to assist in compact
representations, SDP also allows other character sets such as ISO representations, SDP also allows other character sets such as ISO
8859-1 to be used when desired. Internationalization only applies to 8859-1 to be used when desired. Internationalization only applies to
free-text fields (session name and background information), and not free-text fields (session name and background information), and not
to SDP as a whole. to SDP as a whole.
5. SDP Specification 5. SDP Specification
skipping to change at page 9, line 36 skipping to change at page 11, line 15
Text records such as the session name and information are octet Text records such as the session name and information are octet
strings which may contain any octet with the exceptions of 0x00 strings which may contain any octet with the exceptions of 0x00
(Nul), 0x0a (ASCII newline) and 0x0d (ASCII carriage return). The (Nul), 0x0a (ASCII newline) and 0x0d (ASCII carriage return). The
sequence CRLF (0x0d0a) is used to end a record, although parsers sequence CRLF (0x0d0a) is used to end a record, although parsers
SHOULD be tolerant and also accept records terminated with a single SHOULD be tolerant and also accept records terminated with a single
newline character. By default these byte strings contain ISO-10646 newline character. By default these byte strings contain ISO-10646
characters in UTF-8 encoding, but this default MAY be changed using characters in UTF-8 encoding, but this default MAY be changed using
the "charset" attribute. the "charset" attribute.
Protocol Version 5.1 Protocol Version ("v=")
v=0 v=0
The "v=" field gives the version of the Session Description The "v=" field gives the version of the Session Description Protocol.
Protocol. There is no minor version number. There is no minor version number.
Origin 5.2 Origin ("o=")
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 The "o=" field gives the originator of the session (her username and
and the address of the user's host) plus a session id and session the address of the user's host) plus a session id and session version
version number. number.
<username> is the user's login on the originating host, or it <username> is the user's login on the originating host, or it is "-"
is "-" if the originating host does not support the concept of if the originating host does not support the concept of user ids.
user ids. <username> MUST NOT contain spaces. <username> MUST NOT contain spaces.
<session id> is a numeric string such that the tuple of <session id> is a numeric string such that the tuple of <username>,
<username>, <session id>, <network type>, <address type> and <session id>, <network type>, <address type> and <address> form a
<address> form a globally unique identifier for the session. globally unique identifier for the session. The method of session
The method of session id allocation is up to the creating tool, id allocation is up to the creating tool, but it has been
but it has been suggested that a Network Time Protocol (NTP) suggested that a Network Time Protocol (NTP) format timestamp be
format timestamp be used to ensure uniqueness [RFC1305]. used to ensure uniqueness [RFC1305].
<version> is a version number for this announcement. It is <version> is a version number for this announcement. It is needed for
needed for proxy announcements to detect which of several proxy announcements to detect which of several announcements for
announcements for the same session is the most recent. Again the same session is the most recent. Again its usage is up to the
its usage is up to the creating tool, so long as <version> is creating tool, so long as <version> is increased when a
increased when a modification is made to the session data. modification is made to the session data. Again, it is RECOMMENDED
Again, it is RECOMMENDED (but not mandatory) that an NTP format (but not mandatory) that an NTP format timestamp is used.
timestamp is used.
<network type> is a text string giving the type of network. <network type> is a text string giving the type of network.
Initially "IN" is defined to have the meaning "Internet". Initially "IN" is defined to have the meaning "Internet".
<address type> is a text string giving the type of the address <address type> is a text string giving the type of the address that
that follows. Initially "IP4" and "IP6" are defined. follows. Initially "IP4" and "IP6" are defined.
<address> is the globally unique address of the machine from <address> is the globally unique address of the machine from which
which the session was created. For an address type of IP4, the session was created. For an address type of IP4, this is
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 either the fully-qualified domain name of the machine, or the
compressed textual representation of the IP version 6 address dotted-decimal representation of the IP version 4 address of the
of the machine. For both IP4 and IP6, the fully-qualified machine. For an address type of IP6, this is either the
domain name is the form that SHOULD be given unless this is fully-qualified domain name of the machine, or the compressed
unavailable, in which case the globally unique address may be textual representation of the IP version 6 address of the machine.
substituted. A local IP address MUST NOT be used in any For both IP4 and IP6, the fully-qualified domain name is the form
context where the SDP description might leave the scope in that SHOULD be given unless this is unavailable, in which case the
which the address is meaningful. 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 In general, the "o=" field serves as a globally unique identifier for
for this version of this session description, and the subfields this version of this session description, and the subfields excepting
excepting the version taken together identify the session the version taken together identify the session irrespective of any
irrespective of any modifications. modifications.
Session Name 5.3 Session Name ("s=")
s=<session name> s=<session name>
The "s=" field is the session name. There MUST be one and only
one "s=" field per session description. The "s=" field MUST NOT be
empty and SHOULD contain ISO 10646 characters (but see also the
"a=charset" attribute below). If a session has no meaningful name,
the value "s= " SHOULD be used (i.e. a single space as the
session name).
Session and Media Information The "s=" field is the session name. There MUST be one and only one
"s=" field per session description. The "s=" field MUST NOT be empty
and SHOULD contain ISO 10646 characters (but see also the "a=charset"
attribute). If a session has no meaningful name, the value "s= "
SHOULD be used (i.e. a single space as the session name).
5.4 Session and Media Information ("i=")
i=<session description> i=<session description>
The "i=" field is information about the session. There may be at The "i=" field is information about the session. There may be at
most one session-level "i=" field per session description, and at most one session-level "i=" field per session description, and at
most one "i=" field per media. Although it may be omitted, this is most one "i=" field per media. Although it may be omitted, this is
NOT RECOMMENDED for session announcements, and user interfaces for NOT RECOMMENDED for session announcements, and user interfaces for
composing sessions should require text to be entered. If it is composing sessions should require text to be entered. If it is
present it must contain ISO 10646 characters (but see also the present it must contain ISO 10646 characters (but see also the
"a=charset" attribute below). "a=charset" attribute below).
A single "i=" field can also be used for each media definition. A single "i=" field can also be used for each media definition. In
In media definitions, "i=" fields are primarily intended for media definitions, "i=" fields are primarily intended for labeling
labeling media streams. As such, they are most likely to be media streams. As such, they are most likely to be useful when a
useful when a single session has more than one distinct media single session has more than one distinct media stream of the same
stream of the same media type. An example would be two different media type. An example would be two different whiteboards, one for
whiteboards, one for slides and one for feedback and questions. slides and one for feedback and questions.
URI 5.5 URI ("u=")
u=<URI> u=<URI>
A URI is a Universal Resource Identifier as used by WWW clients. A URI is a Universal Resource Identifier as used by WWW clients. The
The URI should be a pointer to additional information about the URI should be a pointer to additional information about the
conference. This field is OPTIONAL, but if it is present it MUST conference. This field is OPTIONAL, but if it is present it MUST be
be specified before the first media field. No more than one URI specified before the first media field. No more than one URI field is
field is allowed per session description. allowed per session description.
Email Address and Phone Number 5.6 Email Address and Phone Number ("e=" and "p=")
e=<email address> e=<email address>
p=<phone number> p=<phone number>
These specify contact information for the person responsible for These specify contact information for the person responsible for the
the conference. This is not necessarily the same person that conference. This is not necessarily the same person that created the
created the conference announcement. conference announcement.
Inclusion of an email address or phone number is OPTIONAL. Note Inclusion of an email address or phone number is OPTIONAL. Note that
that the previous version of SDP specified that either an email the previous version of SDP specified that either an email field or a
field or a phone field MUST be specified, but this was widely phone field MUST be specified, but this was widely ignored. The
ignored. The change brings the specification into line with change brings the specification into line with common usage.
common usage.
If the email addres or phone number are present, they MUST be If the email addres or phone number are present, they MUST be
specified before the first media field. More than one email or specified before the first media field. More than one email or phone
phone field can be given for a session description. field can be given for a session description.
Phone numbers SHOULD be given in the conventional international Phone numbers SHOULD be given in the conventional international
format: preceded by a "+" and the international country code. format: preceded by a "+" and the international country code. There
There must be a space or a hyphen ("-") between the country code must be a space or a hyphen ("-") between the country code and the
and the rest of the phone number. Spaces and hyphens may be used rest of the phone number. Spaces and hyphens may be used to split up
to split up a phone field to aid readability if desired. For a phone field to aid readability if desired. For example:
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 Both email addresses and phone numbers can have an optional free text
text string associated with them, normally giving the name of the string associated with them, normally giving the name of the person
person who may be contacted. This should be enclosed in who may be contacted. This should be enclosed in parenthesis if it
parenthesis if it is present. For example: 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 The alternative RFC822 name quoting convention is also allowed for
both 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 The free text string SHOULD be in the ISO-10646 character set with
UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if
if the appropriate charset session-level attribute is set. the appropriate charset session-level attribute is set.
Connection Data 5.7 Connection Data ("c=")
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 at least one "c=" field A session announcement MUST contain either at least one "c=" field in
in each media description (see below) or a single "c=" field at each media description (see below) or a single "c=" field at the
the session-level. It MAY contain a single session-level "c=" session-level. It MAY contain a single session-level "c=" field and
field and additional "c=" field(s) per media description, in which additional "c=" field(s) per media description, in which case the
case the per-media values override the session-level settings for per-media values override the session-level settings for the
the respective media. respective media.
The first sub-field is the network type, which is a text string The first sub-field is the network type, which is a text string
giving the type of network. Initially "IN" is defined to have the giving the type of network. Initially "IN" is defined to have the
meaning "Internet". meaning "Internet".
The second sub-field is the address type. This allows SDP to be The second sub-field is the address type. This allows SDP to be used
used for sessions that are not IP based. Currently only IP4 and for sessions that are not IP based. Currently only IP4 and IP6 are
IP6 are defined. defined.
The third sub-field is the connection address. Optional extra The third sub-field is the connection address. Optional extra
sub-fields MAY be added after the connection address depending on sub-fields MAY be added after the connection address depending on the
the value of the <address type> field. value of the <address type> field.
For IP4 and IP6 addresses, the connection address is defined as For IP4 and IP6 addresses, the connection address is defined as
follows: follows:
o If the session is multicast, the connection address will be o If the session is multicast, the connection address will be an IP
an IP multicast group address. If the session is not multicast group address. If the session is not multicast, then
multicast, then the connection address contains the unicast the connection address contains the unicast IP address of the
IP address of the expected data source or data relay or data expected data source or data relay or data sink as determined by
sink as determined by additional attribute fields. It is not additional attribute fields. It is not expected that unicast
expected that unicast addresses will be given in a session addresses will be given in a session description that is
description that is communicated by a multicast announcement, communicated by a multicast announcement, though this is not
though this is not prohibited. prohibited.
o Conferences using an IPv4 multicast connection address MUST o Conferences using an IPv4 multicast connection address MUST also
also have a time to live (TTL) value present in addition to have a time to live (TTL) value present in addition to the
the multicast address. The TTL and the address together multicast address. The TTL and the address together define the
define the scope with which multicast packets sent in this scope with which multicast packets sent in this conference will be
conference will be sent. TTL values MUST be in the range sent. TTL values MUST be in the range 0-255.
0-255.
The TTL for the session is appended to the address using a slash The TTL for the session is appended to the address using a slash as a
as a separator. An example is: separator. An example is:
c=IN IP4 224.2.36.42/127 c=IN IP4 224.2.36.42/127
IPv6 multicast does not use TTL scoping, and hence the TTL value IPv6 multicast does not use TTL scoping, and hence the TTL value MUST
MUST NOT be present for IPv6 multicast. It is expected that IPv6 NOT be present for IPv6 multicast. It is expected that IPv6 scoped
scoped addresses will be used to limit the scope of conferences. addresses will be used to limit the scope of conferences.
Hierarchical or layered encoding schemes are data streams where Hierarchical or layered encoding schemes are data streams where the
the encoding from a single media source is split into a number of encoding from a single media source is split into a number of layers.
layers. The receiver can choose the desired quality (and hence The receiver can choose the desired quality (and hence bandwidth) by
bandwidth) by only subscribing to a subset of these layers. Such only subscribing to a subset of these layers. Such layered encodings
layered encodings are normally transmitted in multiple multicast are normally transmitted in multiple multicast groups to allow
groups to allow multicast pruning. This technique keeps unwanted multicast pruning. This technique keeps unwanted traffic from sites
traffic from sites only requiring certain levels of the hierarchy. only requiring certain levels of the hierarchy. For applications
For applications requiring multiple multicast groups, we allow the requiring multiple multicast groups, we allow the following notation
following notation to be used for the connection address: 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 Multicast addresses so assigned are contiguously allocated above the
the base address, so that, for example: 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 would state that addresses 224.2.1.1, 224.2.1.2 and 224.2.1.3 are to
to be used at a ttl of 127. This is semantically identical to be used at a ttl of 127. This is semantically identical to including
including multiple "c=" lines in a media description: 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:
skipping to change at page 14, line 36 skipping to change at page 16, line 9
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 5.8 Bandwidth ("b=")
b=<modifier>:<bandwidth-value> b=<modifier>:<bandwidth-value>
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.
The <bandwidth-value> is in kilobits per second by default. The <bandwidth-value> is in kilobits per second by default. Modifiers
Modifiers MAY specify that alternative units are to be used (the MAY specify that alternative units are to be used (the modifiers
modifiers defined in this memo use the default units). defined in this memo use the default units).
The <modifier> is a single alphanumeric word giving the meaning of The <modifier> is a single alphanumeric word giving the meaning of
the bandwidth figure. the bandwidth figure. Two modifiers are initially defined:
Two modifiers are initially defined:
CT Conference Total CT Conference Total
If the bandwidth of a session or media in a session is If the bandwidth of a session or media in a session is
different from the bandwidth implicit from the scope, a different from the bandwidth implicit from the scope, a
"b=CT:..." line should be supplied for the session giving "b=CT:..." line should be supplied for the session giving
the proposed upper limit to the bandwidth used. The primary the proposed upper limit to the bandwidth used. The primary
purpose of this is to give an approximate idea as to whether purpose of this is to give an approximate idea as to whether
two or more sessions can co-exist simultaneously. two or more sessions can co-exist simultaneously.
AS Application-Specific Maximum AS Application-Specific Maximum
The bandwidth is interpreted to be application-specific (it The bandwidth is interpreted to be application-specific (it
will be the application's concept of maximum bandwidth). will be the application's concept of maximum bandwidth).
Normally this will coincide with what is set on the Normally this will coincide with what is set on the
application's "maximum bandwidth" control if applicable. application's "maximum bandwidth" control if applicable.
For RTP based applications, AS gives the RTP "session For RTP based applications, AS gives the RTP "session
bandwidth" as defined in section 6.2 of [RFC1889]. bandwidth" as defined in section 6.2 of [RFC1889].
Note that CT gives a total bandwidth figure for all the media at Note that CT gives a total bandwidth figure for all the media at all
all sites. AS gives a bandwidth figure for a single media at a sites. AS gives a bandwidth figure for a single media at a single
single site, although there may be many sites sending site, although there may be many sites sending simultaneously.
simultaneously.
Tool writers MAY define experimental bandwidth modifiers by Tool writers MAY define experimental bandwidth modifiers by prefixing
prefixing their modifier with "X-". For example: 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
parsers MUST ignore bandwidth fields with unknown modifiers. MUST ignore bandwidth fields with unknown modifiers. Modifiers MUST
Modifiers MUST be alpha-numeric and, although no length limit is be alpha-numeric and, although no length limit is given, they are
given, they are recommended to be short. recommended to be short.
Times, Repeat Times and Time Zones 5.9 Timing ("t=")
t=<start time> <stop time> t=<start time> <stop time>
"t=" fields specify the start and stop times for a session. "t=" fields specify the start and stop times for a session. Multiple
Multiple "t=" fields MAY be used if a session is active at "t=" fields MAY be used if a session is active at multiple
multiple irregularly spaced times; each additional "t=" field irregularly spaced times; each additional "t=" field specifies an
specifies an additional period of time for which the session will additional period of time for which the session will be active. If
be active. If the session is active at regular times, an "r=" the session is active at regular times, an "r=" field (see below)
field (see below) should be used in addition to and following a should be used in addition to and following a "t=" field - in which
"t=" field - in which case the "t=" field specifies the start and case the "t=" field specifies the start and stop times of the repeat
stop times of the repeat sequence. sequence.
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
the session respectively. These values are the decimal session respectively. These values are the decimal representation of
representation of Network Time Protocol (NTP) time values in Network Time Protocol (NTP) time values in seconds [RFC1305]. To
seconds [RFC1305]. To convert these values to UNIX time, subtract convert these values to UNIX time, subtract decimal 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
counting seconds since 1900, NTP will use the value modulo the 64 seconds since 1900, NTP will use the value modulo the 64 bit limit).
bit limit).
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 though it will not become active until after the start-time. If the
the start-time is also zero, the session is regarded as permanent. start-time is also zero, the session is regarded as permanent.
User interfaces SHOULD strongly discourage the creation of User interfaces SHOULD strongly discourage the creation of unbounded
unbounded and permanent sessions as they give no information about and permanent sessions as they give no information about when the
when the session is actually going to terminate, and so make session is actually going to terminate, and so make scheduling
scheduling difficult. difficult.
The general assumption may be made, when displaying unbounded The general assumption may be made, when displaying unbounded
sessions that have not timed out to the user, that an unbounded sessions that have not timed out to the user, that an unbounded
session will only be active until half an hour from the current session will only be active until half an hour from the current time
time or the session start time, whichever is the later. If or the session start time, whichever is the later. If behaviour
behaviour other than this is required, an end-time should be given other than this is required, an end-time should be given and modified
and modified as appropriate when new information becomes available as appropriate when new information becomes available about when the
about when the session should really end. session should really end.
Permanent sessions may be shown to the user as never being active Permanent sessions may be shown to the user as never being active
unless there are associated repeat times which state precisely unless there are associated repeat times which state precisely when
when the session will be active. In general, permanent sessions the session will be active. In general, permanent sessions SHOULD
SHOULD NOT be created for any session expected to have a duration NOT be created for any session expected to have a duration of less
of less than 2 months, and should be discouraged for sessions than 2 months, and should be discouraged for sessions expected to
expected to have a duration of less than 6 months. have a duration of less than 6 months.
r=<repeat interval> <active duration> <list of offsets from start- 5.10 Repeat Times ("r=")
time>
r=<repeat interval> <active duration> <offsets from start-time>
"r=" fields specify repeat times for a session. For example, if a "r=" fields specify repeat times for a session. For example, if a
session is active at 10am on Monday and 11am on Tuesday for one session is active at 10am on Monday and 11am on Tuesday for one hour
hour each week for three months, then the <start time> in the each week for three months, then the <start time> in the
corresponding "t=" field would be the NTP representation of 10am corresponding "t=" field would be the NTP representation of 10am on
on the first Monday, the <repeat interval> would be 1 week, the the first Monday, the <repeat interval> would be 1 week, the <active
<active duration> would be 1 hour, and the offsets would be zero duration> would be 1 hour, and the offsets would be zero and 25
and 25 hours. The corresponding "t=" field stop time would be the hours. The corresponding "t=" field stop time would be the NTP
NTP representation of the end of the last session three months representation of the end of the last session three months later. By
later. By default all fields are in seconds, so the "r=" and "t=" default all fields are in seconds, so the "r=" and "t=" fields might
fields might be: be:
t=3034423619 3042462419 t=3034423619 3042462419
r=604800 3600 0 90000 r=604800 3600 0 90000
To make description more compact, times may also be given in units To make description more compact, times may also be given in units of
of days, hours or minutes. The syntax for these is a number days, hours or minutes. The syntax for these is a number immediately
immediately followed by a single case-sensitive character. followed by a single case-sensitive character. Fractional units are
Fractional units are not allowed - a smaller unit should be used not allowed - a smaller unit should be used instead. The following
instead. The following unit specification characters are allowed: 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)
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
single SDP repeat time - instead separate "t" fields should be SDP repeat time - instead separate "t=" fields should be used to
used to explicitly list the session times. explicitly list the session times.
5.11 Time Zones ("z=")
z=<adjustment time> <offset> <adjustment time> <offset> .... z=<adjustment time> <offset> <adjustment time> <offset> ....
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
different countries change to or from daylight time on different countries change to or from daylight time on different dates, and
dates, and some countries do not have daylight saving time at all. some countries do not have daylight saving time at all.
Thus in order to schedule a session that is at the same time Thus in order to schedule a session that is at the same time winter
winter and summer, it must be possible to specify unambiguously and summer, it must be possible to specify unambiguously by whose
by whose time zone a session is scheduled. To simplify this task time zone a session is scheduled. To simplify this task for
for receivers, we allow the sender to specify the NTP time that a receivers, we allow the sender to specify the NTP time that a time
time zone adjustment happens and the offset from the time when the zone adjustment happens and the offset from the time when the session
session was first scheduled. The "z" field allows the sender to was first scheduled. The "z=" field allows the sender to specify a
specify a list of these adjustment times and offsets from the base 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, session's repeat times are calculated is shifted back by 1 hour, and
and that at time 2898848070 the session's original time base is that at time 2898848070 the session's original time base is restored.
restored. Adjustments are always relative to the specified start Adjustments are always relative to the specified start time - they
time - they are not cumulative. Adjustments apply to all "t=" and are not cumulative. Adjustments apply to all "t=" and "r=" lines in
"r=" lines in a session description. a session description.
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
the session announcement will be modified periodically rather than session announcement will be modified periodically rather than
transmit several years worth of adjustments in one announcement. transmit several years worth of adjustments in one announcement.
Encryption Keys 5.12 Encryption Keys ("k=")
k=<method> k=<method>
k=<method>:<encryption key> k=<method>:<encryption key>
If transported over a secure and trusted channel, the session If transported over a secure and trusted channel, the session
description protocol MAY be used to convey encryption keys. A key description protocol MAY be used to convey encryption keys. A key
field is permitted before the first media entry (in which case it field is permitted before the first media entry (in which case it
applies to all media in the session), or for each media entry as applies to all media in the session), or for each media entry as
required. required.
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 [RFC1890] for an example. document, but see [RFC1890] for an example.
The method indicates the mechanism to be used to obtain a usable The method indicates the mechanism to be used to obtain a usable key
key by external means, or from the encoded encryption key given. by external means, or from the encoded encryption key given. The
The following methods are defined: following methods are defined:
k=clear:<encryption key> k=clear:<encryption key>
The encryption key is included untransformed in this key field. The encryption key is included untransformed in this key field.
This method MUST NOT be used unless it can be guaranteed that This method MUST NOT be used unless it can be guaranteed that
the SDP is conveyed over a secure channel. the SDP is conveyed over a secure channel.
k=base64:<encoded encryption key> k=base64:<encoded encryption key>
The encryption key 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. This method MUST NOT be used unless it can prohibited in SDP. This method MUST NOT be used unless it can
be guaranteed that the SDP is conveyed over a secure channel. 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 is included in the key field. A Universal Resource Identifier is included in the key field.
The URI refers to the data containing the key, and may require The URI refers to the data containing the key, and may require
additional authentication before the key can be returned. When additional authentication before the key can be returned. When
skipping to change at page 19, line 4 skipping to change at page 20, line 18
k=uri:<URI to obtain key> k=uri:<URI to obtain key>
A Universal Resource Identifier is included in the key field. A Universal Resource Identifier is included in the key field.
The URI refers to the data containing the key, and may require The URI refers to the data containing the key, and may require
additional authentication before the key can be returned. When additional authentication before the key can be returned. When
a request is made to the given URI, the MIME content-type of a request is made to the given URI, the MIME content-type of
the reply specifies the encoding for the key in the reply. the reply specifies the encoding for the key in the reply.
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. The use of user-specified keys is decrypt the media streams. The use of user-specified keys is
NOT RECOMMENDED, since such keys tend to have weak security NOT RECOMMENDED, since such keys tend to have weak security
properties. properties.
The key field MUST NOT be used unless it can be guaranteed that The key field MUST NOT be used unless it can be guaranteed that the
the SDP is conveyed over a secure and trusted channel. An example SDP is conveyed over a secure and trusted channel. An example of such
of such a channel might be SDP embedded inside an S/MIME message. a channel might be SDP embedded inside an S/MIME message.
Attributes 5.13 Attributes ("a=")
a=<attribute> a=<attribute>
a=<attribute>:<value> a=<attribute>:<value>
Attributes are the primary means for extending SDP. Attributes Attributes are the primary means for extending SDP. Attributes may
may be defined to be used as "session-level" attributes, "media- be defined to be used as "session-level" attributes, "media-level"
level" attributes, or both. attributes, or both.
A media description may have any number of attributes ("a=" A media description may have any number of attributes ("a=" fields)
fields) which are media specific. These are referred to as which are media specific. These are referred to as "media-level"
"media-level" attributes and add information about the media attributes and add information about the media stream. Attribute
stream. Attribute fields can also be added before the first media fields can also be added before the first media field; these
field; these "session-level" attributes convey additional "session-level" attributes convey additional information that applies
information that applies to the conference as a whole rather than to the conference as a whole rather than to individual media; an
to individual media; an example might be the conference's floor example might be the conference's floor control policy.
control policy.
Attribute fields may be of two forms: Attribute fields may be of two forms:
o property attributes: o property attributes:
A property attribute is simply of the form "a=<flag>". A property attribute is simply of the form "a=<flag>".
These are binary attributes, and the presence of the These are binary attributes, and the presence of the
attribute conveys that the attribute is a property of attribute conveys that the attribute is a property of
the session. An example might be "a=recvonly". the session. An example might be "a=recvonly".
o value attributes: o value attributes:
A value attribute is of the form "a=<attribute>:<value>". A value attribute is of the form "a=<attribute>:<value>".
For example, a whiteboard could have the value attribute For example, a whiteboard could have the value attribute
"a=orient:landscape" "a=orient:landscape"
Attribute interpretation depends on the media tool being invoked. Attribute interpretation depends on the media tool being invoked.
skipping to change at page 19, line 49 skipping to change at page 21, line 16
attribute conveys that the attribute is a property of attribute conveys that the attribute is a property of
the session. An example might be "a=recvonly". the session. An example might be "a=recvonly".
o value attributes: o value attributes:
A value attribute is of the form "a=<attribute>:<value>". A value attribute is of the form "a=<attribute>:<value>".
For example, a whiteboard could have the value attribute For example, a whiteboard could have the value attribute
"a=orient:landscape" "a=orient:landscape"
Attribute interpretation depends on the media tool being invoked. Attribute interpretation depends on the media tool being invoked.
Thus receivers of session descriptions should be configurable in Thus receivers of session descriptions should be configurable in
their interpretation of announcements in general and of attributes their interpretation of announcements in general and of attributes in
in particular. 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 Attribute values are octet strings, and MAY use any octet value
except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute
attribute values are to be interpreted as in ISO-10646 character values are to be interpreted as in ISO-10646 character set with UTF-8
set with UTF-8 encoding. Unlike other text fields, attribute encoding. Unlike other text fields, attribute values are NOT
values are NOT normally affected by the "charset" attribute as normally affected by the "charset" attribute as this would make
this would make comparisons against known values problematic. comparisons against known values problematic. However, when an
However, when an attribute is defined, it can be defined to be attribute is defined, it can be defined to be charset-dependent, in
charset-dependent, in which case it's value should be interpreted which case it's value should be interpreted in the session charset
in the session charset rather than in ISO-10646. rather than in ISO-10646.
Attributes MUST be registered with IANA (see Appendix B). If an Attributes MUST be registered with IANA (see Section 9). If an
attribute is received that is not understood, it MUST be ignored attribute is received that is not understood, it MUST be ignored by
by the receiver. the receiver.
Media Announcements 5.14 Media Announcements ("m=")
m=<media> <port> <transport> <fmt list> m=<media> <port> <transport> <fmt list>
A session description may contain a number of media descriptions. A session description may contain a number of media descriptions.
Each media description starts with an "m=" field, and is Each media description starts with an "m=" field, and is terminated
terminated by either the next "m=" field or by the end of the by either the next "m=" field or by the end of the session
session description. A media field has several four sub-fields. description. A media field has several sub-fields.
The first sub-field is the media type. Currently defined media The first sub-field is the media type. Currently defined media are
are "audio", "video", "application", "data" and "control", though "audio", "video", "application", "data" and "control", though this
this list may be extended in future. The difference between list may be extended in future. The difference between "application"
"application" and "data" is that the former is a media flow such and "data" is that the former is a media flow such as whiteboard
as whiteboard information, and the latter is bulk-data transfer information, and the latter is bulk-data transfer such as
such as multicasting of program executables which will not multicasting of program executables which will not typically be
typically be displayed to the user. "control" is used to specify displayed to the user. "control" is used to specify an additional
an additional conference control channel for the session. conference control channel for the session.
The second sub-field is the transport port to which the media The second sub-field is the transport port to which the media stream
stream is sent. The meaning of the transport port depends on the is sent. The meaning of the transport port depends on the network
network being used as specified in the relevant "c=" field, and on being used as specified in the relevant "c=" field, and on the
the transport protocol defined in the third sub-field. Other transport protocol defined in the third sub-field. Other ports used
ports used by the media application (such as the RTCP port by the media application (such as the RTCP port [RFC1889]) MAY be
[RFC1889]) MAY be derived algorithmically from the base media port derived algorithmically from the base media port or MAY be specified
or MAY be specified in a separate attribute (e.g. "a=rtcp:" as in a separate attribute (e.g. "a=rtcp:" as defined in [RTCPSDP]).
defined in [RTCPSDP]).
For applications where hierarchically encoded streams are being For applications where hierarchically encoded streams are being sent
sent to a unicast address, it may be necessary to specify multiple to a unicast address, it may be necessary to specify multiple
transport ports. This is done using a similar notation to that transport ports. This is done using a similar notation to that used
used for IP multicast addresses in the "c=" field: 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
For RTP, the default is that only the even numbered ports are used RTP, the default is that only the even numbered ports are used for
for data and the corresponding one-higher odd port is used for data and the corresponding one-higher odd port is used for RTCP. For
RTCP. For example: 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 would specify that ports 49170 and 49171 form one RTP/RTCP pair and
and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the
transport protocol and 31 is the format (see below). If non- transport protocol and 31 is the format (see below). If non-
contiguous ports are required, they must be signalled using a contiguous ports are required, they must be signalled using a
separate attribute (e.g. "a=rtcp:" as defined in [RTCPSDP]) separate attribute (e.g. "a=rtcp:" as defined in [RTCPSDP]).
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
port to the corresponding address is implied. For example: to the corresponding address is implied. For example:
c=IN IP4 224.2.1.1/127/2 c=IN IP4 224.2.1.1/127/2
m=video 49170/2 RTP/AVP 31 m=video 49170/2 RTP/AVP 31
would imply that address 224.2.1.1 is used with ports 49170 and would imply that address 224.2.1.1 is used with ports 49170 and
49171, and address 224.2.1.2 is used with ports 49172 and 49173. 49171, and address 224.2.1.2 is used with ports 49172 and 49173.
The third sub-field 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="
"c=" fields. Thus a "c=" field of IP4 defines that the transport fields. Thus a "c=" field of IP4 defines that the transport protocol
protocol runs over IP4. For IP4, it is normally expected that runs over IP4. For IP4, it is normally expected that most media
most media traffic will be carried as RTP over UDP. The following traffic will be carried as RTP over UDP. The following transport
transport protocols are defined, but may be extended through protocols are defined, but may be extended through registration of
registration of new protocols with IANA (see Appendix B): new protocols with IANA (see Section 9):
RTP/AVP - the IETF's Realtime Transport Protocol using the RTP/AVP - the IETF's Realtime Transport Protocol using the
Audio/Video profile carried over UDP. Audio/Video profile carried over UDP.
udp - User Datagram Protocol udp - User Datagram Protocol
TCP - Transmission Control Protocol 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
and transport protocol over UDP, then simply specifying the transport protocol over UDP, then simply specifying the transport
transport protocol as udp and using the format field to protocol as udp and using the format field to distinguish the
distinguish the combined protocol is recommended. If a transport combined protocol is recommended. If a transport protocol is used
protocol is used over UDP to carry several distinct media types over UDP to carry several distinct media types that need to be
that need to be distinguished by a session directory, then distinguished by a session directory, then specifying the transport
specifying the transport protocol and media format separately is protocol and media format separately is necessary. RTP is an example
necessary. RTP is an example of a transport-protocol that carries of a transport-protocol that carries multiple payload formats that
multiple payload formats that must be distinguished by the session must be distinguished by the session directory for it to know how to
directory for it to know how to start appropriate tools, relays, start appropriate tools, relays, mixers or recorders.
mixers or recorders.
The main reason to specify the transport-protocol in addition to The main reason to specify the transport-protocol in addition to the
the media format is that the same standard media formats may be media format is that the same standard media formats may be carried
carried over different transport protocols even when the network over different transport protocols even when the network protocol is
protocol is the same - a historical example is vat PCM audio and the same - a historical example is vat PCM audio and RTP PCM audio.
RTP PCM audio. In addition, relays and monitoring tools that are In addition, relays and monitoring tools that are
transport-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
[RFC1890], the protocol field is "RTP/AVP". Should other RTP [RFC1890], the protocol field is "RTP/AVP". Should other RTP
profiles be defined in the future, their profiles will be profiles be defined in the future, their profiles will be specified
specified in the same way. For example, the protocol field in the same way. For example, the protocol field "RTP/XYZ" would
"RTP/XYZ" would specify RTP operating under a profile whose short specify RTP operating under a profile whose short name is "XYZ".
name is "XYZ".
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
field is protocol specific. Such formats should be defined in an 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
provide a dynamic binding of media encoding to RTP payload type. a dynamic binding of media encoding to RTP payload type. The encoding
The encoding names in the RTP AV Profile do not specify unique names in the RTP AV Profile do not specify unique audio encodings (in
audio encodings (in terms of clock rate and number of audio terms of clock rate and number of audio channels), and so they are
channels), and so they are not used directly in SDP format fields. not used directly in SDP format fields. Instead, the payload type
Instead, the payload type number should be used to specify the number should be used to specify the format for static payload types
format for static payload types and the payload type number along and the payload type number along with additional encoding
with additional encoding information should be used for information should be used for dynamically allocated 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
channel audio sampled at 8kHz. This is completely defined in the audio sampled at 8kHz. This is completely defined in the RTP Audio/
RTP Audio/Video profile as payload type 0, so the media field for Video profile as payload type 0, so the media field for such a stream
such a stream sent to UDP port 49232 is: 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 An example of a dynamic payload type is 16 bit linear encoded stereo
stereo audio sampled at 16 kHz. If we wish to use dynamic RTP/AVP audio sampled at 16 kHz. If we wish to use dynamic RTP/AVP payload
payload type 98 for such a stream, additional information is type 98 for such a stream, additional information is required to
required to decode it: 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 a=rtpmap:<payload type> <encoding name>/<clock rate>
parameters>] [/<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 directory to make the choice of appropriate media to participate in a
in a session. Codec-specific parameters should be added in other 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.
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
defined in the RTP Audio/Video Profile) packetisation is required, in the RTP Audio/Video Profile) packetisation is required, the
the "ptime" attribute is used as given below. "ptime" attribute is used as given below.
For more details on RTP audio and video formats, see [RFC1890]. For more details on RTP audio and video formats, see [RFC1890].
Predefined application formats for the UDP protocol with non-RTP Predefined application formats for the UDP protocol with non-RTP
media are as below: 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 6. Suggested Attributes
The following attributes are suggested. Since application writers The following attributes are suggested. Since application writers
may add new attributes as they are required, this list is not may add new attributes as they are required, this list is not
exhaustive. exhaustive.
a=cat:<category> a=cat:<category>
This attribute gives the dot-separated hierarchical category of This attribute gives the dot-separated hierarchical category
the session. This is to enable a receiver to filter unwanted of the session. This is to enable a receiver to filter
sessions by category. It is a session-level attribute, and is unwanted sessions by category. It is a session-level
not dependent on charset. 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 interesting session based on keywords describing the purpose
the session. It is a session-level attribute. It is a charset of the session. It is a session-level attribute. It is a
dependent attribute, meaning that its value should be charset dependent attribute, meaning that its value should be
interpreted in the charset specified for the session interpreted in the charset specified for the session
description if one is specified, or by default in ISO description if one is specified, or by default in ISO
10646/UTF-8. 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 This gives the name and version number of the tool used to
create the session description. It is a session-level create the session description. It is a session-level
attribute, and is not dependent on charset. attribute, and is not dependent on charset.
skipping to change at page 24, line 49 skipping to change at page 26, line 14
encoding/packetisation of audio. It is a media attribute, and encoding/packetisation of audio. It is a media attribute, and
is not dependent on charset. is not dependent on charset.
a=maxptime:<maximum packet time> a=maxptime:<maximum packet time>
The maximum amount of media which can be encapsulated in each The maximum amount of media which can be encapsulated in each
packet, expressed as time in milliseconds. The time SHALL be packet, expressed as time in milliseconds. The time SHALL be
calculated as the sum of the time the media present in the calculated as the sum of the time the media present in the
packet represents. The time SHOULD be a multiple of the frame packet represents. The time SHOULD be a multiple of the frame
size. This attribute is probably only meaningful for audio size. This attribute is probably only meaningful for audio
data, but may be used with other media types if it makes sense. data, but may be used with other media types if it makes
It is a media attribute, and is not dependent on charset. Note sense. It is a media attribute, and is not dependent on
that this attribute was introduced after RFC 2327, and non charset. Note that this attribute was introduced after RFC
updated implementations will ignore this attribute. 2327, and non updated implementations will ignore this
attribute.
a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding a=rtpmap:<payload type> <encoding name>/<clock rate>
parameters>] [/<encoding parameters>]
See the section on Media Announcements (the "m=" field). This See Section 5.14. This may be a session or media attribute.
may be either a session or media attribute.
a=recvonly a=recvonly
This specifies that the tools should be started in receive-only This specifies that the tools should be started in receive
mode where applicable. It can be either a session or media only mode where applicable. It can be either a session or
attribute, and is not dependent on charset. Note that recvonly media attribute, and is not dependent on charset. Note that
applies to the media only, not to any associated control recvonly applies to the media only, not to any associated
protocol (e.g. an RTP based system in recvonly mode SHOULD control protocol (e.g. an RTP based system in recvonly mode
still send RTCP packets). SHOULD still send RTCP packets).
a=sendrecv a=sendrecv
This specifies that the tools should be started in send and This specifies that the tools should be started in send and
receive mode. This is necessary for interactive conferences receive mode. This is necessary for interactive conferences
with tools that default to receive only mode. It can be either with tools that default to receive only mode. It can be either
a session or media attribute, and is not dependent on charset. a session or media attribute, and is not dependent on charset.
If none of the attributes "sendonly", "recvonly", "inactive", If none of the attributes "sendonly", "recvonly", "inactive",
and "sendrecv" is present, "sendrecv" SHOULD be assumed as the and "sendrecv" is present, "sendrecv" SHOULD be assumed as the
default for sessions which are not of the conference type default for sessions which are not of the conference type
"broadcast" or "H332" (see below). "broadcast" or "H332" (see below).
a=sendonly a=sendonly
This specifies that the tools should be started in send-only This specifies that the tools should be started in send-only
mode. An example may be where a different unicast address is mode. An example may be where a different unicast address is
to be used for a traffic destination than for a traffic source. to be used for a traffic destination than for a traffic
In such a case, two media descriptions may be use, one sendonly source. In such a case, two media descriptions may be use,
and one recvonly. It can be either a session or media one sendonly and one recvonly. It can be either a session or
attribute, but would normally only be used as a media media attribute, but would normally only be used as a media
attribute, and is not dependent on charset. Note that sendonly attribute, and is not dependent on charset. Note that sendonly
applies only to the media, and any associated control protocol applies only to the media, and any associated control protocol
(e.g. RTCP) SHOULD still be received and processed as normal. (e.g. RTCP) SHOULD still be received and processed as normal.
a=inactive a=inactive
This specifies that the tools should be started in inactive This specifies that the tools should be started in inactive
mode. This is necessary for interactive conferences where mode. This is necessary for interactive conferences where
users can put other users on hold. No media is sent over an users can put other users on hold. No media is sent over an
inactive media stream. Note that an RTP based system SHOULD inactive media stream. Note that an RTP based system SHOULD
skipping to change at page 26, line 18 skipping to change at page 27, line 31
Normally this is only used in a whiteboard media specification. Normally this is only used in a whiteboard media specification.
It specifies the orientation of a the whiteboard on the screen. It specifies the orientation of a the whiteboard on the screen.
It is a media attribute. Permitted values are "portrait", It is a media attribute. Permitted values are "portrait",
"landscape" and "seascape" (upside down landscape). It is not "landscape" and "seascape" (upside down landscape). It is not
dependent on charset. dependent on charset.
a=type:<conference type> a=type:<conference type>
This specifies the type of the conference. Suggested values This specifies the type of the conference. Suggested values
are "broadcast", "meeting", "moderated", "test" and "H332". are "broadcast", "meeting", "moderated", "test" and "H332".
"recvonly" should be the default for "type:broadcast" sessions, "recvonly" should be the default for "type:broadcast"
"type:meeting" should imply "sendrecv" and "type:moderated" sessions, "type:meeting" should imply "sendrecv" and
should indicate the use of a floor control tool and that the "type:moderated" should indicate the use of a floor control
media tools are started so as to mute new sites joining the tool and that the media tools are started so as to mute new
conference. sites joining the conference.
Specifying the attribute "type:H332" indicates that this Specifying the attribute "type:H332" indicates that this
loosely coupled session is part of a H.332 session as defined loosely coupled session is part of a H.332 session as defined
in the ITU H.332 specification [H.332]. Media tools should be in the ITU H.332 specification [H.332]. Media tools should be
started "recvonly". started "recvonly".
Specifying the attribute "type:test" is suggested as a hint Specifying the attribute "type:test" is suggested as a hint
that, unless explicitly requested otherwise, receivers can that, unless explicitly requested otherwise, receivers can
safely avoid displaying this session description to users. 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 This specifies the character set to be used to display the
session name and information data. By default, the ISO-10646 session name and information data. By default, the ISO-10646
character set in UTF-8 encoding is used. If a more compact character set in UTF-8 encoding is used. If a more compact
representation is required, other character sets may be used representation is required, other character sets may be used
such as ISO-8859-1 for Northern European languages. In such as ISO-8859-1 for Northern European languages. In
particular, the ISO 8859-1 is specified with the following SDP particular, the ISO 8859-1 is specified with the following
attribute: SDP attribute:
a=charset:ISO-8859-1 a=charset:ISO-8859-1
This is a session-level attribute; if this attribute is This is a session-level attribute; if this attribute is
present, it MUST be before the first media field. The charset present, it MUST be before the first media field. The charset
specified MUST be one of those registered with IANA, such as specified MUST be one of those registered with IANA, such as
ISO-8859-1. The character set identifier is a US-ASCII string ISO-8859-1. The character set identifier is a US-ASCII string
and MUST be compared against the IANA identifiers using a case- and MUST be compared against the IANA identifiers using a
insensitive comparison. If the identifier is not recognised or case- insensitive comparison. If the identifier is not
not supported, all strings that are affected by it SHOULD be recognised or not supported, all strings that are affected by
regarded as octet strings. it SHOULD be regarded as octet strings.
Note that a character set specified MUST still prohibit the use Note that a character set specified MUST still prohibit the
of bytes 0x00 (Nul), 0x0A (LF) and 0x0d (CR). Character sets use of bytes 0x00 (Nul), 0x0A (LF) and 0x0d (CR). Character
requiring the use of these characters MUST define a quoting sets requiring the use of these characters MUST define a
mechanism that prevents these bytes appearing within text quoting mechanism that prevents these bytes appearing within
fields. text fields.
a=sdplang:<language tag> a=sdplang:<language tag>
This can be a session level attribute or a media level This can be a session level attribute or a media level
attribute. As a session level attribute, it specifies the attribute. As a session level attribute, it specifies the
language for the session description. As a media level language for the session description. As a media level
attribute, it specifies the language for any media-level SDP attribute, it specifies the language for any media-level SDP
information field associated with that media. Multiple sdplang information field associated with that media. Multiple
attributes can be provided either at session or media level if sdplang attributes can be provided either at session or media
multiple languages in the session description or media use level if multiple languages in the session description or
multiple languages, in which case the order of the attributes media use multiple languages, in which case the order of the
indicates the order of importance of the various languages in attributes indicates the order of importance of the various
the session or media from most important to least important. 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
languages is discouraged. Instead, multiple descriptions multiple languages is discouraged. Instead, multiple
SHOULD be sent describing the session, one in each language. descriptions SHOULD be sent describing the session, one in
However this is not possible with all transport mechanisms, and each language. However this is not possible with all
so multiple sdplang attributes are allowed although NOT transport mechanisms, and so multiple sdplang attributes are
RECOMMENDED. allowed although NOT RECOMMENDED.
The "sdplang" attribute value must be a single RFC 3066 The "sdplang" attribute value must be a single RFC 3066
language tag in US-ASCII [RFC3066]. It is not dependent on the language tag in US-ASCII [RFC3066]. It is not dependent on
charset attribute. An "sdplang" attribute SHOULD be specified the charset attribute. An "sdplang" attribute SHOULD be
when a session is of sufficient scope to cross geographic specified when a session is of sufficient scope to cross
boundaries where the language of recipients cannot be assumed, geographic boundaries where the language of recipients cannot
or where the session is in a different language from the be assumed, or where the session is in a different language
locally assumed norm. from the locally assumed norm.
a=lang:<language tag> a=lang:<language tag>
This can be a session level attribute or a media level This can be a session level attribute or a media level
attribute. As a session level attribute, it specifies the attribute. As a session level attribute, it specifies the
default language for the session being described. As a media default language for the session being described. As a media
level attribute, it specifies the language for that media, level attribute, it specifies the language for that media,
overriding any session-level language specified. Multiple lang overriding any session-level language specified. Multiple
attributes can be provided either at session or media level if lang attributes can be provided either at session or media
multiple languages if the session description or media use level if the session description or media use multiple
multiple languages, in which case the order of the attributes languages, in which case the order of the attributes indicates
indicates the order of importance of the various languages in the order of importance of the various languages in the
the session or media from most important to least important. session or media from most important to least important.
The "lang" attribute value must be a single RFC 3066 language The "lang" attribute value must be a single RFC 3066 language
tag in US-ASCII [RFC3066]. It is not dependent on the charset tag in US-ASCII [RFC3066]. It is not dependent on the charset
attribute. A "lang" attribute SHOULD be specified when a attribute. A "lang" attribute SHOULD be specified when a
session is of sufficient scope to cross geographic boundaries session is of sufficient scope to cross geographic boundaries
where the language of recipients cannot be assumed, or where where the language of recipients cannot be assumed, or where
the session is in a different language from the locally assumed the session is in a different language from the locally
norm. 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
"<integer>.<fraction>" are allowed. It is a media attribute, notation "<integer>.<fraction>" are allowed. It is a
is only defined for video media, and is not dependent on media attribute, defined only for video media, and is not
charset. dependent on charset.
a=quality:<quality> a=quality:<quality>
This gives a suggestion for the quality of the encoding as an This gives a suggestion for the quality of the encoding as an
integer value. The intention of the quality attribute for integer value. The intention of the quality attribute for
video is to specify a non-default trade-off between frame-rate video is to specify a non-default trade-off between frame-rate
and still-image quality. For video, the value in the range 0 and still-image quality. For video, the value in the range 0
to 10, with the following suggested meaning: to 10, with the following suggested meaning:
10 - the best still-image quality the compression scheme can 10 - the best still-image quality the compression scheme
give. 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 0 - the worst still-image quality the codec designer
is still usable. 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 This attribute allows parameters that are specific to a
particular format to be conveyed in a way that SDP doesn't have particular format to be conveyed in a way that SDP doesn't
to understand them. The format must be one of the formats have to understand them. The format must be one of the
specified for the media. Format-specific parameters may be any formats specified for the media. Format-specific parameters
set of parameters required to be conveyed by SDP and given may be any set of parameters required to be conveyed by SDP
unchanged to the media tool that will use this format. 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.
5.1. Communicating Conference Control Policy 7. 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 before the first media field, possibly supplemented by properties
such as `recvonly' for some of the media tools. This conference such as `recvonly' for some of the media tools. This conference
attribute conveys the conference control policy. An example might attribute conveys the conference control policy. An example might
skipping to change at page 29, line 46 skipping to change at page 31, line 13
In this example, a general conference attribute (type:H332) is In this example, a general conference attribute (type:H332) is
specified stating that conference control will be provided by an specified stating that conference control will be provided by an
external H.332 tool, and a contact addresses for the H.323 session external H.332 tool, and a contact addresses for the H.323 session
multipoint 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.
6. Security Considerations 8. Security Considerations
SDP is a session description format that describes multimedia SDP is a session description format that describes multimedia
sessions. A session description SHOULD NOT be trusted unless it has sessions. A session description SHOULD NOT be trusted unless it has
been obtained by an authenticated transport protocol from a trusted been obtained by an authenticated transport protocol from a trusted
source. Many different transport protocols may be used to distribute source. Many different transport protocols may be used to distribute
session description, and the nature of the authentication will differ session description, and the nature of the authentication will differ
from transport to transport. from transport to transport.
One transport that will frequently be used to distribute session One transport that will frequently be used to distribute session
descriptions is the Session Announcement Protocol (SAP). SAP descriptions is the Session Announcement Protocol (SAP). SAP
skipping to change at page 32, line 5 skipping to change at page 32, line 27
administrators will apply their own policies, but the exclusive use administrators will apply their own policies, but the exclusive use
of "local" or "site-local" administrative scope within the firewall of "local" or "site-local" administrative scope within the firewall
and the refusal of the firewall to open a hole for such scopes will and the refusal of the firewall to open a hole for such scopes will
provide separation of global multicast sessions from local ones. provide separation of global multicast sessions from local ones.
Use of the "k=" field poses a significant security risk, since it Use of the "k=" field poses a significant security risk, since it
conveys session encryption keys in the clear. SDP MUST NOT be used conveys session encryption keys in the clear. SDP MUST NOT be used
to convey key material, unless it can be guaranteed that the channel to convey key material, unless it can be guaranteed that the channel
over which the SDP is delivered is both private and authenticated. over which the SDP is delivered is both private and authenticated.
Appendix A: SDP Grammar 9. IANA Considerations
There are seven field names that may be registered with IANA. Using
the terminology in the SDP specification BNF, they are "media",
"proto", "fmt", "att-field", "bwtype", "nettype" and "addrtype".
9.1 Media types ("media")
The set of media types is intended to be small and SHOULD NOT be
extended except under rare circumstances. The same rules should
apply for media names as for top-level MIME content types, and where
possible the same name should be registered for SDP as for MIME. For
media other than existing MIME top-level content types, a
standards-track RFC MUST be produced for a new top-level content type
to be registered, and the registration MUST provide good
justification why no existing media name is appropriate (the
"Standards Action" policy of RFC 2434 [RFC2434]).
9.2 Transport protocols ("proto")
The "proto" field describes the transport protocol used. This SHOULD
reference a standards-track protocol RFC. This memo registers three
values: "RTP/AVP" is a reference to RTP [RFC1889] used under the RTP
Profile for Audio and Video Conferences with Minimal Control
[RFC1890]) running over UDP/IP; "TCP" denotes an unspecified format
over TCP; and "udp" indicates an unspecified format over UDP.
New transport protocols MAY be registered with IANA. Registrations
MUST reference an RFC describing the protocol. Such an RFC MAY be
Experimental or Informational, although it is preferable if it is
Standards-Track. Registrations MUST also define the rules by which
their "fmt" namespace is managed (see below).
9.3 Media formats ("fmt")
Each transport protocol, defined by the "proto" field, has an
associated "fmt" namespace that describes the media formats which may
conveyed by that protocol. Formats cover all the possible encodings
that might want to be transported in a multimedia session.
RTP payload formats under the "RTP/AVP" protocol that have been
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 as defined by the MIME type registration
for the payload format.
For "TCP" and "udp" protocols, new formats SHOULD be registered. Use
of an existing MIME subtype for the format is encouraged. If no MIME
subtype exists, it is RECOMMENDED that a suitable one is registered
through the IETF process (RFC 2048) by production of, or reference
to, a standards-track RFC. If a MIME subtype is for some reason
inappropriate, an RFC publication describing the format MUST be
referenced in the registration, but it may be Informational or
Experimental if the protocol is not deemed to be of widespread
deployment.
For other protocols, formats MAY be registered according to the rules
of the associated "proto" specification.
Registrations of new formats MUST specify which transport protocols
they apply to.
9.4 Attribute names ("att-field")
Attribute field names ("att-field") MUST be registered with IANA and
documented, 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.
New attribute registerations are accepted according to the
"Specification Required" policy of RFC 2434, provided that the
specification includes the following information:
o contact name, email address and telephone number
o attribute-name (as it will appear in SDP)
o long-form attribute name in English
o type of attribute (session level, media level, or both)
o whether the attribute value is subject to the charset attribute.
o a one paragraph explanation of the purpose of the attribute.
o a specification of appropriate attribute values for this
attribute.
The above is the minimum that IANA will accept. Attributes that are
expected to see widespread use and interoperability, SHOULD be
documented with a standards-track RFC that specifies the attribute
more precisely.
Submitters of registrations should ensure that the specification is
in the spirit of SDP attributes, most notably that the attribute is
platform independent in the sense that it makes no implicit
assumptions about operating systems and does not name specific pieces
of software in a manner that might inhibit interoperability.
9.5 Bandwidth specifiers ("bwtype")
A proliferation of bandwidth specifiers is strongly discouraged.
New bandwidth specifiers ("bwtype" fields) MUST be registered with
IANA. The submission MUST reference a standards-track RFC specifying
the semantics of the bandwidth specifier precisely, and indicating
when it should be used, and why the existing registered bandwidth
specifiers do not suffice.
9.6 Network types ("nettype")
New network types (the "nettype" field) may be registered with IANA
if SDP needs to be used in the context of non-Internet environments.
Whilst these are not normally the preserve of IANA, there may be
circumstances when an Internet application needs to interoperate with
a non- Internet application, such as when gatewaying an Internet
telephony call into the PSTN. The number of network types should be
small and should be rarely extended. A new network type cannot be
registered without registering at least one address type to be used
with that network type. A new network type registration MUST
reference an RFC which gives details of the network type and address
type and specifies how and when they would be used. Such an RFC MAY
be Informational.
9.7 Address types ("addrtype")
New address types ("addrtype") may be registered with IANA. An
address type is only meaningful in the context of a network type, and
any registration of an address type MUST specify a registered network
type, or be submitted along with a network type registration. A new
address type registration MUST reference an RFC giving details of the
syntax of the address type. Such an RFC MAY be Informational.
Address types are not expected to be registered frequently.
9.8 Registration Procedure
In the RFC documentation that registers SDP "media", "proto", "fmt",
"bwtype", "nettype" and "addrtype" fields, the authors MUST include
the following information for IANA to place in the appropriate
registry:
o contact name, email address and telephone number
o name being registered (as it will appear in SDP)
o long-form name in English
o type of name ("media", "proto", "fmt", "bwtype", "nettype", or
"addrtype")
o a one paragraph explanation of the purpose of the registered name.
o a reference to the specification (e.g. RFC number) of the
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.
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 [RFC2234]. defined in [RFC2234].
; SDP Syntax ; SDP Syntax
announcement = proto-version announcement = proto-version
origin-field origin-field
session-name-field session-name-field
information-field information-field
uri-field uri-field
skipping to change at page 38, line 35 skipping to change at page 41, line 4
; 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 decimal-uchar = DIGIT
/ POS-DIGIT DIGIT / POS-DIGIT DIGIT
/ ("1" 2*(DIGIT)) / ("1" 2*(DIGIT))
/ ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT)
/ ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) / ("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. Changes from RFC 2327
There are seven field names that may be registered with IANA. Using
the terminology in the SDP specification BNF, they are "media",
"proto", "fmt", "att-field", "bwtype", "nettype" and "addrtype".
"media" (e.g., audio, video, application, data).
The set of media is intended to be small and SHOULD NOT be
extended except under rare circumstances. The same rules should
apply for media names as for top-level MIME content types, and
where possible the same name should be registered for SDP as for
MIME. For media other than existing MIME top-level content types,
a standards-track RFC MUST be produced for a new top-level content
type to be registered, and the registration MUST provide good
justification why no existing media name is appropriate (the
"Standards Action" policy of RFC 2434 [RFC2434]).
"proto"
The "proto" field describes the transport protocol used. This
SHOULD reference a standards-track protocol RFC. This memo
registers three values: "RTP/AVP" is a reference to RTP [RFC1889]
used under the RTP Profile for Audio and Video Conferences with
Minimal Control [RFC1890]) running over UDP/IP; "TCP" denotes an
unspecified format over TCP; and "udp" indicates an unspecified
format over UDP.
New transport protocols MAY be registered with IANA. Registrations
MUST reference an RFC describing the protocol. Such an RFC MAY be
Experimental or Informational, although it is preferable if it is
Standards-Track. Registrations MUST also define the rules by which
their "fmt" namespace is managed (see below).
"fmt"
Each transport protocol, defined by the "proto" field, has an
associated "fmt" namespace that describes the media formats which
may conveyed by that protocol. Formats cover all the possible
encodings that might want to be transported in a multimedia
session.
RTP payload formats under the "RTP/AVP" protocol that have been
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 as defined by the MIME type
registration for the payload format.
For "TCP" and "udp" protocols, new formats SHOULD be registered.
Use of an existing MIME subtype for the format is encouraged. If
no MIME subtype exists, it is RECOMMENDED that a suitable one is
registered through the IETF process (RFC 2048) by production of,
or reference to, a standards-track RFC. If a MIME subtype is for
some reason inappropriate, an RFC publication describing the
format MUST be referenced in the registration, but it may be
Informational or Experimental if the protocol is not deemed to be
of widespread deployment.
For other protocols, formats MAY be registered according to the
rules of the associated "proto" specification.
Registrations of new formats MUST specify which transport
protocols they apply to.
"att-field" (Attribute names)
Attribute field names MUST be registered with IANA and documented,
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.
New attribute registerations are accepted according to the
"Specification Required" policy of RFC 2434, provided that the
specification includes the following information:
o contact name, email address and telephone number
o attribute-name (as it will appear in SDP)
o long-form attribute name in English
o type of attribute (session level, media level, or both)
o whether the attribute value is subject to the charset
attribute.
o a one paragraph explanation of the purpose of the attribute.
o a specification of appropriate attribute values for this
attribute.
The above is the minimum that IANA will accept. Attributes that
are expected to see widespread use and interoperability, SHOULD be
documented with a standards-track RFC that specifies the attribute
more precisely.
Submitters of registrations should ensure that the specification
is in the spirit of SDP attributes, most notably that the
attribute is platform independent in the sense that it makes no
implicit assumptions about operating systems and does not name
specific pieces of software in a manner that might inhibit
interoperability.
"bwtype" (bandwidth specifiers)
A proliferation of bandwidth specifiers is strongly discouraged.
New bandwidth specifiers MUST be registered with IANA. The
submission MUST reference a standards-track RFC specifying the
semantics of the bandwidth specifier precisely, and indicating
when it should be used, and why the existing registered bandwidth
specifiers do not suffice.
"nettype" (Network Type)
New network types may be registered with IANA if SDP needs to be
used in the context of non-Internet environments. Whilst these
are not normally the preserve of IANA, there may be circumstances
when an Internet application needs to interoperate with a non-
Internet application, such as when gatewaying an Internet
telephony call into the PSTN. The number of network types should
be small and should be rarely extended. A new network type cannot
be registered without registering at least one address type to be
used with that network type. A new network type registration MUST
reference an RFC which gives details of the network type and
address type and specifies how and when they would be used. Such
an RFC MAY be Informational.
"addrtype" (Address Type)
New address types may be registered with IANA. An address type is
only meaningful in the context of a network type, and any
registration of an address type MUST specify a registered network
type, or be submitted along with a network type registration. A
new address type registration MUST reference an RFC giving details
of the syntax of the address type. Such an RFC MAY be
Informational. Address types are not expected to be registered
frequently.
Registration Procedure
In the RFC documentation that registers SDP "media", "proto", "fmt",
"bwtype", "nettype" and "addrtype" fields, the authors MUST include
the following information for IANA to place in the appropriate
registry:
o contact name, email address and telephone number
o name being registered (as it will appear in SDP)
o long-form name in English
o type of name ("media", "proto", "fmt", "bwtype", "nettype", or
"addrtype")
o a one paragraph explanation of the purpose of the registered
name.
o a reference to the specification (e.g. RFC number) of the
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.
Appendix C: Changes from RFC 2327
o Deprecate X- notation for experimental parameters o Deprecate X- notation for experimental parameters
o Clarify that a=recvonly does NOT mean that you don't send o Clarify that a=recvonly does NOT mean that you don't send RTCP,
RTCP, and similarly for sendonly and inactive. These only and similarly for sendonly and inactive. These only effect the RTP
effect the RTP stream. stream.
o Rewrite and correct the ABNF syntax (thanks to Jonathan Lennox) o Rewrite and correct the ABNF syntax (thanks to Jonathan Lennox)
o Update BNF to support IPv6. 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 o RFC 2327 mandated that either e= or p= was required. Both are now
now optional, to reflect actual usage. optional, to reflect actual usage.
o Removed references to "conference" from the description of o Removed references to "conference" from the description of the t=
the t= line, to make it less SAP oriented. 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 References have been updated and split into normative and o References have been updated and split into normative and
informative sections. informative sections.
o Section 3.1 was replaced with a reference to RFC 2119, and o Section 3.1 was replaced with a reference to RFC 2119, and the
the memo has been updated to use the RFC 2119 terminology memo has been updated to use the RFC 2119 terminology (MUST,
(MUST, SHOULD, etc). SHOULD, etc).
o Use of "application/sdp" as MIME a type for SDP files is now o Use of "application/sdp" as MIME a type for SDP files is now
"MUST" rather than "SHOULD". "MUST" rather than "SHOULD".
o Many sections have been updated to be less SAP specific, and o Many sections have been updated to be less SAP specific, and to
to reference other current uses of SDP such as RTSP and SIP. reference other current uses of SDP such as RTSP and SIP.
o The introduction and background has been rewritten, to remove o The introduction and background has been rewritten, to remove
references to the Mbone, reflecting current use of SDP. references to the Mbone, reflecting current use of SDP.
o The section on concatenation of session descriptions (which o The section on concatenation of session descriptions (which was
was not allowed in SAP, but allowed in other cases) has been not allowed in SAP, but allowed in other cases) has been removed.
removed. It is assumed that transports of SDP specify will
specify this.
o The description of the c= line has been updated to reflect It is assumed that transports of SDP specify will specify this.
common usage of SDP, rather than Mbone conferencing with SAP.
o The b= line no longer makes a normative reference to the o The description of the c= line has been updated to reflect common
Mbone FAQ for bandwidth limits at various TTLs. The AS usage of SDP, rather than Mbone conferencing with SAP.
modifier to b= is 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 Allow a=rtpmap to be a session level attribute, in addition o Allow a=rtpmap to be a session level attribute, in addition to a
to a media level attribute media level attribute
o Clarify the limitations of the k= field o Clarify the limitations of the k= field
o Clarify IANA considerations o Clarify IANA considerations
Appendix D: Authors' Addresses Appendix C. Acknowledgments
Mark Handley
International Computer Science Institute,
1947 Center Street, Suite 600,
Berkeley, CA 94704
United States
Email: mjh@icir.org
Van Jacobson
Packet Design
2465 Latham Street
Mountain View, CA 94040
United States
Email: van@packetdesign.com
Colin Perkins
USC Information Sciences Institute
3811 N. Fairfax Drive, Suite 200
Arlington, VA 22203
United States
Email: csp@csperkins.org
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 suggestions contributing to this document. In particular, we would
like to thank Eve Schooler, Steve Casner, Bill Fenner, Allison like to thank Eve Schooler, Steve Casner, Bill Fenner, Allison
Mankin, Ross Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Mankin, Ross Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann,
Steve Hanna and Jonathan Lennox. Steve Hanna and Jonathan Lennox.
Full Copyright Statement Normative References
Copyright (C) The Internet Society 2003. All Rights Reserved. [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
This document and translations of it may be copied and furnished to [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax
others, and derivative works that comment on or otherwise explain it Specifications: ABNF", RFC 2234, November 1997.
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.
The limited permissions granted above are perpetual and will not be [3] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
revoked by the Internet Society or its successors or assigns. 2279, January 1998.
This document and the information contained herein is provided on an [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
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."
Intellectual Property [5] Alvestrand, H., "Tags for the Identification of Languages", BCP
47, RFC 3066, January 2001.
Informative References
[6] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation", RFC 1305, March 1992.
[7] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996.
[8] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
with Minimal Control", RFC 1890, January 1996.
[9] Handley, M., Perkins, C. and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[11] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
[12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[13] Huitema, C., "RTCP attribute in SDP",
draft-ietf-mmusic-sdp4nat-05 (work in progress), June 2003.
Authors' Addresses
Mark Handley
University College London
Gower Street
London WC1E 6BT
UK
EMail: M.Handley@cs.ucl.ac.uk
Van Jacobson
Packet Design
2465 Latham Street
Mountain View, CA 94040
USA
EMail: van@packetdesign.com
Colin Perkins
University of Glasgow
17 Lilybank Gardens
Glasgow G12 8QQ
UK
EMail: csp@csperkins.org
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of claims of rights made available for publication and any assurances of
skipping to change at page 45, line 39 skipping to change at page 45, line 27
obtain a general license or permission for the use of such obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Normative References Full Copyright Statement
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC2234] D. Crocker and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
[RFC2434] T. Narten and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434, October
1998.
[RFC3066] H. Alvestrand, "Tags for the Identification of Languages",
RFC 3066, January 2001.
Informative References
[RFC1305] D. Mills, "Network Time Protocol (version 3) specification
and implementation", RFC 1305, March 1992.
[RFC1889] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications",
RFC 1889, January 1996.
[RFC1890] H. Schulzrinne, "RTP Profile for Audio and Video
Conferences with Minimal Control", RFC 1890, January
1996.
[RFC2974] M. Handley, C. Perkins and E. Whelan, "Session Copyright (C) The Internet Society (2003). All Rights Reserved.
Announcement Protocol", RFC 2974, October 2000.
[RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. This document and translations of it may be copied and furnished to
Peterson, R. Sparks, M. Handley, E. Schooler "SIP: Session others, and derivative works that comment on or otherwise explain it
Initiatation Protocol", RFC 3261, May 2002. or assist in its implementation 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.
[RFC2326] H. Schulzrinne, A. Rao and R. Lanphier, "Real Time The limited permissions granted above are perpetual and will not be
Streaming Protocol (RTSP)" RFC 2326, April 1998. revoked by the Internet Society or its successors or assignees.
[RFC3264] J. Rosenberg and H. Schulzrinne, "An Offer/Answer Model This document and the information contained herein is provided on an
with SDP", RFC 3264, May 2002. "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.
[RTCPSDP] C. Huitema, "RTCP Attribute in SDP", Work in progress Acknowledgment
(draft-ietf-mmusic-sdp4nat-03.txt), May 2002
[H.332] ITU-T Recommendation H.332 (1998): "Multimedia Terminal for Funding for the RFC Editor function is currently provided by the
Receiving Internet-based H.323 Conferences", ITU, Geneva. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/