draft-ietf-mmusic-rfc4566bis-10.txt   draft-ietf-mmusic-rfc4566bis-11.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 PARC Intended status: Standards Track PARC
Expires: September 18, 2014 C. Perkins Expires: March 19, 2015 C.S. Perkins
University of Glasgow University of Glasgow
A. Begen A. Begen
Cisco Cisco
March 17, 2014 September 15, 2014
SDP: Session Description Protocol SDP: Session Description Protocol
draft-ietf-mmusic-rfc4566bis-10 draft-ietf-mmusic-rfc4566bis-11
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. This document obsoletes RFC 4566. multimedia session initiation. This document obsoletes RFC 4566.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 18, 2014. This Internet-Draft will expire on March 19, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4
3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . . 4 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . . 4
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 4 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 4
3.2. Streaming Media . . . . . . . . . . . . . . . . . . . . . 4 3.2. Streaming Media . . . . . . . . . . . . . . . . . . . . . 4
3.3. Email and the World Wide Web . . . . . . . . . . . . . . 5 3.3. Email and the World Wide Web . . . . . . . . . . . . . . 4
3.4. Multicast Session Announcement . . . . . . . . . . . . . 5 3.4. Multicast Session Announcement . . . . . . . . . . . . . 5
4. Requirements and Recommendations . . . . . . . . . . . . . . 5 4. Requirements and Recommendations . . . . . . . . . . . . . . 5
4.1. Media and Transport Information . . . . . . . . . . . . . 6 4.1. Media and Transport Information . . . . . . . . . . . . . 6
4.2. Timing Information . . . . . . . . . . . . . . . . . . . 7 4.2. Timing Information . . . . . . . . . . . . . . . . . . . 7
4.3. Private Sessions . . . . . . . . . . . . . . . . . . . . 7 4.3. Private Sessions . . . . . . . . . . . . . . . . . . . . 7
4.4. Obtaining Further Information about a Session . . . . . . 7 4.4. Obtaining Further Information about a Session . . . . . . 7
4.5. Categorisation . . . . . . . . . . . . . . . . . . . . . 8 4.5. Categorisation . . . . . . . . . . . . . . . . . . . . . 7
4.6. Internationalisation . . . . . . . . . . . . . . . . . . 8 4.6. Internationalisation . . . . . . . . . . . . . . . . . . 8
5. SDP Specification . . . . . . . . . . . . . . . . . . . . . . 8 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Protocol Version ("v=") . . . . . . . . . . . . . . . . . 11 5.1. Protocol Version ("v=") . . . . . . . . . . . . . . . . . 11
5.2. Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 12 5.2. Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 13 5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 12
5.4. Session Information ("i=") . . . . . . . . . . . . . . . 13 5.4. Session Information ("i=") . . . . . . . . . . . . . . . 13
5.5. URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . 14 5.5. URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . 13
5.6. Email Address and Phone Number ("e=" and "p=") . . . . . 14 5.6. Email Address and Phone Number ("e=" and "p=") . . . . . 13
5.7. Connection Data ("c=") . . . . . . . . . . . . . . . . . 15 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=") . . . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . . 33 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
8.1. The "application/sdp" Media Type . . . . . . . . . . . . 35 8.1. The "application/sdp" Media Type . . . . . . . . . . . . 35
8.2. Registration of Parameters . . . . . . . . . . . . . . . 37 8.2. Registration of Parameters . . . . . . . . . . . . . . . 36
8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 37 8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 36
8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 37 8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 36
8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 38 8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 37
8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 38 8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 38
8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 40 8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 39
8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 40 8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 39
8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 40 8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 40
8.2.8. Registration Procedure . . . . . . . . . . . . . . . 41 8.2.8. Registration Procedure . . . . . . . . . . . . . . . 40
8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 41 8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 40
9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 41 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 41
10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 46 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 46
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
12.1. Normative References . . . . . . . . . . . . . . . . . . 48 12.1. Normative References . . . . . . . . . . . . . . . . . . 47
12.2. Informative References . . . . . . . . . . . . . . . . . 48 12.2. Informative References . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
1. Introduction 1. Introduction
When initiating multimedia teleconferences, voice-over-IP calls, When initiating multimedia teleconferences, voice-over-IP calls,
streaming video, or other sessions, there is a requirement to convey streaming video, or other sessions, there is a requirement to convey
media details, transport addresses, and other session description media details, transport addresses, and other session description
metadata to the participants. metadata to the participants.
SDP provides a standard representation for such information, SDP provides a standard representation for such information,
irrespective of how that information is transported. SDP is purely a irrespective of how that information is transported. SDP is purely a
skipping to change at page 8, line 51 skipping to change at page 8, line 48
damaged by an intermediate caching server, the encoding was designed damaged by an intermediate caching server, the encoding was designed
with strict order and formatting rules so that most errors would with strict order and formatting rules so that most errors would
result in malformed session announcements that could be detected result in malformed session announcements that could be detected
easily and discarded. This also allows rapid discarding of encrypted easily and discarded. This also allows rapid discarding of encrypted
session announcements for which a receiver does not have the correct session announcements for which a receiver does not have the correct
key. key.
An SDP session description consists of a number of lines of text of 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
skipping to change at page 11, line 45 skipping to change at page 11, line 22
"e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply "e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply
with [RFC1034], [RFC1035]. Internationalised domain names (IDNs) with [RFC1034], [RFC1035]. Internationalised domain names (IDNs)
MUST be represented using the ASCII Compatible Encoding (ACE) form MUST be represented using the ASCII Compatible Encoding (ACE) form
defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or
any other encoding (this requirement is for compatibility with any other encoding (this requirement is for compatibility with
[RFC4566] and other early SDP-related standards, which predate the [RFC4566] and other early SDP-related standards, which predate the
development of internationalised domain names). development of internationalised domain names).
5.1. Protocol Version ("v=") 5.1. Protocol Version ("v=")
v=0 v=0
The "v=" field gives the version of the Session Description Protocol. The "v=" field gives the version of the Session Description Protocol.
This memo defines version 0. There is no minor version number. This memo defines version 0. There is no minor version number.
5.2. Origin ("o=") 5.2. Origin ("o=")
o=<username> <sess-id> <sess-version> <nettype> <addrtype> o=<username> <sess-id> <sess-version> <nettype> <addrtype>
<unicast-address> <unicast-address>
The "o=" field gives the originator of the session (her username and The "o=" field gives the originator of the session (her username and
the address of the user's host) plus a session identifier and version the address of the user's host) plus a session identifier and version
number: number:
<username> is the user's login on the originating host, or it is "-" <username> is the user's login on the originating host, or it is "-"
if the originating host does not support the concept of user IDs. if the originating host does not support the concept of user IDs.
The <username> MUST NOT contain spaces. The <username> MUST NOT contain spaces.
<sess-id> is a numeric string such that the tuple of <username>, <sess-id> is a numeric string such that the tuple of <username>,
skipping to change at page 13, line 18 skipping to change at page 12, line 47
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
in a manner that does not affect the global uniqueness of the field. in a manner that does not affect the global uniqueness of the field.
5.3. Session Name ("s=") 5.3. Session Name ("s=")
s=<session name> s=<session name>
The "s=" field is the textual session name. There MUST be one and The "s=" field is the textual session name. There MUST be one and
only one "s=" field per session description. The "s=" field MUST NOT only one "s=" field per session description. The "s=" field MUST NOT
be empty and SHOULD contain ISO 10646 characters (but see also the be empty and SHOULD contain ISO 10646 characters (but see also the
"a=charset" attribute). If a session has no meaningful name, the "a=charset" attribute). If a session has no meaningful name, the
value "s= " SHOULD be used (i.e., a single space as the session value "s= " SHOULD be used (i.e., a single space as the session
name). name).
5.4. Session Information ("i=") 5.4. Session Information ("i=")
i=<session description> i=<session description>
The "i=" field provides textual information about the session. There The "i=" field provides textual information about the session. There
MUST be at most one session-level "i=" field per session description, MUST be at most one session-level "i=" field per session description,
and at most one "i=" field per media. If the "a=charset" attribute and at most one "i=" field per media. If the "a=charset" attribute
is present, it specifies the character set used in the "i=" field. is present, it specifies the character set used in the "i=" field.
If the "a=charset" attribute is not present, the "i=" field MUST If the "a=charset" attribute is not present, the "i=" field MUST
contain ISO 10646 characters in UTF-8 encoding. contain ISO 10646 characters in UTF-8 encoding.
A single "i=" field MAY also be used for each media definition. In A single "i=" field MAY also be used for each media definition. In
media definitions, "i=" fields are primarily intended for labelling media definitions, "i=" fields are primarily intended for labelling
skipping to change at page 14, line 7 skipping to change at page 13, line 32
single session has more than one distinct media stream of the same single session has more than one distinct media stream of the same
media type. An example would be two different whiteboards, one for media type. An example would be two different whiteboards, one for
slides and one for feedback and questions. slides and one for feedback and questions.
The "i=" field is intended to provide a free-form human-readable The "i=" field is intended to provide a free-form human-readable
description of the session or the purpose of a media stream. It is description of the session or the purpose of a media stream. It is
not suitable for parsing by automata. not suitable for parsing by automata.
5.5. URI ("u=") 5.5. URI ("u=")
u=<uri> u=<uri>
A URI is a Uniform Resource Identifier as used by WWW clients A URI is a Uniform Resource Identifier as used by WWW clients
[RFC3986]. The URI should be a pointer to additional information [RFC3986]. The URI should be a pointer to additional information
about the session. This field is OPTIONAL, but if it is present it about the session. This field is OPTIONAL, but if it is present it
MUST be specified before the first media field. No more than one URI MUST be specified before the first media field. No more than one URI
field is allowed per session description. field 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 session. This is not necessarily the same person responsible for the session. This is not necessarily the same person
that created the session description. 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.
Phone numbers SHOULD be given in the form of an international public Phone numbers SHOULD be given in the form of an international public
telecommunication number (see ITU-T Recommendation E.164) preceded by telecommunication number (see ITU-T Recommendation E.164) preceded by
a "+". Spaces and hyphens may be used to split up a phone field to a "+". Spaces and hyphens may be used to split up a phone field to
aid readability if desired. For example: aid readability if desired. For example:
p=+1 617 555-6011 p=+1 617 555-6011
Both email addresses and phone numbers can have an OPTIONAL free text Both email addresses and phone numbers can have an OPTIONAL free text
string associated with them, normally giving the name of the person string associated with them, normally giving the name of the person
who may be contacted. This MUST be enclosed in parentheses if it is who may be contacted. This MUST be enclosed in parentheses if it is
present. For example: present. For example:
e=j.doe@example.com (Jane Doe) e=j.doe@example.com (Jane Doe)
The alternative [RFC5322] name quoting convention is also allowed for The alternative [RFC5322] name quoting convention is also allowed for
both email addresses and phone numbers. For example: both email addresses and phone numbers. For example:
e=Jane Doe <j.doe@example.com> e=Jane Doe <j.doe@example.com>
The free text string SHOULD be in the ISO-10646 character set with The free text string SHOULD be in the ISO-10646 character set with
UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if
the appropriate session-level "a=charset" attribute is set. the appropriate session-level "a=charset" attribute is set.
5.7. Connection Data ("c=") 5.7. Connection Data ("c=")
c=<nettype> <addrtype> <connection-address> c=<nettype> <addrtype> <connection-address>
The "c=" field contains connection data. The "c=" field contains connection data.
A session description MUST contain either at least one "c=" field in A session description MUST contain either at least one "c=" field in
each media description or a single "c=" field at the session level. each media description or a single "c=" field at the session level.
It MAY contain a single session-level "c=" field and additional "c=" It MAY contain a single session-level "c=" field and additional "c="
field(s) per media description, in which case the per-media values field(s) per media description, in which case the per-media values
override the session-level settings for the respective media. override the session-level settings for the respective media.
The first sub-field ("<nettype>") is the network type, which is a The first sub-field ("<nettype>") is the network type, which is a
skipping to change at page 16, line 10 skipping to change at page 15, line 43
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 session 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 233.252.0.1/127 c=IN IP4 233.252.0.1/127
IP6 multicast does not use TTL scoping, and hence the TTL value MUST IP6 multicast does not use TTL scoping, and hence the TTL value MUST
NOT be present for IP6 multicast. It is expected that IP6 scoped NOT be present for IP6 multicast. It is expected that IP6 scoped
addresses will be used to limit the scope of conferences. addresses will be used to limit the scope of conferences.
Hierarchical or layered encoding schemes are data streams where the Hierarchical or layered encoding schemes are data streams where the
encoding from a single media source is split into a number of layers. encoding from a single media source is split into a number of layers.
The receiver can choose the desired quality (and hence bandwidth) by The receiver can choose the desired quality (and hence bandwidth) by
only subscribing to a subset of these layers. Such layered encodings only subscribing to a subset of these layers. Such layered encodings
are normally transmitted in multiple multicast groups to allow are normally transmitted in multiple multicast groups to allow
multicast pruning. This technique keeps unwanted traffic from sites multicast pruning. This technique keeps unwanted traffic from sites
only requiring certain levels of the hierarchy. For applications only requiring certain levels of the hierarchy. For applications
requiring multiple multicast groups, we allow the following notation requiring multiple multicast groups, we allow the following notation
to be used for the connection address: to be used for the connection address:
<base multicast address>[/<ttl>]/<number of addresses> <base multicast address>[/<ttl>]/<number of addresses>
If the number of addresses is not given, it is assumed to be one. If the number of addresses is not given, it is assumed to be one.
Multicast addresses so assigned are contiguously allocated above the Multicast addresses so assigned are contiguously allocated above the
base address, so that, for example: base address, so that, for example:
c=IN IP4 233.252.0.1/127/3 c=IN IP4 233.252.0.1/127/3
would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3 would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3
are to be used at a TTL of 127. This is semantically identical to are to be used at a TTL of 127. This is semantically identical to
including multiple "c=" lines in a media description: including multiple "c=" lines in a media description:
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
c=IN IP4 233.252.0.2/127 c=IN IP4 233.252.0.2/127
c=IN IP4 233.252.0.3/127 c=IN IP4 233.252.0.3/127
Similarly, an IP6 example would be: Similarly, an IP6 example would be:
c=IN IP6 FF15::101/3 c=IN IP6 FF15::101/3
which is semantically equivalent to: which is semantically equivalent to:
c=IN IP6 FF15::101 c=IN IP6 FF15::101
c=IN IP6 FF15::102 c=IN IP6 FF15::102
c=IN IP6 FF15::103 c=IN IP6 FF15::103
(remembering that the TTL field is not present in IP6 multicast). (remembering that the TTL field is not present in IP6 multicast).
Multiple addresses or "c=" lines MAY be specified on a per-media Multiple addresses or "c=" lines MAY be specified on a per-media
basis only if they provide multicast addresses for different layers basis only if they provide multicast addresses for different layers
in a hierarchical or layered encoding scheme. They MUST NOT be in a hierarchical or layered encoding scheme. They MUST NOT be
specified for a session-level "c=" field. specified for a session-level "c=" field.
The slash notation for multiple addresses described above MUST NOT be The slash notation for multiple addresses described above MUST NOT be
used for IP unicast addresses. used for IP unicast addresses.
5.8. Bandwidth ("b=") 5.8. Bandwidth ("b=")
b=<bwtype>:<bandwidth> b=<bwtype>:<bandwidth>
This OPTIONAL field denotes the proposed bandwidth to be used by the This OPTIONAL field denotes the proposed bandwidth to be used by the
session or media. The <bwtype> is an alphanumeric modifier giving session or media. The <bwtype> is an alphanumeric modifier giving
the meaning of the <bandwidth> figure. Two values are defined in the meaning of the <bandwidth> figure. Two values are defined in
this specification, but other values MAY be registered in the future this specification, but other values MAY be registered in the future
(see Section 8 and [RFC3556], [RFC3890]): (see Section 8 and [RFC3556], [RFC3890]):
CT If the bandwidth of a session or media in a session is different CT If the bandwidth of a session or media in a session is different
from the bandwidth implicit from the scope, a "b=CT:..." line from the bandwidth implicit from the scope, a "b=CT:..." line
SHOULD be supplied for the session giving the proposed upper limit SHOULD be supplied for the session giving the proposed upper limit
skipping to change at page 17, line 49 skipping to change at page 17, line 39
gives the RTP "session bandwidth" as defined in Section 6.2 of gives the RTP "session bandwidth" as defined in Section 6.2 of
[RFC3550]. [RFC3550].
Note that CT gives a total bandwidth figure for all the media at all Note that CT gives a total bandwidth figure for all the media at all
sites. AS gives a bandwidth figure for a single media at a single sites. AS gives a bandwidth figure for a single media at a single
site, although there may be many sites sending simultaneously. site, although there may be many sites sending simultaneously.
A prefix "X-" is defined for <bwtype> names. This is intended for A prefix "X-" is defined for <bwtype> names. This is intended for
experimental purposes only. For example: experimental purposes only. For example:
b=X-YZ:128 b=X-YZ:128
Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers
SHOULD be registered with IANA in the standard namespace. SDP SHOULD be registered with IANA in the standard namespace. SDP
parsers MUST ignore bandwidth fields with unknown modifiers. parsers MUST ignore bandwidth fields with unknown modifiers.
Modifiers MUST be alphanumeric and, although no length limit is Modifiers MUST be alphanumeric and, although no length limit is
given, it is recommended that they be short. given, it is recommended that they be short.
The <bandwidth> is interpreted as kilobits per second by default. The <bandwidth> is interpreted as kilobits per second by default.
The definition of a new <bwtype> modifier MAY specify that the The definition of a new <bwtype> modifier MAY specify that the
bandwidth is to be interpreted in some alternative unit (the "CT" and bandwidth is to be interpreted in some alternative unit (the "CT" and
"AS" modifiers defined in this memo use the default units). "AS" modifiers defined in this memo use the default units).
5.9. Timing ("t=") 5.9. Timing ("t=")
t=<start-time> <stop-time> t=<start-time> <stop-time>
The "t=" lines specify the start and stop times for a session. The "t=" lines specify the start and stop times for a session.
Multiple "t=" lines MAY be used if a session is active at multiple Multiple "t=" lines MAY be used if a session is active at multiple
irregularly spaced times; each additional "t=" line specifies an irregularly spaced times; each additional "t=" line specifies an
additional period of time for which the session will be active. If additional period of time for which the session will be active. If
the session is active at regular times, an "r=" line (see below) the session is active at regular times, an "r=" line (see below)
should be used in addition to, and following, a "t=" line -- in which should be used in addition to, and following, a "t=" line -- in which
case the "t=" line specifies the start and stop times of the repeat case the "t=" line specifies the start and stop times of the repeat
sequence. sequence.
skipping to change at page 19, line 13 skipping to change at page 19, line 7
other than this is required, an end-time SHOULD be given and modified other than this is required, an end-time SHOULD be given and modified
as appropriate when new information becomes available about when the as appropriate when new information becomes available about when the
session should really end. session should really end.
Permanent sessions may be shown to the user as never being active Permanent sessions may be shown to the user as never being active
unless there are associated repeat times that state precisely when unless there are associated repeat times that state precisely when
the session will be active. the session will be active.
5.10. Repeat Times ("r=") 5.10. Repeat Times ("r=")
r=<repeat interval> <active duration> <offsets from start-time> r=<repeat interval> <active duration> <offsets from start-time>
"r=" fields specify repeat times for a session. For example, if a "r=" fields specify repeat times for a session. For example, if a
session is active at 10am on Monday and 11am on Tuesday for one hour session is active at 10am on Monday and 11am on Tuesday for one hour
each week for three months, then the <start-time> in the each week for three months, then the <start-time> in the
corresponding "t=" field would be the NTP representation of 10am on corresponding "t=" field would be the NTP representation of 10am on
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 the description more compact, times may also be given in To make the description more compact, times may also be given in
units of 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:
r=7d 1h 0 25h r=7d 1h 0 25h
Monthly and yearly repeats cannot be directly specified with a single Monthly and yearly repeats cannot be directly specified with a single
SDP repeat time; instead, separate "t=" fields should be used to SDP repeat time; instead, separate "t=" fields should be used to
explicitly list the session times. explicitly list the session times.
5.11. Time Zones ("z=") 5.11. Time Zones ("z=")
z=<adjustment time> <offset> <adjustment time> <offset> .... z=<adjustment time> <offset> <adjustment time> <offset> ....
To schedule a repeated session that spans a change from daylight To schedule a repeated session that spans a change from daylight
saving time to standard time or vice versa, it is necessary to saving time to standard time or vice versa, it is necessary to
specify offsets from the base time. This is required because specify offsets from the base time. This is required because
different time zones change time at different times of day, different different time zones change time at different times of day, different
countries change to or from daylight saving time on different dates, countries change to or from daylight saving time on different dates,
and some countries do not have daylight saving time at all. and some countries do not have daylight saving time at all.
Thus, in order to schedule a session that is at the same time winter Thus, in order to schedule a session that is at the same time winter
and summer, it must be possible to specify unambiguously by whose and summer, it must be possible to specify unambiguously by whose
time zone a session is scheduled. To simplify this task for time zone a session is scheduled. To simplify this task for
receivers, we allow the sender to specify the NTP time that a time receivers, we allow the sender to specify the NTP time that a time
zone adjustment happens and the offset from the time when the session zone adjustment happens and the offset from the time when the session
was first scheduled. The "z=" field allows the sender to specify a was first scheduled. The "z=" field allows the sender to specify a
list of these adjustment times and offsets from the base time. list of these adjustment times and offsets from the base time.
An example might be the following: An example might be the following:
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 description 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
description. 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
implementations and its use is NOT RECOMMENDED. Work is in progress implementations and its use is NOT RECOMMENDED. Work is in progress
to define new key exchange mechanisms for use with SDP [RFC4567] to define new key exchange mechanisms for use with SDP [RFC4567]
[RFC4568], and it is expected that new applications will use those [RFC4568], and it is expected that new applications will use those
mechanisms. mechanisms.
skipping to change at page 22, line 19 skipping to change at page 22, line 16
SDP is conveyed over a secure and trusted channel. An example of SDP is conveyed over a secure and trusted channel. An example of
such a channel might be SDP embedded inside an S/MIME message or a such a channel might be SDP embedded inside an S/MIME message or a
TLS-protected HTTP session. It is important to ensure that the TLS-protected HTTP session. It is important to ensure that the
secure channel is with the party that is authorised to join the secure channel is with the party that is authorised to join the
session, not an intermediary: if a caching proxy server is used, it session, not an intermediary: if a caching proxy server is used, it
is important to ensure that the proxy is either trusted or unable to is important to ensure that the proxy is either trusted or unable to
access the SDP. access the SDP.
5.13. Attributes ("a=") 5.13. Attributes ("a=")
a=<attribute> a=<attribute>
a=<attribute>:<value> a=<attribute>:<value>
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
skipping to change at page 23, line 21 skipping to change at page 23, line 16
attribute is defined, it can be defined to be charset dependent, in attribute is defined, it can be defined to be charset dependent, in
which case its value should be interpreted in the session charset which case its value should be interpreted in the session charset
rather than in ISO-10646. rather than in ISO-10646.
Attributes MUST be registered with IANA (see Section 8). If an Attributes MUST be registered with IANA (see Section 8). If an
attribute is received that is not understood, it MUST be ignored by attribute is received that is not understood, it MUST be ignored by
the receiver. the receiver.
5.14. Media Descriptions ("m=") 5.14. Media Descriptions ("m=")
m=<media> <port> <proto> <fmt> ... m=<media> <port> <proto> <fmt> ...
A session description may contain a number of media descriptions. A session description may contain a number of media descriptions.
Each media description starts with an "m=" field and is terminated by Each media description starts with an "m=" field and is terminated by
either the next "m=" field or by the end of the session description. either the next "m=" field or by the end of the session description.
A media field has several sub-fields: A media field has several sub-fields:
<media> is the media type. Currently defined media are "audio", <media> is the media type. Currently defined media are "audio",
"video", "text", "application", and "message", although this list "video", "text", "application", and "message", although this list
may be extended in the future (see Section 8). may be extended in the future (see Section 8).
skipping to change at page 24, line 5 skipping to change at page 23, line 49
media to a <port> that is odd and where the "a=rtcp:" is present media to a <port> that is odd and where the "a=rtcp:" is present
MUST NOT subtract 1 from the RTP port: that is, they MUST send the MUST NOT subtract 1 from the RTP port: that is, they MUST send the
RTP to the port indicated in <port> and send the RTCP to the port RTP to the port indicated in <port> and send the RTCP to the port
indicated in the "a=rtcp" attribute. indicated in the "a=rtcp" attribute.
For applications where hierarchically encoded streams are being For applications where hierarchically encoded streams are being
sent to a unicast address, it may be necessary to specify multiple sent to a unicast address, it may be necessary to specify multiple
transport ports. This is done using a similar notation to that transport ports. This is done using a similar notation to that
used for IP multicast addresses in the "c=" field: used for IP multicast addresses in the "c=" field:
m=<media> <port>/<number of ports> <proto> <fmt> ... m=<media> <port>/<number of ports> <proto> <fmt> ...
In such a case, the ports used depend on the transport protocol. In such a case, the ports used depend on the transport protocol.
For RTP, the default is that only the even-numbered ports are used For RTP, the default is that only the even-numbered ports are used
for data with the corresponding one-higher odd ports used for the for data with the corresponding one-higher odd ports used for the
RTCP belonging to the RTP session, and the <number of ports> RTCP belonging to the RTP session, and the <number of ports>
denoting the number of RTP sessions. For example: denoting the number of RTP sessions. For example:
m=video 49170/2 RTP/AVP 31 m=video 49170/2 RTP/AVP 31
would specify that ports 49170 and 49171 form one RTP/RTCP pair would specify that ports 49170 and 49171 form one RTP/RTCP pair
and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the
transport protocol and 31 is the format (see below). If non- transport protocol and 31 is the format (see below). If non-
contiguous ports are required, they must be signalled using a contiguous ports are required, they must be signalled using a
separate attribute (for example, "a=rtcp:" as defined in separate attribute (for example, "a=rtcp:" as defined in
[RFC3605]). [RFC3605]).
If multiple addresses are specified in the "c=" field and multiple If multiple addresses are specified in the "c=" field and multiple
ports are specified in the "m=" field, a one-to-one mapping from ports are specified in the "m=" field, a one-to-one mapping from
port to the corresponding address is implied. For example: port to the corresponding address is implied. For example:
c=IN IP4 233.252.0.1/127/2 c=IN IP4 233.252.0.1/127/2
m=video 49170/2 RTP/AVP 31 m=video 49170/2 RTP/AVP 31
would imply that address 233.252.0.1 is used with ports 49170 and would imply that address 233.252.0.1 is used with ports 49170 and
49171, and address 233.252.0.2 is used with ports 49172 and 49173. 49171, and address 233.252.0.2 is used with ports 49172 and 49173.
The semantics of multiple "m=" lines using the same transport The semantics of multiple "m=" lines using the same transport
address are undefined. This implies that, unlike limited past address are undefined. This implies that, unlike limited past
practice, there is no implicit grouping defined by such means and practice, there is no implicit grouping defined by such means and
an explicit grouping framework (for example, [RFC5888]) should an explicit grouping framework (for example, [RFC5888]) should
instead be used to express the intended semantics. instead be used to express the intended semantics.
skipping to change at page 27, line 24 skipping to change at page 27, line 24
Although an RTP profile may make static assignments of payload Although an RTP profile may make static assignments of payload
type numbers to payload formats, it is more common for that type numbers to payload formats, it is more common for that
assignment to be done dynamically using "a=rtpmap:" attributes. assignment to be done dynamically using "a=rtpmap:" attributes.
As an example of a static payload type, consider u-law PCM As an example of a static payload type, consider u-law PCM
coded single-channel audio sampled at 8 kHz. This is coded single-channel audio sampled at 8 kHz. This is
completely defined in the RTP Audio/Video profile as payload completely defined in the RTP Audio/Video profile as payload
type 0, so there is no need for an "a=rtpmap:" attribute, and type 0, so there is no need for an "a=rtpmap:" attribute, and
the media for such a stream sent to UDP port 49232 can be the media for such a stream sent to UDP port 49232 can be
specified as: specified as:
m=audio 49232 RTP/AVP 0 m=audio 49232 RTP/AVP 0
An example of a dynamic payload type is 16-bit linear encoded An example of a dynamic payload type is 16-bit linear encoded
stereo audio sampled at 16 kHz. If we wish to use the dynamic stereo audio sampled at 16 kHz. If we wish to use the dynamic
RTP/AVP payload type 98 for this stream, additional information RTP/AVP payload type 98 for this stream, additional information
is required to decode it: is required to decode it:
m=audio 49232 RTP/AVP 98 m=audio 49232 RTP/AVP 98
a=rtpmap:98 L16/16000/2 a=rtpmap:98 L16/16000/2
Up to one rtpmap attribute can be defined for each media format Up to one rtpmap attribute can be defined for each media format
specified. Thus, we might have the following: specified. Thus, we might have the following:
m=audio 49230 RTP/AVP 96 97 98 m=audio 49230 RTP/AVP 96 97 98
a=rtpmap:96 L8/8000 a=rtpmap:96 L8/8000
a=rtpmap:97 L16/8000 a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2 a=rtpmap:98 L16/11025/2
RTP profiles that specify the use of dynamic payload types MUST RTP profiles that specify the use of dynamic payload types MUST
define the set of valid encoding names and/or a means to define the set of valid encoding names and/or a means to
register encoding names if that profile is to be used with SDP. register encoding names if that profile is to be used with SDP.
The "RTP/AVP" and "RTP/SAVP" profiles use media subtypes for The "RTP/AVP" and "RTP/SAVP" profiles use media subtypes for
encoding names, under the top-level media type denoted in the encoding names, under the top-level media type denoted in the
"m=" line. In the example above, the media types are "audio/ "m=" line. In the example above, the media types are "audio/
l8" and "audio/l16". l8" and "audio/l16".
For audio streams, <encoding parameters> indicates the number For audio streams, <encoding parameters> indicates the number
skipping to change at page 29, line 5 skipping to change at page 28, line 46
If none of the attributes "sendonly", "recvonly", "inactive", If none of the attributes "sendonly", "recvonly", "inactive",
and "sendrecv" is present at either session level or media and "sendrecv" is present at either session level or media
level, "sendrecv" SHOULD be assumed as the default for sessions level, "sendrecv" SHOULD be assumed as the default for sessions
that are not of the conference type "broadcast" or "H332" (see that are not of the conference type "broadcast" or "H332" (see
below). below).
Within the following SDP example, the "inactive" attribute Within the following SDP example, the "inactive" attribute
applies to audio media and the "recvonly" attribute applies to applies to audio media and the "recvonly" attribute applies to
video media. video media.
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1
s=SDP Seminar s=SDP Seminar
i=A Seminar on the session description protocol i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe) e=j.doe@example.com (Jane Doe)
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
t=2873397496 2873404696 t=2873397496 2873404696
a=inactive a=inactive
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99 m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000 a=rtpmap:99 h263-1998/90000
a=recvonly a=recvonly
a=recvonly a=recvonly
This specifies that the tools should be started in receive-only This specifies that the tools should be started in receive-only
mode where applicable. It can be either a session- or media- mode where applicable. It can be either a session- or media-
level attribute, and it is not dependent on charset. Note that level attribute, and it is not dependent on charset. Note that
recvonly applies to the media only, not to any associated recvonly applies to the media only, not to any associated
control protocol (e.g., an RTP-based system in recvonly mode control protocol (e.g., an RTP-based system in recvonly mode
SHOULD still send RTCP packets). SHOULD still send RTCP packets).
skipping to change at page 30, line 49 skipping to change at page 31, line 5
a=charset:<character set> a=charset:<character set>
This specifies the character set to be used to display the This specifies the character set to be used to display the
session name and information data. By default, the ISO-10646 session name and information data. By default, the ISO-10646
character set in UTF-8 encoding is used. If a more compact character set in UTF-8 encoding is used. If a more compact
representation is required, other character sets may be used. representation is required, other character sets may be used.
For example, the ISO 8859-1 is specified with the following SDP For example, the ISO 8859-1 is specified with the following SDP
attribute: attribute:
a=charset:ISO-8859-1 a=charset:ISO-8859-1
This is a session-level attribute and is not dependent on This is a session-level attribute and is not dependent on
charset. The charset specified MUST be one of those registered charset. The charset specified MUST be one of those registered
with IANA, such as ISO-8859-1. The character set identifier is with IANA, such as ISO-8859-1. The character set identifier is
a US-ASCII string and MUST be compared against the IANA a US-ASCII string and MUST be compared against the IANA
identifiers using a case-insensitive comparison. If the identifiers using a case-insensitive comparison. If the
identifier is not recognised or not supported, all strings that identifier is not recognised or not supported, all strings that
are affected by it SHOULD be regarded as octet strings. are affected by it SHOULD be regarded as octet strings.
Note that a character set specified MUST still prohibit the use Note that a character set specified MUST still prohibit the use
skipping to change at page 32, line 36 skipping to change at page 32, line 40
dependent on charset. dependent on charset.
a=quality:<quality> a=quality:<quality>
This gives a suggestion for the quality of the encoding as an This gives a suggestion for the quality of the encoding as an
integer value. The intention of the quality attribute for integer value. The intention of the quality attribute for
video is to specify a non-default trade-off between frame-rate video is to specify a non-default trade-off between frame-rate
and still-image quality. For video, the value is in the range and still-image quality. For video, the value is in the range
0 to 10, with the following suggested meaning: 0 to 10, with the following suggested meaning:
10 - the best still-image quality the compression scheme 10 - the best still-image quality the compression scheme
can give. can give.
5 - the default behaviour given no quality suggestion. 5 - the default behaviour given no quality suggestion.
0 - the worst still-image quality the codec designer 0 - the worst still-image quality the codec designer
thinks is still usable. thinks is still usable.
It is a media-level attribute, and it is not dependent on It is a media-level attribute, and it is not dependent on
charset. charset.
a=fmtp:<format> <format specific parameters> a=fmtp:<format> <format specific parameters>
This attribute allows parameters that are specific to a This attribute allows parameters that are specific to a
particular format to be conveyed in a way that SDP does not particular format to be conveyed in a way that SDP does not
have to understand them. The format must be one of the formats have to understand them. The format must be one of the formats
specified for the media. Format-specific parameters may be any specified for the media. Format-specific parameters may be any
set of parameters required to be conveyed by SDP and given set of parameters required to be conveyed by SDP and given
unchanged to the media tool that will use this format. At most unchanged to the media tool that will use this format. At most
one instance of this attribute is allowed for each format. one instance of this attribute is allowed for each format.
It is a media-level attribute, and it is not dependent on It is a media-level attribute, and it is not dependent on
charset. charset.
skipping to change at page 39, line 27 skipping to change at page 38, line 42
expected to see widespread use and interoperability SHOULD be expected to see widespread use and interoperability SHOULD be
documented with a standards-track RFC that specifies the attribute documented with a standards-track RFC that specifies the attribute
more precisely. more precisely.
Submitters of registrations should ensure that the specification is Submitters of registrations should ensure that the specification is
in the spirit of SDP attributes, most notably that the attribute is in the spirit of SDP attributes, most notably that the attribute is
platform independent in the sense that it makes no implicit platform independent in the sense that it makes no implicit
assumptions about operating systems and does not name specific pieces assumptions about operating systems and does not name specific pieces
of software in a manner that might inhibit interoperability. of software in a manner that might inhibit interoperability.
Submitters of registrations should also carefully choose the type of
attribute. They should not choose a session-level only type when the
attribute can have different values when media is disaggregated,
i.e., when each m= section has its own IP address on a different
endpoint. In that case the attribute type chosen should be "both".
IANA has registered the following initial set of attribute names IANA has registered the following initial set of attribute names
("att-field" values), with definitions as in Section 6 of this memo ("att-field" values), with definitions as in Section 6 of this memo
(these definitions update those in [RFC4566]): (these definitions update those in [RFC4566]):
Name | Session or Media level? | Dependent on charset? Name | Session or Media level? | Dependent on charset?
----------+-------------------------+---------------------- ----------+-------------------------+----------------------
cat | Session | No cat | Session | No
keywds | Session | Yes keywds | Session | Yes
tool | Session | No tool | Session | No
ptime | Media | No ptime | Media | No
maxptime | Media | No maxptime | Media | No
rtpmap | Media | No rtpmap | Media | No
recvonly | Either | No recvonly | Either | No
sendrecv | Either | No sendrecv | Either | No
sendonly | Either | No sendonly | Either | No
inactive | Either | No inactive | Either | No
orient | Media | No orient | Media | No
type | Session | No type | Session | No
charset | Session | No charset | Session | No
sdplang | Either | No sdplang | Either | No
lang | Either | No lang | Either | No
framerate | Media | No framerate | Media | No
quality | Media | No quality | Media | No
fmtp | Media | No fmtp | Media | No
8.2.5. Bandwidth Specifiers ("bwtype") 8.2.5. Bandwidth Specifiers ("bwtype")
A proliferation of bandwidth specifiers is strongly discouraged. A proliferation of bandwidth specifiers is strongly discouraged.
New bandwidth specifiers ("bwtype" fields) MUST be registered with New bandwidth specifiers ("bwtype" fields) MUST be registered with
IANA. The submission MUST reference a standards-track RFC specifying IANA. The submission MUST reference a standards-track RFC specifying
the semantics of the bandwidth specifier precisely, and indicating the semantics of the bandwidth specifier precisely, and indicating
when it should be used, and why the existing registered bandwidth when it should be used, and why the existing registered bandwidth
specifiers do not suffice. specifiers do not suffice.
skipping to change at page 47, line 5 skipping to change at page 46, line 26
for hexpart, hexseq, and hex4 have been removed. for hexpart, hexseq, and hex4 have been removed.
IP4 unicast and multicast addresses in the example SDP descriptions IP4 unicast and multicast addresses in the example SDP descriptions
have been revised per RFCs 5735 and 5771. have been revised per RFCs 5735 and 5771.
Text in Section 5.2 has been revised to clarify the use of local Text in Section 5.2 has been revised to clarify the use of local
addresses in case of ICE-like SDP extensions. addresses in case of ICE-like SDP extensions.
Normative and informative references have been updated. Normative and informative references have been updated.
The text regarding the session vs. media-level attribute usage has The text regarding the session vs. media-level attribute usage has
been clarified. been clarified.
The case-insensitivity rules from RFC 4855 have been included in this The case-insensitivity rules from RFC 4855 have been included in this
document. document.
The following purely editorial changes have been made: The following purely editorial changes have been made:
o Section 4.6: fix typo in first sentence: "sets" -> "set" o Section 4.6: fix typo in first sentence: "sets" -> "set"
o Section 5: clarify second paragraph (SDP field and attribute names o Section 5: clarify second paragraph (SDP field and attribute names
skipping to change at page 50, line 10 skipping to change at page 49, line 38
[RFC3890] Westerlund, M., "A Transport Independent Bandwidth [RFC3890] Westerlund, M., "A Transport Independent Bandwidth
Modifier for the Session Description Protocol (SDP)", RFC Modifier for the Session Description Protocol (SDP)", RFC
3890, September 2004. 3890, September 2004.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April Traversal for Offer/Answer Protocols", RFC 5245, April
2010. 2010.
[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B.B., and A.B.
"TCP Candidates with Interactive Connectivity Roach, "TCP Candidates with Interactive Connectivity
Establishment (ICE)", RFC 6544, March 2012. Establishment (ICE)", RFC 6544, March 2012.
[ITU.H332.1998] [ITU.H332.1998]
International Telecommunication Union, "H.323 extended for International Telecommunication Union, "H.323 extended for
loosely coupled conferences", ITU Recommendation H.332, loosely coupled conferences", ITU Recommendation H.332,
September 1998. September 1998.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Carrara, "Key Management Extensions for Session Carrara, "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming Description Protocol (SDP) and Real Time Streaming
skipping to change at page 50, line 38 skipping to change at page 50, line 19
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008. October 2008.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, RFC Specifications and Registration Procedures", BCP 13, RFC
6838, January 2013. 6838, January 2013.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload [RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007. Formats", RFC 4855, February 2007.
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
RFC 2365, July 1998.
Authors' Addresses Authors' Addresses
Mark Handley Mark Handley
University College London University College London
Department of Computer Science Department of Computer Science
London WC1E 6BT London WC1E 6BT
UK UK
EMail: M.Handley@cs.ucl.ac.uk EMail: M.Handley@cs.ucl.ac.uk
Van Jacobson Van Jacobson
PARC PARC
3333 Coyote Hill Road 3333 Coyote Hill Road
Palo Alto, CA 94304 Palo Alto, CA 94304
USA USA
EMail: van@parc.com EMail: van@parc.com
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
 End of changes. 59 change blocks. 
118 lines changed or deleted 127 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/