draft-ietf-mmusic-rfc4566bis-01.txt | draft-ietf-mmusic-rfc4566bis-02.txt | |||
---|---|---|---|---|
Network Working Group M. Handley | Network Working Group M. Handley | |||
Internet-Draft UCL | Internet-Draft UCL | |||
Obsoletes: 4566 (if approved) V. Jacobson | Obsoletes: 4566 (if approved) V. Jacobson | |||
Intended status: Standards Track Packet Design | Intended status: Standards Track Packet Design | |||
Expires: December 10, 2008 C. Perkins | Expires: September 10, 2009 C. Perkins | |||
University of Glasgow | University of Glasgow | |||
June 8, 2008 | March 9, 2009 | |||
SDP: Session Description Protocol | SDP: Session Description Protocol | |||
draft-ietf-mmusic-rfc4566bis-01.txt | draft-ietf-mmusic-rfc4566bis-02.txt | |||
Status of This Memo | Status of This Memo | |||
By submitting this Internet-Draft, each author represents that any | This Internet-Draft is submitted to IETF in full conformance with the | |||
applicable patent or other IPR claims of which he or she is aware | provisions of BCP 78 and BCP 79. This document may contain material | |||
have been or will be disclosed, and any of which he or she becomes | from IETF Documents or IETF Contributions published or made publicly | |||
aware will be disclosed, in accordance with Section 6 of BCP 79. | available before November 10, 2008. The person(s) controlling the | |||
copyright in some of this material may not have granted the IETF | ||||
Trust the right to allow modifications of such material outside the | ||||
IETF Standards Process. Without obtaining an adequate license from | ||||
the person(s) controlling the copyright in such materials, this | ||||
document may not be modified outside the IETF Standards Process, and | ||||
derivative works of it may not be created outside the IETF Standards | ||||
Process, except to format it for publication as an RFC or to | ||||
translate it into languages other than English. | ||||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on December 10, 2008. | This Internet-Draft will expire on September 10, 2009. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The IETF Trust (2008). | Copyright (c) 2009 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | ||||
This document is subject to BCP 78 and the IETF Trust's Legal | ||||
Provisions Relating to IETF Documents in effect on the date of | ||||
publication of this document (http://trustee.ietf.org/license-info). | ||||
Please review these documents carefully, as they describe your rights | ||||
and restrictions with respect to this document. | ||||
Abstract | Abstract | |||
This memo defines the Session Description Protocol (SDP). SDP is | This memo defines the Session Description Protocol (SDP). SDP is | |||
intended for describing multimedia sessions for the purposes of | intended for describing multimedia sessions for the purposes of | |||
session announcement, session invitation, and other forms of | session announcement, session invitation, and other forms of | |||
multimedia session initiation. | multimedia session initiation. | |||
Table of Contents | Table of Contents | |||
skipping to change at page 2, line 37 ¶ | skipping to change at page 2, line 51 ¶ | |||
5.6. Email Address and Phone Number ("e=" and "p=") . . . . . . 14 | 5.6. Email Address and Phone Number ("e=" and "p=") . . . . . . 14 | |||
5.7. Connection Data ("c=") . . . . . . . . . . . . . . . . . . 14 | 5.7. Connection Data ("c=") . . . . . . . . . . . . . . . . . . 14 | |||
5.8. Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 17 | 5.8. Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 17 | |||
5.9. Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 18 | 5.9. Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 18 | |||
5.10. Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . 19 | 5.10. Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . 19 | |||
5.11. Time Zones ("z=") . . . . . . . . . . . . . . . . . . . . 19 | 5.11. Time Zones ("z=") . . . . . . . . . . . . . . . . . . . . 19 | |||
5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . . 20 | 5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . . 20 | |||
5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 22 | 5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 22 | |||
5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 23 | 5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 23 | |||
6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . . 25 | 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 | |||
8.1. The "application/sdp" Media Type . . . . . . . . . . . . . 33 | 8.1. The "application/sdp" Media Type . . . . . . . . . . . . . 33 | |||
8.2. Registration of Parameters . . . . . . . . . . . . . . . . 35 | 8.2. Registration of Parameters . . . . . . . . . . . . . . . . 35 | |||
8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 35 | 8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 35 | |||
8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 35 | 8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 35 | |||
8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 36 | 8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 36 | |||
8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 36 | 8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 36 | |||
8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 38 | 8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 38 | |||
8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 38 | 8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 38 | |||
8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . . 38 | 8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . . 38 | |||
8.2.8. Registration Procedure . . . . . . . . . . . . . . . . 39 | 8.2.8. Registration Procedure . . . . . . . . . . . . . . . . 39 | |||
8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 39 | 8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 39 | |||
9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 39 | 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . . 44 | 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . . 44 | |||
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 | 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . . 45 | 12.1. Normative References . . . . . . . . . . . . . . . . . . . 45 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . . 46 | 12.2. Informative References . . . . . . . . . . . . . . . . . . 46 | |||
1. Introduction | 1. Introduction | |||
When initiating multimedia teleconferences, voice-over-IP calls, | When initiating multimedia teleconferences, voice-over-IP calls, | |||
streaming video, or other sessions, there is a requirement to convey | streaming video, or other sessions, there is a requirement to convey | |||
media details, transport addresses, and other session description | media details, transport addresses, and other session description | |||
metadata to the participants. | metadata to the participants. | |||
skipping to change at page 8, line 38 ¶ | skipping to change at page 8, line 38 ¶ | |||
When many session descriptions are being distributed by SAP, or any | When many session descriptions are being distributed by SAP, or any | |||
other advertisement mechanism, it may be desirable to filter session | other advertisement mechanism, it may be desirable to filter session | |||
announcements that are of interest from those that are not. SDP | announcements that are of interest from those that are not. SDP | |||
supports a categorisation mechanism for sessions that is capable of | supports a categorisation mechanism for sessions that is capable of | |||
being automated (the "a=cat:" attribute; see Section 6). | being automated (the "a=cat:" attribute; see Section 6). | |||
4.6. Internationalisation | 4.6. Internationalisation | |||
The SDP specification recommends the use of the ISO 10646 character | The SDP specification recommends the use of the ISO 10646 character | |||
sets in the UTF-8 encoding [5] to allow many different languages to | set in the UTF-8 encoding [5] to allow many different languages to be | |||
be represented. However, to assist in compact representations, SDP | represented. However, to assist in compact representations, SDP also | |||
also allows other character sets such as ISO 8859-1 to be used when | allows other character sets such as ISO 8859-1 to be used when | |||
desired. Internationalisation only applies to free-text fields | desired. Internationalisation only applies to free-text fields | |||
(session name and background information), and not to SDP as a whole. | (session name and background information), and not to SDP as a whole. | |||
5. SDP Specification | 5. SDP Specification | |||
An SDP session description is denoted by the media type "application/ | An SDP session description is denoted by the media type "application/ | |||
sdp" (See Section 8). | sdp" (See Section 8). | |||
An SDP session description is entirely textual using the ISO 10646 | An SDP session description is entirely textual. SDP field names and | |||
character set in UTF-8 encoding. SDP field names and attribute names | attribute names use only the US-ASCII subset of UTF-8, but textual | |||
use only the US-ASCII subset of UTF-8, but textual fields and | fields and attribute values MAY use the full ISO 10646 character set | |||
attribute values MAY use the full ISO 10646 character set. Field and | in UTF-8 encoding, or some other character set defined by the | |||
attribute values that use the full UTF-8 character set are never | "a=charset:" attribute. Field and attribute values that use the full | |||
directly compared, hence there is no requirement for UTF-8 | UTF-8 character set are never directly compared, hence there is no | |||
normalisation. The textual form, as opposed to a binary encoding | requirement for UTF-8 normalisation. The textual form, as opposed to | |||
such as ASN.1 or XDR, was chosen to enhance portability, to enable a | a binary encoding such as ASN.1 or XDR, was chosen to enhance | |||
variety of transports to be used, and to allow flexible, text-based | portability, to enable a variety of transports to be used, and to | |||
toolkits to be used to generate and process session descriptions. | allow flexible, text-based toolkits to be used to generate and | |||
However, since SDP may be used in environments where the maximum | process session descriptions. However, since SDP may be used in | |||
permissible size of a session description is limited, the encoding is | environments where the maximum permissible size of a session | |||
deliberately compact. Also, since announcements may be transported | description is limited, the encoding is deliberately compact. Also, | |||
via very unreliable means or damaged by an intermediate caching | since announcements may be transported via very unreliable means or | |||
server, the encoding was designed with strict order and formatting | damaged by an intermediate caching server, the encoding was designed | |||
rules so that most errors would result in malformed session | with strict order and formatting rules so that most errors would | |||
announcements that could be detected easily and discarded. This also | result in malformed session announcements that could be detected | |||
allows rapid discarding of encrypted session announcements for which | easily and discarded. This also allows rapid discarding of encrypted | |||
a receiver does not have the correct key. | session announcements for which a receiver does not have the correct | |||
key. | ||||
An SDP session description consists of a number of lines of text of | An SDP session description consists of a number of lines of text of | |||
the form: | the form: | |||
<type>=<value> | <type>=<value> | |||
where <type> MUST be exactly one case-significant character and | where <type> MUST be exactly one case-significant character and | |||
<value> is structured text whose format depends on <type>. In | <value> is structured text whose format depends on <type>. In | |||
general, <value> is either a number of fields delimited by a single | general, <value> is either a number of fields delimited by a single | |||
space character or a free format string, and is case-significant | space character or a free format string, and is case-significant | |||
unless a specific field defines otherwise. Whitespace MUST NOT be | unless a specific field defines otherwise. Whitespace MUST NOT be | |||
used on either side of the "=" sign. | used on either side of the "=" sign. | |||
An SDP session description consists of a session-level section | An SDP session description consists of a session-level section | |||
followed by zero or more media-level sections. The session-level | followed by zero or more media-level sections. The session-level | |||
part starts with a "v=" line and continues to the first media-level | part starts with a "v=" line and continues to the first media-level | |||
section. Each media-level section starts with an "m=" line and | section (or the end of the whole description, whichever comes first). | |||
continues to the next media-level section or end of the whole session | Each media-level section starts with an "m=" line and continues to | |||
description. In general, session-level values are the default for | the next media-level section or the end of the whole session | |||
all media unless overridden by an equivalent media-level value. | description - whichever comes first. In general, session-level | |||
values are the default for all media unless overridden by an | ||||
equivalent media-level value. | ||||
Some lines in each description are REQUIRED and some are OPTIONAL, | Some lines in each description are REQUIRED and some are OPTIONAL, | |||
but all MUST appear in exactly the order given here (the fixed order | but all MUST appear in exactly the order given here (the fixed order | |||
greatly enhances error detection and allows for a simple parser). | greatly enhances error detection and allows for a simple parser). | |||
OPTIONAL items are marked with a "*". | OPTIONAL items are marked with a "*". | |||
Session description | Session description | |||
v= (protocol version) | v= (protocol version) | |||
o= (originator and session identifier) | o= (originator 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) | |||
c=* (connection information -- not required if included in | c=* (connection information -- not required if included in | |||
all media) | all media descriptions) | |||
b=* (zero or more bandwidth information lines) | b=* (zero or more bandwidth information lines) | |||
One or more time descriptions ("t=" and "r=" lines; see below) | One or more time descriptions ("t=" and "r=" lines; see below) | |||
z=* (time zone adjustments) | z=* (time zone adjustments) | |||
k=* (encryption key) | k=* (encryption key) | |||
a=* (zero or more session attribute lines) | a=* (zero or more session attribute lines) | |||
Zero or more media descriptions | Zero or more media descriptions | |||
Time description | Time description | |||
t= (time the session is active) | t= (time the session is active) | |||
r=* (zero or more repeat times) | r=* (zero or more repeat times) | |||
skipping to change at page 12, line 33 ¶ | skipping to change at page 12, line 33 ¶ | |||
it is RECOMMENDED that an NTP format timestamp is used. | it is RECOMMENDED that an NTP format timestamp is used. | |||
<nettype> is a text string giving the type of network. Initially | <nettype> is a text string giving the type of network. Initially | |||
"IN" is defined to have the meaning "Internet", but other values | "IN" is defined to have the meaning "Internet", but other values | |||
MAY be registered in the future (see Section 8). | MAY be registered in the future (see Section 8). | |||
<addrtype> is a text string giving the type of the address that | <addrtype> is a text string giving the type of the address that | |||
follows. Initially "IP4" and "IP6" are defined, but other values | follows. Initially "IP4" and "IP6" are defined, but other values | |||
MAY be registered in the future (see Section 8). | MAY be registered in the future (see Section 8). | |||
<unicast-address> is the address of the machine from which the | <unicast-address> is an address of the machine from which the | |||
session was created. For an address type of IP4, this is either | session was created. For an address type of IP4, this is either a | |||
the fully qualified domain name of the machine or the dotted- | fully qualified domain name of the machine or the dotted-decimal | |||
decimal representation of the IP version 4 address of the machine. | representation of an IP version 4 address of the machine. For an | |||
For an address type of IP6, this is either the fully qualified | address type of IP6, this is either a fully qualified domain name | |||
domain name of the machine or the compressed textual | of the machine or the compressed textual representation of an IP | |||
representation of the IP version 6 address of the machine. For | version 6 address of the machine. For both IP4 and IP6, the fully | |||
both IP4 and IP6, the fully qualified domain name is the form that | qualified domain name is the form that SHOULD be given unless this | |||
SHOULD be given unless this is unavailable, in which case the | is unavailable, in which case a globally unique address MAY be | |||
globally unique address MAY be substituted. A local IP address | substituted. A local IP address MUST NOT be used in any context | |||
MUST NOT be used in any context where the SDP description might | where the SDP description might leave the scope in which the | |||
leave the scope in which the address is meaningful (for example, a | address is meaningful (for example, a local address MUST NOT be | |||
local address MUST NOT be included in an application-level | included in an application-level referral that might leave the | |||
referral that might leave the scope). | scope). | |||
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. | |||
For privacy reasons, it is sometimes desirable to obfuscate the | For privacy reasons, it is sometimes desirable to obfuscate the | |||
username and IP address of the session originator. If this is a | username and IP address of the session originator. If this is a | |||
concern, an arbitrary <username> and private <unicast-address> MAY be | concern, an arbitrary <username> and private <unicast-address> MAY be | |||
chosen to populate the "o=" field, provided that these are selected | chosen to populate the "o=" field, provided that these are selected | |||
skipping to change at page 14, line 11 ¶ | skipping to change at page 14, line 11 ¶ | |||
session. This field is OPTIONAL, but if it is present it MUST be | session. This field is OPTIONAL, but if it is present it MUST be | |||
specified before the first media field. No more than one URI field | specified before the first media field. No more than one URI field | |||
is allowed per session description. | is allowed per session description. | |||
5.6. Email Address and Phone Number ("e=" and "p=") | 5.6. Email Address and Phone Number ("e=" and "p=") | |||
e=<email-address> | e=<email-address> | |||
p=<phone-number> | p=<phone-number> | |||
The "e=" and "p=" lines specify contact information for the person | The "e=" and "p=" lines specify contact information for the person | |||
responsible for the conference. This is not necessarily the same | responsible for the session. This is not necessarily the same person | |||
person that created the conference announcement. | that created the session description. | |||
Inclusion of an email address or phone number is OPTIONAL. Note that | Inclusion of an email address or phone number is OPTIONAL. Note that | |||
the previous version of SDP specified that either an email field or a | the previous version of SDP specified that either an email field or a | |||
phone field MUST be specified, but this was widely ignored. The | phone field MUST be specified, but this was widely ignored. The | |||
change brings the specification into line with common usage. | change brings the specification into line with common usage. | |||
If an email address or phone number is present, it MUST be specified | If an email address or phone number is present, it MUST be specified | |||
before the first media field. More than one email or phone field can | before the first media field. More than one email or phone field can | |||
be given for a session description. | be given for a session description. | |||
skipping to change at page 15, line 38 ¶ | skipping to change at page 15, line 38 ¶ | |||
the connection address contains the unicast IP address of the | the connection address contains the unicast IP address of the | |||
expected data source or data relay or data sink as determined by | expected data source or data relay or data sink as determined by | |||
additional attribute fields. It is not expected that unicast | additional attribute fields. It is not expected that unicast | |||
addresses will be given in a session description that is | addresses will be given in a session description that is | |||
communicated by a multicast announcement, though this is not | communicated by a multicast announcement, though this is not | |||
prohibited. | prohibited. | |||
o Sessions using an IPv4 multicast connection address MUST also have | o Sessions using an IPv4 multicast connection address MUST also have | |||
a time to live (TTL) value present in addition to the multicast | a time to live (TTL) value present in addition to the multicast | |||
address. The TTL and the address together define the scope with | address. The TTL and the address together define the scope with | |||
which multicast packets sent in this conference will be sent. TTL | which multicast packets sent in this session will be sent. TTL | |||
values MUST be in the range 0-255. Although the TTL MUST be | values MUST be in the range 0-255. Although the TTL MUST be | |||
specified, its use to scope multicast traffic is deprecated; | specified, its use to scope multicast traffic is deprecated; | |||
applications SHOULD use an administratively scoped address | applications SHOULD use an administratively scoped address | |||
instead. | instead. | |||
The TTL for the session is appended to the address using a slash as a | The TTL for the session is appended to the address using a slash as a | |||
separator. An example is: | separator. An example is: | |||
c=IN IP4 224.2.36.42/127 | c=IN IP4 224.2.36.42/127 | |||
skipping to change at page 19, line 23 ¶ | skipping to change at page 19, line 23 ¶ | |||
the first Monday, the <repeat interval> would be 1 week, the <active | the first Monday, the <repeat interval> would be 1 week, the <active | |||
duration> would be 1 hour, and the offsets would be zero and 25 | duration> would be 1 hour, and the offsets would be zero and 25 | |||
hours. The corresponding "t=" field stop time would be the NTP | 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 might | default, all fields are in seconds, so the "r=" and "t=" fields might | |||
be the following: | be the following: | |||
t=3034423619 3042462419 | t=3034423619 3042462419 | |||
r=604800 3600 0 90000 | r=604800 3600 0 90000 | |||
To make description more compact, times may also be given in units of | To make the description more compact, times may also be given in | |||
days, hours, or minutes. The syntax for these is a number | units 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 - hours (3600 seconds) | h - hours (3600 seconds) | |||
m - minutes (60 seconds) | m - minutes (60 seconds) | |||
s - seconds (allowed for completeness) | s - seconds (allowed for completeness) | |||
Thus, the above session announcement could also have been written: | Thus, the above session announcement could also have been written: | |||
skipping to change at page 20, line 25 ¶ | skipping to change at page 20, line 25 ¶ | |||
z=2882844526 -1h 2898848070 0 | z=2882844526 -1h 2898848070 0 | |||
This specifies that at time 2882844526, the time base by which the | This specifies that at time 2882844526, the time base by which the | |||
session's repeat times are calculated is shifted back by 1 hour, and | session's repeat times are calculated is shifted back by 1 hour, and | |||
that at time 2898848070, the session's original time base is | that at time 2898848070, the session's original time base is | |||
restored. Adjustments are always relative to the specified start | restored. Adjustments are always relative to the specified start | |||
time -- they are not cumulative. Adjustments apply to all "t=" and | time -- they are not cumulative. Adjustments apply to all "t=" and | |||
"r=" lines in a session description. | "r=" lines in a session description. | |||
If a session is likely to last several years, it is expected that the | If a session is likely to last several years, it is expected that the | |||
session announcement will be modified periodically rather than | session description will be modified periodically rather than | |||
transmit several years' worth of adjustments in one session | transmit several years' worth of adjustments in one session | |||
announcement. | description. | |||
5.12. Encryption Keys ("k=") | 5.12. Encryption Keys ("k=") | |||
k=<method> | k=<method> | |||
k=<method>:<encryption key> | k=<method>:<encryption key> | |||
If transported over a secure and trusted channel, the Session | If transported over a secure and trusted channel, the Session | |||
Description Protocol MAY be used to convey encryption keys. A simple | Description Protocol MAY be used to convey encryption keys. A simple | |||
mechanism for key exchange is provided by the key field ("k="), | mechanism for key exchange is provided by the key field ("k="), | |||
although this is primarily supported for compatibility with older | although this is primarily supported for compatibility with older | |||
skipping to change at page 22, line 19 ¶ | skipping to change at page 22, line 19 ¶ | |||
Attributes are the primary means for extending SDP. Attributes may | Attributes are the primary means for extending SDP. Attributes may | |||
be defined to be used as "session-level" attributes, "media-level" | be defined to be used as "session-level" attributes, "media-level" | |||
attributes, or both. | attributes, or both. | |||
A media description may have any number of attributes ("a=" fields) | A media description may have any number of attributes ("a=" fields) | |||
that are media specific. These are referred to as "media-level" | that are media specific. These are referred to as "media-level" | |||
attributes and add information about the media stream. Attribute | attributes and add information about the media stream. Attribute | |||
fields can also be added before the first media field; these | fields can also be added before the first media field; these | |||
"session-level" attributes convey additional information that applies | "session-level" attributes convey additional information that applies | |||
to the conference as a whole rather than to individual media. | to the session as a whole rather than to individual media. | |||
Attribute fields may be of two forms: | Attribute fields may be of two forms: | |||
o A property attribute is simply of the form "a=<flag>". These are | o A property attribute is simply of the form "a=<flag>". These are | |||
binary attributes, and the presence of the attribute conveys that | binary attributes, and the presence of the attribute conveys that | |||
the attribute is a property of the session. An example might be | the attribute is a property of the session. An example might be | |||
"a=recvonly". | "a=recvonly". | |||
o A value attribute is of the form "a=<attribute>:<value>". For | o A value attribute is of the form "a=<attribute>:<value>". For | |||
example, a whiteboard could have the value attribute "a=orient: | example, a whiteboard could have the value attribute "a=orient: | |||
skipping to change at page 30, line 19 ¶ | skipping to change at page 30, line 19 ¶ | |||
fields. | fields. | |||
a=sdplang:<language tag> | a=sdplang:<language tag> | |||
This can be a session-level attribute or a media-level | This can be a session-level attribute or a media-level | |||
attribute. As a session-level attribute, it specifies the | attribute. As a session-level attribute, it specifies the | |||
language for the session description. As a media-level | language for the session description. As a media-level | |||
attribute, it specifies the language for any media-level SDP | attribute, it specifies the language for any media-level SDP | |||
information field associated with that media. Multiple sdplang | information field associated with that media. Multiple sdplang | |||
attributes can be provided either at session or media level if | attributes can be provided either at session or media level if | |||
multiple languages in the session description or media use | the session description or media use multiple languages. | |||
multiple languages, in which case the order of the attributes | ||||
indicates the order of importance of the various languages in | ||||
the session or media from most important to least important. | ||||
In general, sending session descriptions consisting of multiple | In general, sending session descriptions consisting of multiple | |||
languages is discouraged. Instead, multiple descriptions | languages is discouraged. Instead, multiple descriptions | |||
SHOULD be sent describing the session, one in each language. | SHOULD be sent describing the session, one in each language. | |||
However, this is not possible with all transport mechanisms, | However, this is not possible with all transport mechanisms, | |||
and so multiple sdplang attributes are allowed although NOT | and so multiple sdplang attributes are allowed although NOT | |||
RECOMMENDED. | RECOMMENDED. | |||
The "sdplang" attribute value must be a single RFC 3066 | The "sdplang" attribute value must be a single RFC 4646 | |||
language tag in US-ASCII [9]. It is not dependent on the | language tag in US-ASCII [9]. It is not dependent on the | |||
charset attribute. An "sdplang" attribute SHOULD be specified | charset attribute. An "sdplang" attribute SHOULD be specified | |||
when a session is of sufficient scope to cross geographic | when a session is distributed with sufficient scope to cross | |||
boundaries where the language of recipients cannot be assumed, | geographic boundaries, where the language of recipients cannot | |||
or where the session is in a different language from the | be assumed, or where the session is in a different language | |||
locally assumed norm. | from the locally assumed norm. | |||
a=lang:<language tag> | a=lang:<language tag> | |||
This can be a session-level attribute or a media-level | This can be a session-level attribute or a media-level | |||
attribute. As a session-level attribute, it specifies the | attribute. As a session-level attribute, it specifies the | |||
default language for the session being described. As a media- | default language for the session being described. As a media- | |||
level attribute, it specifies the language for that media, | level attribute, it specifies the language for that media, | |||
overriding any session-level language specified. Multiple lang | overriding any session-level language specified. Multiple lang | |||
attributes can be provided either at session or media level if | attributes can be provided either at session or media level if | |||
the session description or media use multiple languages, in | the session or media use multiple languages, in which case the | |||
which case the order of the attributes indicates the order of | order of the attributes indicates the order of importance of | |||
importance of the various languages in the session or media | the various languages in the session or media, from most | |||
from most important to least important. | important to least important. | |||
The "lang" attribute value must be a single RFC 3066 language | The "lang" attribute value must be a single RFC 4646 language | |||
tag in US-ASCII [9]. It is not dependent on the charset | tag in US-ASCII [9]. It is not dependent on the charset | |||
attribute. A "lang" attribute SHOULD be specified when a | attribute. A "lang" attribute SHOULD be specified when a | |||
session is of sufficient scope to cross geographic boundaries | session is of sufficient scope to cross geographic boundaries | |||
where the language of recipients cannot be assumed, or where | where the language of recipients cannot be assumed, or where | |||
the session is in a different language from the locally assumed | the session is in a different language from the locally assumed | |||
norm. | norm. | |||
a=framerate:<frame rate> | a=framerate:<frame rate> | |||
This gives the maximum video frame rate in frames/sec. It is | This gives the maximum video frame rate in frames/sec. It is | |||
skipping to change at page 32, line 17 ¶ | skipping to change at page 32, line 11 ¶ | |||
SDP is frequently used with the Session Initiation Protocol [15] | SDP is frequently used with the Session Initiation Protocol [15] | |||
using the offer/answer model [17] to agree on parameters for unicast | using the offer/answer model [17] to agree on parameters for unicast | |||
sessions. When used in this manner, the security considerations of | sessions. When used in this manner, the security considerations of | |||
those protocols apply. | those protocols apply. | |||
SDP is a session description format that describes multimedia | SDP is a session description format that describes multimedia | |||
sessions. Entities receiving and acting upon an SDP message SHOULD | sessions. Entities receiving and acting upon an SDP message SHOULD | |||
be aware that a session description cannot be trusted unless it has | be aware that a session description cannot be trusted unless it has | |||
been obtained by an authenticated transport protocol from a known and | been obtained by an authenticated transport protocol from a known and | |||
trusted source. Many different transport protocols may be used to | trusted source. Many different transport protocols may be used to | |||
distribute session description, and the nature of the authentication | distribute session descriptions, and the nature of the authentication | |||
will differ from transport to transport. For some transports, | will differ from transport to transport. For some transports, | |||
security features are often not deployed. In case a session | security features are often not deployed. In case a session | |||
description has not been obtained in a trusted manner, the endpoint | description has not been obtained in a trusted manner, the endpoint | |||
SHOULD exercise care because, among other attacks, the media sessions | SHOULD exercise care because, among other attacks, the media sessions | |||
received may not be the intended ones, the destination where media is | received may not be the intended ones, the destination where media is | |||
sent to may not be the expected one, any of the parameters of the | sent to may not be the expected one, any of the parameters of the | |||
session may be incorrect, or the media security may be compromised. | session may be incorrect, or the media security may be compromised. | |||
It is up to the endpoint to make a sensible decision taking into | It is up to the endpoint to make a sensible decision taking into | |||
account the security risks of the application and the user | account the security risks of the application and the user | |||
preferences and may decide to ask the user whether or not to accept | preferences and may decide to ask the user whether or not to accept | |||
skipping to change at page 44, line 45 ¶ | skipping to change at page 44, line 45 ¶ | |||
; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 4234 | ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 4234 | |||
; URI-reference: from RFC 3986 | ; URI-reference: from RFC 3986 | |||
; addr-spec: from RFC 2822 | ; addr-spec: from RFC 2822 | |||
10. Summary of Changes from RFC 4566 | 10. Summary of Changes from RFC 4566 | |||
The ABNF rule for IP6-address has been corrected. As a result, the | The ABNF rule for IP6-address has been corrected. As a result, the | |||
ABNF rule for IP6-multicast has changed, and the (now unused) rules | ABNF rule for IP6-multicast has changed, and the (now unused) rules | |||
for hexpart, hexseq, and hex4 have been removed. | for hexpart, hexseq, and hex4 have been removed. | |||
The following purely editorial changes have been made: | ||||
o Section 4.6: fix typo in first sentence: "sets" -> "set" | ||||
o Section 5: clarify second paragraph (SDP field and attribute names | ||||
use the US-ASCII subset of UTF-8). | ||||
o Section 5: clarify that an SDP session description can contain | ||||
only a session-level section, with no media-level section, and | ||||
that a media-level section can be terminated by the end of the | ||||
session description, and not always by another media-level | ||||
section. | ||||
o Section 5: clearly differentiate "media" and "media description" | ||||
in the description of the "c=" line. | ||||
o Section 5.2: when describing the <unicast-address> field, clarify | ||||
that "an" address of the machine is used, rather than "the" | ||||
address of the machine, since IP addresses identify interfaces, | ||||
not hosts. | ||||
o Section 5.6: use "session" rather than "conference" | ||||
o Section 5.10: fix typo: "To make description" -> "To make the | ||||
description" | ||||
o Section 5.11: use "session description" rather than "session | ||||
announcement" in the final paragraph | ||||
o Section 7: fix typo: "distribute session description" -> | ||||
"distribute session descriptions" | ||||
Clarify the use of multiple "a=sdplang:" and "a=lang:" attributes, | ||||
and when "a=sdplang:" should be used. | ||||
11. Acknowledgements | 11. Acknowledgements | |||
Many people in the IETF Multiparty Multimedia Session Control | Many people in the IETF Multiparty Multimedia Session Control | |||
(MMUSIC) working group have made comments and suggestions | (MMUSIC) working group have made comments and suggestions | |||
contributing to this document. In particular, we would like to thank | contributing to this document. In particular, we would like to thank | |||
Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross | Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross | |||
Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna, | Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna, | |||
Jonathan Lennox, Keith Drage, Sean Olson, Bernie Hoeneisen, Jonathan | Jonathan Lennox, Keith Drage, Sean Olson, Bernie Hoeneisen, Jonathan | |||
Rosenberg, John Elwell, Flemming Andreasen, Jon Peterson, and Spencer | Rosenberg, John Elwell, Flemming Andreasen, Jon Peterson, Spencer | |||
Dawkins. | Dawkins, and Alfred Hoenes. | |||
12. References | 12. References | |||
12.1. Normative References | 12.1. Normative References | |||
[1] Mockapetris, P., "Domain names - concepts and facilities", | [1] Mockapetris, P., "Domain names - concepts and facilities", | |||
STD 13, RFC 1034, November 1987. | STD 13, RFC 1034, November 1987. | |||
[2] Mockapetris, P., "Domain names - implementation and | [2] Mockapetris, P., "Domain names - implementation and | |||
specification", STD 13, RFC 1035, November 1987. | specification", STD 13, RFC 1035, November 1987. | |||
skipping to change at page 45, line 38 ¶ | skipping to change at page 46, line 25 ¶ | |||
Protocol", RFC 2327, April 1998. | Protocol", RFC 2327, April 1998. | |||
[7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | [7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | |||
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, | Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, | |||
January 2005. | January 2005. | |||
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA | [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA | |||
Considerations Section in RFCs", BCP 26, RFC 2434, | Considerations Section in RFCs", BCP 26, RFC 2434, | |||
October 1998. | October 1998. | |||
[9] Alvestrand, H., "Tags for the Identification of Languages", | [9] Phillips, A. and M. Davis, "Tags for Identifying Languages", | |||
BCP 47, RFC 3066, January 2001. | BCP 47, RFC 4646, September 2006. | |||
[10] Faltstrom, P., Hoffman, P., and A. Costello, | [10] Faltstrom, P., Hoffman, P., and A. Costello, | |||
"Internationalizing Domain Names in Applications (IDNA)", | "Internationalizing Domain Names in Applications (IDNA)", | |||
RFC 3490, March 2003. | RFC 3490, March 2003. | |||
[11] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", | [11] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", | |||
RFC 3548, July 2003. | RFC 3548, July 2003. | |||
[12] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session | [12] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session | |||
Description Protocol", RFC 4566, July 2006. | Description Protocol", RFC 4566, July 2006. | |||
skipping to change at page 48, line 4 ¶ | skipping to change at line 2242 ¶ | |||
EMail: van@packetdesign.com | EMail: van@packetdesign.com | |||
Colin Perkins | Colin Perkins | |||
University of Glasgow | University of Glasgow | |||
Department of Computing Science | Department of Computing Science | |||
17 Lilybank Gardens | 17 Lilybank Gardens | |||
Glasgow G12 8QQ | Glasgow G12 8QQ | |||
UK | UK | |||
EMail: csp@csperkins.org | EMail: csp@csperkins.org | |||
Full Copyright Statement | ||||
Copyright (C) The IETF Trust (2008). | ||||
This document is subject to the rights, licenses and restrictions | ||||
contained in BCP 78, and except as set forth therein, the authors | ||||
retain all their rights. | ||||
This document and the information contained herein are provided on an | ||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | ||||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | ||||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | ||||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
Intellectual Property | ||||
The IETF takes no position regarding the validity or scope of any | ||||
Intellectual Property Rights or other rights that might be claimed to | ||||
pertain to the implementation or use of the technology described in | ||||
this document or the extent to which any license under such rights | ||||
might or might not be available; nor does it represent that it has | ||||
made any independent effort to identify any such rights. Information | ||||
on the procedures with respect to rights in RFC documents can be | ||||
found in BCP 78 and BCP 79. | ||||
Copies of IPR disclosures made to the IETF Secretariat and any | ||||
assurances of licenses to be made available, or the result of an | ||||
attempt made to obtain a general license or permission for the use of | ||||
such proprietary rights by implementers or users of this | ||||
specification can be obtained from the IETF on-line IPR repository at | ||||
http://www.ietf.org/ipr. | ||||
The IETF invites any interested party to bring to its attention any | ||||
copyrights, patents or patent applications, or other proprietary | ||||
rights that may cover technology that may be required to implement | ||||
this standard. Please address the information to the IETF at | ||||
ietf-ipr@ietf.org. | ||||
Acknowledgement | ||||
Funding for the RFC Editor function is provided by the IETF | ||||
Administrative Support Activity (IASA). | ||||
End of changes. 29 change blocks. | ||||
79 lines changed or deleted | 129 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/ |