draft-ietf-mmusic-sdp-new-21.txt   draft-ietf-mmusic-sdp-new-22.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: April 25, 2005 C. Perkins Expires: May 28, 2005 C. Perkins
University of Glasgow University of Glasgow
October 25, 2004 November 27, 2004
SDP: Session Description Protocol SDP: Session Description Protocol
draft-ietf-mmusic-sdp-new-21.txt draft-ietf-mmusic-sdp-new-22.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 39 skipping to change at page 1, line 38
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://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 25, 2005. This Internet-Draft will expire on May 28, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2004).
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . 3 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . 3
3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . 3 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . 4
3.1 Multicast Session Announcement . . . . . . . . . . . . . . 3 3.1 Multicast Session Announcement . . . . . . . . . . . . . . 4
3.2 Session Initiation . . . . . . . . . . . . . . . . . . . . 4 3.2 Session Initiation . . . . . . . . . . . . . . . . . . . . 4
3.3 Streaming media . . . . . . . . . . . . . . . . . . . . . 4 3.3 Streaming media . . . . . . . . . . . . . . . . . . . . . 4
3.4 Email and the World Wide Web . . . . . . . . . . . . . . . 4 3.4 Email and the World Wide Web . . . . . . . . . . . . . . . 4
4. Requirements and Recommendations . . . . . . . . . . . . . . 5 4. Requirements and Recommendations . . . . . . . . . . . . . . 5
4.1 Media and Transport Information . . . . . . . . . . . . . 5 4.1 Media and Transport Information . . . . . . . . . . . . . 6
4.2 Timing Information . . . . . . . . . . . . . . . . . . . . 6 4.2 Timing Information . . . . . . . . . . . . . . . . . . . . 6
4.3 Private Sessions . . . . . . . . . . . . . . . . . . . . . 6 4.3 Private Sessions . . . . . . . . . . . . . . . . . . . . . 7
4.4 Obtaining Further Information about a Session . . . . . . 7 4.4 Obtaining Further Information about a Session . . . . . . 7
4.5 Categorisation . . . . . . . . . . . . . . . . . . . . . . 7 4.5 Categorisation . . . . . . . . . . . . . . . . . . . . . . 7
4.6 Internationalization . . . . . . . . . . . . . . . . . . . 7 4.6 Internationalisation . . . . . . . . . . . . . . . . . . . 7
5. SDP Specification . . . . . . . . . . . . . . . . . . . . . 7 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . 7
5.1 Protocol Version ("v=") . . . . . . . . . . . . . . . . . 10 5.1 Protocol Version ("v=") . . . . . . . . . . . . . . . . . 10
5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 10 5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 11
5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . . 11 5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . . 12
5.4 Session Information ("i=") . . . . . . . . . . . . . . . . 12 5.4 Session Information ("i=") . . . . . . . . . . . . . . . . 12
5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 12 5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 12
5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . 12 5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . 13
5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . 13 5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . 13
5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 15 5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 16
5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 16 5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 17
5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . 17 5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . 18
5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . 18 5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . 18
5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 19 5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 19
5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . 20 5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . 21
5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . . 21 5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . . 22
6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 24 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . 30 7. Security Considerations . . . . . . . . . . . . . . . . . . 31
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32
8.1 The "application/sdp" media type . . . . . . . . . . . . . 32 8.1 The "application/sdp" media type . . . . . . . . . . . . . 32
8.2 Registration of Parameters . . . . . . . . . . . . . . . . 33 8.2 Registration of Parameters . . . . . . . . . . . . . . . . 33
8.3 Encryption Key Access Methods . . . . . . . . . . . . . . 37 8.3 Encryption Key Access Methods . . . . . . . . . . . . . . 38
A. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 37 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 38
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 42 10. Summary of Changes from RFC 2327 . . . . . . . . . . . . . . 43
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 42 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.2 Informative References . . . . . . . . . . . . . . . . . . . 43 12.1 Normative References . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 44 12.2 Informative References . . . . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 46
Intellectual Property and Copyright Statements . . . . . . . 47
1. Introduction 1. Introduction
When initiating multimedia teleconferences, voice-over-IP calls, When initiating multimedia teleconferences, voice-over-IP calls,
streaming video, or other sessions, there is a requirement to convey streaming video, or other sessions, there is a requirement to convey
media details, transport addresses, and other session description media details, transport addresses, and other session description
metadata to the participants. 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 [9], Session appropriate, including the Session Announcement Protocol [14],
Initiation Protocol [10], Real-Time Streaming Protocol [11], Session Initiation Protocol [15], Real-Time Streaming Protocol [16],
electronic mail using the MIME extensions, and the Hypertext electronic mail using the MIME extensions, and the 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.
This memo updates RFC 2327 [6] in the light of implementation
experience, and adds a small number of new features. Section 10
outlines the changes introduced in this memo.
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: A multimedia conference is a set of two or more Conference: A multimedia conference is a set of two or more
communicating users along with the software they are using to communicating users along with the software they are using to
communicate. communicate.
Session: A multimedia session is a set of multimedia senders and Session: A multimedia session is a set of multimedia senders and
receivers and the data streams flowing from senders to receivers. receivers and the data streams flowing from senders to receivers.
A multimedia conference is an example of a multimedia session. A multimedia conference is an example of a multimedia session.
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 [1]. document are to be interpreted as described in RFC 2119 [3].
3. Examples of SDP Usage 3. Examples of SDP Usage
3.1 Multicast Session Announcement 3.1 Multicast Session 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 [9]. SDP provides the is the Session Announcement Protocol, SAP [14]. SDP provides the
recommended session description format for such session recommended session description format for such session
announcements. announcements.
3.2 Session Initiation 3.2 Session Initiation
The Session Initiation Protocol, SIP [10] is an application layer The Session Initiation Protocol, SIP [15] is an application layer
control protocol for creating, modifying and terminating sessions control protocol for creating, modifying and terminating sessions
such as Internet multimedia conferences, Internet telephone calls and such as Internet multimedia conferences, Internet telephone calls and
multimedia distribution. The SIP messages used to create sessions multimedia distribution. The SIP messages used to create sessions
carry session descriptions which allow participants to agree on a set carry session descriptions which allow participants to agree on a set
of compatible media types. These session descriptions are commonly of compatible media types. These session descriptions are commonly
formatted using SDP. When used with SIP, the offer/answer model [12] formatted using SDP. When used with SIP, the offer/answer model [17]
provides a limited framework for negotiation using SDP. provides a limited framework for negotiation using SDP.
3.3 Streaming media 3.3 Streaming media
The Real Time Streaming Protocol, RTSP [11], is an application-level The Real Time Streaming Protocol, RTSP [16], is an application-level
protocol for control over the delivery of data with real-time protocol for control over the delivery of data with real-time
properties. RTSP provides an extensible framework to enable 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
skipping to change at page 6, line 5 skipping to change at page 6, line 11
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 any encryption keys), and to announce the resources to be used to any
non-participants that may need to know (this latter feature is non-participants that may need to know (this latter feature is
primarily useful when SDP is used with a multicast session primarily useful when SDP is used with a multicast session
announcement protocol). announcement protocol).
4.1 Media and Transport Information 4.1 Media and Transport Information
An SDP session description includes the following media information: An SDP session description includes the following media information:
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.)
In addition to media format and transport protocol, SDP conveys In addition to media format and transport protocol, SDP conveys
address and port details. For an IP multicast session, these address and port details. For an IP multicast session, these
comprise: comprise:
o The multicast group address for media o The multicast group address for media
o The transport port for media o The transport port for media
This address and port are the destination address and destination This address and port are the destination address and destination
skipping to change at page 7, line 5 skipping to change at page 7, line 12
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: mechanisms are dependent on the mechanism used to convey SDP: mechanisms are
currently defined for SDP transported using SAP [9] and SIP [10], currently defined for SDP transported using SAP [14] and SIP [15],
others may be defined in future. others may be defined in future.
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
skipping to change at page 7, line 28 skipping to change at page 7, line 35
(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 session other advertisement mechanism, it may be desirable to filter session
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 Internationalisation
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 [3] to allow many different languages to sets in the UTF-8 encoding [5] to allow many different languages to
be represented. However, to assist in compact representations, SDP be represented. However, to assist in compact representations, SDP
also allows other character sets such as ISO 8859-1 to be used when also allows other character sets such as ISO 8859-1 to be used when
desired. Internationalization only applies to free-text fields desired. Internationalisation only applies to free-text fields
(session name and background information), and not to SDP as a whole. (session name and background information), and not to SDP as a whole.
5. SDP Specification 5. SDP Specification
An SDP session description is denoted by the MIME content type An SDP session description is denoted by the MIME content type
"application/sdp" (See Section 8). "application/sdp" (See Section 8).
An SDP session description is entirely textual using the ISO 10646 An SDP session description is 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. Field and attribute values MAY use the full ISO 10646 character set. Field and
attribute values which use the full UTF-8 character set are never attribute values which use the full UTF-8 character set are never
directly compared, hence there is no requirement for UTF-8 directly compared, hence there is no requirement for UTF-8
normalization. The textual form, as opposed to a binary encoding normalisation. The textual form, as opposed to a binary encoding
such as ASN.1 or XDR, was chosen to enhance portability, to enable a such as ASN.1 or XDR, was chosen to enhance portability, to enable a
variety of transports to be used, and to allow flexible, text-based variety of transports to be used, and to allow flexible, text-based
toolkits to be used to generate and process session descriptions. toolkits to be used to generate and process session descriptions.
However, since SDP may be used in environments where the maximum However, since SDP may be used in environments where the maximum
permissable size of a session description is limited, the encoding is permissible size of a session description is limited, the encoding is
deliberately compact. Also, since announcements may be transported deliberately compact. Also, since announcements may be transported
via very unreliable means or damaged by an intermediate caching via very unreliable means or damaged by an intermediate caching
server, the encoding was designed with strict order and formatting server, the encoding was designed with strict order and formatting
rules so that most errors would result in malformed session rules so that most errors would result in malformed session
announcements which could be detected easily and discarded. This announcements which could be detected easily and discarded. This
also allows rapid discarding of encrypted session announcements for also allows rapid discarding of encrypted session announcements for
which a receiver does not have the correct key. which a receiver does not have the correct key.
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:
skipping to change at page 10, line 32 skipping to change at page 10, line 32
Text fields such as the session name and information are octet Text fields 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. If the "a=charset" attribute is not present, newline character. If the "a=charset" attribute is not present,
these octet strings MUST be interpreted as containing ISO-10646 these octet strings MUST be interpreted as containing ISO-10646
characters in UTF-8 encoding (the presence of the "a=charset" characters in UTF-8 encoding (the presence of the "a=charset"
attribute MAY force some fields to be interpreted differently). attribute MAY force some fields to be interpreted differently).
A session description can contain domain names in the "o=", "u=",
"e=", "c=" and "a=" lines. Any domain name used in SDP MUST comply
with [1], [2]. Internationalised domain names (IDNs) MUST be
represented using the ASCII Compatible Encoding (ACE) form defined in
[11] and MUST NOT be directly represented in UTF-8 or any other
encoding (this requirement is for compatibility with RFC 2327 and
other SDP-related standards, which predate the development of
internationalized domain names).
5.1 Protocol Version ("v=") 5.1 Protocol Version ("v=")
v=0 v=0
The "v=" field gives the version of the Session Description Protocol. The "v=" field gives the version of the Session Description Protocol.
This memo defines version 0. There is no minor version number. This memo defines version 0. There is no minor version number.
5.2 Origin ("o=") 5.2 Origin ("o=")
o=<username> <sess-id> <sess-version> <nettype> <addrtype> o=<username> <sess-id> <sess-version> <nettype> <addrtype>
skipping to change at page 11, line 10 skipping to change at page 11, line 23
<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.
The <username> MUST NOT contain spaces. The <username> MUST NOT contain spaces.
<sess-id> is a numeric string such that the tuple of <username>, <sess-id> is a numeric string such that the tuple of <username>,
<sess-id>, <nettype>, <addrtype> and <unicast-address> form a <sess-id>, <nettype>, <addrtype> and <unicast-address> form a
globally unique identifier for the session. The method of globally unique identifier for the session. The method of
<sess-id> allocation is up to the creating tool, but it has been <sess-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 [8]. used to ensure uniqueness [13].
<sess-version> is a version number for this session description. Its <sess-version> is a version number for this session description. Its
usage is up to the creating tool, so long as <sess-version> is usage is up to the creating tool, so long as <sess-version> is
increased when a modification is made to the session data. Again, increased when a modification is made to the session data. Again,
it is RECOMMENDED that an NTP format timestamp is used. it is RECOMMENDED that an NTP format timestamp is used.
<nettype> is a text string giving the type of network. Initially <nettype> is a text string giving the type of network. Initially
"IN" is defined to have the meaning "Internet", but other values "IN" is defined to have the meaning "Internet", but other values
MAY be registered in future (see Section 8). MAY be registered in future (see Section 8).
skipping to change at page 12, line 17 skipping to change at page 12, line 30
i=<session description> i=<session description>
The "i=" field provides textual information about the session. There The "i=" field provides textual information about the session. There
MUST be at most one session-level "i=" field per session description, MUST be at most one session-level "i=" field per session description,
and at most one "i=" field per media. If the "a=charset" attribute and at most one "i=" field per media. If the "a=charset" attribute
is present, it specifies the character set used in the "i=" field. is present, it specifies the character set used in the "i=" field.
If the "a=charset" attribute is not present, the "i=" field MUST If the "a=charset" attribute is not present, the "i=" field MUST
contain ISO 10646 characters in UTF-8 encoding. contain ISO 10646 characters in UTF-8 encoding.
A single "i=" field MAY also be used for each media definition. In A single "i=" field MAY also be used for each media definition. In
media definitions, "i=" fields are primarily intended for labeling media definitions, "i=" fields are primarily intended for labelling
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.
The "i=" field is intended to provide a free-form human readable The "i=" field is intended to provide a free-form human readable
description of the session or the purpose of a media stream. It is description of the session or the purpose of a media stream. It is
not suitable for parsing by automata. not suitable for parsing by automata.
5.5 URI ("u=") 5.5 URI ("u=")
u=<uri> u=<uri>
A URI is a Universal Resource Identifier as used by WWW clients [4], A URI is a Universal Resource Identifier as used by WWW clients [7],
[6]. The URI should be a pointer to additional information about the [9]. The URI should be a pointer to additional information about the
session. This field is OPTIONAL, but if it is present it MUST be session. This field is OPTIONAL, but if it is present it MUST be
specified before the first media field. No more than one URI field specified before the first media field. No more than one URI field
is allowed per session description. is 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>
The "e=" and "p=" lines specify contact information for the person The "e=" and "p=" lines specify contact information for the person
responsible for the conference. This is not necessarily the same responsible for the conference. This is not necessarily the same
person that created the conference announcement. person that created the conference announcement.
Inclusion of an email address or phone number is OPTIONAL. Note that Inclusion of an email address or phone number is OPTIONAL. Note that
the previous version of SDP specified that either an email field or a the previous version of SDP specified that either an email field or a
phone field MUST be specified, but this was widely ignored. The phone field MUST be specified, but this was widely ignored. The
change brings the specification into line with common usage. change brings the specification into line with common usage.
If the email addres or phone number are present, they MUST be If the email address or phone number are present, they MUST be
specified before the first media field. More than one email or phone specified before the first media field. More than one email or phone
field can be given for a session description. field can be given for a session description.
Phone numbers SHOULD be given in the form of an international public Phone numbers SHOULD be given in the form of an international public
telecommunication number (see ITU-T Recommendation E.164) preceded by telecommunication number (see ITU-T Recommendation E.164) preceded by
a "+". Spaces and hyphens may be used to split up a phone field to a "+". Spaces and hyphens may be used to split up a phone field to
aid readability if desired. For example: aid readability if desired. For example:
p=+1 617 555-6011 p=+1 617 555-6011
skipping to change at page 14, line 25 skipping to change at page 14, line 41
addresses will be given in a session description that is addresses will be given in a session description that is
communicated by a multicast announcement, though this is not communicated by a multicast announcement, though this is not
prohibited. prohibited.
o Sessions using an IPv4 multicast connection address MUST also have o Sessions using an IPv4 multicast connection address MUST also have
a time to live (TTL) value present in addition to the multicast a time to live (TTL) value present in addition to the multicast
address. The TTL and the address together define the scope with address. The TTL and the address together define the scope with
which multicast packets sent in this conference will be sent. TTL which multicast packets sent in this conference will be sent. TTL
values MUST be in the range 0-255. While the TTL MUST be values MUST be in the range 0-255. While the TTL MUST be
specified, its use to scope multicast traffic is deprecated; specified, its use to scope multicast traffic is deprecated;
applications SHOULD use an adminstratively scoped address instead. applications SHOULD use an administratively scoped address
instead.
The TTL for the session is appended to the address using a slash as a The TTL for the session is appended to the address using a slash 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 MUST IPv6 multicast does not use TTL scoping, and hence the TTL value MUST
NOT be present for IPv6 multicast. It is expected that IPv6 scoped NOT be present for IPv6 multicast. It is expected that IPv6 scoped
addresses will be used to limit the scope of conferences. addresses will be used to limit the scope of conferences.
skipping to change at page 15, line 43 skipping to change at page 16, line 13
used for IP unicast addresses. used for IP unicast addresses.
5.8 Bandwidth ("b=") 5.8 Bandwidth ("b=")
b=<bwtype>:<bandwidth> b=<bwtype>:<bandwidth>
This OPTIONAL field denotes the proposed bandwidth to be used by the This OPTIONAL field denotes the proposed bandwidth to be used by the
session or media. The <bwtype> is an alphanumeric modifier giving session or media. The <bwtype> is an alphanumeric modifier giving
the meaning of the <bandwidth> figure. Two values are defined in the meaning of the <bandwidth> figure. Two values are defined in
this specification, but other values MAY be registered in future (see this specification, but other values MAY be registered in future (see
Section 8 and [22], [16]): Section 8 and [20], [24]):
CT If the bandwidth of a session or media in a session is different CT If the bandwidth of a session or media in a session is different
from the bandwidth implicit from the scope, a "b=CT:..." line from the bandwidth implicit from the scope, a "b=CT:..." line
SHOULD be supplied for the session giving the proposed upper limit SHOULD be supplied for the session giving the proposed upper limit
to the bandwidth used (the "conference total" bandwidth). The to the bandwidth used (the "conference total" bandwidth). The
primary purpose of this is to give an approximate idea as to primary purpose of this is to give an approximate idea as to
whether two or more sessions can co-exist simultaneously. When whether two or more sessions can co-exist simultaneously. When
using the CT modifier with RTP, if several RTP sessions are part using the CT modifier with RTP, if several RTP sessions are part
of the conference, the conference total refers to total bandwidth of the conference, the conference total refers to total bandwidth
of all RTP sessions. of all RTP sessions.
AS The bandwidth is interpreted to be application-specific (it will AS The bandwidth is interpreted to be application-specific (it will
be the application's concept of maximum bandwidth). Normally this be the application's concept of maximum bandwidth). Normally this
will coincide with what is set on the application's "maximum will coincide with what is set on the application's "maximum
bandwidth" control if applicable. For RTP based applications, AS bandwidth" control if applicable. For RTP based applications, AS
gives the RTP "session bandwidth" as defined in section 6.2 of gives the RTP "session bandwidth" as defined in Section 6.2 of
[14]. [18].
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.
A prefix "X-" is defined for <bwtype> names. This is intended for A prefix "X-" is defined for <bwtype> names. This is intended for
experimental purposes only. For example: experimental purposes only. For example:
b=X-YZ:128 b=X-YZ:128
skipping to change at page 16, line 48 skipping to change at page 17, line 20
Multiple "t=" lines MAY be used if a session is active at multiple Multiple "t=" lines MAY be used if a session is active at multiple
irregularly spaced times; each additional "t=" lines specifies an irregularly spaced times; each additional "t=" lines 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=" line (see below) the session is active at regular times, an "r=" line (see below)
should be used in addition to, and following, a "t=" line - in which should be used in addition to, and following, a "t=" line - in which
case the "t=" line specifies the start and stop times of the repeat case the "t=" line 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 since 1900 [8]. Network Time Protocol (NTP) time values in seconds since 1900 [13].
To convert these values to UNIX time, subtract decimal 2208988800. To convert these values to UNIX time, subtract decimal 2208988800.
NTP timestamps are elsewhere represented by 64 bit values which wrap NTP timestamps are elsewhere represented by 64 bit values which wrap
sometime in the year 2036. Since SDP uses an arbitrary length sometime in the year 2036. Since SDP uses an arbitrary length
decimal representation, this should not cause an issue (SDP decimal representation, this should not cause an issue (SDP
timestamps MUST continue counting seconds since 1900, NTP will use timestamps MUST continue counting seconds since 1900, NTP will use
the value modulo the 64 bit limit). 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 though it will not become active until after the <start-time>. If
skipping to change at page 19, line 20 skipping to change at page 19, line 39
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 simple description protocol MAY be used to convey encryption keys. A simple
mechanism for key exchange is provided by the key field ("k=") mechanism for key exchange is provided by the key field ("k=")
although this is primarily supported for compatibility with older although this is primarily supported for compatibility with older
implementations and its use is NOT RECOMMENDED. Work is in progress implementations and its use is NOT RECOMMENDED. Work is in progress
to define new key exchange mechanisms for use with SDP [20][21] and to define new key exchange mechanisms for use with SDP [26][27] and
it is expected that new applications will use those mechanisms. it is expected that new applications will use those mechanisms.
A key field is permitted before the first media entry (in which case A key 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 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 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 this document, and the key field provides no way to indicate the
encryption algorithm to be used, key type, or other information about encryption algorithm to be used, key type, or other information about
the key: this is assumed to be provided by the higher-level protocol 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, using SDP. If there is a need to convey this information within SDP,
the extensions mentioned previously SHOULD be used. Many security the extensions mentioned previously SHOULD be used. Many security
skipping to change at page 19, line 50 skipping to change at page 20, line 21
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 encryption key the SDP is conveyed over a secure channel. The encryption key
is interpreted as text according to the charset attribute, use is interpreted as text according to the charset attribute, use
the "k=base64:" method to convey characters that are otherwise the "k=base64:" method to convey characters that are otherwise
prohibited in SDP. prohibited in SDP.
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 [13] because it includes characters that are base64 encoded [12] 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 reply should specify a request is made to the given URI, the reply should specify
the encoding for the key. The URI is often a secure HTTP URI, the encoding for the key. The URI is often a secure HTTP URI,
skipping to change at page 20, line 28 skipping to change at page 20, line 48
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 SDP is conveyed over a secure and trusted channel. An example of
such a channel might be SDP embedded inside an S/MIME message or a such a channel might be SDP embedded inside an S/MIME message or a
TLS-protected HTTP session. It is important to ensure that the TLS-protected HTTP session. It is important to ensure that the
secure channel is with the party that is authorized to join the secure channel is with the party that is authorised to join the
session, not an intermediary: if a caching proxy server is used, it 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 is important to ensure that the proxy is either trusted or unable to
access the SDP. Definition of appropriate security measures is access the SDP. Definition of appropriate security measures is
beyond the scope of this specification, and should be defined by the beyond the scope of this specification, and should be defined by the
users of SDP. users of SDP.
5.13 Attributes ("a=") 5.13 Attributes ("a=")
a=<attribute> a=<attribute>
a=<attribute>:<value> a=<attribute>:<value>
skipping to change at page 21, line 45 skipping to change at page 22, line 16
5.14 Media Descriptions ("m=") 5.14 Media Descriptions ("m=")
m=<media> <port> <proto> <fmt> ... m=<media> <port> <proto> <fmt> ...
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 terminated Each media description starts with an "m=" field, and is terminated
by either the next "m=" field or by the end of the session by either the next "m=" field or by the end of the session
description. A media field has several sub-fields: description. A media field has several sub-fields:
<media> is the media type. Currently defined media are "audio", <media> is the media type. Currently defined media are "audio",
"video", "text" and "application", although this list may be "video", "text", "application" and "message", although this list
extended in future (see Section 8). may be extended in future (see Section 8).
<port> is the transport port to which the media stream is sent. The <port> is the transport port to which the media stream is sent. The
meaning of the transport port depends on the network being used as meaning of the transport port depends on the network being used as
specified in the relevant "c=" field, and on the transport specified in the relevant "c=" field, and on the transport
protocol defined in the <proto> sub-field of the media field. protocol defined in the <proto> sub-field of the media field.
Other ports used by the media application (such as the RTCP port Other ports used by the media application (such as the RTCP port
[14]) MAY be derived algorithmically from the base media port or [18]) MAY be derived algorithmically from the base media port or
MAY be specified in a separate attribute (for example "a=rtcp:" as MAY be specified in a separate attribute (for example "a=rtcp:" as
defined in [17]). defined in [21]).
For applications where hierarchically encoded streams are being For applications where hierarchically encoded streams are being
sent to a unicast address, it may be necessary to specify multiple sent to a unicast address, it may be necessary to specify multiple
transport ports. This is done using a similar notation to that transport ports. This is done using a similar notation to that
used for IP multicast addresses in the "c=" field: used for IP multicast addresses in the "c=" field:
m=<media> <port>/<number of ports> <transport> <fmt list> m=<media> <port>/<number of ports> <proto> <fmt> ...
In such a case, the ports used depend on the transport protocol. In such a case, the ports used depend on the transport protocol.
For RTP, 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 with the corresponding one-higher odd ports used for the for data with the corresponding one-higher odd ports used for the
RTCP belonging to the RTP session, and the <number of ports> RTCP belonging to the RTP session, and the <number of ports>
denoting the number of RTP sessions. For example: 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 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 and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the
transport protocol and 31 is the format (see below). If transport protocol and 31 is the format (see below). If
non-contiguous ports are required, they must be signalled using a non-contiguous ports are required, they must be signalled using a
separate attribute (for example "a=rtcp:" as defined in [17]). separate attribute (for example "a=rtcp:" as defined in [21]).
If multiple addresses are specified in the "c=" field and multiple If multiple addresses are specified in the "c=" field and multiple
ports are specified in the "m=" field, a one-to-one mapping from ports are specified in the "m=" field, a one-to-one mapping from
port to the corresponding address is implied. For example: port to the corresponding address is implied. For example:
c=IN IP4 224.2.1.1/127/2 c=IN IP4 224.2.1.1/127/2
m=video 49170/2 RTP/AVP 31 m=video 49170/2 RTP/AVP 31
would imply that address 224.2.1.1 is used with ports 49170 and would imply that address 224.2.1.1 is used with ports 49170 and
49171, and address 224.2.1.2 is used with ports 49172 and 49173. 49171, and address 224.2.1.2 is used with ports 49172 and 49173.
skipping to change at page 23, line 30 skipping to change at page 23, line 47
<proto> is the transport protocol. The meaning of the transport <proto> is the transport protocol. The meaning of the transport
protocol is dependent on the address type field in the relevant protocol is dependent on the address type field in the relevant
"c=" field. Thus a "c=" field of IP4 indicates that the transport "c=" field. Thus a "c=" field of IP4 indicates that the transport
protocol runs over IP4. The following transport protocols are protocol runs over IP4. The following transport protocols are
defined, but may be extended through registration of new protocols defined, but may be extended through registration of new protocols
with IANA (see Section 8): with IANA (see Section 8):
* udp: denotes an unspecified protocol running over UDP. * udp: denotes an unspecified protocol running over UDP.
* RTP/AVP: denotes RTP [14] used under the RTP Profile for Audio * RTP/AVP: denotes RTP [18] used under the RTP Profile for Audio
and Video Conferences with Minimal Control [15] running over and Video Conferences with Minimal Control [19] running over
UDP. UDP.
* RTP/SAVP: denotes the Secure Real-time Transport Protocol [18] * RTP/SAVP: denotes the Secure Real-time Transport Protocol [22]
running over UDP. running over UDP.
The main reason to specify the transport-protocol in addition to The main reason to specify the transport-protocol in addition to
the media format is that the same standard media formats may be the media format is that the same standard media formats may be
carried over different transport protocols even when the network carried over different transport protocols even when the network
protocol is the same - a historical example is vat PCM audio and protocol is the same - a historical example is vat PCM audio and
RTP PCM audio, another might be TCP/RTP PCM audio. In addition, RTP PCM audio, another might be TCP/RTP PCM audio. In addition,
relays and monitoring tools that are transport-protocol-specific relays and monitoring tools that are transport-protocol-specific
but format-independent are possible. but format-independent are possible.
skipping to change at page 24, line 13 skipping to change at page 24, line 33
payload formats MAY be used in the session, but the first of these payload formats MAY be used in the session, but the first of these
formats SHOULD be used as the default format for the session. For formats SHOULD be used as the default format for the session. For
dynamic payload type assignments the "a=rtpmap:" attribute (see dynamic payload type assignments the "a=rtpmap:" attribute (see
Section 6) SHOULD be used to map from an RTP payload type number Section 6) SHOULD be used to map from an RTP payload type number
to a media encoding name that identifies the payload format. The to a media encoding name that identifies the payload format. The
"a=fmtp:" attribute MAY be used to specify format parameters (see "a=fmtp:" attribute MAY be used to specify format parameters (see
Section 6). Section 6).
If the <proto> sub-field is "udp" the <fmt> sub-fields MUST If the <proto> sub-field is "udp" the <fmt> sub-fields MUST
reference a media type describing the format under the "audio", reference a media type describing the format under the "audio",
"video", "text" and "application" top-level MIME types. The media "video", "text", "application" or "message" top-level MIME types.
type registration SHOULD define the packetization format for use The media type registration SHOULD define the packet format for
with UDP transport. use with UDP transport.
For media using other transport protocols, the <fmt> field is For media using other transport protocols, the <fmt> field is
protocol specific. Rules for interpretation of the <fmt> protocol specific. Rules for interpretation of the <fmt>
sub-field MUST be defined when registering new protocols (see sub-field MUST be defined when registering new protocols (see
section 8.2.2). section 8.2.2).
6. SDP Attributes 6. SDP Attributes
The following attributes are defined. Since application writers may The following attributes are defined. Since application writers may
add new attributes as they are required, this list is not exhaustive. add new attributes as they are required, this list is not exhaustive.
skipping to change at page 30, line 41 skipping to change at page 31, line 11
formats specified for the media. Format-specific parameters formats specified for the media. Format-specific parameters
may be any set of parameters required to be conveyed by SDP may be any set of parameters required to be conveyed by SDP
and given unchanged to the media tool that will use this and given unchanged to the media tool that will use this
format. At most one instance of this attribute is allowed format. At most one instance of this attribute is allowed
for each format. for each format.
It is a media attribute, and is not dependent on charset. It is a media attribute, and is not dependent on charset.
7. Security Considerations 7. Security Considerations
SDP is frequently used with the Session Initiation Protocol [10] SDP is frequently used with the Session Initiation Protocol [15]
using the offer/answer model [12] to agree parameters for unicast using the offer/answer model [17] to agree parameters for unicast
sessions. When used in this manner, the security considerations of sessions. When used in this manner, the security considerations of
those protocols apply. those protocols apply.
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.
skipping to change at page 33, line 24 skipping to change at page 33, line 46
8.2.1 Media types ("media") 8.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 [5]. "Standards Action" policy of RFC 2434 [8].
This memo registers the media types "audio", "video", "text" and This memo registers the media types "audio", "video", "text",
"application". "application" and "message".
Note: The media types "control" and "data" were listed as valid in
the previous version of this specification [6], however their
semantics were never fully specified and they are not widely used.
These media types have been removed in this specification, although
they still remain valid media type capabilities for a SIP user agent
as defined in RFC 3840 [23]. If these media types are considered
useful in future, a Standards Track RFC MUST be produced to document
their use. Until that is done, applications SHOULD NOT use these
types and SHOULD NOT declare support for them in SIP capabilities
declarations (even though they exist in the registry created by RFC
3840).
8.2.2 Transport protocols ("proto") 8.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 [14] used under the RTP values: "RTP/AVP" is a reference to RTP [18] used under the RTP
Profile for Audio and Video Conferences with Minimal Control [15] Profile for Audio and Video Conferences with Minimal Control [19]
running over UDP/IP, "RTP/SAVP" is a reference to the Secure running over UDP/IP, "RTP/SAVP" is a reference to the Secure
Real-time Transport Protocol [18], and "udp" indicates an unspecified Real-time Transport Protocol [22], and "udp" indicates an unspecified
protocol over UDP. protocol over UDP.
If other RTP profiles are defined in the future, their "proto" name If other RTP profiles are defined in the future, their "proto" name
SHOULD be specified in the same manner. For example, an RTP profile SHOULD be specified in the same manner. For example, an RTP profile
whose short name is "XYZ" would be denoted by a "proto" field of whose short name is "XYZ" would be denoted by a "proto" field of
"RTP/XYZ". "RTP/XYZ".
New transport protocols SHOULD be registered with IANA. New transport protocols SHOULD be registered with IANA.
Registrations MUST reference an RFC describing the protocol. Such an Registrations MUST reference an RFC describing the protocol. Such an
RFC MAY be Experimental or Informational, although it is preferable RFC MAY be Experimental or Informational, although it is preferable
skipping to change at page 34, line 42 skipping to change at page 35, line 26
they apply to. they apply to.
8.2.4 Attribute names ("att-field") 8.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 registrations 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:
o contact name, email address and telephone number o contact name, email address and telephone number
o attribute-name (as it will appear in SDP) o attribute-name (as it will appear in SDP)
o long-form attribute name in English o long-form attribute name in English
o type of attribute (session level, media level, or both) o type of attribute (session level, media level, or both)
skipping to change at page 37, line 30 skipping to change at page 38, line 16
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.
8.3 Encryption Key Access Methods 8.3 Encryption Key Access Methods
The IANA currently maintains a table of SDP encryption key access The IANA currently maintains a table of SDP encryption key access
method ("enckey") names. This table is obsolete and SHOULD be method ("enckey") names. This table is obsolete and SHOULD be
removed, since the "k=" line is not extensible. New registrations removed, since the "k=" line is not extensible. New registrations
MUST NOT be accepted. MUST NOT be accepted.
Appendix A. SDP Grammar 9. SDP Grammar
This appendix provides an Augmented BNF grammar for SDP. ABNF is This section provides an Augmented BNF grammar for SDP. ABNF is
defined in [2]. defined in [4].
; SDP Syntax ; SDP Syntax
session-description = proto-version session-description = 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 42, line 31 skipping to change at page 43, line 17
/ 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 RFC2396 and RFC2732 ; URI-reference: from RFC2396 and RFC2732
; addr-spec: from RFC 2822 ; addr-spec: from RFC 2822
Appendix B. Acknowledgments 10. Summary of Changes from RFC 2327
Many people in the IETF MMUSIC working group have made comments and The memo has been significantly restructured, incorporating a large
suggestions contributing to this document. In particular, we would number of clarifications to the specification in light of use. With
like to thank Eve Schooler, Steve Casner, Bill Fenner, Allison the exception of those items noted below, the changes to the memo are
Mankin, Ross Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, intended to be backwards compatible clarifications. However, due to
Steve Hanna, Jonathan Lennox and Keith Drage. inconsistencies and unclear definitions in RFC 2327 it is likely that
some implementations interpreted that memo in ways that differ from
this version of SDP.
9. References The ABNF grammar in Section 9 has been extensively revised and
updated, correcting a number of mistakes and incorporating the RFC
3266 IPv6 extensions. Known inconsistencies between the grammar and
the specification text have been resolved.
9.1 Normative References A media type registration for SDP is included. Requirements for the
registration of attributes and other parameters with IANA have been
clarified and tightened (Section 8). It is noted that "text" and
"message" are valid media types for use with SDP, but that "control"
and "data" are under-specified and deprecated.
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement RFC 2119 terms are now used throughout to specify requirements
levels. Certain of those requirements, in particular in relation to
parameter registration, are stricter than those in RFC 2327.
The "RTP/SAVP" RTP profile and its "fmt" namespace are registered.
The attributes "a=inactive" and "a=maxptime" have been added.
RFC 2327 mandated that either "e=" or "p=" was required. Both are
now optional, to reflect actual usage.
The significant limitations of the "k=" field are noted, and its use
is deprecated.
Most uses of the "x-" prefix notation for experimental parameters are
disallowed and the other uses are deprecated.
11. Acknowledgements
Many people in the IETF Multiparty Multimedia Session Control
(MMUSIC) working group have made comments and suggestions
contributing to this document. In particular, we would like to thank
Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross
Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna,
Jonathan Lennox, Keith Drage, Sean Olson, Bernie Hoenelsen and
Jonathan Rosenberg.
12. References
12.1 Normative References
[1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[3] 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 [4] 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 [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998. 2279, January 1998.
[4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource [6] Handley, M. and V. Jacobson, "SDP: Session Description
Identifiers (URI): Generic Syntax", RFC 2396, August 1998. Protocol", RFC 2327, April 1998.
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[6] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[9] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal
IPv6 Addresses in URL's", RFC 2732, December 1999. IPv6 Addresses in URL's", RFC 2732, December 1999.
[7] Alvestrand, H., "Tags for the Identification of Languages", BCP [10] Alvestrand, H., "Tags for the Identification of Languages", BCP
47, RFC 3066, January 2001. 47, RFC 3066, January 2001.
9.2 Informative References [11] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing
Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[8] Mills, D., "Network Time Protocol (Version 3) Specification, [12] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 3548, July 2003.
12.2 Informative References
[13] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation", RFC 1305, March 1992. Implementation", RFC 1305, March 1992.
[9] Handley, M., Perkins, C. and E. Whelan, "Session Announcement [14] 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., [15] 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 [16] 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 [17] 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] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", [18] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
RFC 3548, July 2003.
[14] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64, "RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003. RFC 3550, July 2003.
[15] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video [19] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003. Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[16] Casner, S., "Session Description Protocol (SDP) Bandwidth [20] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556,
July 2003. July 2003.
[17] Huitema, C., "Real Time Control Protocol (RTCP) attribute in [21] Huitema, C., "Real Time Control Protocol (RTCP) attribute in
Session Description Protocol (SDP)", RFC 3605, October 2003. Session Description Protocol (SDP)", RFC 3605, October 2003.
[18] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K. [22] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004. 3711, March 2004.
[19] International Telecommunications Union, "H.323 extended for [23] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Indicating User
Agent Capabilities in the Session Initiation Protocol (SIP)",
RFC 3840, August 2004.
[24] Westerlund, M., "A Transport Independent Bandwidth Modifier for
the Session Description Protocol (SDP)", RFC 3890, September
2004.
[25] International Telecommunications Union, "H.323 extended for
loosely coupled conferences", ITU Recommendation H.332, loosely coupled conferences", ITU Recommendation H.332,
September 1998. September 1998.
[20] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K. [26] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K.
Norrman, "Key Management Extensions for Session Description Norrman, "Key Management Extensions for Session Description
Protocol (SDP) and Real Time Streaming Protocol (RTSP)", Protocol (SDP) and Real Time Streaming Protocol (RTSP)",
draft-ietf-mmusic-kmgmt-ext-11 (work in progress), April 2004. draft-ietf-mmusic-kmgmt-ext-12 (work in progress), November
2004.
[21] Andreasen, F., Baugher, M. and D. Wing, "Session Description [27] Andreasen, F., Baugher, M. and D. Wing, "Session Description
Protocol Security Descriptions for Media Streams", Protocol Security Descriptions for Media Streams",
draft-ietf-mmusic-sdescriptions-07 (work in progress), July draft-ietf-mmusic-sdescriptions-07 (work in progress), July
2004. 2004.
[22] Westerlund, M., "A Transport Independent Bandwidth Modifier for
the Session Description Protocol (SDP)",
draft-ietf-mmusic-sdp-bwparam-06 (work in progress), April
2004.
Authors' Addresses Authors' Addresses
Mark Handley Mark Handley
University College London University College London
Department of Computer Science Department of Computer Science
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. 87 change blocks. 
122 lines changed or deleted 204 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/