draft-ietf-mmusic-rfc4566bis-15.txt   draft-ietf-mmusic-rfc4566bis-16.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: November 6, 2015 C. Perkins Expires: May 6, 2016 C. Perkins
University of Glasgow University of Glasgow
A. Begen A. Begen
Cisco Unaffiliated
May 5, 2015 November 3, 2015
SDP: Session Description Protocol SDP: Session Description Protocol
draft-ietf-mmusic-rfc4566bis-15 draft-ietf-mmusic-rfc4566bis-16
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 November 6, 2015. This Internet-Draft will expire on May 6, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 30 skipping to change at page 2, line 30
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 . . . . . . . . . . . . . . . . . . . . . 5 3.2. Streaming Media . . . . . . . . . . . . . . . . . . . . . 5
3.3. Email and the World Wide Web . . . . . . . . . . . . . . 5 3.3. Email and the World Wide Web . . . . . . . . . . . . . . 5
3.4. Multicast Session Announcement . . . . . . . . . . . . . 5 3.4. Multicast Session Announcement . . . . . . . . . . . . . 5
4. Requirements and Recommendations . . . . . . . . . . . . . . 6 4. Requirements and Recommendations . . . . . . . . . . . . . . 5
4.1. Media and Transport Information . . . . . . . . . . . . . 7 4.1. Media and Transport Information . . . . . . . . . . . . . 6
4.2. Timing Information . . . . . . . . . . . . . . . . . . . 7 4.2. Timing Information . . . . . . . . . . . . . . . . . . . 7
4.3. Private Sessions . . . . . . . . . . . . . . . . . . . . 8 4.3. Obtaining Further Information about a Session . . . . . . 7
4.4. Obtaining Further Information about a Session . . . . . . 8 4.4. Categorisation . . . . . . . . . . . . . . . . . . . . . 8
4.5. Categorisation . . . . . . . . . . . . . . . . . . . . . 8 4.5. 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=") . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 13 5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 13
5.4. Session Information ("i=") . . . . . . . . . . . . . . . 13 5.4. Session Information ("i=") . . . . . . . . . . . . . . . 13
5.5. URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . 14 5.5. URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . 14
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=") . . . . . . . . . . . . . . . . . 15 5.7. Connection Data ("c=") . . . . . . . . . . . . . . . . . 15
5.8. Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . 17 5.8. Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . 17
5.9. Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 18 5.9. Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 18
skipping to change at page 3, line 27 skipping to change at page 3, line 25
6.8. orient (orientation) . . . . . . . . . . . . . . . . . . 33 6.8. orient (orientation) . . . . . . . . . . . . . . . . . . 33
6.9. type (conference type) . . . . . . . . . . . . . . . . . 33 6.9. type (conference type) . . . . . . . . . . . . . . . . . 33
6.10. charset (character set) . . . . . . . . . . . . . . . . . 34 6.10. charset (character set) . . . . . . . . . . . . . . . . . 34
6.11. sdplang (SDP language) . . . . . . . . . . . . . . . . . 35 6.11. sdplang (SDP language) . . . . . . . . . . . . . . . . . 35
6.12. lang (language) . . . . . . . . . . . . . . . . . . . . . 36 6.12. lang (language) . . . . . . . . . . . . . . . . . . . . . 36
6.13. framerate (frame rate) . . . . . . . . . . . . . . . . . 37 6.13. framerate (frame rate) . . . . . . . . . . . . . . . . . 37
6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 37 6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 38 6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 38
7. Security Considerations . . . . . . . . . . . . . . . . . . . 39 7. Security Considerations . . . . . . . . . . . . . . . . . . . 39
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
8.1. The "application/sdp" Media Type . . . . . . . . . . . . 40 8.1. The "application/sdp" Media Type . . . . . . . . . . . . 41
8.2. Registration of Parameters . . . . . . . . . . . . . . . 42 8.2. Registration of Parameters . . . . . . . . . . . . . . . 43
8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 42 8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 43
8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 42 8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 43
8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 43 8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 44
8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 43 8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 44
8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 45 8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 46
8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 45 8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 46
8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 45 8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 47
8.2.8. Registration Procedure . . . . . . . . . . . . . . . 46 8.2.8. Registration Procedure . . . . . . . . . . . . . . . 47
8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 46 8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 48
8.4. Reorganization of the nettype Registry . . . . . . . . . 47 8.4. Reorganization of the nettype Registry . . . . . . . . . 48
8.5. Reorganization of the att-field Registries . . . . . . . 47 8.5. Reorganization of the att-field Registries . . . . . . . 48
9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 47 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 49
10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 53 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 54
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 53 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
12.1. Normative References . . . . . . . . . . . . . . . . . . 53 12.1. Normative References . . . . . . . . . . . . . . . . . . 55
12.2. Informative References . . . . . . . . . . . . . . . . . 55 12.2. Informative References . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59
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
format for session description -- it does not incorporate a transport format for session description -- it does not incorporate a transport
protocol, and it is intended to use different transport protocols as protocol, and it is intended to use different transport protocols as
appropriate, including the Session Announcement Protocol [RFC2974], appropriate, including the Session Announcement Protocol (SAP)
Session Initiation Protocol [RFC3261], Real Time Streaming Protocol [RFC2974], Session Initiation Protocol (SIP) [RFC3261], Real Time
[RFC2326], electronic mail using the MIME extensions, and the Streaming Protocol (RTSP) [RFC2326], electronic mail using the MIME
Hypertext Transport Protocol. extensions, and the Hypertext Transport Protocol (HTTP).
SDP is intended to be general purpose so that it can be used in a SDP is intended to be general purpose so that it can be used in a
wide range of network environments and applications. However, it is wide range of network environments and applications. However, it is
not intended to support negotiation of session content or media not intended to support negotiation of session content or media
encodings: this is viewed as outside the scope of session encodings: this is viewed as outside the scope of session
description. description.
This memo obsoletes [RFC4566]. The changes relative to [RFC4566] are This memo obsoletes [RFC4566]. The changes relative to [RFC4566] are
limited to essential corrections, and are outlined in Section 10 of limited to essential corrections, and are outlined in Section 10 of
this memo. this memo.
skipping to change at page 5, line 47 skipping to change at page 5, line 44
conferences and other multicast sessions, and to communicate the conferences and other multicast sessions, and to communicate the
relevant session setup information to prospective participants, a relevant session setup information to prospective participants, a
distributed session directory may be used. An instance of such a distributed session directory may be used. An instance of such a
session directory periodically sends packets containing a description session directory periodically sends packets containing a description
of the session to a well-known multicast group. These advertisements of the session to a well-known multicast group. These advertisements
are received by other session directories such that potential remote are received by other session directories such that potential remote
participants can use the session description to start the tools participants can use the session description to start the tools
required to participate in the session. required to participate in the session.
One protocol used to implement such a distributed directory is the One protocol used to implement such a distributed directory is the
Session Announcement Protocol (SAP) [RFC2974]. SDP provides the SAP [RFC2974]. SDP provides the recommended session description
recommended session description format for such session format for such session announcements.
announcements.
4. Requirements and Recommendations 4. Requirements and Recommendations
The purpose of SDP is to convey information about media streams in The purpose of SDP is to convey information about media streams in
multimedia sessions to allow the recipients of a session description multimedia sessions to allow the recipients of a session description
to participate in the session. SDP is primarily intended for use in to participate in the session. SDP is primarily intended for use in
an internetwork, although it is sufficiently general that it can an internetwork, although it is sufficiently general that it can
describe multimedia conferences in other network environments. Media describe multimedia conferences in other network environments. Media
streams can be many-to-many. Sessions need not be continually streams can be many-to-many. Sessions need not be continually
active. active.
Thus far, multicast-based sessions on the Internet have differed from Thus far, multicast-based sessions on the Internet have differed from
many other forms of conferencing in that anyone receiving the traffic many other forms of conferencing in that anyone receiving the traffic
can join the session (unless the session traffic is encrypted). In can join the session (unless the session traffic is encrypted). In
such an environment, SDP serves two primary purposes. It is a means such an environment, SDP serves two primary purposes. It is a means
to communicate the existence of a session, and it is a means to to communicate the existence of a session, and it is a means to
convey sufficient information to enable joining and participating in convey sufficient information to enable joining and participating in
the session. In a unicast environment, only the latter purpose is the session. In a unicast environment, only the latter purpose is
likely to be relevant. likely to be relevant.
An SDP session description includes the following: An SDP description includes the following:
o Session name and purpose o Session name and purpose
o Time(s) the session is active o Time(s) the session is active
o The media comprising the session o The media comprising the session
o Information needed to receive those media (addresses, ports, o Information needed to receive those media (addresses, ports,
formats, etc.) formats, etc.)
skipping to change at page 7, line 7 skipping to change at page 6, line 45
In general, SDP must convey sufficient information to enable In general, SDP must convey sufficient information to enable
applications to join a session (with the possible exception of applications to join a session (with the possible exception of
encryption keys) and to announce the resources to be used to any non- encryption keys) and to announce the resources to be used to any non-
participants that may need to know. (This latter feature is participants that may need to know. (This latter feature is
primarily useful when SDP is used with a multicast session primarily useful when SDP is used with a multicast session
announcement protocol.) announcement protocol.)
4.1. Media and Transport Information 4.1. Media and Transport Information
An SDP session description includes the following media information: An SDP description includes the following media information:
o The type of media (video, audio, etc.) o The type of media (video, audio, etc.)
o The transport protocol (RTP/UDP/IP, H.320, etc.) o The media transport protocol (RTP/UDP/IP, H.320, etc.)
o The format of the media (H.261 video, MPEG video, etc.) o The format of the media (H.261 video, MPEG video, etc.)
In addition to media format and transport protocol, SDP conveys In addition to media format and transport protocol, SDP conveys
address and port details. For an IP multicast session, these address and port details. For an IP multicast session, these
comprise: comprise:
o The multicast group address for media o The multicast group address for media
o The transport port for media o The transport port for media
This address and port are the destination address and destination This address and port are the destination address and destination
port of the multicast stream, whether being sent, received, or both. port of the multicast stream, whether being sent, received, or both.
skipping to change at page 8, line 5 skipping to change at page 7, line 43
convey: convey:
o An arbitrary list of start and stop times bounding the session o An arbitrary list of start and stop times bounding the session
o For each bound, repeat times such as "every Wednesday at 10am for o For each bound, repeat times such as "every Wednesday at 10am for
one hour" one hour"
This timing information is globally consistent, irrespective of local This timing information is globally consistent, irrespective of local
time zone or daylight saving time (see Section 5.9). time zone or daylight saving time (see Section 5.9).
4.3. Private Sessions 4.3. Obtaining Further Information about a Session
It is possible to create both public sessions and private sessions.
SDP itself does not distinguish between these; private sessions are
typically conveyed by encrypting the session description during
distribution. The details of how encryption is performed are
dependent on the mechanism used to convey SDP; mechanisms are
currently defined for SDP transported using SAP [RFC2974] and SIP
[RFC3261], and others may be defined in the future.
If a session announcement is private, it is possible to use that
private announcement to convey encryption keys necessary to decode
each of the media in a multimedia conference, including enough
information to know which encryption scheme is used for each media.
4.4. Obtaining Further Information about a Session
A session description should convey enough information to decide A session description could convey enough information to decide
whether or not to participate in a session. SDP may include whether or not to participate in a session. SDP may include
additional pointers in the form of Uniform Resource Identifiers additional pointers in the form of Uniform Resource Identifiers
(URIs) for more information about the session. (URIs) for more information about the session.
4.5. Categorisation 4.4. Categorisation
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.5. Internationalisation
The SDP specification recommends the use of the ISO 10646 character The SDP specification recommends the use of the ISO 10646 character
set in the UTF-8 encoding [RFC3629] to allow many different languages set in the UTF-8 encoding [RFC3629] to allow many different languages
to be represented. However, to assist in compact representations, to be represented. However, to assist in compact representations,
SDP also allows other character sets such as ISO 8859-1 to be used SDP also allows other character sets such as ISO 8859-1 to be used
when desired. Internationalisation only applies to free-text fields when 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 description is denoted by the media type "application/sdp"
sdp" (See Section 8). (See Section 8).
An SDP session description is entirely textual. SDP field names and An SDP description is entirely textual. SDP field names and
attribute names use only the US-ASCII subset of UTF-8, but textual attribute names use only the US-ASCII subset of UTF-8, but textual
fields and attribute values MAY use the full ISO 10646 character set fields and attribute values MAY use the full ISO 10646 character set
in UTF-8 encoding, or some other character set defined by the in UTF-8 encoding, or some other character set defined by the
"a=charset:" attribute. Field and attribute values that use the full "a=charset:" attribute. Field and attribute values that use the full
UTF-8 character set are never directly compared, hence there is no UTF-8 character set are never directly compared, hence there is no
requirement for UTF-8 normalisation. The textual form, as opposed to requirement for UTF-8 normalisation. The textual form, as opposed to
a binary encoding such as ASN.1 or XDR, was chosen to enhance a binary encoding such as ASN.1 or XDR, was chosen to enhance
portability, to enable a variety of transports to be used, and to portability, to enable a variety of transports to be used, and to
allow flexible, text-based toolkits to be used to generate and allow flexible, text-based toolkits to be used to generate and
process session descriptions. However, since SDP may be used in process session descriptions. However, since SDP may be used in
environments where the maximum permissible size of a session environments where the maximum permissible size of a session
description is limited, the encoding is deliberately compact. Also, description is limited, the encoding is deliberately compact. Also,
since announcements may be transported via very unreliable means or since announcements may be transported via very unreliable means or
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 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 description consists of a session-level section followed by
followed by zero or more media-level sections. The session-level zero or more media-level sections. The session-level part starts
part starts with a "v=" line and continues to the first media-level with a "v=" line and continues to the first media-level section (or
section (or the end of the whole description, whichever comes first). the end of the whole description, whichever comes first). Each
Each media-level section starts with an "m=" line and continues to media-level section starts with an "m=" line and continues to the
the next media-level section or the end of the whole session next media-level section or the end of the whole session description
description - whichever comes first. In general, session-level - whichever comes first. In general, session-level values are the
values are the default for all media unless overridden by an default for all media unless overridden by an equivalent media-level
equivalent media-level value. 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)
skipping to change at page 10, line 45 skipping to change at page 10, line 45
The set of type letters is deliberately small and not intended to be The set of type letters is deliberately small and not intended to be
extensible -- an SDP parser MUST completely ignore any session extensible -- an SDP parser MUST completely ignore any session
description that contains a type letter that it does not understand. description that contains a type letter that it does not understand.
The attribute mechanism ("a=" described below) is the primary means The attribute mechanism ("a=" described below) is the primary means
for extending SDP and tailoring it to particular applications or for extending SDP and tailoring it to particular applications or
media. Some attributes (the ones listed in Section 6 of this memo) media. Some attributes (the ones listed in Section 6 of this memo)
have a defined meaning, but others may be added on an application-, have a defined meaning, but others may be added on an application-,
media-, or session-specific basis. An SDP parser MUST ignore any media-, or session-specific basis. An SDP parser MUST ignore any
attribute it doesn't understand. attribute it doesn't understand.
An SDP session description may contain URIs that reference external An SDP description may contain URIs that reference external content
content in the "u=", "k=", and "a=" lines. These URIs may be in the "u=", "k=", and "a=" lines. These URIs may be dereferenced in
dereferenced in some cases, making the session description non-self- some cases, making the session description non-self- contained.
contained.
The connection ("c=") information in the session-level section The connection ("c=") information in the session-level section
applies to all the media of that session unless overridden by applies to all the media of that session unless overridden by
connection information in the media description. For instance, in connection information in the media description. For instance, in
the example below, each audio media description behaves as if it were the example below, each audio media description behaves as if it were
given a "c=IN IP4 233.252.0.2". given a "c=IN IP4 233.252.0.2".
An example SDP description is: An example SDP description is:
v=0 v=0
skipping to change at page 13, line 33 skipping to change at page 13, line 33
"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=" line provides textual information about the session. There The "i=" line provides textual information about the session. There
MUST be at most one session-level "i=" line per session description, MUST be at most one session-level "i=" line per session description,
and at most one "i=" line per media. If the "a=charset" attribute is and at most one "i=" line per media description/definition. Unless a
present, it specifies the character set used in the "i=" line. If media level "i="" line is used, the session-level "i="" line applies
the "a=charset" attribute is not present, the "i=" line MUST contain to that media description. If the "a=charset" attribute is present,
ISO 10646 characters in UTF-8 encoding. it specifies the character set used in the "i=" line. If the
"a=charset" attribute is not present, the "i=" line MUST contain ISO
10646 characters in UTF-8 encoding.
A single "i=" line MAY also be used for each media definition. In A single "i=" line can be used for each media definition. In media
media definitions, "i=" lines are primarily intended for labelling definitions, "i=" lines are primarily intended for labelling media
media streams. As such, they are most likely to be useful when a streams. As such, they are most likely to be useful when a single
single session has more than one distinct media stream of the same session has more than one distinct media stream of the same media
media type. An example would be two different whiteboards, one for type. An example would be two different whiteboards, one for slides
slides and one for feedback and questions. and one for feedback and questions.
The "i=" line is intended to provide a free-form human-readable The "i=" line 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 line is OPTIONAL, but if it is present it about the session. This line is OPTIONAL. No more than one URI line
MUST be specified before the first media field. No more than one URI is allowed per session description.
line 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.
the previous version of SDP specified that either an email line or a
phone line MUST be specified, but this was widely ignored. The
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 line can before the first media field. More than one email or phone line 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:
skipping to change at page 17, line 25 skipping to change at page 17, line 23
5.8. Bandwidth ("b=") 5.8. Bandwidth ("b=")
b=<bwtype>:<bandwidth> b=<bwtype>:<bandwidth>
This OPTIONAL line denotes the proposed bandwidth to be used by the This OPTIONAL line 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 is different from the bandwidth
from the bandwidth implicit from the scope, a "b=CT:..." line implicit from the scope, a "b=CT:..." line SHOULD be supplied for
SHOULD be supplied for the session giving the proposed upper limit the session giving the proposed upper limit to the bandwidth used
to the bandwidth used (the "conference total" bandwidth). The (the "conference total" bandwidth). Similarly, if the bandwidth
primary purpose of this is to give an approximate idea as to of bundled media streams in an m line is different from the
whether two or more sessions can coexist simultaneously. implicit value from the scope, a "b=CT:..." line SHOULD be
supplied in the media level. The primary purpose of this is to
give an approximate idea as to whether two or more sessions (or
bundled media streams) can coexist simultaneously. Note that CT
gives a total bandwidth figure for all the media at all endpoints.
AS The bandwidth is interpreted to be application specific (it will AS The bandwidth is interpreted to be application specific (it will
be the application's concept of maximum bandwidth). Normally, be the application's concept of maximum bandwidth). Normally,
this will coincide with what is set on the application's "maximum this will coincide with what is set on the application's "maximum
bandwidth" control if applicable. For RTP-based applications, AS bandwidth" control if applicable. For RTP-based applications, AS
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 AS gives a bandwidth figure for a single
media at a single endpoint, although there may be many endpoints
Note that CT gives a total bandwidth figure for all the media at all sending simultaneously.
sites. AS gives a bandwidth figure for a single media at a single
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
skipping to change at page 33, line 4 skipping to change at page 33, line 4
Charset Dependent: no Charset Dependent: no
Example: Example:
a=inactive a=inactive
This specifies that the tools should be started in inactive mode. This specifies that the tools should be started in inactive mode.
This is necessary for interactive multimedia conferences where users This is necessary for interactive multimedia conferences where users
can put other users on hold. No media is sent over an inactive media can put other users on hold. No media is sent over an inactive media
stream. Note that an RTP-based system SHOULD still send RTCP, even stream. Note that an RTP-based system MUST still send RTCP (if RTCP
if started inactive. is used), even if started inactive.
6.8. orient (orientation) 6.8. orient (orientation)
Name: orient Name: orient
Value: orient-value Value: orient-value
Usage Level: media Usage Level: media
Charset Dependent: no Charset Dependent: no
skipping to change at page 35, line 46 skipping to change at page 35, line 46
Syntax: Syntax:
sdplang-value = Language-Tag sdplang-value = Language-Tag
; Language-Tag defined in RFC5646 ; Language-Tag defined in RFC5646
Example: Example:
a=sdplang:fr a=sdplang:fr
This can be a session-level attribute or a media-level attribute.
Multiple sdplang attributes can be provided either at session or Multiple sdplang attributes can be provided either at session or
media level if the session description or media use multiple media level if the session description or media use multiple
languages. languages.
As a session-level attribute, it specifies the language for the As a session-level attribute, it specifies the language for the
session description. As a media-level attribute, it specifies the session description (not the language of the media). As a media-
language for any media-level SDP information field associated with level attribute, it specifies the language for any media-level SDP
that media, overriding any sdplang attributes specified at session- information field associated with that media (again not the language
level. of the media), overriding any sdplang attributes specified at
session-level.
In general, sending session descriptions consisting of multiple In general, sending session descriptions consisting of multiple
languages is discouraged. Instead, multiple descriptions SHOULD be languages is discouraged. Instead, multiple descriptions SHOULD be
sent describing the session, one in each language. However, this is sent describing the session, one in each language. However, this is
not possible with all transport mechanisms, and so multiple sdplang not possible with all transport mechanisms, and so multiple sdplang
attributes are allowed although NOT RECOMMENDED. attributes are allowed although NOT RECOMMENDED.
The "sdplang" attribute value must be a single [RFC5646] language tag The "sdplang" attribute value must be a single [RFC5646] language tag
in US-ASCII. An "sdplang" attribute SHOULD be specified when a in US-ASCII. An "sdplang" attribute SHOULD be specified when a
session is distributed with sufficient scope to cross geographic session is distributed with sufficient scope to cross geographic
skipping to change at page 36, line 41 skipping to change at page 36, line 41
Syntax: Syntax:
lang-value = Language-Tag lang-value = Language-Tag
; Language-Tag defined in RFC5646 ; Language-Tag defined in RFC5646
Example: Example:
a=lang:de a=lang:de
Multiple lang attributes can be provided either at session or media Multiple lang attributes can be provided either at session or media
level if the session or media use multiple languages, in which case level if the session or media has capabilities to use multiple
the order of the attributes indicates the order of importance of the languages, in which case the order of the attributes indicates the
various languages in the session or media, from most important to order of preference of the various languages in the session or media,
least important. from most preferred to least preferred.
As a session-level attribute, it specifies the default language for As a session-level attribute, lang specifies a language capability
the session being described. As a media-level attribute, it for the session being described. As a media-level attribute, it
specifies the language for that media, overriding any session-level specifies a language capability for that media, overriding any
languages specified. session-level language(s) specified.
The "lang" attribute value must be a single [RFC5646] language tag in The "lang" attribute value must be a single [RFC5646] language tag in
US-ASCII. A "lang" attribute SHOULD be specified when a session is US-ASCII. A "lang" attribute SHOULD be specified when a session is
of sufficient scope to cross geographic boundaries where the language of sufficient scope to cross geographic boundaries where the language
of recipients cannot be assumed, or where the session is in a of recipients cannot be assumed, or where the session has
different language from the locally assumed norm. capabilities in languages different from the locally assumed norm.
Events during the session can influence which language(s) are used,
and the participants are not strictly bound to only use the declared
languages.
6.13. framerate (frame rate) 6.13. framerate (frame rate)
Name: framerate Name: framerate
Value: framerate-value Value: framerate-value
Usage Level: media Usage Level: media
Charset Dependent: no Charset Dependent: no
skipping to change at page 39, line 31 skipping to change at page 39, line 33
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
the session. the session.
One transport that can be used to distribute session descriptions is One transport that can be used to distribute session descriptions is
the Session Announcement Protocol (SAP). SAP provides both the SAP. SAP provides both encryption and authentication mechanisms,
encryption and authentication mechanisms, but due to the nature of but due to the nature of session announcements it is likely that
session announcements it is likely that there are many occasions there are many occasions where the originator of a session
where the originator of a session announcement cannot be announcement cannot be authenticated because the originator is
authenticated because the originator is previously unknown to the previously unknown to the receiver of the announcement and because no
receiver of the announcement and because no common public key common public key infrastructure is available.
infrastructure is available.
On receiving a session description over an unauthenticated transport On receiving a session description over an unauthenticated transport
mechanism or from an untrusted party, software parsing the session mechanism or from an untrusted party, software parsing the session
should take a few precautions. Session descriptions contain should take a few precautions. Session descriptions contain
information required to start software on the receiver's system. information required to start software on the receiver's system.
Software that parses a session description MUST NOT be able to start Software that parses a session description MUST NOT be able to start
other software except that which is specifically configured as other software except that which is specifically configured as
appropriate software to participate in multimedia sessions. It is appropriate software to participate in multimedia sessions. It is
normally considered inappropriate for software parsing a session normally considered inappropriate for software parsing a session
description to start, on a user's system, software that is description to start, on a user's system, software that is
skipping to change at page 43, line 21 skipping to change at page 44, line 21
Registrations MUST reference an RFC describing the protocol. Such an Registrations MUST reference an RFC describing the protocol. Such an
RFC MAY be Experimental or Informational, although it is preferable RFC MAY be Experimental or Informational, although it is preferable
that it be Standards Track. Registrations MUST also define the rules that it be Standards Track. Registrations MUST also define the rules
by which their "fmt" namespace is managed (see below). by which their "fmt" namespace is managed (see below).
8.2.3. Media Formats ("fmt") 8.2.3. Media Formats ("fmt")
Each transport protocol, defined by the "proto" field, has an Each transport protocol, defined by the "proto" field, has an
associated "fmt" namespace that describes the media formats that may associated "fmt" namespace that describes the media formats that may
be conveyed by that protocol. Formats cover all the possible be conveyed by that protocol. Formats cover all the possible
encodings that might want to be transported in a multimedia session. encodings that could be transported in a multimedia session.
RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST
use the payload type number as their "fmt" value. If the payload use the payload type number as their "fmt" value. If the payload
type number is dynamically assigned by this session description, an type number is dynamically assigned by this session description, an
additional "rtpmap" attribute MUST be included to specify the format additional "rtpmap" attribute MUST be included to specify the format
name and parameters as defined by the media type registration for the name and parameters as defined by the media type registration for the
payload format. It is RECOMMENDED that other RTP profiles that are payload format. It is RECOMMENDED that other RTP profiles that are
registered (in combination with RTP) as SDP transport protocols registered (in combination with RTP) as SDP transport protocols
specify the same rules for the "fmt" namespace. specify the same rules for the "fmt" namespace.
skipping to change at page 44, line 52 skipping to change at page 45, line 52
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 Submitters of registrations should also carefully choose the
attribute usage level. They should not choose only session-level attribute usage level. They should not choose only "session" when
when the attribute can have different values when media is the attribute can have different values when media is disaggregated,
disaggregated, i.e., when each m= section has its own IP address on a i.e., when each m= section has its own IP address on a different
different endpoint. In that case the attribute type chosen should be endpoint. In that case the attribute type chosen should be "session,
"session, media". media". The default rule is that for all new SDP attributes that can
occur both in session and media level, the media level overrides the
session level. When this is not the case for a new SDP attribute, it
should be explicitly stated.
IANA has registered the initial set of attribute names ("att-field" IANA has registered the initial set of attribute names ("att-field"
values), with definitions as in Section 6 of this memo (these values), with definitions as in Section 6 of this memo (these
definitions replace those in [RFC4566]). definitions replace those in [RFC4566]).
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
skipping to change at page 48, line 22 skipping to change at page 49, line 29
bandwidth-fields bandwidth-fields
time-fields time-fields
key-field key-field
attribute-fields attribute-fields
media-descriptions media-descriptions
proto-version = %s"v" "=" 1*DIGIT CRLF proto-version = %s"v" "=" 1*DIGIT CRLF
;this memo describes version 0 ;this memo describes version 0
origin-field = %s"o" "=" username SP sess-id SP sess-version SP origin-field = %s"o" "=" username SP sess-id SP sess-version SP
nettype SP addrtype SP unicast-address CRLF nettype SP addrtype SP unicast-address CRLF
session-name-field = %s"s" "=" text CRLF session-name-field = %s"s" "=" text CRLF
information-field = [%s"i" "=" text CRLF] information-field = [%s"i" "=" text CRLF]
uri-field = [%s"u" "=" uri CRLF] uri-field = [%s"u" "=" uri CRLF]
email-fields = *(%s"e" "=" email-address CRLF) email-fields = *(%s"e" "=" email-address CRLF)
phone-fields = *(%s"p" "=" phone-number CRLF) phone-fields = *(%s"p" "=" phone-number CRLF)
skipping to change at page 52, line 26 skipping to change at page 53, line 31
;default is to interpret this as UTF8 text. ;default is to interpret this as UTF8 text.
;ISO 8859-1 requires "a=charset:ISO-8859-1" ;ISO 8859-1 requires "a=charset:ISO-8859-1"
;session-level attribute to be used ;session-level attribute to be used
byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF)
;any byte except NUL, CR, or LF ;any byte except NUL, CR, or LF
non-ws-string = 1*(VCHAR/%x80-FF) non-ws-string = 1*(VCHAR/%x80-FF)
;string of visible characters ;string of visible characters
token-char = ALPHA / DIGIT token-char = ALPHA / DIGIT
/ "!" / "#" / "$" / "%" / "&" / / "!" / "#" / "$" / "%" / "&"
/ "'" ; (single quote) / "'" ; (single quote)
/ "*" / "+" / "-" / "." / "^" / "_" / "*" / "+" / "-" / "." / "^" / "_"
/ "`" ; (Grave accent) / "`" ; (Grave accent)
/ "{" / "|" / "}" / "~" / "{" / "|" / "}" / "~"
zero-based-integer = "0" / integer
token = 1*(token-char) token = 1*(token-char)
email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF
;any byte except NUL, CR, LF, or the quoting ;any byte except NUL, CR, LF, or the quoting
;characters ()<> ;characters ()<>
integer = POS-DIGIT *DIGIT integer = POS-DIGIT *DIGIT
non-zero-int-or-real = integer / non-zero-real zero-based-integer = "0" / integer
non-zero-real = (integer / "0") "." *DIGIT POS-DIGIT non-zero-int-or-real = integer / non-zero-real
non-zero-real = zero-based-integer "." *DIGIT POS-DIGIT
; generic sub-rules: primitives ; generic sub-rules: primitives
alpha-numeric = ALPHA / DIGIT alpha-numeric = ALPHA / DIGIT
POS-DIGIT = %x31-39 ; 1 - 9 POS-DIGIT = %x31-39 ; 1 - 9
decimal-uchar = DIGIT decimal-uchar = DIGIT
/ POS-DIGIT DIGIT / POS-DIGIT DIGIT
/ ("1" 2*(DIGIT)) / ("1" 2*(DIGIT))
/ ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT)
/ ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5"))
; external references: ; external references:
; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 5234 ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 5234
; URI-reference: from RFC 3986 ; URI-reference: from RFC 3986
; addr-spec: from RFC 5322 ; addr-spec: from RFC 5322
skipping to change at page 53, line 42 skipping to change at page 55, line 4
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.
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. contributing to this document.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66,
3986, January 2005. RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009. Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
September 2009, <http://www.rfc-editor.org/info/rfc5646>.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010. RFC 5890, DOI 10.17487/RFC5890, August 2010,
<http://www.rfc-editor.org/info/rfc5890>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[I-D.ietf-avtext-rtp-grouping-taxonomy] [I-D.ietf-avtext-rtp-grouping-taxonomy]
Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
"A Taxonomy of Grouping Semantics and Mechanisms for Real- B. Burman, "A Taxonomy of Semantics and Mechanisms for
Time Transport Protocol (RTP) Sources", draft-ietf-avtext- Real-Time Transport Protocol (RTP) Sources", draft-ietf-
rtp-grouping-taxonomy-06 (work in progress), March 2015. avtext-rtp-grouping-taxonomy-08 (work in progress), July
2015.
[I-D.iana-charset-reg-procedure] [I-D.iana-charset-reg-procedure]
McFadden, M. and A. Melnikov, "IANA Charset Registration McFadden, M. and A. Melnikov, "IANA Charset Registration
Procedures", draft-iana-charset-reg-procedure-01 (work in Procedures", draft-iana-charset-reg-procedure-01 (work in
progress), April 2015. progress), April 2015.
[I-D.ietf-mmusic-sdp-mux-attributes] [I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-08 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-10
(work in progress), January 2015. (work in progress), July 2015.
12.2. Informative References 12.2. Informative References
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, DOI 10.17487/RFC2327, April 1998,
<http://www.rfc-editor.org/info/rfc2327>.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974,
October 2000, <http://www.rfc-editor.org/info/rfc2974>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326,
DOI 10.17487/RFC2326, April 1998,
<http://www.rfc-editor.org/info/rfc2326>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June with Session Description Protocol (SDP)", RFC 3264,
2002. DOI 10.17487/RFC3264, June 2002,
<http://www.rfc-editor.org/info/rfc3264>.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010. Protocol (SDP) Grouping Framework", RFC 5888,
DOI 10.17487/RFC5888, June 2010,
<http://www.rfc-editor.org/info/rfc5888>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003. DOI 10.17487/RFC3551, July 2003,
<http://www.rfc-editor.org/info/rfc3551>.
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC Modifiers for RTP Control Protocol (RTCP) Bandwidth",
3556, July 2003. RFC 3556, DOI 10.17487/RFC3556, July 2003,
<http://www.rfc-editor.org/info/rfc3556>.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605, October in Session Description Protocol (SDP)", RFC 3605,
2003. DOI 10.17487/RFC3605, October 2003,
<http://www.rfc-editor.org/info/rfc3605>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004. Initiation Protocol (SIP)", RFC 3840,
DOI 10.17487/RFC3840, August 2004,
<http://www.rfc-editor.org/info/rfc3840>.
[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)",
3890, September 2004. RFC 3890, DOI 10.17487/RFC3890, September 2004,
<http://www.rfc-editor.org/info/rfc3890>.
[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,
2010. DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>.
[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
"TCP Candidates with Interactive Connectivity "TCP Candidates with Interactive Connectivity
Establishment (ICE)", RFC 6544, March 2012. Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544,
March 2012, <http://www.rfc-editor.org/info/rfc6544>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
7405, December 2014. RFC 7405, DOI 10.17487/RFC7405, December 2014,
<http://www.rfc-editor.org/info/rfc7405>.
[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
Protocol (RTSP)", RFC 4567, July 2006. Protocol (RTSP)", RFC 4567, DOI 10.17487/RFC4567, July
2006, <http://www.rfc-editor.org/info/rfc4567>.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006. Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006,
<http://www.rfc-editor.org/info/rfc4568>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008. DOI 10.17487/RFC5322, October 2008,
<http://www.rfc-editor.org/info/rfc5322>.
[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,
6838, January 2013. RFC 6838, DOI 10.17487/RFC6838, January 2013,
<http://www.rfc-editor.org/info/rfc6838>.
[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, DOI 10.17487/RFC4855, February 2007,
<http://www.rfc-editor.org/info/rfc4855>.
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
skipping to change at page 57, line 33 skipping to change at page 59, line 33
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
School of Computing Science School of Computing Science
University of Glasgow University of Glasgow
Glasgow G12 8QQ Glasgow G12 8QQ
UK UK
EMail: csp@csperkins.org EMail: csp@csperkins.org
Ali Begen Ali Begen
Cisco Unaffiliated
181 Bay Street
Toronto, ON M5J 2T3
Canada
EMail: abegen@cisco.com EMail: acbegen@gmail.com
 End of changes. 81 change blocks. 
204 lines changed or deleted 225 lines changed or added

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