draft-ietf-mmusic-sdp-new-14.txt   draft-ietf-mmusic-sdp-new-15.txt 
Network Working Group M. Handley Network Working Group M. Handley
Internet-Draft UCL Internet-Draft UCL
Obsoletes: 2327, 3266 (if V. Jacobson Obsoletes: 2327, 3266 (if V. Jacobson
approved) Packet Design approved) Packet Design
Expires: March 4, 2004 C. Perkins Expires: April 26, 2004 C. Perkins
University of Glasgow University of Glasgow
September 4, 2003 October 27, 2003
SDP: Session Description Protocol SDP: Session Description Protocol
draft-ietf-mmusic-sdp-new-14.txt draft-ietf-mmusic-sdp-new-15.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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 4, 2004. This Internet-Draft will expire on April 26, 2004.
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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . 3
3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . 5 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . 4
3.1 Multicast Announcement . . . . . . . . . . . . . . . . . . . 5 3.1 Multicast Announcement . . . . . . . . . . . . . . . . . . . 4
3.2 Session Initiation . . . . . . . . . . . . . . . . . . . . . 5 3.2 Session Initiation . . . . . . . . . . . . . . . . . . . . . 4
3.3 Streaming media . . . . . . . . . . . . . . . . . . . . . . 5 3.3 Streaming media . . . . . . . . . . . . . . . . . . . . . . 4
3.4 Email and the World Wide Web . . . . . . . . . . . . . . . . 5 3.4 Email and the World Wide Web . . . . . . . . . . . . . . . . 4
4. Requirements and Recommendations . . . . . . . . . . . . . . 6 4. Requirements and Recommendations . . . . . . . . . . . . . . 5
4.1 Media Information . . . . . . . . . . . . . . . . . . . . . 7 4.1 Media Information . . . . . . . . . . . . . . . . . . . . . 6
4.2 Timing Information . . . . . . . . . . . . . . . . . . . . . 7 4.2 Timing Information . . . . . . . . . . . . . . . . . . . . . 6
4.3 Private Sessions . . . . . . . . . . . . . . . . . . . . . . 8 4.3 Private Sessions . . . . . . . . . . . . . . . . . . . . . . 7
4.4 Obtaining Further Information about a Session . . . . . . . 8 4.4 Obtaining Further Information about a Session . . . . . . . 7
4.5 Categorisation . . . . . . . . . . . . . . . . . . . . . . . 8 4.5 Categorisation . . . . . . . . . . . . . . . . . . . . . . . 7
4.6 Internationalization . . . . . . . . . . . . . . . . . . . . 8 4.6 Internationalization . . . . . . . . . . . . . . . . . . . . 7
5. SDP Specification . . . . . . . . . . . . . . . . . . . . . 8 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . 7
5.1 Protocol Version ("v=") . . . . . . . . . . . . . . . . . . 11 5.1 Protocol Version ("v=") . . . . . . . . . . . . . . . . . . 10
5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . . 11 5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . . 10
5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . . . 12 5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . . . 11
5.4 Session and Media Information ("i=") . . . . . . . . . . . . 12 5.4 Session and Media Information ("i=") . . . . . . . . . . . . 11
5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . . 13 5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . . 12
5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . . 14 5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . . 13
5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . . 16 5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . . 15
5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . . 17 5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . . 16
5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . . 18 5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . . 17
5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . . . 18 5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . . . 18
5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . . . 19 5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . . . 18
5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . . . 20 5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . . . 20
5.14 Media Announcements ("m=") . . . . . . . . . . . . . . . . . 21 5.14 Media Announcements ("m=") . . . . . . . . . . . . . . . . . 21
6. Suggested Attributes . . . . . . . . . . . . . . . . . . . . 25 6. Suggested Attributes . . . . . . . . . . . . . . . . . . . . 24
7. Communicating Conference Control Policy . . . . . . . . . . 30 7. Communicating Conference Control Policy . . . . . . . . . . 30
8. Security Considerations . . . . . . . . . . . . . . . . . . 31 8. Security Considerations . . . . . . . . . . . . . . . . . . 30
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32
9.1 Media types ("media") . . . . . . . . . . . . . . . . . . . 32 9.1 The "application/sdp" media type . . . . . . . . . . . . . . 32
9.2 Transport protocols ("proto") . . . . . . . . . . . . . . . 32 9.2 Registration of Parameters . . . . . . . . . . . . . . . . . 33
9.3 Media formats ("fmt") . . . . . . . . . . . . . . . . . . . 33 A. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 36
9.4 Attribute names ("att-field") . . . . . . . . . . . . . . . 33 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 41
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 Normative References . . . . . . . . . . . . . . . . . . . . 42
Informative References . . . . . . . . . . . . . . . . . . . 42 Informative References . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 43
Intellectual Property and Copyright Statements . . . . . . . 45 Intellectual Property and Copyright Statements . . . . . . . 44
1. Introduction 1. Introduction
[Note to RFC Editor: All references to RFC XXXX should be replaced by
the RFC number of this document, when published.]
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
protocol, and is intended to use different transport protocols as protocol, and is intended to use different transport protocols as
appropriate, including the Session Announcement Protocol [RFC2974], appropriate, including the Session Announcement Protocol [8], Session
Session Initiation Protocol [RFC3261], Real-Time Streaming Protocol Initiation Protocol [9], Real-Time Streaming Protocol [10],
[RFC2326], electronic mail using the MIME extensions, and the electronic mail using the MIME extensions, and the Hypertext
Hypertext Transport Protocol. Transport Protocol.
SDP is intended to be general purpose so that it can be used in a SDP is intended to be general purpose so that it can be used in a
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
skipping to change at page 4, line 52 skipping to change at page 4, line 7
Session Announcement: A session announcement is a mechanism by which Session Announcement: A session announcement is a mechanism by which
a session description is conveyed to users in a pro-active a session description is conveyed to users in a pro-active
fashion, i.e., the session description was not explicitly fashion, i.e., the session description was not explicitly
requested by the user. requested by the user.
Session Description: A well defined format for conveying sufficient Session Description: A well defined format for conveying sufficient
information to discover and participate in a multimedia session. 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 [1].
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 [8]. 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 [9] is an application layer
layer control protocol for creating, modifying and terminating control protocol for creating, modifying and terminating sessions
sessions such as Internet multimedia conferences, Internet telephone such as Internet multimedia conferences, Internet telephone calls and
calls and multimedia distribution. The SIP messages used to create multimedia distribution. The SIP messages used to create sessions
sessions carry session descriptions which allow participants to agree carry session descriptions which allow participants to agree on a set
on a set of compatible media types. These session descriptions are of compatible media types. These session descriptions are commonly
commonly formatted using SDP. When used with SIP, the offer/answer formatted using SDP. When used with SIP, the offer/answer model [11]
model [RFC3264] provides a limited framework for negotiation using provides a limited framework for negotiation using SDP.
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 [10], is an application- level
level protocol for control over the delivery of data with real-time protocol for control over the delivery of data with real-time
properties. RTSP provides an extensible framework to enable 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
skipping to change at page 8, line 12 skipping to change at page 7, line 14
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 [8] and SIP [9].
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
skipping to change at page 8, line 37 skipping to change at page 7, line 39
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 [3] to allow many different languages to
languages to be represented. However, to assist in compact be represented. However, to assist in compact representations, SDP
representations, SDP also allows other character sets such as ISO also allows other character sets such as ISO 8859-1 to be used when
8859-1 to be used when desired. Internationalization only applies to desired. Internationalization only applies to free-text fields
free-text fields (session name and background information), and not (session name and background information), and not to SDP as a whole.
to SDP as a whole.
5. SDP Specification 5. SDP Specification
SDP session descriptions are entirely textual using the ISO 10646 SDP session descriptions are entirely textual using the ISO 10646
character set in UTF-8 encoding. SDP field names and attribute names character set in UTF-8 encoding. SDP field names and attribute names
use only the US-ASCII subset of UTF-8, but textual fields and use only the US-ASCII subset of UTF-8, but textual fields and
attribute values MAY use the full ISO 10646 character set. The attribute values MAY use the full ISO 10646 character set. Field and
textual form, as opposed to a binary encoding such as ASN.1 or XDR, attribute values which use the full UTF-8 character set are never
was chosen to enhance portability, to enable a variety of transports directly compared, hence there is no requirement for UTF-8
to be used (e.g, session description in a MIME email message) and to normalization. The textual form, as opposed to a binary encoding
allow flexible, text-based toolkits (e.g., Tcl/Tk) to be used to such as ASN.1 or XDR, was chosen to enhance portability, to enable a
generate and to process session descriptions. However, since SDP may variety of transports to be used (e.g, session description in a MIME
be used in environments where the maximum permissable size of a email message) and to allow flexible, text-based toolkits (e.g., Tcl/
session description is limited (e.g. SAP announcements; SIP Tk) to be used to generate and to process session descriptions.
transported in UDP), the encoding is deliberately compact. Also, However, since SDP may be used in environments where the maximum
since announcements may be transported via very unreliable means or permissable size of a session description is limited (e.g. SAP
damaged by an intermediate caching server, the encoding was designed announcements; SIP transported in UDP), the encoding is deliberately
with strict order and formatting rules so that most errors would compact. Also, since announcements may be transported via very
result in malformed announcements which could be detected easily and unreliable means or damaged by an intermediate caching server, the
discarded. This also allows rapid discarding of encrypted encoding was designed with strict order and formatting rules so that
announcements for which a receiver does not have the correct key. most errors would result in malformed announcements which could be
detected easily and discarded. This also allows rapid discarding of
encrypted announcements for which a receiver does not have the
correct key.
An SDP session description may contain URIs which reference external
content in the "u=", "k=" and "a=" lines. These URIs may be
dereferenced in some cases, making the session description non-self
contained.
An SDP session description consists of a number of lines of text of An SDP session description consists of a number of lines of text of
the form: the form:
<type>=<value> <type>=<value>
where <type> MUST be exactly one case-significant character and where <type> MUST be exactly one case-significant character and
<value> is structured text whose format depends on <type>. In <value> is structured text whose format depends on <type>. In
general <value> is either a number of fields delimited by a single general <value> is either a number of fields delimited by a single
space character, or a free format string. Whitespace MUST NOT be used space character, or a free format string. Whitespace MUST NOT be used
skipping to change at page 9, line 50 skipping to change at page 9, line 12
Session description Session description
v= (protocol version) v= (protocol version)
o= (owner/creator and session identifier). o= (owner/creator and session identifier).
s= (session name) s= (session name)
i=* (session information) i=* (session information)
u=* (URI of description) u=* (URI of description)
e=* (email address) e=* (email address)
p=* (phone number) p=* (phone number)
c=* (connection information - not required if included in c=* (connection information - not required if included in
all media) all media)
b=* (bandwidth information) b=* (zero or more bandwidth information lines)
One or more time descriptions (see below) One or more time descriptions (see below)
z=* (time zone adjustments) z=* (time zone adjustments)
k=* (encryption key) k=* (encryption key)
a=* (zero or more session attribute lines) a=* (zero or more session attribute lines)
Zero or more media descriptions (see below) Zero or more media descriptions (see below)
Time description Time description
t= (time the session is active) t= (time the session is active)
r=* (zero or more repeat times) r=* (zero or more repeat times)
Media description Media description
m= (media name and transport address) m= (media name and transport address)
i=* (media title) i=* (media title)
c=* (connection information - optional if included at c=* (connection information - optional if included at
session-level) session-level)
b=* (bandwidth information) b=* (zero or more bandwidth information lines)
k=* (encryption key) k=* (encryption key)
a=* (zero or more media attribute lines) a=* (zero or more media attribute lines)
The set of type letters is deliberately small and not intended to be The set of type letters is deliberately small and not intended to be
extensible -- an SDP parser MUST completely ignore any announcement extensible -- an SDP parser MUST completely ignore any announcement
that contains a type letter that it does not understand. The that contains a type letter that it does not understand. The
attribute mechanism ("a=" described below) is the primary means for attribute mechanism ("a=" described below) is the primary means for
extending SDP and tailoring it to particular applications or media. extending SDP and tailoring it to particular applications or media.
Some attributes (the ones listed in this document) have a defined Some attributes (the ones listed in this document) have a defined
meaning but others may be added on an application-, media- or meaning but others may be added on an application-, media- or
skipping to change at page 11, line 40 skipping to change at page 10, line 50
<username> is the user's login on the originating host, or it is "-" <username> is the user's login on the originating host, or it is "-"
if the originating host does not support the concept of user ids. if the originating host does not support the concept of user ids.
<username> MUST NOT contain spaces. <username> MUST NOT contain spaces.
<session id> is a numeric string such that the tuple of <username>, <session id> is a numeric string such that the tuple of <username>,
<session id>, <network type>, <address type> and <address> form a <session id>, <network type>, <address type> and <address> form a
globally unique identifier for the session. The method of session globally unique identifier for the session. The method of session
id allocation is up to the creating tool, but it has been id allocation is up to the creating tool, but it has been
suggested that a Network Time Protocol (NTP) format timestamp be suggested that a Network Time Protocol (NTP) format timestamp be
used to ensure uniqueness [RFC1305]. used to ensure uniqueness [7].
<version> is a version number for this announcement. It is needed for <version> is a version number for this announcement. It is needed for
proxy announcements to detect which of several announcements for proxy announcements to detect which of several announcements for
the same session is the most recent. Again its usage is up to the the same session is the most recent. Again its usage is up to the
creating tool, so long as <version> is increased when a creating tool, so long as <version> is increased when a
modification is made to the session data. Again, it is RECOMMENDED modification is made to the session data. Again, it is RECOMMENDED
(but not mandatory) that an NTP format timestamp is used. (but not mandatory) that an NTP format 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".
skipping to change at page 13, line 10 skipping to change at page 12, line 20
media definitions, "i=" fields are primarily intended for labeling media definitions, "i=" fields are primarily intended for labeling
media streams. As such, they are most likely to be useful when a media streams. As such, they are most likely to be useful when a
single session has more than one distinct media stream of the same single session has more than one distinct media stream of the same
media type. An example would be two different whiteboards, one for media type. An example would be two different whiteboards, one for
slides and one for feedback and questions. slides and one for feedback and questions.
5.5 URI ("u=") 5.5 URI ("u=")
u=<URI> u=<URI>
A URI is a Universal Resource Identifier as used by WWW clients. The A URI is a Universal Resource Identifier as used by WWW clients [4].
URI should be a pointer to additional information about the The URI should be a pointer to additional information about the
conference. This field is OPTIONAL, but if it is present it MUST be conference. This field is OPTIONAL, but if it is present it MUST be
specified before the first media field. No more than one URI field is specified before the first media field. No more than one URI field is
allowed per session description. allowed per session description.
5.6 Email Address and Phone Number ("e=" and "p=") 5.6 Email Address and Phone Number ("e=" and "p=")
e=<email address> e=<email address>
p=<phone number> p=<phone number>
These specify contact information for the person responsible for the These specify contact information for the person responsible for the
skipping to change at page 16, line 4 skipping to change at page 15, line 16
which is semantically equivalent to: which is semantically equivalent to:
c=IN IP6 FF15::101 c=IN IP6 FF15::101
c=IN IP6 FF15::102 c=IN IP6 FF15::102
c=IN IP6 FF15::103 c=IN IP6 FF15::103
(remembering that the TTL field is not present in IPv6 multicast). (remembering that the TTL field is not present in IPv6 multicast).
Multiple addresses or "c=" lines MAY be specified on a per-media Multiple addresses or "c=" lines MAY be specified on a per-media
basis. They MUST NOT be specified for a session-level "c=" field. basis only if they provide multicast addresses for different layers
in a hierarchical or layered encoding scheme. 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.
5.8 Bandwidth ("b=") 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. Modifiers The <bandwidth-value> is in kilobits per second by default. Modifiers
MAY specify that alternative units are to be used (the modifiers MAY specify that alternative units are to be used (the modifiers
defined in this memo use the default units). defined in this memo use the default units).
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. Two modifiers are initially defined: the bandwidth figure. Two modifiers are initially defined:
CT Conference Total CT If the bandwidth of a session or media in a session is different
If the bandwidth of a session or media in a session is from the bandwidth implicit from the scope, a "b=CT:..." line
different from the bandwidth implicit from the scope, a should be supplied for the session giving the proposed upper limit
"b=CT:..." line should be supplied for the session giving to the bandwidth used. The primary purpose of this is to give an
the proposed upper limit to the bandwidth used. The primary approximate idea as to whether two or more sessions can co-exist
purpose of this is to give an approximate idea as to whether simultaneously. When using the CT modifier with RTP, if several
two or more sessions can co-exist simultaneously. RTP sessions are part of the conference, the conference total
refers to total bandwidth of all RTP sessions.
AS Application-Specific Maximum AS The bandwidth is interpreted to be application-specific (it will
The bandwidth is interpreted to be application-specific (it be the application's concept of maximum bandwidth). Normally this
will be the application's concept of maximum bandwidth). will coincide with what is set on the application's "maximum
Normally this will coincide with what is set on the bandwidth" control if applicable. For RTP based applications, AS
application's "maximum bandwidth" control if applicable. gives the RTP "session bandwidth" as defined in section 6.2 of
For RTP based applications, AS gives the RTP "session [12].
bandwidth" as defined in section 6.2 of [RFC1889].
Note that CT gives a total bandwidth figure for all the media at all Note that CT gives a total bandwidth figure for all the media at all
sites. AS gives a bandwidth figure for a single media at a single sites. AS gives a bandwidth figure for a single media at a single
site, although there may be many sites sending simultaneously. site, although there may be many sites sending simultaneously.
Tool writers MAY define experimental bandwidth modifiers by prefixing Tool writers MAY define experimental bandwidth modifiers by prefixing
their modifier with "X-". For example: their modifier with "X-". For example:
b=X-YZ:128 b=X-YZ:128
skipping to change at page 17, line 21 skipping to change at page 16, line 35
"t=" fields MAY be used if a session is active at multiple "t=" fields MAY be used if a session is active at multiple
irregularly spaced times; each additional "t=" field specifies an irregularly spaced times; each additional "t=" field specifies an
additional period of time for which the session will be active. If additional period of time for which the session will be active. If
the session is active at regular times, an "r=" field (see below) the session is active at regular times, an "r=" field (see below)
should be used in addition to and following a "t=" field - in which should be used in addition to and following a "t=" field - in which
case the "t=" field specifies the start and stop times of the repeat case the "t=" field specifies the start and stop times of the repeat
sequence. sequence.
The first and second sub-fields give the start and stop times for the The first and second sub-fields give the start and stop times for the
session respectively. These values are the decimal representation of session respectively. These values are the decimal representation of
Network Time Protocol (NTP) time values in seconds [RFC1305]. To Network Time Protocol (NTP) time values in seconds [7]. To convert
convert these values to UNIX time, subtract decimal 2208988800. these values to UNIX time, subtract decimal 2208988800.
NTP timestamps are 64 bit values which wrap sometime in the year NTP timestamps are 64 bit values which wrap sometime in the year
2036. Since SDP uses an arbitrary length decimal representation, 2036. Since SDP uses an arbitrary length decimal representation,
this should not cause an issue (SDP timestamps will continue counting this should not cause an issue (SDP timestamps will continue counting
seconds since 1900, NTP will use the value modulo the 64 bit limit). seconds since 1900, NTP will use the value modulo the 64 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 the though it will not become active until after the start-time. If the
start-time is also zero, the session is regarded as permanent. start-time is also zero, the session is regarded as permanent.
skipping to change at page 19, line 34 skipping to change at page 18, line 47
If a session is likely to last several years, it is expected that the If a session is likely to last several years, it is expected that the
session announcement will be modified periodically rather than session announcement will be modified periodically rather than
transmit several years worth of adjustments in one announcement. transmit several years worth of adjustments in one announcement.
5.12 Encryption Keys ("k=") 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 simple
field is permitted before the first media entry (in which case it mechanism for key exchange is provided by the key field ("k=")
applies to all media in the session), or for each media entry as although this is primarily supported for compatibility with older
required. implementations and its use is NOT RECOMMENDED. Work is in progress
to define new key exchange mechanisms for use with SDP [17][16] and
it is expected that new applications will use those mechanisms.
The format of keys and their usage is outside the scope of this A key field is permitted before the first media entry (in which case
document, but see [RFC1890] for an example. it applies to all media in the session), or for each media entry as
required. The format of keys and their usage is outside the scope of
this document, and the key field provides no way to indicate the
encryption algorithm to be used, key type, or other information about
the key: this is assumed to be provided by the higher-level protocol
using SDP. If there is a need to convey this information within SDP,
the extensions mentioned previously SHOULD be used. Many security
protocols require two keys, one for confidentiality and another for
integrity. This specification does not support the transfer of two
keys.
The method indicates the mechanism to be used to obtain a usable key The method indicates the mechanism to be used to obtain a usable key
by external means, or from the encoded encryption key given. The by external means, or from the encoded encryption key given. 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.
skipping to change at page 20, line 14 skipping to change at page 19, line 40
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
a request is made to the given URI, the MIME content-type of a request is made to the given URI, the reply should specify
the reply specifies the encoding for the key in the reply. the encoding for the key. The URI is often a secure HTTP URI,
although this is not required.
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 The key field MUST NOT be used unless it can be guaranteed that the
SDP is conveyed over a secure and trusted channel. An example of such SDP is conveyed over a secure and trusted channel. An example of such
a channel might be SDP embedded inside an S/MIME message. a channel might be SDP embedded inside an S/MIME message or a TLS
protected HTTP or SIP session. It is important to ensure that the
secure channel is with the party that is authorized to join the
session, not an intermediary: if a caching proxy server is used, it
is important to ensure that the proxy is either trusted or unable to
access the SDP. Definition of appropriate security measures is beyond
the scope of this specification, and should be defined by the users
of SDP.
5.13 Attributes ("a=") 5.13 Attributes ("a=")
a=<attribute> a=<attribute>
a=<attribute>:<value> a=<attribute>:<value>
Attributes are the primary means for extending SDP. Attributes may Attributes are the primary means for extending SDP. Attributes may
be defined to be used as "session-level" attributes, "media-level" be defined to be used as "session-level" attributes, "media-level"
attributes, or both. attributes, or both.
skipping to change at page 22, line 9 skipping to change at page 21, line 43
and "data" is that the former is a media flow such as whiteboard and "data" is that the former is a media flow such as whiteboard
information, and the latter is bulk-data transfer such as information, and the latter is bulk-data transfer such as
multicasting of program executables which will not typically be multicasting of program executables which will not typically be
displayed to the user. "control" is used to specify an additional displayed to the user. "control" is used to specify an additional
conference control channel for the session. conference control channel for the session.
The second sub-field is the transport port to which the media stream The second sub-field is the transport port to which the media stream
is sent. The meaning of the transport port depends on the network is sent. The meaning of the transport port depends on the network
being used as specified in the relevant "c=" field, and on the being used as specified in the relevant "c=" field, and on the
transport protocol defined in the third sub-field. Other ports used transport protocol defined in the third sub-field. Other ports used
by the media application (such as the RTCP port [RFC1889]) MAY be by the media application (such as the RTCP port [12]) MAY be derived
derived algorithmically from the base media port or MAY be specified algorithmically from the base media port or MAY be specified in a
in a separate attribute (e.g. "a=rtcp:" as defined in [RTCPSDP]). separate attribute (e.g. "a=rtcp:" as defined in [14]).
For applications where hierarchically encoded streams are being sent For applications where hierarchically encoded streams are being sent
to a unicast address, it may be necessary to specify multiple to a unicast address, it may be necessary to specify multiple
transport ports. This is done using a similar notation to that used transport ports. This is done using a similar notation to that used
for IP multicast addresses in the "c=" field: for IP multicast addresses in the "c=" field:
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. For In such a case, the ports used depend on the transport protocol. For
RTP, the default is that only the even numbered ports are used for RTP, the default is that only the even numbered ports are used for
data and the corresponding one-higher odd port is used for RTCP. For data with the corresponding one-higher odd ports used for the RTCP
example: belonging to the RTP session, and the <number of ports> denoting the
number of RTP sessions. For example:
m=video 49170/2 RTP/AVP 31 m=video 49170/2 RTP/AVP 31
would specify that ports 49170 and 49171 form one RTP/RTCP pair and would specify that ports 49170 and 49171 form one RTP/RTCP pair 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 [14]).
If multiple addresses are specified in the "c=" field and multiple If multiple addresses are specified in the "c=" field and multiple
ports are specified in the "m=" field, a one-to-one mapping from port ports are specified in the "m=" field, a one-to-one mapping from port
to the corresponding address is implied. For example: to the corresponding address is implied. For example:
c=IN IP4 224.2.1.1/127/2 c=IN IP4 224.2.1.1/127/2
m=video 49170/2 RTP/AVP 31 m=video 49170/2 RTP/AVP 31
would imply that address 224.2.1.1 is used with ports 49170 and would imply that address 224.2.1.1 is used with ports 49170 and
49171, and address 224.2.1.2 is used with ports 49172 and 49173. 49171, and address 224.2.1.2 is used with ports 49172 and 49173.
skipping to change at page 23, line 27 skipping to change at page 23, line 13
start appropriate tools, relays, mixers or recorders. start appropriate tools, relays, mixers or recorders.
The main reason to specify the transport-protocol in addition to the The main reason to specify the transport-protocol in addition to the
media format is that the same standard media formats may be carried media format is that the same standard media formats may be carried
over different transport protocols even when the network protocol is over different transport protocols even when the network protocol is
the same - a historical example is vat PCM audio and RTP PCM audio. the same - a historical example is vat PCM audio and 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 [13], the protocol field is "RTP/AVP". Should other RTP profiles be
profiles be defined in the future, their profiles will be specified defined in the future, their profiles will be specified in the same
in the same way. For example, the protocol field "RTP/XYZ" would way. For example, the protocol field "RTP/XYZ" would specify RTP
specify RTP operating under a profile whose short name is "XYZ". operating under a profile whose short 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 field For media whose transport protocol is not RTP or UDP the format field
skipping to change at page 25, line 6 skipping to change at page 24, line 39
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 defined about the number of samples per packet. If a non-default (as defined
in the RTP Audio/Video Profile) packetisation is required, the in the RTP Audio/Video Profile) packetisation is required, 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 [13].
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)
6. Suggested Attributes 6. Suggested Attributes
The following attributes are suggested. Since application writers The following attributes are suggested. Since application writers
skipping to change at page 27, line 39 skipping to change at page 27, line 22
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" "recvonly" should be the default for "type:broadcast"
sessions, "type:meeting" should imply "sendrecv" and sessions, "type:meeting" should imply "sendrecv" and
"type:moderated" should indicate the use of a floor control "type:moderated" should indicate the use of a floor control
tool and that the media tools are started so as to mute new tool and that the media tools are started so as to mute new
sites joining the 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 [15]. 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>
skipping to change at page 28, line 50 skipping to change at page 28, line 33
important. important.
In general, sending session descriptions consisting of In general, sending session descriptions consisting of
multiple languages is discouraged. Instead, multiple multiple languages is discouraged. Instead, multiple
descriptions SHOULD be sent describing the session, one in descriptions SHOULD be sent describing the session, one in
each language. However this is not possible with all each language. However this is not possible with all
transport mechanisms, and so multiple sdplang attributes are transport mechanisms, and so multiple sdplang attributes are
allowed although NOT 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 language tag in US-ASCII [6]. It is not dependent on
the charset attribute. An "sdplang" attribute SHOULD be the charset attribute. An "sdplang" attribute SHOULD be
specified when a session is of sufficient scope to cross specified when a session is of sufficient scope to cross
geographic boundaries where the language of recipients cannot geographic boundaries where the language of recipients cannot
be assumed, or where the session is in a different language be assumed, or where the session is in a different language
from the 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 overriding any session-level language specified. Multiple
lang attributes can be provided either at session or media lang attributes can be provided either at session or media
level if the session description or media use multiple level if the session description or media use multiple
languages, in which case the order of the attributes indicates languages, in which case the order of the attributes indicates
the order of importance of the various languages in the the order of importance of the various languages in 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 [6]. 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 the session is in a different language from the locally
assumed 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.
skipping to change at page 31, line 43 skipping to change at page 31, line 27
should take a few precautions. Session descriptions contain should take a few precautions. Session descriptions contain
information required to start software on the receivers system. information required to start software on the receivers system.
Software that parses a session description MUST NOT be able to start Software that parses a session description MUST NOT be able to start
other software except that which is specifically configured as other software except that which is specifically configured as
appropriate software to participate in multimedia sessions. It is appropriate software to participate in multimedia sessions. It is
normally considered inappropriate for software parsing a session normally considered inappropriate for software parsing a session
description to start, on a user's system, software that is description to start, on a user's system, software that is
appropriate to participate in multimedia sessions, without the user appropriate to participate in multimedia sessions, without the user
first being informed that such software will be started and giving first being informed that such software will be started and giving
their consent. Thus a session description arriving by session their consent. Thus a session description arriving by session
announcement, email, session invitation, or WWW page SHOULD NOT announcement, email, session invitation, or WWW page MUST NOT deliver
deliver the user into an interactive multimedia session without the the user into an interactive multimedia session unless the user has
user being aware that this will happen. As it is not always simple explicitly pre-authorized such action. As it is not always simple to
to tell whether a session is interactive or not, applications that tell whether a session is interactive or not, applications that are
are unsure should assume sessions are interactive. unsure should assume sessions are interactive.
In this specification, there are no attributes which would allow the In this specification, there are no attributes which would allow the
recipient of a session description to be informed to start multimedia recipient of a session description to be informed to start multimedia
tools in a mode where they default to transmitting. Under some tools in a mode where they default to transmitting. Under some
circumstances it might be appropriate to define such attributes. If circumstances it might be appropriate to define such attributes. If
this is done an application parsing a session description containing this is done an application parsing a session description containing
such attributes SHOULD either ignore them, or inform the user that such attributes SHOULD either ignore them, or inform the user that
joining this session will result in the automatic transmission of joining this session will result in the automatic transmission of
multimedia data. The default behaviour for an unknown attribute is multimedia data. The default behaviour for an unknown attribute is
to ignore it. to ignore it.
skipping to change at page 32, line 29 skipping to change at page 32, line 13
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.
9. IANA Considerations 9. IANA Considerations
9.1 The "application/sdp" media type
One new MIME type is to be registered, as defined below. This updates
the previous definition from RFC 2327.
To: ietf-types@iana.org
Subject: Registration of MIME media type application/sdp
MIME media type name: application
MIME subtype name: sdp
Required parameters: None.
Optional parameters: None.
Encoding considerations:
See section 5 of RFC XXXX
Security considerations:
See section 8 of RFC XXXX
Interoperability considerations:
See RFC XXXX
Published specification:
RFC XXXX
Applications which use this media type:
Voice over IP, video teleconferencing, streaming media, instant
messaging, etc. See also section 3 of RFC XXXX.
Additional information:
Magic number(s): None.
File extension(s): The extension ".sdp" is commonly used.
Macintosh File Type Code(s):
Person & email address to contact for further information:
Colin Perkins <csp@csperkins.org>
IETF MMUSIC working group
Intended usage: COMMON
Author/Change controller:
Authors of RFC XXXX
IETF MMUSIC working group
9.2 Registration of Parameters
There are seven field names that may be registered with IANA. Using There are seven field names that may be registered with IANA. Using
the terminology in the SDP specification BNF, they are "media", the terminology in the SDP specification BNF, they are "media",
"proto", "fmt", "att-field", "bwtype", "nettype" and "addrtype". "proto", "fmt", "att-field", "bwtype", "nettype" and "addrtype".
9.1 Media types ("media") 9.2.1 Media types ("media")
The set of media types is intended to be small and SHOULD NOT be The set of media types is intended to be small and SHOULD NOT be
extended except under rare circumstances. The same rules should extended except under rare circumstances. The same rules should
apply for media names as for top-level MIME content types, and where apply for media names as for top-level MIME content types, and where
possible the same name should be registered for SDP as for MIME. For possible the same name should be registered for SDP as for MIME. For
media other than existing MIME top-level content types, a media other than existing MIME top-level content types, a
standards-track RFC MUST be produced for a new top-level content type standards-track RFC MUST be produced for a new top-level content type
to be registered, and the registration MUST provide good to be registered, and the registration MUST provide good
justification why no existing media name is appropriate (the justification why no existing media name is appropriate (the
"Standards Action" policy of RFC 2434 [RFC2434]). "Standards Action" policy of RFC 2434 [5].
9.2 Transport protocols ("proto") 9.2.2 Transport protocols ("proto")
The "proto" field describes the transport protocol used. This SHOULD The "proto" field describes the transport protocol used. This SHOULD
reference a standards-track protocol RFC. This memo registers three reference a standards-track protocol RFC. This memo registers three
values: "RTP/AVP" is a reference to RTP [RFC1889] used under the RTP values: "RTP/AVP" is a reference to RTP [12] used under the RTP
Profile for Audio and Video Conferences with Minimal Control Profile for Audio and Video Conferences with Minimal Control [13]
[RFC1890]) running over UDP/IP; "TCP" denotes an unspecified format running over UDP/IP; "TCP" denotes an unspecified format over TCP;
over TCP; and "udp" indicates an unspecified format over UDP. and "udp" indicates an unspecified format over UDP.
New transport protocols MAY be registered with IANA. Registrations New transport protocols MAY be registered with IANA. Registrations
MUST reference an RFC describing the protocol. Such an RFC MAY be MUST reference an RFC describing the protocol. Such an RFC MAY be
Experimental or Informational, although it is preferable if it is Experimental or Informational, although it is preferable if it is
Standards-Track. Registrations MUST also define the rules by which Standards-Track. Registrations MUST also define the rules by which
their "fmt" namespace is managed (see below). their "fmt" namespace is managed (see below).
9.3 Media formats ("fmt") 9.2.3 Media formats ("fmt")
Each transport protocol, defined by the "proto" field, has an Each transport protocol, defined by the "proto" field, has an
associated "fmt" namespace that describes the media formats which may associated "fmt" namespace that describes the media formats which may
conveyed by that protocol. Formats cover all the possible encodings conveyed by that protocol. Formats cover all the possible encodings
that might want to be transported in a multimedia session. that might want to be transported in a multimedia session.
RTP payload formats under the "RTP/AVP" protocol that have been RTP payload formats under the "RTP/AVP" protocol that have been
assigned static payload types MUST use the static payload type as assigned static payload types MUST use the static payload type as
their "fmt" value. For payload formats under "RTP/AVP" that have a their "fmt" value. For payload formats under "RTP/AVP" that have a
dynamic payload type number, the dynamic payload type number is given dynamic payload type number, the dynamic payload type number is given
skipping to change at page 33, line 43 skipping to change at page 34, line 32
referenced in the registration, but it may be Informational or referenced in the registration, but it may be Informational or
Experimental if the protocol is not deemed to be of widespread Experimental if the protocol is not deemed to be of widespread
deployment. deployment.
For other protocols, formats MAY be registered according to the rules For other protocols, formats MAY be registered according to the rules
of the associated "proto" specification. of the associated "proto" specification.
Registrations of new formats MUST specify which transport protocols Registrations of new formats MUST specify which transport protocols
they apply to. they apply to.
9.4 Attribute names ("att-field") 9.2.4 Attribute names ("att-field")
Attribute field names ("att-field") MUST be registered with IANA and Attribute field names ("att-field") MUST be registered with IANA and
documented, because of noticeable issues due to conflicting documented, because of noticeable issues due to conflicting
attributes under the same name. Unknown attributes in SDP are simply attributes under the same name. Unknown attributes in SDP are simply
ignored, but conflicting ones that fragment the protocol are a ignored, but conflicting ones that fragment the protocol are a
serious problem. serious problem.
New attribute registerations are accepted according to the New attribute registerations are accepted according to the
"Specification Required" policy of RFC 2434, provided that the "Specification Required" policy of RFC 2434, provided that the
specification includes the following information: specification includes the following information:
skipping to change at page 34, line 33 skipping to change at page 35, line 22
expected to see widespread use and interoperability, SHOULD be expected to see widespread use and interoperability, SHOULD be
documented with a standards-track RFC that specifies the attribute documented with a standards-track RFC that specifies the attribute
more precisely. more precisely.
Submitters of registrations should ensure that the specification is Submitters of registrations should ensure that the specification is
in the spirit of SDP attributes, most notably that the attribute is in the spirit of SDP attributes, most notably that the attribute is
platform independent in the sense that it makes no implicit platform independent in the sense that it makes no implicit
assumptions about operating systems and does not name specific pieces assumptions about operating systems and does not name specific pieces
of software in a manner that might inhibit interoperability. of software in a manner that might inhibit interoperability.
9.5 Bandwidth specifiers ("bwtype") 9.2.5 Bandwidth specifiers ("bwtype")
A proliferation of bandwidth specifiers is strongly discouraged. A proliferation of bandwidth specifiers is strongly discouraged.
New bandwidth specifiers ("bwtype" fields) MUST be registered with New bandwidth specifiers ("bwtype" fields) MUST be registered with
IANA. The submission MUST reference a standards-track RFC specifying IANA. The submission MUST reference a standards-track RFC specifying
the semantics of the bandwidth specifier precisely, and indicating the semantics of the bandwidth specifier precisely, and indicating
when it should be used, and why the existing registered bandwidth when it should be used, and why the existing registered bandwidth
specifiers do not suffice. specifiers do not suffice.
9.6 Network types ("nettype") 9.2.6 Network types ("nettype")
New network types (the "nettype" field) may be registered with IANA New network types (the "nettype" field) may be registered with IANA
if SDP needs to be used in the context of non-Internet environments. 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 Whilst these are not normally the preserve of IANA, there may be
circumstances when an Internet application needs to interoperate with circumstances when an Internet application needs to interoperate with
a non- Internet application, such as when gatewaying an Internet a non- Internet application, such as when gatewaying an Internet
telephony call into the PSTN. The number of network types should be telephony call into the PSTN. The number of network types should be
small and should be rarely extended. A new network type cannot be small and should be rarely extended. A new network type cannot be
registered without registering at least one address type to be used registered without registering at least one address type to be used
with that network type. A new network type registration MUST with that network type. A new network type registration MUST
reference an RFC which gives details of the network type and address 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 type and specifies how and when they would be used. Such an RFC MAY
be Informational. be Informational.
9.7 Address types ("addrtype") 9.2.7 Address types ("addrtype")
New address types ("addrtype") may be registered with IANA. An New address types ("addrtype") may be registered with IANA. An
address type is only meaningful in the context of a network type, and address type is only meaningful in the context of a network type, and
any registration of an address type MUST specify a registered network any registration of an address type MUST specify a registered network
type, or be submitted along with a network type registration. A new type, or be submitted along with a network type registration. A new
address type registration MUST reference an RFC giving details of the address type registration MUST reference an RFC giving details of the
syntax of the address type. Such an RFC MAY be Informational. syntax of the address type. Such an RFC MAY be Informational.
Address types are not expected to be registered frequently. Address types are not expected to be registered frequently.
9.8 Registration Procedure 9.2.8 Registration Procedure
In the RFC documentation that registers SDP "media", "proto", "fmt", In the RFC documentation that registers SDP "media", "proto", "fmt",
"bwtype", "nettype" and "addrtype" fields, the authors MUST include "bwtype", "nettype" and "addrtype" fields, the authors MUST include
the following information for IANA to place in the appropriate the following information for IANA to place in the appropriate
registry: registry:
o contact name, email address and telephone number o contact name, email address and telephone number
o name being registered (as it will appear in SDP) o name being registered (as it will appear in SDP)
skipping to change at page 35, line 48 skipping to change at page 36, line 37
o a reference to the specification (e.g. RFC number) of the o a reference to the specification (e.g. RFC number) of the
registered name. registered name.
IANA may refer any registration to the IESG Transport Area Directors IANA may refer any registration to the IESG Transport Area Directors
for review, and may request revisions to be made before a for review, and may request revisions to be made before a
registration will be made. registration will be made.
Appendix A. SDP Grammar Appendix A. SDP Grammar
This appendix provides an Augmented BNF grammar for SDP. ABNF is This appendix provides an Augmented BNF grammar for SDP. ABNF is
defined in [RFC2234]. defined in [2].
; 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
email-fields email-fields
phone-fields phone-fields
connection-field connection-field
skipping to change at page 39, line 34 skipping to change at page 40, line 24
unicast-address = IP4-address / IP6-address / FQDN / extn-addr unicast-address = IP4-address / IP6-address / FQDN / extn-addr
multicast-address = IP4-multicast / IP6-multicast multicast-address = IP4-multicast / IP6-multicast
IP4-multicast = m1 3( "." decimal-uchar ) IP4-multicast = m1 3( "." decimal-uchar )
"/" ttl [ "/" integer ] "/" ttl [ "/" integer ]
; IPv4 multicast addresses may be in the ; IPv4 multicast addresses may be in the
; range 224.0.0.0 to 239.255.255.255 ; range 224.0.0.0 to 239.255.255.255
m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) /
("23" DIGIT )) ("23" DIGIT )
IP6-multicast = hexpart [ "/" integer ] IP6-multicast = hexpart [ "/" integer ]
; IPv6 address starting with FF ; IPv6 address starting with FF
ttl = (POS-DIGIT *2DIGIT) / "0" ttl = (POS-DIGIT *2DIGIT) / "0"
FQDN = 4*(alpha-numeric / "-" / ".") FQDN = 4*(alpha-numeric / "-" / ".")
; fully qualified domain name as specified ; fully qualified domain name as specified
; in RFC1035 ; in RFC1035
skipping to change at page 40, line 28 skipping to change at page 41, line 18
;session-level attribute to be used ;session-level attribute to be used
byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF)
;any byte except NUL, CR or LF ;any byte except NUL, CR or LF
non-ws-string = 1*(VCHAR/%x80-FF) non-ws-string = 1*(VCHAR/%x80-FF)
;string of visible characters ;string of visible characters
token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
/ %x41-5A / %x5E-7E / %x41-5A / %x5E-7E
; definition from RFC 2045 -
; "any (US-ASCII) CHAR except SPACE, CTLs,
; or tspecials".
; the tspecials are ()<>@,;:
token = 1*(token-char) token = 1*(token-char)
email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF
;any byte except NUL, CR, LF, or the quoting ;any byte except NUL, CR, LF, or the quoting
;characters ()<> ;characters ()<>
integer = POS-DIGIT *DIGIT integer = POS-DIGIT *DIGIT
; generic sub-rules: primitives ; generic sub-rules: primitives
skipping to change at page 41, line 4 skipping to change at page 41, line 37
; 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. Changes from RFC 2327 Appendix B. Acknowledgments
o Deprecate X- notation for experimental parameters
o Clarify that a=recvonly does NOT mean that you don't send RTCP,
and similarly for sendonly and inactive. These only effect the RTP
stream.
o Rewrite and correct the ABNF syntax (thanks to Jonathan Lennox)
o Update BNF to support IPv6.
o Add a=inactive attribute.
o Add a=maxptime attribute.
o RFC 2327 mandated that either e= or p= was required. Both are now
optional, to reflect actual usage.
o Removed references to "conference" from the description of the t=
line, to make it less SAP oriented.
o Note about wrap-around of NTP timestamps in t=
o References have been updated and split into normative and
informative sections.
o Section 3.1 was replaced with a reference to RFC 2119, and the
memo has been updated to use the RFC 2119 terminology (MUST,
SHOULD, etc).
o Use of "application/sdp" as MIME a type for SDP files is now
"MUST" rather than "SHOULD".
o Many sections have been updated to be less SAP specific, and to
reference other current uses of SDP such as RTSP and SIP.
o The introduction and background has been rewritten, to remove
references to the Mbone, reflecting current use of SDP.
o The section on concatenation of session descriptions (which was
not allowed in SAP, but allowed in other cases) has been removed.
It is assumed that transports of SDP specify will specify this.
o The description of the c= line has been updated to reflect common
usage of SDP, rather than Mbone conferencing with SAP.
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 Note use of s= in sessions with no meaningful name
o Allow a=rtpmap to be a session level attribute, in addition to a
media level attribute
o Clarify the limitations of the k= field
o Clarify IANA considerations
Appendix C. 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.
Normative References Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[3] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC [3] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998. 2279, January 1998.
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Alvestrand, H., "Tags for the Identification of Languages", BCP [6] Alvestrand, H., "Tags for the Identification of Languages", BCP
47, RFC 3066, January 2001. 47, RFC 3066, January 2001.
Informative References 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 [7] Mills, D., "Network Time Protocol (Version 3) Specification,
with Minimal Control", RFC 1890, January 1996. Implementation", RFC 1305, March 1992.
[9] Handley, M., Perkins, C. and E. Whelan, "Session Announcement [8] Handley, M., Perkins, C. and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000. Protocol", RFC 2974, October 2000.
[10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[11] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming [10] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998. Protocol (RTSP)", RFC 2326, April 1998.
[12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
[13] Huitema, C., "RTCP attribute in SDP", [12] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
draft-ietf-mmusic-sdp4nat-05 (work in progress), June 2003. "RTP: A Transport Protocol for Real-Time Applications", RFC
3550, July 2003.
[13] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", RFC 3551, July 2003.
[14] Huitema, C., "Real Time Control Protocol (RTCP) attribute in
Session Description Protocol (SDP)", RFC 3605, October 2003.
[15] International Telecommunications Union, "H.323 extended for
loosely coupled conferences", ITU Recommendation H.332,
September 1998.
[16] Arkko, J., "Key Management Extensions for Session Description
Protocol (SDP) and Real Time Streaming Protocol (RTSP)",
draft-ietf-mmusic-kmgmt-ext-09 (work in progress), October
2003.
[17] Andreasen, F., Baugher, M. and D. Wing, "SDP Security
Descriptions for Media Streams",
draft-ietf-mmusic-sdescriptions-02 (work in progress), October
2003.
Authors' Addresses Authors' Addresses
Mark Handley Mark Handley
University College London University College London
Gower Street Gower Street
London WC1E 6BT London WC1E 6BT
UK UK
EMail: M.Handley@cs.ucl.ac.uk EMail: M.Handley@cs.ucl.ac.uk
 End of changes. 

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