draft-ietf-mmusic-sdp-new-07.txt | draft-ietf-mmusic-sdp-new-08.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-07.txt Van Jacobson/Packet Design | draft-ietf-mmusic-sdp-new-08.txt Van Jacobson/Packet Design | |||
Colin Perkins/ISI | Colin Perkins/ISI | |||
26 March 2002 | 19 April 2002 | |||
Expires: September 2002 | Expires: October 2002 | |||
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 2, line 12 ¶ | skipping to change at page 2, line 12 ¶ | |||
purposes of session announcement, session invitation, and | purposes of session announcement, session invitation, and | |||
other forms of multimedia session initiation. | other forms of multimedia session initiation. | |||
1. Introduction | 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 memo does not describe multicast address allocation or | |||
the distribution of SDP messages. These are described in accompanying | the distribution of SDP messages. These are described in accompanying | |||
drafts. SDP is not intended for negotiation of media encodings. | drafts. SDP is not intended for negotiation of media 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. | |||
Session directories assist the advertisement of conference sessions and | Session directories assist the advertisement of conference sessions and | |||
communicate the relevant conference setup information to prospective | communicate the relevant conference setup information to prospective | |||
participants. SDP is designed to convey such information to recipients. | participants. SDP is designed to convey such information to recipients. | |||
skipping to change at page 3, line 30 ¶ | skipping to change at page 3, line 30 ¶ | |||
discover and participate in a multimedia session. | discover and participate in a multimedia session. | |||
3.1. Terminology | 3.1. Terminology | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in RFC 2119 [13]. | document are to be interpreted as described in RFC 2119 [13]. | |||
4. Examples of SDP Usage | 4. Examples of SDP Usage | |||
4.1. Session Initiation | 4.1. Multicast Announcement | |||
In order to assist the advertisement of multicast multimedia conferences | ||||
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. | ||||
One protocol commonly used to implement such a distributed directory is | ||||
the Session Announcement Protocol, SAP [4]. SDP provides the recommended | ||||
session description format for such announcements. | ||||
4.2. Session Initiation | ||||
The Session Initiation Protocol, SIP [11] is an application-layer | The Session Initiation Protocol, SIP [11] is an application-layer | |||
control protocol for creating, modifying and terminating sessions such | control protocol for creating, modifying and terminating sessions such | |||
as Internet multimedia conferences, Internet telephone calls and | as Internet multimedia conferences, Internet telephone calls and | |||
multimedia distribution. The SIP messages used to create sessions carry | multimedia distribution. The SIP messages used to create sessions carry | |||
session descriptions which allow participants to agree on a set of | session descriptions which allow participants to agree on a set of | |||
compatible media types. These session descriptions are commonly | compatible media types. These session descriptions are commonly | |||
formatted using SDP. | formatted using SDP. | |||
4.2. Streaming media | 4.3. Streaming media | |||
The Real Time Streaming Protocol, RTSP [12], is an application-level | The Real Time Streaming Protocol, RTSP [12], is an application-level | |||
protocol for control over the delivery of data with real-time | protocol for control over the delivery of data with real-time | |||
properties. RTSP provides an extensible framework to enable controlled, | properties. RTSP provides an extensible framework to enable controlled, | |||
on-demand delivery of real-time data, such as audio and video. It is | 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 | necessary for RTSP to convey a description of the session to be | |||
controlled: SDP is often used for this purpose. | controlled. SDP is often used for this purpose. | |||
4.3. Multicast Announcement | ||||
In order to assist the advertisement of multicast multimedia conferences | ||||
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. | ||||
One protocol commonly used to implement such a distributed directory is | ||||
the Session Announcement Protocol, SAP [4]. SDP provides the recommended | ||||
session description format for such announcements. | ||||
4.4. Email and the World Wide Web | 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'' MUST 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 | |||
skipping to change at page 7, line 32 ¶ | skipping to change at page 7, line 33 ¶ | |||
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 attribute 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 SDP may be used in environments where the | descriptions. However, since SDP may be used in environments where the | |||
maximum permissable size of a session description is limited (e.g. SAP | maximum permissable size of a session description is limited (e.g. SAP | |||
announcements; SIP transported in UDP), the encoding is deliberately | announcements; SIP transported in UDP), the encoding is deliberately | |||
compact. Also, since announcements may be transported via very | compact. Also, since announcements may be transported via very | |||
unreliable means (e.g., email) or damaged by an intermediate caching | unreliable means or damaged by an intermediate caching server, the | |||
server, the encoding was designed with strict order and formatting rules | encoding was designed with strict order and formatting rules so that | |||
so that most errors would result in malformed announcements which could | most errors would result in malformed announcements which could be | |||
be detected easily and discarded. This also allows rapid discarding of | detected easily and discarded. This also allows rapid discarding of | |||
encrypted announcements for which a receiver does not have the correct | encrypted announcements for which a receiver does not have the correct | |||
key. | 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 MUST NOT be used 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 section followed by | |||
that apply to the whole session and all media streams) and optionally | zero or more media-level sections. The session-level part starts with a | |||
several media-level descriptions (details that apply only to a single | `v=' line and continues to the first media-level section. The media | |||
media stream). | ||||
An announcement consists of a session-level section followed by zero or | ||||
more media-level sections. The session-level part starts with a `v=' | ||||
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. | |||
Some lines in each description are REQUIRED and some are OPTIONAL but | 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 | all MUST appear in exactly the order given here (the fixed order greatly | |||
enhances error detection and allows for a simple parser). OPTIONAL | enhances error detection and allows for a simple parser). OPTIONAL | |||
items are marked with a `*'. | items are marked with a `*'. | |||
skipping to change at page 10, line 19 ¶ | skipping to change at page 10, line 19 ¶ | |||
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps | u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps | |||
e=mjh@isi.edu (Mark Handley) | e=mjh@isi.edu (Mark Handley) | |||
c=IN IP4 224.2.17.12/127 | c=IN IP4 224.2.17.12/127 | |||
t=2873397496 2873404696 | t=2873397496 2873404696 | |||
a=recvonly | a=recvonly | |||
m=audio 49170 RTP/AVP 0 | m=audio 49170 RTP/AVP 0 | |||
m=video 51372 RTP/AVP 31 | m=video 51372 RTP/AVP 31 | |||
m=application 32416 udp wb | m=application 32416 udp wb | |||
a=orient:portrait | a=orient:portrait | |||
Text records such as the session name and information are bytes strings | Text records such as the session name and information are octet strings | |||
which may contain any byte with the exceptions of 0x00 (Nul), 0x0a | which may contain any octet with the exceptions of 0x00 (Nul), 0x0a | |||
(ASCII newline) and 0x0d (ASCII carriage return). The sequence CRLF | (ASCII newline) and 0x0d (ASCII carriage return). The sequence CRLF | |||
(0x0d0a) is used to end a record, although parsers should be tolerant | (0x0d0a) is used to end a record, although parsers SHOULD be tolerant | |||
and also accept records terminated with a single newline character. By | and also accept records terminated with a single newline character. By | |||
default these byte strings contain ISO-10646 characters in UTF-8 | default these byte strings contain ISO-10646 characters in UTF-8 | |||
encoding, but this default may be changed using the `charset' attribute. | encoding, but this default MAY be changed using the `charset' attribute. | |||
Protocol Version | Protocol Version | |||
v=0 | v=0 | |||
The ``v='' field gives the version of the Session Description Protocol. | The ``v='' field gives the version of the Session Description Protocol. | |||
There is no minor version number. | There is no minor version number. | |||
Origin | Origin | |||
skipping to change at page 12, line 13 ¶ | skipping to change at page 12, line 13 ¶ | |||
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 | A URI is a Universal Resource Identifier as used by WWW clients. The URI | |||
should be a pointer to additional information about the conference. This | ||||
o The URI should be a pointer to additional information about the | field is OPTIONAL, but if it is present it MUST be specified before the | |||
conference | first media field. No more than one URI field is allowed per session | |||
description | ||||
o This field is OPTIONAL, but if it is present it MUST be specified | ||||
before the first media field | ||||
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 | 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 | |||
the conference announcement. | conference announcement. | |||
o Inclusion of an email address or phone number is OPTIONAL. Note | ||||
that the previous version of SDP specified that either an email | ||||
field or a phone field MUST be specified, but this was widely | ||||
ignored. The change brings the specification into line with common | ||||
usage. | ||||
o If these are present, they should be specified before the first | Inclusion of an email address or phone number is OPTIONAL. Note that the | |||
media field. | previous version of SDP specified that either an email field or a phone | |||
field MUST be specified, but this was widely ignored. The change brings | ||||
the specification into line with common usage. | ||||
o More than one email or phone field can be given for a session | If these are present, they MUST be specified before the first media | |||
description. | field. More than one email or phone field can be given for a session | |||
description. | ||||
o Phone numbers should be given in the conventional international | Phone numbers should be given in the conventional international format - | |||
format - preceded by a ``+'' and the international country code. | preceded by a ``+'' and the international country code. There must be a | |||
There must be a space or a hyphen (``-'') between the country code | space or a hyphen (``-'') between the country code and the rest of the | |||
and the rest of the phone number. Spaces and hyphens may be used to | phone number. Spaces and hyphens may be used to split up a phone field | |||
split up a phone field to aid readability if desired. For example: | to aid readability if desired. For example: | |||
p=+44-171-380-7777 or p=+1 617 253 6011 | p=+44-171-380-7777 or p=+1 617 253 6011 | |||
o Both email addresses and phone numbers can have an optional free | Both email addresses and phone numbers can have an optional free text | |||
text string associated with them, normally giving the name of the | string associated with them, normally giving the name of the person who | |||
person who may be contacted. This should be enclosed in parenthesis | may be contacted. This should be enclosed in parenthesis if it is | |||
if it is present. For example: | present. For example: | |||
e=mjh@isi.edu (Mark Handley) | e=mjh@isi.edu (Mark Handley) | |||
The alternative RFC822 name quoting convention is also allowed for | The alternative RFC822 name quoting convention is also allowed for both | |||
both email addresses and phone numbers. For example, | email addresses and phone numbers. For example, | |||
e=Mark Handley <mjh@isi.edu> | e=Mark Handley <mjh@isi.edu> | |||
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 | |||
UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if | encoding, or alternatively in ISO-8859-1 or other encodings if the | |||
the appropriate charset session-level attribute is set. | 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 either one ``c='' field in each | A session announcement MUST contain either one ``c='' field in each | |||
media description (see below) or a ``c='' field at the session-level. | media description (see below) or a ``c='' field at the session-level. | |||
It MAY contain a session-level ``c='' field and one additional ``c='' | It MAY contain a session-level ``c='' field and one additional ``c='' | |||
skipping to change at page 18, line 9 ¶ | skipping to change at page 17, line 45 ¶ | |||
d - days (86400 seconds) | d - days (86400 seconds) | |||
h - hours (3600 seconds) | h - hours (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) | |||
Thus, the above announcement could also have been written: | Thus, the above announcement could also have been written: | |||
r=7d 1h 0 25h | r=7d 1h 0 25h | |||
Monthly and yearly repeats cannot currently be directly specified | Monthly and yearly repeats cannot be directly specified with a | |||
with a single SDP repeat time - instead separate "t" fields should | single SDP repeat time - instead separate "t" fields should be used | |||
be used to explicitly list the session times. | to explicitly list the session times. | |||
z=<adjustment time> <offset> <adjustment time> <offset> .... | z=<adjustment time> <offset> <adjustment time> <offset> .... | |||
o To schedule a repeated session which spans a change from daylight- | o To schedule a repeated session which spans a change from daylight- | |||
saving time to standard time or vice-versa, it is necessary to | saving time to standard time or vice-versa, it is necessary to | |||
specify offsets from the base repeat times. This is required because | specify offsets from the base repeat times. This is required because | |||
different time zones change time at different times of day, | different time zones change time at different times of day, | |||
different countries change to or from daylight time on different | different countries change to or from daylight time on different | |||
dates, and some countries do not have daylight saving time at all. | dates, and some countries do not have daylight saving time at all. | |||
skipping to change at page 20, line 32 ¶ | skipping to change at page 20, line 23 ¶ | |||
``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 octet strings, and MAY use any octet 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. | |||
Attributes that will be commonly used can be registered with IANA (see | Attributes that will be commonly used can be registered with IANA (see | |||
Appendix B). Unregistered attributes should begin with "X-" to prevent | Appendix B). Unregistered attributes should begin with "X-" to prevent | |||
skipping to change at page 24, line 13 ¶ | skipping to change at page 24, line 10 ¶ | |||
attributes. | attributes. | |||
Up to one rtpmap attribute can be defined for each media format | Up to one rtpmap attribute can be defined for each media format | |||
specified. Thus we might have: | specified. Thus we might have: | |||
m=audio 49230 RTP/AVP 96 97 98 | m=audio 49230 RTP/AVP 96 97 98 | |||
a=rtpmap:96 L8/8000 | a=rtpmap:96 L8/8000 | |||
a=rtpmap:97 L16/8000 | a=rtpmap:97 L16/8000 | |||
a=rtpmap:98 L16/11025/2 | a=rtpmap:98 L16/11025/2 | |||
RTP profiles that specify the use of dynamic payload types must | RTP profiles that specify the use of dynamic payload types MUST | |||
define the set of valid encoding names and/or a means to register | define the set of valid encoding names and/or a means to register | |||
encoding names if that profile is to be used with SDP. | encoding names if that profile is to be used with SDP. | |||
Experimental encoding formats can also be specified using rtpmap. | Experimental encoding formats can also be specified using rtpmap. | |||
RTP formats that are not registered as standard format names must be | RTP formats that are not registered as standard format names must be | |||
preceded by ``X-''. Thus a new experimental redundant audio stream | preceded by ``X-''. Thus a new experimental redundant audio stream | |||
called GSMLPC using dynamic payload type 99 could be specified as: | called GSMLPC using dynamic payload type 99 could be specified as: | |||
m=audio 49232 RTP/AVP 99 | m=audio 49232 RTP/AVP 99 | |||
a=rtpmap:99 X-GSMLPC/8000 | a=rtpmap:99 X-GSMLPC/8000 | |||
skipping to change at page 25, line 25 ¶ | skipping to change at page 25, line 22 ¶ | |||
charset specified for the session description if one is specified, | charset specified for the session description if one is specified, | |||
or by default in ISO 10646/UTF-8. | or by default in ISO 10646/UTF-8. | |||
a=tool:<name and version of tool> | a=tool:<name and version of tool> | |||
This gives the name and version number of the tool used to create | This gives the name and version number of the tool used to create | |||
the session description. It is a session-level attribute, and is | the session description. It is a session-level attribute, and is | |||
not dependent on charset. | not dependent on charset. | |||
a=ptime:<packet time> | a=ptime:<packet time> | |||
This gives the length of time in milliseconds represented by the | This gives the length of time in milliseconds represented by the | |||
media in a packet. This is probably only meaningful for audio data. | media in a packet. This is probably only meaningful for audio data, | |||
It should not be necessary to know ptime to decode RTP or vat audio, | but may be used with other media types if it makes sense. It should | |||
and it is intended as a recommendation for the | not be necessary to know ptime to decode RTP or vat audio, and it is | |||
encoding/packetisation of audio. It is a media attribute, and is | intended as a recommendation for the encoding/packetisation of | |||
not dependent on charset. | audio. It is a media attribute, and is not dependent on charset. | |||
a=maxptime:<maximum packet time> | a=maxptime:<maximum packet time> | |||
The maximum amount of media which can be encapsulated in each | The maximum amount of media which can be encapsulated in each | |||
packet, expressed as time in milliseconds. The time shall be | packet, expressed as time in milliseconds. The time SHALL be | |||
calculated as the sum of the time the media present in the packet | calculated as the sum of the time the media present in the packet | |||
represents. The time SHOULD be a multiple of the frame size. This is | represents. The time SHOULD be a multiple of the frame size. This | |||
probably only meaningful for audio data. It is a media attribute, | attribute is probably only meaningful for audio data, but may be | |||
and is not dependent on charset. Note that this attribute was | used with other media types if it makes sense. It is a media | |||
introduced after RFC 2327, and non updated implementations will | attribute, and is not dependent on charset. Note that this | |||
ignore this attribute. | attribute was introduced after RFC 2327, and non updated | |||
implementations will ignore this attribute. | ||||
a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding | a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding | |||
parameters>] | parameters>] | |||
See the section on Media Announcements (the ``m='' field). This may | See the section on Media Announcements (the ``m='' field). This may | |||
be either a session or media attribute. | be either a session or media attribute. | |||
a=recvonly | a=recvonly | |||
This specifies that the tools should be started in receive-only mode | This specifies that the tools should be started in receive-only mode | |||
where applicable. It can be either a session or media attribute, and | where applicable. It can be either a session or media attribute, and | |||
is not dependent on charset. Note that recvonly applies to the media | is not dependent on charset. Note that recvonly applies to the media | |||
skipping to change at page 27, line 22 ¶ | skipping to change at page 27, line 22 ¶ | |||
specified with the following SDP attribute: | specified with the following SDP attribute: | |||
a=charset:ISO-8859-1 | a=charset:ISO-8859-1 | |||
This is a session-level attribute; if this attribute is present, it | This is a session-level attribute; if this attribute is present, it | |||
must be before the first media field. The charset specified MUST be | must be before the first media field. The charset specified MUST be | |||
one of those registered with IANA, such as ISO-8859-1. The | one of those registered with IANA, such as ISO-8859-1. The | |||
character set identifier is a US-ASCII string and MUST be compared | character set identifier is a US-ASCII string and MUST be compared | |||
against the IANA identifiers using a case-insensitive comparison. | against the IANA identifiers using a case-insensitive comparison. | |||
If the identifier is not recognised or not supported, all strings | If the identifier is not recognised or not supported, all strings | |||
that are affected by it SHOULD be regarded as byte strings. | that are affected by it SHOULD be regarded as octet strings. | |||
Note that a character set specified MUST still prohibit the use of | Note that a character set specified MUST still prohibit the use of | |||
bytes 0x00 (Nul), 0x0A (LF) and 0x0d (CR). Character sets requiring | bytes 0x00 (Nul), 0x0A (LF) and 0x0d (CR). Character sets requiring | |||
the use of these characters MUST define a quoting mechanism that | the use of these characters MUST define a quoting mechanism that | |||
prevents these bytes appearing within text fields. | prevents these bytes appearing within text fields. | |||
a=sdplang:<language tag> | a=sdplang:<language tag> | |||
This can be a session level attribute or a media level attribute. | This can be a session level attribute or a media level attribute. | |||
As a session level attribute, it specifies the language for the | As a session level attribute, it specifies the language for the | |||
session description. As a media level attribute, it specifies the | session description. As a media level attribute, it specifies the | |||
skipping to change at page 31, line 24 ¶ | skipping to change at page 31, line 24 ¶ | |||
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 | |||
they are previously unknown to the receiver of the announcement and | they are previously unknown to the receiver of the announcement and | |||
because no common public key infrastructure is available. | because no common public key infrastructure is available. | |||
On receiving a session description over an unauthenticated transport | On receiving a session description over an unauthenticated transport | |||
mechanism or from an untrusted party, software parsing the session | mechanism or from an untrusted party, software parsing the session | |||
should take a few precautions. Session description contain information | should take a few precautions. Session descriptions 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, session invitation, or WWW page | |||
SHOULD NOT deliver the user into an interactive | SHOULD NOT deliver the user into an interactive multimedia session | |||
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 | |||
joining this session will result in the automatic transmission of | joining this session will result in the automatic transmission of | |||
multimedia data. The default behaviour for an unknown attribute is to | multimedia data. The default behaviour for an unknown attribute is to | |||
ignore it. | ignore it. | |||
Session descriptions may be parsed at intermediate systems such as | Session descriptions may be parsed at intermediate systems such as | |||
firewalls for the purposes of opening a hole in the firewall to allow | firewalls for the purposes of opening a hole in the firewall to allow | |||
the participation in multimedia sessions. It is considered | the participation in multimedia sessions. It is considered | |||
INAPPROPRIATE for a firewall to open such holes for unicast data streams | inappropriate for a firewall to open such holes for unicast data streams | |||
unless the session description comes in a request from inside the | unless the session description comes in a request from inside the | |||
firewall. For multicast sessions, it is likely that local | firewall. For multicast sessions, it is likely that local | |||
administrators will apply their own policies, but the exclusive use of | administrators will apply their own policies, but the exclusive use of | |||
"local" or "site-local" administrative scope within the firewall and the | "local" or "site-local" administrative scope within the firewall and the | |||
refusal of the firewall to open a hole for such scopes will provide | refusal of the firewall to open a hole for such scopes will provide | |||
separation of global multicast sessions from local ones. | separation of global multicast sessions from local ones. | |||
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 | |||
skipping to change at page 40, line 4 ¶ | skipping to change at page 40, line 4 ¶ | |||
; generic sub-rules: primitives | ; generic sub-rules: primitives | |||
alpha-numeric = ALPHA / DIGIT | alpha-numeric = ALPHA / DIGIT | |||
POS-DIGIT = %x31-39 ; 1 - 9 | POS-DIGIT = %x31-39 ; 1 - 9 | |||
; external references: | ; external references: | |||
; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 2234 | ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 2234 | |||
; URI-reference: from RFC1630 and RFC2732 | ; URI-reference: from RFC1630 and RFC2732 | |||
; addr-spec: from RFC 2822 | ; addr-spec: from RFC 2822 | |||
Appendix B: Guidelines for registering SDP names with IANA | Appendix B: IANA Considerations | |||
There are seven field names that may be registered with IANA. Using the | There are seven field names that may be registered with IANA. Using the | |||
terminology in the SDP specification BNF, they are "media", "proto", | terminology in the SDP specification BNF, they are "media", "proto", | |||
"fmt", "att-field", "bwtype", "nettype" and "addrtype". | "fmt", "att-field", "bwtype", "nettype" and "addrtype". | |||
"media" (eg, audio, video, application, data). | "media" (eg, audio, video, application, data). | |||
The set of media is intended to be small and not to be extended | The set of media is intended to be small and not to be extended | |||
except under rare circumstances. The same rules should apply for | except under rare circumstances. The same rules should apply for | |||
media names as for top-level MIME content types, and where possible | media names as for top-level MIME content types, and where possible | |||
skipping to change at page 41, line 21 ¶ | skipping to change at page 41, line 21 ¶ | |||
For non-RTP formats, any unregistered format name may be | For non-RTP formats, any unregistered format name may be | |||
registered. If there is a suitable mapping from a MIME subtype to | registered. If there is a suitable mapping from a MIME subtype to | |||
the format, then the MIME subtype name should be registered. If | the format, then the MIME subtype name should be registered. If | |||
there is no suitable mapping from a MIME subtype, a new name should | there is no suitable mapping from a MIME subtype, a new name should | |||
be registered. In either case, unless there are strong reasons not | be registered. In either case, unless there are strong reasons not | |||
to do so, a standards-track RFC SHOULD be produced describing the | to do so, a standards-track RFC SHOULD be produced describing the | |||
format and this RFC SHOULD be referenced in the registration. | format and this RFC SHOULD be referenced in the registration. | |||
"att-field" (Attribute names) | "att-field" (Attribute names) | |||
Attribute field names MAY be registered with IANA, although this is | Attribute field names SHOULD be registered with IANA, although this | |||
not compulsory, and unknown attributes are simply ignored. | is not compulsory, and unknown attributes are simply ignored. | |||
When an attribute is registered, it must be accompanied by a brief | When an attribute is registered, it must be accompanied by a brief | |||
specification stating the following: | specification stating the following: | |||
o contact name, email address and telephone number | o contact name, email address and telephone number | |||
o attribute-name (as it will appear in SDP) | o attribute-name (as it will appear in SDP) | |||
o long-form attribute name in English | o long-form attribute name in English | |||
skipping to change at page 42, line 21 ¶ | skipping to change at page 42, line 21 ¶ | |||
New bandwidth specifiers may be registered with IANA. The | New bandwidth specifiers may be registered with IANA. The | |||
submission MUST reference a standards-track RFC specifying the | submission MUST reference a standards-track RFC specifying the | |||
semantics of the bandwidth specifier precisely, and indicating when | semantics of the bandwidth specifier precisely, and indicating when | |||
it should be used, and why the existing registered bandwidth | it should be used, and why the existing registered bandwidth | |||
specifiers do not suffice. | specifiers do not suffice. | |||
"nettype" (Network Type) | "nettype" (Network Type) | |||
New network types may be registered with IANA if SDP needs to be | New network types may be registered with IANA if SDP needs to be | |||
used in the context of non-internet environments. Whilst these are | used in the context of non-Internet environments. Whilst these are | |||
not normally the preserve of IANA, there may be circumstances when | not normally the preserve of IANA, there may be circumstances when | |||
an Internet application needs to interoperate with a non-internet | an Internet application needs to interoperate with a non-Internet | |||
application, such as when gatewaying an internet telephony call | application, such as when gatewaying an Internet telephony call | |||
into the PSTN. The number of network types should be small and | into the PSTN. The number of network types should be small and | |||
should be rarely extended. A new network type cannot be registered | should be rarely extended. A new network type cannot be registered | |||
without registering at least one address type to be used with that | without registering at least one address type to be used with that | |||
network type. A new network type registration MUST reference an | network type. A new network type registration MUST reference an | |||
RFC which gives details of the network type and address type and | 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 | specifies how and when they would be used. Such an RFC MAY be | |||
Informational. | Informational. | |||
"addrtype" (Address Type) | "addrtype" (Address Type) | |||
End of changes. 38 change blocks. | ||||
107 lines changed or deleted | 96 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/ |