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 32 skipping to change at page 12, line 32
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 2240
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.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/