draft-ietf-mmusic-sdp-new-01.txt | draft-ietf-mmusic-sdp-new-02.txt | |||
---|---|---|---|---|
Internet Engineering Task Force MMUSIC WG | Internet Engineering Task Force MMUSIC WG | |||
INTERNET-DRAFT Mark Handley/ACIRI | INTERNET-DRAFT Mark Handley/ACIRI | |||
draft-ietf-mmusic-sdp-new-01.txt Van Jacobson/Packet Design | draft-ietf-mmusic-sdp-new-02.txt Van Jacobson/Packet Design | |||
Colin Perkins/ISI | Colin Perkins/ISI | |||
2 March 2001 | 30 April 2001 | |||
Expires: September 2001 | Expires: October 2001 | |||
SDP: Session Description Protocol | SDP: Session Description Protocol | |||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft and is in full conformance with all | This document is an Internet-Draft and is in full conformance with all | |||
provisions of Section 10 of RFC2026. | provisions of Section 10 of RFC2026. | |||
Internet-Drafts are working documents of the Internet Engineering Task | Internet-Drafts are working documents of the Internet Engineering Task | |||
Force (IETF), its areas, and its working groups. Note that other groups | Force (IETF), its areas, and its working groups. Note that other groups | |||
skipping to change at page 1, line 32 ¶ | skipping to change at page 1, line 32 ¶ | |||
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 material | time. It is inappropriate to use Internet- Drafts as reference material | |||
or to cite them other than as "work in progress." | 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. | |||
Abstract | ||||
This document defines the Session Description Protocol, SDP. | ||||
SDP is intended for describing multimedia sessions for the | ||||
purposes of session announcement, session invitation, and | ||||
other forms of multimedia session initiation. | ||||
This document is a product of the Multiparty Multimedia Session Control | This document is a product of the Multiparty Multimedia Session Control | |||
(MMUSIC) working group of the Internet Engineering Task Force. Comments | (MMUSIC) working group of the Internet Engineering Task Force. Comments | |||
are solicited and should be addressed to the working group's mailing | are solicited and should be addressed to the working group's mailing | |||
list at confctrl@isi.edu and/or the authors. | list at confctrl@isi.edu and/or the authors. | |||
1. Introduction | Abstract | |||
Note: This draft is essentially identical to RFC 2327. It is made | This memo defines the Session Description Protocol (SDP). SDP | |||
available to stimulate discussion of corrections and clarifications | is intended for describing multimedia sessions for the | |||
which need to be made in order to advance SDP to a draft standard RFC. | purposes of session announcement, session invitation, and | |||
other forms of multimedia session initiation. | ||||
1. Introduction | ||||
On the Internet multicast backbone (Mbone), a session directory tool is | On the Internet multicast backbone (Mbone), a session directory tool is | |||
used to advertise multimedia conferences and communicate the conference | used to advertise multimedia conferences and communicate the conference | |||
addresses and conference tool-specific information necessary for | addresses and conference tool-specific information necessary for | |||
participation. This document defines a session description protocol for | participation. This document defines a session description protocol for | |||
this purpose, and for general real-time multimedia session description | this purpose, and for general real-time multimedia session description | |||
purposes. This draft does not describe multicast address allocation or | purposes. This draft does not describe multicast address allocation or | |||
the distribution of SDP messages in detail. These are described in | the distribution of SDP messages. These are described in accompanying | |||
accompanying drafts. SDP is not intended for negotiation of media | drafts. SDP is not intended for negotiation of media encodings. | |||
encodings. | ||||
2. Background | 2. Background | |||
The Mbone is the part of the internet that supports IP multicast, and | The Mbone is the part of the internet that supports IP multicast, and | |||
thus permits efficient many-to-many communication. It is used | thus permits efficient many-to-many communication. It is used | |||
extensively for multimedia conferencing. Such conferences usually have | extensively for multimedia conferencing. Such conferences usually have | |||
the property that tight coordination of conference membership is not | the property that tight coordination of conference membership is not | |||
necessary; to receive a conference, a user at an Mbone site only has to | necessary; to receive a conference, a user at an Mbone site only has to | |||
know the conference's multicast group address and the UDP ports for the | know the conference's multicast group address and the UDP ports for the | |||
conference data streams. | conference data streams. | |||
skipping to change at page 3, line 33 ¶ | skipping to change at page 3, line 24 ¶ | |||
A session announcement is a mechanism by which a session description | A session announcement is a mechanism by which a session description | |||
is conveyed to users in a pro-active fashion, i.e., the session | is conveyed to users in a pro-active fashion, i.e., the session | |||
description was not explicitly requested by the user. | description was not explicitly requested by the user. | |||
Session Description | Session Description | |||
A well defined format for conveying sufficient information to | A well defined format for conveying sufficient information to | |||
discover and participate in a multimedia session. | discover and participate in a multimedia session. | |||
3.1. Terminology | 3.1. Terminology | |||
This document uses the same words as RFC 1123 for defining the | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
significance of each particular requirement. These words are: | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in RFC 2119 [13]. | ||||
must: | ||||
This word or the adjective ``required'' means that the item is an | ||||
absolute requirement of the specification. | ||||
should: | ||||
This word or the adjective ``recommended'' means that there may | ||||
exist valid reasons in particular circumstances to ignore this | ||||
item, but the full implications should be understood and the case | ||||
carefully weighed before choosing a different course. | ||||
may: | ||||
This word or the adjective ``optional'' means that this item is | ||||
truly optional. One implementation may choose to include the item | ||||
because a particular application requires it or because it enhances | ||||
the product, for example, another implementation may omit the same | ||||
item. | ||||
An implementation is not compliant if it fails to satisfy one or more of | 4. Examples of SDP Usage | |||
the must requirements for the protocols it implements. An | ||||
implementation that satisfies all the must and all the should | ||||
requirements for the protocols it implements is said to be | ||||
``unconditionally compliant''; one that satisfies all the must | ||||
requirements but not all of the should requirements for the protocols it | ||||
implements is said to be ``conditionally compliant''. | ||||
4. SDP Usage | 4.1. Session Initiation | |||
4.1. Multicast Announcements | The Session Initiation Protocol, SIP [11] is an application-layer | |||
control protocol for creating, modifying and terminating sessions such | ||||
as Internet multimedia conferences, Internet telephone calls and | ||||
multimedia distribution. The SIP messages used to create sessions carry | ||||
session descriptions which allow participants to agree on a set of | ||||
compatible media types. These session descriptions are commonly | ||||
formatted using SDP. | ||||
SDP is a session description protocol for multimedia sessions. A common | 4.2. Streaming media | |||
mode of usage is for a client to announce a conference session by | ||||
periodically multicasting an announcement packet to a well known | ||||
multicast address and port using the Session Announcement Protocol | ||||
(SAP). | ||||
SAP packets are UDP packets with the following format: | The Real Time Streaming Protocol, RTSP [12], is an application-level | |||
protocol for control over the delivery of data with real-time | ||||
properties. RTSP provides an extensible framework to enable controlled, | ||||
on-demand delivery of real-time data, such as audio and video. It is | ||||
necessary for RTSP to convey a description of the session to be | ||||
controlled: SDP is often used for this purpose. | ||||
0 31 | 4.3. Multicast Announcement | |||
|--------------------| | ||||
| SAP header | | ||||
|--------------------| | ||||
| text payload | | ||||
|/\/\/\/\/\/\/\/\/\/\| | ||||
The header is the Session Announcement Protocol header. SAP is | In order to assist the advertisement of multicast multimedia conferences | |||
described in more detail in a companion draft [4] | and other multicast sessions, and to communicate the relevant session | |||
setup information to prospective participants, a distributed session | ||||
directory may be used. An instance of such a session directory | ||||
periodically sends packets containing a description of the session to a | ||||
well known multicast group. These advertisements are received by other | ||||
session directories such that potential remote participants can use the | ||||
session description to start the tools required to participate in the | ||||
session. | ||||
The text payload is an SDP session description, as described in this | One protocol commonly used to implement such a distributed directory is | |||
draft. The text payload should be no greater than 1 Kbyte in length. | the Session Announcement Protocol, SAP [4]. SDP provides the recommended | |||
If announced by SAP, only one session announcement is permitted in a | session description format for such announcements. | |||
single packet. | ||||
4.2. Email and WWW Announcements | 4.4. Email and the World Wide Web | |||
Alternative means of conveying session descriptions include electronic | Alternative means of conveying session descriptions include electronic | |||
mail and the World Wide Web. For both email and WWW distribution, the | mail and the World Wide Web. For both email and WWW distribution, the | |||
use of the MIME content type ``application/sdp'' should be used. This | use of the MIME content type ``application/sdp'' MUST be used. This | |||
enables the automatic launching of applications for participation in the | enables the automatic launching of applications for participation in the | |||
session from the WWW client or mail reader in a standard manner. | session from the WWW client or mail reader in a standard manner. | |||
Note that announcements of multicast sessions made only via email or the | Note that announcements of multicast sessions made only via email or the | |||
World Wide Web (WWW) do not have the property that the receiver of a | World Wide Web (WWW) do not have the property that the receiver of a | |||
session announcement can necessarily receive the session because the | session announcement can necessarily receive the session because the | |||
multicast sessions may be restricted in scope, and access to the WWW | multicast sessions may be restricted in scope, and access to the WWW | |||
server or reception of email is possible outside this scope. SAP | server or reception of email is possible outside this scope. SAP | |||
announcements do not suffer from this mismatch. | announcements do not suffer from this mismatch. | |||
skipping to change at page 7, line 4 ¶ | skipping to change at page 6, line 27 ¶ | |||
establish a control channel for the actual media flow. | establish a control channel for the actual media flow. | |||
5.2. Timing Information | 5.2. Timing Information | |||
Sessions may either be bounded or unbounded in time. Whether or not | Sessions may either be bounded or unbounded in time. Whether or not | |||
they are bounded, they may be only active at specific times. | they are bounded, they may be only active at specific times. | |||
SDP can convey: | SDP can convey: | |||
o An arbitrary list of start and stop times bounding the session | o An arbitrary list of start and stop times bounding the session | |||
o For each bound, repeat times such as "every Wednesday at 10am for | o For each bound, repeat times such as "every Wednesday at 10am for | |||
one hour" | one hour" | |||
This timing information is globally consistent, irrespective of local | This timing information is globally consistent, irrespective of local | |||
time zone or daylight saving time. | time zone or daylight saving time. | |||
5.3. Private Sessions | 5.3. Private Sessions | |||
It is possible to create both public sessions and private sessions. | It is possible to create both public sessions and private sessions. SDP | |||
Private sessions will typically be conveyed by encrypting the session | itself does not distinguish between these: private sessions are | |||
description to distribute it. The details of how encryption is | typically conveyed by encrypting the session description during | |||
performed are dependent on the mechanism used to convey SDP - see [4] | distribution. The details of how encryption is performed are dependent | |||
for how this is done for session announcements. | on the mechanism used to convey SDP - e.g. mechanisms are defined for | |||
SDP transported using SAP [4] and SIP [11]. | ||||
If a session announcement is private it is possible to use that private | If a session announcement is private it is possible to use that private | |||
announcement to convey encryption keys necessary to decode each of the | announcement to convey encryption keys necessary to decode each of the | |||
media in a conference, including enough information to know which | media in a conference, including enough information to know which | |||
encryption scheme is used for each media. | encryption scheme is used for each media. | |||
5.4. Obtaining Further Information about a Session | 5.4. Obtaining Further Information about a Session | |||
A session description should convey enough information to decide whether | A session description should convey enough information to decide whether | |||
or not to participate in a session. SDP may include additional pointers | or not to participate in a session. SDP may include additional pointers | |||
in the form of Universal Resources Identifiers (URIs) for more | in the form of Universal Resources Identifiers (URIs) for more | |||
information about the session. | information about the session. | |||
5.5. Categorisation | 5.5. Categorisation | |||
When many session descriptions are being distributed by SAP or any other | When many session descriptions are being distributed by SAP, or any | |||
advertisement mechanism, it may be desirable to filter announcements | other advertisement mechanism, it may be desirable to filter | |||
that are of interest from those that are not. SDP supports a | announcements that are of interest from those that are not. SDP | |||
categorisation mechanism for sessions that is capable of being | supports a categorisation mechanism for sessions that is capable of | |||
automated. | being automated. | |||
5.6. Internationalization | 5.6. Internationalization | |||
The SDP specification recommends the use of the ISO 10646 character sets | The SDP specification recommends the use of the ISO 10646 character sets | |||
in the UTF-8 encoding (RFC 2044) to allow many different languages to be | in the UTF-8 encoding (RFC 2044) to allow many different languages to be | |||
represented. However, to assist in compact representations, SDP also | represented. However, to assist in compact representations, SDP also | |||
allows other character sets such as ISO 8859-1 to be used when desired. | allows other character sets such as ISO 8859-1 to be used when desired. | |||
Internationalization only applies to free-text fields (session name and | Internationalization only applies to free-text fields (session name and | |||
background information), and not to SDP as a whole. | background information), and not to SDP as a whole. | |||
6. SDP Specification | 6. SDP Specification | |||
SDP session descriptions are entirely textual using the ISO 10646 | SDP session descriptions are entirely textual using the ISO 10646 | |||
character set in UTF-8 encoding. SDP field names and attributes names | character set in UTF-8 encoding. SDP field names and attributes names | |||
use only the US-ASCII subset of UTF-8, but textual fields and attribute | use only the US-ASCII subset of UTF-8, but textual fields and attribute | |||
values may use the full ISO 10646 character set. The textual form, as | values may use the full ISO 10646 character set. The textual form, as | |||
opposed to a binary encoding such as ASN/1 or XDR, was chosen to enhance | opposed to a binary encoding such as ASN/1 or XDR, was chosen to enhance | |||
portability, to enable a variety of transports to be used (e.g, session | portability, to enable a variety of transports to be used (e.g, session | |||
description in a MIME email message) and to allow flexible, text-based | description in a MIME email message) and to allow flexible, text-based | |||
toolkits (e.g., Tcl/Tk ) to be used to generate and to process session | toolkits (e.g., Tcl/Tk ) to be used to generate and to process session | |||
descriptions. However, since the total bandwidth allocated to all SAP | descriptions. However, since SDP may be used in environments where the | |||
announcements is strictly limited, the encoding is deliberately compact. | maximum permissable size of a session description is limited (e.g. SAP | |||
Also, since announcements may be transported via very unreliable means | announcements; SIP transported in UDP), the encoding is deliberately | |||
(e.g., email) or damaged by an intermediate caching server, the encoding | compact. Also, since announcements may be transported via very | |||
was designed with strict order and formatting rules so that most errors | unreliable means (e.g., email) or damaged by an intermediate caching | |||
would result in malformed announcements which could be detected easily | server, the encoding was designed with strict order and formatting rules | |||
and discarded. This also allows rapid discarding of encrypted | so that most errors would result in malformed announcements which could | |||
announcements for which a receiver does not have the correct key. | be detected easily and discarded. This also allows rapid discarding of | |||
encrypted announcements for which a receiver does not have the correct | ||||
key. | ||||
An SDP session description consists of a number of lines of text of the | An SDP session description consists of a number of lines of text of the | |||
form | form | |||
<type>=<value> | <type>=<value> | |||
<type> is always exactly one character and is case-significant. <value> | <type> is always exactly one character and is case-significant. <value> | |||
is a structured text string whose format depends on <type>. It also | is a structured text string whose format depends on <type>. It also | |||
will be case-significant unless a specific field defines otherwise. | will be case-significant unless a specific field defines otherwise. | |||
Whitespace is not permitted either side of the `=' sign. In general | Whitespace MUST NOT be used either side of the `=' sign. In general | |||
<value> is either a number of fields delimited by a single space | <value> is either a number of fields delimited by a single space | |||
character or a free format string. | character or a free format string. | |||
A session description consists of a session-level description (details | A session description consists of a session-level description (details | |||
that apply to the whole session and all media streams) and optionally | that apply to the whole session and all media streams) and optionally | |||
several media-level descriptions (details that apply onto to a single | several media-level descriptions (details that apply onto to a single | |||
media stream). | media stream). | |||
An announcement consists of a session-level section followed by zero or | An announcement consists of a session-level section followed by zero or | |||
more media-level sections. The session-level part starts with a `v=' | more media-level sections. The session-level part starts with a `v=' | |||
line and continues to the first media-level section. The media | line and continues to the first media-level section. The media | |||
description starts with an `m=' line and continues to the next media | description starts with an `m=' line and continues to the next media | |||
description or end of the whole session description. In general, | description or end of the whole session description. In general, | |||
session-level values are the default for all media unless overridden by | session-level values are the default for all media unless overridden by | |||
an equivalent media-level value. | an equivalent media-level value. | |||
When SDP is conveyed by SAP, only one session description is allowed per | Some lines in each description are REQUIRED and some are OPTIONAL but | |||
packet. When SDP is conveyed by other means, many SDP session | all MUST appear in exactly the order given here (the fixed order greatly | |||
descriptions may be concatenated together (the `v=' line indicating the | enhances error detection and allows for a simple parser). OPTIONAL | |||
start of a session description terminates the previous description). | ||||
Some lines in each description are required and some are optional but | ||||
all must appear in exactly the order given here (the fixed order greatly | ||||
enhances error detection and allows for a simple parser). Optional | ||||
items are marked with a `*'. | items are marked with a `*'. | |||
Session description | Session description | |||
v= (protocol version) | v= (protocol version) | |||
o= (owner/creator and session identifier). | o= (owner/creator and session identifier). | |||
s= (session name) | s= (session name) | |||
i=* (session information) | i=* (session information) | |||
u=* (URI of description) | u=* (URI of description) | |||
e=* (email address) | e=* (email address) | |||
p=* (phone number) | p=* (phone number) | |||
skipping to change at page 9, line 36 ¶ | skipping to change at page 9, line 34 ¶ | |||
Media description | Media description | |||
m= (media name and transport address) | m= (media name and transport address) | |||
i=* (media title) | i=* (media title) | |||
c=* (connection information - optional if included at session-level) | c=* (connection information - optional if included at session-level) | |||
b=* (bandwidth information) | b=* (bandwidth information) | |||
k=* (encryption key) | k=* (encryption key) | |||
a=* (zero or more media attribute lines) | a=* (zero or more media attribute lines) | |||
The set of `type' letters is deliberately small and not intended to be | The set of `type' letters is deliberately small and not intended to be | |||
extensible -- SDP parsers must completely ignore any announcement that | extensible -- an SDP parser MUST completely ignore any announcement that | |||
contains a `type' letter that it does not understand. The `attribute' | contains a `type' letter that it does not understand. The `attribute' | |||
mechanism ("a=" described below) is the primary means for extending SDP | mechanism ("a=" described below) is the primary means for extending SDP | |||
and tailoring it to particular applications or media. Some attributes | and tailoring it to particular applications or media. Some attributes | |||
(the ones listed in this document) have a defined meaning but others may | (the ones listed in this document) have a defined meaning but others may | |||
be added on an application-, media- or session-specific basis. A | be added on an application-, media- or session-specific basis. An SDP | |||
session directory must ignore any attribute it doesn't understand. | parser MUST ignore any attribute it doesn't understand. | |||
The connection (`c=') and attribute (`a=') information in the session- | The connection (`c=') and attribute (`a=') information in the session- | |||
level section applies to all the media of that session unless overridden | level section applies to all the media of that session unless overridden | |||
by connection information or an attribute of the same name in the media | by connection information or an attribute of the same name in the media | |||
description. For instance, in the example below, each media behaves as | description. For instance, in the example below, each media behaves as | |||
if it were given a `recvonly' attribute. | if it were given a `recvonly' attribute. | |||
An example SDP description is: | An example SDP description is: | |||
v=0 | v=0 | |||
skipping to change at page 10, line 43 ¶ | skipping to change at page 10, line 43 ¶ | |||
Origin | Origin | |||
o=<username> <session id> <version> <network type> <address type> | o=<username> <session id> <version> <network type> <address type> | |||
<address> | <address> | |||
The ``o='' field gives the originator of the session (their username and | The ``o='' field gives the originator of the session (their username and | |||
the address of the user's host) plus a session id and session version | the address of the user's host) plus a session id and session version | |||
number. <username> is the user's login on the originating host, or it | number. <username> is the user's login on the originating host, or it | |||
is ``-'' if the originating host does not support the concept of user | is ``-'' if the originating host does not support the concept of user | |||
ids. <username> must not contain spaces. <session id> is a numeric | ids. <username> MUST NOT contain spaces. <session id> is a numeric | |||
string such that the tuple of <username>, <session id>, <network type>, | string such that the tuple of <username>, <session id>, <network type>, | |||
<address type> and <address> form a globally unique identifier for the | <address type> and <address> form a globally unique identifier for the | |||
session. The method of session id allocation is up to the creating | session. The method of session id allocation is up to the creating | |||
tool, but it has been suggested that a Network Time Protocol (NTP) | tool, but it has been suggested that a Network Time Protocol (NTP) | |||
timestamp be used to ensure uniqueness [1]. <version> is a version | timestamp be used to ensure uniqueness [1]. <version> is a version | |||
number for this announcement. It is needed for proxy announcements to | number for this announcement. It is needed for proxy announcements to | |||
detect which of several announcements for the same session is the most | detect which of several announcements for the same session is the most | |||
recent. Again its usage is up to the creating tool, so long as | recent. Again its usage is up to the creating tool, so long as | |||
<version> is increased when a modification is made to the session data. | <version> is increased when a modification is made to the session data. | |||
Again, it is recommended (but not mandatory) that an NTP timestamp is | Again, it is RECOMMENDED (but not mandatory) that an NTP timestamp is | |||
used. <network type> is a text string giving the type of network. | used. <network type> is a text string giving the type of network. | |||
Initially ``IN'' is defined to have the meaning ``Internet''. <address | Initially ``IN'' is defined to have the meaning ``Internet''. <address | |||
type> is a text string giving the type of the address that follows. | type> is a text string giving the type of the address that follows. | |||
Initially ``IP4'' and ``IP6'' are defined. <address> is the globally | Initially ``IP4'' and ``IP6'' are defined. <address> is the globally | |||
unique address of the machine from which the session was created. For | unique address of the machine from which the session was created. For | |||
an address type of IP4, this is either the fully-qualified domain name | an address type of IP4, this is either the fully-qualified domain name | |||
of the machine, or the dotted-decimal representation of the IP version 4 | of the machine, or the dotted-decimal representation of the IP version 4 | |||
address of the machine. For an address type of IP6, this is either the | address of the machine. For an address type of IP6, this is either the | |||
fully-qualified domain name of the machine, or the compressed textual | fully-qualified domain name of the machine, or the compressed textual | |||
representation of the IP version 6 address of the machine. For both IP4 | representation of the IP version 6 address of the machine. For both IP4 | |||
skipping to change at page 11, line 32 ¶ | skipping to change at page 11, line 32 ¶ | |||
In general, the ``o='' field serves as a globally unique identifier for | In general, the ``o='' field serves as a globally unique identifier for | |||
this version of this session description, and the subfields excepting | this version of this session description, and the subfields excepting | |||
the version taken together identify the session irrespective of any | the version taken together identify the session irrespective of any | |||
modifications. | modifications. | |||
Session Name | Session Name | |||
s=<session name> | s=<session name> | |||
The ``s='' field is the session name. There must be one and only one | The ``s='' field is the session name. There MUST be one and only one | |||
``s='' field per session description, and it must contain ISO 10646 | ``s='' field per session description, and it SHOULD contain ISO 10646 | |||
characters (but see also the `charset' attribute below). | characters (but see also the `charset' attribute below). | |||
Session and Media Information | Session and Media Information | |||
i=<session description> | i=<session description> | |||
The ``i='' field is information about the session. There may be at most | The ``i='' field is information about the session. There may be at most | |||
one session-level ``i='' field per session description, and at most one | one session-level ``i='' field per session description, and at most one | |||
``i='' field per media. Although it may be omitted, this is discouraged | ``i='' field per media. Although it may be omitted, this is NOT | |||
for session announcements, and user interfaces for composing sessions | RECOMMENDED for session announcements, and user interfaces for composing | |||
should require text to be entered. If it is present it must contain ISO | sessions should require text to be entered. If it is present it must | |||
10646 characters (but see also the `charset' attribute below). | contain ISO 10646 characters (but see also the `charset' attribute | |||
below). | ||||
A single ``i='' field can also be used for each media definition. In | A single ``i='' field can also be used for each media definition. In | |||
media definitions, ``i='' fields are primarily intended for labeling | media definitions, ``i='' fields are primarily intended for labeling | |||
media streams. As such, they are most likely to be useful when a single | media streams. As such, they are most likely to be useful when a single | |||
session has more than one distinct media stream of the same media type. | session has more than one distinct media stream of the same media type. | |||
An example would be two different whiteboards, one for slides and one | An example would be two different whiteboards, one for slides and one | |||
for feedback and questions. | for feedback and questions. | |||
URI | URI | |||
u=<URI> | u=<URI> | |||
o A URI is a Universal Resource Identifier as used by WWW clients | o A URI is a Universal Resource Identifier as used by WWW clients | |||
o The URI should be a pointer to additional information about the | o The URI should be a pointer to additional information about the | |||
skipping to change at page 12, line 15 ¶ | skipping to change at page 12, line 17 ¶ | |||
URI | URI | |||
u=<URI> | u=<URI> | |||
o A URI is a Universal Resource Identifier as used by WWW clients | o A URI is a Universal Resource Identifier as used by WWW clients | |||
o The URI should be a pointer to additional information about the | o The URI should be a pointer to additional information about the | |||
conference | conference | |||
o This field is optional, but if it is present it should be specified | o This field is OPTIONAL, but if it is present it MUST be specified | |||
before the first media field | before the first media field | |||
o No more than one URI field is allowed per session description | o No more than one URI field is allowed per session description | |||
Email Address and Phone Number | Email Address and Phone Number | |||
e=<email address> | e=<email address> | |||
p=<phone number> | p=<phone number> | |||
o These specify contact information for the person responsible for the | o These specify contact information for the person responsible for the | |||
conference. This is not necessarily the same person that created | conference. This is not necessarily the same person that created | |||
the conference announcement. | the conference announcement. | |||
o Either an email field or a phone field must be specified. | o Either an email field or a phone field MUST be specified. | |||
Additional email and phone fields are allowed. | Additional email and phone fields are allowed. | |||
o If these are present, they should be specified before the first | o If these are present, they should be specified before the first | |||
media field. | media field. | |||
o More than one email or phone field can be given for a session | o More than one email or phone field can be given for a session | |||
description. | description. | |||
o Phone numbers should be given in the conventional international | o Phone numbers should be given in the conventional international | |||
format - preceded by a ``+'' and the international country code. | format - preceded by a ``+'' and the international country code. | |||
skipping to change at page 13, line 24 ¶ | skipping to change at page 13, line 27 ¶ | |||
The free text string should be in the ISO-10646 character set with | The free text string should be in the ISO-10646 character set with | |||
UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if | UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if | |||
the appropriate charset session-level attribute is set. | the appropriate charset session-level attribute is set. | |||
Connection Data | Connection Data | |||
c=<network type> <address type> <connection address> | c=<network type> <address type> <connection address> | |||
The ``c='' field contains connection data. | The ``c='' field contains connection data. | |||
A session announcement must contain one ``c='' field in each media | A session announcement MUST contain one ``c='' field in each media | |||
description (see below) or a ``c='' field at the session-level. It may | description (see below) or a ``c='' field at the session-level. It MAY | |||
contain a session-level ``c='' field and one additional ``c='' field per | contain a session-level ``c='' field and one additional ``c='' field per | |||
media description, in which case the per-media values override the | media description, in which case the per-media values override the | |||
session-level settings for the relevant media. | session-level settings for the relevant media. | |||
The first sub-field is the network type, which is a text string giving | The first sub-field is the network type, which is a text string giving | |||
the type of network. Initially ``IN'' is defined to have the meaning | the type of network. Initially ``IN'' is defined to have the meaning | |||
``Internet''. | ``Internet''. | |||
The second sub-field is the address type. This allows SDP to be used | The second sub-field is the address type. This allows SDP to be used | |||
for sessions that are not IP based. Currently only IP4 is defined. | for sessions that are not IP based. Currently only IP4 is defined. | |||
The third sub-field is the connection address. Optional extra sub- | The third sub-field is the connection address. Optional extra sub- | |||
fields may be added after the connection address depending on the value | fields may be added after the connection address depending on the value | |||
of the <address type> field. | of the <address type> field. | |||
For IP4 addresses, the connection address is defined as follows: | For IP4 addresses, the connection address is defined as follows: | |||
o Typically the connection address will be a class-D IP multicast | o If the session is multicast, the connection address will be an IP | |||
group address. If the conference is not multicast, then the | multicast group address. If the conference is not multicast, then | |||
connection address contains the unicast IP address of the expected | the connection address contains the unicast IP address of the | |||
data source or data relay or data sink as determined by additional | expected data source or data relay or data sink as determined by | |||
attribute fields. It is not expected that unicast addresses will be | additional attribute fields. It is not expected that unicast | |||
given in a session description that is communicated by a multicast | addresses will be given in a session description that is | |||
announcement, though this is not prohibited. | communicated by a multicast announcement, though this is not | |||
prohibited. | ||||
o Conferences using an IP multicast connection address must also have | o Conferences using an IP multicast connection address MUST also have | |||
a time to live (TTL) value present in addition to the multicast | a time to live (TTL) value present in addition to the multicast | |||
address. The TTL and the address together define the scope with | address. The TTL and the address together define the scope with | |||
which multicast packets sent in this conference will be sent. TTL | which multicast packets sent in this conference will be sent. TTL | |||
values must be in the range 0-255. | values MUST be in the range 0-255. | |||
The TTL for the session is appended to the address using a slash as | The TTL for the session is appended to the address using a slash as | |||
a separator. An example is: | a separator. An example is: | |||
c=IN IP4 224.2.1.1/127 | c=IN IP4 224.2.1.1/127 | |||
Hierarchical or layered encoding schemes are data streams where the | Hierarchical or layered encoding schemes are data streams where the | |||
encoding from a single media source is split into a number of | encoding from a single media source is split into a number of | |||
layers. The receiver can choose the desired quality (and hence | layers. The receiver can choose the desired quality (and hence | |||
bandwidth) by only subscribing to a subset of these layers. Such | bandwidth) by only subscribing to a subset of these layers. Such | |||
skipping to change at page 14, line 45 ¶ | skipping to change at page 14, line 46 ¶ | |||
be used at a ttl of 127. This is semantically identical to | be used at a ttl of 127. This is semantically identical to | |||
including multiple ``c='' lines in a media description: | including multiple ``c='' lines in a media description: | |||
c=IN IP4 224.2.1.1/127 | c=IN IP4 224.2.1.1/127 | |||
c=IN IP4 224.2.1.2/127 | c=IN IP4 224.2.1.2/127 | |||
c=IN IP4 224.2.1.3/127 | c=IN IP4 224.2.1.3/127 | |||
Multiple addresses or ``c='' lines can only be specified on a per- | Multiple addresses or ``c='' lines can only be specified on a per- | |||
media basis, and not for a session-level ``c='' field. | media basis, and not for a session-level ``c='' field. | |||
It is illegal for the slash notation described above to be used for | The slash notation described above MUST NOT be used for IP unicast | |||
IP unicast addresses. | addresses. | |||
Bandwidth | Bandwidth | |||
b=<modifier>:<bandwidth-value> | b=<modifier>:<bandwidth-value> | |||
o This specifies the proposed bandwidth to be used by the session or | o This specifies the proposed bandwidth to be used by the session or | |||
media, and is optional. | media, and is OPTIONAL. | |||
o <bandwidth-value> is in kilobits per second by default. Modifiers | o <bandwidth-value> is in kilobits per second by default. Modifiers | |||
may specify that alternative units are to be used (the modifiers | may specify that alternative units are to be used (the modifiers | |||
defined in this memo use the default units). | defined in this memo use the default units). | |||
o <modifier> is a single alphanumeric word giving the meaning of the | o <modifier> is a single alphanumeric word giving the meaning of the | |||
bandwidth figure. | bandwidth figure. | |||
o Two modifiers are initially defined: | o Two modifiers are initially defined: | |||
CT Conference Total: An implicit maximum bandwidth is associated with | CT Conference Total: If the bandwidth of a session or media in a | |||
each TTL on the Mbone or within a particular multicast | session is different from the bandwidth implicit from the scope, a | |||
administrative scope region (the Mbone bandwidth vs. TTL limits | `b=CT:...' line should be supplied for the session giving the | |||
are given in the MBone FAQ). If the bandwidth of a session or | proposed upper limit to the bandwidth used. The primary purpose | |||
media in a session is different from the bandwidth implicit from | of this is to give an approximate idea as to whether two or more | |||
the scope, a `b=CT:...' line should be supplied for the session | sessions can co-exist simultaneously. | |||
giving the proposed upper limit to the bandwidth used. The | ||||
primary purpose of this is to give an approximate idea as to | ||||
whether two or more conferences can co-exist simultaneously. | ||||
AS Application-Specific Maximum: The bandwidth is interpreted to be | AS Application-Specific Maximum: The bandwidth is interpreted to be | |||
application-specific, i.e., will be the application's concept of | application-specific, i.e., will be the application's concept of | |||
maximum bandwidth. Normally this will coincide with what is set | maximum bandwidth. Normally this will coincide with what is set | |||
on the application's ``maximum bandwidth'' control if applicable. | on the application's ``maximum bandwidth'' control if applicable. | |||
Note that CT gives a total bandwidth figure for all the media at all | Note that CT gives a total bandwidth figure for all the media at all | |||
sites. AS gives a bandwidth figure for a single media at a single | sites. AS gives a bandwidth figure for a single media at a single | |||
site, although there may be many sites sending simultaneously. | site, although there may be many sites sending simultaneously. | |||
o Extension Mechanism: Tool writers can define experimental bandwidth | o Extension Mechanism: Tool writers can define experimental bandwidth | |||
modifiers by prefixing their modifier with ``X-''. For example: | modifiers by prefixing their modifier with ``X-''. For example: | |||
b=X-YZ:128 | b=X-YZ:128 | |||
SDP parsers should ignore bandwidth fields with unknown modifiers. | SDP parsers MUST ignore bandwidth fields with unknown modifiers. | |||
Modifiers should be alpha-numeric and, although no length limit is | Modifiers MUST be alpha-numeric and, although no length limit is | |||
given, they are recommended to be short. | given, they are recommended to be short. | |||
Times, Repeat Times and Time Zones | Times, Repeat Times and Time Zones | |||
t=<start time> <stop time> | t=<start time> <stop time> | |||
o ``t='' fields specify the start and stop times for a conference | ||||
session. Multiple ``t='' fields may be used if a session is active | o ``t='' fields specify the start and stop times for a session. | |||
at multiple irregularly spaced times; each additional ``t='' field | Multiple ``t='' fields MAY be used if a session is active at | |||
multiple irregularly spaced times; each additional ``t='' field | ||||
specifies an additional period of time for which the session will be | specifies an additional period of time for which the session will be | |||
active. If the session is active at regular times, an ``r='' field | active. If the session is active at regular times, an ``r='' field | |||
(see below) should be used in addition to and following a ``t='' | (see below) should be used in addition to and following a ``t='' | |||
field - in which case the ``t='' field specifies the start and stop | field - in which case the ``t='' field specifies the start and stop | |||
times of the repeat sequence. | times of the repeat sequence. | |||
o The first and second sub-fields give the start and stop times for | o The first and second sub-fields give the start and stop times for | |||
the conference respectively. These values are the decimal | the conference respectively. These values are the decimal | |||
representation of Network Time Protocol (NTP) time values in seconds | representation of Network Time Protocol (NTP) time values in seconds | |||
[1]. To convert these values to UNIX time, subtract decimal | [1]. To convert these values to UNIX time, subtract decimal | |||
2208988800. | 2208988800. | |||
o If the stop-time is set to zero, then the session is not bounded, | o If the stop-time is set to zero, then the session is not bounded, | |||
though it will not become active until after the start-time. If the | though it will not become active until after the start-time. If the | |||
start-time is also zero, the session is regarded as permanent. | start-time is also zero, the session is regarded as permanent. | |||
User interfaces should strongly discourage the creation of unbounded | User interfaces SHOULD strongly discourage the creation of unbounded | |||
and permanent sessions as they give no information about when the | and permanent sessions as they give no information about when the | |||
session is actually going to terminate, and so make scheduling | session is actually going to terminate, and so make scheduling | |||
difficult. | difficult. | |||
The general assumption may be made, when displaying unbounded | The general assumption may be made, when displaying unbounded | |||
sessions that have not timed out to the user, that an unbounded | sessions that have not timed out to the user, that an unbounded | |||
session will only be active until half an hour from the current time | session will only be active until half an hour from the current time | |||
or the session start time, whichever is the later. If behaviour | or the session start time, whichever is the later. If behaviour | |||
other than this is required, an end-time should be given and | other than this is required, an end-time should be given and | |||
modified as appropriate when new information becomes available about | modified as appropriate when new information becomes available about | |||
when the session should really end. | when the session should really end. | |||
Permanent sessions may be shown to the user as never being active | Permanent sessions may be shown to the user as never being active | |||
unless there are associated repeat times which state precisely when | unless there are associated repeat times which state precisely when | |||
the session will be active. In general, permanent sessions should | the session will be active. In general, permanent sessions SHOULD | |||
not be created for any session expected to have a duration of less | NOT be created for any session expected to have a duration of less | |||
than 2 months, and should be discouraged for sessions expected to | than 2 months, and should be discouraged for sessions expected to | |||
have a duration of less than 6 months. | have a duration of less than 6 months. | |||
r=<repeat interval> <active duration> <list of offsets from start-time> | r=<repeat interval> <active duration> <list of offsets from start-time> | |||
o ``r='' fields specify repeat times for a session. For example, if | o ``r='' fields specify repeat times for a session. For example, if | |||
a session is active at 10am on Monday and 11am on Tuesday for one | a session is active at 10am on Monday and 11am on Tuesday for one | |||
hour each week for three months, then the <start time> in the | hour each week for three months, then the <start time> in the | |||
corresponding ``t='' field would be the NTP representation of 10am | corresponding ``t='' field would be the NTP representation of 10am | |||
on the first Monday, the <repeat interval> would be 1 week, the | on the first Monday, the <repeat interval> would be 1 week, the | |||
<active duration> would be 1 hour, and the offsets would be zero and | <active duration> would be 1 hour, and the offsets would be zero and | |||
25 hours. The corresponding ``t='' field stop time would be the NTP | 25 hours. The corresponding ``t='' field stop time would be the NTP | |||
representation of the end of the last session three months later. By | representation of the end of the last session three months later. By | |||
default all fields are in seconds, so the ``r='' and ``t='' fields | default all fields are in seconds, so the ``r='' and ``t='' fields | |||
might be: | might be: | |||
t=3034423619 3042462419 | t=3034423619 3042462419 | |||
r=604800 3600 0 90000 | r=604800 3600 0 90000 | |||
To make announcements more compact, times may also be given in units | To make description more compact, times may also be given in units | |||
of days, hours or minutes. The syntax for these is a number | of days, hours or minutes. The syntax for these is a number | |||
immediately followed by a single case-sensitive character. | immediately followed by a single case-sensitive character. | |||
Fractional units are not allowed - a smaller unit should be used | Fractional units are not allowed - a smaller unit should be used | |||
instead. The following unit specification characters are allowed: | instead. The following unit specification characters are allowed: | |||
d - days (86400 seconds) | d - days (86400 seconds) | |||
h - minutes (3600 seconds) | h - minutes (3600 seconds) | |||
m - minutes (60 seconds) | m - minutes (60 seconds) | |||
s - seconds (allowed for completeness but not recommended) | s - seconds (allowed for completeness but not recommended) | |||
skipping to change at page 18, line 22 ¶ | skipping to change at page 18, line 19 ¶ | |||
o If a session is likely to last several years, it is expected that | o If a session is likely to last several years, it is expected that | |||
the session announcement will be modified periodically rather than | the session announcement will be modified periodically rather than | |||
transmit several years worth of adjustments in one announcement. | transmit several years worth of adjustments in one announcement. | |||
Encryption Keys | Encryption Keys | |||
k=<method> | k=<method> | |||
k=<method>:<encryption key> | k=<method>:<encryption key> | |||
o The session description protocol may be used to convey encryption | o The session description protocol MAY be used to convey encryption | |||
keys. A key field is permitted before the first media entry (in | keys. A key field is permitted before the first media entry (in | |||
which case it applies to all media in the session), or for each | which case it applies to all media in the session), or for each | |||
media entry as required. | media entry as required. | |||
o The format of keys and their usage is outside the scope of this | o The format of keys and their usage is outside the scope of this | |||
document, but see [3]. | document, but see [3]. | |||
o The method indicates the mechanism to be used to obtain a usable key | o The method indicates the mechanism to be used to obtain a usable key | |||
by external means, or from the encoded encryption key given. The | by external means, or from the encoded encryption key given. The | |||
following methods are defined: | following methods are defined: | |||
skipping to change at page 19, line 50 ¶ | skipping to change at page 19, line 48 ¶ | |||
o value attributes. A value attribute is of the form | o value attributes. A value attribute is of the form | |||
``a=<attribute>:<value>''. An example might be that a whiteboard | ``a=<attribute>:<value>''. An example might be that a whiteboard | |||
could have the value attribute ``a=orient:landscape'' | could have the value attribute ``a=orient:landscape'' | |||
Attribute interpretation depends on the media tool being invoked. Thus | Attribute interpretation depends on the media tool being invoked. Thus | |||
receivers of session descriptions should be configurable in their | receivers of session descriptions should be configurable in their | |||
interpretation of announcements in general and of attributes in | interpretation of announcements in general and of attributes in | |||
particular. | particular. | |||
Attribute names must be in the US-ASCII subset of ISO-10646/UTF-8. | Attribute names MUST be in the US-ASCII subset of ISO-10646/UTF-8. | |||
Attribute values are byte strings, and MAY use any byte value except | Attribute values are byte strings, and MAY use any byte value except | |||
0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute values are | 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute values are | |||
to be interpreted as in ISO-10646 character set with UTF-8 encoding. | to be interpreted as in ISO-10646 character set with UTF-8 encoding. | |||
Unlike other text fields, attribute values are NOT normally affected by | Unlike other text fields, attribute values are NOT normally affected by | |||
the `charset' attribute as this would make comparisons against known | the `charset' attribute as this would make comparisons against known | |||
values problematic. However, when an attribute is defined, it can be | values problematic. However, when an attribute is defined, it can be | |||
defined to be charset-dependent, in which case it's value should be | defined to be charset-dependent, in which case it's value should be | |||
interpreted in the session charset rather than in ISO-10646. | interpreted in the session charset rather than in ISO-10646. | |||
skipping to change at page 20, line 47 ¶ | skipping to change at page 20, line 44 ¶ | |||
conference control channel for the session. | conference control channel for the session. | |||
o The second sub-field is the transport port to which the media stream | o The second sub-field is the transport port to which the media stream | |||
will be sent. The meaning of the transport port depends on the | will be sent. The meaning of the transport port depends on the | |||
network being used as specified in the relevant ``c'' field and on | network being used as specified in the relevant ``c'' field and on | |||
the transport protocol defined in the third sub-field. Other ports | the transport protocol defined in the third sub-field. Other ports | |||
used by the media application (such as the RTCP port, see [2]) | used by the media application (such as the RTCP port, see [2]) | |||
should be derived algorithmically from the base media port. | should be derived algorithmically from the base media port. | |||
Note: For transports based on UDP, the value should be in the range | Note: For transports based on UDP, the value should be in the range | |||
1024 to 65535 inclusive. For RTP compliance it should be an even | 1024 to 65535 inclusive. For RTP compliance it SHOULD be an even | |||
number. | number. | |||
For applications where hierarchically encoded streams are being sent | For applications where hierarchically encoded streams are being sent | |||
to a unicast address, it may be necessary to specify multiple | to a unicast address, it may be necessary to specify multiple | |||
transport ports. This is done using a similar notation to that used | transport ports. This is done using a similar notation to that used | |||
for IP multicast addresses in the ``c='' field: | for IP multicast addresses in the ``c='' field: | |||
m=<media> <port>/<number of ports> <transport> <fmt list> | m=<media> <port>/<number of ports> <transport> <fmt list> | |||
In such a case, the ports used depend on the transport protocol. | In such a case, the ports used depend on the transport protocol. | |||
skipping to change at page 22, line 22 ¶ | skipping to change at page 22, line 20 ¶ | |||
In addition, relays and monitoring tools that are transport- | In addition, relays and monitoring tools that are transport- | |||
protocol-specific but format-independent are possible. | protocol-specific but format-independent are possible. | |||
For RTP media streams operating under the RTP Audio/Video Profile | For RTP media streams operating under the RTP Audio/Video Profile | |||
[3], the protocol field is ``RTP/AVP''. Should other RTP profiles | [3], the protocol field is ``RTP/AVP''. Should other RTP profiles | |||
be defined in the future, their profiles will be specified in the | be defined in the future, their profiles will be specified in the | |||
same way. For example, the protocol field ``RTP/XYZ'' would specify | same way. For example, the protocol field ``RTP/XYZ'' would specify | |||
RTP operating under a profile whose short name is ``XYZ''. | RTP operating under a profile whose short name is ``XYZ''. | |||
o The fourth and subsequent sub-fields are media formats. For audio | o The fourth and subsequent sub-fields are media formats. For audio | |||
and video, these will normally be a media payload type as defined in | and video, these SHOULD reference a MIME sub-type describing the | |||
the RTP Audio/Video Profile. | format under the `audio' and `video' top-level MIME types. | |||
When a list of payload formats is given, this implies that all of | When a list of payload formats is given, this implies that all of | |||
these formats may be used in the session, but the first of these | these formats may be used in the session, but the first of these | |||
formats is the default format for the session. | formats is the default format for the session. | |||
For media whose transport protocol is not RTP or UDP the format | For media whose transport protocol is not RTP or UDP the format | |||
field is protocol specific. Such formats should be defined in an | field is protocol specific. Such formats should be defined in an | |||
additional specification document. | additional specification document. | |||
For media whose transport protocol is RTP, SDP can be used to | For media whose transport protocol is RTP, SDP can be used to | |||
skipping to change at page 29, line 8 ¶ | skipping to change at page 29, line 8 ¶ | |||
controller is given. | controller is given. | |||
In this document, only the declarative style of conference control | In this document, only the declarative style of conference control | |||
declaration is specified. Other forms of conference control should | declaration is specified. Other forms of conference control should | |||
specify an appropriate type attribute, and should define the | specify an appropriate type attribute, and should define the | |||
implications this has for control media. | implications this has for control media. | |||
7. Security Considerations | 7. Security Considerations | |||
SDP is a session description format that describes multimedia sessions. | SDP is a session description format that describes multimedia sessions. | |||
A session description should not be trusted unless it has been obtained | A session description SHOULD NOT be trusted unless it has been obtained | |||
by an authenticated transport protocol from a trusted source. Many | by an authenticated transport protocol from a trusted source. Many | |||
different transport protocols may be used to distribute session | different transport protocols may be used to distribute session | |||
description, and the nature of the authentication will differ from | description, and the nature of the authentication will differ from | |||
transport to transport. | 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 provides | descriptions is the Session Announcement Protocol (SAP). SAP provides | |||
both encryption and authentication mechanisms but due to the nature of | both encryption and authentication mechanisms but due to the nature of | |||
session announcements it is likely that there are many occasions where | session announcements it is likely that there are many occasions where | |||
the originator of a session announcement cannot be authenticated because | the originator of a session announcement cannot be authenticated because | |||
skipping to change at page 29, line 34 ¶ | skipping to change at page 29, line 34 ¶ | |||
should take a few precautions. Session description contain information | should take a few precautions. Session description contain information | |||
required to start software on the receivers system. Software that | required to start software on the receivers system. Software that | |||
parses a session description MUST not be able to start other software | parses a session description MUST not be able to start other software | |||
except that which is specifically configured as appropriate software to | except that which is specifically configured as appropriate software to | |||
participate in multimedia sessions. It is normally considered | participate in multimedia sessions. It is normally considered | |||
INAPPROPRIATE for software parsing a session description to start, on a | INAPPROPRIATE for software parsing a session description to start, on a | |||
user's system, software that is appropriate to participate in multimedia | user's system, software that is appropriate to participate in multimedia | |||
sessions, without the user first being informed that such software will | sessions, without the user first being informed that such software will | |||
be started and giving their consent. Thus a session description | be started and giving their consent. Thus a session description | |||
arriving by session announcement, email, sessioR multimedia,session page | arriving by session announcement, email, sessioR multimedia,session page | |||
SHOULD not deliver the user into an interactive | SHOULD NOT deliver the user into an interactive | |||
without the user being aware that this will happen. As it is not always | without the user being aware that this will happen. As it is not always | |||
simple to tell whether a session is interactive or not, applications | simple to tell whether a session is interactive or not, applications | |||
that are unsure should assume sessions are interactive. | that are unsure should assume sessions are interactive. | |||
In this specification, there are no attributes which would allow the | In this specification, there are no attributes which would allow the | |||
recipient of a session description to be informed to start multimedia | recipient of a session description to be informed to start multimedia | |||
tools in a mode where they default to transmitting. Under some | tools in a mode where they default to transmitting. Under some | |||
circumstances it might be appropriate to define such attributes. If | circumstances it might be appropriate to define such attributes. If | |||
this is done an application parsing a session description containing | this is done an application parsing a session description containing | |||
such attributes SHOULD either ignore them, or inform the user that | such attributes SHOULD either ignore them, or inform the user that | |||
skipping to change at line 1492 ¶ | skipping to change at page 35, line 12 ¶ | |||
;there must be a space or hyphen between the | ;there must be a space or hyphen between the | |||
;international code and the rest of the number. | ;international code and the rest of the number. | |||
nettype = "IN" | nettype = "IN" | |||
;list to be extended | ;list to be extended | |||
addrtype = "IP4" | "IP6" | addrtype = "IP4" | "IP6" | |||
;list to be extended | ;list to be extended | |||
addr = FQDN | unicast-address | addr = FQDN | unicast-address | |||
FQDN = 4*(alpha-numeric|"-"|".") | ||||
;fully qualified domain name as specified in RFC1035 | ||||
unicast-address = IP4-address | IP6-address | ||||
IP4-address = b1 "." decimal_uchar "." decimal_uchar "." b4 | ||||
b1 = decimal_uchar | ||||
;less than "224"; not "0" or "127" | ||||
b4 = decimal_uchar | ||||
;not "0" | ||||
IP6-address = ;to be defined | ||||
text = byte-string | ||||
;default is to interpret this as IS0-10646 UTF8 | ||||
;ISO 8859-1 requires a "a=charset:ISO-8859-1" | ||||
;session-level attribute to be used | ||||
byte-string = 1*(0x01..0x09|0x0b|0x0c|0x0e..0xff) | ||||
;any byte except NUL, CR or LF | ||||
decimal_uchar = DIGIT | ||||
| POS-DIGIT DIGIT | ||||
| ("1" 2*(DIGIT)) | ||||
| ("2" ("0"|"1"|"2"|"3"|"4") DIGIT) | ||||
| ("2" "5" ("0"|"1"|"2"|"3"|"4"|"5")) | ||||
integer = POS-DIGIT *(DIGIT) | ||||
alpha-numeric = ALPHA | DIGIT | ||||
DIGIT = "0" | POS-DIGIT | ||||
POS-DIGIT = "1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9" | ||||
ALPHA = "a"|"b"|"c"|"d"|"e"|"f"|"g"|"h"|"i"|"j"|"k"| | ||||
"l"|"m"|"n"|"o "|"p"|"q"|"r"|"s"|"t"|"u"|"v"| | ||||
"w"|"x"|"y"|"z"|"A"|"B"|"C "|"D"|"E"|"F"|"G"| | ||||
"H"|"I"|"J"|"K"|"L"|"M"|"N"|"O"|"P"|" Q"|"R"| | ||||
"S"|"T"|"U"|"V"|"W"|"X"|"Y"|"Z" | ||||
email-safe = safe | space | tab | ||||
safe = alpha-numeric | | ||||
"'" | "'" | "-" | "." | "/" | ":" | "?" | """ | | ||||
"#" | "$" | "&" | "*" | ";" | "=" | "@" | "[" | | ||||
"]" | "^" | "_" | "`" | "{" | "|" | "}" | "+" | | ||||
"~" | "\" | ||||
space = %d32 | ||||
tab = %d9 | ||||
CRLF = %d13.10 | ||||
Appendix B: Guidelines for registering SDP names with IANA | ||||
There are seven field names that may be registered with IANA. Using the | ||||
terminology in the SDP specification BNF, they are "media", "proto", | ||||
"fmt", "att-field", "bwtype", "nettype" and "addrtype". | ||||
"media" (eg, audio, video, application, data). | ||||
The set of media is intended to be small and not to be extended | ||||
except under rare circumstances. The same rules should apply for | ||||
media names as for top-level MIME content types, and where possible | ||||
the same name should be registered for SDP as for MIME. For media | ||||
other than existing MIME top-level content types, a standards-track | ||||
RFC MUST be produced for a new top-level content type to be | ||||
registered, and the registration MUST provide good justification | ||||
why no existing media name is appropriate. | ||||
"proto" | ||||
In general this should be an IETF standards-track transport | ||||
protocol identifier such as RTP/AVP (rfc 1889 under the rfc 1890 | ||||
profile). | ||||
However, people will want to invent their own proprietary transport | ||||
protocols. Some of these should be registered as a "fmt" using | ||||
"udp" as the protocol and some of which probably can't be. | ||||
Where the protocol and the application are intimately linked, such | ||||
as with the LBL whiteboard wb which used a proprietary and special | ||||
purpose protocol over UDP, the protocol name should be "udp" and | ||||
the format name that should be registered is "wb". The rules for | ||||
formats (see below) apply to such registrations. | ||||
Where the proprietary transport protocol really carries many | ||||
different data formats, it is possible to register a new protocol | ||||
name with IANA. In such a case, an RFC MUST be produced describing | ||||
the protocol and referenced in the registration. Such an RFC MAY | ||||
be informational, although it is preferable if it is standards- | ||||
track. | ||||
"fmt" | ||||
The format namespace is dependent on the context of the "proto" | ||||
field, so a format cannot be registered without specifying one or | ||||
more transport protocols that it applies to. | ||||
Formats cover all the possible encodings that might want to be | ||||
transported in a multimedia session. | ||||
For RTP formats that have been assigned static payload types, the | ||||
payload type number is used. For RTP formats using a dynamic | ||||
payload type number, the dynamic payload type number is given as | ||||
the format and an additional "rtpmap" attribute specifies the | ||||
format and parameters. | ||||
For non-RTP formats, any unregistered format name may be | ||||
registered. If there is a suitable mapping from a MIME subtype to | ||||
the format, then the MIME subtype name should be registered. If | ||||
there is no suitable mapping from a MIME subtype, a new name should | ||||
be registered. In either case, unless there are strong reasons not | ||||
to do so, a standards-track RFC SHOULD be produced describing the | ||||
format and this RFC SHOULD be referenced in the registration. | ||||
"att-field" (Attribute names) | ||||
Attribute field names MAY be registered with IANA, although this is | ||||
not compulsory, and unknown attributes are simply ignored. | ||||
When an attribute is registered, it must be accompanied by a brief | ||||
specification stating the following: | ||||
o contact name, email address and telephone number | ||||
o attribute-name (as it will appear in SDP) | ||||
o long-form attribute name in English | ||||
o type of attribute (session level, media level, or both) | ||||
o whether the attribute value is subject to the charset | ||||
attribute. | ||||
o a one paragraph explanation of the purpose of the attribute. | ||||
o a specification of appropriate attribute values for this | ||||
attribute. | ||||
IANA will not sanity check such attribute registrations except to | ||||
ensure that they do not clash with existing registrations. | ||||
Although the above is the minimum that IANA will accept, if the | ||||
attribute is expected to see widespread use and interoperability is | ||||
an issue, authors are encouraged to produce a standards-track RFC | ||||
that specifies the attribute more precisely. | ||||
Submitters of registrations should ensure that the specification is | ||||
in the spirit of SDP attributes, most notably that the attribute is | ||||
platform independent in the sense that it makes no implicit | ||||
assumptions about operating systems and does not name specific | ||||
pieces of software in a manner that might inhibit interoperability. | ||||
"bwtype" (bandwidth specifiers) | ||||
A proliferation of bandwidth specifiers is strongly discouraged. | ||||
New bandwidth specifiers may be registered with IANA. The | ||||
submission MUST reference a standards-track RFC specifying the | ||||
semantics of the bandwidth specifier precisely, and indicating when | ||||
it should be used, and why the existing registered bandwidth | ||||
specifiers do not suffice. | ||||
"nettype" (Network Type) | ||||
New network types may be registered with IANA if SDP needs to be | ||||
used in the context of non-internet environments. Whilst these are | ||||
not normally the preserve of IANA, there may be circumstances when | ||||
an Internet application needs to interoperate with a non-internet | ||||
application, such as when gatewaying an internet telephony call | ||||
into the PSTN. The number of network types should be small and | ||||
should be rarely extended. A new network type cannot be registered | ||||
without registering at least one address type to be used with that | ||||
network type. A new network type registration MUST reference an | ||||
RFC which gives details of the network type and address type and | ||||
specifies how and when they would be used. Such an RFC MAY be | ||||
Informational. | ||||
"addrtype" (Address Type) | ||||
New address types may be registered with IANA. An address type is | ||||
only meaningful in the context of a network type, and any | ||||
registration of an address type MUST specify a registered network | ||||
type, or be submitted along with a network type registration. A | ||||
new address type registration MUST reference an RFC giving details | ||||
of the syntax of the address type. Such an RFC MAY be | ||||
Informational. Address types are not expected to be registered | ||||
frequently. | ||||
Registration Procedure | ||||
To register a name the above guidelines should be followed regarding the | ||||
required level of documentation that is required. The registration | ||||
itself should be sent to IANA. Attribute registrations should include | ||||
the information given above. Other registrations should include the | ||||
following additional information: | ||||
o contact name, email address and telephone number | ||||
o name being registered (as it will appear in SDP) | ||||
o long-form name in English | ||||
o type of name ("media", "proto", "fmt", "bwtype", "nettype", or | ||||
"addrtype") | ||||
o a one paragraph explanation of the purpose of the registered name. | ||||
o a reference to the specification (eg RFC number) of the registered | ||||
name. | ||||
IANA may refer any registration to the IESG or to any appropriate IETF | ||||
working group for review, and may request revisions to be made before a | ||||
registration will be made. | ||||
Appendix C: Authors' Addresses | ||||
Mark Handley | ||||
AT&T Center for Internet Research at ICSI, | ||||
International Computer Science Institute, | ||||
1947 Center Street, Suite 600, | ||||
Berkeley, CA 94704, USA | ||||
Email: mjh@isi.edu | ||||
Van Jacobson | ||||
MS 46a-1121 | ||||
Lawrence Berkeley Laboratory | ||||
Berkeley, CA 94720 | ||||
United States | ||||
Email: van@ee.lbl.gov | ||||
Colin Perkins | ||||
USC Information Sciences Institute | ||||
4350 N. Fairfax Drive | ||||
Arlington, VA 22203 | ||||
United States | ||||
Email: csp@isi.edu | ||||
Acknowledgments | ||||
Many people in the IETF MMUSIC working group have made comments and | ||||
suggestions contributing to this document. In particular, we would like | ||||
to thank Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross | ||||
Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann and Steve Hanna. | ||||
References | ||||
[1] D. Mills, ``Network Time Protocol (version 3) specification and | ||||
implementation", RFC 1305, March 1992. | ||||
[2] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, ``RTP: A | ||||
Transport Protocol for Real-Time Applications'', RFC 1889, January | ||||
1996. | ||||
[3] H. Schulzrinne, ``RTP Profile for Audio and Video Conferences with | ||||
Minimal Control'', RFC 1890, January 1996. | ||||
[4] M. Handley, C. Perkins and E. Whelan, ``Session Announcement | ||||
Protocol'', RFC 2974, October 2000. | ||||
[5] V. Jacobson and S. McCanne, ``vat - X11-based audio teleconferencing | ||||
tool'' vat manual page, Lawrence Berkeley Laboratory, 1994. | ||||
[6] The Unicode Consortium, "The Unicode Standard -- Version 2.0", | ||||
Addison-Wesley, 1996. | ||||
[7] ISO/IEC 10646-1:1993. International Standard -- Information | ||||
technology -- Universal Multiple-Octet Coded Character Set (UCS) | ||||
-- Part 1: Architecture and Basic Multilingual Plane. Five | ||||
amendments and a technical corrigendum have been published up | ||||
to now. UTF-8 is described in Annex R, published as Amendment 2. | ||||
[8] D. Goldsmith and M. Davis, ``Using Unicode with MIME'', RFC1641, | ||||
July 1994 | ||||
[9] F. Yergeau, ``UTF-8, a transformation format of Unicode and ISO | ||||
10646'', RFC 2044, October 1996 | ||||
[10] ITU-T Recommendation H.332 (1998): "Multimedia Terminal for | ||||
Receiving Internet-based H.323 Conferences", ITU, Geneva. | ||||
[11] M. Handley, H. Schulzrinne, E. Scholler and J. Rosenberg ``SIP: | ||||
Session Initiation Protocol'', RFC 2543, March 1999. | ||||
[12] H. Schulzrinne, A. Rao and R. Lanphier, ``Real Time Streaming | ||||
Protocol (RTSP)'' RFC 2326, April 1998. | ||||
[13] S. Bradner, ``Key words for use in RFCs to Indicate Requirement | ||||
Levels'', RFC 2119, March 1997. | ||||
End of changes. 52 change blocks. | ||||
143 lines changed or deleted | 126 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/ |