draft-ietf-mmusic-rfc4566bis-23.txt   draft-ietf-mmusic-rfc4566bis-24.txt 
Network Working Group M. Handley Network Working Group M. Handley
Internet-Draft UCL Internet-Draft UCL
Obsoletes: 4566 (if approved) V. Jacobson Obsoletes: 4566 (if approved) C. Perkins
Intended status: Standards Track Intended status: Standards Track University of Glasgow
Expires: March 20, 2018 C. Perkins Expires: April 10, 2018 A. Begen
University of Glasgow
A. Begen
Networked Media Networked Media
September 16, 2017 October 7, 2017
SDP: Session Description Protocol SDP: Session Description Protocol
draft-ietf-mmusic-rfc4566bis-23 draft-ietf-mmusic-rfc4566bis-24
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 36
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 March 20, 2018. This Internet-Draft will expire on April 10, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 25 skipping to change at page 2, line 23
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4
3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . . 4 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . . 5
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . 5 4. Requirements and Recommendations . . . . . . . . . . . . . . 6
4.1. Media and Transport Information . . . . . . . . . . . . . 6 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 . . . . . . 7 4.3. Obtaining Further Information about a Session . . . . . . 8
4.4. Categorisation . . . . . . . . . . . . . . . . . . . . . 8 4.4. Categorisation . . . . . . . . . . . . . . . . . . . . . 8
4.5. Internationalisation . . . . . . . . . . . . . . . . . . 8 4.5. Internationalisation . . . . . . . . . . . . . . . . . . 8
5. SDP Specification . . . . . . . . . . . . . . . . . . . . . . 8 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Protocol Version ("v=") . . . . . . . . . . . . . . . . . 11 5.1. Protocol Version ("v=") . . . . . . . . . . . . . . . . . 11
5.2. Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 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 Data ("c=") . . . . . . . . . . . . . . . . . 15 5.7. Connection Data ("c=") . . . . . . . . . . . . . . . . . 15
skipping to change at page 3, line 10 skipping to change at page 3, line 8
5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 20 5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 20
5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 20 5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 20
5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 21 5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 21
6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 24 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 24
6.1. cat (category) . . . . . . . . . . . . . . . . . . . . . 24 6.1. cat (category) . . . . . . . . . . . . . . . . . . . . . 24
6.2. keywds (keywords) . . . . . . . . . . . . . . . . . . . . 25 6.2. keywds (keywords) . . . . . . . . . . . . . . . . . . . . 25
6.3. tool . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.3. tool . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.4. ptime (packet time) . . . . . . . . . . . . . . . . . . . 26 6.4. ptime (packet time) . . . . . . . . . . . . . . . . . . . 26
6.5. maxptime (maximum packet time) . . . . . . . . . . . . . 26 6.5. maxptime (maximum packet time) . . . . . . . . . . . . . 26
6.6. rtpmap . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.6. rtpmap . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.7. Media Direction Attributes . . . . . . . . . . . . . . . 29 6.7. Media Direction Attributes . . . . . . . . . . . . . . . 28
6.7.1. recvonly (receive-only) . . . . . . . . . . . . . . . 29 6.7.1. recvonly (receive-only) . . . . . . . . . . . . . . . 29
6.7.2. sendrecv (send-receive) . . . . . . . . . . . . . . . 30 6.7.2. sendrecv (send-receive) . . . . . . . . . . . . . . . 30
6.7.3. sendonly (send-only) . . . . . . . . . . . . . . . . 30 6.7.3. sendonly (send-only) . . . . . . . . . . . . . . . . 30
6.7.4. inactive . . . . . . . . . . . . . . . . . . . . . . 31 6.7.4. inactive . . . . . . . . . . . . . . . . . . . . . . 30
6.8. orient (orientation) . . . . . . . . . . . . . . . . . . 31 6.8. orient (orientation) . . . . . . . . . . . . . . . . . . 31
6.9. type (conference type) . . . . . . . . . . . . . . . . . 32 6.9. type (conference type) . . . . . . . . . . . . . . . . . 31
6.10. charset (character set) . . . . . . . . . . . . . . . . . 32 6.10. charset (character set) . . . . . . . . . . . . . . . . . 32
6.11. sdplang (SDP language) . . . . . . . . . . . . . . . . . 33 6.11. sdplang (SDP language) . . . . . . . . . . . . . . . . . 33
6.12. lang (language) . . . . . . . . . . . . . . . . . . . . . 34 6.12. lang (language) . . . . . . . . . . . . . . . . . . . . . 34
6.13. framerate (frame rate) . . . . . . . . . . . . . . . . . 35 6.13. framerate (frame rate) . . . . . . . . . . . . . . . . . 35
6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 36 6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 36 6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 36
7. Security Considerations . . . . . . . . . . . . . . . . . . . 37 7. Security Considerations . . . . . . . . . . . . . . . . . . . 37
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
8.1. The "application/sdp" Media Type . . . . . . . . . . . . 39 8.1. The "application/sdp" Media Type . . . . . . . . . . . . 39
8.2. Registration of Parameters . . . . . . . . . . . . . . . 41 8.2. Registration of Parameters . . . . . . . . . . . . . . . 41
skipping to change at page 4, line 26 skipping to change at page 4, line 26
not intended to support negotiation of session content or media not intended to support negotiation of session content or media
encodings: this is viewed as outside the scope of session encodings: this is viewed as outside the scope of session
description. description.
This memo obsoletes [RFC4566]. The changes relative to [RFC4566] are This memo obsoletes [RFC4566]. The changes relative to [RFC4566] are
limited to essential corrections, and are outlined in Section 10 of limited to essential corrections, and are outlined in Section 10 of
this memo. this memo.
2. Glossary of Terms 2. Glossary of Terms
The following term is used in this document and has specific meaning The following terms are used in this document and has specific
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
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
descriptions, whereas the session description refers to the whole
body that includes the session-level section and the media
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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
3. Examples of SDP Usage 3. Examples of SDP Usage
skipping to change at page 9, line 15 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 fields delimited by a single general, <value> is either a number of fields delimited by a single
space character or a free format string, and is case-significant space character or a free format string, and is case-significant
unless a specific field defines otherwise. Whitespace separators unless a specific field defines otherwise. Whitespace separators
MUST NOT be used on either side of the "=" sign, however, if the MUST NOT be used on either side of the "=" sign, however, if the
value can contain a leading whitespace as part of its syntax, i.e., value can contain a leading whitespace as part of its syntax, i.e.,
that whitespace is part of the value. that whitespace is part of the value.
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-level sections. The session-level part starts zero or more media descriptions. The session-level section starts
with a "v=" line and continues to the first media-level section (or with a "v=" line and continues to the first media description (or the
the end of the whole description, whichever comes first). Each end of the whole description, whichever comes first). Each media
media-level section starts with an "m=" line and continues to the description starts with an "m=" line and continues to the next media
next media-level section or the end of the whole session description description or the end of the whole session description - whichever
- whichever comes first. In general, session-level values are the comes first. In general, session-level values are the default for
default for all media unless overridden by an equivalent media-level all media unless overridden by an equivalent media-level value.
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 order
greatly enhances error detection and allows for a simple parser). greatly enhances error detection and allows for a simple parser).
OPTIONAL items are marked with a "*". 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)
skipping to change at page 22, line 5 skipping to change at page 22, line 5
m=<media> <port> <proto> <fmt> ... m=<media> <port> <proto> <fmt> ...
A session description may contain a number of media descriptions. A session description may contain a number of media descriptions.
Each media description starts with an "m=" line and is terminated by Each media description starts with an "m=" line and is terminated by
either the next "m=" line or by the end of the session description. either the next "m=" line or by the end of the session description.
A media field has several sub-fields: A media field has several sub-fields:
<media> is the media type. This document defines the values <media> is the media type. This document defines the values
"audio", "video", "text", "application", and "message". This list "audio", "video", "text", "application", and "message". This list
is extended and may be further extended by other memos registering is extended and may be further extended by other memos registering
media types in the future (see Section 8). media types in the future (see Section 8). For example, [RFC6466]
defined the "image" media type.
<port> is the transport port to which the media stream is sent. The <port> is the transport port to which the media stream is sent. The
meaning of the transport port depends on the network being used as meaning of the transport port depends on the network being used as
specified in the relevant "c=" line, and on the transport protocol specified in the relevant "c=" line, and on the transport protocol
defined in the <proto> sub-field of the media field. Other ports defined in the <proto> sub-field of the media field. Other ports
used by the media application (such as the RTP Control Protocol used by the media application (such as the RTP Control Protocol
(RTCP) port [RFC3550]) MAY be derived algorithmically from the (RTCP) port [RFC3550]) MAY be derived algorithmically from the
base media port or MAY be specified in a separate attribute (for base media port or MAY be specified in a separate attribute (for
example, "a=rtcp:" as defined in [RFC3605]). example, "a=rtcp:" as defined in [RFC3605]).
skipping to change at page 27, line 23 skipping to change at page 27, line 27
Name: rtpmap Name: rtpmap
Value: rtpmap-value Value: rtpmap-value
Usage Level: media Usage Level: media
Charset Dependent: no Charset Dependent: no
Syntax: Syntax:
rtpmap-value = payload-type SP encoding-name rtpmap-value = payload-type SP encoding-name
"/" clock-rate [ "/" encoding-params ] "/" clock-rate [ "/" encoding-params ]
payload-type = zero-based-integer payload-type = zero-based-integer
encoding-name = token encoding-name = token
clock-rate = integer clock-rate = integer
; Editor's note: Do we want to define a limited range for this? encoding-params = channels
encoding-params = channels channels = integer
; Editor's note: 4566 is vague about what this can be. RFC4855 seems to be
; the authoritative source, and only allows the
; value of the media subtype "channels" parameter - the
; number of audio channels.
; Does anyone think this can be used for something else?
; (The implication that multiple parameters might be included
; seems a misdirection - additional parameters are
; to go into a=fmtp.)
; Does anyone have an example of other parameters
; using this field? If none, it will stay as it is.
channels = integer
; Editor's note: Is there any reason to make this less restrictive?
This attribute maps from an RTP payload type number (as used in an This attribute maps from an RTP payload type number (as used in an
"m=" line) to an encoding name denoting the payload format to be "m=" line) to an encoding name denoting the payload format to be
used. It also provides information on the clock rate and encoding used. It also provides information on the clock rate and encoding
parameters. Note that the payload type number is indicated in a parameters. Note that the payload type number is indicated in a
7-bit field, limiting the values to incusively between 0 and 127. 7-bit field, limiting the values to incusively between 0 and 127.
Although an RTP profile can make static assignments of payload type Although an RTP profile can make static assignments of payload type
numbers to payload formats, it is more common for that assignment to numbers to payload formats, it is more common for that assignment to
be done dynamically using "a=rtpmap:" attributes. As an example of a be done dynamically using "a=rtpmap:" attributes. As an example of a
skipping to change at page 34, line 17 skipping to change at page 34, line 5
a=sdplang:fr a=sdplang:fr
Multiple sdplang attributes can be provided either at session or Multiple sdplang attributes can be provided either at session or
media level if the session description or media use multiple media level if the session description or media use multiple
languages. languages.
As a session-level attribute, it specifies the language for the As a session-level attribute, it specifies the language for the
session description (not the language of the media). As a media- session description (not the language of the media). As a media-
level attribute, it specifies the language for any media-level SDP level attribute, it specifies the language for any media-level SDP
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 of the media), overriding any sdplang attributes specified at session
session-level. level.
In general, sending session descriptions consisting of multiple In general, sending session descriptions consisting of multiple
languages is discouraged. Instead, multiple descriptions SHOULD be languages is discouraged. Instead, multiple descriptions SHOULD be
sent describing the session, one in each language. However, this is sent describing the session, one in each language. However, this is
not possible with all transport mechanisms, and so multiple sdplang not possible with all transport mechanisms, and so multiple sdplang
attributes are allowed although NOT RECOMMENDED. 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 tag
in US-ASCII. An "sdplang" attribute SHOULD be specified when a in US-ASCII. An "sdplang" attribute SHOULD be specified when a
session is distributed with sufficient scope to cross geographic session is distributed with sufficient scope to cross geographic
skipping to change at page 41, line 26 skipping to change at page 41, line 26
8.2.1. Media Types ("media") 8.2.1. Media Types ("media")
The set of media types is intended to be small and SHOULD NOT be The set of media types is intended to be small and SHOULD NOT be
extended except under rare circumstances. The same rules should extended except under rare circumstances. The same rules should
apply for media names as for top-level media types, and where apply for media names as for top-level media types, and where
possible the same name should be registered for SDP as for MIME. For possible the same name should be registered for SDP as for MIME. For
media other than existing top-level media types, a Standards Track media other than existing top-level media types, a Standards Track
RFC MUST be produced for a new top-level media type to be registered, RFC MUST be produced for a new top-level media type to be registered,
and the registration MUST provide good justification why no existing and the registration MUST provide good justification why no existing
media name is appropriate (the "Standards Action" policy of media name is appropriate (the "Standards Action" policy of
[RFC5226]. [RFC8126].
This memo registers the media types "audio", "video", "text", This memo registers the media types "audio", "video", "text",
"application", and "message". "application", and "message".
Note: The media types "control" and "data" were listed as valid in an Note: The media types "control" and "data" were listed as valid in an
early version of this specification (RFC 2327); however, their early version of this specification (RFC 2327); however, their
semantics were never fully specified and they are not widely used. semantics were never fully specified and they are not widely used.
These media types have been removed in this specification, although These media types have been removed in this specification, although
they still remain valid media type capabilities for a SIP user agent they still remain valid media type capabilities for a SIP user agent
as defined in [RFC3840]. If these media types are considered useful as defined in [RFC3840]. If these media types are considered useful
in the future, a Standards Track RFC MUST be produced to document in the future, a Standards Track RFC MUST be produced to document
their use. Until that is done, applications SHOULD NOT use these their use. Until that is done, applications SHOULD NOT use these
types and SHOULD NOT declare support for them in SIP capabilities types and SHOULD NOT declare support for them in SIP capabilities
declarations (even though they exist in the registry created by declarations (even though they exist in the registry created by
[RFC3840]). [RFC3840]). Also note that [RFC6466] defined the "image" media type.
8.2.2. Transport Protocols ("proto") 8.2.2. Transport Protocols ("proto")
The "proto" field describes the transport protocol used. This SHOULD The "proto" field describes the transport protocol used. This SHOULD
reference a standards-track protocol RFC. This memo registers three reference a standards-track protocol RFC. This memo registers three
values: "RTP/AVP" is a reference to [RFC3550] used under the RTP values: "RTP/AVP" is a reference to [RFC3550] used under the RTP
Profile for Audio and Video Conferences with Minimal Control Profile for Audio and Video Conferences with Minimal Control
[RFC3551] running over UDP/IP, "RTP/SAVP" is a reference to the [RFC3551] running over UDP/IP, "RTP/SAVP" is a reference to the
Secure Real-time Transport Protocol [RFC3711], and "udp" indicates an Secure Real-time Transport Protocol [RFC3711], and "udp" indicates an
unspecified protocol over UDP. unspecified protocol over UDP.
skipping to change at page 43, line 8 skipping to change at page 43, line 8
8.2.4.1. New Attributes 8.2.4.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, because of noticeable issues due to conflicting documented, because of noticeable issues due to conflicting
attributes under the same name. Unknown attributes in SDP are simply attributes under the same name. Unknown attributes in SDP are simply
ignored, but conflicting ones that fragment the protocol are a ignored, but conflicting ones that fragment the protocol are a
serious problem. serious problem.
New attribute registrations are accepted according to the New attribute registrations are accepted according to the
"Specification Required" policy of [RFC5226], provided that the "Specification Required" policy of [RFC8126], provided that the
specification includes the following information: specification includes the following information:
o Contact Name. o Contact Name.
o Contact Email Address. o Contact Email Address.
o Attribute Name: The name of the attribute that will appear in o Attribute Name: The name of the attribute that will appear in
SDP). This MUST conform to the definition of <att-field>. SDP). This MUST conform to the definition of <att-field>.
o Attribute Syntax: For a value attribute (see clause 5.13), an ABNF o Attribute Syntax: For a value attribute (see clause 5.13), an ABNF
skipping to change at page 44, line 36 skipping to change at page 44, line 36
session level. When this is not the case for a new SDP attribute, it session level. When this is not the case for a new SDP attribute, it
MUST be explicitly stated. MUST be explicitly 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 [RFC5226], provided that the "Specification Required" policy of [RFC8126], provided that the
specification updating the attribute (for example, by adding a new specification updating the attribute (for example, by adding a new
value) considers the registration information items from value) considers the registration information items from
Section Section 8.2.4.1 according to the following bullets: Section 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.
skipping to change at page 45, line 47 skipping to change at page 45, line 47
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.6. Network Types ("nettype")
New network types (the "nettype" field) MUST be registered with IANA New network types (the "nettype" field) MUST be registered with IANA
if SDP needs to be used in the context of non-Internet environments. if SDP needs to be used in the context of non-Internet environments.
The registration is subject to the RFC Required - RFC publication The registration is subject to the RFC Required - RFC publication
policy of [RFC5226]. 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.7. 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 - RFC publication policy registration is subject to the RFC Required - RFC publication policy
of [RFC5226]. An address type is only meaningful in the context of a of [RFC8126]. An address type is only meaningful in the context of a
network type, and any registration of an address type MUST specify a network type, and any registration of an address type MUST specify a
registered network type or be submitted along with a network type registered network type or be submitted along with a network type
registration. A new address type registration MUST reference an RFC registration. A new address type registration MUST reference an RFC
giving details of the syntax of the address type. Address types are giving details of the syntax of the address type. Address types are
not expected to be registered frequently. not expected to be registered frequently.
IANA has registered the address types "IP4" and "IP6" with IANA has registered the address types "IP4" and "IP6" with
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]).
skipping to change at page 55, line 14 skipping to change at page 55, line 14
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <https://www.rfc-editor.org/info/rfc4566>. July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<https://www.rfc-editor.org/info/rfc5576>. <https://www.rfc-editor.org/info/rfc5576>.
[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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
12.2. Informative References 12.2. Informative References
[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.
[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>.
skipping to change at page 57, line 10 skipping to change at page 57, line 5
"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>.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Carrara, "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", RFC 4567, DOI 10.17487/RFC4567, July
2006, <https://www.rfc-editor.org/info/rfc4567>.
[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>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010, DOI 10.17487/RFC5245, April 2010,
<https://www.rfc-editor.org/info/rfc5245>. <https://www.rfc-editor.org/info/rfc5245>.
skipping to change at page 57, line 45 skipping to change at page 57, line 29
[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, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC6466] Salgueiro, G., "IANA Registration of the 'image' Media
Type for the Session Description Protocol (SDP)",
RFC 6466, DOI 10.17487/RFC6466, December 2011,
<https://www.rfc-editor.org/info/rfc6466>.
[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
"TCP Candidates with Interactive Connectivity "TCP Candidates with Interactive Connectivity
Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544,
March 2012, <https://www.rfc-editor.org/info/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>.
skipping to change at page 58, line 35 skipping to change at page 58, line 20
Authors' Addresses Authors' Addresses
Mark Handley Mark Handley
University College London University College London
Department of Computer Science Department of Computer Science
London WC1E 6BT London WC1E 6BT
UK UK
EMail: M.Handley@cs.ucl.ac.uk EMail: M.Handley@cs.ucl.ac.uk
Van Jacobson
USA
EMail: van@parc.com
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
School of Computing Science School of Computing Science
University of Glasgow University of Glasgow
Glasgow G12 8QQ Glasgow G12 8QQ
UK UK
EMail: csp@csperkins.org EMail: csp@csperkins.org
Ali Begen Ali Begen
Networked Media Networked Media
Konya Konya
Turkey Turkey
EMail: ali.begen@networked.media EMail: ali.begen@networked.media
 End of changes. 28 change blocks. 
79 lines changed or deleted 60 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/