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.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |