draft-ietf-mmusic-rfc4566bis-32.txt   draft-ietf-mmusic-rfc4566bis-33.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: June 21, 2019 C. Perkins Expires: August 26, 2019 C. Perkins
University of Glasgow University of Glasgow
M. Handley M. Handley
UCL UCL
December 18, 2018 February 22, 2019
SDP: Session Description Protocol SDP: Session Description Protocol
draft-ietf-mmusic-rfc4566bis-32 draft-ietf-mmusic-rfc4566bis-33
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 June 21, 2019. This Internet-Draft will expire on August 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 31 skipping to change at page 3, line 31
6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 36 6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 36
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 . . . . . . . . . . . . . . . . . . . . . 39
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. Media Formats ("fmt") . . . . . . . . . . . . . . . . 42
8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 43 8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 43
8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 45 8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 46
8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 46 8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 46
8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 46 8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 46
8.2.8. Registration Procedure . . . . . . . . . . . . . . . 46 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 Registry . . . . . . . . . 47
8.5. Reorganization of the att-field Registries . . . . . . . 48 8.5. Reorganization of the att-field Registries . . . . . . . 48
9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 48 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 49
10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 54 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 54
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 55
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
12.1. Normative References . . . . . . . . . . . . . . . . . . 54 12.1. Normative References . . . . . . . . . . . . . . . . . . 56
12.2. Informative References . . . . . . . . . . . . . . . . . 57 12.2. Informative References . . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 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
skipping to change at page 4, line 22 skipping to change at page 4, line 22
extensions [RFC5322], and the Hypertext Transport Protocol (HTTP) extensions [RFC5322], and the Hypertext Transport Protocol (HTTP)
[RFC7230]. [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
limited to essential corrections, and are outlined in Section 10 of outlined in Section 10 of this memo.
this memo.
2. Glossary of Terms 2. Glossary of Terms
The following terms are used in this document and have specific The following terms are used in this document and have specific
meaning within the context of this document. meaning within the context of this document.
Session Description: A well-defined format for conveying sufficient Session Description: A well-defined format for conveying sufficient
information to discover and participate in a multimedia session. information to discover and participate in a multimedia session.
Media Description: A media description starts with an "m=" line and Media Description: A Media Description contains the information
is terminated by either the next "m=" line or by the end of the needed for one party to establish an application layer network
session description. protocol connection to another party. It starts with an "m=" line
and is terminated by either the next "m=" line or by the end of
the session description.
Session-level Section: This refers to the parts that are not media Session-level Section: This refers to the parts that are not media
descriptions, whereas the session description refers to the whole descriptions, whereas the session description refers to the whole
body that includes the session-level section and the media body that includes the session-level section and the media
description(s). description(s).
The terms "multimedia conference" and "multimedia session" are used The terms "multimedia conference" and "multimedia session" are used
in this document as defined in [RFC7656]. The terms "session" and in this document as defined in [RFC7656]. The terms "session" and
"multimedia session" are used interchangeably in this document. "multimedia session" are used interchangeably in this document.
skipping to change at page 5, line 37 skipping to change at page 5, line 37
those parameters. those parameters.
3.3. Email and the World Wide Web 3.3. Email and the World Wide Web
Alternative means of conveying session descriptions include Alternative means of conveying session descriptions include
electronic mail and the World Wide Web (WWW). For both email and WWW electronic mail and the World Wide Web (WWW). For both email and WWW
distribution, the media type "application/sdp" is used. This enables distribution, the media type "application/sdp" is used. This enables
the automatic launching of applications for participation in the the automatic launching of applications for participation in the
session from the WWW client or mail reader in a standard manner. session from the WWW client or mail reader in a standard manner.
Note that descriptions of multicast sessions made only via email or Note that descriptions of multicast sessions sent only via email or
the WWW do not have the property that the receiver of a session the WWW do not have the property that the receiver of a session
description can necessarily receive the session because the multicast description can necessarily receive the session because the multicast
sessions may be restricted in scope, and access to the WWW server or sessions may be restricted in scope, and access to the WWW server or
reception of email is possible outside this scope. reception of email is possible outside this scope.
3.4. Multicast Session Announcement 3.4. Multicast Session Announcement
In order to assist the advertisement of multicast multimedia In order to assist the advertisement of multicast multimedia
conferences and other multicast sessions, and to communicate the conferences and other multicast sessions, and to communicate the
relevant session setup information to prospective participants, a relevant session setup information to prospective participants, a
skipping to change at page 7, line 25 skipping to change at page 7, line 25
o The format of the media (H.261 video, MPEG video, etc.) o The format of the media (H.261 video, MPEG video, etc.)
In addition to media format and transport protocol, SDP conveys In addition to media format and transport protocol, SDP conveys
address and port details. For an IP multicast session, these address and port details. For an IP multicast session, these
comprise: comprise:
o The multicast group address for media o The multicast group address for media
o The transport port for media o The transport port for media
This address and port is the destination address and destination port This address and port are the destination address and destination
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 this address and port depend on the media and
transport protocol defined. By default, this SHOULD be the remote transport protocol defined. By default, this SHOULD be the remote
address and remote port to which media is sent. Some media types may address and remote port to which media is sent. Some media types may
skipping to change at page 9, line 23 skipping to change at page 9, line 23
where <type> MUST be exactly one case-significant character and where <type> MUST be exactly one case-significant character and
<value> is structured text whose format depends on <type>. In <value> is structured text whose format depends on <type>. In
general, <value> is either a number of sub-fields delimited by a general, <value> is either a number of sub-fields delimited by a
single space character or a free format string, and is case- single space character or a free format string, and is case-
significant unless a specific field defines otherwise. Whitespace significant unless a specific field defines otherwise. Whitespace
separators MUST NOT be used on either side of the "=" sign, however, separators MUST NOT be used on either side of the "=" sign, however,
the value can contain a leading whitespace as part of its syntax, the value can contain a leading whitespace as part of its syntax,
i.e., that whitespace is part of the value. i.e., that whitespace is part of the value.
An SDP description MUST conform to the syntax defined in Section 9.
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 order but all must appear in exactly the order given here. (The fixed
greatly enhances error detection and allows for a simple parser). In order greatly enhances error detection and allows for a simple
the following overview OPTIONAL items are marked with a "*". (For parser). In the following overview optional items are marked with a
details, see the formal grammar in Section 9.) "*".
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)
p=* (phone number) p=* (phone number)
c=* (connection information -- not required if included in c=* (connection information -- not required if included in
all media descriptions) all media descriptions)
skipping to change at page 11, line 28 skipping to change at page 11, line 28
e=j.doe@example.com (Jane Doe) e=j.doe@example.com (Jane Doe)
c=IN IP4 233.252.0.2 c=IN IP4 233.252.0.2
t=2873397496 2873404696 t=2873397496 2873404696
a=recvonly a=recvonly
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
m=audio 49180 RTP/AVP 0 m=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 IP4 233.252.0.1/127
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 (the presence of the
"a=charset" attribute may force some fields to be interpreted "a=charset" attribute may force some fields to be interpreted
differently). differently).
skipping to change at page 13, line 6 skipping to change at page 13, line 6
<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 compressed textual representation of an IP
version 6 address of the machine. For both IP4 and IP6, the fully version 6 address of the machine. For both IP4 and IP6, the fully
qualified domain name is the form that SHOULD be given unless this qualified domain name is the form that SHOULD be given unless this
is unavailable, in which case a globally unique address MAY be is unavailable, in which case a globally unique address MAY be
substituted. Unless an SDP extension for NAT traversal is used substituted.
(e.g., ICE [RFC8445], ICE TCP [RFC6544]), a local IP address MUST
NOT be used in any context where the SDP description might leave
the scope in which the address is meaningful (for example, a local
address MUST NOT be included in an application-level referral that
might leave the scope).
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
skipping to change at page 13, line 42 skipping to change at page 13, line 37
has no meaningful name, the "s= " line SHOULD be used (i.e., a single has no meaningful name, the "s= " line SHOULD be used (i.e., a single
space as the session name). space as the session name).
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 MUST 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
single session has more than one distinct media stream of the same single session has more than one distinct media stream of the same
media type. An example would be two different whiteboards, one for media type. An example would be two different whiteboards, one for
slides and one for feedback and questions. slides and one for feedback and questions.
The "i=" 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 URI (Uniform Resource Identifier) The "u=" line (uri-field) provides a URI (Uniform Resource
as used by WWW clients [RFC3986]. The URI should be a pointer to Identifier) as used by WWW clients [RFC3986]. The URI should be a
additional information about the session. This line is OPTIONAL. No pointer to additional information about the session. This line is
more than one "u=" line is allowed per session description. OPTIONAL. No more than one "u=" line is allowed per session
description.
5.6. Email Address and Phone Number ("e=" and "p=") 5.6. Email Address and Phone Number ("e=" and "p=")
e=<email-address> e=<email-address>
p=<phone-number> p=<phone-number>
The "e=" 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 15, line 15 skipping to change at page 15, line 13
e=Jane Doe <j.doe@example.com> e=Jane Doe <j.doe@example.com>
The free text string SHOULD be in the ISO-10646 character set with The free text string SHOULD be in the ISO-10646 character set with
UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if
the appropriate session-level "a=charset" attribute is set. the appropriate session-level "a=charset" attribute is set.
5.7. Connection Information ("c=") 5.7. Connection Information ("c=")
c=<nettype> <addrtype> <connection-address> c=<nettype> <addrtype> <connection-address>
The "c=" line (connection-field) contains connection data. The "c=" line (connection-field) contains information necessary to
establish a network connection.
A session description MUST contain either at least one "c=" line in A session description MUST contain either at least one "c=" line in
each media description or a single "c=" line at the session level. each media description or a single "c=" line at the session level.
It MAY contain a single session-level "c=" line and additional "c=" It MAY contain a single session-level "c=" line and additional media-
line(s) per media description, in which case the per-media values level "c=" line(s) per-media-description, in which case the media-
override the session-level settings for the respective media. level values override the session-level settings for the respective
media.
The first sub-field ("<nettype>") is the network type, which is a The first sub-field ("<nettype>") is the network type, which is a
text string giving the type of network. Initially, "IN" is defined text string giving the type of network. Initially, "IN" is defined
to have the meaning "Internet", but other values MAY be registered in to have the meaning "Internet", but other values MAY be registered in
the future (see Section 8). the future (see Section 8).
The second sub-field ("<addrtype>") is the address type. This allows The second sub-field ("<addrtype>") is the address type. This allows
SDP to be used for sessions that are not IP based. This memo only SDP to be used for sessions that are not IP based. This memo only
defines IP4 and IP6, but other values MAY be registered in the future defines IP4 and IP6, but other values MAY be registered in the future
(see Section 8). (see Section 8).
skipping to change at page 16, line 15 skipping to change at page 16, line 15
specified, its use to scope multicast traffic is deprecated; specified, its use to scope multicast traffic is deprecated;
applications SHOULD use an administratively scoped address applications SHOULD use an administratively scoped address
instead. instead.
The TTL for the session is appended to the address using a slash as a The TTL for the session is appended to the address using a slash as a
separator. An example is: separator. An example is:
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
IP6 multicast does not use TTL scoping, and hence the TTL value MUST IP6 multicast does not use TTL scoping, and hence the TTL value MUST
NOT be present for IP6 multicast. It is expected that IP6 scoped NOT be present for IP6 multicast. It is expected that IPv6 scoped
addresses will be used to limit the scope of multimedia conferences. addresses will be used to limit the scope of multimedia conferences.
Hierarchical or layered encoding schemes are data streams where the Hierarchical or layered encoding schemes are data streams where the
encoding from a single media source is split into a number of layers. encoding from a single media source is split into a number of layers.
The receiver can choose the desired quality (and hence bandwidth) by The receiver can choose the desired quality (and hence bandwidth) by
only subscribing to a subset of these layers. Such layered encodings only subscribing to a subset of these layers. Such layered encodings
are normally transmitted in multiple multicast groups to allow are normally transmitted in multiple multicast groups to allow
multicast pruning. This technique keeps unwanted traffic from sites multicast pruning. This technique keeps unwanted traffic from sites
only requiring certain levels of the hierarchy. For applications only requiring certain levels of the hierarchy. For applications
requiring multiple multicast groups, we allow the following notation requiring multiple multicast groups, we allow the following notation
skipping to change at page 16, line 44 skipping to change at page 16, line 44
c=IN IP4 233.252.0.1/127/3 c=IN IP4 233.252.0.1/127/3
would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3 would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3
are to be used 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 IP6 example would be: Similarly, an IPv6 example would be:
c=IN IP6 FF15::101/3 c=IN IP6 FF15::101/3
which is semantically equivalent to: which is semantically equivalent to:
c=IN IP6 FF15::101 c=IN IP6 FF15::101
c=IN IP6 FF15::102 c=IN IP6 FF15::102
c=IN IP6 FF15::103 c=IN IP6 FF15::103
(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. They different layers in a hierarchical or layered encoding scheme.
MUST NOT be specified for a session-level "c=" line. Multiple addresses or "c=" lines MUST NOT be specified at session
level.
The slash notation for multiple addresses described above MUST NOT be The slash notation for multiple addresses described above MUST NOT be
used for IP unicast addresses. used for IP unicast addresses.
5.8. Bandwidth Information ("b=") 5.8. Bandwidth Information ("b=")
b=<bwtype>:<bandwidth> b=<bwtype>:<bandwidth>
The OPTIONAL "b=" line (bandwidth-field) denotes the proposed The OPTIONAL "b=" line (bandwidth-field) denotes the proposed
bandwidth to be used by the session or media description. The bandwidth to be used by the session or media description. The
skipping to change at page 17, line 50 skipping to change at page 17, line 51
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.
A prefix "X-" is defined for <bwtype> names. This is intended for [RFC4566] defined an "X-" prefix for <bwtype> names. This was
experimental purposes only. For example: intended for experimental purposes only. For example:
b=X-YZ:128 b=X-YZ:128
Use of the "X-" prefix is NOT RECOMMENDED: instead new (non "X-" Use of the "X-" prefix is NOT RECOMMENDED. Instead new (non "X-"
prefix) <bwtype> names SHOULD be defined, and then MUST be registered prefix) <bwtype> names SHOULD be defined, and then MUST be registered
with IANA in the standard namespace. SDP parsers MUST ignore with IANA in the standard namespace. SDP parsers MUST ignore
bandwidth-fields with unknown <bwtype> names. The <bwtype> names bandwidth-fields with unknown <bwtype> names. The <bwtype> names
MUST be alphanumeric and, although no length limit is given, it is MUST be alphanumeric and, although no length limit is given, it is
recommended that they be short. recommended that they be short.
The <bandwidth> is interpreted as kilobits per second by default The <bandwidth> is interpreted as kilobits per second by default
(including the transport and network-layer but not the link-layer (including the transport and network-layer but not the link-layer
overhead). The definition of a new <bwtype> modifier MAY specify overhead). The definition of a new <bwtype> modifier MAY specify
that the bandwidth is to be interpreted in some alternative unit (the that the bandwidth is to be interpreted in some alternative unit (the
"CT" and "AS" modifiers defined in this memo use the default units). "CT" and "AS" modifiers defined in this memo use the default units).
5.9. Time Active ("t=") 5.9. Time Active ("t=")
t=<start-time> <stop-time> t=<start-time> <stop-time>
A "t=" line (time-field) initiates a time description that specifies A "t=" line (time-field) begins a time description that specifies the
the start and stop times for a session. Multiple time descriptions start and stop times for a session. Multiple time descriptions MAY
MAY be used if a session is active at multiple irregularly spaced be used if a session is active at multiple irregularly spaced times;
times; each additional time description specifies additional periods each additional time description specifies additional periods of time
of time for which the session will be active. If the session is for which the session will be active. If the session is active at
active at regular repeat times, a repeat description, initiated by an regular repeat times, a repeat description, begun by an "r=" line
"r=" line (see below) can be included following the time-field -- in (see below) can be included following the time-field -- in which case
which case the time-field specifies the start and stop times of the the time-field specifies the start and stop times of the entire
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 values are the
decimal representation of Network Time Protocol (NTP) time values in decimal representation of Network Time Protocol (NTP) time values in
seconds since 1900 [RFC5905]. To convert these values to UNIX time seconds since 1900 [RFC5905]. To convert these values to UNIX time
skipping to change at page 21, line 30 skipping to change at page 21, line 30
"k=" line in an SDP, and MUST discard it if it is received in an SDP. "k=" line in an SDP, and MUST discard it if it is received in an SDP.
5.13. Attributes ("a=") 5.13. Attributes ("a=")
a=<attribute> a=<attribute>
a=<attribute>:<value> a=<attribute>:<value>
Attributes are the primary means for extending SDP. Attributes may Attributes are the primary means for extending SDP. Attributes may
be defined to be used as "session-level" attributes, "media-level" be defined to be used as "session-level" attributes, "media-level"
attributes, or both. (Attribute scopes in addition to media- and attributes, or both. (Attribute scopes in addition to media- and
session- specific may also be defined in extensions to this document. session- level may also be defined in extensions to this document.
E.g., [RFC5576], [I-D.ietf-mmusic-data-channel-sdpneg].) E.g., [RFC5576], [I-D.ietf-mmusic-data-channel-sdpneg].)
A media description may contain any number of "a=" lines (attribute- A media description may contain any number of "a=" lines (attribute-
fields) that are media description specific. These are referred to fields) that are media description specific. These are referred to
as "media-level" attributes and add information about the media as "media-level" attributes and add information about the media
description. Attribute-fields can also be added before the first description. Attribute-fields can also be added before the first
media description; these "session-level" attributes convey additional media description; these "session-level" attributes convey additional
information that applies to the session as a whole rather than to information that applies to the session as a whole rather than to
individual media descriptions. individual media descriptions.
skipping to change at page 23, line 27 skipping to change at page 23, line 27
In such a case, the ports used depend on the transport protocol. In such a case, the ports used depend on the transport protocol.
For RTP, the default is that only the even-numbered ports are used For RTP, the default is that only the even-numbered ports are used
for data with the corresponding one-higher odd ports used for the for data with the corresponding one-higher odd ports used for the
RTCP belonging to the RTP session, and the <number of ports> RTCP belonging to the RTP session, and the <number of ports>
denoting the number of RTP sessions. For example: denoting the number of RTP sessions. For example:
m=video 49170/2 RTP/AVP 31 m=video 49170/2 RTP/AVP 31
would specify that ports 49170 and 49171 form one RTP/RTCP pair would specify that ports 49170 and 49171 form one RTP/RTCP pair
and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the
transport protocol and 31 is the format (see below). If non- transport protocol and 31 is the format (see below).
contiguous ports are required, they must be signaled using a
separate attribute. (There is currently no attribute defined that This document does not include a mechanism for declaring
can accomplish this. The "a=rtcp:" defined in [RFC3605] does not hierarchically encoded streams using non-contiguous ports. (There
handle hierarchical encoding.) is currently no attribute defined that can accomplish this. The
"a=rtcp:" defined in [RFC3605] does not handle hierarchical
encoding.) If a need arises to declare non-contiguous ports then
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 c=IN IP4 233.252.0.1/127/2
m=video 49170/2 RTP/AVP 31 m=video 49170/2 RTP/AVP 31
would imply that address 233.252.0.1 is used with ports 49170 and would imply that address 233.252.0.1 is used with ports 49170 and
49171, and address 233.252.0.2 is used with ports 49172 and 49173. 49171, and address 233.252.0.2 is used with ports 49172 and 49173.
This document provides no semantics for using multiple "m=" lines This document gives no meaning to assigning the same media address
using the same transport address. This implies that, unlike to multiple media-descriptions. Doing so does not implicitly
limited past practice, there is no implicit grouping defined by group those media-descriptions in any way. An explicit grouping
such means and an explicit grouping framework (for example, framework (for example, [RFC5888]) should instead be used to
[RFC5888]) should instead be used to express the intended express the intended semantics. For instance, see
semantics. Such semantics may alo be added as extensions. For [I-D.ietf-mmusic-sdp-bundle-negotiation].
instance, see [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
indicates that the transport protocol runs over IP4. The indicates that the transport protocol runs over IPv4. The
following transport protocols are defined, but may be extended following transport protocols are defined, but may be extended
through registration of new protocols with IANA (see Section 8): through registration of new protocols with IANA (see Section 8):
* udp: denotes that the data is transported directly in UDP with * udp: denotes that the data is transported directly in UDP with
no additional framing. no additional framing.
* RTP/AVP: denotes RTP [RFC3550] used under the RTP Profile for * RTP/AVP: denotes RTP [RFC3550] used under the RTP Profile for
Audio and Video Conferences with Minimal Control [RFC3551] Audio and Video Conferences with Minimal Control [RFC3551]
running over UDP. running over UDP.
skipping to change at page 25, line 48 skipping to change at page 25, line 48
cat-value = category cat-value = category
category = non-ws-string category = non-ws-string
Example: Example:
a=cat:foo.bar a=cat:foo.bar
This attribute gives the dot-separated hierarchical category of the This attribute gives the dot-separated hierarchical category of the
session. This is to enable a receiver to filter unwanted sessions by session. This is to enable a receiver to filter unwanted sessions by
category. There is no central registry of categories. This category. There is no central registry of categories. This
attribute is obsoleted. attribute is obsolete and SHOULD NOT be used. It SHOULD be ignored
if received.
6.2. keywds (keywords) 6.2. keywds (keywords)
Name: keywds Name: keywds
Value: keywds-value Value: keywds-value
Usage Level: session Usage Level: session
Charset Dependent: yes Charset Dependent: yes
skipping to change at page 26, line 30 skipping to change at page 26, line 30
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 is to assist identifying wanted sessions
at the receiver. This allows a receiver to select interesting at the receiver. This allows a receiver to select interesting
sessions based on keywords describing the purpose of the session; sessions based on keywords describing the purpose of the session;
there is no central registry of keywords. Its value should be there is no central registry of keywords. Its value should be
interpreted in the charset specified for the session description if interpreted in the charset specified for the session description if
one is specified, or by default in ISO 10646/UTF-8. This attribute one is specified, or by default in ISO 10646/UTF-8. This attribute
is obsoleted. is obsolete and SHOULD NOT be used. It SHOULD be ignored 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
skipping to change at page 29, line 41 skipping to change at page 29, line 44
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 of recvonly/sendrecv/sendonly/inactive MAY appear at At most one occurence of recvonly, sendrecv, sendonly, or inactive
session level, and at most one MAY appear in each media description. MAY appear at session level, and at most one MAY appear in each media
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 for sessions that are not of the multimedia conference type
"broadcast" or "H332" (see below). "broadcast" or "H332" (see below).
skipping to change at page 30, line 39 skipping to change at page 30, line 44
Charset Dependent: no Charset Dependent: no
Example: Example:
a=recvonly a=recvonly
This specifies that the tools should be started in receive-only mode This specifies that the tools should be started in receive-only mode
where applicable. Note that recvonly applies to the media only, not where applicable. Note that recvonly applies to the media only, not
to any associated control protocol (e.g., an RTP-based system in to any associated control protocol (e.g., an RTP-based system in
recvonly mode SHOULD still send RTCP packets). recvonly mode should still send RTCP packets).
6.7.2. sendrecv (send-receive) 6.7.2. sendrecv (send-receive)
Name: sendrecv Name: sendrecv
Value: Value:
Usage Level: session, media Usage Level: session, media
Charset Dependent: no Charset Dependent: no
Example: Example:
a=sendrecv a=sendrecv
This specifies that the tools should be started in send and receive This specifies that the tools should be started in send and receive
mode. This is necessary for interactive multimedia conferences with mode. This is necessary for interactive multimedia conferences with
tools that default to receive-only mode. tools that default to receive-only mode.
6.7.3. sendonly (send-only) 6.7.3. sendonly (send-only)
skipping to change at page 41, line 15 skipping to change at page 41, line 15
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: None Restrictions on usage: None
Author/Change controller: Author/Change controller:
Authors of RFC XXXX Authors of RFC XXXX
IETF MMUSIC working group delegated from the IESG IETF MMUSIC working group delegated from the IESG
8.2. Registration of Parameters 8.2. Registration of Parameters
This specification establishes and initializes IANA parameter This specification replaces and updates the definitions of IANA
registries for seven named SDP sub-fields. Using the terminology in parameter registries for seven named SDP sub-fields originally
the SDP specification Augmented Backus-Naur Form (ABNF), they are defined in [RFC4566]. Using the terminology in the SDP specification
"media", "proto", "att-field", "bwtype", "nettype", and "addrtype". Augmented Backus-Naur Form (ABNF), they are "media", "proto", "att-
field", "bwtype", "nettype", and "addrtype".
[EDITOR: Please change the RFC references to RFC4566 in these
registries to instead refer to this document.]
The contact address for all parameters registered below is: The contact address for all parameters registered below is:
IETF MMUSIC working group <mmusic@ietf.org> The IETF MMUSIC working group <mmusic@ietf.org> or its successor
as designated by the IESG.
8.2.1. Media Types ("media") 8.2.1. Media Types ("media")
The set of media types is intended to be small and SHOULD NOT be The set of media types is intended to be small and SHOULD NOT be
extended except under rare circumstances. The same rules should extended except under rare circumstances. The same rules should
apply for media names as for top-level media types, and where apply for media names as for top-level media types, and where
possible the same name should be registered for SDP as for MIME. For possible the same name should be registered for SDP as for MIME. For
media other than existing top-level media types, a Standards Track media other than existing top-level media types, a Standards Track
RFC MUST be produced for a new top-level media type to be registered, RFC MUST be produced for a new top-level media type to be registered,
and the registration MUST provide good justification why no existing and the registration MUST provide good justification why no existing
skipping to change at page 44, line 50 skipping to change at page 45, line 8
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.4.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], provided that the "Specification Required" policy of [RFC8126].
specification updating the attribute (for example, by adding a new
value) considers the registration information items from The Designated Expert reviewing the update is requested to evaluate
whether the update is compatible with the prior intent and use of the
attribute, and whether the new document is of sufficient maturity and
authority in relation to the prior document.
The specification updating the attribute (for example, by adding a
new value) MUST update registration information items from
Section 8.2.4.1 according to the following bullets: Section 8.2.4.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
skipping to change at page 46, line 51 skipping to change at page 47, line 16
definitions as in Sections 5.2 and 5.7 of this memo (these definitions as in Sections 5.2 and 5.7 of this memo (these
definitions update those in [RFC4566]). definitions update those in [RFC4566]).
8.2.8. Registration Procedure 8.2.8. Registration Procedure
In the RFC specifications that register new values for SDP "media", In the RFC specifications that register new values for SDP "media",
"proto", "fmt", "bwtype", "nettype", and "addrtype" parameters, the "proto", "fmt", "bwtype", "nettype", and "addrtype" parameters, the
authors MUST include the following information for IANA to place in authors MUST include the following information for IANA to place in
the appropriate registry: the appropriate registry:
o contact name, email address, and telephone number o contact name
o name being registered (as it will appear in SDP)
o long-form name in English o contact email address
o name being registered (as it will appear in SDP)
o type of name ("media", "proto", "fmt", "bwtype", "nettype", or o type of name ("media", "proto", "fmt", "bwtype", "nettype", or
"addrtype") "addrtype")
o a one-paragraph explanation of the purpose of the registered name o a one-paragraph explanation of the purpose of the registered name
o a reference to the specification for the registered name (this o a reference to the specification for the registered name (this
will typically be an RFC number) will typically be an RFC number)
In the case of a new addrtype registration, the author has to check In the case of a new addrtype registration, the author has to check
skipping to change at page 49, line 29 skipping to change at page 49, line 45
uri-field = %s"u" "=" uri CRLF uri-field = %s"u" "=" uri CRLF
email-field = %s"e" "=" email-address CRLF email-field = %s"e" "=" email-address CRLF
phone-field = %s"p" "=" phone-number CRLF phone-field = %s"p" "=" phone-number CRLF
connection-field = %s"c" "=" nettype SP addrtype SP connection-field = %s"c" "=" nettype SP addrtype SP
connection-address CRLF connection-address CRLF
;a connection field must be present ;a connection field must be present
;in every media description or at the ;in every media description or at the
;session-level ;session level
bandwidth-field = %s"b" "=" bwtype ":" bandwidth CRLF bandwidth-field = %s"b" "=" bwtype ":" bandwidth CRLF
time-description = time-field time-description = time-field
[repeat-description] [repeat-description]
repeat-description = 1*repeat-field repeat-description = 1*repeat-field
[zone-field] [zone-field]
time-field = %s"t" "=" start-time SP stop-time CRLF time-field = %s"t" "=" start-time SP stop-time CRLF
repeat-field = %s"r" "=" repeat-interval SP typed-time repeat-field = %s"r" "=" repeat-interval SP typed-time
1*(SP typed-time) CRLF 1*(SP typed-time) CRLF
zone-field = %s"z" "=" time SP ["-"] typed-time zone-field = %s"z" "=" time SP ["-"] typed-time
*(SP time SP ["-"] typed-time) CRLF *(SP time SP ["-"] typed-time) CRLF
skipping to change at page 54, line 19 skipping to change at page 54, line 33
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>
URI-reference = <URI-reference definition from RFC3986> URI-reference = <URI-reference definition from RFC3986>
addr-spec = <addr-spec definition from RFC5322> addr-spec = <addr-spec definition from RFC5322>
10. Summary of Changes from RFC 4566 10. Summary of Changes from RFC 4566
The ABNF rule for IP6-address has been corrected. As a result, the o Generally clarified and refined terminology.
ABNF rule for IP6-multicast has changed, and the (now unused) rules
for hexpart, hexseq, and hex4 have been removed.
IP4 unicast and multicast addresses in the example SDP descriptions o Identified now-obsolete items: "a=cat", "a=keywds", "k=".
have been revised per RFCs 5735 and 5771.
Text in Section 5.2 has been revised to clarify the use of local o Updated normative and informative references, and added references
addresses in case of ICE-like SDP extensions. to additional relevant related RFCs.
Normative and informative references have been updated. o Reformatted the SDP Attributes section for readability. The
syntax of attribute values is now given in ABNF.
The text regarding the session vs. media-level attribute usage has o Made mandatory the sending of RTCP with inactive media streams.
been clarified.
The case-insensitivity rules from RFC 4855 have been included in this o Expanded and clarified the specification of the "lang" and
document. "sdplang" attributes.
o Removed some references to SAP because it is no longer in
widespread use.
o Changed the way <fmt> values for UDP transport are registered.
o Changed the mechanism and documentation required for registering
new attributes.
o Tightened up IANA registration procedures for extensions. Removed
phone number and long-form name.
o Reorganized the IANA nettype registry
o Reorganized the several IANA att-type registries into a single
registry
o Revised ABNF syntax for clarity. Backward compatibility is
maintained with a few exceptions:
* Revised the syntax of time descriptions ("t=", "r=", "z=") to
remove ambiguities. Clarified that "z=" only modifies the
immediately preceding "r=" lines. Made "z=" without a
preceding "r=" a syntax error. (This is incompatible with
certain aberrant usage.)
* Updated the "IP6-address" and "IP6-multicast" rules, consistent
with the syntax in RFC3986. (This mirrors a bug fix made to
RFC3261 by RFC5964.) Removed rules that were unused as a
result of this change.
o Revised IPv4 unicast and multicast addresses in the example SDP
descriptions per RFCs 5735 and 5771.
o Incorporated case-insensitivity rules from RFC 4855.
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
contributed to the creation of this document or one of its
predecessor documents: Adam Roach, Allison Mankin, Bernie Hoeneisen,
Bill Fenner, Carsten Bormann, Eve Schooler, Flemming Andreasen,
Gonzalo Camarillo, Joerg Ott, John Elwell, Jon Peterson, Jonathan
Lennox, Jonathan Rosenberg, Keith Drage, Peter Parnes, Rob Lanphier,
Ross Finlayson, Sean Olson, Spencer Dawkins, Steve Casner, Steve
Hanna, Van Jacobson.
12. References 12. References
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., Stoetzer-Bradler, J., Ejzak, R., Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R.,
Marcon, J., and R. Even, "SDP-based Data Channel Marcon, J., and R. Even, "SDP-based Data Channel
Negotiation", draft-ietf-mmusic-data-channel-sdpneg-22 Negotiation", draft-ietf-mmusic-data-channel-sdpneg-23
(work in progress), November 2018. (work in progress), January 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.
[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>.
 End of changes. 53 change blocks. 
105 lines changed or deleted 168 lines changed or added

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