draft-ietf-mmusic-rfc4566bis-35.txt   draft-ietf-mmusic-rfc4566bis-36.txt 
Network Working Group A. Begen Network Working Group A. Begen
Internet-Draft Networked Media Internet-Draft Networked Media
Obsoletes: 4566 (if approved) P. Kyzivat Obsoletes: 4566 (if approved) P. Kyzivat
Intended status: Standards Track Intended status: Standards Track
Expires: November 4, 2019 C. Perkins Expires: December 20, 2019 C. Perkins
University of Glasgow University of Glasgow
M. Handley M. Handley
UCL UCL
May 3, 2019 June 18, 2019
SDP: Session Description Protocol SDP: Session Description Protocol
draft-ietf-mmusic-rfc4566bis-35 draft-ietf-mmusic-rfc4566bis-36
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 4, 2019. This Internet-Draft will expire on December 20, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 34 skipping to change at page 2, line 34
2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4
3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . . 5 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . . 5
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 5 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 5
3.2. Streaming Media . . . . . . . . . . . . . . . . . . . . . 5 3.2. Streaming Media . . . . . . . . . . . . . . . . . . . . . 5
3.3. Email and the World Wide Web . . . . . . . . . . . . . . 5 3.3. Email and the World Wide Web . . . . . . . . . . . . . . 5
3.4. Multicast Session Announcement . . . . . . . . . . . . . 5 3.4. Multicast Session Announcement . . . . . . . . . . . . . 5
4. Requirements and Recommendations . . . . . . . . . . . . . . 6 4. Requirements and Recommendations . . . . . . . . . . . . . . 6
4.1. Media and Transport Information . . . . . . . . . . . . . 7 4.1. Media and Transport Information . . . . . . . . . . . . . 7
4.2. Timing Information . . . . . . . . . . . . . . . . . . . 7 4.2. Timing Information . . . . . . . . . . . . . . . . . . . 7
4.3. Obtaining Further Information about a Session . . . . . . 8 4.3. Obtaining Further Information about a Session . . . . . . 8
4.4. Categorization . . . . . . . . . . . . . . . . . . . . . 8 4.4. Internationalization . . . . . . . . . . . . . . . . . . 8
4.5. Internationalization . . . . . . . . . . . . . . . . . . 8
5. SDP Specification . . . . . . . . . . . . . . . . . . . . . . 8 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Protocol Version ("v=") . . . . . . . . . . . . . . . . . 12 5.1. Protocol Version ("v=") . . . . . . . . . . . . . . . . . 12
5.2. Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 12 5.2. Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 13 5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 13
5.4. Session Information ("i=") . . . . . . . . . . . . . . . 13 5.4. Session Information ("i=") . . . . . . . . . . . . . . . 13
5.5. URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . 14 5.5. URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . 14
5.6. Email Address and Phone Number ("e=" and "p=") . . . . . 14 5.6. Email Address and Phone Number ("e=" and "p=") . . . . . 14
5.7. Connection Information ("c=") . . . . . . . . . . . . . . 15 5.7. Connection Information ("c=") . . . . . . . . . . . . . . 15
5.8. Bandwidth Information ("b=") . . . . . . . . . . . . . . 17 5.8. Bandwidth Information ("b=") . . . . . . . . . . . . . . 17
5.9. Time Active ("t=") . . . . . . . . . . . . . . . . . . . 18 5.9. Time Active ("t=") . . . . . . . . . . . . . . . . . . . 18
skipping to change at page 3, line 10 skipping to change at page 3, line 9
5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 21 5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 21
5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 21 5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 21
5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 22 5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 22
6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 25 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 25
6.1. cat (category) . . . . . . . . . . . . . . . . . . . . . 25 6.1. cat (category) . . . . . . . . . . . . . . . . . . . . . 25
6.2. keywds (keywords) . . . . . . . . . . . . . . . . . . . . 26 6.2. keywds (keywords) . . . . . . . . . . . . . . . . . . . . 26
6.3. tool . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.3. tool . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.4. ptime (packet time) . . . . . . . . . . . . . . . . . . . 27 6.4. ptime (packet time) . . . . . . . . . . . . . . . . . . . 27
6.5. maxptime (maximum packet time) . . . . . . . . . . . . . 27 6.5. maxptime (maximum packet time) . . . . . . . . . . . . . 27
6.6. rtpmap . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.6. rtpmap . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.7. Media Direction Attributes . . . . . . . . . . . . . . . 29 6.7. Media Direction Attributes . . . . . . . . . . . . . . . 30
6.7.1. recvonly (receive-only) . . . . . . . . . . . . . . . 30 6.7.1. recvonly (receive-only) . . . . . . . . . . . . . . . 30
6.7.2. sendrecv (send-receive) . . . . . . . . . . . . . . . 30 6.7.2. sendrecv (send-receive) . . . . . . . . . . . . . . . 31
6.7.3. sendonly (send-only) . . . . . . . . . . . . . . . . 31 6.7.3. sendonly (send-only) . . . . . . . . . . . . . . . . 31
6.7.4. inactive . . . . . . . . . . . . . . . . . . . . . . 31 6.7.4. inactive . . . . . . . . . . . . . . . . . . . . . . 32
6.8. orient (orientation) . . . . . . . . . . . . . . . . . . 32 6.8. orient (orientation) . . . . . . . . . . . . . . . . . . 32
6.9. type (conference type) . . . . . . . . . . . . . . . . . 32 6.9. type (conference type) . . . . . . . . . . . . . . . . . 33
6.10. charset (character set) . . . . . . . . . . . . . . . . . 33 6.10. charset (character set) . . . . . . . . . . . . . . . . . 34
6.11. sdplang (SDP language) . . . . . . . . . . . . . . . . . 34 6.11. sdplang (SDP language) . . . . . . . . . . . . . . . . . 34
6.12. lang (language) . . . . . . . . . . . . . . . . . . . . . 35 6.12. lang (language) . . . . . . . . . . . . . . . . . . . . . 35
6.13. framerate (frame rate) . . . . . . . . . . . . . . . . . 36 6.13. framerate (frame rate) . . . . . . . . . . . . . . . . . 36
6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 36 6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 37 6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 37
7. Security Considerations . . . . . . . . . . . . . . . . . . . 38 7. Security Considerations . . . . . . . . . . . . . . . . . . . 38
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
8.1. The "application/sdp" Media Type . . . . . . . . . . . . 40 8.1. The "application/sdp" Media Type . . . . . . . . . . . . 40
8.2. Registration of Parameters . . . . . . . . . . . . . . . 41 8.2. Registration of Parameters . . . . . . . . . . . . . . . 41
8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 41 8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 41
8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 42 8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 42
8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 42 8.2.3. Attribute Names ("att-field") . . . . . . . . . . . . 43
8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 43 8.2.4. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 46
8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 46 8.2.5. Network Types ("nettype") . . . . . . . . . . . . . . 46
8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 46 8.2.6. Address Types ("addrtype") . . . . . . . . . . . . . 47
8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 46 8.2.7. Registration Procedure . . . . . . . . . . . . . . . 47
8.2.8. Registration Procedure . . . . . . . . . . . . . . . 47
8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 47 8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 47
8.4. Reorganization of the nettype Registry . . . . . . . . . 47 8.4. Reorganization of the nettype and addrtype registries . . 48
8.5. Reorganization of the att-field Registries . . . . . . . 48 8.5. Reorganization of the att-field Registries . . . . . . . 48
9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 49 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 49
10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 54 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 54
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 55 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
12.1. Normative References . . . . . . . . . . . . . . . . . . 56 12.1. Normative References . . . . . . . . . . . . . . . . . . 56
12.2. Informative References . . . . . . . . . . . . . . . . . 58 12.2. Informative References . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61
1. Introduction 1. Introduction
When initiating multimedia teleconferences, voice-over-IP calls, When initiating multimedia teleconferences, voice-over-IP calls,
streaming video, or other sessions, there is a requirement to convey streaming video, or other sessions, there is a requirement to convey
media details, transport addresses, and other session description media details, transport addresses, and other session description
metadata to the participants. metadata to the participants.
SDP provides a standard representation for such information, SDP provides a standard representation for such information,
irrespective of how that information is transported. SDP is purely a irrespective of how that information is transported. SDP is purely a
format for session description -- it does not incorporate a transport format for session description -- it does not incorporate a transport
protocol, and it is intended to use different transport protocols as protocol, and it is intended to use different transport protocols as
appropriate, including the Session Announcement Protocol (SAP) appropriate, including the Session Announcement Protocol (SAP)
[RFC2974], Session Initiation Protocol (SIP) [RFC3261], Real Time [RFC2974], Session Initiation Protocol (SIP) [RFC3261], Real Time
Streaming Protocol (RTSP) [RFC7826], electronic mail using the MIME Streaming Protocol (RTSP) [RFC7826], electronic mail [RFC5322] using
extensions [RFC5322], and the Hypertext Transport Protocol (HTTP) the MIME extensions [RFC2045], and the Hypertext Transport Protocol
[RFC7230]. (HTTP) [RFC7230].
SDP is intended to be general purpose so that it can be used in a SDP is intended to be general purpose so that it can be used in a
wide range of network environments and applications. However, it is wide range of network environments and applications. However, it is
not intended to support negotiation of session content or media not intended to support negotiation of session content or media
encodings: this is viewed as outside the scope of session encodings: this is viewed as outside the scope of session
description. description.
This memo obsoletes [RFC4566]. The changes relative to [RFC4566] are This memo obsoletes [RFC4566]. The changes relative to [RFC4566] are
outlined in Section 10 of this memo. outlined in Section 10 of this memo.
skipping to change at page 5, line 14 skipping to change at page 5, line 14
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-
layer control protocol for creating, modifying, and terminating layer control protocol for creating, modifying, and terminating
sessions such as Internet multimedia conferences, Internet telephone sessions such as Internet multimedia conferences, Internet telephone
calls, and multimedia distribution. The SIP messages used to create calls, and multimedia distribution. The SIP messages used to create
sessions carry session descriptions that allow participants to agree sessions carry session descriptions that allow participants to agree
on a set of compatible media types. These session descriptions are on a set of compatible media types [RFC6838]. These session
commonly formatted using SDP. When used with SIP, the offer/answer descriptions are commonly formatted using SDP. When used with SIP,
model [RFC3264] provides a limited framework for negotiation using the offer/answer model [RFC3264] provides a limited framework for
SDP. negotiation using SDP.
3.2. Streaming Media 3.2. Streaming Media
The Real Time Streaming Protocol (RTSP) [RFC7826], is an application- The Real Time Streaming Protocol (RTSP) [RFC7826], is an application-
level protocol for control over the delivery of data with real-time level protocol for control over the delivery of data with real-time
properties. RTSP provides an extensible framework to enable properties. RTSP provides an extensible framework to enable
controlled, on-demand delivery of real-time data, such as audio and controlled, on-demand delivery of real-time data, such as audio and
video. An RTSP client and server negotiate an appropriate set of video. An RTSP client and server negotiate an appropriate set of
parameters for media delivery, partially using SDP syntax to describe parameters for media delivery, partially using SDP syntax to describe
those parameters. those parameters.
skipping to change at page 6, line 15 skipping to change at page 6, line 15
required to participate in the session. required to participate in the session.
One protocol used to implement such a distributed directory is the One protocol used to implement such a distributed directory is the
SAP [RFC2974]. SDP provides the recommended session description SAP [RFC2974]. SDP provides the recommended session description
format for such session announcements. format for such session 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
an internetwork, although it is sufficiently general that it can with Internet protocols, although it is sufficiently general that it
describe multimedia conferences in other network environments. Media can describe multimedia conferences in other network environments.
streams can be many-to-many. Sessions need not be continually Media streams can be many-to-many. Sessions need not be continually
active. active.
Thus far, multicast-based sessions on the Internet have differed from Thus far, multicast-based sessions on the Internet have differed from
many other forms of conferencing in that anyone receiving the traffic many other forms of conferencing in that anyone receiving the traffic
can join the session (unless the session traffic is encrypted). In can join the session (unless the session traffic is encrypted). In
such an environment, SDP serves two primary purposes. It is a means such an environment, SDP serves two primary purposes. It is a means
to communicate the existence of a session, and it is a means to to communicate the existence of a session, and it is a means to
convey sufficient information to enable joining and participating in convey sufficient information to enable joining and participating in
the session. In a unicast environment, only the latter purpose is the session. In a unicast environment, only the latter purpose is
likely to be relevant. likely to be relevant.
skipping to change at page 7, line 34 skipping to change at page 7, line 34
This address and port are the destination address and destination This address and port are the destination address and destination
port of the multicast stream, whether being sent, received, or both. port of the multicast stream, whether being sent, received, or both.
For unicast IP sessions, the following are conveyed: For unicast IP sessions, the following are conveyed:
o The remote address for media o The remote address for media
o The remote transport port for media o The remote transport port for media
The semantics of this address and port depend on the media and The semantics of the address and port depend on context. Typically,
transport protocol defined. By default, this SHOULD be the remote this SHOULD be the remote address and remote port to which media is
address and remote port to which media is sent. Some media types may to be sent or received. Details may differ based on the network
redefine this behavior, but this is NOT RECOMMENDED since it type, address type, protocol and media specified, and whether the SDP
complicates implementations (including middleboxes that must parse is being distributed as an advertisement or negotiated in an offer/
the addresses to open Network Address Translation (NAT) or firewall answer [RFC3264] exchange. (E.g., Some address types or protocols
pinholes). may not have a notion of port.) Deviating from typical behavior
should be done cautiously since this complicates implementations
(including middleboxes that must parse the addresses to open Network
Address Translation (NAT) or firewall pinholes).
4.2. Timing Information 4.2. Timing Information
Sessions may be either bounded or unbounded in time. Whether or not Sessions may be either bounded or unbounded in time. Whether or not
they are bounded, they may be only active at specific times. SDP can they are bounded, they may be only active at specific times. SDP can
convey: convey:
o An arbitrary list of start and stop times bounding the session o An arbitrary list of start and stop times bounding the session
o For each bound, repeat times such as "every Wednesday at 10am for o For each bound, repeat times such as "every Wednesday at 10am for
one hour" one hour"
This timing information is globally consistent, irrespective of local This timing information is globally consistent, irrespective of local
time zone or daylight saving time (see Section 5.9). time zone or daylight saving time (see Section 5.9).
4.3. Obtaining Further Information about a Session 4.3. Obtaining Further Information about a Session
A session description could convey enough information to decide A session description could convey enough information to decide
whether or not to participate in a session. SDP may include whether or not to participate in a session. SDP may include
skipping to change at page 8, line 13 skipping to change at page 8, line 15
one hour" one hour"
This timing information is globally consistent, irrespective of local This timing information is globally consistent, irrespective of local
time zone or daylight saving time (see Section 5.9). time zone or daylight saving time (see Section 5.9).
4.3. Obtaining Further Information about a Session 4.3. Obtaining Further Information about a Session
A session description could convey enough information to decide A session description could convey enough information to decide
whether or not to participate in a session. SDP may include whether or not to participate in a session. SDP may include
additional pointers in the form of Uniform Resource Identifiers additional pointers in the form of Uniform Resource Identifiers
(URIs) for more information about the session. (URIs) [RFC3986] for more information about the session. (Note that
use of URIs to indicate remote resources is subject to the security
4.4. Categorization considerations from [RFC3986].)
When many session descriptions are being distributed by an
advertisement mechanism, it may be desirable to filter session
descriptions that are of interest from those that are not. SDP
supports a categorization mechanism for sessions that is capable of
being automated (the "a=cat:" attribute; see Section 6).
4.5. Internationalization 4.4. Internationalization
The SDP specification recommends the use of the ISO 10646 character The SDP specification recommends the use of the ISO 10646 character
set in the UTF-8 encoding [RFC3629] to allow many different languages set in the UTF-8 encoding [RFC3629] to allow many different languages
to be represented. However, to assist in compact representations, to be represented. However, to assist in compact representations,
SDP also allows other character sets such as ISO 8859-1 to be used SDP also allows other character sets such as [ISO.8859-1.1998] to be
when desired. Internationalization only applies to free-text sub- used when desired. Internationalization only applies to free-text
fields (session name and background information), and not to SDP as a sub-fields (session name and background information), and not to SDP
whole. as a whole.
5. SDP Specification 5. SDP Specification
An SDP description is denoted by the media type "application/sdp" An SDP description is denoted by the media type "application/sdp"
(See Section 8). (See Section 8).
An SDP description is entirely textual. SDP field names and An SDP description is entirely textual. SDP field names and
attribute names use only the US-ASCII subset of UTF-8 [RFC3629], but attribute names use only the US-ASCII subset of UTF-8 [RFC3629], but
textual fields and attribute values MAY use the full ISO 10646 textual fields and attribute values MAY use the full ISO 10646
character set in UTF-8 encoding, or some other character set defined character set in UTF-8 encoding, or some other character set defined
skipping to change at page 9, line 6 skipping to change at page 8, line 51
opposed to a binary encoding such as ASN.1 or XDR, was chosen to opposed to a binary encoding such as ASN.1 or XDR, was chosen to
enhance portability, to enable a variety of transports to be used, enhance portability, to enable a variety of transports to be used,
and to allow flexible, text-based toolkits to be used to generate and and to allow flexible, text-based toolkits to be used to generate and
process session descriptions. However, since SDP may be used in process session descriptions. However, since SDP may be used in
environments where the maximum permissible size of a session environments where the maximum permissible size of a session
description is limited, the encoding is deliberately compact. Also, description is limited, the encoding is deliberately compact. Also,
since descriptions may be transported via very unreliable means or since descriptions may be transported via very unreliable means or
damaged by an intermediate caching server, the encoding was designed damaged by an intermediate caching server, the encoding was designed
with strict order and formatting rules so that most errors would with strict order and formatting rules so that most errors would
result in malformed session descriptions that could be detected result in malformed session descriptions that could be detected
easily and discarded. This also allows rapid discarding of encrypted easily and discarded.
session descriptions for which a receiver does not have the correct
key.
An SDP description consists of a number of lines of text of the form: An SDP description consists of a number of lines of text of the form:
<type>=<value> <type>=<value>
where <type> MUST be exactly one case-significant character and where <type> is exactly one case-significant character and <value> is
<value> is structured text whose format depends on <type>. In structured text whose format depends on <type>. In general, <value>
general, <value> is either a number of sub-fields delimited by a is either a number of sub-fields delimited by a single space
single space character or a free format string, and is case- character or a free format string, and is case-significant unless a
significant unless a specific field defines otherwise. Whitespace specific field defines otherwise. Whitespace separators are not used
separators MUST NOT be used on either side of the "=" sign, however, on either side of the "=" sign, however, the value can contain a
the value can contain a leading whitespace as part of its syntax, leading whitespace as part of its syntax, i.e., that whitespace is
i.e., that whitespace is part of the value. part of the value.
An SDP description MUST conform to the syntax defined in Section 9. An SDP description MUST conform to the syntax defined in Section 9.
The following is an overview of the syntax: The following is an overview of the syntax:
An SDP description consists of a session-level section followed by An SDP description consists of a session-level section followed by
zero or more media descriptions. The session-level section starts zero or more media descriptions. The session-level section starts
with a "v=" line and continues to the first media description (or the with a "v=" line and continues to the first media description (or the
end of the whole description, whichever comes first). Each media end of the whole description, whichever comes first). Each media
description starts with an "m=" line and continues to the next media description starts with an "m=" line and continues to the next media
description or the end of the whole session description, whichever description or the end of the whole session description, whichever
comes first. In general, session-level values are the default for comes first. In general, session-level values are the default for
all media unless overridden by an equivalent media-level value. all media unless overridden by an equivalent media-level value.
Some lines in each description are required and some are optional, Some lines in each description are required and some are optional,
but all must appear in exactly the order given here. (The fixed but when present must appear in exactly the order given here. (The
order greatly enhances error detection and allows for a simple fixed order greatly enhances error detection and allows for a simple
parser). In the following overview optional items are marked with a parser). In the following overview optional items are marked with a
"*". "*".
Session description Session description
v= (protocol version) v= (protocol version)
o= (originator and session identifier) o= (originator and session identifier)
s= (session name) s= (session name)
i=* (session information) i=* (session information)
u=* (URI of description) u=* (URI of description)
e=* (email address) e=* (email address)
skipping to change at page 10, line 37 skipping to change at page 10, line 37
Media description, if present Media description, if present
m= (media name and transport address) m= (media name and transport address)
i=* (media title) i=* (media title)
c=* (connection information -- optional if included at c=* (connection information -- optional if included at
session level) session level)
b=* (zero or more bandwidth information lines) b=* (zero or more bandwidth information lines)
k=* (obsolete) k=* (obsolete)
a=* (zero or more media attribute lines) a=* (zero or more media attribute lines)
The set of type letters is deliberately small and not intended to be The set of type letters is deliberately small and not intended to be
extensible -- an SDP parser MUST completely ignore any session extensible -- an SDP parser MUST completely ignore or reject any
description that contains a type letter that it does not understand. session description that contains a type letter that it does not
The attribute mechanism ("a=" described below) is the primary means understand. The attribute mechanism ("a=" described below) is the
for extending SDP and tailoring it to particular applications or primary means for extending SDP and tailoring it to particular
media. Some attributes (the ones listed in Section 6 of this memo) applications or media. Some attributes (the ones listed in Section 6
have a defined meaning, but others may be added on a media- or of this memo) have a defined meaning, but others may be added on a
session-specific basis. (Attribute scopes in addition to media- media- or session-specific basis. (Attribute scopes in addition to
specific and session-specific may also be defined in extensions to media-specific and session-specific may also be defined in extensions
this document. E.g., [RFC5576], to this document. E.g., [RFC5576],
[I-D.ietf-mmusic-data-channel-sdpneg].) An SDP parser MUST ignore [I-D.ietf-mmusic-data-channel-sdpneg].) An SDP parser MUST ignore
any attribute it doesn't understand. any attribute it doesn't understand.
An SDP description may contain URIs that reference external content An SDP description may contain URIs that reference external content
in the "u=", "k=", and "a=" lines. These URIs may be dereferenced in in the "u=", "k=", and "a=" lines. These URIs may be dereferenced in
some cases, making the session description non-self-contained. some cases, making the session description non-self-contained.
The connection ("c=") information in the session-level section The connection ("c=") information in the session-level section
applies to all the media descriptions of that session unless applies to all the media descriptions of that session unless
overridden by connection information in the media description. For overridden by connection information in the media description. For
instance, in the example below, each audio media description behaves instance, in the example below, each audio media description behaves
as if it were given a "c=IN IP4 233.252.0.2". as if it were given a "c=IN IP4 198.51.100.1".
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 3724394400 3724394405 IN IP4 198.51.100.1
s=SDP Seminar s=Call to John Smith
i=A Seminar on the session description protocol i=SDP Offer #1
u=http://www.example.com/seminars/sdp.pdf u=http://www.jdoe.example.com/home.html
e=j.doe@example.com (Jane Doe) e=Jane Doe <jane@jdoe.example.com>
c=IN IP4 233.252.0.2 p=+1 617 555-6011
t=2873397496 2873404696 c=IN IP4 198.51.100.1
a=recvonly t=0 0
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
m=audio 49180 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 c=IN IP6 2001:db8::2
a=rtpmap:99 h263-1998/90000 a=rtpmap:99 h263-1998/90000
Text-containing fields such as the session-name-field and Text-containing fields such as the session-name-field and
information-field are octet strings that may contain any octet with information-field are octet strings that may contain any octet with
the exceptions of 0x00 (Nul), 0x0a (ASCII newline), and 0x0d (ASCII the exceptions of 0x00 (Nul), 0x0a (ASCII newline), and 0x0d (ASCII
carriage return). The sequence CRLF (0x0d0a) is used to end a line, carriage return). The sequence CRLF (0x0d0a) is used to end a line,
although parsers SHOULD be tolerant and also accept lines terminated although parsers SHOULD be tolerant and also accept lines terminated
with a single newline character. If the "a=charset" attribute is not with a single newline character. If the "a=charset" attribute is not
present, these octet strings MUST be interpreted as containing present, these octet strings MUST be interpreted as containing
ISO-10646 characters in UTF-8 encoding (the presence of the ISO-10646 characters in UTF-8 encoding. When the "a=charset"
"a=charset" attribute may force some fields to be interpreted attribute is present the session-name-field, information-field, and
differently). some attribute fields are interpreted according to the selected
character set.
A session description can contain domain names in the "o=", "u=", A session description can contain domain names in the "o=", "u=",
"e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply "e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply
with [RFC1034], [RFC1035]. Internationalized domain names (IDNs) with [RFC1034] and [RFC1035]. Internationalized domain names (IDNs)
MUST be represented using the ASCII Compatible Encoding (ACE) form MUST be represented using the ASCII Compatible Encoding (ACE) form
defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or
any other encoding (this requirement is for compatibility with any other encoding (this requirement is for compatibility with
[RFC2327] and other early SDP-related standards, which predate the [RFC2327] and other early SDP-related standards, which predate the
development of internationalized domain names). development of internationalized domain names).
5.1. Protocol Version ("v=") 5.1. Protocol Version ("v=")
v=0 v=0
skipping to change at page 12, line 29 skipping to change at page 12, line 29
username and the address of the user's host) plus a session username and the address of the user's host) plus a session
identifier and version number: identifier and version 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 <sess- globally unique identifier for the session. The method of <sess-
id> allocation is up to the creating tool, but it has been id> allocation is up to the creating tool, but a timestamp, in
suggested that a Network Time Protocol (NTP) format timestamp be seconds since January 1, 1900 UTC, is recommended to ensure
used to ensure uniqueness [RFC5905]. uniqueness.
<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 description. increased when a modification is made to the session description.
Again, it is RECOMMENDED that an NTP format timestamp is used. Again, as with <sess-id> it is RECOMMENDED that a timestamp be
used.
<nettype> is a text string giving the type of network. Initially <nettype> is a text string giving the type of network. Initially
"IN" is defined to have the meaning "Internet", but other values "IN" is defined to have the meaning "Internet", but other values
MAY be registered in the future (see Section 8). MAY be registered in the future (see Section 8).
<addrtype> is a text string giving the type of the address that <addrtype> is a text string giving the type of the address that
follows. Initially "IP4" and "IP6" are defined, but other values follows. Initially "IP4" and "IP6" are defined, but other values
MAY be registered in the future (see Section 8). MAY be registered in the future (see Section 8).
<unicast-address> is an address of the machine from which the <unicast-address> is an address of the machine from which the
session was created. For an address type of IP4, this is either a session was created. For an address type of IP4, this is either a
fully qualified domain name of the machine or the dotted-decimal fully qualified domain name of the machine or the dotted-decimal
representation of an IP version 4 address of the machine. For an representation of an IP version 4 address of the machine. For an
address type of IP6, this is either a fully qualified domain name address type of IP6, this is either a fully qualified domain name
of the machine or the compressed textual representation of an IP of the machine or the address of the machine represented as
version 6 address of the machine. For both IP4 and IP6, the fully specified in Section 4 of [RFC5952]. For both IP4 and IP6, the
qualified domain name is the form that SHOULD be given unless this fully qualified domain name is the form that SHOULD be given
is unavailable, in which case a globally unique address MAY be unless this is unavailable, in which case a globally unique
substituted. address MAY be substituted.
In general, the "o=" line serves as a globally unique identifier for In general, the "o=" line serves as a globally unique identifier for
this version of the session description, and the sub-fields excepting this version of the session description, and the sub-fields excepting
the version, taken together identify the session irrespective of any the version, taken together identify the session irrespective of any
modifications. modifications.
For privacy reasons, it is sometimes desirable to obfuscate the For privacy reasons, it is sometimes desirable to obfuscate the
username and IP address of the session originator. If this is a username and IP address of the session originator. If this is a
concern, an arbitrary <username> and private <unicast-address> MAY be concern, an arbitrary <username> and private <unicast-address> MAY be
chosen to populate the "o=" line, provided that these are selected in chosen to populate the "o=" line, provided that these are selected in
a manner that does not affect the global uniqueness of the field. a manner that does not affect the global uniqueness of the field.
5.3. Session Name ("s=") 5.3. Session Name ("s=")
s=<session name> s=<session name>
The "s=" line (session-name-field) is the textual session name. The "s=" line (session-name-field) is the textual session name.
There MUST be one and only one "s=" line per session description. There MUST be one and only one "s=" line per session description.
The "s=" line MUST NOT be empty and SHOULD contain ISO 10646 The "s=" line MUST NOT be empty. If a session has no meaningful
characters (but see also the "a=charset" attribute). If a session name, then "s= " or "s=-" (i.e., a single space or dash as the
has no meaningful name, the "s= " line SHOULD be used (i.e., a single session name) is RECOMMENDED. If a session-level "a=charset"
space as the session name). attribute is present, it specifies the character set used in the "s="
field. If a session-level "a=charset" attribute is not present, the
"s=" field MUST contain ISO 10646 characters in UTF-8 encoding.
5.4. Session Information ("i=") 5.4. Session Information ("i=")
i=<session information> i=<session information>
The "i=" line (information-field) provides textual information about The "i=" line (information-field) provides textual information about
the session. There MUST be at most one session-level "i=" line per the session. There can be at most one session-level "i=" line per
session description, and at most one "i=" line in each media session description, and at most one "i=" line in each media
description. Unless a media-level "i=" line is provided, the description. Unless a media-level "i=" line is provided, the
session-level "i=" line applies to that media description. If the session-level "i=" line applies to that media description. If the
"a=charset" attribute is present, it specifies the character set used "a=charset" attribute is present, it specifies the character set used
in the "i=" line. If the "a=charset" attribute is not present, the in the "i=" line. If the "a=charset" attribute is not present, the
"i=" line MUST contain ISO 10646 characters in UTF-8 encoding. "i=" line MUST contain ISO 10646 characters in UTF-8 encoding.
At most one "i=" line can be used for each media description. In At most one "i=" line can be used for each media description. In
media definitions, "i=" lines are primarily intended for labelling media definitions, "i=" lines are primarily intended for labelling
media streams. As such, they are most likely to be useful when a media streams. As such, they are most likely to be useful when a
skipping to change at page 14, line 14 skipping to change at page 14, line 14
The "i=" line is intended to provide a free-form human-readable The "i=" line is intended to provide a free-form human-readable
description of the session or the purpose of a media stream. It is description of the session or the purpose of a media stream. It is
not suitable for parsing by automata. not suitable for parsing by automata.
5.5. URI ("u=") 5.5. URI ("u=")
u=<uri> u=<uri>
The "u=" line (uri-field) provides a URI (Uniform Resource The "u=" line (uri-field) provides a URI (Uniform Resource
Identifier) as used by WWW clients [RFC3986]. The URI should be a Identifier) [RFC3986]. The URI should be a pointer to additional
pointer to additional information about the session. This line is human readable information about the session. This line is OPTIONAL.
OPTIONAL. No more than one "u=" line is allowed per session No more than one "u=" line is allowed per session description.
description.
5.6. Email Address and Phone Number ("e=" and "p=") 5.6. Email Address and Phone Number ("e=" and "p=")
e=<email-address> e=<email-address>
p=<phone-number> p=<phone-number>
The "e=" line (email-field) and "p=" line (phone-field) specify The "e=" line (email-field) and "p=" line (phone-field) specify
contact information for the person responsible for the session. This contact information for the person responsible for the session. This
is not necessarily the same person that created the session is not necessarily the same person that created the session
description. description.
skipping to change at page 16, line 46 skipping to change at page 16, line 46
would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3 would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3
are to be used with a TTL of 127. This is semantically identical to are to be used with a TTL of 127. This is semantically identical to
including multiple "c=" lines in a media description: including multiple "c=" lines in a media description:
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
c=IN IP4 233.252.0.2/127 c=IN IP4 233.252.0.2/127
c=IN IP4 233.252.0.3/127 c=IN IP4 233.252.0.3/127
Similarly, an IPv6 example would be: Similarly, an IPv6 example would be:
c=IN IP6 FF15::101/3 c=IN IP6 ff00::db8:0:101/3
which is semantically equivalent to: which is semantically equivalent to:
c=IN IP6 FF15::101 c=IN IP6 ff00::db8:0:101
c=IN IP6 FF15::102 c=IN IP6 ff00::db8:0:102
c=IN IP6 FF15::103 c=IN IP6 ff00::db8:0:103
(remembering that the TTL sub-field is not present in IP6 multicast). (remembering that the TTL sub-field is not present in IP6 multicast).
Multiple addresses or "c=" lines MAY be specified on a per media Multiple addresses or "c=" lines MAY be specified on a per media
description basis only if they provide multicast addresses for description basis only if they provide multicast addresses for
different layers in a hierarchical or layered encoding scheme. different layers in a hierarchical or layered encoding scheme.
Multiple addresses or "c=" lines MUST NOT be specified at session Multiple addresses or "c=" lines MUST NOT be specified at session
level. level.
The slash notation for multiple addresses described above MUST NOT be The slash notation for multiple addresses described above MUST NOT be
skipping to change at page 17, line 35 skipping to change at page 17, line 35
bandwidth to be used by the session or media description. The bandwidth to be used by the session or media description. The
<bwtype> is an alphanumeric modifier giving the meaning of the <bwtype> is an alphanumeric modifier giving the meaning of the
<bandwidth> figure. Two values are defined in this specification, <bandwidth> figure. Two values are defined in this specification,
but other values MAY be registered in the future (see Section 8 and but other values MAY be registered in the future (see Section 8 and
[RFC3556], [RFC3890]): [RFC3556], [RFC3890]):
CT If the bandwidth of a session is different from the bandwidth CT If the bandwidth of a session is different from the bandwidth
implicit from the scope, a "b=CT:..." line SHOULD be supplied for implicit from the scope, a "b=CT:..." line SHOULD be supplied for
the session giving the proposed upper limit to the bandwidth used the session giving the proposed upper limit to the bandwidth used
(the "conference total" bandwidth). Similarly, if the bandwidth (the "conference total" bandwidth). Similarly, if the bandwidth
of bundled media streams in an "m=" line is different from the of bundled media streams [I-D.ietf-mmusic-sdp-bundle-negotiation]
implicit value from the scope, a "b=CT:..." line SHOULD be in an "m=" line is different from the implicit value from the
supplied in the media level. The primary purpose of this is to scope, a "b=CT:..." line SHOULD be supplied in the media level.
give an approximate idea as to whether two or more sessions (or The primary purpose of this is to give an approximate idea as to
bundled media streams) can coexist simultaneously. Note that CT whether two or more sessions (or bundled media streams) can
gives a total bandwidth figure for all the media at all endpoints. coexist simultaneously. Note that CT gives a total bandwidth
figure for all the media at all endpoints.
AS The bandwidth is interpreted to be application specific (it will AS The bandwidth is interpreted to be application specific (it will
be the application's concept of maximum bandwidth). Normally, be the application's concept of maximum bandwidth). Normally,
this will coincide with what is set on the application's "maximum this will coincide with what is set on the application's "maximum
bandwidth" control if applicable. For RTP-based applications, AS bandwidth" control if applicable. For RTP-based applications, AS
gives the RTP "session bandwidth" as defined in Section 6.2 of gives the RTP "session bandwidth" as defined in Section 6.2 of
[RFC3550]. Note that AS gives a bandwidth figure for a single [RFC3550]. Note that AS gives a bandwidth figure for a single
media at a single endpoint, although there may be many endpoints media at a single endpoint, although there may be many endpoints
sending simultaneously. sending simultaneously.
skipping to change at page 18, line 40 skipping to change at page 18, line 43
(see below) can be included following the time-field -- in which case (see below) can be included following the time-field -- in which case
the time-field specifies the start and stop times of the entire the time-field specifies the start and stop times of the entire
repeat sequence. repeat sequence.
The following example specifies two active intervals: The following example specifies two active intervals:
t=3724394400 3724398000 ; Mon 8-Jan-2018 10:00-11:00 UTC t=3724394400 3724398000 ; Mon 8-Jan-2018 10:00-11:00 UTC
t=3724484400 3724488000 ; Tue 9-Jan-2018 11:00-12:00 UTC t=3724484400 3724488000 ; Tue 9-Jan-2018 11:00-12:00 UTC
The first and second sub-fields of the time-field give the start and The first and second sub-fields of the time-field give the start and
stop times, respectively, for the session. These values are the stop times, respectively, for the session. These are the decimal
decimal representation of Network Time Protocol (NTP) time values in representation of time values in seconds since January 1, 1900 UTC.
seconds since 1900 [RFC5905]. To convert these values to UNIX time To convert these values to UNIX time (UTC), subtract decimal
(UTC), subtract decimal 2208988800. 2208988800.
NTP timestamps are elsewhere represented by 64-bit values, which wrap Some time representations will wrap in the year 2036. Because SDP
sometime in the year 2036. Since SDP uses an arbitrary length uses an arbitrary length decimal representation, it does not have
decimal representation, this should not cause an issue (SDP this issue. Implementations of SDP need to be prepared to handle
timestamps MUST continue counting seconds since 1900 - NTP will use these larger values.
the value modulo the 64-bit limit).
If the <stop-time> is set to zero, then the session is not bounded, If the <stop-time> is set to zero, then the session is not bounded,
though it will not become active until after the <start-time>. If though it will not become active until after the <start-time>. If
the <start-time> is also zero, the session is regarded as permanent. the <start-time> is also zero, the session is regarded as permanent.
User interfaces SHOULD strongly discourage the creation of unbounded User interfaces SHOULD strongly discourage the creation of unbounded
and permanent sessions as they give no information about when the and permanent sessions as they give no information about when the
session is actually going to terminate, and so make scheduling session is actually going to terminate, and so make scheduling
difficult. difficult.
skipping to change at page 19, line 34 skipping to change at page 19, line 34
the session will be active. the session will be active.
5.10. Repeat Times ("r=") 5.10. Repeat Times ("r=")
r=<repeat interval> <active duration> <offsets from start-time> r=<repeat interval> <active duration> <offsets from start-time>
An"r=" line (repeat-field) specifies repeat times for a session. If An"r=" line (repeat-field) specifies repeat times for a session. If
needed to express complex schedules, multiple repeat-fields may be needed to express complex schedules, multiple repeat-fields may be
included. For example, if a session is active at 10am on Monday and included. For example, if a session is active at 10am on Monday and
11am on Tuesday for one hour each week for three months, then the 11am on Tuesday for one hour each week for three months, then the
<start-time> in the corresponding "t=" line would be the NTP <start-time> in the corresponding "t=" line would be the
representation of 10am on the first Monday, the <repeat interval> representation of 10am on the first Monday, the <repeat interval>
would be 1 week, the <active duration> would be 1 hour, and the would be 1 week, the <active duration> would be 1 hour, and the
offsets would be zero and 25 hours. The corresponding "t=" line stop offsets would be zero and 25 hours. The corresponding "t=" line stop
time would be the NTP representation of the end of the last session time would be the representation of the end of the last session three
three months later. By default, all sub-fields are in seconds, so months later. By default, all sub-fields are in seconds, so the "r="
the "r=" and "t=" lines might be the following: and "t=" lines might be the following:
t=3724394400 3730536000 ; Mon 8-Jan-2018 10:00-11:00 UTC t=3724394400 3730536000 ; Mon 8-Jan-2018 10:00-11:00 UTC
; Tues 20-Mar-2018 12:00 UTC ; Tues 20-Mar-2018 12:00 UTC
r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours
To make the description more compact, times may also be given in To make the description more compact, times may also be given in
units of days, hours, or minutes. The syntax for these is a number units of days, hours, or minutes. The syntax for these is a number
immediately followed by a single case-sensitive character. immediately followed by a single case-sensitive character.
Fractional units are not allowed -- a smaller unit should be used Fractional units are not allowed -- a smaller unit should be used
instead. The following unit specification characters are allowed: instead. The following unit specification characters are allowed:
skipping to change at page 20, line 35 skipping to change at page 20, line 35
To schedule a repeated session that spans a change from daylight To schedule a repeated session that spans a change from daylight
saving time to standard time or vice versa, it is necessary to saving time to standard time or vice versa, it is necessary to
specify offsets from the base time. This is required because specify offsets from the base time. This is required because
different time zones change time at different times of day, different different time zones change time at different times of day, different
countries change to or from daylight saving time on different dates, countries change to or from daylight saving time on different dates,
and some countries do not have daylight saving time at all. and some countries do not have daylight saving time at all.
Thus, in order to schedule a session that is at the same time winter Thus, in order to schedule a session that is at the same time winter
and summer, it must be possible to specify unambiguously by whose and summer, it must be possible to specify unambiguously by whose
time zone a session is scheduled. To simplify this task for time zone a session is scheduled. To simplify this task for
receivers, we allow the sender to specify the NTP time that a time receivers, we allow the sender to specify the time (represented as
zone adjustment happens and the offset from the time when the session seconds since January 1, 1900 UTC) that a time zone adjustment
was first scheduled. The "z=" line allows the sender to specify a happens and the offset from the time when the session was first
list of these adjustment times and offsets from the base time. scheduled. The "z=" line allows the sender to specify a list of
these adjustment times and offsets from the base time.
An example might be the following: An example might be the following:
t=3724394400 3754123200 ; Mon 8-Jan-2018 10:00 UTC t=3724394400 3754123200 ; Mon 8-Jan-2018 10:00 UTC
; Tues 18-Dec-2018 12:00 UTC ; Tues 18-Dec-2018 12:00 UTC
r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours
z=3730928400 -1h 3749680800 0 ; Sun 25-Mar-2018 1:00 UTC, z=3730928400 -1h 3749680800 0 ; Sun 25-Mar-2018 1:00 UTC,
; offset 1 hour, ; offset 1 hour,
; Sun 28-Oct-2018 2:00 UTC, no offset ; Sun 28-Oct-2018 2:00 UTC,
; no offset
This specifies that at time 3730928400 (Sun 25-Mar-2018 1:00 UTC, the This specifies that at time 3730928400 (Sun 25-Mar-2018 1:00 UTC, the
onset of British Summer Time) the time base by which the session's onset of British Summer Time) the time base by which the session's
repeat times are calculated is shifted back by 1 hour, and that at repeat times are calculated is shifted back by 1 hour, and that at
time 3749680800 (Sun 28-Oct-2018 2:00 UTC, the end of British Summer time 3749680800 (Sun 28-Oct-2018 2:00 UTC, the end of British Summer
Time) the session's original time base is restored. Adjustments are Time) the session's original time base is restored. Adjustments are
always relative to the specified start time -- they are not always relative to the specified start time -- they are not
cumulative. cumulative.
If a session is likely to last several years, it is expected that the If a session is likely to last several years, it is expected that the
skipping to change at page 23, line 40 skipping to change at page 23, line 45
hierarchically encoded streams using non-contiguous ports. (There hierarchically encoded streams using non-contiguous ports. (There
is currently no attribute defined that can accomplish this. The is currently no attribute defined that can accomplish this. The
"a=rtcp:" defined in [RFC3605] does not handle hierarchical "a=rtcp:" defined in [RFC3605] does not handle hierarchical
encoding.) If a need arises to declare non-contiguous ports then encoding.) If a need arises to declare non-contiguous ports then
it will be necessary to define a new attribute to do so. it will be necessary to define a new attribute to do so.
If multiple addresses are specified in the "c=" line and multiple If multiple addresses are specified in the "c=" line and multiple
ports are specified in the "m=" line, a one-to-one mapping from ports are specified in the "m=" line, a one-to-one mapping from
port to the corresponding address is implied. For example: port to the corresponding address is implied. For example:
c=IN IP4 233.252.0.1/127/2
m=video 49170/2 RTP/AVP 31 m=video 49170/2 RTP/AVP 31
c=IN IP4 233.252.0.1/127/2
would imply that address 233.252.0.1 is used with ports 49170 and would imply that address 233.252.0.1 is used with ports 49170 and
49171, and address 233.252.0.2 is used with ports 49172 and 49173. 49171, and address 233.252.0.2 is used with ports 49172 and 49173.
The mapping is similar if multiple addresses are specified using
multiple "c=" lines. For example:
m=video 49170/2 RTP/AVP 31
c=IN IP6 ff00::db8:0:101
c=IN IP6 ff00::db8:0:102
would imply that address ff00::db8:0:101 is used with ports 49170
and 49171, and address ff00::db8:0:102 is used with ports 49172
and 49173.
This document gives no meaning to assigning the same media address This document gives no meaning to assigning the same media address
to multiple media-descriptions. Doing so does not implicitly to multiple media-descriptions. Doing so does not implicitly
group those media-descriptions in any way. An explicit grouping group those media-descriptions in any way. An explicit grouping
framework (for example, [RFC5888]) should instead be used to framework (for example, [RFC5888]) should instead be used to
express the intended semantics. For instance, see express the intended semantics. For instance, see
[I-D.ietf-mmusic-sdp-bundle-negotiation]. [I-D.ietf-mmusic-sdp-bundle-negotiation].
<proto> is the transport protocol. The meaning of the transport <proto> is the transport protocol. The meaning of the transport
protocol is dependent on the address type sub-field in the protocol is dependent on the address type sub-field in the
relevant "c=" line. Thus a "c=" line with an address type of IP4 relevant "c=" line. Thus a "c=" line with an address type of IP4
skipping to change at page 26, line 24 skipping to change at page 26, line 38
Syntax: Syntax:
keywds-value = keywords keywds-value = keywords
keywords = text keywords = text
Example: Example:
a=keywds:SDP session description protocol a=keywds:SDP session description protocol
Like the cat attribute, this is to assist identifying wanted sessions Like the cat attribute, this was intended to assist identifying
at the receiver. This allows a receiver to select interesting wanted sessions at the receiver. This allows a receiver to select
sessions based on keywords describing the purpose of the session; interesting sessions based on keywords describing the purpose of the
there is no central registry of keywords. Its value should be session; there is no central registry of keywords. Its value should
interpreted in the charset specified for the session description if be interpreted in the charset specified for the session description
one is specified, or by default in ISO 10646/UTF-8. This attribute if one is specified, or by default in ISO 10646/UTF-8. This
is obsolete and SHOULD NOT be used. It SHOULD be ignored if attribute is obsolete and SHOULD NOT be used. It SHOULD be ignored
received. if received.
6.3. tool 6.3. tool
Name: tool Name: tool
Value: tool-value Value: tool-value
Usage Level: session Usage Level: session
Charset Dependent: no Charset Dependent: no
Syntax: Syntax:
tool-value = tool-name-and-version tool-value = tool-name-and-version
tool-name-and-version = text tool-name-and-version = text
Example: Example:
skipping to change at page 29, line 44 skipping to change at page 30, line 9
session. Codec-specific parameters should be added in other session. Codec-specific parameters should be added in other
attributes (for example, "a=fmtp:"). attributes (for example, "a=fmtp:").
Note: RTP audio formats typically do not include information about Note: RTP audio formats typically do not include information about
the number of samples per packet. If a non-default (as defined in the number of samples per packet. If a non-default (as defined in
the RTP Audio/Video Profile [RFC3551]) packetization is required, the the RTP Audio/Video Profile [RFC3551]) packetization is required, the
"ptime" attribute is used as given above. "ptime" attribute is used as given above.
6.7. Media Direction Attributes 6.7. Media Direction Attributes
At most one occurence of recvonly, sendrecv, sendonly, or inactive At most one occurrence of recvonly, sendrecv, sendonly, or inactive
MAY appear at session level, and at most one MAY appear in each media MAY appear at session level, and at most one MAY appear in each media
description. description.
If any one of these appears in a media description then it applies If any one of these appears in a media description then it applies
for that media description. If none appear in a media description for that media description. If none appear in a media description
then the one from session level, if any, applies to that media then the one from session level, if any, applies to that media
description. description.
If none of the media direction attributes is present at either If none of the media direction attributes is present at either
session level or media level, "sendrecv" SHOULD be assumed as the session level or media level, "sendrecv" SHOULD be assumed as the
default for sessions that are not of the multimedia conference type default.
"broadcast" or "H332" (see below).
Within the following SDP example, the "inactive" attribute applies to Within the following SDP example, the "sendrecv" attribute applies to
audio media and the "recvonly" attribute applies to video media. the first audio media and the "inactive" attribute applies to the
others.
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 o=jdoe 3724395000 3724395001 IN IP6 2001:db8::1
s=SDP Seminar s=-
i=A Seminar on the session description protocol c=IN IP6 2001:db8::1
u=http://www.example.com/seminars/sdp.pdf t=0 0
e=j.doe@example.com (Jane Doe) a=inactive
c=IN IP4 233.252.0.1/127 m=audio 49170 RTP/AVP 0
t=2873397496 2873404696 a=sendrecv
a=inactive m=audio 49180 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
6.7.1. recvonly (receive-only) 6.7.1. recvonly (receive-only)
Name: recvonly Name: recvonly
Value: Value:
Usage Level: session, media Usage Level: session, media
Charset Dependent: no Charset Dependent: no
skipping to change at page 33, line 20 skipping to change at page 33, line 31
meeting = %s"meeting" meeting = %s"meeting"
moderated = %s"moderated" moderated = %s"moderated"
test = %s"test" test = %s"test"
H332 = %s"H332" H332 = %s"H332"
; NOTE: These names are case-sensitive. ; NOTE: These names are case-sensitive.
Example: Example:
a=type:moderated a=type:moderated
This specifies the type of the multimedia conference. Suggested This specifies the type of the multimedia conference. Allowed values
values are "broadcast", "meeting", "moderated", "test", and "H332". are "broadcast", "meeting", "moderated", "test", and "H332". These
"recvonly" should be the default for "type:broadcast" sessions, values have implications for other options that are likely to be
"type:meeting" should imply "sendrecv", and "type:moderated" should appropriate:
indicate the use of a floor control tool and that the media tools are
started so as to mute new sites joining the multimedia conference.
Specifying the attribute "type:H332" indicates that this loosely o When "a=type:broadcast" is specified, "a=recvonly" is probably
coupled session is part of an H.332 session as defined in the ITU appropriate for those connecting.
H.332 specification [ITU.H332.1998]. Media tools should be started
"recvonly".
Specifying the attribute "type:test" is suggested as a hint that, o When "a=type:meeting" is specified, "a=sendrecv" is likely to be
unless explicitly requested otherwise, receivers can safely avoid appropriate.
displaying this session description to users.
o "a=type:moderated" suggests the use of a floor control tool and
that the media tools be started so as to mute new sites joining
the multimedia conference.
o Specifying "a=type:H332" indicates that this loosely coupled
session is part of an H.332 session as defined in the ITU H.332
specification [ITU.H332.1998]. Media tools should be started
using "a=recvonly".
o Specifying "a=type:test" is suggested as a hint that, unless
explicitly requested otherwise, receivers can safely avoid
displaying this session description to users.
6.10. charset (character set) 6.10. charset (character set)
Name: charset Name: charset
Value: charset-value Value: charset-value
Usage Level: session Usage Level: session
Charset Dependent: no Charset Dependent: no
skipping to change at page 34, line 13 skipping to change at page 34, line 34
name and information data. By default, the ISO-10646 character set name and information data. By default, the ISO-10646 character set
in UTF-8 encoding is used. If a more compact representation is in UTF-8 encoding is used. If a more compact representation is
required, other character sets may be used. For example, the ISO required, other character sets may be used. For example, the ISO
8859-1 is specified with the following SDP attribute: 8859-1 is specified with the following SDP attribute:
a=charset:ISO-8859-1 a=charset:ISO-8859-1
The charset specified MUST be one of those registered in the IANA The charset specified MUST be one of those registered in the IANA
Character Sets registry (http://www.iana.org/assignments/character- Character Sets registry (http://www.iana.org/assignments/character-
sets), such as ISO-8859-1. The character set identifier is a string sets), such as ISO-8859-1. The character set identifier is a string
in the US-ASCII subset of UTF-8 and MUST be compared against that MUST be compared against identifiers from the "Name" or
identifiers from the "Name" or "Preferred MIME Name" field of the "Preferred MIME Name" field of the registry using a case-insensitive
registry using a case-insensitive comparison. If the identifier is comparison. If the identifier is not recognized or not supported,
not recognised or not supported, all strings that are affected by it all strings that are affected by it SHOULD be regarded as octet
SHOULD be regarded as octet strings. strings.
Note that a character set specified MUST still prohibit the use of Charset-dependent fields MUST contain only sequences of bytes that
bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets requiring are valid according to the definition of the selected character set.
the use of these characters MUST define a quoting mechanism that Furthermore, charset-dependent fields MUST NOT contain the bytes 0x00
prevents these bytes from appearing within text fields. (Nul), 0x0A (LF), and 0x0d (CR).
6.11. sdplang (SDP language) 6.11. sdplang (SDP language)
Name: sdplang Name: sdplang
Value: sdplang-value Value: sdplang-value
Usage Level: session, media Usage Level: session, media
Charset Dependent: no Charset Dependent: no
Syntax: Syntax:
sdplang-value = Language-Tag sdplang-value = Language-Tag
; Language-Tag defined in RFC5646 ; Language-Tag defined in RFC5646
Example: Example:
a=sdplang:fr a=sdplang:fr
skipping to change at page 35, line 13 skipping to change at page 35, line 32
information-field associated with that media (again not the language information-field associated with that media (again not the language
of the media), overriding any sdplang attributes specified at session of the media), overriding any sdplang attributes 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 sesssion descriptions languages is discouraged. Instead, multiple sesssion 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, and so However, this is not possible with all transport mechanisms, and so
multiple sdplang attributes are allowed although NOT RECOMMENDED. multiple sdplang attributes are allowed although NOT RECOMMENDED.
The "sdplang" attribute value must be a single [RFC5646] language tag The "sdplang" attribute value must be a single [RFC5646] language
in the US-ASCII subset of UTF-8. An "sdplang" attribute SHOULD be tag. An "sdplang" attribute SHOULD be specified when a session is
specified when a session is distributed with sufficient scope to distributed with sufficient scope to cross geographic boundaries,
cross geographic boundaries, where the language of recipients cannot where the language of recipients cannot be assumed, or where the
be assumed, or where the session is in a different language from the session is in a different language from the locally assumed norm.
locally assumed norm.
6.12. lang (language) 6.12. lang (language)
Name: lang Name: lang
Value: lang-value Value: lang-value
Usage Level: session, media Usage Level: session, media
Charset Dependent: no Charset Dependent: no
skipping to change at page 35, line 50 skipping to change at page 36, line 20
level if the session or media has capabilities in more than one level if the session or media has capabilities in more than one
language, in which case the order of the attributes indicates the language, in which case the order of the attributes indicates the
order of preference of the various languages in the session or media, order of preference of the various languages in the session or media,
from most preferred to least preferred. from most preferred to least preferred.
As a session-level attribute, lang specifies a language capability As a session-level attribute, lang specifies a language capability
for the session being described. As a media-level attribute, it for the session being described. As a media-level attribute, it
specifies a language capability for that media, overriding any specifies a language capability for that media, overriding any
session-level language(s) specified. session-level language(s) specified.
The "lang" attribute value must be a single [RFC5646] language tag in The "lang" attribute value must be a single [RFC5646] language tag.
the US-ASCII subset of UTF-8. A "lang" attribute SHOULD be specified A "lang" attribute SHOULD be specified when a session is of
when a session is of sufficient scope to cross geographic boundaries sufficient scope to cross geographic boundaries where the language of
where the language of participants cannot be assumed, or where the participants cannot be assumed, or where the session has capabilities
session has capabilities in languages different from the locally in languages different from the locally assumed norm.
assumed norm.
The "lang" attribute is supposed to be used for setting the initial The "lang" attribute is supposed to be used for setting the initial
language(s) used in the session. Events during the session may language(s) used in the session. Events during the session may
influence which language(s) are used, and the participants are not influence which language(s) are used, and the participants are not
strictly bound to only use the declared languages. strictly bound to only use the declared languages.
Most real-time use cases start with just one language used, while Most real-time use cases start with just one language used, while
other cases involve a range of languages, e.g. an interpreted or other cases involve a range of languages, e.g. an interpreted or
subtitled session. When more than one 'lang' attribute is specified, subtitled session. When more than one 'lang' attribute is specified,
the "lang" attribute itself does not provide any information about the "lang" attribute itself does not provide any information about
skipping to change at page 38, line 40 skipping to change at page 39, line 10
because, among other attacks, the media sessions received may not be because, among other attacks, the media sessions received may not be
the intended ones, the destination where media is sent to may not be the intended ones, the destination where media is sent to may not be
the expected one, any of the parameters of the session may be the expected one, any of the parameters of the session may be
incorrect, or the media security may be compromised. It is up to the incorrect, or the media security may be compromised. It is up to the
endpoint to make a sensible decision taking into account the security endpoint to make a sensible decision taking into account the security
risks of the application and the user preferences - the endpoint may risks of the application and the user preferences - the endpoint may
decide to ask the user whether or not to accept the session. decide to ask the user whether or not to accept the session.
On receiving a session description over an unauthenticated transport On receiving a session description over an unauthenticated transport
mechanism or from an untrusted party, software parsing the session mechanism or from an untrusted party, software parsing the session
should take a few precautions. Similar concerns apply if integrity description should take a few precautions. Similar concerns apply if
protection is not in place. Session descriptions contain information integrity protection is not in place. Session descriptions contain
required to start software on the receiver's system. Software that information required to start software on the receiver's system.
parses a session description MUST NOT be able to start other software Software that parses a session description MUST NOT be able to start
except that which is specifically configured as appropriate software other software except that which is specifically configured as
to participate in multimedia sessions. It is normally considered appropriate software to participate in multimedia sessions. It is
inappropriate for software parsing a session description to start, on normally considered inappropriate for software parsing a session
a user's system, software that is appropriate to participate in description to start, on a user's system, software that is
multimedia sessions, without the user first being informed that such appropriate to participate in multimedia sessions, without the user
software will be started and giving the user's consent. Thus, a first being informed that such software will be started and giving
session description arriving by session announcement, email, session the user's consent. Thus, a session description arriving by session
invitation, or WWW page MUST NOT deliver the user into an interactive announcement, email, session invitation, or WWW page MUST NOT deliver
multimedia session unless the user has explicitly pre-authorized such the user into an interactive multimedia session unless the user has
action. As it is not always simple to tell whether or not a session explicitly pre-authorized such action. As it is not always simple to
is interactive, applications that are unsure should assume sessions tell whether or not a session is interactive, applications that are
are interactive. unsure should assume sessions are interactive. Software processing
URLs contained in session descriptions should also heed the security
considerations identified in [RFC3986].
In this specification, there are no attributes that would allow the In this specification, there are no attributes that would allow the
recipient of a session description to be informed to start multimedia recipient of a session description to be informed to start multimedia
tools in a mode where they default to transmitting. Under some tools in a mode where they default to transmitting. Under some
circumstances it might be appropriate to define such attributes. If circumstances it might be appropriate to define such attributes. If
this is done, an application parsing a session description containing this is done, an application parsing a session description containing
such attributes SHOULD either ignore them or inform the user that such attributes SHOULD either ignore them or inform the user that
joining this session will result in the automatic transmission of joining this session will result in the automatic transmission of
multimedia data. The default behavior for an unknown attribute is to multimedia data. The default behavior for an unknown attribute is to
ignore it. ignore it.
skipping to change at page 39, line 37 skipping to change at page 40, line 9
are NOT RECOMMENDED unless the session description is conveyed in are NOT RECOMMENDED unless the session description is conveyed in
such a manner that allows the intermediary system to conduct proper such a manner that allows the intermediary system to conduct proper
checks to establish the authenticity of the session description, and checks to establish the authenticity of the session description, and
the authority of its source to establish such communication sessions. the authority of its source to establish such communication sessions.
SDP by itself does not include sufficient information to enable these SDP by itself does not include sufficient information to enable these
checks: they depend on the encapsulating protocol (e.g., SIP or checks: they depend on the encapsulating protocol (e.g., SIP or
RTSP). Use of some procedures and SDP extensions (e.g., ICE RTSP). Use of some procedures and SDP extensions (e.g., ICE
[RFC8445] and ICE-SIP-SDP [I-D.ietf-mmusic-ice-sip-sdp]) may avoid [RFC8445] and ICE-SIP-SDP [I-D.ietf-mmusic-ice-sip-sdp]) may avoid
the need for intermediaries to modify SDP. the need for intermediaries to modify SDP.
Use of the "k=" line poses a significant security risk, since it SDP MUST NOT be used to convey keying material (e.g., using
conveys session encryption keys in the clear. SDP MUST NOT be used "a=crypto" [RFC4568]) unless it can be guaranteed that the channel
to convey keying material, unless it can be guaranteed that the over which the SDP is delivered is both private and authenticated.
channel over which the SDP is delivered is both private and
authenticated. Moreover, the "k=" line provides no way to indicate
or negotiate cryptographic key algorithms. As it provides for only a
single symmetric key, rather than separate keys for confidentiality
and integrity, its utility is severely limited. The "k=" line MUST
NOT be used, as discussed in Section 5.12.
8. IANA Considerations 8. IANA Considerations
8.1. The "application/sdp" Media Type 8.1. The "application/sdp" Media Type
One media type registration from [RFC4566] is to be updated, as One media type registration from [RFC4566] is to be updated, as
defined below. defined below.
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of media type "application/sdp" Subject: Registration of media type "application/sdp"
Type name: application Type name: application
skipping to change at page 40, line 20 skipping to change at page 40, line 31
Subject: Registration of media type "application/sdp" Subject: Registration of media type "application/sdp"
Type name: application Type name: application
Subtype name: sdp Subtype name: sdp
Required parameters: None. Required parameters: None.
Optional parameters: None. Optional parameters: None.
Encoding considerations: Encoding considerations: 8-bit text.
SDP files are primarily UTF-8 format text. The "a=charset:" SDP files are primarily UTF-8 format text. The "a=charset:"
attribute may be used to signal the presence of other character attribute may be used to signal the presence of other character
sets in certain parts of an SDP file (see Section 6 of RFC sets in certain parts of an SDP file (see Section 6 of RFC
XXXX). Arbitrary binary content cannot be directly XXXX). Arbitrary binary content cannot be directly
represented in SDP. represented in SDP.
Security considerations: Security considerations:
See Section 7 of RFC XXXX. See Section 7 of RFC XXXX.
Interoperability considerations: Interoperability considerations:
skipping to change at page 42, line 30 skipping to change at page 42, line 42
Such an RFC MAY be Experimental or Informational, although it is Such an RFC MAY be Experimental or Informational, although it is
preferable that it be Standards Track. The RFC defining a new preferable that it be Standards Track. The RFC defining a new
protocol MUST define the rules by which the "fmt" (see below) protocol MUST define the rules by which the "fmt" (see below)
namespace is managed. namespace is managed.
"proto" names starting with "RTP/" MUST only be used for defining "proto" names starting with "RTP/" MUST only be used for defining
transport protocols that are profiles of the RTP protocol. For transport protocols that are profiles of the RTP protocol. For
example, a profile whose short name is "XYZ" would be denoted by a example, a profile whose short name is "XYZ" would be denoted by a
"proto" sub-field of "RTP/XYZ". "proto" sub-field of "RTP/XYZ".
8.2.3. Media Formats ("fmt")
Each transport protocol, defined by the "proto" sub-field, has an Each transport protocol, defined by the "proto" sub-field, has an
associated "fmt" namespace that describes the media formats that may associated "fmt" namespace that describes the media formats that may
be conveyed by that protocol. Formats cover all the possible be conveyed by that protocol. Formats cover all the possible
encodings that could be transported in a multimedia session. encodings that could be transported in a multimedia session.
RTP payload formats under the "RTP/AVP" and other "RTP/*" profiles RTP payload formats under the "RTP/AVP" and other "RTP/*" profiles
MUST use the payload type number as their "fmt" value. If the MUST use the payload type number as their "fmt" value. If the
payload type number is dynamically assigned by this session payload type number is dynamically assigned by this session
description, an additional "rtpmap" attribute MUST be included to description, an additional "rtpmap" attribute MUST be included to
specify the format name and parameters as defined by the media type specify the format name and parameters as defined by the media type
skipping to change at page 43, line 13 skipping to change at page 43, line 22
that a new one be registered through the IETF process [RFC6838] by that a new one be registered through the IETF process [RFC6838] by
production of, or reference to, a standards-track RFC that defines production of, or reference to, a standards-track RFC that defines
the format. the 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.3. Attribute Names ("att-field")
8.2.4.1. New Attributes 8.2.3.1. New Attributes
Attribute-field names ("att-field") MUST be registered with IANA and Attribute-field names ("att-field") MUST be registered with IANA and
documented, to avoid any issues due to conflicting attribute documented, to avoid any issues due to conflicting attribute
definitions under the same name. Unknown attributes in SDP are definitions under the same name. Unknown attributes in SDP are
simply ignored, but conflicting ones that fragment the protocol are a simply 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 [RFC8126], provided that the "Specification Required" policy of [RFC8126], provided that the
specification includes the following information: specification includes the following information:
skipping to change at page 45, line 5 skipping to change at page 45, line 11
media" or "media" (depending on desired semantics). The default rule media" or "media" (depending on desired semantics). The default rule
is that for all new SDP attributes that can occur both in session and is that for all new SDP attributes that can occur both in session and
media level, the media level overrides the session level. When this media level, the media level overrides the session level. When this
is not the case for a new SDP attribute, it MUST be explicitly is not the case for a new SDP attribute, it MUST be explicitly
stated. stated.
IANA has registered the initial set of attribute names ("att-field" IANA has registered the initial set of attribute names ("att-field"
values) with definitions as in Section 6 of this memo (these values) with definitions as in Section 6 of this memo (these
definitions replace those in [RFC4566]). definitions replace those in [RFC4566]).
8.2.4.2. Updates to Existing Attributes 8.2.3.2. Updates to Existing Attributes
Updated attribute registrations are accepted according to the Updated attribute registrations are accepted according to the
"Specification Required" policy of [RFC8126]. "Specification Required" policy of [RFC8126].
The Designated Expert reviewing the update is requested to evaluate The Designated Expert reviewing the update is requested to evaluate
whether the update is compatible with the prior intent and use of the whether the update is compatible with the prior intent and use of the
attribute, and whether the new document is of sufficient maturity and attribute, and whether the new document is of sufficient maturity and
authority in relation to the prior document. authority in relation to the prior document.
The specification updating the attribute (for example, by adding a The specification updating the attribute (for example, by adding a
new value) MUST update registration information items from new value) MUST update registration information items from
Section 8.2.4.1 according to the following bullets: Section 8.2.3.1 according to the following bullets:
o Contact Name: A name MUST be provided. o Contact Name: A name MUST be provided.
o Contact Email Address: An email address MUST be provided. o Contact Email Address: An email address MUST be provided.
o Attribute Name: MUST be provided and MUST NOT be changed. o Attribute Name: MUST be provided and MUST NOT be changed.
Otherwise it is a new attribute. Otherwise it is a new attribute.
o Attribute Syntax: The existing rule syntax with the syntax o Attribute Syntax: The existing rule syntax with the syntax
extensions MUST be provided if there is a change to the syntax. A extensions MUST be provided if there is a change to the syntax. A
skipping to change at page 46, line 8 skipping to change at page 46, line 15
o Mux Category: No change unless from "TBD" to another value (see o Mux Category: No change unless from "TBD" to another value (see
[I-D.ietf-mmusic-sdp-mux-attributes]. It MAY also change if [I-D.ietf-mmusic-sdp-mux-attributes]. It MAY also change if
'media' level is being added to the definition of an attribute 'media' level is being added to the definition of an attribute
that previously did not include it. that previously did not include it.
o Reference: A new reference MUST be provided. o Reference: A new reference MUST be provided.
Items SHOULD be omitted if there is no impact to them as a result of Items SHOULD be omitted if there is no impact to them as a result of
the attribute update. the attribute update.
8.2.5. Bandwidth Specifiers ("bwtype") 8.2.4. Bandwidth Specifiers ("bwtype")
A proliferation of bandwidth specifiers is strongly discouraged. A proliferation of bandwidth specifiers is strongly discouraged.
New bandwidth specifiers (<bwtype> sub-field values) MUST be New bandwidth specifiers (<bwtype> sub-field values) MUST be
registered with IANA. The submission MUST reference a standards- registered with IANA. The submission MUST reference a standards-
track RFC specifying the semantics of the bandwidth specifier track RFC specifying the semantics of the bandwidth specifier
precisely, and indicating when it should be used, and why the precisely, and indicating when it should be used, and why the
existing registered bandwidth specifiers do not suffice. existing registered bandwidth specifiers do not suffice.
IANA has registered the bandwidth specifiers "CT" and "AS" with IANA has registered the bandwidth specifiers "CT" and "AS" with
definitions as in Section 5.8 of this memo (these definitions update definitions as in Section 5.8 of this memo (these definitions update
those in [RFC4566]). those in [RFC4566]).
8.2.6. Network Types ("nettype") 8.2.5. Network Types ("nettype")
New network types (<nettype> sub-field values) MUST be registered New network types (<nettype> sub-field values) MUST be registered
with IANA if SDP needs to be used in the context of non-Internet with IANA if SDP needs to be used in the context of non-Internet
environments. The registration is subject to the "RFC Required" environments. The registration is subject to the "RFC Required"
policy of [RFC8126]. Although these are not normally the preserve of policy of [RFC8126]. Although these are not normally the preserve of
IANA, there may be circumstances when an Internet application needs IANA, there may be circumstances when an Internet application needs
to interoperate with a non-Internet application, such as when to interoperate with a non-Internet application, such as when
gatewaying an Internet telephone call into the Public Switched gatewaying an Internet telephone call into the Public Switched
Telephone Network (PSTN). The number of network types should be Telephone Network (PSTN). The number of network types should be
small and should be rarely extended. A new network type cannot be small and should be rarely extended. A new network type cannot be
registered without registering at least one address type to be used registered without registering at least one address type to be used
with that network type. A new network type registration MUST with that network type. A new network type registration MUST
reference an RFC that gives details of the network type and address reference an RFC that gives details of the network type and address
type(s) and specifies how and when they would be used. type(s) and specifies how and when they would be used.
IANA has registered the network type "IN" to represent the Internet, IANA has registered the network type "IN" to represent the Internet,
with definition as in Sections 5.2 and 5.7 of this memo (these with definition as in Sections 5.2 and 5.7 of this memo (these
definitions update those in [RFC4566]). definitions update those in [RFC4566]).
8.2.7. Address Types ("addrtype") 8.2.6. Address Types ("addrtype")
New address types ("addrtype") MUST be registered with IANA. The New address types ("addrtype") MUST be registered with IANA. The
registration is subject to the "RFC Required" policy of [RFC8126]. registration is subject to the "RFC Required" policy of [RFC8126].
An address type is only meaningful in the context of a network type, An address type is only meaningful in the context of a network type,
and any registration of an address type MUST specify a registered and any registration of an address type MUST specify a registered
network type or be submitted along with a network type registration. network type or be submitted along with a network type registration.
A new address type registration MUST reference an RFC giving details A new address type registration MUST reference an RFC giving details
of the syntax of the address type. Address types are not expected to of the syntax of the address type. Address types are not expected to
be registered frequently. be registered frequently.
IANA has registered the address types "IP4" and "IP6" with Section 5.7 of this document gives new definitions of address types
definitions as in Sections 5.2 and 5.7 of this memo (these "IP4" and "IP6". The registries are to be correspondingly updated by
definitions update those in [RFC4566]). IANA.
8.2.8. Registration Procedure
In the RFC specifications that register new values for SDP "media", 8.2.7. Registration Procedure
"proto", "fmt", "bwtype", "nettype", and "addrtype" parameters, the
authors MUST include the following information for IANA to place in
the appropriate registry:
o contact name A specification document that defines new values for SDP "media",
"proto", "bwtype", "nettype", and "addrtype" parameters MUST include
the following information:
o contact email address o contact name;
o name being registered (as it will appear in SDP) o contact email address;
o type of name ("media", "proto", "fmt", "bwtype", "nettype", or o name being defined (as it will appear in SDP);
"addrtype")
o a one-paragraph explanation of the purpose of the registered name o type of name ("media", "proto", "bwtype", "nettype", or
"addrtype");
o a reference to the specification for the registered name (this o a description of the purpose of the defined name;
will typically be an RFC number)
In the case of a new addrtype registration, the author has to check o a stable reference to the document containing this information and
whether the new address type is usable with the existing network the definition of the value. (This will typically be an RFC
types. If yes, the "nettype" registry MUST be updated accordingly. number.)
In the case of a new nettype registration, the author MUST specify
the usable address type(s).
IANA may refer any registration to the IESG for review, and may IANA will populate its registries with some or all of these values.
request revisions to be made before a registration will be made.
8.3. Encryption Key Access Methods 8.3. Encryption Key Access Methods
The IANA previously maintained a table of SDP encryption key access The IANA previously maintained a table of SDP encryption key access
method ("enckey") names. This table is obsolete, since the "k=" line method ("enckey") names. This table is obsolete, since the "k=" line
is not extensible. New registrations MUST NOT be accepted. is not extensible. New registrations MUST NOT be accepted.
8.4. Reorganization of the nettype Registry 8.4. Reorganization of the nettype and addrtype registries
This document adds a new column in the "nettype" registry with the This document adds a new column in the "nettype" registry with the
title "Usable addrtype Values" and updates the "nettype" registry as title "Usable addrtype Values", replacing the separate "addrtype"
follows: registry. The following is the revised "nettype" registry:
-------------------------------------------------------------------- --------------------------------------------------------------------
|Type | SDP Name | Usable addrtype Values | Reference | |Type | SDP Name | Usable addrtype Values | Reference |
-------------------------------------------------------------------- --------------------------------------------------------------------
|nettype | IN | IP4, IP6 | [RFCXXXX] | |nettype | IN | IP4, IP6 | [RFCXXXX] |
|nettype | TN | RFC2543 | [RFC2848] | |nettype | TN | RFC2543 | [RFC2848] |
|nettype | ATM | NSAP, GWID, E164 | [RFC3108] | |nettype | ATM | NSAP, GWID, E164 | [RFC3108] |
|nettype | PSTN | E164 | [RFC7195] | |nettype | PSTN | E164 | [RFC7195] |
-------------------------------------------------------------------- --------------------------------------------------------------------
skipping to change at page 48, line 26 skipping to change at page 48, line 32
type has a different context for ATM and PSTN networks. type has a different context for ATM and PSTN networks.
8.5. Reorganization of the att-field Registries 8.5. Reorganization of the att-field Registries
This document combines all of the (currently) five "att-field" This document combines all of the (currently) five "att-field"
registries into one registry called "att-field" registry, and updates registries into one registry called "att-field" registry, and updates
the columns to reflect the name, usage level(s), charset dependency the columns to reflect the name, usage level(s), charset dependency
and reference. As such IANA is requested to create a new combined and reference. As such IANA is requested to create a new combined
registry using the following columns: registry using the following columns:
Name | Usage Level | Dependent on Charset? | Mux Category | Reference | | Dependent | Mux | |
Name | Usage Level | on Charset? | Category | Reference |
The "Name" column reflects the attribute name (as it will appear in The "Name" column reflects the attribute name (as it will appear in
the SDP). The "Usage Level" column MUST indicate one or more of the the SDP). The "Usage Level" column MUST indicate one or more of the
following: session, media, source, dcsa and dcsa(subprotocol). The following: session, media, source, dcsa and dcsa(subprotocol). The
"Dependent on Charset?" column MUST indicate "Yes" or "No" depending "Dependent on Charset?" column MUST indicate "Yes" or "No" depending
on whether the attribute value is subject to the charset attribute. on whether the attribute value is subject to the charset attribute.
The "Mux Category" column MUST indicate one of the following The "Mux Category" column MUST indicate one of the following
categories: NORMAL, NOT RECOMMENDED, IDENTICAL, SUM, TRANSPORT, categories: NORMAL, NOT RECOMMENDED, IDENTICAL, SUM, TRANSPORT,
INHERIT, IDENTICAL-PER-PT, SPECIAL or TBD as defined by INHERIT, IDENTICAL-PER-PT, SPECIAL or TBD as defined by
[I-D.ietf-mmusic-sdp-mux-attributes]. Finally, the "Reference" [I-D.ietf-mmusic-sdp-mux-attributes]. Finally, the "Reference"
column indicates the specification(s) where the attribute is defined. column indicates the specification(s) where the attribute is defined.
For example, the attribute "setup" which is defined for both session For example, the attribute "setup" which is defined for both session
and media level, will be listed in the new registry as follows: and media level, will be listed in the new registry as follows:
Name | Usage Level | Dependent on Charset?|Mux Category| Reference | | | Dependent | Mux | |
setup | session,media, | No |IDENTICAL | [RFC4145] | Name | Usage Level | on Charset? | Category | Reference |
| dcsa,dcsa(msrp)| | | [RFC6135] | ------|----------------|-------------|----------|----------------|
| | | | [I-D.mmusic setup | session,media, | No |IDENTICAL | [RFC4145] |
| | | |-msrp-usage- | dcsa,dcsa(msrp)| | | [RFC6135] |
| | | |data-channel | | | | [I-D.mmusic- |
| | | |] | | | | | msrp-usage- |
| | | | data-channel] |
9. SDP Grammar 9. SDP Grammar
This section provides an Augmented BNF grammar for SDP. ABNF is This section provides an Augmented BNF grammar for SDP. ABNF is
defined in [RFC5234] and [RFC7405]. defined in [RFC5234] and [RFC7405].
; SDP Syntax ; SDP Syntax
session-description = version-field session-description = version-field
origin-field origin-field
session-name-field session-name-field
skipping to change at page 51, line 27 skipping to change at page 51, line 36
bwtype = token bwtype = token
bandwidth = 1*DIGIT bandwidth = 1*DIGIT
; sub-rules of 't=' ; sub-rules of 't='
start-time = time / "0" start-time = time / "0"
stop-time = time / "0" stop-time = time / "0"
time = POS-DIGIT 9*DIGIT time = POS-DIGIT 9*DIGIT
; Decimal representation of NTP time in ; Decimal representation of time in
; seconds since 1900. The representation ; seconds since January 1, 1900 UTC.
; of NTP time is an unbounded length field ; The representation is an unbounded
; containing at least 10 digits. Unlike the ; length field containing at least
; 64-bit representation used elsewhere, time ; 10 digits. Unlike some representations
; in SDP does not wrap in the year 2036. ; used elsewhere, time in SDP does not
; wrap in the year 2036.
; sub-rules of 'r=' and 'z=' ; sub-rules of 'r=' and 'z='
repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit]
typed-time = 1*DIGIT [fixed-len-time-unit] typed-time = 1*DIGIT [fixed-len-time-unit]
fixed-len-time-unit = %s"d" / %s"h" / %s"m" / %s"s" fixed-len-time-unit = %s"d" / %s"h" / %s"m" / %s"s"
; NOTE: These units are case-sensitive. ; NOTE: These units are case-sensitive.
; sub-rules of 'k=' ; sub-rules of 'k='
skipping to change at page 54, line 17 skipping to change at page 54, line 26
non-zero-real = zero-based-integer "." *DIGIT POS-DIGIT non-zero-real = zero-based-integer "." *DIGIT POS-DIGIT
; generic sub-rules: primitives ; generic sub-rules: primitives
alpha-numeric = ALPHA / DIGIT alpha-numeric = ALPHA / DIGIT
POS-DIGIT = %x31-39 ; 1 - 9 POS-DIGIT = %x31-39 ; 1 - 9
decimal-uchar = DIGIT decimal-uchar = DIGIT
/ POS-DIGIT DIGIT / POS-DIGIT DIGIT
/ ("1" 2*(DIGIT)) / ("1" 2(DIGIT))
/ ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT)
/ ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5"))
; external references: ; external references:
ALPHA = <ALPHA definition from RFC5234> ALPHA = <ALPHA definition from RFC5234>
DIGIT = <DIGIT definition from RFC5234> DIGIT = <DIGIT definition from RFC5234>
CRLF = <CRLF definition from RFC5234> CRLF = <CRLF definition from RFC5234>
HEXDIG = <HEXDIG definition from RFC5234> HEXDIG = <HEXDIG definition from RFC5234>
SP = <SP definition from RFC5234> SP = <SP definition from RFC5234>
VCHAR = <VCHAR definition from RFC5234> VCHAR = <VCHAR definition from RFC5234>
skipping to change at page 55, line 38 skipping to change at page 55, line 44
remove ambiguities. Clarified that "z=" only modifies the remove ambiguities. Clarified that "z=" only modifies the
immediately preceding "r=" lines. Made "z=" without a immediately preceding "r=" lines. Made "z=" without a
preceding "r=" a syntax error. (This is incompatible with preceding "r=" a syntax error. (This is incompatible with
certain aberrant usage.) certain aberrant usage.)
* Updated the "IP6-address" and "IP6-multicast" rules, consistent * Updated the "IP6-address" and "IP6-multicast" rules, consistent
with the syntax in RFC3986. (This mirrors a bug fix made to with the syntax in RFC3986. (This mirrors a bug fix made to
RFC3261 by RFC5964.) Removed rules that were unused as a RFC3261 by RFC5964.) Removed rules that were unused as a
result of this change. result of this change.
o Revised normative statements that were redundant with ABNF syntax,
making the text non-normative.
o Revised IPv4 unicast and multicast addresses in the example SDP o Revised IPv4 unicast and multicast addresses in the example SDP
descriptions per RFCs 5735 and 5771. descriptions per RFCs 5735 and 5771.
o Changed some examples to use IPv6 addresses, and added additional
examples using IPv6.
o Incorporated case-insensitivity rules from RFC 4855. o Incorporated case-insensitivity rules from RFC 4855.
o Revised sections that incorrectly referenced NTP.
o Clarified the explanation of the impact and use of a=charset.
o Revised the description of a=type to remove implication that it
sometimes changes the default media direction to something other
than sendrecv.
11. Acknowledgements 11. Acknowledgements
Many people in the IETF Multiparty Multimedia Session Control Many people in the IETF Multiparty Multimedia Session Control
(MMUSIC) working group have made comments and suggestions (MMUSIC) working group have made comments and suggestions
contributing to this document. contributing to this document.
In particular, we would like to thank the following people who In particular, we would like to thank the following people who
contributed to the creation of this document or one of its contributed to the creation of this document or one of its
predecessor documents: Adam Roach, Allison Mankin, Bernie Hoeneisen, predecessor documents: Adam Roach, Allison Mankin, Bernie Hoeneisen,
Bill Fenner, Carsten Bormann, Eve Schooler, Flemming Andreasen, Bill Fenner, Carsten Bormann, Eve Schooler, Flemming Andreasen,
skipping to change at page 56, line 20 skipping to change at page 56, line 41
12.1. Normative References 12.1. Normative References
[E164] International Telecommunication Union, "E.164 : The [E164] International Telecommunication Union, "E.164 : The
international public telecommunication numbering plan", international public telecommunication numbering plan",
ITU Recommendation E.164, November 2010. ITU Recommendation E.164, November 2010.
[I-D.ietf-mmusic-data-channel-sdpneg] [I-D.ietf-mmusic-data-channel-sdpneg]
Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R.
Even, "SDP-based Data Channel Negotiation", draft-ietf- Even, "SDP-based Data Channel Negotiation", draft-ietf-
mmusic-data-channel-sdpneg-27 (work in progress), April mmusic-data-channel-sdpneg-28 (work in progress), May
2019. 2019.
[I-D.ietf-mmusic-sdp-mux-attributes] [I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17
(work in progress), February 2018. (work in progress), February 2018.
[ISO.8859-1.1998]
International Organization for Standardization,
"Information technology - 8-bit single byte coded graphic
- character sets - Part 1: Latin alphabet No. 1, JTC1/
SC2", ISO/IEC Standard 8859-1, 1998.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
skipping to change at page 57, line 47 skipping to change at page 58, line 28
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
September 2009, <https://www.rfc-editor.org/info/rfc5646>. September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010, RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>. <https://www.rfc-editor.org/info/rfc5890>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/info/rfc5952>.
[RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model
for the Message Session Relay Protocol (MSRP)", RFC 6135, for the Message Session Relay Protocol (MSRP)", RFC 6135,
DOI 10.17487/RFC6135, February 2011, DOI 10.17487/RFC6135, February 2011,
<https://www.rfc-editor.org/info/rfc6135>. <https://www.rfc-editor.org/info/rfc6135>.
[RFC7195] Garcia-Martin, M. and S. Veikkolainen, "Session [RFC7195] Garcia-Martin, M. and S. Veikkolainen, "Session
Description Protocol (SDP) Extension for Setting Audio and Description Protocol (SDP) Extension for Setting Audio and
Video Media Streams over Circuit-Switched Bearers in the Video Media Streams over Circuit-Switched Bearers in the
Public Switched Telephone Network (PSTN)", RFC 7195, Public Switched Telephone Network (PSTN)", RFC 7195,
DOI 10.17487/RFC7195, May 2014, DOI 10.17487/RFC7195, May 2014,
skipping to change at page 58, line 27 skipping to change at page 59, line 11
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-mmusic-ice-sip-sdp] [I-D.ietf-mmusic-ice-sip-sdp]
Petit-Huguenin, M., Nandakumar, S., and A. Keranen, Petit-Huguenin, M., Nandakumar, S., and A. Keranen,
"Session Description Protocol (SDP) Offer/Answer "Session Description Protocol (SDP) Offer/Answer
procedures for Interactive Connectivity Establishment procedures for Interactive Connectivity Establishment
(ICE)", draft-ietf-mmusic-ice-sip-sdp-24 (work in (ICE)", draft-ietf-mmusic-ice-sip-sdp-36 (work in
progress), November 2018. progress), June 2019.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-54 (work in progress), December 2018. negotiation-54 (work in progress), December 2018.
[ITU.H332.1998] [ITU.H332.1998]
International Telecommunication Union, "H.323 extended for International Telecommunication Union, "H.323 extended for
loosely coupled conferences", ITU Recommendation H.332, loosely coupled conferences", ITU Recommendation H.332,
September 1998. September 1998.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>.
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, DOI 10.17487/RFC2327, April 1998, Protocol", RFC 2327, DOI 10.17487/RFC2327, April 1998,
<https://www.rfc-editor.org/info/rfc2327>. <https://www.rfc-editor.org/info/rfc2327>.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974,
October 2000, <https://www.rfc-editor.org/info/rfc2974>. October 2000, <https://www.rfc-editor.org/info/rfc2974>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
skipping to change at page 60, line 5 skipping to change at page 60, line 36
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, Initiation Protocol (SIP)", RFC 3840,
DOI 10.17487/RFC3840, August 2004, DOI 10.17487/RFC3840, August 2004,
<https://www.rfc-editor.org/info/rfc3840>. <https://www.rfc-editor.org/info/rfc3840>.
[RFC3890] Westerlund, M., "A Transport Independent Bandwidth [RFC3890] Westerlund, M., "A Transport Independent Bandwidth
Modifier for the Session Description Protocol (SDP)", Modifier for the Session Description Protocol (SDP)",
RFC 3890, DOI 10.17487/RFC3890, September 2004, RFC 3890, DOI 10.17487/RFC3890, September 2004,
<https://www.rfc-editor.org/info/rfc3890>. <https://www.rfc-editor.org/info/rfc3890>.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006,
<https://www.rfc-editor.org/info/rfc4568>.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload [RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007,
<https://www.rfc-editor.org/info/rfc4855>. <https://www.rfc-editor.org/info/rfc4855>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008, DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>. <https://www.rfc-editor.org/info/rfc5322>.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, Protocol (SDP) Grouping Framework", RFC 5888,
DOI 10.17487/RFC5888, June 2010, DOI 10.17487/RFC5888, June 2010,
<https://www.rfc-editor.org/info/rfc5888>. <https://www.rfc-editor.org/info/rfc5888>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC6466] Salgueiro, G., "IANA Registration of the 'image' Media [RFC6466] Salgueiro, G., "IANA Registration of the 'image' Media
Type for the Session Description Protocol (SDP)", Type for the Session Description Protocol (SDP)",
RFC 6466, DOI 10.17487/RFC6466, December 2011, RFC 6466, DOI 10.17487/RFC6466, December 2011,
<https://www.rfc-editor.org/info/rfc6466>. <https://www.rfc-editor.org/info/rfc6466>.
[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
"TCP Candidates with Interactive Connectivity
Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544,
March 2012, <https://www.rfc-editor.org/info/rfc6544>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>. <https://www.rfc-editor.org/info/rfc6838>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
 End of changes. 102 change blocks. 
300 lines changed or deleted 326 lines changed or added

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