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]). | |||
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> <transport> <fmt list> | |||
skipping to change at page 22, line 50 ¶ | skipping to change at page 22, line 45 ¶ | |||
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. 37 change blocks. | ||||
100 lines changed or deleted | 55 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |