draft-ietf-mmusic-rfc4566bis-11.txt   draft-ietf-mmusic-rfc4566bis-12.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: March 19, 2015 C.S. Perkins Expires: March 27, 2015 C.S. Perkins
University of Glasgow University of Glasgow
A. Begen A. Begen
Cisco Cisco
September 15, 2014 September 23, 2014
SDP: Session Description Protocol SDP: Session Description Protocol
draft-ietf-mmusic-rfc4566bis-11 draft-ietf-mmusic-rfc4566bis-12
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 March 19, 2015. This Internet-Draft will expire on March 27, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4
3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . . 4 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . . 4
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 4 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 4
3.2. Streaming Media . . . . . . . . . . . . . . . . . . . . . 4 3.2. Streaming Media . . . . . . . . . . . . . . . . . . . . . 5
3.3. Email and the World Wide Web . . . . . . . . . . . . . . 4 3.3. Email and the World Wide Web . . . . . . . . . . . . . . 5
3.4. Multicast Session Announcement . . . . . . . . . . . . . 5 3.4. Multicast Session Announcement . . . . . . . . . . . . . 5
4. Requirements and Recommendations . . . . . . . . . . . . . . 5 4. Requirements and Recommendations . . . . . . . . . . . . . . 5
4.1. Media and Transport Information . . . . . . . . . . . . . 6 4.1. Media and Transport Information . . . . . . . . . . . . . 6
4.2. Timing Information . . . . . . . . . . . . . . . . . . . 7 4.2. Timing Information . . . . . . . . . . . . . . . . . . . 7
4.3. Private Sessions . . . . . . . . . . . . . . . . . . . . 7 4.3. Private Sessions . . . . . . . . . . . . . . . . . . . . 7
4.4. Obtaining Further Information about a Session . . . . . . 7 4.4. Obtaining Further Information about a Session . . . . . . 8
4.5. Categorisation . . . . . . . . . . . . . . . . . . . . . 7 4.5. Categorisation . . . . . . . . . . . . . . . . . . . . . 8
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=") . . . . . . . . . . . . . . . . . . . 12 5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 13
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=") . . . . . 13 5.6. Email Address and Phone Number ("e=" and "p=") . . . . . 14
5.7. Connection Data ("c=") . . . . . . . . . . . . . . . . . 14 5.7. Connection Data ("c=") . . . . . . . . . . . . . . . . . 15
5.8. Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . 17 5.8. Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . 17
5.9. Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 18 5.9. Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 18
5.10. Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . 19 5.10. Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . 19
5.11. Time Zones ("z=") . . . . . . . . . . . . . . . . . . . . 19 5.11. Time Zones ("z=") . . . . . . . . . . . . . . . . . . . . 20
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 . . . . . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 6.1. cat (category) . . . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 6.2. keywds (keywords) . . . . . . . . . . . . . . . . . . . . 26
8.1. The "application/sdp" Media Type . . . . . . . . . . . . 35 6.3. tool . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.2. Registration of Parameters . . . . . . . . . . . . . . . 36 6.4. ptime (packet time) . . . . . . . . . . . . . . . . . . . 28
8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 36 6.5. maxptime (maximum packet time) . . . . . . . . . . . . . 28
8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 36 6.6. rtpmap . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 37 6.7. Media Direction Attributes . . . . . . . . . . . . . . . 31
8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 38 6.7.1. recvonly (receive-only) . . . . . . . . . . . . . . . 32
8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 39 6.7.2. sendrecv (send-receive) . . . . . . . . . . . . . . . 33
8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 39 6.7.3. sendonly (send-only) . . . . . . . . . . . . . . . . 33
8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 40 6.7.4. inactive . . . . . . . . . . . . . . . . . . . . . . 33
8.2.8. Registration Procedure . . . . . . . . . . . . . . . 40 6.8. orient (orientation) . . . . . . . . . . . . . . . . . . 34
8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 40 6.9. type (conference type) . . . . . . . . . . . . . . . . . 34
9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 41 6.10. charset (character set) . . . . . . . . . . . . . . . . . 35
10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 46 6.11. sdplang (SDP language) . . . . . . . . . . . . . . . . . 36
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 6.12. lang (language) . . . . . . . . . . . . . . . . . . . . . 37
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.13. framerate (frame rate) . . . . . . . . . . . . . . . . . 38
12.1. Normative References . . . . . . . . . . . . . . . . . . 47 6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 39
12.2. Informative References . . . . . . . . . . . . . . . . . 48 6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 7. Security Considerations . . . . . . . . . . . . . . . . . . . 40
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
8.1. The "application/sdp" Media Type . . . . . . . . . . . . 42
8.2. Registration of Parameters . . . . . . . . . . . . . . . 43
8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 43
8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 44
8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 44
8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 45
8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 47
8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 47
8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 47
8.2.8. Registration Procedure . . . . . . . . . . . . . . . 48
8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 48
9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 48
10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 53
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 55
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 55
12.1. Normative References . . . . . . . . . . . . . . . . . . 55
12.2. Informative References . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58
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 4, line 7 skipping to change at page 4, line 26
not intended to support negotiation of session content or media not intended to support negotiation of session content or media
encodings: this is viewed as outside the scope of session encodings: this is viewed as outside the scope of session
description. description.
This memo obsoletes [RFC4566]. The changes relative to [RFC4566] are This memo obsoletes [RFC4566]. The changes relative to [RFC4566] are
limited to essential corrections, and are outlined in Section 10 of limited to essential corrections, and are outlined in Section 10 of
this memo. this memo.
2. Glossary of Terms 2. Glossary of Terms
The following terms are used in this document and have specific The following term is used in this document and has specific meaning
meaning within the context of this document. within the context of this document.
Conference: A multimedia conference is a set of two or more
communicating users along with the software they are using to
communicate.
Session: A multimedia session is a set of multimedia senders and
receivers and the data streams flowing from senders to receivers.
A multimedia conference is an example of a multimedia session.
Session Description: A well-defined format for conveying sufficient Session Description: A well-defined format for conveying sufficient
information to discover and participate in a multimedia session. information to discover and participate in a multimedia session.
The terms "multimedia conference" and "multimedia session" are used
in this document as defined in
[I-D.ietf-avtext-rtp-grouping-taxonomy]. The terms "session" and
"multimedia session" are used interchangeably in this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
3. Examples of SDP Usage 3. Examples of SDP Usage
3.1. Session Initiation 3.1. Session Initiation
The Session Initiation Protocol (SIP) [RFC3261] is an application- The Session Initiation Protocol (SIP) [RFC3261] is an application-
skipping to change at page 5, line 39 skipping to change at page 6, line 6
Session Announcement Protocol (SAP) [RFC2974]. SDP provides the Session Announcement Protocol (SAP) [RFC2974]. SDP provides the
recommended session description format for such session recommended session description format for such session
announcements. announcements.
4. Requirements and Recommendations 4. Requirements and Recommendations
The purpose of SDP is to convey information about media streams in The purpose of SDP is to convey information about media streams in
multimedia sessions to allow the recipients of a session description multimedia sessions to allow the recipients of a session description
to participate in the session. SDP is primarily intended for use in to participate in the session. SDP is primarily intended for use in
an internetwork, although it is sufficiently general that it can an internetwork, although it is sufficiently general that it can
describe conferences in other network environments. Media streams describe multimedia conferences in other network environments. Media
can be many-to-many. Sessions need not be continually active. streams can be many-to-many. Sessions need not be continually
active.
Thus far, multicast-based sessions on the Internet have differed from Thus far, multicast-based sessions on the Internet have differed from
many other forms of conferencing in that anyone receiving the traffic many other forms of conferencing in that anyone receiving the traffic
can join the session (unless the session traffic is encrypted). In can join the session (unless the session traffic is encrypted). In
such an environment, SDP serves two primary purposes. It is a means such an environment, SDP serves two primary purposes. It is a means
to communicate the existence of a session, and it is a means to to communicate the existence of a session, and it is a means to
convey sufficient information to enable joining and participating in convey sufficient information to enable joining and participating in
the session. In a unicast environment, only the latter purpose is the session. In a unicast environment, only the latter purpose is
likely to be relevant. likely to be relevant.
skipping to change at page 7, line 40 skipping to change at page 8, line 9
It is possible to create both public sessions and private sessions. It is possible to create both public sessions and private sessions.
SDP itself does not distinguish between these; private sessions are SDP itself does not distinguish between these; private sessions are
typically conveyed by encrypting the session description during typically conveyed by encrypting the session description during
distribution. The details of how encryption is performed are distribution. The details of how encryption is performed are
dependent on the mechanism used to convey SDP; mechanisms are dependent on the mechanism used to convey SDP; mechanisms are
currently defined for SDP transported using SAP [RFC2974] and SIP currently defined for SDP transported using SAP [RFC2974] and SIP
[RFC3261], and others may be defined in the future. [RFC3261], and others may be defined in the future.
If a session announcement is private, it is possible to use that If a session announcement is private, it is possible to use that
private announcement to convey encryption keys necessary to decode private announcement to convey encryption keys necessary to decode
each of the media in a conference, including enough information to each of the media in a multimedia conference, including enough
know which encryption scheme is used for each media. information to know which encryption scheme is used for each media.
4.4. Obtaining Further Information about a Session 4.4. Obtaining Further Information about a Session
A session description should convey enough information to decide A session description should convey enough information to decide
whether or not to participate in a session. SDP may include whether or not to participate in a session. SDP may include
additional pointers in the form of Uniform Resource Identifiers additional pointers in the form of Uniform Resource Identifiers
(URIs) for more information about the session. (URIs) for more information about the session.
4.5. Categorisation 4.5. Categorisation
When many session descriptions are being distributed by SAP, or any When many session descriptions are being distributed by SAP, or any
other advertisement mechanism, it may be desirable to filter session other advertisement mechanism, it may be desirable to filter session
announcements that are of interest from those that are not. SDP announcements that are of interest from those that are not. SDP
supports a categorisation mechanism for sessions that is capable of supports a categorisation mechanism for sessions that is capable of
being automated (the "a=cat:" attribute; see Section 6). being automated (the "a=cat:" attribute; see Section 6).
4.6. Internationalisation 4.6. Internationalisation
The SDP specification recommends the use of the ISO 10646 character The SDP specification recommends the use of the ISO 10646 character
set in the UTF-8 encoding [RFC3629] to allow many different languages set in the UTF-8 encoding [RFC3629] to allow many different languages
skipping to change at page 15, line 47 skipping to change at page 16, line 12
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 multimedia 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:
skipping to change at page 17, line 18 skipping to change at page 17, line 29
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
to the bandwidth used (the "conference total" bandwidth). The to the bandwidth used (the "multimedia conference total"
primary purpose of this is to give an approximate idea as to bandwidth). The primary purpose of this is to give an approximate
whether two or more sessions can coexist simultaneously. When idea as to whether two or more sessions can coexist
using the CT modifier with RTP, if several RTP sessions are part simultaneously. When using the CT modifier with RTP, if several
of the conference, the conference total refers to total bandwidth RTP sessions are part of the multimedia conference, the multimedia
of all RTP sessions. conference total refers to total bandwidth of all RTP sessions.
AS The bandwidth is interpreted to be application specific (it will AS The bandwidth is interpreted to be application specific (it will
be the application's concept of maximum bandwidth). Normally, be the application's concept of maximum bandwidth). Normally,
this will coincide with what is set on the application's "maximum this will coincide with what is set on the application's "maximum
bandwidth" control if applicable. For RTP-based applications, AS bandwidth" control if applicable. For RTP-based applications, AS
gives the RTP "session bandwidth" as defined in Section 6.2 of gives the RTP "session bandwidth" as defined in Section 6.2 of
[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
skipping to change at page 26, line 5 skipping to change at page 26, line 25
in media type strings and in the default mapping to the SDP a=fmtp in media type strings and in the default mapping to the SDP a=fmtp
attribute. 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 Registration procedures for new attributes are defined in
Section 8.2.4. Section 8.2.4.
a=cat:<category> 6.1. cat (category)
This attribute gives the dot-separated hierarchical category of Name: cat
the session. This is to enable a receiver to filter unwanted
sessions by category. There is no central registry of
categories. It is a session-level attribute, and it is not
dependent on charset.
a=keywds:<keywords> Value: cat-value
Like the cat attribute, this is to assist identifying wanted Usage Level: session
sessions at the receiver. This allows a receiver to select
interesting session based on keywords describing the purpose of
the session; there is no central registry of keywords. It is a
session-level attribute. It is a charset-dependent attribute,
meaning that its value should be interpreted in the charset
specified for the session description if one is specified, or
by default in ISO 10646/UTF-8.
a=tool:<name and version of tool> Charset Dependent: no
This gives the name and version number of the tool used to Syntax:
create the session description. It is a session-level
attribute, and it is not dependent on charset.
a=ptime:<packet time> cat-value = category
category = byte-string
; Note: syntax is vague because usage is not understood
This gives the length of time in milliseconds represented by Example:
the media in a packet. This is probably only meaningful for
audio data, but may be used with other media types if it makes
sense. It should not be necessary to know ptime to decode RTP
or vat audio, and it is intended as a recommendation for the
encoding/packetisation of audio. It is a media-level
attribute, and it is not dependent on charset.
a=maxptime:<maximum packet time> a=cat:foo.bar
This gives the maximum amount of media that can be encapsulated This attribute gives the dot-separated hierarchical category of the
in each packet, expressed as time in milliseconds. The time session. This is to enable a receiver to filter unwanted sessions by
SHALL be calculated as the sum of the time the media present in category. There is no central registry of categories.
the packet represents. For frame-based codecs, the time SHOULD
be an integer multiple of the frame size. This attribute is
probably only meaningful for audio data, but may be used with
other media types if it makes sense. It is a media-level
attribute, and it is not dependent on charset. Note that this
attribute was introduced after [RFC2327], and non-updated
implementations will ignore this attribute.
a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding 6.2. keywds (keywords)
parameters>] Name: keywds
This attribute maps from an RTP payload type number (as used in Value: keywds-value
an "m=" line) to an encoding name denoting the payload format
to be used. It also provides information on the clock rate and
encoding parameters. It is a media-level attribute that is not
dependent on charset.
Although an RTP profile may make static assignments of payload Usage Level: session
type numbers to payload formats, it is more common for that
assignment to be done dynamically using "a=rtpmap:" attributes.
As an example of a static payload type, consider u-law PCM
coded single-channel audio sampled at 8 kHz. This is
completely defined in the RTP Audio/Video profile as payload
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
specified as:
m=audio 49232 RTP/AVP 0 Charset Dependent: yes
An example of a dynamic payload type is 16-bit linear encoded Syntax:
stereo audio sampled at 16 kHz. If we wish to use the dynamic
RTP/AVP payload type 98 for this stream, additional information keywds-value = keywords
is required to decode it: keywords = byte-string
; Note: syntax is vague because usage is not understood
Example:
a=keywds:SDP session description protocol
Like the cat attribute, this is to assist identifying wanted sessions
at the receiver. This allows a receiver to select interesting
session based on keywords describing the purpose of the session;
there is no central registry of keywords. session-level attribute.
Its value should be interpreted in the charset specified for the
session description if one is specified, or by default in ISO 10646/
UTF-8.
6.3. tool
Name: tool
Value: tool-value
Usage Level: session
Charset Dependent: no
Syntax:
tool-value = tool-name-and-version
tool-name-and-version = byte-string
; Note: syntax is vague because usage is not understood
Example:
a=tool:foobar V3.2
This gives the name and version number of the tool used to create the
session description.
6.4. ptime (packet time)
Name: ptime
Value: ptime-value
Usage Level: media
Charset Dependent: no
Syntax:
ptime-value = packet-time
packet-time = integer
; do we want to define a limited range for this?
Example:
a=ptime:20
This gives the length of time in milliseconds represented by the
media in a packet. This is probably only meaningful for audio data,
but may be used with other media types if it makes sense. It should
not be necessary to know ptime to decode RTP or vat audio, and it is
intended as a recommendation for the encoding/packetisation of audio.
6.5. maxptime (maximum packet time)
Name: maxptime
Value: maxptime-value
Usage Level: media
Charset Dependent: no
Syntax:
maxptime-value = packet-time
Example:
a=maxptime:20
This gives the maximum amount of media that can be encapsulated in
each packet, expressed as time in milliseconds. The time SHALL be
calculated as the sum of the time the media present in the packet
represents. For frame-based codecs, the time SHOULD be an integer
multiple of the frame size. This attribute is probably only
meaningful for audio data, but may be used with other media types if
it makes sense. Note that this attribute was introduced after
[RFC2327], and non-updated implementations will ignore this
attribute.
6.6. rtpmap
Name: rtpmap
Value: rtpmap-value
Usage Level: media
Charset Dependent: no
Syntax:
rtpmap-value = payload-type SP encoding-name
"/" clock-rate [ "/" encoding-params ]
payload-type = integer
; do we want to define a limited range for this
; based on how big a PT can be in RTP?
encoding-name = token
; To be matched in a case-insensitive way!
; RFC4855 seems to be the primary definition for this.
; It refers both to RFC2045 and RFC4288 for the definition.
; The definition in RFC2045 is messy,
; but equivalent to SDP <token>.
; The definition in RFC4288 (<subtype-name>) is more
; restrictive and governs what can be registered.
; Since ultimately only registered names can be referenced,
; using <token> here seems safe and easy.
clock-rate = integer
; do we want to define a limited range for this?
encoding-params = channels
; 4566 is vague about what this can be. RFC4855 seems to be
; the authoritative source, and only allows the
; value of the media subtype "channels" parameter - the
; number of audio channels.
; Does anyone think this can be used for something else???
; (The implication that multiple parameters might be included
; seems a misdirection - additional parameters are
; to go into a=fmtp.)
; Does anyone have an example of other parameters
; using this field?
channels = integer
; Is there any reason to make this less restrictive?
This attribute maps from an RTP payload type number (as used in an
"m=" line) to an encoding name denoting the payload format to be
used. It also provides information on the clock rate and encoding
parameters.
Although an RTP profile can make static assignments of payload type
numbers to payload formats, it is more common for that assignment to
be done dynamically using "a=rtpmap:" attributes. As an example of a
static payload type, consider u-law PCM coded single-channel audio
sampled at 8 kHz. This is completely defined in the RTP Audio/Video
profile as payload 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 specified as:
m=audio 49232 RTP/AVP 0
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 RTP/AVP
payload type 98 for this stream, additional information 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
register encoding names if that profile is to be used with SDP. encoding names if that profile is to be used with SDP. The "RTP/AVP"
The "RTP/AVP" and "RTP/SAVP" profiles use media subtypes for and "RTP/SAVP" profiles use media subtypes for encoding names, under
encoding names, under the top-level media type denoted in the the top-level media type denoted in the "m=" line. In the example
"m=" line. In the example above, the media types are "audio/ above, the media types are "audio/l8" and "audio/l16".
l8" and "audio/l16".
For audio streams, <encoding parameters> indicates the number For audio streams, <encoding parameters> indicates the number of
of audio channels. This parameter is OPTIONAL and may be audio channels. This parameter is OPTIONAL and may be omitted if the
omitted if the number of channels is one, provided that no number of channels is one, provided that no additional parameters are
additional parameters are needed. 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, but
but codec-specific parameters SHOULD NOT be added. Parameters codec-specific parameters SHOULD NOT be added. Parameters added to
added to an "a=rtpmap:" attribute SHOULD only be those required an "a=rtpmap:" attribute SHOULD only be those required for a session
for a session directory to make the choice of appropriate media directory to make the choice of appropriate media to participate in a
to participate in a session. Codec-specific parameters should session. Codec-specific parameters should be added in other
be added in other attributes (for example, "a=fmtp:"). attributes (for example, "a=fmtp:").
Note: RTP audio formats typically do not include information Note: RTP audio formats typically do not include information about
about the number of samples per packet. If a non-default (as the number of samples per packet. If a non-default (as defined in
defined in the RTP Audio/Video Profile) packetisation is the RTP Audio/Video Profile) packetisation is required, the "ptime"
required, the "ptime" attribute is used as given above. attribute is used as given above.
a=recvonly, a=sendrecv, a=sendonly, a=inactive 6.7. Media Direction Attributes
At most one of recvonly/sendrecv/sendonly/inactive MAY appear At most one of recvonly/sendrecv/sendonly/inactive MAY appear at
at session level, and at most one MAY appear in each media session level, and at most one MAY appear in each media section.
section.
If any one of these appears in a media section then it applies If any one of these appears in a media section then it applies for
for that media section. If none appear in a media section then that media section. If none appear in a media section then the one
the one from session level, if any, applies to that media from session level, if any, applies to that media section.
section.
If none of the attributes "sendonly", "recvonly", "inactive", If none of the media direction attributes is present at either
and "sendrecv" is present at either session level or media session level or media level, "sendrecv" SHOULD be assumed as the
level, "sendrecv" SHOULD be assumed as the default for sessions default for sessions that are not of the multimedia conference type
that are not of the conference type "broadcast" or "H332" (see "broadcast" or "H332" (see below).
below).
Within the following SDP example, the "inactive" attribute Within the following SDP example, the "inactive" attribute applies to
applies to audio media and the "recvonly" attribute applies to audio media and the "recvonly" attribute applies to video media.
video media.
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1
s=SDP Seminar s=SDP Seminar
i=A Seminar on the session description protocol i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe) e=j.doe@example.com (Jane Doe)
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
t=2873397496 2873404696 t=2873397496 2873404696
a=inactive a=inactive
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99 m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000 a=rtpmap:99 h263-1998/90000
a=recvonly a=recvonly
6.7.1. recvonly (receive-only)
Name: recvonly
Value:
Usage Level: session, media
Charset Dependent: no
Example:
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
mode where applicable. It can be either a session- or media- where applicable. Note that recvonly applies to the media only, not
level attribute, and it is not dependent on charset. Note that to any associated control protocol (e.g., an RTP-based system in
recvonly applies to the media only, not to any associated recvonly mode SHOULD still send RTCP packets).
control protocol (e.g., an RTP-based system in recvonly mode
SHOULD still send RTCP packets). 6.7.2. sendrecv (send-receive)
Name: sendrecv
Value:
Usage Level: session, media
Charset Dependent: no
Example:
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
receive mode. This is necessary for interactive conferences mode. This is necessary for interactive multimedia conferences with
with tools that default to receive-only mode. It can be either tools that default to receive-only mode.
a session or media-level attribute, and it is not dependent on
charset. 6.7.3. sendonly (send-only)
Name: sendonly
Value:
Usage Level: session, media
Charset Dependent: no
Example:
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.
mode. An example may be where a different unicast address is An example may be where a different unicast address is to be used for
to be used for a traffic destination than for a traffic source. a traffic destination than for a traffic source. In such a case, two
In such a case, two media descriptions may be used, one media descriptions may be used, one sendonly and one recvonly. Note
sendonly and one recvonly. It can be either a session- or that sendonly applies only to the media, and any associated control
media-level attribute, but would normally only be used as a
media attribute. It is not dependent on charset. Note that
sendonly applies only to the media, and any associated control
protocol (e.g., RTCP) SHOULD still be received and processed as protocol (e.g., RTCP) SHOULD still be received and processed as
normal. normal.
6.7.4. inactive
Name: inactive
Value:
Usage Level: session, media
Charset Dependent: no
Example:
a=inactive a=inactive
This specifies that the tools should be started in inactive
mode. This is necessary for interactive conferences where
users can put other users on hold. No media is sent over an
inactive media stream. Note that an RTP-based system SHOULD
still send RTCP, even if started inactive. It can be either a
session or media-level attribute, and it is not dependent on
charset.
a=orient:<orientation> This specifies that the tools should be started in inactive mode.
This is necessary for interactive multimedia conferences where users
can put other users on hold. No media is sent over an inactive media
stream. Note that an RTP-based system SHOULD still send RTCP, even
if started inactive.
Normally this is only used for a whiteboard or presentation 6.8. orient (orientation)
tool. It specifies the orientation of a the workspace on the
screen. It is a media-level attribute. Permitted values are
"portrait", "landscape", and "seascape" (upside-down
landscape). It is not dependent on charset.
a=type:<conference type> Name: orient
This specifies the type of the conference. Suggested values Value: orient-value
are "broadcast", "meeting", "moderated", "test", and "H332".
Usage Level: media
Charset Dependent: no
Syntax:
orient-value = portrait / landscape / seascape
portrait = %x70.6f.72.74.72.61.69.74 ; "portrait"
landscape = %x6c.61.6e.64.73.63.61.70.65 ; "landscape"
seascape = %x73.65.61.73.63.61.70.65 ; "seascape"
; Note: this assumes the intent was to be case-sensitive
; Does anything think this should be matched in a
; case-insensitive way???
Example:
a=orient:portrait
Normally this is only used for a whiteboard or presentation tool. It
specifies the orientation of a the workspace on the screen.
Permitted values are "portrait", "landscape", and "seascape" (upside-
down landscape).
6.9. type (conference type)
Name: type
Value: type-value
Usage Level: session
Charset Dependent: no
Syntax:
type-value = conference-type
conference-type = broadcast / meeting / moderated / test / H332
broadcast = %x62.72.6f.61.64.63.61.73.74 ; "broadcast"
meeting = %x6d.65.65.74.69.6e.67 ; "meeting"
moderated = %x6d.6f.64.65.72.61.74.65.64 ; "moderated"
test = %x74.65.73.74 ; "test"
H332 = %x48.33.33.32 ; "H332"
; NOTE: are these names intended to be case-sensitive?
; Should there be an extensibility hook? A registry?
Example:
a=type:moderated
This specifies the type of the multimedia conference. Suggested
values are "broadcast", "meeting", "moderated", "test", and "H332".
"recvonly" should be the default for "type:broadcast" sessions, "recvonly" should be the default for "type:broadcast" sessions,
"type:meeting" should imply "sendrecv", and "type:moderated" "type:meeting" should imply "sendrecv", and "type:moderated" should
should indicate the use of a floor control tool and that the indicate the use of a floor control tool and that the media tools are
media tools are started so as to mute new sites joining the started so as to mute new sites joining the multimedia conference.
conference.
Specifying the attribute "type:H332" indicates that this Specifying the attribute "type:H332" indicates that this loosely
loosely coupled session is part of an H.332 session as defined coupled session is part of an H.332 session as defined in the ITU
in the ITU H.332 specification [ITU.H332.1998]. Media tools H.332 specification [ITU.H332.1998]. Media tools should be started
should be started "recvonly". "recvonly".
Specifying the attribute "type:test" is suggested as a hint Specifying the attribute "type:test" is suggested as a hint that,
that, unless explicitly requested otherwise, receivers can unless explicitly requested otherwise, receivers can safely avoid
safely avoid displaying this session description to users. displaying this session description to users.
The type attribute is a session-level attribute, and it is not 6.10. charset (character set)
dependent on charset.
a=charset:<character set> Name: charset
This specifies the character set to be used to display the Value: charset-value
session name and information data. By default, the ISO-10646 Usage Level: session
character set in UTF-8 encoding is used. If a more compact
representation is required, other character sets may be used. Charset Dependent: no
For example, the ISO 8859-1 is specified with the following SDP
attribute: Syntax:
charset-value = iana-charset-preferred-mime-name
iana-charset-preferred-mime-name = 1*40VCHAR
; Should we be using Preferred MIME Name or Name?
; Should SP be allowed in the name?
This specifies the character set to be used to display the session
name and information data. By default, the ISO-10646 character set
in UTF-8 encoding is used. If a more compact representation is
required, other character sets may be used. For example, the ISO
8859-1 is specified with the following SDP attribute:
a=charset:ISO-8859-1 a=charset:ISO-8859-1
This is a session-level attribute and is not dependent on The charset specified MUST be one of those registered with IANA, such
charset. The charset specified MUST be one of those registered as ISO-8859-1. The character set identifier is a US-ASCII string and
with IANA, such as ISO-8859-1. The character set identifier is MUST be compared against the IANA identifiers using a case-
a US-ASCII string and MUST be compared against the IANA insensitive comparison. If the identifier is not recognised or not
identifiers using a case-insensitive comparison. If the supported, all strings that are affected by it SHOULD be regarded as
identifier is not recognised or not supported, all strings that 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
of bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets requiring
requiring the use of these characters MUST define a quoting the use of these characters MUST define a quoting mechanism that
mechanism that prevents these bytes from appearing within text prevents these bytes from appearing within text fields.
fields.
a=sdplang:<language tag> 6.11. sdplang (SDP language)
This can be a session-level attribute or a media-level Name: sdplang
attribute. Multiple sdplang attributes can be provided either
at session or media level if the session description or media Value: sdplang-value
use multiple languages.
Usage Level: session, media
Charset Dependent: no
Syntax:
sdplang-value = Language-Tag
Language-Tag = token
; the actual definition of <Language-Tag> is in RFC5646.
; That is a proper subset of <token>. Since the use here is
; to reference definitions done elsewhere against the
; more restrictive definition, it seems reasonable to use
; the simpler syntax here.
; Should we actually reference the RFC5646 definition?
Example:
a=sdplang:fr
This can be a session-level attribute or a media-level attribute.
Multiple sdplang attributes can be provided either at session or
media level if the session description or media use multiple
languages.
As a session-level attribute, it specifies the language for the As a session-level attribute, it specifies the language for the
session description. As a media-level attribute, it specifies session description. As a media-level attribute, it specifies the
the language for any media-level SDP information field language for any media-level SDP information field associated with
associated with that media, overriding any sdplang attributes that media, overriding any sdplang attributes specified at session-
specified at session-level. 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
SHOULD be sent describing the session, one in each language. sent describing the session, one in each language. However, this is
However, this is not possible with all transport mechanisms, not possible with all transport mechanisms, and so multiple sdplang
and so multiple sdplang attributes are allowed although NOT 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
language tag in US-ASCII. It is not dependent on the charset in US-ASCII. 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 geographic
session is distributed with sufficient scope to cross boundaries, where the language of recipients cannot be assumed, or
geographic boundaries, where the language of recipients cannot where the session is in a different language from the locally assumed
be assumed, or where the session is in a different language norm.
from the locally assumed norm.
a=lang:<language tag> 6.12. lang (language)
This can be a session-level attribute or a media-level
attribute. Multiple lang attributes can be provided either at
session or media level if the session or media use multiple
languages, in which case the order of the attributes indicates
the order of importance of the various languages in the session
or media, from most important to least important.
As a session-level attribute, it specifies the default language Name: lang
for the session being described. As a media-level attribute,
it specifies the language for that media, overriding any
session-level languages specified.
The "lang" attribute value must be a single [RFC5646] language Value: lang-value
tag in US-ASCII. It is not dependent on the charset attribute.
A "lang" attribute SHOULD be specified when a session is of
sufficient scope to cross geographic boundaries where the
language of recipients cannot be assumed, or where the session
is in a different language from the locally assumed norm.
a=framerate:<frame rate> Usage Level: session, media
Charset Dependent: no
Syntax:
lang-value = Language-Tag
; <Language-Tag> defined with sdplang.
Example:
a=lang:de
Multiple lang attributes can be provided either at session or media
level if the session or media use multiple languages, in which case
the order of the attributes indicates the order of importance of the
various languages in the session or media, from most important to
least important.
As a session-level attribute, it specifies the default language for
the session being described. As a media-level attribute, it
specifies the language for that media, overriding any session-level
languages specified.
The "lang" attribute value must be a single [RFC5646] language tag in
US-ASCII. A "lang" attribute SHOULD be specified when a session is
of sufficient scope to cross geographic boundaries where the language
of recipients cannot be assumed, or where the session is in a
different language from the locally assumed norm.
6.13. framerate (frame rate)
Name: framerate
Value: framerate-value
Usage Level: media
Charset Dependent: no
Syntax:
framerate-value = positive-real-number
positive-real-number = (integer / "0") [ "." integer ]
; Notes:
; - this permits a zero value. OK?
; - do we want to restrict the range or precision?
Example:
a=framerate:60
This gives the maximum video frame rate in frames/sec. It is This gives the maximum video frame rate in frames/sec. It is
intended as a recommendation for the encoding of video data. intended as a recommendation for the encoding of video data. Decimal
Decimal representations of fractional values using the notation representations of fractional values are allowed. It is defined only
"<integer>.<fraction>" are allowed. It is a media-level for video media.
attribute, defined only for video media, and it is not
dependent on charset.
a=quality:<quality> 6.14. quality
This gives a suggestion for the quality of the encoding as an Name: quality
integer value. The intention of the quality attribute for
video is to specify a non-default trade-off between frame-rate Value: quality-value
and still-image quality. For video, the value is in the range
0 to 10, with the following suggested meaning: Usage Level: media
Charset Dependent: no
Syntax:
quality-value = integer
; Do we want to restrict the range?
; The definition above limits the range to [0-10]
; *for video*, but seems to leave usage open for other media.
Example:
a=quality:10
This gives a suggestion for the quality of the encoding as an integer
value. The intention of the quality attribute for video is to
specify a non-default trade-off between frame-rate and still-image
quality. For video, the value is in the range 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 6.15. fmtp (format parameters)
charset. Name: fmtp
a=fmtp:<format> <format specific parameters> Value: fmtp-value
This attribute allows parameters that are specific to a
particular format to be conveyed in a way that SDP does not
have to understand them. The format must be one of the formats
specified for the media. Format-specific parameters may be any
set of parameters required to be conveyed by SDP and given
unchanged to the media tool that will use this format. At most
one instance of this attribute is allowed for each format.
It is a media-level attribute, and it is not dependent on Usage Level: media
charset.
Charset Dependent: no
Syntax:
fmtp-value = fmt SP format-specific-params
format-specific-params = byte-string
; Notes:
; - I've assumed a space separator is required.
; - the rest is vague because it is format-specific.
Example:
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
This attribute allows parameters that are specific to a particular
format to be conveyed in a way that SDP does not have to understand
them. The format must be one of the formats specified for the media.
Format-specific parameters may be any set of parameters required to
be conveyed by SDP and given unchanged to the media tool that will
use this format. At most one instance of this attribute is allowed
for each format.
7. Security Considerations 7. Security Considerations
SDP is frequently used with the Session Initiation Protocol [RFC3261] SDP is frequently used with the Session Initiation Protocol [RFC3261]
using the offer/answer model [RFC3264] to agree on parameters for using the offer/answer model [RFC3264] to agree on parameters for
unicast sessions. When used in this manner, the security unicast sessions. When used in this manner, the security
considerations of those protocols apply. considerations of those protocols apply.
SDP is a session description format that describes multimedia SDP is a session description format that describes multimedia
sessions. Entities receiving and acting upon an SDP message SHOULD sessions. Entities receiving and acting upon an SDP message SHOULD
skipping to change at page 36, line 4 skipping to change at page 43, line 24
Voice over IP, video teleconferencing, streaming media, instant Voice over IP, video teleconferencing, streaming media, instant
messaging, among others. See also Section 3 of RFC XXXX. messaging, among others. See also Section 3 of RFC XXXX.
Additional information: Additional information:
Magic number(s): None. Magic number(s): None.
File extension(s): The extension ".sdp" is commonly used. File extension(s): The extension ".sdp" is commonly used.
Macintosh File Type Code(s): "sdp " Macintosh File Type Code(s): "sdp "
Person & email address to contact for further information: Person & email address to contact for further information:
Mark Handley <M.Handley@cs.ucl.ac.uk>
Colin Perkins <csp@csperkins.org>
IETF MMUSIC working group <mmusic@ietf.org> IETF MMUSIC working group <mmusic@ietf.org>
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: Author/Change controller:
Authors of RFC XXXX Authors of RFC XXXX
IETF MMUSIC working group delegated from the IESG IETF MMUSIC working group delegated from the IESG
8.2. Registration of Parameters 8.2. Registration of Parameters
There are seven field names that may be registered with IANA. Using There are seven field names that may be registered with IANA. Using
the terminology in the SDP specification Backus-Naur Form (BNF), they the terminology in the SDP specification Backus-Naur Form (BNF), they
are "media", "proto", "fmt", "att-field", "bwtype", "nettype", and are "media", "proto", "fmt", "att-field", "bwtype", "nettype", and
"addrtype". "addrtype".
The contact address for all parameters registered below is:
IETF MMUSIC working group <mmusic@ietf.org>
8.2.1. Media Types ("media") 8.2.1. Media Types ("media")
The set of media types is intended to be small and SHOULD NOT be The set of media types is intended to be small and SHOULD NOT be
extended except under rare circumstances. The same rules should extended except under rare circumstances. The same rules should
apply for media names as for top-level media types, and where apply for media names as for top-level media types, and where
possible the same name should be registered for SDP as for MIME. For possible the same name should be registered for SDP as for MIME. For
media other than existing top-level media types, a Standards Track media other than existing top-level media types, a Standards Track
RFC MUST be produced for a new top-level media type to be registered, RFC MUST be produced for a new top-level media type to be registered,
and the registration MUST provide good justification why no existing and the registration MUST provide good justification why no existing
media name is appropriate (the "Standards Action" policy of media name is appropriate (the "Standards Action" policy of
skipping to change at page 38, line 17 skipping to change at page 45, line 36
Attribute field names ("att-field") MUST be registered with IANA and Attribute field names ("att-field") MUST be registered with IANA and
documented, because of noticeable issues due to conflicting documented, because of noticeable issues due to conflicting
attributes under the same name. Unknown attributes in SDP are simply attributes under the same name. Unknown attributes in SDP are simply
ignored, but conflicting ones that fragment the protocol are a ignored, but conflicting ones that fragment the protocol are a
serious problem. serious problem.
New attribute registrations are accepted according to the New attribute registrations are accepted according to the
"Specification Required" policy of [RFC5226], provided that the "Specification Required" policy of [RFC5226], provided that the
specification includes the following information: specification includes the following information:
o contact name, email address, and telephone number o Contact name, email address, and telephone number.
o attribute name (as it will appear in SDP) o Attribute name (as it will appear in SDP). This MUST conform to
the definition of <att-field>.
o long-form attribute name in English o Attribute value: the name of an ABNF syntax rule defining the
syntax of the value. Absence of a rule name indicates that the
attribute takes no value. Enclosing the rule name in "[" and "]"
indicates that a value is optional.
o type of attribute (session level, media level, or both) o Long-form attribute name in English.
o whether the attribute value is subject to the charset attribute [ED: I propose that we drop the long form. It hasn't been used
and isn't needed.]
o a one-paragraph explanation of the purpose of the attribute o Usage level of the attribute. (One or more of: session, media).
o a specification of appropriate attribute values for this attribute o Whether the attribute value is subject to the charset attribute.
o An ABNF definition of the attribute value rule. The rule MUST NOT
match anything that is not also matched by <att-value>. The rule
name SHOULD [MUST?] NOT be defined as an Incremental Alternative
to <att-value>.
o An explanation of the purpose and usage of the attribute.
o A specification of appropriate attribute values for this attribute
(If not included in syntax).
The above is the minimum that IANA will accept. Attributes that are The above is the minimum that IANA will accept. Attributes that are
expected to see widespread use and interoperability SHOULD be expected to see widespread use and interoperability SHOULD be
documented with a standards-track RFC that specifies the attribute documented with a standards-track RFC that specifies the attribute
more precisely. more precisely.
Submitters of registrations should ensure that the specification is Submitters of registrations should ensure that the specification is
in the spirit of SDP attributes, most notably that the attribute is in the spirit of SDP attributes, most notably that the attribute is
platform independent in the sense that it makes no implicit platform independent in the sense that it makes no implicit
assumptions about operating systems and does not name specific pieces assumptions about operating systems and does not name specific pieces
of software in a manner that might inhibit interoperability. of software in a manner that might inhibit interoperability.
Submitters of registrations should also carefully choose the type of Submitters of registrations should also carefully choose the
attribute. They should not choose a session-level only type when the attribute usage level. They should not choose only session-level
attribute can have different values when media is disaggregated, when the attribute can have different values when media is
i.e., when each m= section has its own IP address on a different disaggregated, i.e., when each m= section has its own IP address on a
endpoint. In that case the attribute type chosen should be "both". different endpoint. In that case the attribute type chosen should be
"session, media".
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 replace those in [RFC4566]):
Name | Session or Media level? | Dependent on charset? [ED: Do we need the following list? I propose that it be dropped
in favor of simply referencing Section 6.]
Name | Usage 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 | Session, Media | No
sendrecv | Either | No sendrecv | Session, Media | No
sendonly | Either | No sendonly | Session, Media | No
inactive | Either | No inactive | Session, Media | No
orient | Media | No orient | Media | No
type | Session | No type | Session | No
charset | Session | No charset | Session | No
sdplang | Either | No sdplang | Session, Media | No
lang | Either | No lang | Session, Media | 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
skipping to change at page 48, line 26 skipping to change at page 56, line 11
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010. RFC 5890, 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: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[I-D.ietf-avtext-rtp-grouping-taxonomy]
Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro,
"A Taxonomy of Grouping Semantics and Mechanisms for Real-
Time Transport Protocol (RTP) Sources", draft-ietf-avtext-
rtp-grouping-taxonomy-02 (work in progress), June 2014.
12.2. Informative References 12.2. Informative References
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and 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
 End of changes. 90 change blocks. 
303 lines changed or deleted 634 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/