draft-ietf-mmusic-rfc4566bis-02.txt   draft-ietf-mmusic-rfc4566bis-03.txt 
Network Working Group M. Handley Network Working Group M. Handley
Internet-Draft UCL Internet-Draft UCL
Obsoletes: 4566 (if approved) V. Jacobson Obsoletes: 4566 (if approved) V. Jacobson
Intended status: Standards Track Packet Design Intended status: Standards Track Packet Design
Expires: September 10, 2009 C. Perkins Expires: November 6, 2011 C. Perkins
University of Glasgow University of Glasgow
March 9, 2009 A. Begen
Cisco
May 5, 2011
SDP: Session Description Protocol SDP: Session Description Protocol
draft-ietf-mmusic-rfc4566bis-02.txt draft-ietf-mmusic-rfc4566bis-03
Abstract
This memo defines the Session Description Protocol (SDP). SDP is
intended for describing multimedia sessions for the purposes of
session announcement, session invitation, and other forms of
multimedia session initiation.
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on November 6, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 10, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2011 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This memo defines the Session Description Protocol (SDP). SDP is This document may contain material from IETF Documents or IETF
intended for describing multimedia sessions for the purposes of Contributions published or made publicly available before November
session announcement, session invitation, and other forms of 10, 2008. The person(s) controlling the copyright in some of this
multimedia session initiation. material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4
3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . . 5 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . . 5
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 5 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 5
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
skipping to change at page 3, line 19 skipping to change at page 3, line 21
8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 36 8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 36
8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 36 8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 36
8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 38 8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 38
8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 38 8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 38
8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . . 38 8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . . 38
8.2.8. Registration Procedure . . . . . . . . . . . . . . . . 39 8.2.8. Registration Procedure . . . . . . . . . . . . . . . . 39
8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 39 8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 39
9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 39 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 39
10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . . 44 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . . 44
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
12.1. Normative References . . . . . . . . . . . . . . . . . . . 45 12.1. Normative References . . . . . . . . . . . . . . . . . . . 46
12.2. Informative References . . . . . . . . . . . . . . . . . . 46 12.2. Informative References . . . . . . . . . . . . . . . . . . 46
1. Introduction 1. Introduction
When initiating multimedia teleconferences, voice-over-IP calls, When initiating multimedia teleconferences, voice-over-IP calls,
streaming video, or other sessions, there is a requirement to convey streaming video, or other sessions, there is a requirement to convey
media details, transport addresses, and other session description media details, transport addresses, and other session description
metadata to the participants. metadata to the participants.
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 [14], appropriate, including the Session Announcement Protocol [RFC2974],
Session Initiation Protocol [15], Real Time Streaming Protocol [16], Session Initiation Protocol [RFC3261], Real Time Streaming Protocol
electronic mail using the MIME extensions, and the Hypertext [RFC2326], electronic mail using the MIME extensions, and the
Transport Protocol. Hypertext Transport Protocol.
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 RFC 4566 [12]. The changes relative to RFC 4566 This memo obsoletes [RFC4566]. The changes relative to [RFC4566] are
are limited to essential corrections, and are outlined in Section 10 limited to essential corrections, and are outlined in Section 10 of
of this memo. this memo.
2. Glossary of Terms 2. Glossary of Terms
The following terms are used in this document and have specific The following terms are used in this document and have specific
meaning within the context of this document. meaning within the context of this document.
Conference: A multimedia conference is a set of two or more Conference: A multimedia conference is a set of two or more
communicating users along with the software they are using to communicating users along with the software they are using to
communicate. communicate.
Session: A multimedia session is a set of multimedia senders and Session: A multimedia session is a set of multimedia senders and
receivers and the data streams flowing from senders to receivers. receivers and the data streams flowing from senders to receivers.
A multimedia conference is an example of a multimedia session. A multimedia conference is an example of a multimedia session.
Session Description: A well-defined format for conveying sufficient Session Description: A well-defined format for conveying sufficient
information to discover and participate in a multimedia session. information to discover and participate in a multimedia session.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [3]. "OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
3. Examples of SDP Usage 3. Examples of SDP Usage
3.1. Session Initiation 3.1. Session Initiation
The Session Initiation Protocol (SIP) [15] is an application-layer The Session Initiation Protocol (SIP) [RFC3261] is an application-
control protocol for creating, modifying, and terminating sessions layer control protocol for creating, modifying, and terminating
such as Internet multimedia conferences, Internet telephone calls, sessions such as Internet multimedia conferences, Internet telephone
and multimedia distribution. The SIP messages used to create calls, and multimedia distribution. The SIP messages used to create
sessions carry session descriptions that allow participants to agree sessions carry session descriptions that allow participants to agree
on a set of compatible media types. These session descriptions are on a set of compatible media types. These session descriptions are
commonly formatted using SDP. When used with SIP, the offer/answer commonly formatted using SDP. When used with SIP, the offer/answer
model [17] provides a limited framework for negotiation using SDP. model [RFC3264] provides a limited framework for negotiation using
SDP.
3.2. Streaming Media 3.2. Streaming Media
The Real Time Streaming Protocol (RTSP) [16], is an application-level The Real Time Streaming Protocol (RTSP) [RFC2326], is an application-
protocol for control over the delivery of data with real-time level protocol for control over the delivery of data with real-time
properties. RTSP provides an extensible framework to enable properties. RTSP provides an extensible framework to enable
controlled, on-demand delivery of real-time data, such as audio and controlled, on-demand delivery of real-time data, such as audio and
video. An RTSP client and server negotiate an appropriate set of video. An RTSP client and server negotiate an appropriate set of
parameters for media delivery, partially using SDP syntax to describe parameters for media delivery, partially using SDP syntax to describe
those parameters. those parameters.
3.3. Email and the World Wide Web 3.3. Email and the World Wide Web
Alternative means of conveying session descriptions include Alternative means of conveying session descriptions include
electronic mail and the World Wide Web (WWW). For both email and WWW electronic mail and the World Wide Web (WWW). For both email and WWW
skipping to change at page 6, line 6 skipping to change at page 6, line 7
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) [14]. SDP provides the Session Announcement Protocol (SAP) [RFC2974]. SDP provides the
recommended session description format for such session recommended session description 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 conferences in other network environments. Media streams describe conferences in other network environments. Media streams
skipping to change at page 8, line 12 skipping to change at page 8, line 14
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. Private Sessions
It is possible to create both public sessions and private sessions. It is possible to create both public sessions and private sessions.
SDP itself does not distinguish between these; private sessions are SDP itself does not distinguish between these; private sessions are
typically conveyed by encrypting the session description during typically conveyed by encrypting the session description during
distribution. The details of how encryption is performed are distribution. The details of how encryption is performed are
dependent on the mechanism used to convey SDP; mechanisms are dependent on the mechanism used to convey SDP; mechanisms are
currently defined for SDP transported using SAP [14] and SIP [15], currently defined for SDP transported using SAP [RFC2974] and SIP
and others may be defined in the future. [RFC3261], and others may be defined in the future.
If a session announcement is private, it is possible to use that If a session announcement is private, it is possible to use that
private announcement to convey encryption keys necessary to decode private announcement to convey encryption keys necessary to decode
each of the media in a conference, including enough information to each of the media in a conference, including enough information to
know which encryption scheme is used for each media. know which encryption scheme is used for each media.
4.4. Obtaining Further Information about a Session 4.4. Obtaining Further Information about a Session
A session description should convey enough information to decide A session description should 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
skipping to change at page 8, line 38 skipping to change at page 8, line 40
When many session descriptions are being distributed by SAP, or any When many session descriptions are being distributed by SAP, or any
other advertisement mechanism, it may be desirable to filter session other advertisement mechanism, it may be desirable to filter session
announcements that are of interest from those that are not. SDP announcements that are of interest from those that are not. SDP
supports a categorisation mechanism for sessions that is capable of supports a categorisation mechanism for sessions that is capable of
being automated (the "a=cat:" attribute; see Section 6). being automated (the "a=cat:" attribute; see Section 6).
4.6. Internationalisation 4.6. Internationalisation
The SDP specification recommends the use of the ISO 10646 character The SDP specification recommends the use of the ISO 10646 character
set in the UTF-8 encoding [5] to allow many different languages to be set in the UTF-8 encoding [RFC3629] to allow many different languages
represented. However, to assist in compact representations, SDP also to be represented. However, to assist in compact representations,
allows other character sets such as ISO 8859-1 to be used when SDP also allows other character sets such as ISO 8859-1 to be used
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 session description is denoted by the media type "application/
sdp" (See Section 8). sdp" (See Section 8).
An SDP session description is entirely textual. SDP field names and An SDP session 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
skipping to change at page 11, line 10 skipping to change at page 11, line 10
The connection ("c=") and attribute ("a=") information in the The connection ("c=") and attribute ("a=") information in the
session-level section applies to all the media of that session unless session-level section applies to all the media of that session unless
overridden by connection information or an attribute of the same name overridden by connection information or an attribute of the same name
in the media description. For instance, in the example below, each in the media description. For instance, in the example below, each
media behaves as if it were given a "recvonly" attribute. media behaves as if it were given a "recvonly" attribute.
An example SDP description is: An example SDP description is:
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 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 224.2.17.12/127 c=IN IP4 233.252.0.1/127
t=2873397496 2873404696 t=2873397496 2873404696
a=recvonly a=recvonly
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99 m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000 a=rtpmap:99 h263-1998/90000
Text fields such as the session name and information are octet Text fields such as the session name and information are octet
strings that may contain any octet with the exceptions of 0x00 (Nul), strings that may contain any octet with the exceptions of 0x00 (Nul),
0x0a (ASCII newline), and 0x0d (ASCII carriage return). The sequence 0x0a (ASCII newline), and 0x0d (ASCII carriage return). The sequence
CRLF (0x0d0a) is used to end a record, although parsers SHOULD be CRLF (0x0d0a) is used to end a record, although parsers SHOULD be
tolerant and also accept records terminated with a single newline tolerant and also accept records terminated with a single newline
character. If the "a=charset" attribute is not present, these octet character. If the "a=charset" attribute is not present, these octet
strings MUST be interpreted as containing ISO-10646 characters in strings MUST be interpreted as containing ISO-10646 characters in
UTF-8 encoding (the presence of the "a=charset" attribute may force UTF-8 encoding (the presence of the "a=charset" attribute may force
some fields to be interpreted differently). some fields to be interpreted differently).
A session description can contain domain names in the "o=", "u=", A session description can contain domain names in the "o=", "u=",
"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 [1], [2]. Internationalised domain names (IDNs) MUST be with [RFC1034], [RFC1035]. Internationalised domain names (IDNs)
represented using the ASCII Compatible Encoding (ACE) form defined in MUST be represented using the ASCII Compatible Encoding (ACE) form
[10] and MUST NOT be directly represented in UTF-8 or any other defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or
encoding (this requirement is for compatibility with RFC 2327 [6] and any other encoding (this requirement is for compatibility with
other early SDP-related standards, which predate the development of [RFC2327] and other early SDP-related standards, which predate the
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=")
skipping to change at page 12, line 17 skipping to change at page 12, line 17
<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>,
<sess-id>, <nettype>, <addrtype>, and <unicast-address> forms a <sess-id>, <nettype>, <addrtype>, and <unicast-address> forms a
globally unique identifier for the session. The method of globally unique identifier for the session. The method of
<sess-id> allocation is up to the creating tool, but it has been <sess-id> allocation is up to the creating tool, but it has been
suggested that a Network Time Protocol (NTP) format timestamp be suggested that a Network Time Protocol (NTP) format timestamp be
used to ensure uniqueness [13]. used to ensure uniqueness [RFC5905].
<sess-version> is a version number for this session description. <sess-version> is a version number for this session description.
Its usage is up to the creating tool, so long as <sess-version> is Its usage is up to the creating tool, so long as <sess-version> is
increased when a modification is made to the session data. Again, increased when a modification is made to the session data. Again,
it is RECOMMENDED that an NTP format timestamp is used. it is RECOMMENDED that an NTP format timestamp is used.
<nettype> is a text string giving the type of network. Initially <nettype> is a text string giving the type of network. Initially
"IN" is defined to have the meaning "Internet", but other values "IN" is defined to have the meaning "Internet", but other values
MAY be registered in the future (see Section 8). MAY be registered in the future (see Section 8).
skipping to change at page 13, line 48 skipping to change at page 13, line 48
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 [7]. A URI is a Uniform Resource Identifier as used by WWW clients
The URI should be a pointer to additional information about the [RFC3986]. The URI should be a pointer to additional information
session. This field is OPTIONAL, but if it is present it MUST be about the session. This field is OPTIONAL, but if it is present it
specified before the first media field. No more than one URI field MUST be specified before the first media field. No more than one URI
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.
skipping to change at page 14, line 37 skipping to change at page 14, line 37
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 RFC 2822 [29] name quoting convention is also allowed The alternative [RFC5322] name quoting convention is also allowed for
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>
skipping to change at page 15, line 47 skipping to change at page 15, line 47
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 224.2.36.42/127 c=IN IP4 233.252.0.1/127
IPv6 multicast does not use TTL scoping, and hence the TTL value MUST IPv6 multicast does not use TTL scoping, and hence the TTL value MUST
NOT be present for IPv6 multicast. It is expected that IPv6 scoped NOT be present for IPv6 multicast. It is expected that IPv6 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
skipping to change at page 16, line 21 skipping to change at page 16, line 21
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 224.2.1.1/127/3 c=IN IP4 233.252.0.1/127/3
would state that addresses 224.2.1.1, 224.2.1.2, and 224.2.1.3 are to would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3
be used at a TTL of 127. This is semantically identical to including are to be used at a TTL of 127. This is semantically identical to
multiple "c=" lines in a media description: including multiple "c=" lines in a media description:
c=IN IP4 224.2.1.1/127 c=IN IP4 233.252.0.1/127
c=IN IP4 224.2.1.2/127 c=IN IP4 233.252.0.2/127
c=IN IP4 224.2.1.3/127 c=IN IP4 233.252.0.3/127
Similarly, an IPv6 example would be: Similarly, an IPv6 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
skipping to change at page 17, line 13 skipping to change at page 17, line 13
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 [21], [25]): (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
to the bandwidth used (the "conference total" bandwidth). The to the bandwidth used (the "conference total" bandwidth). The
primary purpose of this is to give an approximate idea as to primary purpose of this is to give an approximate idea as to
whether two or more sessions can coexist simultaneously. When whether two or more sessions can coexist simultaneously. When
using the CT modifier with RTP, if several RTP sessions are part using the CT modifier with RTP, if several RTP sessions are part
of the conference, the conference total refers to total bandwidth of the conference, the conference total refers to total bandwidth
of all RTP sessions. of all RTP sessions.
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
[19]. [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
skipping to change at page 18, line 21 skipping to change at page 18, line 21
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.
The first and second sub-fields give the start and stop times, The first and second sub-fields give the start and stop times,
respectively, for the session. These values are the decimal respectively, for the session. These values are the decimal
representation of Network Time Protocol (NTP) time values in seconds representation of Network Time Protocol (NTP) time values in seconds
since 1900 [13]. To convert these values to UNIX time, subtract since 1900 [RFC5905]. To convert these values to UNIX time, subtract
decimal 2208988800. decimal 2208988800.
NTP timestamps are elsewhere represented by 64-bit values, which wrap NTP timestamps are elsewhere represented by 64-bit values, which wrap
sometime in the year 2036. Since SDP uses an arbitrary length sometime in the year 2036. Since SDP uses an arbitrary length
decimal representation, this should not cause an issue (SDP decimal representation, this should not cause an issue (SDP
timestamps MUST continue counting seconds since 1900, NTP will use timestamps MUST continue counting seconds since 1900, NTP will use
the value modulo the 64-bit limit). the value modulo the 64-bit limit).
If the <stop-time> is set to zero, then the session is not bounded, If the <stop-time> is set to zero, then the session is not bounded,
though it will not become active until after the <start-time>. If though it will not become active until after the <start-time>. If
skipping to change at page 20, line 39 skipping to change at page 20, line 39
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 [27] [28], and to define new key exchange mechanisms for use with SDP [RFC4567]
it is expected that new applications will use those mechanisms. [RFC4568], and it is expected that new applications will use those
mechanisms.
A key field is permitted before the first media entry (in which case A key field is permitted before the first media entry (in which case
it applies to all media in the session), or for each media entry as it applies to all media in the session), or for each media entry as
required. The format of keys and their usage are outside the scope required. The format of keys and their usage are outside the scope
of this document, and the key field provides no way to indicate the of this document, and the key field provides no way to indicate the
encryption algorithm to be used, key type, or other information about encryption algorithm to be used, key type, or other information about
the key: this is assumed to be provided by the higher-level protocol the key: this is assumed to be provided by the higher-level protocol
using SDP. If there is a need to convey this information within SDP, using SDP. If there is a need to convey this information within SDP,
the extensions mentioned previously SHOULD be used. Many security the extensions mentioned previously SHOULD be used. Many security
protocols require two keys: one for confidentiality, another for protocols require two keys: one for confidentiality, another for
skipping to change at page 21, line 21 skipping to change at page 21, line 21
The encryption key is included untransformed in this key field. The encryption key is included untransformed in this key field.
This method MUST NOT be used unless it can be guaranteed that This method MUST NOT be used unless it can be guaranteed that
the SDP is conveyed over a secure channel. The encryption key the SDP is conveyed over a secure channel. The encryption key
is interpreted as text according to the charset attribute; use is interpreted as text according to the charset attribute; use
the "k=base64:" method to convey characters that are otherwise the "k=base64:" method to convey characters that are otherwise
prohibited in SDP. prohibited in SDP.
k=base64:<encoded encryption key> k=base64:<encoded encryption key>
The encryption key is included in this key field but has been The encryption key is included in this key field but has been
base64 encoded [11] because it includes characters that are base64 encoded [RFC4648] because it includes characters that
prohibited in SDP. This method MUST NOT be used unless it can are prohibited in SDP. This method MUST NOT be used unless it
be guaranteed that the SDP is conveyed over a secure channel. can be guaranteed that the SDP is conveyed over a secure
channel.
k=uri:<URI to obtain key> k=uri:<URI to obtain key>
A Uniform Resource Identifier is included in the key field. A Uniform Resource Identifier is included in the key field.
The URI refers to the data containing the key, and may require The URI refers to the data containing the key, and may require
additional authentication before the key can be returned. When additional authentication before the key can be returned. When
a request is made to the given URI, the reply should specify a request is made to the given URI, the reply should specify
the encoding for the key. The URI is often an Secure Socket the encoding for the key. The URI is often an Secure Socket
Layer/Transport Layer Security (SSL/TLS)-protected HTTP URI Layer/Transport Layer Security (SSL/TLS)-protected HTTP URI
("https:"), although this is not required. ("https:"), although this is not required.
skipping to change at page 23, line 23 skipping to change at page 23, line 24
<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).
<port> is the transport port to which the media stream is sent. The <port> is the transport port to which the media stream is sent. The
meaning of the transport port depends on the network being used as meaning of the transport port depends on the network being used as
specified in the relevant "c=" field, and on the transport specified in the relevant "c=" field, and on the transport
protocol defined in the <proto> sub-field of the media field. protocol defined in the <proto> sub-field of the media field.
Other ports used by the media application (such as the RTP Control Other ports used by the media application (such as the RTP Control
Protocol (RTCP) port [19]) MAY be derived algorithmically from the Protocol (RTCP) port [RFC3550]) MAY be derived algorithmically
base media port or MAY be specified in a separate attribute (for from the base media port or MAY be specified in a separate
example, "a=rtcp:" as defined in [22]). attribute (for example, "a=rtcp:" as defined in [RFC3605]).
If non-contiguous ports are used or if they don't follow the If non-contiguous ports are used or if they don't follow the
parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:"
attribute MUST be used. Applications that are requested to send attribute MUST be used. Applications that are requested to send
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
skipping to change at page 24, line 8 skipping to change at page 24, line 8
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 [22]). separate attribute (for example, "a=rtcp:" as defined in
[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 224.2.1.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 224.2.1.1 is used with ports 49170 and would imply that address 233.252.0.1 is used with ports 49170 and
49171, and address 224.2.1.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, [18]) should instead an explicit grouping framework (for example, [RFC5888]) should
be used to express the intended semantics. instead be used to express the intended semantics.
<proto> is the transport protocol. The meaning of the transport <proto> is the transport protocol. The meaning of the transport
protocol is dependent on the address type field in the relevant protocol is dependent on the address type field in the relevant
"c=" field. Thus a "c=" field of IP4 indicates that the transport "c=" field. Thus a "c=" field of IP4 indicates that the transport
protocol runs over IP4. The following transport protocols are protocol runs over IP4. The following transport protocols are
defined, but may be extended through registration of new protocols defined, but may be extended through registration of new protocols
with IANA (see Section 8): with IANA (see Section 8):
* udp: denotes an unspecified protocol running over UDP. * udp: denotes an unspecified protocol running over UDP.
* RTP/AVP: denotes RTP [19] used under the RTP Profile for Audio * RTP/AVP: denotes RTP [RFC3550] used under the RTP Profile for
and Video Conferences with Minimal Control [20] running over Audio and Video Conferences with Minimal Control [RFC3551]
UDP.
* RTP/SAVP: denotes the Secure Real-time Transport Protocol [23]
running over UDP. running over UDP.
* RTP/SAVP: denotes the Secure Real-time Transport Protocol
[RFC3711] running over UDP.
The main reason to specify the transport protocol in addition to The main reason to specify the transport protocol in addition to
the media format is that the same standard media formats may be the media format is that the same standard media formats may be
carried over different transport protocols even when the network carried over different transport protocols even when the network
protocol is the same -- a historical example is vat Pulse Code protocol is the same -- a historical example is vat Pulse Code
Modulation (PCM) audio and RTP PCM audio; another might be TCP/RTP Modulation (PCM) audio and RTP PCM audio; another might be TCP/RTP
PCM audio. In addition, relays and monitoring tools that are PCM audio. In addition, relays and monitoring tools that are
transport-protocol-specific but format-independent are possible. transport-protocol-specific but format-independent are possible.
<fmt> is a media format description. The fourth and any subsequent <fmt> is a media format description. The fourth and any subsequent
sub-fields describe the format of the media. The interpretation sub-fields describe the format of the media. The interpretation
skipping to change at page 26, line 34 skipping to change at page 26, line 34
a=maxptime:<maximum packet time> a=maxptime:<maximum packet time>
This gives the maximum amount of media that can be encapsulated This gives the maximum amount of media that can be encapsulated
in each packet, expressed as time in milliseconds. The time in each packet, expressed as time in milliseconds. The time
SHALL be calculated as the sum of the time the media present in SHALL be calculated as the sum of the time the media present in
the packet represents. For frame-based codecs, the time SHOULD the packet represents. For frame-based codecs, the time SHOULD
be an integer multiple of the frame size. This attribute is be an integer multiple of the frame size. This attribute is
probably only meaningful for audio data, but may be used with probably only meaningful for audio data, but may be used with
other media types if it makes sense. It is a media-level other media types if it makes sense. It is a media-level
attribute, and it is not dependent on charset. Note that this attribute, and it is not dependent on charset. Note that this
attribute was introduced after RFC 2327 [6], and non-updated attribute was introduced after [RFC2327], and non-updated
implementations will ignore this attribute. implementations will ignore this attribute.
a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding
parameters>] parameters>]
This attribute maps from an RTP payload type number (as used in This attribute maps from an RTP payload type number (as used in
an "m=" line) to an encoding name denoting the payload format an "m=" line) to an encoding name denoting the payload format
to be used. It also provides information on the clock rate and to be used. It also provides information on the clock rate and
encoding parameters. It is a media-level attribute that is not encoding parameters. It is a media-level attribute that is not
dependent on charset. dependent on charset.
skipping to change at page 29, line 25 skipping to change at page 29, line 25
This specifies the type of the conference. Suggested values This specifies the type of the conference. Suggested values
are "broadcast", "meeting", "moderated", "test", and "H332". are "broadcast", "meeting", "moderated", "test", and "H332".
"recvonly" should be the default for "type:broadcast" sessions, "recvonly" should be the default for "type:broadcast" sessions,
"type:meeting" should imply "sendrecv", and "type:moderated" "type:meeting" should imply "sendrecv", and "type:moderated"
should indicate the use of a floor control tool and that the should indicate the use of a floor control tool and that the
media tools are started so as to mute new sites joining the media tools are started so as to mute new sites joining the
conference. conference.
Specifying the attribute "type:H332" indicates that this Specifying the attribute "type:H332" indicates that this
loosely coupled session is part of an H.332 session as defined loosely coupled session is part of an H.332 session as defined
in the ITU H.332 specification [26]. Media tools should be in the ITU H.332 specification [ITU.H332.1998]. Media tools
started "recvonly". should be started "recvonly".
Specifying the attribute "type:test" is suggested as a hint Specifying the attribute "type:test" is suggested as a hint
that, unless explicitly requested otherwise, receivers can that, unless explicitly requested otherwise, receivers can
safely avoid displaying this session description to users. safely avoid displaying this session description to users.
The type attribute is a session-level attribute, and it is not The type attribute is a session-level attribute, and it is not
dependent on charset. dependent on charset.
a=charset:<character set> a=charset:<character set>
skipping to change at page 30, line 28 skipping to change at page 30, line 28
attributes can be provided either at session or media level if attributes can be provided either at session or media level if
the session description or media use multiple languages. the session description or media use multiple languages.
In general, sending session descriptions consisting of multiple In general, sending session descriptions consisting of multiple
languages is discouraged. Instead, multiple descriptions languages is discouraged. Instead, multiple descriptions
SHOULD be sent describing the session, one in each language. SHOULD be sent describing the session, one in each language.
However, this is not possible with all transport mechanisms, However, this is not possible with all transport mechanisms,
and so multiple sdplang attributes are allowed although NOT and so multiple sdplang attributes are allowed although NOT
RECOMMENDED. RECOMMENDED.
The "sdplang" attribute value must be a single RFC 4646 The "sdplang" attribute value must be a single [RFC5646]
language tag in US-ASCII [9]. It is not dependent on the language tag in US-ASCII. It is not dependent on the charset
charset attribute. An "sdplang" attribute SHOULD be specified attribute. An "sdplang" attribute SHOULD be specified when a
when a session is distributed with sufficient scope to cross session is distributed with sufficient scope to cross
geographic boundaries, where the language of recipients cannot geographic boundaries, where the language of recipients cannot
be assumed, or where the session is in a different language be assumed, or where the session is in a different language
from the locally assumed norm. from the locally assumed norm.
a=lang:<language tag> a=lang:<language tag>
This can be a session-level attribute or a media-level This can be a session-level attribute or a media-level
attribute. As a session-level attribute, it specifies the attribute. As a session-level attribute, it specifies the
default language for the session being described. As a media- default language for the session being described. As a media-
level attribute, it specifies the language for that media, level attribute, it specifies the language for that media,
overriding any session-level language specified. Multiple lang overriding any session-level language specified. Multiple lang
attributes can be provided either at session or media level if attributes can be provided either at session or media level if
the session or media use multiple languages, in which case the the session or media use multiple languages, in which case the
order of the attributes indicates the order of importance of order of the attributes indicates the order of importance of
the various languages in the session or media, from most the various languages in the session or media, from most
important to least important. important to least important.
The "lang" attribute value must be a single RFC 4646 language The "lang" attribute value must be a single [RFC5646] language
tag in US-ASCII [9]. It is not dependent on the charset tag in US-ASCII. It is not dependent on the charset attribute.
attribute. A "lang" attribute SHOULD be specified when a A "lang" attribute SHOULD be specified when a session is of
session is of sufficient scope to cross geographic boundaries sufficient scope to cross geographic boundaries where the
where the language of recipients cannot be assumed, or where language of recipients cannot be assumed, or where the session
the session is in a different language from the locally assumed is in a different language from the locally assumed norm.
norm.
a=framerate:<frame rate> a=framerate:<frame rate>
This gives the maximum video frame rate in frames/sec. It is This gives the maximum video frame rate in frames/sec. It is
intended as a recommendation for the encoding of video data. intended as a recommendation for the encoding of video data.
Decimal representations of fractional values using the notation Decimal representations of fractional values using the notation
"<integer>.<fraction>" are allowed. It is a media-level "<integer>.<fraction>" are allowed. It is a media-level
attribute, defined only for video media, and it is not attribute, defined only for video media, and it is not
dependent on charset. dependent on charset.
skipping to change at page 31, line 49 skipping to change at page 31, line 48
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.
7. Security Considerations 7. Security Considerations
SDP is frequently used with the Session Initiation Protocol [15] SDP is frequently used with the Session Initiation Protocol [RFC3261]
using the offer/answer model [17] to agree on parameters for unicast using the offer/answer model [RFC3264] to agree on parameters for
sessions. When used in this manner, the security considerations of unicast sessions. When used in this manner, the security
those protocols apply. considerations of those protocols apply.
SDP is a session description format that describes multimedia SDP is a session description format that describes multimedia
sessions. Entities receiving and acting upon an SDP message SHOULD sessions. Entities receiving and acting upon an SDP message SHOULD
be aware that a session description cannot be trusted unless it has be aware that a session description cannot be trusted unless it has
been obtained by an authenticated transport protocol from a known and been obtained by an authenticated transport protocol from a known and
trusted source. Many different transport protocols may be used to trusted source. Many different transport protocols may be used to
distribute session descriptions, and the nature of the authentication distribute session descriptions, and the nature of the authentication
will differ from transport to transport. For some transports, will differ from transport to transport. For some transports,
security features are often not deployed. In case a session security features are often not deployed. In case a session
description has not been obtained in a trusted manner, the endpoint description has not been obtained in a trusted manner, the endpoint
skipping to change at page 33, line 43 skipping to change at page 33, line 41
Moreover, the "k=" line provides no way to indicate or negotiate Moreover, the "k=" line provides no way to indicate or negotiate
cryptographic key algorithms. As it provides for only a single cryptographic key algorithms. As it provides for only a single
symmetric key, rather than separate keys for confidentiality and symmetric key, rather than separate keys for confidentiality and
integrity, its utility is severely limited. The use of the "k=" line integrity, its utility is severely limited. The use of the "k=" line
is NOT RECOMMENDED, as discussed in Section 5.12. is NOT RECOMMENDED, as discussed in Section 5.12.
8. IANA Considerations 8. IANA Considerations
8.1. The "application/sdp" Media Type 8.1. The "application/sdp" Media Type
One media type registration from RFC 4566 is to be updated, as One media type registration from [RFC4566] is to be updated, as
defined below. defined below.
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of media type "application/sdp" Subject: Registration of media type "application/sdp"
Type name: application Type name: application
Subtype name: sdp Subtype name: sdp
Required parameters: None. Required parameters: None.
skipping to change at page 34, line 24 skipping to change at page 34, line 24
Optional parameters: None. Optional parameters: None.
Encoding considerations: Encoding considerations:
SDP files are primarily UTF-8 format text. The "a=charset:" SDP files are primarily UTF-8 format text. The "a=charset:"
attribute may be used to signal the presence of other character attribute may be used to signal the presence of other character
sets in certain parts of an SDP file (see Section 6 of RFC sets in certain parts of an SDP file (see Section 6 of RFC
XXXX). Arbitrary binary content cannot be directly XXXX). Arbitrary binary content cannot be directly
represented in SDP. represented in SDP.
Security considerations: Security considerations:
See Section 7 of RFC XXXX See Section 7 of RFC XXXX.
Interoperability considerations: Interoperability considerations:
See RFC XXXX See RFC XXXX.
Published specification: Published specification:
See RFC XXXX See RFC XXXX.
Applications which use this media type: Applications which use this media type:
Voice over IP, video teleconferencing, streaming media, instant Voice over IP, video teleconferencing, streaming media, instant
messaging, among others. See also Section 3 of RFC XXXX. messaging, among others. See also Section 3 of RFC XXXX.
Additional information: Additional information:
Magic number(s): None. Magic number(s): None.
File extension(s): The extension ".sdp" is commonly used. File extension(s): The extension ".sdp" is commonly used.
Macintosh File Type Code(s): "sdp " Macintosh File Type Code(s): "sdp "
skipping to change at page 35, line 22 skipping to change at page 35, line 22
8.2.1. Media Types ("media") 8.2.1. Media Types ("media")
The set of media types is intended to be small and SHOULD NOT be The set of media types is intended to be small and SHOULD NOT be
extended except under rare circumstances. The same rules should extended except under rare circumstances. The same rules should
apply for media names as for top-level media content types, and where apply for media names as for top-level media content types, and where
possible the same name should be registered for SDP as for MIME. For possible the same name should be registered for SDP as for MIME. For
media other than existing top-level media content types, a Standards media other than existing top-level media content types, a Standards
Track RFC MUST be produced for a new top-level content type to be Track RFC MUST be produced for a new top-level content type to be
registered, and the registration MUST provide good justification why registered, and the registration MUST provide good justification why
no existing media name is appropriate (the "Standards Action" policy no existing media name is appropriate (the "Standards Action" policy
of RFC 2434 [8]. of [RFC5226].
This memo registers the media types "audio", "video", "text", This memo registers the media types "audio", "video", "text",
"application", and "message". "application", and "message".
Note: The media types "control" and "data" were listed as valid in an Note: The media types "control" and "data" were listed as valid in an
early version of this specification [6]; however, their semantics early version of this specification [RFC2327]; however, their
were never fully specified and they are not widely used. These media semantics were never fully specified and they are not widely used.
types have been removed in this specification, although they still These media types have been removed in this specification, although
remain valid media type capabilities for a SIP user agent as defined they still remain valid media type capabilities for a SIP user agent
in RFC 3840 [24]. If these media types are considered useful in the as defined in [RFC3840]. If these media types are considered useful
future, a Standards Track RFC MUST be produced to document their use. in the future, a Standards Track RFC MUST be produced to document
Until that is done, applications SHOULD NOT use these types and their use. Until that is done, applications SHOULD NOT use these
SHOULD NOT declare support for them in SIP capabilities declarations types and SHOULD NOT declare support for them in SIP capabilities
(even though they exist in the registry created by RFC 3840). declarations (even though they exist in the registry created by
[RFC3840]).
8.2.2. Transport Protocols ("proto") 8.2.2. Transport Protocols ("proto")
The "proto" field describes the transport protocol used. This SHOULD The "proto" field describes the transport protocol used. This SHOULD
reference a standards-track protocol RFC. This memo registers three reference a standards-track protocol RFC. This memo registers three
values: "RTP/AVP" is a reference to RTP [19] used under the RTP values: "RTP/AVP" is a reference to [RFC3550] used under the RTP
Profile for Audio and Video Conferences with Minimal Control [20] Profile for Audio and Video Conferences with Minimal Control
running over UDP/IP, "RTP/SAVP" is a reference to the Secure Real- [RFC3551] running over UDP/IP, "RTP/SAVP" is a reference to the
time Transport Protocol [23], and "udp" indicates an unspecified Secure Real-time Transport Protocol [RFC3711], and "udp" indicates an
protocol over UDP. unspecified protocol over UDP.
If other RTP profiles are defined in the future, their "proto" name If other RTP profiles are defined in the future, their "proto" name
SHOULD be specified in the same manner. For example, an RTP profile SHOULD be specified in the same manner. For example, an RTP profile
whose short name is "XYZ" would be denoted by a "proto" field of whose short name is "XYZ" would be denoted by a "proto" field of
"RTP/XYZ". "RTP/XYZ".
New transport protocols SHOULD be registered with IANA. New transport protocols SHOULD be registered with IANA.
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
skipping to change at page 36, line 30 skipping to change at page 36, line 30
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.
For the "udp" protocol, new formats SHOULD be registered. Use of an For the "udp" protocol, new formats SHOULD be registered. Use of an
existing media subtype for the format is encouraged. If no media existing media subtype for the format is encouraged. If no media
subtype exists, it is RECOMMENDED that a suitable one be registered subtype exists, it is RECOMMENDED that a suitable one be registered
through the IETF process [30] by production of, or reference to, a through the IETF process [RFC4288] by production of, or reference to,
standards-track RFC that defines the transport protocol for the a standards-track RFC that defines the transport protocol for the
format. format.
For other protocols, formats MAY be registered according to the rules For other protocols, formats MAY be registered according to the rules
of the associated "proto" specification. of the associated "proto" specification.
Registrations of new formats MUST specify which transport protocols Registrations of new formats MUST specify which transport protocols
they apply to. they apply to.
8.2.4. Attribute Names ("att-field") 8.2.4. Attribute Names ("att-field")
Attribute field names ("att-field") MUST be registered with IANA and Attribute field names ("att-field") MUST be registered with IANA and
documented, because of noticeable issues due to conflicting documented, because of noticeable issues due to conflicting
attributes under the same name. Unknown attributes in SDP are simply attributes under the same name. Unknown attributes in SDP are simply
ignored, but conflicting ones that fragment the protocol are a ignored, but conflicting ones that fragment the protocol are a
serious problem. serious problem.
New attribute registrations are accepted according to the New attribute registrations are accepted according to the
"Specification Required" policy of RFC 2434, provided that the "Specification Required" policy of [RFC5226], provided that the
specification includes the following information: specification includes the following information:
o contact name, email address, and telephone number o contact name, email address, and telephone number
o attribute name (as it will appear in SDP) o attribute name (as it will appear in SDP)
o long-form attribute name in English o long-form attribute name in English
o type of attribute (session level, media level, or both) o type of attribute (session level, media level, or both)
skipping to change at page 37, line 32 skipping to change at page 37, line 32
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.
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 RFC 4566): (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
skipping to change at page 38, line 18 skipping to change at page 38, line 18
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.
IANA has registered the bandwidth specifiers "CT" and "AS" with IANA has registered the bandwidth specifiers "CT" and "AS" with
definitions as in Section 5.8 of this memo (these definitions update definitions as in Section 5.8 of this memo (these definitions update
those in RFC 4566). those in [RFC4566]).
8.2.6. Network Types ("nettype") 8.2.6. Network Types ("nettype")
New network types (the "nettype" field) may be registered with IANA New network types (the "nettype" field) may be registered with IANA
if SDP needs to be used in the context of non-Internet environments. if SDP needs to be used in the context of non-Internet environments.
Although these are not normally the preserve of IANA, there may be Although these are not normally the preserve of IANA, there may be
circumstances when an Internet application needs to interoperate with circumstances when an Internet application needs to interoperate with
a non-Internet application, such as when gatewaying an Internet a non-Internet application, such as when gatewaying an Internet
telephone call into the Public Switched Telephone Network (PSTN). telephone call into the Public Switched Telephone Network (PSTN).
The number of network types should be small and should be rarely The number of network types should be small and should be rarely
extended. A new network type cannot be registered without extended. A new network type cannot be registered without
registering at least one address type to be used with that network registering at least one address type to be used with that network
type. A new network type registration MUST reference an RFC that type. A new network type registration MUST reference an RFC that
gives details of the network type and address type and specifies how gives details of the network type and address type and specifies how
and when they would be used. and when they would be used.
IANA has registered the network type "IN" to represent the Internet, IANA has registered the network type "IN" to represent the Internet,
with definition as in Sections 5.2 and 5.7 of this memo (these with definition as in Sections 5.2 and 5.7 of this memo (these
definitions update those in RFC 4566). definitions update those in [RFC4566]).
8.2.7. Address Types ("addrtype") 8.2.7. Address Types ("addrtype")
New address types ("addrtype") may be registered with IANA. An New address types ("addrtype") may be registered with IANA. An
address type is only meaningful in the context of a network type, and address type is only meaningful in the context of a network type, and
any registration of an address type MUST specify a registered network any registration of an address type MUST specify a registered network
type or be submitted along with a network type registration. A new type or be submitted along with a network type registration. A new
address type registration MUST reference an RFC giving details of the address type registration MUST reference an RFC giving details of the
syntax of the address type. Address types are not expected to be syntax of the address type. Address types are not expected to be
registered frequently. registered frequently.
IANA has registered the address types "IP4" and "IP6" with IANA has registered the address types "IP4" and "IP6" with
definitions as in Sections 5.2 and 5.7 of this memo (these definitions as in Sections 5.2 and 5.7 of this memo (these
definitions update those in RFC 4566). definitions update those in [RFC4566]).
8.2.8. Registration Procedure 8.2.8. Registration Procedure
In the RFC documentation that registers SDP "media", "proto", "fmt", In the RFC documentation that registers SDP "media", "proto", "fmt",
"bwtype", "nettype", and "addrtype" fields, the authors MUST include "bwtype", "nettype", and "addrtype" fields, the authors MUST include
the following information for IANA to place in the appropriate the following information for IANA to place in the appropriate
registry: registry:
o contact name, email address, and telephone number o contact name, email address, and telephone number
skipping to change at page 39, line 38 skipping to change at page 39, line 38
8.3. Encryption Key Access Methods 8.3. Encryption Key Access Methods
The IANA previously maintained a table of SDP encryption key access The IANA previously maintained a table of SDP encryption key access
method ("enckey") names. This table is obsolete, since the "k=" line method ("enckey") names. This table is obsolete, since the "k=" line
is not extensible. New registrations MUST NOT be accepted. is not extensible. New registrations MUST NOT be accepted.
9. SDP Grammar 9. SDP Grammar
This section provides an Augmented BNF grammar for SDP. ABNF is This section provides an Augmented BNF grammar for SDP. ABNF is
defined in [4]. defined in [RFC5234].
; SDP Syntax ; SDP Syntax
session-description = proto-version session-description = proto-version
origin-field origin-field
session-name-field session-name-field
information-field information-field
uri-field uri-field
email-fields email-fields
phone-fields phone-fields
connection-field connection-field
skipping to change at page 41, line 26 skipping to change at page 41, line 26
nettype = token nettype = token
;typically "IN" ;typically "IN"
addrtype = token addrtype = token
;typically "IP4" or "IP6" ;typically "IP4" or "IP6"
; sub-rules of 'u=' ; sub-rules of 'u='
uri = URI-reference uri = URI-reference
; see RFC 3986 ; see RFC 3986
; sub-rules of 'e=', see RFC 2822 for definitions ; sub-rules of 'e=', see RFC 5322 for definitions
email-address = address-and-comment / dispname-and-address email-address = address-and-comment / dispname-and-address
/ addr-spec / addr-spec
address-and-comment = addr-spec 1*SP "(" 1*email-safe ")" address-and-comment = addr-spec 1*SP "(" 1*email-safe ")"
dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">" dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">"
; sub-rules of 'p=' ; sub-rules of 'p='
phone-number = phone *SP "(" 1*email-safe ")" / phone-number = phone *SP "(" 1*email-safe ")" /
1*email-safe "<" phone ">" / 1*email-safe "<" phone ">" /
phone phone
skipping to change at page 44, line 35 skipping to change at page 44, line 35
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 4234 ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 5234
; URI-reference: from RFC 3986 ; URI-reference: from RFC 3986
; addr-spec: from RFC 2822 ; addr-spec: from RFC 5322
10. Summary of Changes from RFC 4566 10. Summary of Changes from RFC 4566
The ABNF rule for IP6-address has been corrected. As a result, the The ABNF rule for IP6-address has been corrected. As a result, the
ABNF rule for IP6-multicast has changed, and the (now unused) rules ABNF rule for IP6-multicast has changed, and the (now unused) rules
for hexpart, hexseq, and hex4 have been removed. for hexpart, hexseq, and hex4 have been removed.
IPv4 unicast and multicast addresses in the example SDP descriptions
have been revised per RFCs 5735 and 5771.
Normative and informative references have been updated.
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
use the US-ASCII subset of UTF-8). use the US-ASCII subset of UTF-8).
o Section 5: clarify that an SDP session description can contain o Section 5: clarify that an SDP session description can contain
only a session-level section, with no media-level section, and only a session-level section, with no media-level section, and
that a media-level section can be terminated by the end of the that a media-level section can be terminated by the end of the
skipping to change at page 45, line 48 skipping to change at page 46, line 7
Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross
Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna, Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna,
Jonathan Lennox, Keith Drage, Sean Olson, Bernie Hoeneisen, Jonathan Jonathan Lennox, Keith Drage, Sean Olson, Bernie Hoeneisen, Jonathan
Rosenberg, John Elwell, Flemming Andreasen, Jon Peterson, Spencer Rosenberg, John Elwell, Flemming Andreasen, Jon Peterson, Spencer
Dawkins, and Alfred Hoenes. Dawkins, and Alfred Hoenes.
12. References 12. References
12.1. Normative References 12.1. Normative References
[1] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and
STD 13, RFC 1034, November 1987. facilities", STD 13, RFC 1034, November 1987.
[2] 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, November 1987.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for
Specifications: ABNF", RFC 4234, October 2005. Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008.
[5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[6] Handley, M. and V. Jacobson, "SDP: Session Description [RFC2327] Handley, M. and V. Jacobson, "SDP: Session
Protocol", RFC 2327, April 1998. Description Protocol", RFC 2327, April 1998.
[7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, "Uniform Resource Identifier (URI): Generic Syntax",
January 2005. STD 66, RFC 3986, January 2005.
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for
Considerations Section in RFCs", BCP 26, RFC 2434, Writing an IANA Considerations Section in RFCs",
October 1998. BCP 26, RFC 5226, May 2008.
[9] Phillips, A. and M. Davis, "Tags for Identifying Languages", [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
BCP 47, RFC 4646, September 2006. Languages", BCP 47, RFC 5646, September 2009.
[10] Faltstrom, P., Hoffman, P., and A. Costello, [RFC5890] Klensin, J., "Internationalized Domain Names for
"Internationalizing Domain Names in Applications (IDNA)", Applications (IDNA): Definitions and Document
RFC 3490, March 2003. Framework", RFC 5890, August 2010.
[11] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
RFC 3548, July 2003. Encodings", RFC 4648, October 2006.
[12] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP:
Description Protocol", RFC 4566, July 2006. Session Description Protocol", RFC 4566, July 2006.
12.2. Informative References 12.2. Informative References
[13] Mills, D., "Network Time Protocol (Version 3) Specification, [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch,
Implementation", RFC 1305, March 1992. "Network Time Protocol Version 4: Protocol and
Algorithms Specification", RFC 5905, June 2010.
[14] Handley, M., Perkins, C., and E. Whelan, "Session Announcement [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[15] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Johnston, A., Peterson, J., Sparks, R., Handley, M.,
Session Initiation Protocol", RFC 3261, June 2002. and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[16] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real
Protocol (RTSP)", RFC 2326, April 1998. Time Streaming Protocol (RTSP)", RFC 2326,
April 1998.
[17] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer
Session Description Protocol (SDP)", RFC 3264, June 2002. Model with Session Description Protocol (SDP)",
RFC 3264, June 2002.
[18] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session
"Grouping of Media Lines in the Session Description Protocol Description Protocol (SDP) Grouping Framework",
(SDP)", RFC 3388, December 2002. RFC 5888, June 2010.
[19] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
"RTP: A Transport Protocol for Real-Time Applications", STD 64, Jacobson, "RTP: A Transport Protocol for Real-Time
RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[20] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for
Conferences with Minimal Control", STD 65, RFC 3551, July 2003. Audio and Video Conferences with Minimal Control",
STD 65, RFC 3551, July 2003.
[21] Casner, S., "Session Description Protocol (SDP) Bandwidth [RFC3556] Casner, S., "Session Description Protocol (SDP)
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, Bandwidth Modifiers for RTP Control Protocol (RTCP)
July 2003. Bandwidth", RFC 3556, July 2003.
[22] Huitema, C., "Real Time Control Protocol (RTCP) attribute in [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP)
Session Description Protocol (SDP)", RFC 3605, October 2003. attribute in Session Description Protocol (SDP)",
RFC 3605, October 2003.
[23] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E.,
Norrman, "The Secure Real-time Transport Protocol (SRTP)", and K. Norrman, "The Secure Real-time Transport
RFC 3711, March 2004. Protocol (SRTP)", RFC 3711, March 2004.
[24] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
User Agent Capabilities in the Session Initiation Protocol "Indicating User Agent Capabilities in the Session
(SIP)", RFC 3840, August 2004. Initiation Protocol (SIP)", RFC 3840, August 2004.
[25] Westerlund, M., "A Transport Independent Bandwidth Modifier for [RFC3890] Westerlund, M., "A Transport Independent Bandwidth
the Session Description Protocol (SDP)", RFC 3890, Modifier for the Session Description Protocol
September 2004. (SDP)", RFC 3890, September 2004.
[26] International Telecommunication Union, "H.323 extended for [ITU.H332.1998] International Telecommunication Union, "H.323
loosely coupled conferences", ITU Recommendation H.332, extended for loosely coupled conferences",
September 1998. ITU Recommendation H.332, September 1998.
[27] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K.,
Norrman, "Key Management Extensions for Session Description and E. Carrara, "Key Management Extensions for
Protocol (SDP) and Real Time Streaming Protocol (RTSP)", Session Description Protocol (SDP) and Real Time
RFC 4567, July 2006. Streaming Protocol (RTSP)", RFC 4567, July 2006.
[28] Andreasen, F., Baugher, M., and D. Wing, "Session Description [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Protocol (SDP) Security Descriptions for Media Streams", Description Protocol (SDP) Security Descriptions for
RFC 4568, July 2006. Media Streams", RFC 4568, July 2006.
[29] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC5322] Resnick, P., Ed., "Internet Message Format",
RFC 5322, October 2008.
[30] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications
Registration Procedures", BCP 13, RFC 4288, December 2005. and Registration Procedures", BCP 13, RFC 4288,
December 2005.
Authors' Addresses Authors' Addresses
Mark Handley Mark Handley
University College London University College London
Department of Computer Science Department of Computer Science
Gower Street Gower Street
London WC1E 6BT London WC1E 6BT
UK UK
skipping to change at page 48, line 26 skipping to change at page 49, line 4
EMail: M.Handley@cs.ucl.ac.uk EMail: M.Handley@cs.ucl.ac.uk
Van Jacobson Van Jacobson
Packet Design Packet Design
2465 Latham Street 2465 Latham Street
Mountain View, CA 94040 Mountain View, CA 94040
USA USA
EMail: van@packetdesign.com EMail: van@packetdesign.com
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
Department of Computing Science Department of Computing Science
17 Lilybank Gardens 17 Lilybank Gardens
Glasgow G12 8QQ Glasgow G12 8QQ
UK UK
EMail: csp@csperkins.org EMail: csp@csperkins.org
Ali Begen
Cisco
181 Bay Street
Toronto, ON M5J 2T3
Canada
EMail: abegen@cisco.com
 End of changes. 96 change blocks. 
228 lines changed or deleted 248 lines changed or added

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