draft-ietf-mmusic-rfc4566bis-36.txt   draft-ietf-mmusic-rfc4566bis-37.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: December 20, 2019 C. Perkins Expires: February 10, 2020 C. Perkins
University of Glasgow University of Glasgow
M. Handley M. Handley
UCL UCL
June 18, 2019 August 9, 2019
SDP: Session Description Protocol SDP: Session Description Protocol
draft-ietf-mmusic-rfc4566bis-36 draft-ietf-mmusic-rfc4566bis-37
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 December 20, 2019. This Internet-Draft will expire on February 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 51 skipping to change at page 2, line 51
5.6. Email Address and Phone Number ("e=" and "p=") . . . . . 14 5.6. Email Address and Phone Number ("e=" and "p=") . . . . . 14
5.7. Connection Information ("c=") . . . . . . . . . . . . . . 15 5.7. Connection Information ("c=") . . . . . . . . . . . . . . 15
5.8. Bandwidth Information ("b=") . . . . . . . . . . . . . . 17 5.8. Bandwidth Information ("b=") . . . . . . . . . . . . . . 17
5.9. Time Active ("t=") . . . . . . . . . . . . . . . . . . . 18 5.9. Time Active ("t=") . . . . . . . . . . . . . . . . . . . 18
5.10. Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . 19 5.10. Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . 19
5.11. Time Zone Adjustment ("z=") . . . . . . . . . . . . . . . 20 5.11. Time Zone Adjustment ("z=") . . . . . . . . . . . . . . . 20
5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 21 5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 21
5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 21 5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 21
5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 22 5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 22
6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 25 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 25
6.1. cat (category) . . . . . . . . . . . . . . . . . . . . . 25 6.1. cat (category) . . . . . . . . . . . . . . . . . . . . . 26
6.2. keywds (keywords) . . . . . . . . . . . . . . . . . . . . 26 6.2. keywds (keywords) . . . . . . . . . . . . . . . . . . . . 26
6.3. tool . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.3. tool . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.4. ptime (packet time) . . . . . . . . . . . . . . . . . . . 27 6.4. ptime (packet time) . . . . . . . . . . . . . . . . . . . 27
6.5. maxptime (maximum packet time) . . . . . . . . . . . . . 27 6.5. maxptime (maximum packet time) . . . . . . . . . . . . . 28
6.6. rtpmap . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.6. rtpmap . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.7. Media Direction Attributes . . . . . . . . . . . . . . . 30 6.7. Media Direction Attributes . . . . . . . . . . . . . . . 30
6.7.1. recvonly (receive-only) . . . . . . . . . . . . . . . 30 6.7.1. recvonly (receive-only) . . . . . . . . . . . . . . . 31
6.7.2. sendrecv (send-receive) . . . . . . . . . . . . . . . 31 6.7.2. sendrecv (send-receive) . . . . . . . . . . . . . . . 31
6.7.3. sendonly (send-only) . . . . . . . . . . . . . . . . 31 6.7.3. sendonly (send-only) . . . . . . . . . . . . . . . . 32
6.7.4. inactive . . . . . . . . . . . . . . . . . . . . . . 32 6.7.4. inactive . . . . . . . . . . . . . . . . . . . . . . 32
6.8. orient (orientation) . . . . . . . . . . . . . . . . . . 32 6.8. orient (orientation) . . . . . . . . . . . . . . . . . . 33
6.9. type (conference type) . . . . . . . . . . . . . . . . . 33 6.9. type (conference type) . . . . . . . . . . . . . . . . . 33
6.10. charset (character set) . . . . . . . . . . . . . . . . . 34 6.10. charset (character set) . . . . . . . . . . . . . . . . . 34
6.11. sdplang (SDP language) . . . . . . . . . . . . . . . . . 34 6.11. sdplang (SDP language) . . . . . . . . . . . . . . . . . 35
6.12. lang (language) . . . . . . . . . . . . . . . . . . . . . 35 6.12. lang (language) . . . . . . . . . . . . . . . . . . . . . 36
6.13. framerate (frame rate) . . . . . . . . . . . . . . . . . 36 6.13. framerate (frame rate) . . . . . . . . . . . . . . . . . 37
6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 37 6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 37 6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 38
7. Security Considerations . . . . . . . . . . . . . . . . . . . 38 7. Security Considerations . . . . . . . . . . . . . . . . . . . 39
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
8.1. The "application/sdp" Media Type . . . . . . . . . . . . 40 8.1. The "application/sdp" Media Type . . . . . . . . . . . . 40
8.2. Registration of Parameters . . . . . . . . . . . . . . . 41 8.2. Registration of SDP Parameters with IANA . . . . . . . . 42
8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 41 8.2.1. Registration Procedure . . . . . . . . . . . . . . . 42
8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 42 8.2.2. Media Types ("media") . . . . . . . . . . . . . . . . 43
8.2.3. Attribute Names ("att-field") . . . . . . . . . . . . 43 8.2.3. Transport Protocols ("proto") . . . . . . . . . . . . 43
8.2.4. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 46 8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 44
8.2.5. Network Types ("nettype") . . . . . . . . . . . . . . 46 8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 48
8.2.6. Address Types ("addrtype") . . . . . . . . . . . . . 47 8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 48
8.2.7. Registration Procedure . . . . . . . . . . . . . . . 47 8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 49
8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 47 8.3. Encryption Key Access Methods (OBSOLETE) . . . . . . . . 50
8.4. Reorganization of the nettype and addrtype registries . . 48 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.5. Reorganization of the att-field Registries . . . . . . . 48 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 55
9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 49 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57
10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 54 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 57
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56 12.1. Normative References . . . . . . . . . . . . . . . . . . 57
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 12.2. Informative References . . . . . . . . . . . . . . . . . 60
12.1. Normative References . . . . . . . . . . . . . . . . . . 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62
12.2. Informative References . . . . . . . . . . . . . . . . . 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 17, line 43 skipping to change at page 17, line 43
the session giving the proposed upper limit to the bandwidth used the session giving the proposed upper limit to the bandwidth used
(the "conference total" bandwidth). Similarly, if the bandwidth (the "conference total" bandwidth). Similarly, if the bandwidth
of bundled media streams [I-D.ietf-mmusic-sdp-bundle-negotiation] of bundled media streams [I-D.ietf-mmusic-sdp-bundle-negotiation]
in an "m=" line is different from the implicit value from the in an "m=" line is different from the implicit value from the
scope, a "b=CT:..." line SHOULD be supplied in the media level. scope, a "b=CT:..." line SHOULD be supplied in the media level.
The primary purpose of this is to give an approximate idea as to The primary purpose of this is to give an approximate idea as to
whether two or more sessions (or bundled media streams) can whether two or more sessions (or bundled media streams) can
coexist simultaneously. Note that CT gives a total bandwidth coexist simultaneously. Note that CT gives a total bandwidth
figure for all the media at all endpoints. figure for all the media at all endpoints.
The Mux Category for CT is NORMAL. This is discussed in
[I-D.ietf-mmusic-sdp-mux-attributes].
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.
The Mux Category for AS is SUM. This is discussed in
[I-D.ietf-mmusic-sdp-mux-attributes].
[RFC4566] defined an "X-" prefix for <bwtype> names. This was [RFC4566] defined an "X-" prefix for <bwtype> names. This was
intended for 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
skipping to change at page 41, line 22 skipping to change at page 42, line 5
IETF MMUSIC working group <mmusic@ietf.org> IETF MMUSIC working group <mmusic@ietf.org>
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 SDP Parameters with IANA
This specification replaces and updates the definitions of IANA This document specifies IANA parameter registries for six named SDP
parameter registries for seven named SDP sub-fields originally sub-fields. Using the terminology in the SDP specification Augmented
defined in [RFC4566]. Using the terminology in the SDP specification Backus-Naur Form (ABNF), they are "media", "proto", "att-field",
Augmented Backus-Naur Form (ABNF), they are "media", "proto", "att- "bwtype", "nettype", and "addrtype".
field", "bwtype", "nettype", and "addrtype".
[EDITOR: Please change the RFC references to RFC4566 in these This document also replaces and updates the definitions of all those
registries to instead refer to this document.] parameters previously defined by [RFC4566].
The contact address for all parameters registered below is: IANA: Please change all references to RFC4566 in these registries to
instead refer to this document.
The contact name and email address for all parameters registered in
this document is:
The IETF MMUSIC working group <mmusic@ietf.org> or its successor The IETF MMUSIC working group <mmusic@ietf.org> or its successor
as designated by the IESG. as designated by the IESG.
8.2.1. Media Types ("media") All of these registries have a common format:
----------------------------------------------------
| Type | SDP Name | [other fields] | Reference |
----------------------------------------------------
8.2.1. Registration Procedure
A specification document that defines values for SDP "media",
"proto", "att-field", "bwtype", "nettype", and "addrtype" parameters
MUST include the following information:
o contact name;
o contact email address;
o name being defined (as it will appear in SDP);
o type of name ("media", "proto", "bwtype", "nettype", or
"addrtype");
o a description of the purpose of the defined name;
o a stable reference to the document containing this information and
the definition of the value. (This will typically be an RFC
number.)
The subsections below specify what other information (if any) must be
specified for particular parameters, and what other fields are to be
included in the registry.
8.2.2. 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
[RFC8126]). [RFC8126]).
skipping to change at page 42, line 20 skipping to change at page 43, line 36
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]). Also note that [RFC6466] defined the "image" media type. [RFC3840]). Also note that [RFC6466] defined the "image" media type.
8.2.2. Transport Protocols ("proto") 8.2.3. Transport Protocols ("proto")
The "proto" sub-field describes the transport protocol used. The The "proto" sub-field describes the transport protocol used. The
registration procedure for this registry is "RFC Required". registration procedure for this registry is "RFC Required".
This document registers two values: "RTP/AVP" is a reference to This document registers two values:
[RFC3550] used under the RTP Profile for Audio and Video Conferences
with Minimal Control [RFC3551] running over UDP/IP, and "udp" o "RTP/AVP" is a reference to [RFC3550] used under the RTP Profile
indicates direct use of the UDP protocol. for Audio and Video Conferences with Minimal Control [RFC3551]
running over UDP/IP,
o "UDP" indicates direct use of the UDP protocol.
New transport protocols MAY be defined, and MUST be registered with New transport protocols MAY be defined, and MUST be registered with
IANA. Registrations MUST reference an RFC describing the protocol. IANA. Registrations MUST reference an RFC describing the protocol.
Such an RFC MAY be Experimental or Informational, although it is Such an RFC MAY be Experimental or Informational, although it is
preferable that it be Standards Track. The RFC defining a new preferable that it be Standards Track. The RFC defining a new
protocol MUST define the rules by which the "fmt" (see below) protocol MUST define the rules by which the "fmt" (see below)
namespace is managed. namespace is managed.
"proto" names starting with "RTP/" MUST only be used for defining "proto" names starting with "RTP/" MUST only be used for defining
transport protocols that are profiles of the RTP protocol. For transport protocols that are profiles of the RTP protocol. For
skipping to change at page 43, line 7 skipping to change at page 44, line 26
RTP payload formats under the "RTP/AVP" and other "RTP/*" profiles RTP payload formats under the "RTP/AVP" and other "RTP/*" profiles
MUST use the payload type number as their "fmt" value. If the MUST use the payload type number as their "fmt" value. If the
payload type number is dynamically assigned by this session payload type number is dynamically assigned by this session
description, an additional "rtpmap" attribute MUST be included to description, an additional "rtpmap" attribute MUST be included to
specify the format name and parameters as defined by the media type specify the format name and parameters as defined by the media type
registration for the payload format. It is RECOMMENDED that other registration for the payload format. It is RECOMMENDED that other
RTP profiles that are registered (in combination with RTP) as SDP RTP profiles that are registered (in combination with RTP) as SDP
transport protocols specify the same rules for the "fmt" namespace. transport protocols specify the same rules for the "fmt" namespace.
For the "udp" protocol, allowed "fmt" values are media subtypes from For the "UDP" protocol, allowed "fmt" values are media subtypes from
the IANA Media Types registry. The media type and subtype the IANA Media Types registry. The media type and subtype
combination <media>/<fmt> specifies the format of the body of UDP combination <media>/<fmt> specifies the format of the body of UDP
packets. Use of an existing media subtype for the format is packets. Use of an existing media subtype for the format is
encouraged. If no suitable media subtype exists, it is RECOMMENDED encouraged. If no suitable media subtype exists, it is RECOMMENDED
that a new one be registered through the IETF process [RFC6838] by that a new one be registered through the IETF process [RFC6838] by
production of, or reference to, a standards-track RFC that defines production of, or reference to, a standards-track RFC that defines
the format. the format.
For other protocols, formats MAY be registered according to the rules For other protocols, formats MAY be registered according to the rules
of the associated "proto" specification. of the associated "proto" specification.
Registrations of new formats MUST specify which transport protocols Registrations of new formats MUST specify which transport protocols
they apply to. they apply to.
8.2.3. Attribute Names ("att-field") 8.2.4. Attribute Names ("att-field")
8.2.3.1. New Attributes
Attribute-field names ("att-field") MUST be registered with IANA and Attribute-field names ("att-field") MUST be registered with IANA and
documented, to avoid any issues due to conflicting attribute documented, to avoid any issues due to conflicting attribute
definitions under the same name. Unknown attributes in SDP are definitions under the same name. (While unknown attributes in SDP
simply ignored, but conflicting ones that fragment the protocol are a are simply ignored, conflicting ones that fragment the protocol are a
serious problem. serious problem.)
The format of the attribute registry is:
----------------------------------------------------------------------
| | | | Mux | |
| Type | SDP Name | Usage Level | Category | Reference |
----------------------------------------------------------------------
For example, the attribute "setup" which is defined for both session
and media level, will be listed in the new registry as follows:
----------------------------------------------------------------------
| | | | Mux | |
| Type | SDP Name | Usage Level | Category | Reference |
|----------|------------|----------------|----------|----------------|
|attribute |setup | session,media, |IDENTICAL | [RFC4145] |
| | | dcsa,dcsa(msrp)| | [RFC6135] |
| | | | | [I-D.mmusic- |
| | | | | msrp-usage- |
| | | | | data-channel] |
----------------------------------------------------------------------
This one registry combines all of the previous usage-level-specific
"att-field" registries, including updates made by
[I-D.ietf-mmusic-sdp-mux-attributes]. IANA is requested to do the
necessary reformatting.
Section 6 of this document replaces the initial set of attribute
definitions made by [RFC4566]. IANA is requested to update the
registry accordingly.
Documents can define new attributes and can also extend the
definitions of previously defined attributes:
8.2.4.1. New Attributes
New attribute registrations are accepted according to the New attribute registrations are accepted according to the
"Specification Required" policy of [RFC8126], provided that the "Specification Required" policy of [RFC8126], provided that the
specification includes the following information: specification includes the following information:
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
skipping to change at page 44, line 14 skipping to change at page 46, line 18
o Attribute Semantics: For a value attribute, a semantic description o Attribute Semantics: For a value attribute, a semantic description
of the values that the attribute might take MUST be provided. The of the values that the attribute might take MUST be provided. The
usage of a property attribute is described under purpose below. usage of a property attribute is described under purpose below.
o Attribute Value: The name of an ABNF syntax rule defining the o Attribute Value: The name of an ABNF syntax rule defining the
syntax of the value. Absence of a rule name indicates that the syntax of the value. Absence of a rule name indicates that the
attribute takes no values. Enclosing the rule name in "[" and "]" attribute takes no values. Enclosing the rule name in "[" and "]"
indicates that a value is optional. indicates that a value is optional.
o Usage Level: Usage level(s) of the attribute. One or more of: o Usage Level: Usage level(s) of the attribute. This MUST be one or
session, media, source, dcsa, dcsa(subprotocol). For a definition more of the following: session, media, source, dcsa and
of source level attributes, see [RFC5576]. For a definition of dcsa(subprotocol). For a definition of source level attributes,
dcsa attributes see: [I-D.ietf-mmusic-data-channel-sdpneg]. see [RFC5576]. For a definition of dcsa attributes see:
[I-D.ietf-mmusic-data-channel-sdpneg].
o Charset Dependent: Whether the attribute value is subject to the o Charset Dependent: This MUST be "Yes" or "No" depending on whether
charset attribute or not (Yes/No). the attribute value is subject to the charset attribute.
o Purpose: An explanation of the purpose and usage of the attribute. o Purpose: An explanation of the purpose and usage of the attribute.
o O/A Procedures: Offer/Answer procedures as explained in [RFC3264]. o O/A Procedures: Offer/Answer procedures as explained in [RFC3264].
o Mux Category: Indication of which multiplexing "category" o Mux Category: This MUST indicate one of the following categories:
[I-D.ietf-mmusic-sdp-mux-attributes] an attribute is associated NORMAL, NOT RECOMMENDED, IDENTICAL, SUM, TRANSPORT, INHERIT,
with. IDENTICAL-PER-PT, SPECIAL or TBD as defined by [I-D.ietf-mmusic-
sdp-mux-attributes].
o Reference: A reference to the specification defining the o Reference: A reference to the specification defining the
attribute. attribute.
The above is the minimum that IANA will accept. Attributes that are The above is the minimum that IANA will accept. Attributes that are
expected to see widespread use and interoperability SHOULD be expected to see widespread use and interoperability SHOULD be
documented with a standards-track RFC that specifies the attribute documented with a standards-track RFC that specifies the attribute
more precisely. more precisely.
Submitters of registrations should ensure that the specification is Submitters of registrations should ensure that the specification is
skipping to change at page 45, line 11 skipping to change at page 47, line 17
media" or "media" (depending on desired semantics). The default rule media" or "media" (depending on desired semantics). The default rule
is that for all new SDP attributes that can occur both in session and is that for all new SDP attributes that can occur both in session and
media level, the media level overrides the session level. When this media level, the media level overrides the session level. When this
is not the case for a new SDP attribute, it MUST be explicitly is not the case for a new SDP attribute, it MUST be explicitly
stated. stated.
IANA has registered the initial set of attribute names ("att-field" IANA has registered the initial set of attribute names ("att-field"
values) with definitions as in Section 6 of this memo (these values) with definitions as in Section 6 of this memo (these
definitions replace those in [RFC4566]). definitions replace those in [RFC4566]).
8.2.3.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]. "Specification Required" policy of [RFC8126].
The Designated Expert reviewing the update is requested to evaluate The Designated Expert reviewing the update is requested to evaluate
whether the update is compatible with the prior intent and use of the whether the update is compatible with the prior intent and use of the
attribute, and whether the new document is of sufficient maturity and attribute, and whether the new document is of sufficient maturity and
authority in relation to the prior document. authority in relation to the prior document.
The specification updating the attribute (for example, by adding a The specification updating the attribute (for example, by adding a
new value) MUST update registration information items from new value) MUST update registration information items from
Section 8.2.3.1 according to the following bullets: Section 8.2.4.1 according to the following constraints:
o Contact Name: A name MUST be provided. o Contact Name: A name for an entity responsible for the update MUST
be provided.
o Contact Email Address: An email address MUST be provided. o Contact Email Address: An email address for an entity responsible
for the update MUST be provided.
o Attribute Name: MUST be provided and MUST NOT be changed. o Attribute Name: MUST be provided and MUST NOT be changed.
Otherwise it is a new attribute. Otherwise it is a new attribute.
o Attribute Syntax: The existing rule syntax with the syntax o Attribute Syntax: The existing rule syntax with the syntax
extensions MUST be provided if there is a change to the syntax. A extensions MUST be provided if there is a change to the syntax. A
revision to an existing attribute usage MAY extend the syntax of revision to an existing attribute usage MAY extend the syntax of
an attribute, but MUST be backward compatible. an attribute, but MUST be backward compatible.
o Attribute Semantics: A semantic description of new additional o Attribute Semantics: A semantic description of new additional
skipping to change at page 46, line 10 skipping to change at page 48, line 17
o Purpose: MAY be extended according to the updated usage. o Purpose: MAY be extended according to the updated usage.
o O/A Procedures: MAY be updated in a backward compatible manner o O/A Procedures: MAY be updated in a backward compatible manner
and/or it applies to a new usage level only. and/or it applies to a new usage level only.
o Mux Category: No change unless from "TBD" to another value (see o Mux Category: No change unless from "TBD" to another value (see
[I-D.ietf-mmusic-sdp-mux-attributes]. It MAY also change if [I-D.ietf-mmusic-sdp-mux-attributes]. It MAY also change if
'media' level is being added to the definition of an attribute 'media' level is being added to the definition of an attribute
that previously did not include it. that previously did not include it.
o Reference: A new reference MUST be provided. o Reference: A new (additional or replacement) reference MUST be
provided.
Items SHOULD be omitted if there is no impact to them as a result of Items SHOULD be omitted if there is no impact to them as a result of
the attribute update. the attribute update.
8.2.4. Bandwidth Specifiers ("bwtype") 8.2.5. Bandwidth Specifiers ("bwtype")
A proliferation of bandwidth specifiers is strongly discouraged. A proliferation of bandwidth specifiers is strongly discouraged.
New bandwidth specifiers (<bwtype> sub-field values) MUST be New bandwidth specifiers (<bwtype> sub-field values) MUST be
registered with IANA. The submission MUST reference a standards- registered with IANA. The submission MUST reference a standards-
track RFC specifying the semantics of the bandwidth specifier track RFC specifying the semantics of the bandwidth specifier
precisely, and indicating when it should be used, and why the precisely, and indicating when it should be used, and why the
existing registered bandwidth specifiers do not suffice. existing registered bandwidth specifiers do not suffice.
IANA has registered the bandwidth specifiers "CT" and "AS" with The RFC MUST specify the Mux Category for this value as defined by
definitions as in Section 5.8 of this memo (these definitions update [I-D.ietf-mmusic-sdp-mux-attributes].
those in [RFC4566]).
8.2.5. Network Types ("nettype")
New network types (<nettype> sub-field values) MUST be registered
with IANA if SDP needs to be used in the context of non-Internet
environments. The registration is subject to the "RFC Required"
policy of [RFC8126]. Although these are not normally the preserve of
IANA, there may be circumstances when an Internet application needs
to interoperate with a non-Internet application, such as when
gatewaying an Internet telephone call into the Public Switched
Telephone Network (PSTN). The number of network types should be
small and should be rarely extended. A new network type cannot be
registered without registering at least one address type to be used
with that network type. A new network type registration MUST
reference an RFC that gives details of the network type and address
type(s) and specifies how and when they would be used.
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
definitions update those in [RFC4566]).
8.2.6. Address Types ("addrtype")
New address types ("addrtype") MUST be registered with IANA. The
registration is subject to the "RFC Required" policy 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 registered
network type or be submitted along with a network type registration.
A new address type registration MUST reference an RFC giving details
of the syntax of the address type. Address types are not expected to
be registered frequently.
Section 5.7 of this document gives new definitions of address types
"IP4" and "IP6". The registries are to be correspondingly updated by
IANA.
8.2.7. Registration Procedure
A specification document that defines new values for SDP "media",
"proto", "bwtype", "nettype", and "addrtype" parameters MUST include
the following information:
o contact name;
o contact email address;
o name being defined (as it will appear in SDP);
o type of name ("media", "proto", "bwtype", "nettype", or The format of the "bwtype" registry is:
"addrtype");
o a description of the purpose of the defined name; --------------------------------------------------
| Type | SDP Name | Mux Category | Reference |
--------------------------------------------------
o a stable reference to the document containing this information and IANA is requested to update the "bwtype" registry entries for the
the definition of the value. (This will typically be an RFC bandwidth specifiers "CT" and "AS" with the definitions in
number.) Section 5.8 of this memo (these definitions replace those in
[RFC4566]).
IANA will populate its registries with some or all of these values. 8.2.6. Network Types ("nettype")
8.3. Encryption Key Access Methods Network type "IN", representing the Internet, is defined in
Section 5.2 and Section 5.7 of this memo. (This definition replaces
that in [RFC4566].)
To enable SDP to reference a new non-Internet environment a new
network type (<nettype> sub-field value) MUST be registered with
IANA. The registration is subject to the "RFC Required" policy of
[RFC8126]. Although non-Internet environments are not normally the
preserve of IANA, there may be circumstances when an Internet
application needs to interoperate with a non-Internet application,
such as when gatewaying an Internet telephone call into the Public
Switched Telephone Network (PSTN). The number of network types
should be small and should be rarely extended. A new network type
registration MUST reference an RFC that gives details of the network
type and the address type(s) that may be used with it.
The IANA previously maintained a table of SDP encryption key access The format of the "nettype" registry is:
method ("enckey") names. This table is obsolete, since the "k=" line
is not extensible. New registrations MUST NOT be accepted.
8.4. Reorganization of the nettype and addrtype registries --------------------------------------------------------------------
|Type | SDP Name | Usable addrtype Values | Reference |
--------------------------------------------------------------------
This document adds a new column in the "nettype" registry with the IANA is requested to update the "nettype" registry to this new
title "Usable addrtype Values", replacing the separate "addrtype" format. The following is the updated content of th registry:
registry. The following is the revised "nettype" registry:
-------------------------------------------------------------------- --------------------------------------------------------------------
|Type | SDP Name | Usable addrtype Values | Reference | |Type | SDP Name | Usable addrtype Values | Reference |
-------------------------------------------------------------------- --------------------------------------------------------------------
|nettype | IN | IP4, IP6 | [RFCXXXX] | |nettype | IN | IP4, IP6 | [RFCXXXX] |
|nettype | TN | RFC2543 | [RFC2848] | |nettype | TN | RFC2543 | [RFC2848] |
|nettype | ATM | NSAP, GWID, E164 | [RFC3108] | |nettype | ATM | NSAP, GWID, E164 | [RFC3108] |
|nettype | PSTN | E164 | [RFC7195] | |nettype | PSTN | E164 | [RFC7195] |
-------------------------------------------------------------------- --------------------------------------------------------------------
Note that both [RFC7195] and [RFC3108] registered "E164" as an Note that both [RFC7195] and [RFC3108] registered "E164" as an
address type, although [RFC7195] mentions that the "E164" address address type, although [RFC7195] mentions that the "E164" address
type has a different context for ATM and PSTN networks. type has a different context for ATM and PSTN networks.
8.5. Reorganization of the att-field Registries 8.2.7. Address Types ("addrtype")
This document combines all of the (currently) five "att-field"
registries into one registry called "att-field" registry, and updates
the columns to reflect the name, usage level(s), charset dependency
and reference. As such IANA is requested to create a new combined
registry using the following columns:
| | Dependent | Mux | | New address types ("addrtype") MUST be registered with IANA. The
Name | Usage Level | on Charset? | Category | Reference | registration is subject to the "RFC Required" policy of [RFC8126]. A
new address type registration MUST reference an RFC giving details of
the syntax of the address type. Address types are not expected to be
registered frequently.
The "Name" column reflects the attribute name (as it will appear in Section 5.7 of this document gives new definitions of address types
the SDP). The "Usage Level" column MUST indicate one or more of the "IP4" and "IP6".
following: session, media, source, dcsa and dcsa(subprotocol). The
"Dependent on Charset?" column MUST indicate "Yes" or "No" depending
on whether the attribute value is subject to the charset attribute.
The "Mux Category" column MUST indicate one of the following
categories: NORMAL, NOT RECOMMENDED, IDENTICAL, SUM, TRANSPORT,
INHERIT, IDENTICAL-PER-PT, SPECIAL or TBD as defined by
[I-D.ietf-mmusic-sdp-mux-attributes]. Finally, the "Reference"
column indicates the specification(s) where the attribute is defined.
For example, the attribute "setup" which is defined for both session 8.3. Encryption Key Access Methods (OBSOLETE)
and media level, will be listed in the new registry as follows:
| | Dependent | Mux | | The IANA previously maintained a table of SDP encryption key access
Name | Usage Level | on Charset? | Category | Reference | method ("enckey") names. This table is obsolete, since the "k=" line
------|----------------|-------------|----------|----------------| is not extensible. New registrations MUST NOT be accepted.
setup | session,media, | No |IDENTICAL | [RFC4145] |
| dcsa,dcsa(msrp)| | | [RFC6135] |
| | | | [I-D.mmusic- |
| | | | msrp-usage- |
| | | | data-channel] |
9. SDP Grammar 9. SDP Grammar
This section provides an Augmented BNF grammar for SDP. ABNF is This section provides an Augmented BNF grammar for SDP. ABNF is
defined in [RFC5234] and [RFC7405]. defined in [RFC5234] and [RFC7405].
; SDP Syntax ; SDP Syntax
session-description = version-field session-description = version-field
origin-field origin-field
session-name-field session-name-field
skipping to change at page 55, line 25 skipping to change at page 56, line 25
widespread use. widespread use.
o Changed the way <fmt> values for UDP transport are registered. o Changed the way <fmt> values for UDP transport are registered.
o Changed the mechanism and documentation required for registering o Changed the mechanism and documentation required for registering
new attributes. new attributes.
o Tightened up IANA registration procedures for extensions. Removed o Tightened up IANA registration procedures for extensions. Removed
phone number and long-form name. phone number and long-form name.
o Reorganized the IANA nettype registry o Expanded the IANA nettype registry to identify valid addrtypes.
o Reorganized the several IANA att-type registries into a single o Reorganized the several IANA att-type registries into a single
registry registry
o Revised ABNF syntax for clarity. Backward compatibility is o Revised ABNF syntax for clarity. Backward compatibility is
maintained with a few exceptions: maintained with a few exceptions:
* Revised the syntax of time descriptions ("t=", "r=", "z=") to * Revised the syntax of time descriptions ("t=", "r=", "z=") to
remove ambiguities. Clarified that "z=" only modifies the remove ambiguities. Clarified that "z=" only modifies the
immediately preceding "r=" lines. Made "z=" without a immediately preceding "r=" lines. Made "z=" without a
skipping to change at page 59, line 8 skipping to change at page 60, line 8
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-mmusic-ice-sip-sdp] [I-D.ietf-mmusic-ice-sip-sdp]
Petit-Huguenin, M., Nandakumar, S., and A. Keranen, Petit-Huguenin, M., Nandakumar, S., Keranen, A., Shpount,
"Session Description Protocol (SDP) Offer/Answer R., and C. Holmberg, "Session Description Protocol (SDP)
procedures for Interactive Connectivity Establishment Offer/Answer procedures for Interactive Connectivity
(ICE)", draft-ietf-mmusic-ice-sip-sdp-36 (work in Establishment (ICE)", draft-ietf-mmusic-ice-sip-sdp-38
progress), June 2019. (work in progress), August 2019.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-54 (work in progress), December 2018. negotiation-54 (work in progress), December 2018.
[ITU.H332.1998] [ITU.H332.1998]
International Telecommunication Union, "H.323 extended for International Telecommunication Union, "H.323 extended for
loosely coupled conferences", ITU Recommendation H.332, loosely coupled conferences", ITU Recommendation H.332,
 End of changes. 50 change blocks. 
170 lines changed or deleted 198 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/