draft-ietf-mmusic-rfc4566bis-07.txt   draft-ietf-mmusic-rfc4566bis-08.txt 
Network Working Group M. Handley Network Working Group M. Handley
Internet-Draft UCL Internet-Draft UCL
Obsoletes: 4566 (if approved) V. Jacobson Obsoletes: 4566 (if approved) V. Jacobson
Intended status: Standards Track PARC Intended status: Standards Track PARC
Expires: August 29, 2013 C. Perkins Expires: September 12, 2013 C.S. Perkins
University of Glasgow University of Glasgow
A. Begen A. Begen
Cisco Cisco
February 25, 2013 March 11, 2013
SDP: Session Description Protocol SDP: Session Description Protocol
draft-ietf-mmusic-rfc4566bis-07 draft-ietf-mmusic-rfc4566bis-08
Abstract Abstract
This memo defines the Session Description Protocol (SDP). SDP is This memo defines the Session Description Protocol (SDP). SDP is
intended for describing multimedia sessions for the purposes of intended for describing multimedia sessions for the purposes of
session announcement, session invitation, and other forms of session announcement, session invitation, and other forms of
multimedia session initiation. This document obsoletes RFC 4566. multimedia session initiation. This document obsoletes RFC 4566.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 29, 2013. This Internet-Draft will expire on September 12, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 23 skipping to change at page 2, line 23
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4
3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . . 5 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . . 4
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 5 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 4
3.2. Streaming Media . . . . . . . . . . . . . . . . . . . . . 5 3.2. Streaming Media . . . . . . . . . . . . . . . . . . . . . 4
3.3. Email and the World Wide Web . . . . . . . . . . . . . . . 5 3.3. Email and the World Wide Web . . . . . . . . . . . . . . 4
3.4. Multicast Session Announcement . . . . . . . . . . . . . . 5 3.4. Multicast Session Announcement . . . . . . . . . . . . . 5
4. Requirements and Recommendations . . . . . . . . . . . . . . . 6 4. Requirements and Recommendations . . . . . . . . . . . . . . 5
4.1. Media and Transport Information . . . . . . . . . . . . . 7 4.1. Media and Transport Information . . . . . . . . . . . . . 6
4.2. Timing Information . . . . . . . . . . . . . . . . . . . . 7 4.2. Timing Information . . . . . . . . . . . . . . . . . . . 7
4.3. Private Sessions . . . . . . . . . . . . . . . . . . . . . 8 4.3. Private Sessions . . . . . . . . . . . . . . . . . . . . 7
4.4. Obtaining Further Information about a Session . . . . . . 8 4.4. Obtaining Further Information about a Session . . . . . . 7
4.5. Categorisation . . . . . . . . . . . . . . . . . . . . . . 8 4.5. Categorisation . . . . . . . . . . . . . . . . . . . . . 7
4.6. Internationalisation . . . . . . . . . . . . . . . . . . . 8 4.6. Internationalisation . . . . . . . . . . . . . . . . . . 8
5. SDP Specification . . . . . . . . . . . . . . . . . . . . . . 8 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Protocol Version ("v=") . . . . . . . . . . . . . . . . . 11 5.1. Protocol Version ("v=") . . . . . . . . . . . . . . . . . 11
5.2. Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 13 5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 12
5.4. Session Information ("i=") . . . . . . . . . . . . . . . . 13 5.4. Session Information ("i=") . . . . . . . . . . . . . . . 13
5.5. URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 13 5.5. URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . 13
5.6. Email Address and Phone Number ("e=" and "p=") . . . . . . 14 5.6. Email Address and Phone Number ("e=" and "p=") . . . . . 13
5.7. Connection Data ("c=") . . . . . . . . . . . . . . . . . . 14 5.7. Connection Data ("c=") . . . . . . . . . . . . . . . . . 14
5.8. Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 17 5.8. Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . 17
5.9. Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 18 5.9. Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 18
5.10. Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . 19 5.10. Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . 19
5.11. Time Zones ("z=") . . . . . . . . . . . . . . . . . . . . 19 5.11. Time Zones ("z=") . . . . . . . . . . . . . . . . . . . . 19
5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . . 20 5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 20
5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 22 5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 22
5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 23 5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 23
6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . . 25 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
8.1. The "application/sdp" Media Type . . . . . . . . . . . . . 33 8.1. The "application/sdp" Media Type . . . . . . . . . . . . 35
8.2. Registration of Parameters . . . . . . . . . . . . . . . . 35 8.2. Registration of Parameters . . . . . . . . . . . . . . . 36
8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 35 8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 36
8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 35 8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 36
8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 36 8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 37
8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 36 8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 38
8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 38 8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 39
8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 38 8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 39
8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . . 38 8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 40
8.2.8. Registration Procedure . . . . . . . . . . . . . . . . 39 8.2.8. Registration Procedure . . . . . . . . . . . . . . . 40
8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 39 8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 40
9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 39 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 40
10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . . 44 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 46
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
12.1. Normative References . . . . . . . . . . . . . . . . . . . 46 12.1. Normative References . . . . . . . . . . . . . . . . . . 47
12.2. Informative References . . . . . . . . . . . . . . . . . . 46 12.2. Informative References . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
When initiating multimedia teleconferences, voice-over-IP calls, When initiating multimedia teleconferences, voice-over-IP calls,
streaming video, or other sessions, there is a requirement to convey streaming video, or other sessions, there is a requirement to convey
media details, transport addresses, and other session description media details, transport addresses, and other session description
metadata to the participants. metadata to the participants.
SDP provides a standard representation for such information, SDP provides a standard representation for such information,
irrespective of how that information is transported. SDP is purely a irrespective of how that information is transported. SDP is purely a
skipping to change at page 9, line 27 skipping to change at page 8, line 48
damaged by an intermediate caching server, the encoding was designed damaged by an intermediate caching server, the encoding was designed
with strict order and formatting rules so that most errors would with strict order and formatting rules so that most errors would
result in malformed session announcements that could be detected result in malformed session announcements that could be detected
easily and discarded. This also allows rapid discarding of encrypted easily and discarded. This also allows rapid discarding of encrypted
session announcements for which a receiver does not have the correct session announcements for which a receiver does not have the correct
key. key.
An SDP session description consists of a number of lines of text of An SDP session description consists of a number of lines of text of
the form: the form:
<type>=<value> <type>=<value>
where <type> MUST be exactly one case-significant character and where <type> MUST be exactly one case-significant character and
<value> is structured text whose format depends on <type>. In <value> is structured text whose format depends on <type>. In
general, <value> is either a number of fields delimited by a single general, <value> is either a number of fields delimited by a single
space character or a free format string, and is case-significant space character or a free format string, and is case-significant
unless a specific field defines otherwise. Whitespace MUST NOT be unless a specific field defines otherwise. Whitespace MUST NOT be
used on either side of the "=" sign. used on either side of the "=" sign.
An SDP session description consists of a session-level section An SDP session description consists of a session-level section
followed by zero or more media-level sections. The session-level followed by zero or more media-level sections. The session-level
part starts with a "v=" line and continues to the first media-level part starts with a "v=" line and continues to the first media-level
skipping to change at page 10, line 50 skipping to change at page 10, line 24
media. Some attributes (the ones listed in Section 6 of this memo) media. Some attributes (the ones listed in Section 6 of this memo)
have a defined meaning, but others may be added on an application-, have a defined meaning, but others may be added on an application-,
media-, or session-specific basis. An SDP parser MUST ignore any media-, or session-specific basis. An SDP parser MUST ignore any
attribute it doesn't understand. attribute it doesn't understand.
An SDP session description may contain URIs that reference external An SDP session description may contain URIs that reference external
content in the "u=", "k=", and "a=" lines. These URIs may be content in the "u=", "k=", and "a=" lines. These URIs may be
dereferenced in some cases, making the session description non-self- dereferenced in some cases, making the session description non-self-
contained. contained.
The connection ("c=") and attribute ("a=") information in the The connection ("c=") information in the session-level section
session-level section applies to all the media of that session unless applies to all the media of that session unless overridden by
overridden by connection information or an attribute of the same name connection information in the media description. For instance, in
in the media description. For instance, in the example below, each the example below, each audio media behaves as if it were given a
media behaves as if it were given a "recvonly" attribute. "c=IN IP4 233.252.0.2".
An example SDP description is: An example SDP description is:
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1
s=SDP Seminar s=SDP Seminar
i=A Seminar on the session description protocol i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe) e=j.doe@example.com (Jane Doe)
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.2
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=audio 49180 RTP/AVP 0
a=rtpmap:99 h263-1998/90000 m=video 51372 RTP/AVP 99
c=IN IP4 233.252.0.1/127
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).
skipping to change at page 11, line 43 skipping to change at page 11, line 22
"e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply "e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply
with [RFC1034], [RFC1035]. Internationalised domain names (IDNs) with [RFC1034], [RFC1035]. Internationalised domain names (IDNs)
MUST be represented using the ASCII Compatible Encoding (ACE) form MUST be represented using the ASCII Compatible Encoding (ACE) form
defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or
any other encoding (this requirement is for compatibility with any other encoding (this requirement is for compatibility with
[RFC4566] and other early SDP-related standards, which predate the [RFC4566] and other early SDP-related standards, which predate the
development of internationalised domain names). development of internationalised domain names).
5.1. Protocol Version ("v=") 5.1. Protocol Version ("v=")
v=0 v=0
The "v=" field gives the version of the Session Description Protocol. The "v=" field gives the version of the Session Description Protocol.
This memo defines version 0. There is no minor version number. This memo defines version 0. There is no minor version number.
5.2. Origin ("o=") 5.2. Origin ("o=")
o=<username> <sess-id> <sess-version> <nettype> <addrtype> o=<username> <sess-id> <sess-version> <nettype> <addrtype>
<unicast-address> <unicast-address>
The "o=" field gives the originator of the session (her username and The "o=" field gives the originator of the session (her username and
the address of the user's host) plus a session identifier and version the address of the user's host) plus a session identifier and version
number: number:
<username> is the user's login on the originating host, or it is "-" <username> is the user's login on the originating host, or it is "-"
if the originating host does not support the concept of user IDs. if the originating host does not support the concept of user IDs.
The <username> MUST NOT contain spaces. The <username> MUST NOT contain spaces.
<sess-id> is a numeric string such that the tuple of <username>, <sess-id> is a numeric string such that the tuple of <username>,
<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-
<sess-id> allocation is up to the creating tool, but it has been 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 [RFC5905]. 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
skipping to change at page 13, line 13 skipping to change at page 12, line 47
modifications. modifications.
For privacy reasons, it is sometimes desirable to obfuscate the For privacy reasons, it is sometimes desirable to obfuscate the
username and IP address of the session originator. If this is a username and IP address of the session originator. If this is a
concern, an arbitrary <username> and private <unicast-address> MAY be concern, an arbitrary <username> and private <unicast-address> MAY be
chosen to populate the "o=" field, provided that these are selected chosen to populate the "o=" field, provided that these are selected
in a manner that does not affect the global uniqueness of the field. in a manner that does not affect the global uniqueness of the field.
5.3. Session Name ("s=") 5.3. Session Name ("s=")
s=<session name> s=<session name>
The "s=" field is the textual session name. There MUST be one and The "s=" field is the textual session name. There MUST be one and
only one "s=" field per session description. The "s=" field MUST NOT only one "s=" field per session description. The "s=" field MUST NOT
be empty and SHOULD contain ISO 10646 characters (but see also the be empty and SHOULD contain ISO 10646 characters (but see also the
"a=charset" attribute). If a session has no meaningful name, the "a=charset" attribute). If a session has no meaningful name, the
value "s= " SHOULD be used (i.e., a single space as the session value "s= " SHOULD be used (i.e., a single space as the session
name). name).
5.4. Session Information ("i=") 5.4. Session Information ("i=")
i=<session description> i=<session description>
The "i=" field provides textual information about the session. There The "i=" field provides textual information about the session. There
MUST be at most one session-level "i=" field per session description, MUST be at most one session-level "i=" field per session description,
and at most one "i=" field per media. If the "a=charset" attribute and at most one "i=" field per media. If the "a=charset" attribute
is present, it specifies the character set used in the "i=" field. is present, it specifies the character set used in the "i=" field.
If the "a=charset" attribute is not present, the "i=" field MUST If the "a=charset" attribute is not present, the "i=" field MUST
contain ISO 10646 characters in UTF-8 encoding. contain ISO 10646 characters in UTF-8 encoding.
A single "i=" field MAY also be used for each media definition. In A single "i=" field MAY also be used for each media definition. In
media definitions, "i=" fields are primarily intended for labelling media definitions, "i=" fields are primarily intended for labelling
skipping to change at page 13, line 46 skipping to change at page 13, line 32
single session has more than one distinct media stream of the same single session has more than one distinct media stream of the same
media type. An example would be two different whiteboards, one for media type. An example would be two different whiteboards, one for
slides and one for feedback and questions. slides and one for feedback and questions.
The "i=" field is intended to provide a free-form human-readable The "i=" field is intended to provide a free-form human-readable
description of the session or the purpose of a media stream. It is description of the session or the purpose of a media stream. It is
not suitable for parsing by automata. not suitable for parsing by automata.
5.5. URI ("u=") 5.5. URI ("u=")
u=<uri> u=<uri>
A URI is a Uniform Resource Identifier as used by WWW clients A URI is a Uniform Resource Identifier as used by WWW clients
[RFC3986]. The URI should be a pointer to additional information [RFC3986]. The URI should be a pointer to additional information
about the session. This field is OPTIONAL, but if it is present it about the session. This field is OPTIONAL, but if it is present it
MUST be specified before the first media field. No more than one URI MUST be specified before the first media field. No more than one URI
field is allowed per session description. field is allowed per session description.
5.6. Email Address and Phone Number ("e=" and "p=") 5.6. Email Address and Phone Number ("e=" and "p=")
e=<email-address> e=<email-address>
p=<phone-number> p=<phone-number>
The "e=" and "p=" lines specify contact information for the person The "e=" and "p=" lines specify contact information for the person
responsible for the session. This is not necessarily the same person responsible for the session. This is not necessarily the same person
that created the session description. that created the session description.
Inclusion of an email address or phone number is OPTIONAL. Note that Inclusion of an email address or phone number is OPTIONAL. Note that
the previous version of SDP specified that either an email field or a the previous version of SDP specified that either an email field or a
phone field MUST be specified, but this was widely ignored. The phone field MUST be specified, but this was widely ignored. The
change brings the specification into line with common usage. change brings the specification into line with common usage.
If an email address or phone number is present, it MUST be specified If an email address or phone number is present, it MUST be specified
before the first media field. More than one email or phone field can before the first media field. More than one email or phone field can
be given for a session description. be given for a session description.
Phone numbers SHOULD be given in the form of an international public Phone numbers SHOULD be given in the form of an international public
telecommunication number (see ITU-T Recommendation E.164) preceded by telecommunication number (see ITU-T Recommendation E.164) preceded by
a "+". Spaces and hyphens may be used to split up a phone field to a "+". Spaces and hyphens may be used to split up a phone field to
aid readability if desired. For example: aid readability if desired. For example:
p=+1 617 555-6011 p=+1 617 555-6011
Both email addresses and phone numbers can have an OPTIONAL free text Both email addresses and phone numbers can have an OPTIONAL free text
string associated with them, normally giving the name of the person string associated with them, normally giving the name of the person
who may be contacted. This MUST be enclosed in parentheses if it is who may be contacted. This MUST be enclosed in parentheses if it is
present. For example: present. For example:
e=j.doe@example.com (Jane Doe) e=j.doe@example.com (Jane Doe)
The alternative [RFC5322] name quoting convention is also allowed for The alternative [RFC5322] name quoting convention is also allowed for
both email addresses and phone numbers. For example: both email addresses and phone numbers. For example:
e=Jane Doe <j.doe@example.com> e=Jane Doe <j.doe@example.com>
The free text string SHOULD be in the ISO-10646 character set with The free text string SHOULD be in the ISO-10646 character set with
UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if
the appropriate session-level "a=charset" attribute is set. the appropriate session-level "a=charset" attribute is set.
5.7. Connection Data ("c=") 5.7. Connection Data ("c=")
c=<nettype> <addrtype> <connection-address> c=<nettype> <addrtype> <connection-address>
The "c=" field contains connection data. The "c=" field contains connection data.
A session description MUST contain either at least one "c=" field in A session description MUST contain either at least one "c=" field in
each media description or a single "c=" field at the session level. each media description or a single "c=" field at the session level.
It MAY contain a single session-level "c=" field and additional "c=" It MAY contain a single session-level "c=" field and additional "c="
field(s) per media description, in which case the per-media values field(s) per media description, in which case the per-media values
override the session-level settings for the respective media. override the session-level settings for the respective media.
The first sub-field ("<nettype>") is the network type, which is a The first sub-field ("<nettype>") is the network type, which is a
skipping to change at page 15, line 47 skipping to change at page 15, line 43
address. The TTL and the address together define the scope with address. The TTL and the address together define the scope with
which multicast packets sent in this session will be sent. TTL which multicast packets sent in this session will be sent. TTL
values MUST be in the range 0-255. Although the TTL MUST be values MUST be in the range 0-255. Although the TTL MUST be
specified, its use to scope multicast traffic is deprecated; specified, its use to scope multicast traffic is deprecated;
applications SHOULD use an administratively scoped address applications SHOULD use an administratively scoped address
instead. instead.
The TTL for the session is appended to the address using a slash as a The TTL for the session is appended to the address using a slash as a
separator. An example is: separator. An example is:
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
IP6 multicast does not use TTL scoping, and hence the TTL value MUST IP6 multicast does not use TTL scoping, and hence the TTL value MUST
NOT be present for IP6 multicast. It is expected that IP6 scoped NOT be present for IP6 multicast. It is expected that IP6 scoped
addresses will be used to limit the scope of conferences. addresses will be used to limit the scope of conferences.
Hierarchical or layered encoding schemes are data streams where the Hierarchical or layered encoding schemes are data streams where the
encoding from a single media source is split into a number of layers. encoding from a single media source is split into a number of layers.
The receiver can choose the desired quality (and hence bandwidth) by The receiver can choose the desired quality (and hence bandwidth) by
only subscribing to a subset of these layers. Such layered encodings only subscribing to a subset of these layers. Such layered encodings
are normally transmitted in multiple multicast groups to allow are normally transmitted in multiple multicast groups to allow
multicast pruning. This technique keeps unwanted traffic from sites multicast pruning. This technique keeps unwanted traffic from sites
only requiring certain levels of the hierarchy. For applications only requiring certain levels of the hierarchy. For applications
requiring multiple multicast groups, we allow the following notation requiring multiple multicast groups, we allow the following notation
to be used for the connection address: to be used for the connection address:
<base multicast address>[/<ttl>]/<number of addresses> <base multicast address>[/<ttl>]/<number of addresses>
If the number of addresses is not given, it is assumed to be one. If the number of addresses is not given, it is assumed to be one.
Multicast addresses so assigned are contiguously allocated above the Multicast addresses so assigned are contiguously allocated above the
base address, so that, for example: base address, so that, for example:
c=IN IP4 233.252.0.1/127/3 c=IN IP4 233.252.0.1/127/3
would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3 would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3
are to be used at a TTL of 127. This is semantically identical to are to be used at a TTL of 127. This is semantically identical to
including multiple "c=" lines in a media description: including multiple "c=" lines in a media description:
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
c=IN IP4 233.252.0.2/127 c=IN IP4 233.252.0.2/127
c=IN IP4 233.252.0.3/127 c=IN IP4 233.252.0.3/127
Similarly, an IP6 example would be: Similarly, an IP6 example would be:
c=IN IP6 FF15::101/3 c=IN IP6 FF15::101/3
which is semantically equivalent to: which is semantically equivalent to:
c=IN IP6 FF15::101 c=IN IP6 FF15::101
c=IN IP6 FF15::102 c=IN IP6 FF15::102
c=IN IP6 FF15::103 c=IN IP6 FF15::103
(remembering that the TTL field is not present in IP6 multicast). (remembering that the TTL field is not present in IP6 multicast).
Multiple addresses or "c=" lines MAY be specified on a per-media Multiple addresses or "c=" lines MAY be specified on a per-media
basis only if they provide multicast addresses for different layers basis only if they provide multicast addresses for different layers
in a hierarchical or layered encoding scheme. They MUST NOT be in a hierarchical or layered encoding scheme. They MUST NOT be
specified for a session-level "c=" field. specified for a session-level "c=" field.
The slash notation for multiple addresses described above MUST NOT be The slash notation for multiple addresses described above MUST NOT be
used for IP unicast addresses. used for IP unicast addresses.
5.8. Bandwidth ("b=") 5.8. Bandwidth ("b=")
b=<bwtype>:<bandwidth> b=<bwtype>:<bandwidth>
This OPTIONAL field denotes the proposed bandwidth to be used by the This OPTIONAL field denotes the proposed bandwidth to be used by the
session or media. The <bwtype> is an alphanumeric modifier giving session or media. The <bwtype> is an alphanumeric modifier giving
the meaning of the <bandwidth> figure. Two values are defined in the meaning of the <bandwidth> figure. Two values are defined in
this specification, but other values MAY be registered in the future this specification, but other values MAY be registered in the future
(see Section 8 and [RFC3556], [RFC3890]): (see Section 8 and [RFC3556], [RFC3890]):
CT If the bandwidth of a session or media in a session is different CT If the bandwidth of a session or media in a session is different
from the bandwidth implicit from the scope, a "b=CT:..." line from the bandwidth implicit from the scope, a "b=CT:..." line
SHOULD be supplied for the session giving the proposed upper limit SHOULD be supplied for the session giving the proposed upper limit
skipping to change at page 17, line 39 skipping to change at page 17, line 39
gives the RTP "session bandwidth" as defined in Section 6.2 of gives the RTP "session bandwidth" as defined in Section 6.2 of
[RFC3550]. [RFC3550].
Note that CT gives a total bandwidth figure for all the media at all Note that CT gives a total bandwidth figure for all the media at all
sites. AS gives a bandwidth figure for a single media at a single sites. AS gives a bandwidth figure for a single media at a single
site, although there may be many sites sending simultaneously. site, although there may be many sites sending simultaneously.
A prefix "X-" is defined for <bwtype> names. This is intended for A prefix "X-" is defined for <bwtype> names. This is intended for
experimental purposes only. For example: experimental purposes only. For example:
b=X-YZ:128 b=X-YZ:128
Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers
SHOULD be registered with IANA in the standard namespace. SDP SHOULD be registered with IANA in the standard namespace. SDP
parsers MUST ignore bandwidth fields with unknown modifiers. parsers MUST ignore bandwidth fields with unknown modifiers.
Modifiers MUST be alphanumeric and, although no length limit is Modifiers MUST be alphanumeric and, although no length limit is
given, it is recommended that they be short. given, it is recommended that they be short.
The <bandwidth> is interpreted as kilobits per second by default. The <bandwidth> is interpreted as kilobits per second by default.
The definition of a new <bwtype> modifier MAY specify that the The definition of a new <bwtype> modifier MAY specify that the
bandwidth is to be interpreted in some alternative unit (the "CT" and bandwidth is to be interpreted in some alternative unit (the "CT" and
"AS" modifiers defined in this memo use the default units). "AS" modifiers defined in this memo use the default units).
5.9. Timing ("t=") 5.9. Timing ("t=")
t=<start-time> <stop-time> t=<start-time> <stop-time>
The "t=" lines specify the start and stop times for a session. The "t=" lines specify the start and stop times for a session.
Multiple "t=" lines MAY be used if a session is active at multiple Multiple "t=" lines MAY be used if a session is active at multiple
irregularly spaced times; each additional "t=" line specifies an irregularly spaced times; each additional "t=" line specifies an
additional period of time for which the session will be active. If additional period of time for which the session will be active. If
the session is active at regular times, an "r=" line (see below) the session is active at regular times, an "r=" line (see below)
should be used in addition to, and following, a "t=" line -- in which should be used in addition to, and following, a "t=" line -- in which
case the "t=" line specifies the start and stop times of the repeat case the "t=" line specifies the start and stop times of the repeat
sequence. sequence.
skipping to change at page 19, line 7 skipping to change at page 19, line 7
other than this is required, an end-time SHOULD be given and modified other than this is required, an end-time SHOULD be given and modified
as appropriate when new information becomes available about when the as appropriate when new information becomes available about when the
session should really end. session should really end.
Permanent sessions may be shown to the user as never being active Permanent sessions may be shown to the user as never being active
unless there are associated repeat times that state precisely when unless there are associated repeat times that state precisely when
the session will be active. the session will be active.
5.10. Repeat Times ("r=") 5.10. Repeat Times ("r=")
r=<repeat interval> <active duration> <offsets from start-time> r=<repeat interval> <active duration> <offsets from start-time>
"r=" fields specify repeat times for a session. For example, if a "r=" fields specify repeat times for a session. For example, if a
session is active at 10am on Monday and 11am on Tuesday for one hour session is active at 10am on Monday and 11am on Tuesday for one hour
each week for three months, then the <start-time> in the each week for three months, then the <start-time> in the
corresponding "t=" field would be the NTP representation of 10am on corresponding "t=" field would be the NTP representation of 10am on
the first Monday, the <repeat interval> would be 1 week, the <active the first Monday, the <repeat interval> would be 1 week, the <active
duration> would be 1 hour, and the offsets would be zero and 25 duration> would be 1 hour, and the offsets would be zero and 25
hours. The corresponding "t=" field stop time would be the NTP hours. The corresponding "t=" field stop time would be the NTP
representation of the end of the last session three months later. By representation of the end of the last session three months later. By
default, all fields are in seconds, so the "r=" and "t=" fields might default, all fields are in seconds, so the "r=" and "t=" fields might
be the following: be the following:
t=3034423619 3042462419 t=3034423619 3042462419
r=604800 3600 0 90000 r=604800 3600 0 90000
To make the description more compact, times may also be given in To make the description more compact, times may also be given in
units of days, hours, or minutes. The syntax for these is a number units of days, hours, or minutes. The syntax for these is a number
immediately followed by a single case-sensitive character. immediately followed by a single case-sensitive character.
Fractional units are not allowed -- a smaller unit should be used Fractional units are not allowed -- a smaller unit should be used
instead. The following unit specification characters are allowed: instead. The following unit specification characters are allowed:
d - days (86400 seconds) d - days (86400 seconds)
h - hours (3600 seconds) h - hours (3600 seconds)
m - minutes (60 seconds) m - minutes (60 seconds)
s - seconds (allowed for completeness) s - seconds (allowed for completeness)
Thus, the above session announcement could also have been written: Thus, the above session announcement could also have been written:
r=7d 1h 0 25h r=7d 1h 0 25h
Monthly and yearly repeats cannot be directly specified with a single Monthly and yearly repeats cannot be directly specified with a single
SDP repeat time; instead, separate "t=" fields should be used to SDP repeat time; instead, separate "t=" fields should be used to
explicitly list the session times. explicitly list the session times.
5.11. Time Zones ("z=") 5.11. Time Zones ("z=")
z=<adjustment time> <offset> <adjustment time> <offset> .... z=<adjustment time> <offset> <adjustment time> <offset> ....
To schedule a repeated session that spans a change from daylight To schedule a repeated session that spans a change from daylight
saving time to standard time or vice versa, it is necessary to saving time to standard time or vice versa, it is necessary to
specify offsets from the base time. This is required because specify offsets from the base time. This is required because
different time zones change time at different times of day, different different time zones change time at different times of day, different
countries change to or from daylight saving time on different dates, countries change to or from daylight saving time on different dates,
and some countries do not have daylight saving time at all. and some countries do not have daylight saving time at all.
Thus, in order to schedule a session that is at the same time winter Thus, in order to schedule a session that is at the same time winter
and summer, it must be possible to specify unambiguously by whose and summer, it must be possible to specify unambiguously by whose
time zone a session is scheduled. To simplify this task for time zone a session is scheduled. To simplify this task for
receivers, we allow the sender to specify the NTP time that a time receivers, we allow the sender to specify the NTP time that a time
zone adjustment happens and the offset from the time when the session zone adjustment happens and the offset from the time when the session
was first scheduled. The "z=" field allows the sender to specify a was first scheduled. The "z=" field allows the sender to specify a
list of these adjustment times and offsets from the base time. list of these adjustment times and offsets from the base time.
An example might be the following: An example might be the following:
z=2882844526 -1h 2898848070 0 z=2882844526 -1h 2898848070 0
This specifies that at time 2882844526, the time base by which the This specifies that at time 2882844526, the time base by which the
session's repeat times are calculated is shifted back by 1 hour, and session's repeat times are calculated is shifted back by 1 hour, and
that at time 2898848070, the session's original time base is that at time 2898848070, the session's original time base is
restored. Adjustments are always relative to the specified start restored. Adjustments are always relative to the specified start
time -- they are not cumulative. Adjustments apply to all "t=" and time -- they are not cumulative. Adjustments apply to all "t=" and
"r=" lines in a session description. "r=" lines in a session description.
If a session is likely to last several years, it is expected that the If a session is likely to last several years, it is expected that the
session description will be modified periodically rather than session description will be modified periodically rather than
transmit several years' worth of adjustments in one session transmit several years' worth of adjustments in one session
description. description.
5.12. Encryption Keys ("k=") 5.12. Encryption Keys ("k=")
k=<method> k=<method>
k=<method>:<encryption key> k=<method>:<encryption key>
If transported over a secure and trusted channel, the Session If transported over a secure and trusted channel, the Session
Description Protocol MAY be used to convey encryption keys. A simple Description Protocol MAY be used to convey encryption keys. A simple
mechanism for key exchange is provided by the key field ("k="), mechanism for key exchange is provided by the key field ("k="),
although this is primarily supported for compatibility with older although this is primarily supported for compatibility with older
implementations and its use is NOT RECOMMENDED. Work is in progress implementations and its use is NOT RECOMMENDED. Work is in progress
to define new key exchange mechanisms for use with SDP [RFC4567] to define new key exchange mechanisms for use with SDP [RFC4567]
[RFC4568], and it is expected that new applications will use those [RFC4568], and it is expected that new applications will use those
mechanisms. mechanisms.
skipping to change at page 22, line 8 skipping to change at page 22, line 16
SDP is conveyed over a secure and trusted channel. An example of SDP is conveyed over a secure and trusted channel. An example of
such a channel might be SDP embedded inside an S/MIME message or a such a channel might be SDP embedded inside an S/MIME message or a
TLS-protected HTTP session. It is important to ensure that the TLS-protected HTTP session. It is important to ensure that the
secure channel is with the party that is authorised to join the secure channel is with the party that is authorised to join the
session, not an intermediary: if a caching proxy server is used, it session, not an intermediary: if a caching proxy server is used, it
is important to ensure that the proxy is either trusted or unable to is important to ensure that the proxy is either trusted or unable to
access the SDP. access the SDP.
5.13. Attributes ("a=") 5.13. Attributes ("a=")
a=<attribute> a=<attribute>
a=<attribute>:<value> a=<attribute>:<value>
Attributes are the primary means for extending SDP. Attributes may Attributes are the primary means for extending SDP. Attributes may
be defined to be used as "session-level" attributes, "media-level" be defined to be used as "session-level" attributes, "media-level"
attributes, or both. attributes, or both.
A media description may have any number of attributes ("a=" fields) A media description may have any number of attributes ("a=" fields)
that are media specific. These are referred to as "media-level" that are media specific. These are referred to as "media-level"
attributes and add information about the media stream. Attribute attributes and add information about the media stream. Attribute
fields can also be added before the first media field; these fields can also be added before the first media field; these
"session-level" attributes convey additional information that applies "session-level" attributes convey additional information that applies
to the session as a whole rather than to individual media. to the session as a whole rather than to individual media.
Attribute fields may be of two forms: Attribute fields may be of two forms:
o A property attribute is simply of the form "a=<flag>". These are o A property attribute is simply of the form "a=<flag>". These are
binary attributes, and the presence of the attribute conveys that binary attributes, and the presence of the attribute conveys that
the attribute is a property of the session. An example might be the attribute is a property of the session. An example might be
"a=recvonly". "a=recvonly".
o A value attribute is of the form "a=<attribute>:<value>". For o A value attribute is of the form "a=<attribute>:<value>". For
example, a whiteboard could have the value attribute "a=orient: example, a whiteboard could have the value attribute
landscape" "a=orient:landscape"
Attribute interpretation depends on the media tool being invoked. Attribute interpretation depends on the media tool being invoked.
Thus receivers of session descriptions should be configurable in Thus receivers of session descriptions should be configurable in
their interpretation of session descriptions in general and of their interpretation of session descriptions in general and of
attributes in particular. attributes in particular.
Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8.
Attribute values are octet strings, and MAY use any octet value Attribute values are octet strings, and MAY use any octet value
except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute
skipping to change at page 23, line 8 skipping to change at page 23, line 16
attribute is defined, it can be defined to be charset dependent, in attribute is defined, it can be defined to be charset dependent, in
which case its value should be interpreted in the session charset which case its value should be interpreted in the session charset
rather than in ISO-10646. rather than in ISO-10646.
Attributes MUST be registered with IANA (see Section 8). If an Attributes MUST be registered with IANA (see Section 8). If an
attribute is received that is not understood, it MUST be ignored by attribute is received that is not understood, it MUST be ignored by
the receiver. the receiver.
5.14. Media Descriptions ("m=") 5.14. Media Descriptions ("m=")
m=<media> <port> <proto> <fmt> ... m=<media> <port> <proto> <fmt> ...
A session description may contain a number of media descriptions. A session description may contain a number of media descriptions.
Each media description starts with an "m=" field and is terminated by Each media description starts with an "m=" field and is terminated by
either the next "m=" field or by the end of the session description. either the next "m=" field or by the end of the session description.
A media field has several sub-fields: A media field has several sub-fields:
<media> is the media type. Currently defined media are "audio", <media> is the media type. Currently defined media are "audio",
"video", "text", "application", and "message", although this list "video", "text", "application", and "message", although this list
may be extended in the future (see Section 8). may be extended in the future (see Section 8).
skipping to change at page 23, line 41 skipping to change at page 23, line 49
media to a <port> that is odd and where the "a=rtcp:" is present media to a <port> that is odd and where the "a=rtcp:" is present
MUST NOT subtract 1 from the RTP port: that is, they MUST send the MUST NOT subtract 1 from the RTP port: that is, they MUST send the
RTP to the port indicated in <port> and send the RTCP to the port RTP to the port indicated in <port> and send the RTCP to the port
indicated in the "a=rtcp" attribute. indicated in the "a=rtcp" attribute.
For applications where hierarchically encoded streams are being For applications where hierarchically encoded streams are being
sent to a unicast address, it may be necessary to specify multiple sent to a unicast address, it may be necessary to specify multiple
transport ports. This is done using a similar notation to that transport ports. This is done using a similar notation to that
used for IP multicast addresses in the "c=" field: used for IP multicast addresses in the "c=" field:
m=<media> <port>/<number of ports> <proto> <fmt> ... m=<media> <port>/<number of ports> <proto> <fmt> ...
In such a case, the ports used depend on the transport protocol. In such a case, the ports used depend on the transport protocol.
For RTP, the default is that only the even-numbered ports are used For RTP, the default is that only the even-numbered ports are used
for data with the corresponding one-higher odd ports used for the for data with the corresponding one-higher odd ports used for the
RTCP belonging to the RTP session, and the <number of ports> RTCP belonging to the RTP session, and the <number of ports>
denoting the number of RTP sessions. For example: denoting the number of RTP sessions. For example:
m=video 49170/2 RTP/AVP 31 m=video 49170/2 RTP/AVP 31
would specify that ports 49170 and 49171 form one RTP/RTCP pair would specify that ports 49170 and 49171 form one RTP/RTCP pair
and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the
transport protocol and 31 is the format (see below). If non- transport protocol and 31 is the format (see below). If non-
contiguous ports are required, they must be signalled using a contiguous ports are required, they must be signalled using a
separate attribute (for example, "a=rtcp:" as defined in separate attribute (for example, "a=rtcp:" as defined in
[RFC3605]). [RFC3605]).
If multiple addresses are specified in the "c=" field and multiple If multiple addresses are specified in the "c=" field and multiple
ports are specified in the "m=" field, a one-to-one mapping from ports are specified in the "m=" field, a one-to-one mapping from
port to the corresponding address is implied. For example: port to the corresponding address is implied. For example:
c=IN IP4 233.252.0.1/127/2 c=IN IP4 233.252.0.1/127/2
m=video 49170/2 RTP/AVP 31 m=video 49170/2 RTP/AVP 31
would imply that address 233.252.0.1 is used with ports 49170 and would imply that address 233.252.0.1 is used with ports 49170 and
49171, and address 233.252.0.2 is used with ports 49172 and 49173. 49171, and address 233.252.0.2 is used with ports 49172 and 49173.
The semantics of multiple "m=" lines using the same transport The semantics of multiple "m=" lines using the same transport
address are undefined. This implies that, unlike limited past address are undefined. This implies that, unlike limited past
practice, there is no implicit grouping defined by such means and practice, there is no implicit grouping defined by such means and
an explicit grouping framework (for example, [RFC5888]) should an explicit grouping framework (for example, [RFC5888]) should
instead be used to express the intended semantics. instead be used to express the intended semantics.
skipping to change at page 25, line 28 skipping to change at page 25, line 36
Section 6). Section 6).
If the <proto> sub-field is "udp" the <fmt> sub-fields MUST If the <proto> sub-field is "udp" the <fmt> sub-fields MUST
reference a media type describing the format under the "audio", reference a media type describing the format under the "audio",
"video", "text", "application", or "message" top-level media "video", "text", "application", or "message" top-level media
types. The media type registration SHOULD define the packet types. The media type registration SHOULD define the packet
format for use with UDP transport. format for use with UDP transport.
For media using other transport protocols, the <fmt> field is For media using other transport protocols, the <fmt> field is
protocol specific. Rules for interpretation of the <fmt> sub- protocol specific. Rules for interpretation of the <fmt> sub-
field MUST be defined when registering new protocols (see Section field MUST be defined when registering new protocols (see
8.2.2). Section 8.2.2).
Section 3 of [RFC4855] states that the payload format (encoding)
names defined in the RTP Profile are commonly shown in upper case,
while media subtype names are commonly shown in lower case. It
also states that both of these names are case-insensitive in both
places, similar to parameter names which are case-insensitive both
in media type strings and in the default mapping to the SDP a=fmtp
attribute.
6. SDP Attributes 6. SDP Attributes
The following attributes are defined. Since application writers may The following attributes are defined. Since application writers may
add new attributes as they are required, this list is not exhaustive. add new attributes as they are required, this list is not exhaustive.
Registration procedures for new attributes are defined in Section Registration procedures for new attributes are defined in
8.2.4. Section 8.2.4.
a=cat:<category> a=cat:<category>
This attribute gives the dot-separated hierarchical category of This attribute gives the dot-separated hierarchical category of
the session. This is to enable a receiver to filter unwanted the session. This is to enable a receiver to filter unwanted
sessions by category. There is no central registry of sessions by category. There is no central registry of
categories. It is a session-level attribute, and it is not categories. It is a session-level attribute, and it is not
dependent on charset. dependent on charset.
a=keywds:<keywords> a=keywds:<keywords>
skipping to change at page 27, line 8 skipping to change at page 27, line 24
Although an RTP profile may make static assignments of payload Although an RTP profile may make static assignments of payload
type numbers to payload formats, it is more common for that type numbers to payload formats, it is more common for that
assignment to be done dynamically using "a=rtpmap:" attributes. assignment to be done dynamically using "a=rtpmap:" attributes.
As an example of a static payload type, consider u-law PCM As an example of a static payload type, consider u-law PCM
coded single-channel audio sampled at 8 kHz. This is coded single-channel audio sampled at 8 kHz. This is
completely defined in the RTP Audio/Video profile as payload completely defined in the RTP Audio/Video profile as payload
type 0, so there is no need for an "a=rtpmap:" attribute, and type 0, so there is no need for an "a=rtpmap:" attribute, and
the media for such a stream sent to UDP port 49232 can be the media for such a stream sent to UDP port 49232 can be
specified as: specified as:
m=audio 49232 RTP/AVP 0 m=audio 49232 RTP/AVP 0
An example of a dynamic payload type is 16-bit linear encoded An example of a dynamic payload type is 16-bit linear encoded
stereo audio sampled at 16 kHz. If we wish to use the dynamic stereo audio sampled at 16 kHz. If we wish to use the dynamic
RTP/AVP payload type 98 for this stream, additional information RTP/AVP payload type 98 for this stream, additional information
is required to decode it: is required to decode it:
m=audio 49232 RTP/AVP 98 m=audio 49232 RTP/AVP 98
a=rtpmap:98 L16/16000/2 a=rtpmap:98 L16/16000/2
Up to one rtpmap attribute can be defined for each media format Up to one rtpmap attribute can be defined for each media format
specified. Thus, we might have the following: specified. Thus, we might have the following:
m=audio 49230 RTP/AVP 96 97 98 m=audio 49230 RTP/AVP 96 97 98
a=rtpmap:96 L8/8000 a=rtpmap:96 L8/8000
a=rtpmap:97 L16/8000 a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2 a=rtpmap:98 L16/11025/2
RTP profiles that specify the use of dynamic payload types MUST RTP profiles that specify the use of dynamic payload types MUST
define the set of valid encoding names and/or a means to define the set of valid encoding names and/or a means to
register encoding names if that profile is to be used with SDP. register encoding names if that profile is to be used with SDP.
The "RTP/AVP" and "RTP/SAVP" profiles use media subtypes for The "RTP/AVP" and "RTP/SAVP" profiles use media subtypes for
encoding names, under the top-level media type denoted in the encoding names, under the top-level media type denoted in the
"m=" line. In the example above, the media types are "m=" line. In the example above, the media types are "audio/
"audio/l8" and "audio/l16". l8" and "audio/l16".
For audio streams, <encoding parameters> indicates the number For audio streams, <encoding parameters> indicates the number
of audio channels. This parameter is OPTIONAL and may be of audio channels. This parameter is OPTIONAL and may be
omitted if the number of channels is one, provided that no omitted if the number of channels is one, provided that no
additional parameters are needed. additional parameters are needed.
For video streams, no encoding parameters are currently For video streams, no encoding parameters are currently
specified. specified.
Additional encoding parameters MAY be defined in the future, Additional encoding parameters MAY be defined in the future,
skipping to change at page 28, line 6 skipping to change at page 28, line 25
added to an "a=rtpmap:" attribute SHOULD only be those required added to an "a=rtpmap:" attribute SHOULD only be those required
for a session directory to make the choice of appropriate media for a session directory to make the choice of appropriate media
to participate in a session. Codec-specific parameters should to participate in a session. Codec-specific parameters should
be added in other attributes (for example, "a=fmtp:"). be added in other attributes (for example, "a=fmtp:").
Note: RTP audio formats typically do not include information Note: RTP audio formats typically do not include information
about the number of samples per packet. If a non-default (as about the number of samples per packet. If a non-default (as
defined in the RTP Audio/Video Profile) packetisation is defined in the RTP Audio/Video Profile) packetisation is
required, the "ptime" attribute is used as given above. required, the "ptime" attribute is used as given above.
a=recvonly, a=sendrecv, a=sendonly, a=inactive
At most one of recvonly/sendrecv/sendonly/inactive MAY appear
at session level, and at most one MAY appear in each media
section.
If any one of these appears in a media section then it applies
for that media section. If none appear in a media section then
the one from session level, if any, applies to that media
section.
If none of the attributes "sendonly", "recvonly", "inactive",
and "sendrecv" is present at either session level or media
level, "sendrecv" SHOULD be assumed as the default for sessions
that are not of the conference type "broadcast" or "H332" (see
below).
Within the following SDP example, the "inactive" attribute
applies to audio media and the "recvonly" attribute applies to
video media.
v=0
o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 233.252.0.1/127
t=2873397496 2873404696
a=inactive
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000
a=recvonly
a=recvonly a=recvonly
This specifies that the tools should be started in receive-only This specifies that the tools should be started in receive-only
mode where applicable. It can be either a session- or media- mode where applicable. It can be either a session- or media-
level attribute, and it is not dependent on charset. Note that level attribute, and it is not dependent on charset. Note that
recvonly applies to the media only, not to any associated recvonly applies to the media only, not to any associated
control protocol (e.g., an RTP-based system in recvonly mode control protocol (e.g., an RTP-based system in recvonly mode
SHOULD still send RTCP packets). SHOULD still send RTCP packets).
a=sendrecv a=sendrecv
This specifies that the tools should be started in send and This specifies that the tools should be started in send and
receive mode. This is necessary for interactive conferences receive mode. This is necessary for interactive conferences
with tools that default to receive-only mode. It can be either with tools that default to receive-only mode. It can be either
a session or media-level attribute, and it is not dependent on a session or media-level attribute, and it is not dependent on
charset. charset.
If none of the attributes "sendonly", "recvonly", "inactive",
and "sendrecv" is present, "sendrecv" SHOULD be assumed as the
default for sessions that are not of the conference type
"broadcast" or "H332" (see below).
a=sendonly a=sendonly
This specifies that the tools should be started in send-only This specifies that the tools should be started in send-only
mode. An example may be where a different unicast address is mode. An example may be where a different unicast address is
to be used for a traffic destination than for a traffic source. to be used for a traffic destination than for a traffic source.
In such a case, two media descriptions may be used, one In such a case, two media descriptions may be used, one
sendonly and one recvonly. It can be either a session- or sendonly and one recvonly. It can be either a session- or
media-level attribute, but would normally only be used as a media-level attribute, but would normally only be used as a
media attribute. It is not dependent on charset. Note that media attribute. It is not dependent on charset. Note that
sendonly applies only to the media, and any associated control sendonly applies only to the media, and any associated control
skipping to change at page 29, line 44 skipping to change at page 31, line 5
a=charset:<character set> a=charset:<character set>
This specifies the character set to be used to display the This specifies the character set to be used to display the
session name and information data. By default, the ISO-10646 session name and information data. By default, the ISO-10646
character set in UTF-8 encoding is used. If a more compact character set in UTF-8 encoding is used. If a more compact
representation is required, other character sets may be used. representation is required, other character sets may be used.
For example, the ISO 8859-1 is specified with the following SDP For example, the ISO 8859-1 is specified with the following SDP
attribute: attribute:
a=charset:ISO-8859-1 a=charset:ISO-8859-1
This is a session-level attribute and is not dependent on This is a session-level attribute and is not dependent on
charset. The charset specified MUST be one of those registered charset. The charset specified MUST be one of those registered
with IANA, such as ISO-8859-1. The character set identifier is with IANA, such as ISO-8859-1. The character set identifier is
a US-ASCII string and MUST be compared against the IANA a US-ASCII string and MUST be compared against the IANA
identifiers using a case-insensitive comparison. If the identifiers using a case-insensitive comparison. If the
identifier is not recognised or not supported, all strings that identifier is not recognised or not supported, all strings that
are affected by it SHOULD be regarded as octet strings. are affected by it SHOULD be regarded as octet strings.
Note that a character set specified MUST still prohibit the use Note that a character set specified MUST still prohibit the use
of bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets of bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets
requiring the use of these characters MUST define a quoting requiring the use of these characters MUST define a quoting
mechanism that prevents these bytes from appearing within text mechanism that prevents these bytes from appearing within text
fields. fields.
a=sdplang:<language tag> a=sdplang:<language tag>
This can be a session-level attribute or a media-level This can be a session-level attribute or a media-level
attribute. As a session-level attribute, it specifies the attribute. Multiple sdplang attributes can be provided either
language for the session description. As a media-level at session or media level if the session description or media
attribute, it specifies the language for any media-level SDP use multiple languages.
information field associated with that media. Multiple sdplang
attributes can be provided either at session or media level if As a session-level attribute, it specifies the language for the
the session description or media use multiple languages. session description. As a media-level attribute, it specifies
the language for any media-level SDP information field
associated with that media, overriding any sdplang attributes
specified at session-level.
In general, sending session descriptions consisting of multiple In general, sending session descriptions consisting of multiple
languages is discouraged. Instead, multiple descriptions 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 [RFC5646] The "sdplang" attribute value must be a single [RFC5646]
language tag in US-ASCII. It is not dependent on the charset language tag in US-ASCII. It is not dependent on the charset
skipping to change at page 30, line 37 skipping to change at page 32, line 4
The "sdplang" attribute value must be a single [RFC5646] The "sdplang" attribute value must be a single [RFC5646]
language tag in US-ASCII. It is not dependent on the charset language tag in US-ASCII. It is not dependent on the charset
attribute. An "sdplang" attribute SHOULD be specified when a attribute. An "sdplang" attribute SHOULD be specified 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. Multiple lang attributes can be provided either at
default language for the session being described. As a media- session or media level if the session or media use multiple
level attribute, it specifies the language for that media, languages, in which case the order of the attributes indicates
overriding any session-level language specified. Multiple lang the order of importance of the various languages in the session
attributes can be provided either at session or media level if or media, from most important to least important.
the session or media use multiple languages, in which case the
order of the attributes indicates the order of importance of As a session-level attribute, it specifies the default language
the various languages in the session or media, from most for the session being described. As a media-level attribute,
important to least important. it specifies the language for that media, overriding any
session-level languages specified.
The "lang" attribute value must be a single [RFC5646] language The "lang" attribute value must be a single [RFC5646] language
tag in US-ASCII. It is not dependent on the charset attribute. tag in US-ASCII. It is not dependent on the charset attribute.
A "lang" attribute SHOULD be specified when a session is of A "lang" attribute SHOULD be specified when a session is of
sufficient scope to cross geographic boundaries where the sufficient scope to cross geographic boundaries where the
language of recipients cannot be assumed, or where the session language of recipients cannot be assumed, or where the session
is in a different language from the locally assumed norm. is in a different language from the locally assumed norm.
a=framerate:<frame rate> a=framerate:<frame rate>
skipping to change at page 31, line 24 skipping to change at page 32, line 40
dependent on charset. dependent on charset.
a=quality:<quality> a=quality:<quality>
This gives a suggestion for the quality of the encoding as an This gives a suggestion for the quality of the encoding as an
integer value. The intention of the quality attribute for integer value. The intention of the quality attribute for
video is to specify a non-default trade-off between frame-rate video is to specify a non-default trade-off between frame-rate
and still-image quality. For video, the value is in the range and still-image quality. For video, the value is in the range
0 to 10, with the following suggested meaning: 0 to 10, with the following suggested meaning:
10 - the best still-image quality the compression scheme 10 - the best still-image quality the compression scheme
can give. can give.
5 - the default behaviour given no quality suggestion. 5 - the default behaviour given no quality suggestion.
0 - the worst still-image quality the codec designer 0 - the worst still-image quality the codec designer
thinks is still usable. thinks is still usable.
It is a media-level attribute, and it is not dependent on It is a media-level attribute, and it is not dependent on
charset. charset.
a=fmtp:<format> <format specific parameters> a=fmtp:<format> <format specific parameters>
This attribute allows parameters that are specific to a This attribute allows parameters that are specific to a
particular format to be conveyed in a way that SDP does not particular format to be conveyed in a way that SDP does not
have to understand them. The format must be one of the formats have to understand them. The format must be one of the formats
specified for the media. Format-specific parameters may be any specified for the media. Format-specific parameters may be any
set of parameters required to be conveyed by SDP and given set of parameters required to be conveyed by SDP and given
unchanged to the media tool that will use this format. At most unchanged to the media tool that will use this format. At most
one instance of this attribute is allowed for each format. one instance of this attribute is allowed for each format.
It is a media-level attribute, and it is not dependent on It is a media-level attribute, and it is not dependent on
charset. charset.
skipping to change at page 35, line 51 skipping to change at page 37, line 14
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 [RFC3550] 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 Profile for Audio and Video Conferences with Minimal Control
[RFC3551] running over UDP/IP, "RTP/SAVP" is a reference to the [RFC3551] running over UDP/IP, "RTP/SAVP" is a reference to the
Secure Real-time Transport Protocol [RFC3711], and "udp" indicates an Secure Real-time Transport Protocol [RFC3711], and "udp" indicates an
unspecified 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
"RTP/XYZ". /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
by which their "fmt" namespace is managed (see below). by which their "fmt" namespace is managed (see below).
8.2.3. Media Formats ("fmt") 8.2.3. Media Formats ("fmt")
Each transport protocol, defined by the "proto" field, has an Each transport protocol, defined by the "proto" field, has an
skipping to change at page 36, line 30 skipping to change at page 37, line 42
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 [RFC4288] by production of, or reference to, through the IETF process [RFC6838] by production of, or reference to,
a 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")
skipping to change at page 37, line 34 skipping to change at page 38, line 46
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 [RFC4566]): (these definitions update those in [RFC4566]):
Name | Session or Media level? | Dependent on charset? Name | Session or Media level? | Dependent on charset?
----------+-------------------------+---------------------- ----------+-------------------------+----------------------
cat | Session | No cat | Session | No
keywds | Session | Yes keywds | Session | Yes
tool | Session | No tool | Session | No
ptime | Media | No ptime | Media | No
maxptime | Media | No maxptime | Media | No
rtpmap | Media | No rtpmap | Media | No
recvonly | Either | No recvonly | Either | No
sendrecv | Either | No sendrecv | Either | No
sendonly | Either | No sendonly | Either | No
inactive | Either | No inactive | Either | No
orient | Media | No orient | Media | No
type | Session | No type | Session | No
charset | Session | No charset | Session | No
sdplang | Either | No sdplang | Either | No
lang | Either | No lang | Either | No
framerate | Media | No framerate | Media | No
quality | Media | No quality | Media | No
fmtp | Media | No fmtp | Media | No
8.2.5. Bandwidth Specifiers ("bwtype") 8.2.5. Bandwidth Specifiers ("bwtype")
A proliferation of bandwidth specifiers is strongly discouraged. A proliferation of bandwidth specifiers is strongly discouraged.
New bandwidth specifiers ("bwtype" fields) MUST be registered with New bandwidth specifiers ("bwtype" fields) MUST be registered with
IANA. The submission MUST reference a standards-track RFC specifying IANA. The submission MUST reference a standards-track RFC specifying
the semantics of the bandwidth specifier precisely, and indicating the semantics of the bandwidth specifier precisely, and indicating
when it should be used, and why the existing registered bandwidth when it should be used, and why the existing registered bandwidth
specifiers do not suffice. specifiers do not suffice.
skipping to change at page 45, line 5 skipping to change at page 46, line 19
for hexpart, hexseq, and hex4 have been removed. for hexpart, hexseq, and hex4 have been removed.
IP4 unicast and multicast addresses in the example SDP descriptions IP4 unicast and multicast addresses in the example SDP descriptions
have been revised per RFCs 5735 and 5771. have been revised per RFCs 5735 and 5771.
Text in Section 5.2 has been revised to clarify the use of local Text in Section 5.2 has been revised to clarify the use of local
addresses in case of ICE-like SDP extensions. addresses in case of ICE-like SDP extensions.
Normative and informative references have been updated. Normative and informative references have been updated.
The text regarding the session vs. media-level attribute usage has
been clarified.
The case-insensitivity rules from RFC 4855 have been included in this
document.
The following purely editorial changes have been made: The following purely editorial changes have been made:
o Section 4.6: fix typo in first sentence: "sets" -> "set" o Section 4.6: fix typo in first sentence: "sets" -> "set"
o Section 5: clarify second paragraph (SDP field and attribute names o Section 5: clarify second paragraph (SDP field and attribute names
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 37 skipping to change at page 47, line 8
o Section 5.10: fix typo: "To make description" -> "To make the o Section 5.10: fix typo: "To make description" -> "To make the
description" description"
o Section 5.11: use "session description" rather than "session o Section 5.11: use "session description" rather than "session
announcement" in the final paragraph announcement" in the final paragraph
o Section 7: fix typo: "distribute session description" -> o Section 7: fix typo: "distribute session description" ->
"distribute session descriptions" "distribute session descriptions"
To-do: Clarify the use of multiple "a=sdplang:" and "a=lang:"
attributes. In general, review the text proposed by Paul K. on 1/3/
2013 and incorporate into the text to clarify the usage of session-
level attributes. Consider including the case-sensitivity rules from
RFC 3555 in this document.
11. Acknowledgements 11. Acknowledgements
Many people in the IETF Multiparty Multimedia Session Control Many people in the IETF Multiparty Multimedia Session Control
(MMUSIC) working group have made comments and suggestions (MMUSIC) working group have made comments and suggestions
contributing to this document. In particular, we would like to thank contributing to this document. In particular, we would like to thank
Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross
Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna, Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna,
Jonathan Lennox, Keith Drage, Sean Olson, Bernie Hoeneisen, Jonathan Jonathan Lennox, Keith Drage, Sean Olson, Bernie Hoeneisen, Jonathan
Rosenberg, John Elwell, Flemming Andreasen, Jon Peterson, Spencer Rosenberg, John Elwell, Flemming Andreasen, Jon Peterson, Spencer
Dawkins, and Alfred Hoenes. Dawkins, Alfred Hoenes, Brett Tate and Paul Kyzivat.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
facilities", STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Syntax Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234, January 2008.
January 2008.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
"Uniform Resource Identifier (URI): Generic Syntax", Resource Identifier (URI): Generic Syntax", STD 66, RFC
STD 66, RFC 3986, January 2005. 3986, January 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Writing an IANA Considerations Section in RFCs", IANA Considerations Section in RFCs", BCP 26, RFC 5226,
BCP 26, RFC 5226, May 2008. May 2008.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009. Languages", BCP 47, RFC 5646, September 2009.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Applications (IDNA): Definitions and Document Framework",
Framework", RFC 5890, August 2010. RFC 5890, August 2010.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Session Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
12.2. Informative References 12.2. Informative References
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Description Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
"Network Time Protocol Version 4: Protocol and Time Protocol Version 4: Protocol and Algorithms
Algorithms Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
Johnston, A., Peterson, J., Sparks, R., Handley, M., A., Peterson, J., Sparks, R., Handley, M., and E.
and E. Schooler, "SIP: Session Initiation Protocol", Schooler, "SIP: Session Initiation Protocol", RFC 3261,
RFC 3261, June 2002. June 2002.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Time Streaming Protocol (RTSP)", RFC 2326, Streaming Protocol (RTSP)", RFC 2326, April 1998.
April 1998.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
Model with Session Description Protocol (SDP)", with Session Description Protocol (SDP)", RFC 3264, June
RFC 3264, June 2002. 2002.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Description Protocol (SDP) Grouping Framework", Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
RFC 5888, June 2010.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Audio and Video Conferences with Minimal Control", Video Conferences with Minimal Control", STD 65, RFC 3551,
STD 65, RFC 3551, July 2003. July 2003.
[RFC3556] Casner, S., "Session Description Protocol (SDP) [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth
Bandwidth Modifiers for RTP Control Protocol (RTCP) Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC
Bandwidth", RFC 3556, July 2003. 3556, July 2003.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
attribute in Session Description Protocol (SDP)", in Session Description Protocol (SDP)", RFC 3605, October
RFC 3605, October 2003. 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
and K. Norrman, "The Secure Real-time Transport Norrman, "The Secure Real-time Transport Protocol (SRTP)",
Protocol (SRTP)", RFC 3711, March 2004. RFC 3711, March 2004.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004. Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3890] Westerlund, M., "A Transport Independent Bandwidth [RFC3890] Westerlund, M., "A Transport Independent Bandwidth
Modifier for the Session Description Protocol Modifier for the Session Description Protocol (SDP)", RFC
(SDP)", RFC 3890, September 2004. 3890, September 2004.
[RFC5245] Rosenberg, J., "Interactive Connectivity [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
Establishment (ICE): A Protocol for Network Address (ICE): A Protocol for Network Address Translator (NAT)
Translator (NAT) Traversal for Offer/Answer Traversal for Offer/Answer Protocols", RFC 5245, April
Protocols", RFC 5245, April 2010. 2010.
[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B.B., and A.B.
Roach, "TCP Candidates with Interactive Connectivity Roach, "TCP Candidates with Interactive Connectivity
Establishment (ICE)", RFC 6544, March 2012. Establishment (ICE)", RFC 6544, March 2012.
[ITU.H332.1998] International Telecommunication Union, "H.323 [ITU.H332.1998]
extended for loosely coupled conferences", International Telecommunication Union, "H.323 extended for
ITU Recommendation H.332, September 1998. loosely coupled conferences", ITU Recommendation H.332,
September 1998.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
and E. Carrara, "Key Management Extensions for Carrara, "Key Management Extensions for Session
Session Description Protocol (SDP) and Real Time Description Protocol (SDP) and Real Time Streaming
Streaming Protocol (RTSP)", RFC 4567, July 2006. Protocol (RTSP)", RFC 4567, July 2006.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Description Protocol (SDP) Security Descriptions for Media
Media Streams", RFC 4568, July 2006. Streams", RFC 4568, July 2006.
[RFC5322] Resnick, P., Ed., "Internet Message Format", [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
RFC 5322, October 2008. October 2008.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
and Registration Procedures", RFC 4288, Specifications and Registration Procedures", BCP 13, RFC
December 2005. 6838, January 2013.
Authors' Addresses [RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007.
Authors' Addresses
Mark Handley Mark Handley
University College London University College London
Department of Computer Science Department of Computer Science
London WC1E 6BT London WC1E 6BT
UK UK
EMail: M.Handley@cs.ucl.ac.uk EMail: M.Handley@cs.ucl.ac.uk
Van Jacobson Van Jacobson
PARC PARC
3333 Coyote Hill Road 3333 Coyote Hill Road
Palo Alto, CA 94304 Palo Alto, CA 94304
USA USA
EMail: van@parc.com EMail: van@parc.com
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
 End of changes. 97 change blocks. 
281 lines changed or deleted 324 lines changed or added

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