draft-ietf-mmusic-sdp-new-19.txt   draft-ietf-mmusic-sdp-new-20.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: February 9, 2005 C. Perkins Expires: March 20, 2005 C. Perkins
University of Glasgow University of Glasgow
August 11, 2004 September 19, 2004
SDP: Session Description Protocol SDP: Session Description Protocol
draft-ietf-mmusic-sdp-new-19.txt draft-ietf-mmusic-sdp-new-20.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of section 3 of RFC 3667. By submitting this Internet-Draft, each
and any of which I become aware will be disclosed, in accordance with 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 become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference 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 February 9, 2005. This Internet-Draft will expire on March 20, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. 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
skipping to change at page 2, line 37 skipping to change at page 2, line 37
5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . 12 5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . 12
5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . 13 5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . 13
5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 15 5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 15
5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 16 5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 16
5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . 17 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=") . . . . . . . . . . . . . . . . . 19
5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . 20 5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . 20
5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . . 21 5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . . 21
6. Suggested Attributes . . . . . . . . . . . . . . . . . . . . 23 6. Suggested Attributes . . . . . . . . . . . . . . . . . . . . 23
7. Communicating Conference Control Policy . . . . . . . . . . 30 7. Security Considerations . . . . . . . . . . . . . . . . . . 30
8. Security Considerations . . . . . . . . . . . . . . . . . . 31 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32 8.1 The "application/sdp" media type . . . . . . . . . . . . . 31
9.1 The "application/sdp" media type . . . . . . . . . . . . . 32 8.2 Registration of Parameters . . . . . . . . . . . . . . . . 32
9.2 Registration of Parameters . . . . . . . . . . . . . . . . 33 8.3 Encryption Key Access Methods . . . . . . . . . . . . . . 36
9.3 Encryption Key Access Methods . . . . . . . . . . . . . . 37 A. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 37
A. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 38 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 42
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 43 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 42
10.1 Normative References . . . . . . . . . . . . . . . . . . . 43 9.2 Informative References . . . . . . . . . . . . . . . . . . . 42
10.2 Informative References . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 45 Intellectual Property and Copyright Statements . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . 46
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
skipping to change at page 7, line 40 skipping to change at page 7, line 40
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 [3] 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. Internationalization 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 9). "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 normalization. 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
skipping to change at page 11, line 23 skipping to change at page 11, line 23
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 [8].
<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 9). MAY be registered in future (see Section 8).
<addrtype> is a text string giving the type of the address that <addrtype> is a text string giving the type of the address that
follows. Initially "IP4" and "IP6" are defined, but other values follows. Initially "IP4" and "IP6" are defined, but other values
MAY be registered in future (see Section 9). MAY be registered in future (see Section 8).
<unicast-address> is the address of the machine from which the <unicast-address> is the address of the machine from which the
session was created. For an address type of IP4, this is either session was created. For an address type of IP4, this is either
the fully-qualified domain name of the machine, or the the fully-qualified domain name of the machine, or the
dotted-decimal representation of the IP version 4 address of the dotted-decimal representation of the IP version 4 address of the
machine. For an address type of IP6, this is either the machine. For an address type of IP6, this is either the
fully-qualified domain name of the machine, or the compressed fully-qualified domain name of the machine, or the compressed
textual representation of the IP version 6 address of the machine. textual representation of the IP version 6 address of the machine.
For both IP4 and IP6, the fully-qualified domain name is the form For both IP4 and IP6, the fully-qualified domain name is the form
that SHOULD be given unless this is unavailable, in which case the that SHOULD be given unless this is unavailable, in which case the
skipping to change at page 13, line 49 skipping to change at page 13, line 49
A session description MUST contain either at least one "c=" field in A session description MUST contain either at least one "c=" field in
each media description or a single "c=" field at the session level. each media description or a single "c=" field at the session level.
It MAY contain a single session-level "c=" field and additional "c=" It MAY contain a single session-level "c=" field and additional "c="
field(s) per media description, in which case the per-media values field(s) per media description, in which case the per-media values
override the session-level settings for the respective media. override the session-level settings for the respective media.
The first sub-field ("<nettype>") is the network type, which is a The first sub-field ("<nettype>") is the network type, which is a
text string giving the type of network. Initially "IN" is defined to text string giving the type of network. Initially "IN" is defined to
have the meaning "Internet", but other values MAY be registered in have the meaning "Internet", but other values MAY be registered in
the future (see Section 9). the future (see Section 8).
The second sub-field ("<addrtype>") is the address type. This allows The second sub-field ("<addrtype>") is the address type. This allows
SDP to be used for sessions that are not IP based. Currently only SDP to be used for sessions that are not IP based. Currently only
IP4 and IP6 are defined, but other values MAY be registered in the IP4 and IP6 are defined, but other values MAY be registered in the
future (see Section 9). future (see Section 8).
The third sub-field ("<connection-address>") is the connection The third sub-field ("<connection-address>") is the connection
address. OPTIONAL sub-fields MAY be added after the connection address. OPTIONAL sub-fields MAY be added after the connection
address depending on the value of the <addrtype> field. address depending on the value of the <addrtype> field.
When the <addrtype> is IP4 and IP6, the connection address is defined When the <addrtype> is IP4 and IP6, the connection address is defined
as follows: as follows:
o If the session is multicast, the connection address will be an IP o If the session is multicast, the connection address will be an IP
multicast group address. If the session is not multicast, then multicast group address. If the session is not multicast, then
skipping to change at page 15, line 46 skipping to change at page 15, line 46
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 9 and [22], [16]): Section 8 and [22], [16]):
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 primary purpose of this is to give an to the bandwidth used. The primary purpose of this is to give an
approximate idea as to whether two or more sessions can co-exist approximate idea as to whether two or more sessions can co-exist
simultaneously. When using the CT modifier with RTP, if several simultaneously. When using the CT modifier with RTP, if several
RTP sessions are part of the conference, the conference total RTP sessions are part of the conference, the conference total
refers to total bandwidth of all RTP sessions. refers to total bandwidth of all RTP sessions.
skipping to change at page 21, line 31 skipping to change at page 21, line 31
Attribute values are octet strings, and MAY use any octet value Attribute values are octet strings, and MAY use any octet value
except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute
values are to be interpreted as in ISO-10646 character set with UTF-8 values are to be interpreted as in ISO-10646 character set with UTF-8
encoding. Unlike other text fields, attribute values are NOT encoding. Unlike other text fields, attribute values are NOT
normally affected by the "charset" attribute as this would make normally affected by the "charset" attribute as this would make
comparisons against known values problematic. However, when an comparisons against known values problematic. However, when an
attribute is defined, it can be defined to be charset-dependent, in attribute is defined, it can be defined to be charset-dependent, in
which case it's value should be interpreted in the session charset which case it's value should be interpreted in the session charset
rather than in ISO-10646. rather than in ISO-10646.
Attributes MUST be registered with IANA (see Section 9). If an Attributes MUST be registered with IANA (see Section 8). If an
attribute is received that is not understood, it MUST be ignored by attribute is received that is not understood, it MUST be ignored by
the receiver. the receiver.
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", "application", "data" and "control", although "video", "text" and "application", although this list may be
this list may be extended in future (see Section 9). The extended in future (see Section 8).
difference between "application" and "data" is that the former is
a media flow such as whiteboard information, and the latter is
bulk-data transfer such as multicasting of program executables
which will not typically be displayed to the user. "control" is
used to specify an additional conference control channel for the
session.
<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 [14]) 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 [17]).
skipping to change at page 22, line 50 skipping to change at page 22, line 44
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.
<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 9): 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 [14] used under the RTP Profile for Audio
and Video Conferences with Minimal Control [15] running over and Video Conferences with Minimal Control [15] running over
UDP. UDP.
* RTP/SAVP: denotes the Secure Real-time Transport Protocol [18] * RTP/SAVP: denotes the Secure Real-time Transport Protocol [18]
running over UDP. running over UDP.
skipping to change at page 23, line 43 skipping to change at page 23, line 39
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",
"text" and "video" top-level MIME types. The media type "text" and "video" top-level MIME types. The media type
registration SHOULD define the packetization format for use with registration SHOULD define the packetization format for use with
UDP transport. 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 9.2.2). section 8.2.2).
6. Suggested Attributes 6. Suggested 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.
Registration procedures for new attributes are defined in Section Registration procedures for new attributes are defined in Section
9.2.4. 8.2.4.
a=cat:<category> a=cat:<category>
This attribute gives the dot-separated hierarchical category This attribute gives the dot-separated hierarchical category
of the session. This is to enable a receiver to filter of the session. This is to enable a receiver to filter
unwanted sessions by category. It is a session-level unwanted sessions by category. It is a session-level
attribute, and is not dependent on charset. attribute, and is not dependent on charset.
a=keywds:<keywords> a=keywds:<keywords>
skipping to change at page 30, line 12 skipping to change at page 30, line 9
particular format to be conveyed in a way that SDP doesn't particular format to be conveyed in a way that SDP doesn't
have to understand them. The format must be one of the have to understand them. The format must be one of the
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. Communicating Conference Control Policy 7. Security Considerations
There is some debate over the way conference control policy should be
communicated. In general, the authors believe that an implicit
declarative style of specifying conference control is desirable where
possible.
A simple declarative style uses a single conference attribute field
before the first media field, possibly supplemented by properties
such as `recvonly' for some of the media tools. This conference
attribute conveys the conference control policy. An example might
be:
a=type:moderated
In some cases, however, it is possible that this may be insufficient
to communicate the details of an unusual conference control policy.
If this is the case, then a conference attribute specifying external
control might be set, and then one or more "media" fields might be
used to specify the conference control tools and configuration data
for those tools. An example is an ITU H.332 session:
...
c=IN IP4 224.5.6.7
a=type:H332
m=audio 49230 RTP/AVP 0
m=video 49232 RTP/AVP 31
m=application 12349 udp wb
m=control 49234 H323 mc
c=IN IP4 134.134.157.81
In this example, a general conference attribute (type:H332) is
specified stating that conference control will be provided by an
external H.332 tool, and a contact addresses for the H.323 session
multipoint controller is given.
In this document, only the declarative style of conference control
declaration is specified. Other forms of conference control should
specify an appropriate type attribute, and should define the
implications this has for control media.
8. Security Considerations
SDP is a session description format that describes multimedia SDP is a session description format that describes multimedia
sessions. A session description SHOULD NOT be trusted unless it has sessions. A session description SHOULD NOT be trusted unless it has
been obtained by an authenticated transport protocol from a trusted been obtained by an authenticated transport protocol from a trusted
source. Many different transport protocols may be used to distribute source. Many different transport protocols may be used to distribute
session description, and the nature of the authentication will differ session description, and the nature of the authentication will differ
from transport to transport. from transport to transport.
One transport that will frequently be used to distribute session One transport that will frequently be used to distribute session
descriptions is the Session Announcement Protocol (SAP). SAP descriptions is the Session Announcement Protocol (SAP). SAP
skipping to change at page 32, line 21 skipping to change at page 31, line 24
administrators will apply their own policies, but the exclusive use administrators will apply their own policies, but the exclusive use
of "local" or "site-local" administrative scope within the firewall of "local" or "site-local" administrative scope within the firewall
and the refusal of the firewall to open a hole for such scopes will and the refusal of the firewall to open a hole for such scopes will
provide separation of global multicast sessions from local ones. provide separation of global multicast sessions from local ones.
Use of the "k=" field poses a significant security risk, since it Use of the "k=" field poses a significant security risk, since it
conveys session encryption keys in the clear. SDP MUST NOT be used conveys session encryption keys in the clear. SDP MUST NOT be used
to convey key material, unless it can be guaranteed that the channel to convey key material, unless it can be guaranteed that the channel
over which the SDP is delivered is both private and authenticated. over which the SDP is delivered is both private and authenticated.
9. IANA Considerations 8. IANA Considerations
9.1 The "application/sdp" media type 8.1 The "application/sdp" media type
One MIME type is to be registered, as defined below. This updates One MIME type is to be registered, as defined below. This updates
the previous definition from RFC 2327. the previous definition from RFC 2327.
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of media type "application/sdp" Subject: Registration of media type "application/sdp"
MIME media type name: application MIME media type name: application
MIME subtype name: sdp MIME subtype name: sdp
skipping to change at page 33, line 22 skipping to change at page 32, line 27
Person & email address to contact for further information: Person & email address to contact for further information:
Colin Perkins <csp@csperkins.org> Colin Perkins <csp@csperkins.org>
IETF MMUSIC working group IETF MMUSIC working group
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: Author/Change controller:
Authors of RFC XXXX Authors of RFC XXXX
IETF MMUSIC working group delegated from the IESG IETF MMUSIC working group delegated from the IESG
9.2 Registration of Parameters 8.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.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 [5].
This memo registers the media types "audio", "video", "text", This memo registers the media types "audio", "video", "text" and
"application", "data" and "control". "application".
9.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 [14] used under the RTP
Profile for Audio and Video Conferences with Minimal Control [15] Profile for Audio and Video Conferences with Minimal Control [15]
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 [18], 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
if it is Standards-Track. Registrations MUST also define the rules if it is Standards-Track. Registrations MUST also define the rules
by which their "fmt" namespace is managed (see below). by which their "fmt" namespace is managed (see below).
9.2.3 Media formats ("fmt") 8.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" and "RTP/SAVP" profiles MUST RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST
use the payload type number as their "fmt" value. If the payload use the payload type number as their "fmt" value. If the payload
type number is dynamically assigned by this session description, an type number is dynamically assigned by this session description, an
additional "rtpmap" attribute MUST be included to specify the format additional "rtpmap" attribute MUST be included to specify the format
skipping to change at page 34, line 46 skipping to change at page 34, line 5
through the IETF process (RFC 2048) by production of, or reference through the IETF process (RFC 2048) by production of, or reference
to, a standards-track RFC that defines the transport protocol for the to, a standards-track RFC that defines the transport protocol for the
format. format.
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.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 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 36, line 26 skipping to change at page 35, line 26
inactive | Either | No inactive | Either | No
orient | Media | No orient | Media | No
type | Session | No type | Session | No
charset | Session | No charset | Session | No
sdplang | Either | No sdplang | Either | No
lang | Either | No lang | Either | No
framerate | Media | No framerate | Media | No
quality | Media | No quality | Media | No
fmtp | Media | No fmtp | Media | No
9.2.5 Bandwidth specifiers ("bwtype") 8.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.
IANA is requested to register the bandwith specifiers "CT" and "AS" IANA is requested to register the bandwith specifiers "CT" and "AS"
with definitions as in Section 5.8 of this memo (these definitions with definitions as in Section 5.8 of this memo (these definitions
update those in RFC 2327). update those in RFC 2327).
9.2.6 Network types ("nettype") 8.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. type and specifies how and when they would be used.
IANA is requested to register the network type "IN" to represent the IANA is requested to register the network type "IN" to represent the
Internet, with definition as in Sections 5.2 and 5.7 of this memo Internet, with definition as in Sections 5.2 and 5.7 of this memo
(these definitions update those in RFC 2327). (these definitions update those in RFC 2327).
9.2.7 Address types ("addrtype") 8.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. Address types are not expected to be syntax of the address type. Address types are not expected to be
registered frequently. registered frequently.
IANA is requested to register the address types "IP4" and "IP6" with IANA is requested to register the address types "IP4" and "IP6" with
definitions as in Sections 5.2 and 5.7 of this memo (these definitions as in Sections 5.2 and 5.7 of this memo (these
definitions update those in RFC 2327). definitions update those in RFC 2327).
9.2.8 Registration Procedure 8.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 37, line 49 skipping to change at page 36, line 49
o a one paragraph explanation of the purpose of the registered name. o a one paragraph explanation of the purpose of the registered name.
o a reference to the specification for the registered name (this o a reference to the specification for the registered name (this
will typically be an RFC number). will typically be an RFC number).
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.
9.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 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 [2]. defined in [2].
skipping to change at page 41, line 16 skipping to change at page 40, line 16
; sub-rules of 'a=' ; sub-rules of 'a='
attribute = (att-field ":" att-value) / att-field attribute = (att-field ":" att-value) / att-field
att-field = token att-field = token
att-value = byte-string att-value = byte-string
; sub-rules of 'm=' ; sub-rules of 'm='
media = token media = token
;typically "audio", "video", "text", ;typically "audio", "video", "text" or
;"application" or "data" ;"application"
fmt = token fmt = token
;typically an RTP payload type for audio ;typically an RTP payload type for audio
;and video media ;and video media
proto = token *("/" token) proto = token *("/" token)
;typically "RTP/AVP" or "udp" ;typically "RTP/AVP" or "udp"
port = 1*DIGIT port = 1*DIGIT
;should be either "0" or in the range "1024" ;should be either "0" or in the range "1024"
skipping to change at page 43, line 23 skipping to change at page 42, line 23
; addr-spec: from RFC 2822 ; addr-spec: from RFC 2822
Appendix B. Acknowledgments Appendix B. 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, Jonathan Lennox and Keith Drage. Steve Hanna, Jonathan Lennox and Keith Drage.
10. References 9. References
10.1 Normative References 9.1 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.
skipping to change at page 43, line 48 skipping to change at page 42, line 48
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [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.
[6] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal [6] 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 [7] Alvestrand, H., "Tags for the Identification of Languages", BCP
47, RFC 3066, January 2001. 47, RFC 3066, January 2001.
10.2 Informative References 9.2 Informative References
[8] Mills, D., "Network Time Protocol (Version 3) Specification, [8] 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 [9] 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., [10] 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.
 End of changes. 36 change blocks. 
100 lines changed or deleted 54 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/