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 10, line 50 skipping to change at page 10, line 23
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=audio 49180 RTP/AVP 0
m=video 51372 RTP/AVP 99 m=video 51372 RTP/AVP 99
c=IN IP4 233.252.0.1/127
a=rtpmap:99 h263-1998/90000 a=rtpmap:99 h263-1998/90000
Text fields such as the session name and information are octet Text fields such as the session name and information are octet
strings that may contain any octet with the exceptions of 0x00 (Nul), strings that may contain any octet with the exceptions of 0x00 (Nul),
0x0a (ASCII newline), and 0x0d (ASCII carriage return). The sequence 0x0a (ASCII newline), and 0x0d (ASCII carriage return). The sequence
CRLF (0x0d0a) is used to end a record, although parsers SHOULD be CRLF (0x0d0a) is used to end a record, although parsers SHOULD be
tolerant and also accept records terminated with a single newline tolerant and also accept records terminated with a single newline
character. If the "a=charset" attribute is not present, these octet character. If the "a=charset" attribute is not present, these octet
strings MUST be interpreted as containing ISO-10646 characters in strings MUST be interpreted as containing ISO-10646 characters in
UTF-8 encoding (the presence of the "a=charset" attribute may force UTF-8 encoding (the presence of the "a=charset" attribute may force
skipping to change at page 12, line 14 skipping to change at page 11, line 42
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 22, line 30 skipping to change at page 22, line 38
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 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 31 skipping to change at page 27, line 47
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 30, line 14 skipping to change at page 31, line 24
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 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 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 33 skipping to change at page 47, line 4
address of the machine, since IP addresses identify interfaces, address of the machine, since IP addresses identify interfaces,
not hosts. not hosts.
o Section 5.6: use "session" rather than "conference" o Section 5.6: use "session" rather than "conference"
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. 56 change blocks. 
159 lines changed or deleted 203 lines changed or added

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