rfc8866v1.txt | rfc8866.txt | |||
---|---|---|---|---|
Internet Engineering Task Force (IETF) A. Begen | Internet Engineering Task Force (IETF) A. Begen | |||
Request for Comments: 8866 Networked Media | Request for Comments: 8866 Networked Media | |||
Obsoletes: 4566 P. Kyzivat | Obsoletes: 4566 P. Kyzivat | |||
Category: Standards Track | Category: Standards Track | |||
ISSN: 2070-1721 C. Perkins | ISSN: 2070-1721 C. Perkins | |||
University of Glasgow | University of Glasgow | |||
M. Handley | M. Handley | |||
UCL | UCL | |||
July 2020 | September 2020 | |||
SDP: Session Description Protocol | SDP: Session Description Protocol | |||
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. | |||
skipping to change at line 116 ¶ | skipping to change at line 116 ¶ | |||
6.11. sdplang (SDP Language) | 6.11. sdplang (SDP Language) | |||
6.12. lang (Language) | 6.12. lang (Language) | |||
6.13. framerate (Frame Rate) | 6.13. framerate (Frame Rate) | |||
6.14. quality | 6.14. quality | |||
6.15. fmtp (Format Parameters) | 6.15. fmtp (Format Parameters) | |||
7. Security Considerations | 7. Security Considerations | |||
8. IANA Considerations | 8. IANA Considerations | |||
8.1. The "application/sdp" Media Type | 8.1. The "application/sdp" Media Type | |||
8.2. Registration of SDP Parameters with IANA | 8.2. Registration of SDP Parameters with IANA | |||
8.2.1. Registration Procedure | 8.2.1. Registration Procedure | |||
8.2.2. Media Types ("media") | 8.2.2. Media Types (<media>) | |||
8.2.3. Transport Protocols ("proto") | 8.2.3. Transport Protocols (<proto>) | |||
8.2.4. Attribute Names ("att-field") | 8.2.4. Attribute Names (<attribute-name>) | |||
8.2.5. Bandwidth Specifiers ("bwtype") | 8.2.5. Bandwidth Specifiers (<bwtype>) | |||
8.2.6. Network Types ("nettype") | 8.2.6. Network Types (<nettype>) | |||
8.2.7. Address Types ("addrtype") | 8.2.7. Address Types (<addrtype>) | |||
8.3. Encryption Key Access Methods (OBSOLETE) | 8.3. Encryption Key Access Methods (OBSOLETE) | |||
9. SDP Grammar | 9. SDP Grammar | |||
10. Summary of Changes from RFC 4566 | 10. Summary of Changes from RFC 4566 | |||
11. References | 11. References | |||
11.1. Normative References | 11.1. Normative References | |||
11.2. Informative References | 11.2. Informative References | |||
Acknowledgements | Acknowledgements | |||
Authors' Addresses | Authors' Addresses | |||
1. Introduction | 1. Introduction | |||
skipping to change at line 222 ¶ | skipping to change at line 222 ¶ | |||
Alternative means of conveying session descriptions include | Alternative means of conveying session descriptions include | |||
electronic mail and the World Wide Web (WWW). For both email and WWW | electronic mail and the World Wide Web (WWW). For both email and WWW | |||
distribution, the media type "application/sdp" is used. This enables | distribution, the media type "application/sdp" is used. This enables | |||
the automatic launching of applications for participation in the | the automatic launching of applications for participation in the | |||
session from the WWW client or mail reader in a standard manner. | session from the WWW client or mail reader in a standard manner. | |||
Note that descriptions of multicast sessions sent only via email or | Note that descriptions of multicast sessions sent only via email or | |||
the WWW do not have the property that the receiver of a session | the WWW do not have the property that the receiver of a session | |||
description can necessarily receive the session because the multicast | description can necessarily receive the session because the multicast | |||
sessions may be restricted in scope, and access to the WWW server or | sessions may be restricted in scope, and access to the WWW server or | |||
reception of email is possible outside this scope. | reception of email is possibly outside this scope. | |||
3.4. Multicast Session Announcement | 3.4. Multicast Session Announcement | |||
In order to assist the advertisement of multicast multimedia | In order to assist the advertisement of multicast multimedia | |||
conferences and other multicast sessions, and to communicate the | conferences and other multicast sessions, and to communicate the | |||
relevant session setup information to prospective participants, a | relevant session setup information to prospective participants, a | |||
distributed session directory may be used. An instance of such a | distributed session directory may be used. An instance of such a | |||
session directory periodically sends packets containing a description | session directory periodically sends packets containing a description | |||
of the session to a well-known multicast group. These advertisements | of the session to a well-known multicast group. These advertisements | |||
are received by other session directories such that potential remote | are received by other session directories such that potential remote | |||
skipping to change at line 352 ¶ | skipping to change at line 352 ¶ | |||
use of URIs to indicate remote resources is subject to the security | use of URIs to indicate remote resources is subject to the security | |||
considerations from [RFC3986].) | considerations from [RFC3986].) | |||
4.4. Internationalization | 4.4. Internationalization | |||
The SDP specification recommends the use of the ISO 10646 character | The SDP specification recommends the use of the ISO 10646 character | |||
set in the UTF-8 encoding [RFC3629] to allow many different languages | set in the UTF-8 encoding [RFC3629] to allow many different languages | |||
to be represented. However, to assist in compact representations, | to be represented. However, to assist in compact representations, | |||
SDP also allows other character sets such as [ISO.8859-1.1998] to be | SDP also allows other character sets such as [ISO.8859-1.1998] to be | |||
used when desired. Internationalization only applies to free-text | used when desired. Internationalization only applies to free-text | |||
sub-fields (session name and background information), and not to SDP | subfields (session name and background information), and not to SDP | |||
as a whole. | as a whole. | |||
5. SDP Specification | 5. SDP Specification | |||
An SDP description is denoted by the media type "application/sdp" | An SDP description is denoted by the media type "application/sdp" | |||
(See Section 8). | (See Section 8). | |||
An SDP description is entirely textual. SDP field names and | An SDP description is entirely textual. SDP field names and | |||
attribute names use only the US-ASCII subset of UTF-8 [RFC3629], but | attribute names use only the US-ASCII subset of UTF-8 [RFC3629], but | |||
textual fields and attribute values MAY use the full ISO 10646 | textual fields and attribute values MAY use the full ISO 10646 | |||
skipping to change at line 385 ¶ | skipping to change at line 385 ¶ | |||
with strict order and formatting rules so that most errors would | with strict order and formatting rules so that most errors would | |||
result in malformed session descriptions that could be detected | result in malformed session descriptions that could be detected | |||
easily and discarded. | easily and discarded. | |||
An SDP description consists of a number of lines of text of the form: | An SDP description consists of a number of lines of text of the form: | |||
<type>=<value> | <type>=<value> | |||
where <type> is exactly one case-significant character and <value> is | where <type> is exactly one case-significant character and <value> is | |||
structured text whose format depends on <type>. In general, <value> | structured text whose format depends on <type>. In general, <value> | |||
is either a number of sub-fields delimited by a single space | is either a number of subfields delimited by a single space character | |||
character or a free format string, and is case-significant unless a | or a free format string, and is case-significant unless a specific | |||
specific field defines otherwise. Whitespace separators are not used | field defines otherwise. Whitespace separators are not used on | |||
on either side of the "=" sign, however, the value can contain a | either side of the "=" sign, however, the value can contain a leading | |||
leading whitespace as part of its syntax, i.e., that whitespace is | whitespace as part of its syntax, i.e., that whitespace is part of | |||
part of the value. | the value. | |||
An SDP description MUST conform to the syntax defined in Section 9. | An SDP description MUST conform to the syntax defined in Section 9. | |||
The following is an overview of the syntax. | The following is an overview of the syntax. | |||
An SDP description consists of a session-level section followed by | An SDP description consists of a session-level section followed by | |||
zero or more media descriptions. The session-level section starts | zero or more media descriptions. The session-level section starts | |||
with a "v=" line and continues to the first media description (or the | with a "v=" line and continues to the first media description (or the | |||
end of the whole description, whichever comes first). Each media | end of the whole description, whichever comes first). Each media | |||
description starts with an "m=" line and continues to the next media | description starts with an "m=" line and continues to the next media | |||
description or the end of the whole session description, whichever | description or the end of the whole session description, whichever | |||
skipping to change at line 485 ¶ | skipping to change at line 485 ¶ | |||
m=audio 49180 RTP/AVP 0 | m=audio 49180 RTP/AVP 0 | |||
m=video 51372 RTP/AVP 99 | m=video 51372 RTP/AVP 99 | |||
c=IN IP6 2001:db8::2 | c=IN IP6 2001:db8::2 | |||
a=rtpmap:99 h263-1998/90000 | a=rtpmap:99 h263-1998/90000 | |||
Text-containing fields such as the session-name-field and | Text-containing fields such as the session-name-field and | |||
information-field are octet strings that may contain any octet with | information-field are octet strings that may contain any octet with | |||
the exceptions of 0x00 (Nul), 0x0a (ASCII newline), and 0x0d (ASCII | the exceptions of 0x00 (Nul), 0x0a (ASCII newline), and 0x0d (ASCII | |||
carriage return). The sequence CRLF (0x0d0a) is used to end a line, | carriage return). The sequence CRLF (0x0d0a) is used to end a line, | |||
although parsers SHOULD be tolerant and also accept lines terminated | although parsers SHOULD be tolerant and also accept lines terminated | |||
with a single newline character. If the "a=charset" attribute is not | with a single newline character. If the "a=charset:" attribute is | |||
present, these octet strings MUST be interpreted as containing | not present, these octet strings MUST be interpreted as containing | |||
ISO-10646 characters in UTF-8 encoding. When the "a=charset" | ISO-10646 characters in UTF-8 encoding. When the "a=charset:" | |||
attribute is present the session-name-field, information-field, and | attribute is present the session-name-field, information-field, and | |||
some attribute fields are interpreted according to the selected | some attribute fields are interpreted according to the selected | |||
character set. | character set. | |||
A session description can contain domain names in the "o=", "u=", | A session description can contain domain names in the "o=", "u=", | |||
"e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply | "e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply | |||
with [RFC1034] and [RFC1035]. Internationalized domain names (IDNs) | with [RFC1034] and [RFC1035]. Internationalized domain names (IDNs) | |||
MUST be represented using the ASCII Compatible Encoding (ACE) form | MUST be represented using the ASCII Compatible Encoding (ACE) form | |||
defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or | defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or | |||
any other encoding (this requirement is for compatibility with | any other encoding (this requirement is for compatibility with | |||
skipping to change at line 544 ¶ | skipping to change at line 544 ¶ | |||
<nettype> is a text string giving the type of network. Initially, | <nettype> is a text string giving the type of network. Initially, | |||
"IN" is defined to have the meaning "Internet", but other values | "IN" is defined to have the meaning "Internet", but other values | |||
MAY be registered in the future (see Section 8). | MAY be registered in the future (see Section 8). | |||
<addrtype> is a text string giving the type of the address that | <addrtype> is a text string giving the type of the address that | |||
follows. Initially, "IP4" and "IP6" are defined, but other values | follows. Initially, "IP4" and "IP6" are defined, but other values | |||
MAY be registered in the future (see Section 8). | MAY be registered in the future (see Section 8). | |||
<unicast-address> is an address of the machine from which the | <unicast-address> is an address of the machine from which the | |||
session was created. For an address type of IP4, this is either a | session was created. For an address type of "IP4", this is either | |||
fully qualified domain name of the machine or the dotted-decimal | a fully qualified domain name of the machine or the dotted-decimal | |||
representation of an IP version 4 address of the machine. For an | representation of an IP version 4 address of the machine. For an | |||
address type of IP6, this is either a fully qualified domain name | address type of "IP6", this is either a fully qualified domain | |||
of the machine or the address of the machine represented as | name of the machine or the address of the machine represented as | |||
specified in Section 4 of [RFC5952]. For both IP4 and IP6, the | specified in Section 4 of [RFC5952]. For both "IP4" and "IP6", | |||
fully qualified domain name is the form that SHOULD be given | the fully qualified domain name is the form that SHOULD be given | |||
unless this is unavailable, in which case a globally unique | unless this is unavailable, in which case a globally unique | |||
address MAY be substituted. | address MAY be substituted. | |||
In general, the "o=" line serves as a globally unique identifier for | In general, the "o=" line serves as a globally unique identifier for | |||
this version of the session description, and the sub-fields excepting | this version of the session description, and the subfields excepting | |||
the version, taken together identify the session irrespective of any | the version, taken together identify the session irrespective of any | |||
modifications. | modifications. | |||
For privacy reasons, it is sometimes desirable to obfuscate the | For privacy reasons, it is sometimes desirable to obfuscate the | |||
username and IP address of the session originator. If this is a | username and IP address of the session originator. If this is a | |||
concern, an arbitrary <username> and private <unicast-address> MAY be | concern, an arbitrary <username> and private <unicast-address> MAY be | |||
chosen to populate the "o=" line, provided that these are selected in | chosen to populate the "o=" line, provided that these are selected in | |||
a manner that does not affect the global uniqueness of the field. | a manner that does not affect the global uniqueness of the field. | |||
5.3. Session Name ("s=") | 5.3. Session Name ("s=") | |||
s=<session name> | s=<session name> | |||
The "s=" line (session-name-field) is the textual session name. | The "s=" line (session-name-field) is the textual session name. | |||
There MUST be one and only one "s=" line per session description. | There MUST be one and only one "s=" line per session description. | |||
The "s=" line MUST NOT be empty. If a session has no meaningful | The "s=" line MUST NOT be empty. If a session has no meaningful | |||
name, then "s= " or "s=-" (i.e., a single space or dash as the | name, then "s= " or "s=-" (i.e., a single space or dash as the | |||
session name) is RECOMMENDED. If a session-level "a=charset" | session name) is RECOMMENDED. If a session-level "a=charset:" | |||
attribute is present, it specifies the character set used in the "s=" | attribute is present, it specifies the character set used in the "s=" | |||
field. If a session-level "a=charset" attribute is not present, the | field. If a session-level "a=charset:" attribute is not present, the | |||
"s=" field MUST contain ISO 10646 characters in UTF-8 encoding. | "s=" field MUST contain ISO 10646 characters in UTF-8 encoding. | |||
5.4. Session Information ("i=") | 5.4. Session Information ("i=") | |||
i=<session information> | i=<session information> | |||
The "i=" line (information-field) provides textual information about | The "i=" line (information-field) provides textual information about | |||
the session. There can be at most one session-level "i=" line per | the session. There can be at most one session-level "i=" line per | |||
session description, and at most one "i=" line in each media | session description, and at most one "i=" line in each media | |||
description. Unless a media-level "i=" line is provided, the | description. Unless a media-level "i=" line is provided, the | |||
session-level "i=" line applies to that media description. If the | session-level "i=" line applies to that media description. If the | |||
"a=charset" attribute is present, it specifies the character set used | "a=charset:" attribute is present, it specifies the character set | |||
in the "i=" line. If the "a=charset" attribute is not present, the | used in the "i=" line. If the "a=charset:" attribute is not present, | |||
"i=" line MUST contain ISO 10646 characters in UTF-8 encoding. | the "i=" line MUST contain ISO 10646 characters in UTF-8 encoding. | |||
At most one "i=" line can be used for each media description. In | At most one "i=" line can be used for each media description. In | |||
media definitions, "i=" lines are primarily intended for labeling | media definitions, "i=" lines are primarily intended for labeling | |||
media streams. As such, they are most likely to be useful when a | media streams. As such, they are most likely to be useful when a | |||
single session has more than one distinct media stream of the same | single session has more than one distinct media stream of the same | |||
media type. An example would be two different whiteboards, one for | media type. An example would be two different whiteboards, one for | |||
slides and one for feedback and questions. | slides and one for feedback and questions. | |||
The "i=" line is intended to provide a free-form human-readable | The "i=" line is intended to provide a free-form human-readable | |||
description of the session or the purpose of a media stream. It is | description of the session or the purpose of a media stream. It is | |||
skipping to change at line 648 ¶ | skipping to change at line 648 ¶ | |||
e=j.doe@example.com (Jane Doe) | e=j.doe@example.com (Jane Doe) | |||
The alternative [RFC5322] name quoting convention is also allowed for | The alternative [RFC5322] name quoting convention is also allowed for | |||
both email addresses and phone numbers. For example: | both email addresses and phone numbers. For example: | |||
e=Jane Doe <j.doe@example.com> | e=Jane Doe <j.doe@example.com> | |||
The free text string SHOULD be in the ISO-10646 character set with | The free text string SHOULD be in the ISO-10646 character set with | |||
UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if | UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if | |||
the appropriate session-level "a=charset" attribute is set. | the appropriate session-level "a=charset:" attribute is set. | |||
5.7. Connection Information ("c=") | 5.7. Connection Information ("c=") | |||
c=<nettype> <addrtype> <connection-address> | c=<nettype> <addrtype> <connection-address> | |||
The "c=" line (connection-field) contains information necessary to | The "c=" line (connection-field) contains information necessary to | |||
establish a network connection. | establish a network connection. | |||
A session description MUST contain either at least one "c=" line in | A session description MUST contain either at least one "c=" line in | |||
each media description or a single "c=" line at the session level. | each media description or a single "c=" line at the session level. | |||
It MAY contain a single session-level "c=" line and additional media- | It MAY contain a single session-level "c=" line and additional media- | |||
level "c=" line(s) per-media-description, in which case the media- | level "c=" line(s) per-media-description, in which case the media- | |||
level values override the session-level settings for the respective | level values override the session-level settings for the respective | |||
media. | media. | |||
The first sub-field (<nettype>) is the network type, which is a text | The first subfield (<nettype>) is the network type, which is a text | |||
string giving the type of network. Initially, "IN" is defined to | string giving the type of network. Initially, "IN" is defined to | |||
have the meaning "Internet", but other values MAY be registered in | have the meaning "Internet", but other values MAY be registered in | |||
the future (see Section 8). | the future (see Section 8). | |||
The second sub-field (<addrtype>) is the address type. This allows | The second subfield (<addrtype>) is the address type. This allows | |||
SDP to be used for sessions that are not IP based. This memo only | SDP to be used for sessions that are not IP based. This memo only | |||
defines IP4 and IP6, but other values MAY be registered in the future | defines "IP4" and "IP6", but other values MAY be registered in the | |||
(see Section 8). | future (see Section 8). | |||
The third sub-field (<connection-address>) is the connection address. | The third subfield (<connection-address>) is the connection address. | |||
Additional sub-fields MAY be added after the connection address | Additional subfields MAY be added after the connection address | |||
depending on the value of the <addrtype> sub-field. | depending on the value of the <addrtype> subfield. | |||
When the <addrtype> is IP4 or IP6, the connection address is defined | When the <addrtype> is "IP4" or "IP6", the connection address is | |||
as follows: | defined as follows: | |||
* If the session is multicast, the connection address will be an IP | * If the session is multicast, the connection address will be an IP | |||
multicast group address. If the session is not multicast, then | multicast group address. If the session is not multicast, then | |||
the connection address contains the unicast IP address of the | the connection address contains the unicast IP address of the | |||
expected data source, data relay, or data sink as determined by | expected data source, data relay, or data sink as determined by | |||
additional attribute-fields (Section 5.13). It is not expected | additional attribute-fields (Section 5.13). It is not expected | |||
that unicast addresses will be given in a session description that | that unicast addresses will be given in a session description that | |||
is communicated by a multicast announcement, though this is not | is communicated by a multicast announcement, though this is not | |||
prohibited. | prohibited. | |||
* Sessions using an IP4 multicast connection address MUST also have | * Sessions using an "IP4" multicast connection address MUST also | |||
a time to live (TTL) value present in addition to the multicast | have a time to live (TTL) value present in addition to the | |||
address. The TTL and the address together define the scope with | multicast address. The TTL and the address together define the | |||
which multicast packets sent in this session will be sent. TTL | scope with which multicast packets sent in this session will be | |||
values MUST be in the range 0-255. Although the TTL MUST be | sent. TTL values MUST be in the range 0-255. Although the TTL | |||
specified, its use to scope multicast traffic is deprecated; | MUST be specified, its use to scope multicast traffic is | |||
applications SHOULD use an administratively scoped address | deprecated; applications SHOULD use an administratively scoped | |||
instead. | address instead. | |||
The TTL for the session is appended to the address using a slash as a | The TTL for the session is appended to the address using a slash as a | |||
separator. An example is: | separator. An example is: | |||
c=IN IP4 233.252.0.1/127 | c=IN IP4 233.252.0.1/127 | |||
IP6 multicast does not use TTL scoping, and hence the TTL value MUST | "IP6" multicast does not use TTL scoping, and hence the TTL value | |||
NOT be present for IP6 multicast. It is expected that IPv6 scoped | MUST NOT be present for "IP6" multicast. It is expected that IPv6 | |||
addresses will be used to limit the scope of multimedia conferences. | scoped addresses will be used to limit the scope of multimedia | |||
conferences. | ||||
Hierarchical or layered encoding schemes are data streams where the | Hierarchical or layered encoding schemes are data streams where the | |||
encoding from a single media source is split into a number of layers. | encoding from a single media source is split into a number of layers. | |||
The receiver can choose the desired quality (and hence bandwidth) by | The receiver can choose the desired quality (and hence bandwidth) by | |||
only subscribing to a subset of these layers. Such layered encodings | only subscribing to a subset of these layers. Such layered encodings | |||
are normally transmitted in multiple multicast groups to allow | are normally transmitted in multiple multicast groups to allow | |||
multicast pruning. This technique keeps unwanted traffic from sites | multicast pruning. This technique keeps unwanted traffic from sites | |||
only requiring certain levels of the hierarchy. For applications | only requiring certain levels of the hierarchy. For applications | |||
requiring multiple multicast groups, we allow the following notation | requiring multiple multicast groups, we allow the following notation | |||
to be used for the connection address: | to be used for the connection address: | |||
skipping to change at line 744 ¶ | skipping to change at line 745 ¶ | |||
Similarly, an IPv6 example would be: | Similarly, an IPv6 example would be: | |||
c=IN IP6 ff00::db8:0:101/3 | c=IN IP6 ff00::db8:0:101/3 | |||
which is semantically equivalent to: | which is semantically equivalent to: | |||
c=IN IP6 ff00::db8:0:101 | c=IN IP6 ff00::db8:0:101 | |||
c=IN IP6 ff00::db8:0:102 | c=IN IP6 ff00::db8:0:102 | |||
c=IN IP6 ff00::db8:0:103 | c=IN IP6 ff00::db8:0:103 | |||
(remember that the TTL sub-field is not present in IP6 multicast). | (remember that the TTL subfield is not present in "IP6" multicast). | |||
Multiple addresses or "c=" lines MAY be specified on a per media | Multiple addresses or "c=" lines MAY be specified on a per media | |||
description basis only if they provide multicast addresses for | description basis only if they provide multicast addresses for | |||
different layers in a hierarchical or layered encoding scheme. | different layers in a hierarchical or layered encoding scheme. | |||
Multiple addresses or "c=" lines MUST NOT be specified at session | Multiple addresses or "c=" lines MUST NOT be specified at session | |||
level. | level. | |||
The slash notation for multiple addresses described above MUST NOT be | The slash notation for multiple addresses described above MUST NOT be | |||
used for IP unicast addresses. | used for IP unicast addresses. | |||
skipping to change at line 767 ¶ | skipping to change at line 768 ¶ | |||
b=<bwtype>:<bandwidth> | b=<bwtype>:<bandwidth> | |||
The OPTIONAL "b=" line (bandwidth-field) denotes the proposed | The OPTIONAL "b=" line (bandwidth-field) denotes the proposed | |||
bandwidth to be used by the session or media description. The | bandwidth to be used by the session or media description. The | |||
<bwtype> is an alphanumeric modifier that provides the meaning of the | <bwtype> is an alphanumeric modifier that provides the meaning of the | |||
<bandwidth> number. Two values are defined in this specification, | <bandwidth> number. Two values are defined in this specification, | |||
but other values MAY be registered in the future (see Section 8 and | but other values MAY be registered in the future (see Section 8 and | |||
[RFC3556], [RFC3890]): | [RFC3556], [RFC3890]): | |||
CT If the bandwidth of a session is different from the bandwidth | CT If the bandwidth of a session is different from the bandwidth | |||
implicit from the scope, a "b=CT:..." line SHOULD be supplied for | implicit from the scope, a "b=CT:" line SHOULD be supplied for the | |||
the session giving the proposed upper limit to the bandwidth used | session giving the proposed upper limit to the bandwidth used (the | |||
(the "conference total" bandwidth). Similarly, if the bandwidth | "conference total" bandwidth). Similarly, if the bandwidth of | |||
of bundled media streams [RFC8843] in an "m=" line is different | bundled media streams [RFC8843] in an "m=" line is different from | |||
from the implicit value from the scope, a "b=CT:..." line SHOULD | the implicit value from the scope, a "b=CT:" line SHOULD be | |||
be supplied in the media level. The primary purpose of this is to | supplied in the media level. The primary purpose of this is to | |||
give an approximate idea as to whether two or more sessions (or | give an approximate idea as to whether two or more sessions (or | |||
bundled media streams) can coexist simultaneously. Note that CT | bundled media streams) can coexist simultaneously. Note that a | |||
gives a total bandwidth figure for all the media at all endpoints. | "b=CT:" line gives a total bandwidth figure for all the media at | |||
all endpoints. | ||||
The Mux Category for CT is NORMAL. This is discussed in | The Mux Category for "b=CT:" is NORMAL. This is discussed in | |||
[RFC8859]. | [RFC8859]. | |||
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, the | |||
gives the RTP "session bandwidth" as defined in Section 6.2 of | "b=AS:" line gives the RTP "session bandwidth" as defined in | |||
[RFC3550]. Note that AS gives a bandwidth figure for a single | Section 6.2 of [RFC3550]. Note that a "b=AS:" line gives a | |||
media at a single endpoint, although there may be many endpoints | bandwidth figure for a single media at a single endpoint, although | |||
sending simultaneously. | there may be many endpoints sending simultaneously. | |||
The Mux Category for AS is SUM. This is discussed in [RFC8859]. | The Mux Category for "b=AS:" is SUM. This is discussed in | |||
[RFC8859]. | ||||
[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 | |||
skipping to change at line 828 ¶ | skipping to change at line 831 ¶ | |||
regular repeat times, a repeat description, begun by an "r=" line | regular repeat times, a repeat description, begun by an "r=" line | |||
(see Section 5.10) can be included following the time-field -- in | (see Section 5.10) can be included following the time-field -- in | |||
which case the time-field specifies the start and stop times of the | which case the time-field specifies the start and stop times of the | |||
entire repeat sequence. | entire repeat sequence. | |||
The following example specifies two active intervals: | The following example specifies two active intervals: | |||
t=3724394400 3724398000 ; Mon 8-Jan-2018 10:00-11:00 UTC | t=3724394400 3724398000 ; Mon 8-Jan-2018 10:00-11:00 UTC | |||
t=3724484400 3724488000 ; Tue 9-Jan-2018 11:00-12:00 UTC | t=3724484400 3724488000 ; Tue 9-Jan-2018 11:00-12:00 UTC | |||
The first and second sub-fields of the time-field give the start and | The first and second subfields of the time-field give the start and | |||
stop times, respectively, for the session. These are the decimal | stop times, respectively, for the session. These are the decimal | |||
representation of time values in seconds since January 1, 1900 UTC. | representation of time values in seconds since January 1, 1900 UTC. | |||
To convert these values to Unix time (UTC), subtract decimal | To convert these values to Unix time (UTC), subtract decimal | |||
2208988800. | 2208988800. | |||
Some time representations will wrap in the year 2036. Because SDP | Some time representations will wrap in the year 2036. Because SDP | |||
uses an arbitrary length decimal representation, it does not have | uses an arbitrary length decimal representation, it does not have | |||
this issue. Implementations of SDP need to be prepared to handle | this issue. Implementations of SDP need to be prepared to handle | |||
these larger values. | these larger values. | |||
skipping to change at line 852 ¶ | skipping to change at line 855 ¶ | |||
User interfaces SHOULD strongly discourage the creation of unbounded | User interfaces SHOULD strongly discourage the creation of unbounded | |||
and permanent sessions as they give no information about when the | and permanent sessions as they give no information about when the | |||
session is actually going to terminate, and so make scheduling | session is actually going to terminate, and so make scheduling | |||
difficult. | difficult. | |||
The general assumption may be made, when displaying unbounded | The general assumption may be made, when displaying unbounded | |||
sessions that have not timed out to the user, that an unbounded | sessions that have not timed out to the user, that an unbounded | |||
session will only be active until half an hour from the current time | session will only be active until half an hour from the current time | |||
or the session start time, whichever is the later. If behavior other | or the session start time, whichever is the later. If behavior other | |||
than this is required, an end-time SHOULD be given and modified as | than this is required, a <stop-time> SHOULD be given and modified as | |||
appropriate when new information becomes available about when the | appropriate when new information becomes available about when the | |||
session should really end. | session should really end. | |||
Permanent sessions may be shown to the user as never being active | Permanent sessions may be shown to the user as never being active | |||
unless there are associated repeat times that state precisely when | unless there are associated repeat times that state precisely when | |||
the session will be active. | the session will be active. | |||
5.10. Repeat Times ("r=") | 5.10. Repeat Times ("r=") | |||
r=<repeat interval> <active duration> <offsets from start-time> | r=<repeat interval> <active duration> <offsets from start-time> | |||
An"r=" line (repeat-field) specifies repeat times for a session. If | An"r=" line (repeat-field) specifies repeat times for a session. If | |||
needed to express complex schedules, multiple repeat-fields may be | needed to express complex schedules, multiple repeat-fields may be | |||
included. For example, if a session is active at 10am on Monday and | included. For example, if a session is active at 10am on Monday and | |||
11am on Tuesday for one hour each week for three months, then the | 11am on Tuesday for one hour each week for three months, then the | |||
<start-time> in the corresponding "t=" line would be the | <start-time> in the corresponding "t=" line would be the | |||
representation of 10am on the first Monday, the <repeat interval> | representation of 10am on the first Monday, the <repeat interval> | |||
would be 1 week, the <active duration> would be 1 hour, and the | would be 1 week, the <active duration> would be 1 hour, and the | |||
offsets would be zero and 25 hours. The corresponding "t=" line stop | offsets would be zero and 25 hours. The corresponding "t=" line stop | |||
time would be the representation of the end of the last session three | time would be the representation of the end of the last session three | |||
months later. By default, all sub-fields are in seconds, so the "r=" | months later. By default, all subfields are in seconds, so the "r=" | |||
and "t=" lines might be the following: | and "t=" lines might be the following: | |||
t=3724394400 3730536000 ; Mon 8-Jan-2018 10:00-11:00 UTC | t=3724394400 3730536000 ; Mon 8-Jan-2018 10:00-11:00 UTC | |||
; Tues 20-Mar-2018 12:00 UTC | ; Tues 20-Mar-2018 12:00 UTC | |||
r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours | r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours | |||
To make the description more compact, times may also be given in | To make the description more compact, times may also be given in | |||
units of days, hours, or minutes. The syntax for these is a number | units of days, hours, or minutes. The syntax for these is a number | |||
immediately followed by a single case-sensitive character. | immediately followed by a single case-sensitive character. | |||
Fractional units are not allowed -- a smaller unit should be used | Fractional units are not allowed -- a smaller unit should be used | |||
skipping to change at line 896 ¶ | skipping to change at line 899 ¶ | |||
+---+------------------------------------+ | +---+------------------------------------+ | |||
| d | days (86400 seconds) | | | d | days (86400 seconds) | | |||
+---+------------------------------------+ | +---+------------------------------------+ | |||
| h | hours (3600 seconds) | | | h | hours (3600 seconds) | | |||
+---+------------------------------------+ | +---+------------------------------------+ | |||
| m | minutes (60 seconds) | | | m | minutes (60 seconds) | | |||
+---+------------------------------------+ | +---+------------------------------------+ | |||
| s | seconds (allowed for completeness) | | | s | seconds (allowed for completeness) | | |||
+---+------------------------------------+ | +---+------------------------------------+ | |||
Table 1: Time unit specification | Table 1: Time Unit Specification | |||
characters | Characters | |||
Thus, the above repeat-field could also have been written: | Thus, the above repeat-field could also have been written: | |||
r=7d 1h 0 25h | r=7d 1h 0 25h | |||
Monthly and yearly repeats cannot be directly specified with a single | Monthly and yearly repeats cannot be directly specified with a single | |||
SDP repeat time; instead, separate time-descriptions should be used | SDP repeat time; instead, separate time-descriptions should be used | |||
to explicitly list the session times. | to explicitly list the session times. | |||
5.11. Time Zone Adjustment ("z=") | 5.11. Time Zone Adjustment ("z=") | |||
skipping to change at line 964 ¶ | skipping to change at line 967 ¶ | |||
k=<method> | k=<method> | |||
k=<method>:<encryption key> | k=<method>:<encryption key> | |||
The "k=" line (key-field) is obsolete and MUST NOT be used. It is | The "k=" line (key-field) is obsolete and MUST NOT be used. It is | |||
included in this document for legacy reasons. One MUST NOT include a | included in this document for legacy reasons. One MUST NOT include a | |||
"k=" line in an SDP, and MUST discard it if it is received in an SDP. | "k=" line in an SDP, and MUST discard it if it is received in an SDP. | |||
5.13. Attributes ("a=") | 5.13. Attributes ("a=") | |||
a=<attribute> | a=<attribute-name> | |||
a=<attribute>:<value> | a=<attribute-name>:<attribute-value> | |||
Attributes are the primary means for extending SDP. Attributes may | Attributes are the primary means for extending SDP. Attributes may | |||
be defined to be used as session-level attributes, media-level | be defined to be used as session-level attributes, media-level | |||
attributes, or both. (Attribute scopes in addition to media-level | attributes, or both. (Attribute scopes in addition to media-level | |||
and session-level scopes may also be defined in extensions to this | and session-level scopes may also be defined in extensions to this | |||
document, e.g., [RFC5576] and [RFC8864].) | document, e.g., [RFC5576] and [RFC8864].) | |||
A media description may contain any number of "a=" lines (attribute- | A media description may contain any number of "a=" lines (attribute- | |||
fields) that are media description specific. These are referred to | fields) that are media description specific. These are referred to | |||
as media-level attributes and add information about the media | as media-level attributes and add information about the media | |||
description. Attribute-fields can also be added before the first | description. Attribute-fields can also be added before the first | |||
media description; these session-level attributes convey additional | media description; these session-level attributes convey additional | |||
information that applies to the session as a whole rather than to | information that applies to the session as a whole rather than to | |||
individual media descriptions. | individual media descriptions. | |||
Attribute-fields may be of two forms: | Attribute-fields may be of two forms: | |||
* A property attribute is simply of the form "a=<attribute>". These | * A property attribute is simply of the form "a=<attribute-name>". | |||
are binary attributes, and the presence of the attribute conveys | These are binary attributes, and the presence of the attribute | |||
that the attribute is a property of the session. An example might | conveys that the attribute is a property of the session. An | |||
be "a=recvonly". | example might be "a=recvonly". | |||
* A value attribute is of the form "a=<attribute>:<value>". For | * A value attribute is of the form "a=<attribute-name>:<attribute- | |||
example, a whiteboard could have the value attribute | value>". For example, a whiteboard could have the value attribute | |||
"a=orient:landscape". | "a=orient:landscape". | |||
Attribute interpretation depends on the media tool being invoked. | Attribute interpretation depends on the media tool being invoked. | |||
Thus receivers of session descriptions should be configurable in | Thus receivers of session descriptions should be configurable in | |||
their interpretation of session descriptions in general and of | their interpretation of session descriptions in general and of | |||
attributes in particular. | attributes in particular. | |||
Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. | Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. | |||
Attribute values are octet strings, and MAY use any octet value | Attribute values are octet strings, and MAY use any octet value | |||
except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute | except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute | |||
values are to be interpreted as in ISO-10646 character set with UTF-8 | values are to be interpreted as in ISO-10646 character set with UTF-8 | |||
encoding. Unlike other text fields, attribute values are NOT | encoding. Unlike other text fields, attribute values are NOT | |||
normally affected by the "charset" attribute as this would make | normally affected by the "a=charset:" attribute as this would make | |||
comparisons against known values problematic. However, when an | comparisons against known values problematic. However, when an | |||
attribute is defined, it can be defined to be charset dependent, in | attribute is defined, it can be defined to be charset dependent, in | |||
which case its value should be interpreted in the session charset | which case its value should be interpreted in the session charset | |||
rather than in ISO-10646. | rather than in ISO-10646. | |||
Attributes MUST be registered with IANA (see Section 8). If an | Attributes MUST be registered with IANA (see Section 8). If an | |||
attribute is received that is not understood, it MUST be ignored by | attribute is received that is not understood, it MUST be ignored by | |||
the receiver. | the receiver. | |||
5.14. Media Descriptions ("m=") | 5.14. Media Descriptions ("m=") | |||
m=<media> <port> <proto> <fmt> ... | m=<media> <port> <proto> <fmt> ... | |||
A session description may contain a number of media descriptions. | A session description may contain a number of media descriptions. | |||
Each media description starts with an "m=" line (media-field) and is | Each media description starts with an "m=" line (media-field) and is | |||
terminated by either the next "m=" line or by the end of the session | terminated by either the next "m=" line or by the end of the session | |||
description. A media-field has several sub-fields: | description. A media-field has several subfields: | |||
<media> is the media type. This document defines the values | <media> is the media type. This document defines the values | |||
"audio", "video", "text", "application", and "message". This list | "audio", "video", "text", "application", and "message". This list | |||
is extended by other memos and may be further extended by | is extended by other memos and may be further extended by | |||
additional memos registering media types in the future (see | additional memos registering media types in the future (see | |||
Section 8). For example, [RFC6466] defined the "image" media | Section 8). For example, [RFC6466] defined the "image" media | |||
type. | type. | |||
<port> is the transport port to which the media stream is sent. The | <port> is the transport port to which the media stream is sent. The | |||
meaning of the transport port depends on the network being used as | meaning of the transport port depends on the network being used as | |||
specified in the relevant "c=" line, and on the transport protocol | specified in the relevant "c=" line, and on the transport protocol | |||
defined in the <proto> sub-field of the media-field. Other ports | defined in the <proto> subfield of the media-field. Other ports | |||
used by the media application (such as the RTP Control Protocol | used by the media application (such as the RTP Control Protocol | |||
(RTCP) port [RFC3550]) MAY be derived algorithmically from the | (RTCP) port [RFC3550]) MAY be derived algorithmically from the | |||
base media port or MAY be specified in a separate attribute (for | base media port or MAY be specified in a separate attribute (for | |||
example, "a=rtcp:" as defined in [RFC3605]). | example, the "a=rtcp:" attribute as defined in [RFC3605]). | |||
If noncontiguous ports are used or if they don't follow the parity | If noncontiguous ports are used or if they don't follow the parity | |||
rule of even RTP ports and odd RTCP ports, the "a=rtcp:" attribute | rule of even RTP ports and odd RTCP ports, the "a=rtcp:" attribute | |||
MUST be used. Applications that are requested to send media to a | MUST be used. Applications that are requested to send media to a | |||
<port> that is odd and where the "a=rtcp:" is present MUST NOT | <port> that is odd and where the "a=rtcp:" attribute is present | |||
subtract 1 from the RTP port: that is, they MUST send the RTP to | MUST NOT subtract 1 from the RTP port: that is, they MUST send the | |||
the port indicated in <port> and send the RTCP to the port | RTP to the port indicated in <port> and send the RTCP to the port | |||
indicated in the "a=rtcp" attribute. | indicated in the "a=rtcp:" attribute. | |||
For applications where hierarchically encoded streams are being | For applications where hierarchically encoded streams are being | |||
sent to a unicast address, it may be necessary to specify multiple | sent to a unicast address, it may be necessary to specify multiple | |||
transport ports. This is done using a similar notation to that | transport ports. This is done using a similar notation to that | |||
used for IP multicast addresses in the "c=" line: | used for IP multicast addresses in the "c=" line: | |||
m=<media> <port>/<number of ports> <proto> <fmt> ... | m=<media> <port>/<number of ports> <proto> <fmt> ... | |||
In such a case, the ports used depend on the transport protocol. | In such a case, the ports used depend on the transport protocol. | |||
For RTP, the default is that only the even-numbered ports are used | For RTP, the default is that only the even-numbered ports are used | |||
skipping to change at line 1069 ¶ | skipping to change at line 1072 ¶ | |||
m=video 49170/2 RTP/AVP 31 | m=video 49170/2 RTP/AVP 31 | |||
would specify that ports 49170 and 49171 form one RTP/RTCP pair, | would specify that ports 49170 and 49171 form one RTP/RTCP pair, | |||
and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the | and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the | |||
transport protocol, and 31 is the format (see the description of | transport protocol, and 31 is the format (see the description of | |||
<fmt> below). | <fmt> below). | |||
This document does not include a mechanism for declaring | This document does not include a mechanism for declaring | |||
hierarchically encoded streams using noncontiguous ports. (There | hierarchically encoded streams using noncontiguous ports. (There | |||
is currently no attribute defined that can accomplish this. The | is currently no attribute defined that can accomplish this. The | |||
"a=rtcp:" defined in [RFC3605] does not handle hierarchical | "a=rtcp:" attribute defined in [RFC3605] does not handle | |||
encoding.) If a need arises to declare noncontiguous ports then | hierarchical encoding.) If a need arises to declare noncontiguous | |||
it will be necessary to define a new attribute to do so. | ports then it will be necessary to define a new attribute to do | |||
so. | ||||
If multiple addresses are specified in the "c=" line and multiple | If multiple addresses are specified in the "c=" line and multiple | |||
ports are specified in the "m=" line, a one-to-one mapping from | ports are specified in the "m=" line, a one-to-one mapping from | |||
port to the corresponding address is implied. For example: | port to the corresponding address is implied. For example: | |||
m=video 49170/2 RTP/AVP 31 | m=video 49170/2 RTP/AVP 31 | |||
c=IN IP4 233.252.0.1/127/2 | c=IN IP4 233.252.0.1/127/2 | |||
would imply that address 233.252.0.1 is used with ports 49170 and | would imply that address 233.252.0.1 is used with ports 49170 and | |||
49171, and address 233.252.0.2 is used with ports 49172 and 49173. | 49171, and address 233.252.0.2 is used with ports 49172 and 49173. | |||
skipping to change at line 1101 ¶ | skipping to change at line 1105 ¶ | |||
and 49171, and address ff00::db8:0:102 is used with ports 49172 | and 49171, and address ff00::db8:0:102 is used with ports 49172 | |||
and 49173. | and 49173. | |||
This document gives no meaning to assigning the same media address | This document gives no meaning to assigning the same media address | |||
to multiple media descriptions. Doing so does not implicitly | to multiple media descriptions. Doing so does not implicitly | |||
group those media descriptions in any way. An explicit grouping | group those media descriptions in any way. An explicit grouping | |||
framework (for example, [RFC5888]) should instead be used to | framework (for example, [RFC5888]) should instead be used to | |||
express the intended semantics. For instance, see [RFC8843]. | express the intended semantics. For instance, see [RFC8843]. | |||
<proto> is the transport protocol. The meaning of the transport | <proto> is the transport protocol. The meaning of the transport | |||
protocol is dependent on the address type sub-field in the | protocol is dependent on the address type subfield in the relevant | |||
relevant "c=" line. Thus a "c=" line with an address type of IP4 | "c=" line. Thus a "c=" line with an address type of "IP4" | |||
indicates that the transport protocol runs over IPv4. The | indicates that the transport protocol runs over IPv4. The | |||
following transport protocols are defined, but may be extended | following transport protocols are defined, but may be extended | |||
through registration of new protocols with IANA (see Section 8): | through registration of new protocols with IANA (see Section 8): | |||
* udp: denotes that the data is transported directly in UDP with | * udp: denotes that the data is transported directly in UDP with | |||
no additional framing. | no additional framing. | |||
* RTP/AVP: denotes RTP [RFC3550] used under the RTP Profile for | * RTP/AVP: denotes RTP [RFC3550] used under the RTP Profile for | |||
Audio and Video Conferences with Minimal Control [RFC3551] | Audio and Video Conferences with Minimal Control [RFC3551] | |||
running over UDP. | running over UDP. | |||
* RTP/SAVP: denotes the Secure Real-time Transport Protocol | * RTP/SAVP: denotes the Secure Real-time Transport Protocol | |||
[RFC3711] running over UDP. | [RFC3711] running over UDP. | |||
* RTP/SAVPF: denotes SRTP with the Extended SRTP Profile for | ||||
RTCP-Based Feedback [RFC5124] running over UDP. | ||||
The main reason to specify the transport protocol in addition to | The main reason to specify the transport protocol in addition to | |||
the media format is that the same standard media formats may be | the media format is that the same standard media formats may be | |||
carried over different transport protocols even when the network | carried over different transport protocols even when the network | |||
protocol is the same -- a historical example is VAT (MBone's | protocol is the same -- a historical example is vat (MBone's | |||
popular multimedia audio tool) Pulse Code Modulation (PCM) audio | popular multimedia audio tool) Pulse Code Modulation (PCM) audio | |||
and RTP PCM audio; another might be TCP/RTP PCM audio. In | and RTP PCM audio; another might be TCP/RTP PCM audio. In | |||
addition, relays and monitoring tools that are transport-protocol- | addition, relays and monitoring tools that are transport-protocol- | |||
specific but format-independent are possible. | specific but format-independent are possible. | |||
<fmt> is a media format description. The fourth and any subsequent | <fmt> is a media format description. The fourth and any subsequent | |||
sub-fields describe the format of the media. The interpretation | subfields describe the format of the media. The interpretation of | |||
of the media format depends on the value of the <proto> sub-field. | the media format depends on the value of the <proto> subfield. | |||
If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP", the <fmt> | If the <proto> subfield is "RTP/AVP" or "RTP/SAVP", the <fmt> | |||
sub-fields contain RTP payload type numbers. When a list of | subfields contain RTP payload type numbers. When a list of | |||
payload type numbers is given, this implies that all of these | payload type numbers is given, this implies that all of these | |||
payload formats MAY be used in the session, but the first of these | payload formats MAY be used in the session, and these payload | |||
formats SHOULD be used as the default format for the session. For | formats are listed in order of preference, with the first format | |||
dynamic payload type assignments, the "a=rtpmap:" attribute (see | listed being preferred. When multiple payload formats are listed, | |||
Section 6) SHOULD be used to map from an RTP payload type number | the first acceptable payload format from the beginning of the list | |||
to a media encoding name that identifies the payload format. The | SHOULD be used for the session. For dynamic payload type | |||
"a=fmtp:" attribute MAY be used to specify format parameters (see | assignments, the "a=rtpmap:" attribute (see Section 6.6) SHOULD be | |||
Section 6). | used to map from an RTP payload type number to a media encoding | |||
name that identifies the payload format. The "a=fmtp:" attribute | ||||
MAY be used to specify format parameters (see Section 6.15). | ||||
If the <proto> sub-field is "udp", the <fmt> sub-fields MUST | If the <proto> subfield is "udp", the <fmt> subfields MUST | |||
reference a media type describing the format under the "audio", | reference a media type describing the format under the "audio", | |||
"video", "text", "application", or "message" top-level media | "video", "text", "application", or "message" top-level media | |||
types. The media type registration SHOULD define the packet | types. The media type registration SHOULD define the packet | |||
format for use with UDP transport. | format for use with UDP transport. | |||
For media using other transport protocols, the <fmt> sub-field is | For media using other transport protocols, the <fmt> subfield is | |||
protocol specific. Rules for interpretation of the <fmt> sub- | protocol specific. Rules for interpretation of the <fmt> subfield | |||
field MUST be defined when registering new protocols (see | MUST be defined when registering new protocols (see | |||
Section 8.2.2). | Section 8.2.2). | |||
Section 3 of [RFC4855] states that the payload format (encoding) | Section 3 of [RFC4855] states that the payload format (encoding) | |||
names defined in the RTP profile are commonly shown in upper case, | names defined in the RTP profile are commonly shown in upper case, | |||
while media subtype names are commonly shown in lower case. It | while media subtype names are commonly shown in lower case. It | |||
also states that both of these names are case-insensitive in both | also states that both of these names are case-insensitive in both | |||
places, similar to parameter names which are case-insensitive both | places, similar to parameter names which are case-insensitive both | |||
in media type strings and in the default mapping to the SDP | in media type strings and in the default mapping to the SDP | |||
"a=fmtp:" attribute. | "a=fmtp:" attribute. | |||
skipping to change at line 1212 ¶ | skipping to change at line 1221 ¶ | |||
Syntax: | Syntax: | |||
keywds-value = keywords | keywds-value = keywords | |||
keywords = text | keywords = text | |||
Example: | Example: | |||
a=keywds:SDP session description protocol | a=keywds:SDP session description protocol | |||
Like the "cat" attribute, this was intended to assist identifying | Like the "a=cat:" attribute, this was intended to assist identifying | |||
wanted sessions at the receiver, and to allow a receiver to select | wanted sessions at the receiver, and to allow a receiver to select | |||
interesting sessions based on keywords describing the purpose of the | interesting sessions based on keywords describing the purpose of the | |||
session; however, there is no central registry of keywords. Its | session; however, there is no central registry of keywords. Its | |||
value should be interpreted in the charset specified for the session | value should be interpreted in the charset specified for the session | |||
description if one is specified, or by default in ISO 10646/UTF-8. | description if one is specified, or by default in ISO 10646/UTF-8. | |||
This attribute is obsolete and SHOULD NOT be used. It SHOULD be | This attribute is obsolete and SHOULD NOT be used. It SHOULD be | |||
ignored if received. | ignored if received. | |||
6.3. tool | 6.3. tool | |||
skipping to change at line 1264 ¶ | skipping to change at line 1273 ¶ | |||
ptime-value = non-zero-int-or-real | ptime-value = non-zero-int-or-real | |||
Example: | Example: | |||
a=ptime:20 | a=ptime:20 | |||
This gives the length of time in milliseconds represented by the | This gives the length of time in milliseconds represented by the | |||
media in a packet. This is probably only meaningful for audio data, | media in a packet. This is probably only meaningful for audio data, | |||
but may be used with other media types if it makes sense. It should | but may be used with other media types if it makes sense. It should | |||
not be necessary to know ptime to decode RTP or VAT audio, and it is | not be necessary to know "a=ptime:" to decode RTP or vat audio, and | |||
intended as a recommendation for the encoding/packetization of audio. | it is intended as a recommendation for the encoding/packetization of | |||
audio. | ||||
6.5. maxptime (Maximum Packet Time) | 6.5. maxptime (Maximum Packet Time) | |||
Name: maxptime | Name: maxptime | |||
Value: maxptime-value | Value: maxptime-value | |||
Usage Level: media | Usage Level: media | |||
Charset Dependent: no | Charset Dependent: no | |||
skipping to change at line 1340 ¶ | skipping to change at line 1350 ¶ | |||
m=audio 49232 RTP/AVP 0 | m=audio 49232 RTP/AVP 0 | |||
An example of a dynamic payload type is 16-bit linear encoded stereo | An example of a dynamic payload type is 16-bit linear encoded stereo | |||
audio sampled at 16 kHz. If we wish to use the dynamic RTP/AVP | audio sampled at 16 kHz. If we wish to use the dynamic RTP/AVP | |||
payload type 98 for this stream, additional information is required | payload type 98 for this stream, additional information is required | |||
to decode it: | to decode it: | |||
m=audio 49232 RTP/AVP 98 | m=audio 49232 RTP/AVP 98 | |||
a=rtpmap:98 L16/16000/2 | a=rtpmap:98 L16/16000/2 | |||
Up to one rtpmap attribute can be defined for each media format | Up to one "a=rtpmap:" attribute can be defined for each media format | |||
specified. Thus, we might have the following: | specified. Thus, we might have the following: | |||
m=audio 49230 RTP/AVP 96 97 98 | m=audio 49230 RTP/AVP 96 97 98 | |||
a=rtpmap:96 L8/8000 | a=rtpmap:96 L8/8000 | |||
a=rtpmap:97 L16/8000 | a=rtpmap:97 L16/8000 | |||
a=rtpmap:98 L16/11025/2 | a=rtpmap:98 L16/11025/2 | |||
RTP profiles that specify the use of dynamic payload types MUST | RTP profiles that specify the use of dynamic payload types MUST | |||
define the set of valid encoding names and/or a means to register | define the set of valid encoding names and/or a means to register | |||
encoding names if that profile is to be used with SDP. The "RTP/AVP" | encoding names if that profile is to be used with SDP. The "RTP/AVP" | |||
skipping to change at line 1372 ¶ | skipping to change at line 1382 ¶ | |||
Additional encoding parameters MAY be defined in the future, but | Additional encoding parameters MAY be defined in the future, but | |||
codec-specific parameters SHOULD NOT be added. Parameters added to | codec-specific parameters SHOULD NOT be added. Parameters added to | |||
an "a=rtpmap:" attribute SHOULD only be those required for a session | an "a=rtpmap:" attribute SHOULD only be those required for a session | |||
directory to make the choice of appropriate media to participate in a | directory to make the choice of appropriate media to participate in a | |||
session. Codec-specific parameters should be added in other | session. Codec-specific parameters should be added in other | |||
attributes (for example, "a=fmtp:"). | attributes (for example, "a=fmtp:"). | |||
Note: RTP audio formats typically do not include information about | Note: RTP audio formats typically do not include information about | |||
the number of samples per packet. If a non-default (as defined in | the number of samples per packet. If a non-default (as defined in | |||
the RTP Audio/Video Profile [RFC3551]) packetization is required, the | the RTP Audio/Video Profile [RFC3551]) packetization is required, the | |||
"ptime" attribute is used as given in Section 6.4. | "a=ptime:" attribute is used as given in Section 6.4. | |||
6.7. Media Direction Attributes | 6.7. Media Direction Attributes | |||
At most one occurrence of recvonly, sendrecv, sendonly, or inactive | At most one occurrence of "a=recvonly", "a=sendrecv", "a=sendonly", | |||
MAY appear at session level, and at most one MAY appear in each media | or "a=inactive" MAY appear at session level, and at most one MAY | |||
description. | appear in each media description. | |||
If any one of these appears in a media description, then it applies | If any one of these appears in a media description, then it applies | |||
for that media description. If none appears in a media description, | for that media description. If none appears in a media description, | |||
then the one from session level, if any, applies to that media | then the one from session level, if any, applies to that media | |||
description. | description. | |||
If none of the media direction attributes is present at either | If none of the media direction attributes is present at either | |||
session level or media level, "sendrecv" SHOULD be assumed as the | session level or media level, "a=sendrecv" SHOULD be assumed as the | |||
default. | default. | |||
Within the following SDP example, the "sendrecv" attribute applies to | Within the following SDP example, the "a=sendrecv" attribute applies | |||
the first audio media and the "inactive" attribute applies to the | to the first audio media and the "a=inactive" attribute applies to | |||
others. | the others. | |||
v=0 | v=0 | |||
o=jdoe 3724395000 3724395001 IN IP6 2001:db8::1 | o=jdoe 3724395000 3724395001 IN IP6 2001:db8::1 | |||
s=- | s=- | |||
c=IN IP6 2001:db8::1 | c=IN IP6 2001:db8::1 | |||
t=0 0 | t=0 0 | |||
a=inactive | a=inactive | |||
m=audio 49170 RTP/AVP 0 | m=audio 49170 RTP/AVP 0 | |||
a=sendrecv | a=sendrecv | |||
m=audio 49180 RTP/AVP 0 | m=audio 49180 RTP/AVP 0 | |||
skipping to change at line 1420 ¶ | skipping to change at line 1430 ¶ | |||
Usage Level: session, media | Usage Level: session, media | |||
Charset Dependent: no | Charset Dependent: no | |||
Example: | Example: | |||
a=recvonly | a=recvonly | |||
This specifies that the tools should be started in receive-only mode | This specifies that the tools should be started in receive-only mode | |||
where applicable. Note that recvonly applies to the media only, not | where applicable. Note that receive-only mode applies to the media | |||
to any associated control protocol. An RTP-based system in recvonly | only, not to any associated control protocol. An RTP-based system in | |||
mode MUST still send RTCP packets as described in [RFC3550], | receive-only mode MUST still send RTCP packets as described in | |||
Section 6. | [RFC3550], Section 6. | |||
6.7.2. sendrecv (Send-Receive) | 6.7.2. sendrecv (Send-Receive) | |||
Name: sendrecv | Name: sendrecv | |||
Value: | Value: | |||
Usage Level: session, media | Usage Level: session, media | |||
Charset Dependent: no | Charset Dependent: no | |||
skipping to change at line 1460 ¶ | skipping to change at line 1470 ¶ | |||
Charset Dependent: no | Charset Dependent: no | |||
Example: | Example: | |||
a=sendonly | a=sendonly | |||
This specifies that the tools should be started in send-only mode. | This specifies that the tools should be started in send-only mode. | |||
An example may be where a different unicast address is to be used for | An example may be where a different unicast address is to be used for | |||
a traffic destination than for a traffic source. In such a case, two | a traffic destination than for a traffic source. In such a case, two | |||
media descriptions may be used, one sendonly and one recvonly. Note | media descriptions may be used, one in send-only mode and one in | |||
that sendonly applies only to the media, and any associated control | receive-vonly mode. Note that send-only mode applies only to the | |||
protocol (e.g., RTCP) SHOULD still be received and processed as | media, and any associated control protocol (e.g., RTCP) SHOULD still | |||
normal. | be received and processed as normal. | |||
6.7.4. inactive | 6.7.4. inactive | |||
Name: inactive | Name: inactive | |||
Value: | Value: | |||
Usage Level: session, media | Usage Level: session, media | |||
Charset Dependent: no | Charset Dependent: no | |||
Example: | Example: | |||
a=inactive | a=inactive | |||
This specifies that the tools should be started in inactive mode. | This specifies that the tools should be started in inactive mode. | |||
This is necessary for interactive multimedia conferences where users | This is necessary for interactive multimedia conferences where users | |||
can put other users on hold. No media is sent over an inactive media | can put other users on hold. No media is sent over an inactive media | |||
stream. Note that an RTP-based system MUST still send RTCP (if RTCP | stream. Note that an RTP-based system MUST still send RTCP (if RTCP | |||
is used), even if started inactive. | is used), even if started in inactive mode. | |||
6.8. orient (Orientation) | 6.8. orient (Orientation) | |||
Name: orient | Name: orient | |||
Value: orient-value | Value: orient-value | |||
Usage Level: media | Usage Level: media | |||
Charset Dependent: no | Charset Dependent: no | |||
skipping to change at line 1617 ¶ | skipping to change at line 1627 ¶ | |||
Syntax: | Syntax: | |||
sdplang-value = Language-Tag | sdplang-value = Language-Tag | |||
; Language-Tag defined in RFC 5646 | ; Language-Tag defined in RFC 5646 | |||
Example: | Example: | |||
a=sdplang:fr | a=sdplang:fr | |||
Multiple sdplang attributes can be provided either at session or | Multiple "a=sdplang:" attributes can be provided either at session or | |||
media level if the session description or media use multiple | media level if the session description or media use multiple | |||
languages. | languages. | |||
As a session-level attribute, it specifies the language for the | As a session-level attribute, it specifies the language for the | |||
session description (not the language of the media). As a media- | session description (not the language of the media). As a media- | |||
level attribute, it specifies the language for any media-level SDP | level attribute, it specifies the language for any media-level SDP | |||
information-field associated with that media (again not the language | information-field associated with that media (again not the language | |||
of the media), overriding any sdplang attributes specified at session | of the media), overriding any "a=sdplang:" attributes specified at | |||
level. | session level. | |||
In general, sending session descriptions consisting of multiple | In general, sending session descriptions consisting of multiple | |||
languages is discouraged. Instead, multiple session descriptions | languages is discouraged. Instead, multiple session descriptions | |||
SHOULD be sent describing the session, one in each language. | SHOULD be sent describing the session, one in each language. | |||
However, this is not possible with all transport mechanisms, and so | However, this is not possible with all transport mechanisms, and so | |||
multiple sdplang attributes are allowed although NOT RECOMMENDED. | multiple "a=sdplang:" attributes are allowed although NOT | |||
RECOMMENDED. | ||||
The "sdplang" attribute value must be a single language tag | The "a=sdplang:" attribute value must be a single language tag | |||
[RFC5646]. An "sdplang" attribute SHOULD be specified when a session | [RFC5646]. An "a=sdplang:" attribute SHOULD be specified when a | |||
is distributed with sufficient scope to cross geographic boundaries, | session is distributed with sufficient scope to cross geographic | |||
where the language of recipients cannot be assumed, or where the | boundaries, where the language of recipients cannot be assumed, or | |||
session is in a different language from the locally assumed norm. | where the session is in a different language from the locally assumed | |||
norm. | ||||
6.12. lang (Language) | 6.12. lang (Language) | |||
Name: lang | Name: lang | |||
Value: lang-value | Value: lang-value | |||
Usage Level: session, media | Usage Level: session, media | |||
Charset Dependent: no | Charset Dependent: no | |||
Syntax: | Syntax: | |||
lang-value = Language-Tag | lang-value = Language-Tag | |||
; Language-Tag defined in RFC 5646 | ; Language-Tag defined in RFC 5646 | |||
Example: | Example: | |||
a=lang:de | a=lang:de | |||
Multiple lang attributes can be provided either at session or media | Multiple "a=lang:" attributes can be provided either at session or | |||
level if the session or media has capabilities in more than one | media level if the session or media has capabilities in more than one | |||
language, in which case the order of the attributes indicates the | language, in which case the order of the attributes indicates the | |||
order of preference of the various languages in the session or media, | order of preference of the various languages in the session or media, | |||
from most preferred to least preferred. | from most preferred to least preferred. | |||
As a session-level attribute, lang specifies a language capability | As a session-level attribute, "a=lang:" specifies a language | |||
for the session being described. As a media-level attribute, it | capability for the session being described. As a media-level | |||
specifies a language capability for that media, overriding any | attribute, it specifies a language capability for that media, | |||
session-level language(s) specified. | overriding any session-level language(s) specified. | |||
The "lang" attribute value must be a single [RFC5646] language tag. | The "a=lang:" attribute value must be a single [RFC5646] language | |||
A "lang" attribute SHOULD be specified when a session is of | tag. An "a=lang:" attribute SHOULD be specified when a session is of | |||
sufficient scope to cross geographic boundaries where the language of | sufficient scope to cross geographic boundaries where the language of | |||
participants cannot be assumed, or where the session has capabilities | participants cannot be assumed, or where the session has capabilities | |||
in languages different from the locally assumed norm. | in languages different from the locally assumed norm. | |||
The "lang" attribute is supposed to be used for setting the initial | The "a=lang:" attribute is supposed to be used for setting the | |||
language(s) used in the session. Events during the session may | initial language(s) used in the session. Events during the session | |||
influence which language(s) are used, and the participants are not | may influence which language(s) are used, and the participants are | |||
strictly bound to only use the declared languages. | not strictly bound to only use the declared languages. | |||
Most real-time use cases start with just one language used, while | Most real-time use cases start with just one language used, while | |||
other cases involve a range of languages, e.g., an interpreted or | other cases involve a range of languages, e.g., an interpreted or | |||
subtitled session. When more than one "lang" attribute is specified, | subtitled session. When more than one "a=lang:" attribute is | |||
the "lang" attribute itself does not provide any information about | specified, the "a=lang:" attribute itself does not provide any | |||
multiple languages being intended to be used during the session, or | information about multiple languages being intended to be used during | |||
if the intention is to only select one of the languages. If needed, | the session, or if the intention is to only select one of the | |||
a new attribute can be defined and used to indicate such intentions. | languages. If needed, a new attribute can be defined and used to | |||
Without such semantics, it is assumed that for a negotiated session | indicate such intentions. Without such semantics, it is assumed that | |||
one of the declared languages will be selected and used. | for a negotiated session one of the declared languages will be | |||
selected and used. | ||||
6.13. framerate (Frame Rate) | 6.13. framerate (Frame Rate) | |||
Name: framerate | Name: framerate | |||
Value: framerate-value | Value: framerate-value | |||
Usage Level: media | Usage Level: media | |||
Charset Dependent: no | Charset Dependent: no | |||
skipping to change at line 1749 ¶ | skipping to change at line 1762 ¶ | |||
| 10 | the best still-image quality the | | | 10 | the best still-image quality the | | |||
| | compression scheme can give. | | | | compression scheme can give. | | |||
+----+----------------------------------------+ | +----+----------------------------------------+ | |||
| 5 | the default behavior given no quality | | | 5 | the default behavior given no quality | | |||
| | suggestion. | | | | suggestion. | | |||
+----+----------------------------------------+ | +----+----------------------------------------+ | |||
| 0 | the worst still-image quality the | | | 0 | the worst still-image quality the | | |||
| | codec designer thinks is still usable. | | | | codec designer thinks is still usable. | | |||
+----+----------------------------------------+ | +----+----------------------------------------+ | |||
Table 2: Encoding quality values | Table 2: Encoding Quality Values | |||
6.15. fmtp (Format Parameters) | 6.15. fmtp (Format Parameters) | |||
Name: fmtp | Name: fmtp | |||
Value: fmtp-value | Value: fmtp-value | |||
Usage Level: media | Usage Level: media | |||
Charset Dependent: no | Charset Dependent: no | |||
skipping to change at line 1781 ¶ | skipping to change at line 1794 ¶ | |||
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 | a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 | |||
This attribute allows parameters that are specific to a particular | This attribute allows parameters that are specific to a particular | |||
format to be conveyed in a way that SDP does not have to understand | format to be conveyed in a way that SDP does not have to understand | |||
them. The format must be one of the formats specified for the media. | them. The format must be one of the formats specified for the media. | |||
Format-specific parameters, semicolon separated, may be any set of | Format-specific parameters, semicolon separated, may be any set of | |||
parameters required to be conveyed by SDP and given unchanged to the | parameters required to be conveyed by SDP and given unchanged to the | |||
media tool that will use this format. At most one instance of this | media tool that will use this format. At most one instance of this | |||
attribute is allowed for each format. | attribute is allowed for each format. | |||
The fmtp attribute may be used to specify parameters for any protocol | The "a=fmtp:" attribute may be used to specify parameters for any | |||
and format that defines use of such parameters. | protocol and format that defines use of such parameters. | |||
7. Security Considerations | 7. Security Considerations | |||
SDP is frequently used with the Session Initiation Protocol [RFC3261] | SDP is frequently used with the Session Initiation Protocol [RFC3261] | |||
using the offer/answer model [RFC3264] to agree on parameters for | using the offer/answer model [RFC3264] to agree on parameters for | |||
unicast sessions. When used in this manner, the security | unicast sessions. When used in this manner, the security | |||
considerations of those protocols apply. | considerations of those protocols apply. | |||
SDP is a session description format that describes multimedia | SDP is a session description format that describes multimedia | |||
sessions. Entities receiving and acting upon an SDP message SHOULD | sessions. Entities receiving and acting upon an SDP message SHOULD | |||
skipping to change at line 1859 ¶ | skipping to change at line 1872 ¶ | |||
are NOT RECOMMENDED unless the session description is conveyed in | are NOT RECOMMENDED unless the session description is conveyed in | |||
such a manner that allows the intermediary system to conduct proper | such a manner that allows the intermediary system to conduct proper | |||
checks to establish the authenticity of the session description, and | checks to establish the authenticity of the session description, and | |||
the authority of its source to establish such communication sessions. | the authority of its source to establish such communication sessions. | |||
SDP by itself does not include sufficient information to enable these | SDP by itself does not include sufficient information to enable these | |||
checks: they depend on the encapsulating protocol (e.g., SIP or | checks: they depend on the encapsulating protocol (e.g., SIP or | |||
RTSP). The use of some procedures and SDP extensions (e.g., | RTSP). The use of some procedures and SDP extensions (e.g., | |||
Interactive Connectivity Establishment (ICE) [RFC8445] and ICE-SIP- | Interactive Connectivity Establishment (ICE) [RFC8445] and ICE-SIP- | |||
SDP [RFC8839]) may avoid the need for intermediaries to modify SDP. | SDP [RFC8839]) may avoid the need for intermediaries to modify SDP. | |||
SDP MUST NOT be used to convey keying material (e.g., using | SDP MUST NOT be used to convey keying material (e.g., using the | |||
"a=crypto" [RFC4568]) unless it can be guaranteed that the channel | "a=crypto:" attribute [RFC4568]) unless it can be guaranteed that the | |||
over which the SDP is delivered is both private and authenticated. | channel over which the SDP is delivered is both private and | |||
authenticated. | ||||
8. IANA Considerations | 8. IANA Considerations | |||
8.1. The "application/sdp" Media Type | 8.1. The "application/sdp" Media Type | |||
One media type registration from [RFC4566] is to be updated, as | One media type registration from [RFC4566] is to be updated, as | |||
defined below. | defined below. | |||
Type name: application | Type name: application | |||
skipping to change at line 1918 ¶ | skipping to change at line 1932 ¶ | |||
Restrictions on usage: None | Restrictions on usage: None | |||
Author/Change controller: | Author/Change controller: | |||
Authors of RFC 8866 | Authors of RFC 8866 | |||
IETF MMUSIC working group delegated from the IESG | IETF MMUSIC working group delegated from the IESG | |||
8.2. Registration of SDP Parameters with IANA | 8.2. Registration of SDP Parameters with IANA | |||
This document specifies IANA parameter registries for six named SDP | This document specifies IANA parameter registries for six named SDP | |||
sub-fields. Using the terminology in the SDP specification Augmented | subfields. Using the terminology in the SDP specification Augmented | |||
Backus-Naur Form (ABNF), they are "media", "proto", "att-field", | Backus-Naur Form (ABNF), they are <media>, <proto>, <attribute-name>, | |||
"bwtype", "nettype", and "addrtype". | <bwtype>, <nettype>, and <addrtype>. | |||
This document also replaces and updates the definitions of all those | This document also replaces and updates the definitions of all those | |||
parameters previously defined by [RFC4566]. | parameters previously defined by [RFC4566]. | |||
IANA: Please change all references to RFC4566 in these registries to | IANA: Please change all references to RFC4566 in these registries to | |||
instead refer to this document. | instead refer to this document. | |||
The contact name and email address for all parameters registered in | The contact name and email address for all parameters registered in | |||
this document is: | 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. | |||
All of these registries have a common format: | All of these registries have a common format: | |||
+======+==========+================+===========+ | +======+==========+================+===========+ | |||
| Type | SDP Name | [other fields] | Reference | | | Type | SDP Name | [other fields] | Reference | | |||
+======+==========+================+===========+ | +======+==========+================+===========+ | |||
Table 3: Common format for SDP registries | Table 3: Common Format for SDP Registries | |||
8.2.1. Registration Procedure | 8.2.1. Registration Procedure | |||
A specification document that defines values for SDP "media", | A specification document that defines values for SDP <media>, | |||
"proto", "att-field", "bwtype", "nettype", and "addrtype" parameters | <proto>, <attribute-name>, <bwtype>, <nettype>, and <addrtype> | |||
MUST include the following information: | parameters MUST include the following information: | |||
* Contact name | * Contact name | |||
* Contact email address | * Contact email address | |||
* Name being defined (as it will appear in SDP) | * Name being defined (as it will appear in SDP) | |||
* Type of name ("media", "proto", "bwtype", "nettype", or | * Type of name (<media>, <proto>, <bwtype>, <nettype>, or | |||
"addrtype") | <addrtype>) | |||
* A description of the purpose of the defined name | * A description of the purpose of the defined name | |||
* A stable reference to the document containing this information and | * A stable reference to the document containing this information and | |||
the definition of the value. (This will typically be an RFC | the definition of the value. (This will typically be an RFC | |||
number.) | number.) | |||
The subsections below specify what other information (if any) must be | The subsections below specify what other information (if any) must be | |||
specified for particular parameters, and what other fields are to be | specified for particular parameters, and what other fields are to be | |||
included in the registry. | included in the registry. | |||
8.2.2. Media Types ("media") | 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 well as for top-level media types, and where | apply for media names as well 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 line 1994 ¶ | skipping to change at line 2008 ¶ | |||
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.3. Transport Protocols ("proto") | 8.2.3. Transport Protocols (<proto>) | |||
The "proto" sub-field describes the transport protocol used. The | The <proto> subfield 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: | This document registers two values: | |||
* "RTP/AVP" is a reference to [RFC3550] used under the RTP Profile | * "RTP/AVP" is a reference to [RFC3550] used under the RTP Profile | |||
for Audio and Video Conferences with Minimal Control [RFC3551] | for Audio and Video Conferences with Minimal Control [RFC3551] | |||
running over UDP/IP. | running over UDP/IP. | |||
* "udp" indicates direct use of UDP. | * "udp" indicates direct use of UDP. | |||
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 RTP. For example, a profile | transport protocols that are profiles of RTP. For example, a profile | |||
whose short name is "XYZ" would be denoted by a "proto" sub-field of | whose short name is "XYZ" would be denoted by a <proto> subfield of | |||
"RTP/XYZ". | "RTP/XYZ". | |||
Each transport protocol, defined by the "proto" sub-field, has an | Each transport protocol, defined by the <proto> subfield, has an | |||
associated "fmt" namespace that describes the media formats that may | associated <fmt> namespace that describes the media formats that may | |||
be conveyed by that protocol. Formats cover all the possible | be conveyed by that protocol. Formats cover all the possible | |||
encodings that could be transported in a multimedia session. | encodings that could be transported in a multimedia session. | |||
RTP payload formats under the "RTP/AVP" and other "RTP/*" profiles | RTP payload formats under the "RTP/AVP" and other "RTP/*" profiles | |||
MUST use the payload type number as their "fmt" value. If the | MUST use the payload type number as their <fmt> value. If the | |||
payload type number is dynamically assigned by this session | payload type number is dynamically assigned by this session | |||
description, an additional "rtpmap" attribute MUST be included to | description, an additional "a=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, the allowed "fmt" values are media subtypes | For the "udp" protocol, the allowed <fmt> values are media subtypes | |||
from the IANA Media Types registry. The media type and subtype | from 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.4. Attribute Names ("att-field") | 8.2.4. Attribute Names (<attribute-name>) | |||
Attribute-field names ("att-field") MUST be registered with IANA and | Attribute-field names (<attribute-name>) MUST be registered with IANA | |||
documented to avoid any issues due to conflicting attribute | and documented to avoid any issues due to conflicting attribute | |||
definitions under the same name. (While unknown attributes in SDP | definitions under the same name. (While unknown attributes in SDP | |||
are simply ignored, 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: | The format of the <attribute-name> registry is: | |||
+======+==========+=============+==============+===========+ | +======+==========+=============+==============+===========+ | |||
| Type | SDP Name | Usage Level | Mux Category | Reference | | | Type | SDP Name | Usage Level | Mux Category | Reference | | |||
+======+==========+=============+==============+===========+ | +======+==========+=============+==============+===========+ | |||
Table 4: Format of the attribute registry | Table 4: Format of the <attribute-name> Registry | |||
For example, the attribute "setup", which is defined for both session | For example, the attribute "lang", which is defined for both session | |||
and media level, will be listed in the new registry as follows: | and media level, will be listed in the new registry as follows: | |||
+===========+=======+=============+===========+====================+ | +===========+======+==========+===========+========================+ | |||
| Type | SDP | Usage Level | Mux | Reference | | | Type | SDP | Usage | Mux | Reference | | |||
| | Name | | Category | | | | | Name | Level | Category | | | |||
+===========+=======+=============+===========+====================+ | +===========+======+==========+===========+========================+ | |||
| attribute | setup | session, | IDENTICAL | [RFC4145] | | | attribute | lang | session, | TRANSPORT | [RFC8866] [RFC8859] | | |||
| | | media, dcsa | | [RFC6135] | | | | | media | | | | |||
| | | (msrp) | | [MSRP-DATACHANNEL] | | +-----------+------+----------+-----------+------------------------+ | |||
+-----------+-------+-------------+-----------+--------------------+ | ||||
Table 5: Attribute registry example | Table 5: <attribute-name> Registry Example | |||
This one registry combines all of the previous usage-level-specific | This one <attribute-name> registry combines all of the previous | |||
"att-field" registries, including updates made by [RFC8859]. IANA is | usage-level-specific "att-field" registries, including updates made | |||
requested to do the necessary reformatting. | by [RFC8859]. IANA is requested to do the necessary reformatting. | |||
Section 6 of this document replaces the initial set of attribute | Section 6 of this document replaces the initial set of attribute | |||
definitions made by [RFC4566]. IANA is requested to update the | definitions made by [RFC4566]. IANA is requested to update the | |||
registry accordingly. | registry accordingly. | |||
Documents can define new attributes and can also extend the | Documents can define new attributes and can also extend the | |||
definitions of previously defined attributes. | definitions of previously defined attributes. | |||
8.2.4.1. New 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: | |||
* Contact name | * Contact name | |||
* Contact email address | * Contact email address | |||
* Attribute name: the name of the attribute that will appear in SDP. | * Attribute name: the name of the attribute that will appear in SDP. | |||
This MUST conform to the definition of <att-field>. | This MUST conform to the definition of <attribute-name>. | |||
* Attribute syntax: for a value attribute (see Section 5.13), an | * Attribute syntax: for a value attribute (see Section 5.13), an | |||
ABNF definition of the attribute value <att-value> syntax (see | ABNF definition of the attribute value <attribute-value> syntax | |||
Section 9) MUST be provided. The syntax MUST follow the rule form | (see Section 9) MUST be provided. The syntax MUST follow the rule | |||
per Section 2.2 of [RFC5234] and [RFC7405]. This SHALL define the | form per Section 2.2 of [RFC5234] and [RFC7405]. This SHALL | |||
allowable values that the attribute might take. It MAY also | define the allowable values that the attribute might take. It MAY | |||
define an extension method for the addition of future values. For | also define an extension method for the addition of future values. | |||
a property attribute, the ABNF definition is omitted as the | For a property attribute, the ABNF definition is omitted as the | |||
property attribute takes no values. | property attribute takes no values. | |||
* Attribute semantics: for a value attribute, a semantic description | * 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. | |||
* Attribute value: the name of an ABNF syntax rule defining the | * 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. | |||
* Usage level: the usage level(s) of the attribute. This MUST be | * Usage level: the usage level(s) of the attribute. This MUST be | |||
one or more of the following: session, media, source, dcsa, and | one or more of the following: session, media, source, dcsa, and | |||
dcsa(subprotocol). For a definition of source-level attributes, | dcsa(subprotocol). For a definition of source-level attributes, | |||
see [RFC5576]. For a definition of dcsa attributes see [RFC8864]. | see [RFC5576]. For a definition of dcsa attributes see [RFC8864]. | |||
* Charset dependent: this MUST be "Yes" or "No" depending on whether | * Charset dependent: this MUST be "Yes" or "No" depending on whether | |||
the attribute value is subject to the charset attribute. | the attribute value is subject to the "a=charset:" attribute. | |||
* Purpose: an explanation of the purpose and usage of the attribute. | * Purpose: an explanation of the purpose and usage of the attribute. | |||
* O/A procedures: offer/answer procedures as explained in [RFC3264]. | * O/A procedures: offer/answer procedures as explained in [RFC3264]. | |||
* Mux Category: this MUST indicate one of the following categories: | * Mux Category: this MUST indicate one of the following categories: | |||
NORMAL, NOT RECOMMENDED, IDENTICAL, SUM, TRANSPORT, INHERIT, | NORMAL, NOT RECOMMENDED, IDENTICAL, SUM, TRANSPORT, INHERIT, | |||
IDENTICAL-PER-PT, SPECIAL, or TBD as defined by [RFC8859]. | IDENTICAL-PER-PT, SPECIAL, or TBD as defined by [RFC8859]. | |||
* Reference: a reference to the specification defining the | * Reference: a reference to the specification defining the | |||
skipping to change at line 2161 ¶ | skipping to change at line 2174 ¶ | |||
attribute usage level. They should not choose only "session" when | attribute usage level. They should not choose only "session" when | |||
the attribute can have different values when media is disaggregated, | the attribute can have different values when media is disaggregated, | |||
i.e., when each "m=" section has its own IP address on a different | i.e., when each "m=" section has its own IP address on a different | |||
endpoint. In that case, the attribute type chosen should be | endpoint. In that case, the attribute type chosen should be | |||
"session, media" or "media" (depending on desired semantics). The | "session, media" or "media" (depending on desired semantics). The | |||
default rule is that for all new SDP attributes that can occur both | default rule is that for all new SDP attributes that can occur both | |||
in session and media level, the media level overrides the session | in session and media level, the media level overrides the session | |||
level. When this is not the case for a new SDP attribute, it MUST be | level. When this is not the case for a new SDP attribute, it MUST be | |||
explicitly stated. | explicitly stated. | |||
IANA has registered the initial set of attribute names ("att-field" | IANA has registered the initial set of attribute names (<attribute- | |||
values) with definitions as in Section 6 of this memo (these | name> values) with definitions as in Section 6 of this memo (these | |||
definitions replace those in [RFC4566]). | definitions replace those in [RFC4566]). | |||
8.2.4.2. Updates to Existing Attributes | 8.2.4.2. Updates to Existing Attributes | |||
Updated attribute registrations are accepted according to the | Updated attribute registrations are accepted according to the | |||
"Specification Required" policy of [RFC8126]. | "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 | |||
skipping to change at line 2217 ¶ | skipping to change at line 2230 ¶ | |||
* Mux Category: no change unless from "TBD" to another value (see | * Mux Category: no change unless from "TBD" to another value (see | |||
[RFC8859]. It MAY also change if media level is being added to | [RFC8859]. It MAY also change if media level is being added to | |||
the definition of an attribute that previously did not include it. | the definition of an attribute that previously did not include it. | |||
* Reference: a new (additional or replacement) reference MUST be | * Reference: a new (additional or replacement) reference MUST be | |||
provided. | provided. | |||
Items SHOULD be omitted if there is no impact to them as a result of | Items SHOULD be omitted if there is no impact to them as a result of | |||
the attribute update. | the attribute update. | |||
8.2.5. Bandwidth Specifiers ("bwtype") | 8.2.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> subfield 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. | |||
The RFC MUST specify the Mux Category for this value as defined by | The RFC MUST specify the Mux Category for this value as defined by | |||
[RFC8859]. | [RFC8859]. | |||
The format of the "bwtype" registry is: | The format of the <bwtype> registry is: | |||
+======+==========+==============+===========+ | +======+==========+==============+===========+ | |||
| Type | SDP Name | Mux Category | Reference | | | Type | SDP Name | Mux Category | Reference | | |||
+======+==========+==============+===========+ | +======+==========+==============+===========+ | |||
Table 6: Format of the "bwtype" registry | Table 6: Format of the <bwtype> Registry | |||
IANA is requested to update the "bwtype" registry entries for the | IANA is requested to update the <bwtype> registry entries for the | |||
bandwidth specifiers "CT" and "AS" with the definitions in | bandwidth specifiers "CT" and "AS" with the definitions in | |||
Section 5.8 of this memo (these definitions replace those in | Section 5.8 of this memo (these definitions replace those in | |||
[RFC4566]). | [RFC4566]). | |||
8.2.6. Network Types ("nettype") | 8.2.6. Network Types (<nettype>) | |||
Network type "IN", representing the Internet, is defined in | Network type "IN", representing the Internet, is defined in | |||
Section 5.2 and Section 5.7 of this memo (this definition replaces | Section 5.2 and Section 5.7 of this memo (this definition replaces | |||
that in [RFC4566]). | that in [RFC4566]). | |||
To enable SDP to reference a new non-Internet environment, a new | To enable SDP to reference a new non-Internet environment, a new | |||
network type (<nettype> sub-field value) MUST be registered with | network type (<nettype> subfield value) MUST be registered with IANA. | |||
IANA. The registration is subject to the "RFC Required" policy of | The registration is subject to the "RFC Required" policy of | |||
[RFC8126]. Although non-Internet environments are not normally the | [RFC8126]. Although non-Internet environments are not normally the | |||
preserve of IANA, there may be circumstances when an Internet | preserve of IANA, there may be circumstances when an Internet | |||
application needs to interoperate with a non-Internet application, | application needs to interoperate with a non-Internet application, | |||
such as when gatewaying an Internet telephone call into the Public | such as when gatewaying an Internet telephone call into the Public | |||
Switched Telephone Network (PSTN). The number of network types | Switched Telephone Network (PSTN). The number of network types | |||
should be small and should be rarely extended. A new network type | should be small and should be rarely extended. A new network type | |||
registration MUST reference an RFC that gives details of the network | registration MUST reference an RFC that gives details of the network | |||
type and the address type(s) that may be used with it. | type and the address type(s) that may be used with it. | |||
The format of the "nettype" registry is: | The format of the <nettype> registry is: | |||
+======+==========+========================+===========+ | +======+==========+========================+===========+ | |||
| Type | SDP Name | Usable addrtype Values | Reference | | | Type | SDP Name | Usable addrtype Values | Reference | | |||
+======+==========+========================+===========+ | +======+==========+========================+===========+ | |||
Table 7: Format of the "nettype" registry | Table 7: Format of the <nettype> Registry | |||
IANA is requested to update the "nettype" registry to this new | IANA is requested to update the <nettype> registry to this new | |||
format. The following is the updated content of the registry: | format. The following is the updated content of the registry: | |||
+=========+==========+========================+===========+ | +=========+==========+========================+===========+ | |||
| Type | SDP Name | Usable addrtype Values | Reference | | | Type | SDP Name | Usable addrtype Values | Reference | | |||
+=========+==========+========================+===========+ | +=========+==========+========================+===========+ | |||
| nettype | IN | IP4, IP6 | RFC 8866 | | | nettype | IN | IP4, IP6 | [RFC8866] | | |||
+---------+----------+------------------------+-----------+ | +---------+----------+------------------------+-----------+ | |||
| 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] | | |||
+---------+----------+------------------------+-----------+ | +---------+----------+------------------------+-----------+ | |||
Table 8: Content of the "nettype" registry | Table 8: Content of the <nettype> registry | |||
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.2.7. Address Types ("addrtype") | 8.2.7. Address Types (<addrtype>) | |||
New address types ("addrtype") MUST be registered with IANA. The | New address types (<addrtype>) MUST be registered with IANA. The | |||
registration is subject to the "RFC Required" policy of [RFC8126]. A | registration is subject to the "RFC Required" policy of [RFC8126]. A | |||
new address type registration MUST reference an RFC, giving details | new address type registration MUST reference an RFC, giving details | |||
of the syntax of the address type. Address types are not expected to | of the syntax of the address type. Address types are not expected to | |||
be registered frequently. | be registered frequently. | |||
Section 5.7 of this document gives new definitions of address types | Section 5.7 of this document gives new definitions of address types | |||
"IP4" and "IP6". | "IP4" and "IP6". | |||
8.3. Encryption Key Access Methods (OBSOLETE) | 8.3. Encryption Key Access Methods (OBSOLETE) | |||
skipping to change at line 2455 ¶ | skipping to change at line 2468 ¶ | |||
%s"base64:" base64 / | %s"base64:" base64 / | |||
%s"uri:" uri | %s"uri:" uri | |||
; NOTE: These names are case-sensitive. | ; NOTE: These names are case-sensitive. | |||
base64 = *base64-unit [base64-pad] | base64 = *base64-unit [base64-pad] | |||
base64-unit = 4base64-char | base64-unit = 4base64-char | |||
base64-pad = 2base64-char "==" / 3base64-char "=" | base64-pad = 2base64-char "==" / 3base64-char "=" | |||
base64-char = ALPHA / DIGIT / "+" / "/" | base64-char = ALPHA / DIGIT / "+" / "/" | |||
; sub-rules of 'a=' | ; sub-rules of 'a=' | |||
attribute = (att-field ":" att-value) / att-field | attribute = (attribute-name ":" attribute-value) / | |||
attribute-name | ||||
att-field = token | attribute-name = token | |||
att-value = byte-string | attribute-value = byte-string | |||
att-field = attribute-name ; for backward compatibility | ||||
; sub-rules of 'm=' | ; sub-rules of 'm=' | |||
media = token | media = token | |||
;typically "audio", "video", "text", "image" | ;typically "audio", "video", "text", "image" | |||
;or "application" | ;or "application" | |||
fmt = token | fmt = token | |||
;typically an RTP payload type for audio | ;typically an RTP payload type for audio | |||
;and video media | ;and video media | |||
proto = token *("/" token) | proto = token *("/" token) | |||
;typically "RTP/AVP" or "udp" | ;typically "RTP/AVP", "RTP/SAVP", "udp", | |||
;or "RTP/SAVPF" | ||||
port = 1*DIGIT | port = 1*DIGIT | |||
; generic sub-rules: addressing | ; generic sub-rules: addressing | |||
unicast-address = IP4-address / IP6-address / FQDN / extn-addr | unicast-address = IP4-address / IP6-address / FQDN / extn-addr | |||
multicast-address = IP4-multicast / IP6-multicast / FQDN | multicast-address = IP4-multicast / IP6-multicast / FQDN | |||
/ extn-addr | / extn-addr | |||
IP4-multicast = m1 3( "." decimal-uchar ) | IP4-multicast = m1 3( "." decimal-uchar ) | |||
skipping to change at line 2578 ¶ | skipping to change at line 2595 ¶ | |||
DIGIT = <DIGIT definition from RFC 5234> | DIGIT = <DIGIT definition from RFC 5234> | |||
CRLF = <CRLF definition from RFC 5234> | CRLF = <CRLF definition from RFC 5234> | |||
HEXDIG = <HEXDIG definition from RFC 5234> | HEXDIG = <HEXDIG definition from RFC 5234> | |||
SP = <SP definition from RFC 5234> | SP = <SP definition from RFC 5234> | |||
VCHAR = <VCHAR definition from RFC 5234> | VCHAR = <VCHAR definition from RFC 5234> | |||
URI-reference = <URI-reference definition from RFC 3986> | URI-reference = <URI-reference definition from RFC 3986> | |||
addr-spec = <addr-spec definition from RFC 5322> | addr-spec = <addr-spec definition from RFC 5322> | |||
10. Summary of Changes from RFC 4566 | 10. Summary of Changes from RFC 4566 | |||
* Generally clarified and refined terminology. | * Generally clarified and refined terminology. Aligned terms used | |||
in text with the ABNF. The terms <attribute>, <att-field>, and | ||||
"att-field" are now <attribute-name>. The terms <value> and <att- | ||||
value> are now <attribute-value>. The term "media" is now | ||||
<media>. | ||||
* Identified now-obsolete items: "a=cat" (Section 6.1), "a=keywds" | * Identified now-obsolete items: "a=cat:" (Section 6.1), "a=keywds:" | |||
(Section 6.2), and "k=" (Section 5.12). | (Section 6.2), and "k=" (Section 5.12). | |||
* Updated normative and informative references, and added references | * Updated normative and informative references, and added references | |||
to additional relevant related RFCs. | to additional relevant related RFCs. | |||
* Reformatted the SDP Attributes section (Section 6) for | * Reformatted the SDP Attributes section (Section 6) for | |||
readability. The syntax of attribute values is now given in ABNF. | readability. The syntax of attribute values is now given in ABNF. | |||
* Made mandatory the sending of RTCP with inactive media streams | * Made mandatory the sending of RTCP with inactive media streams | |||
(Section 6.7.4). | (Section 6.7.4). | |||
* Removed the section "Private Sessions". That section dated back | * Removed the section "Private Sessions". That section dated back | |||
to a time when the primary use of SDP was with SAP (Session | to a time when the primary use of SDP was with SAP (Session | |||
Announcement Protocol), which has fallen out of use. Now the vast | Announcement Protocol), which has fallen out of use. Now the vast | |||
majority of uses of SDP is for establishment of private sessions. | majority of uses of SDP is for establishment of private sessions. | |||
The considerations for that are covered in Section 7. | The considerations for that are covered in Section 7. | |||
* Expanded and clarified the specification of the "lang" | * Expanded and clarified the specification of the "a=lang:" | |||
(Section 6.12) and "sdplang" (Section 6.11) attributes. | (Section 6.12) and "a=sdplang:" (Section 6.11) attributes. | |||
* Removed some references to SAP because it is no longer in | * Removed some references to SAP because it is no longer in | |||
widespread use. | widespread use. | |||
* Changed the way <fmt> values for UDP transport are registered | * Changed the way <fmt> values for UDP transport are registered | |||
(Section 8.2.3). | (Section 8.2.3). | |||
* Changed the mechanism and documentation required for registering | * Changed the mechanism and documentation required for registering | |||
new attributes (Section 8.2.4.1). | new attributes (Section 8.2.4.1). | |||
* Tightened up IANA registration procedures for extensions. Removed | * Tightened up IANA registration procedures for extensions. Removed | |||
phone number and long-form name (Section 8.2). | phone number and long-form name (Section 8.2). | |||
* Expanded the IANA nettype registry to identify valid addrtypes | * Expanded the IANA <nettype> registry to identify valid <addrtype> | |||
(Section 8.2.6). | subfields (Section 8.2.6). | |||
* Reorganized the several IANA att-field registries into a single | * Reorganized the several IANA "att-field" registries into a single | |||
registry (Section 8.2.4). | <attribute-name> registry (Section 8.2.4). | |||
* Revised ABNF syntax (Section 9) for clarity. Backward | * Revised ABNF syntax (Section 9) for clarity and for alignment with | |||
compatibility is maintained with a few exceptions: | text. Backward compatibility is maintained with a few exceptions. | |||
Of particular note: | ||||
- 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 | |||
preceding "r=" a syntax error (Section 5.11). (This is | preceding "r=" a syntax error (Section 5.11). (This is | |||
incompatible with certain aberrant usage.) | incompatible with certain aberrant usage.) | |||
- Updated the "IP6-address" and "IP6-multicast" rules, consistent | - Updated the "IP6-address" and "IP6-multicast" rules, consistent | |||
with the syntax in [RFC3986], mirroring a bug fix made to | with the syntax in [RFC3986], mirroring a bug fix made to | |||
[RFC3261] by [RFC5954]. Removed rules that were unused as a | [RFC3261] by [RFC5954]. Removed rules that were unused as a | |||
result of this change. | result of this change. | |||
- The "att-field" rule has been renamed "attribute-name" because | ||||
elsewhere "*-field" always refers to a complete line. However, | ||||
the rulename "att-field" remains defined as a synonym for | ||||
backward compatibility with references from other RFCs. | ||||
- The "att-value" rule has been renamed "attribute-value". | ||||
* Revised normative statements that were redundant with ABNF syntax, | * Revised normative statements that were redundant with ABNF syntax, | |||
making the text non-normative. | making the text non-normative. | |||
* Revised IPv4 unicast and multicast addresses in the example SDP | * Revised IPv4 unicast and multicast addresses in the example SDP | |||
descriptions per [RFC5735] and [RFC5771]. | descriptions per [RFC5735] and [RFC5771]. | |||
* Changed some examples to use IPv6 addresses, and added additional | * Changed some examples to use IPv6 addresses, and added additional | |||
examples using IPv6. | examples using IPv6. | |||
* Incorporated case-insensitivity rules from [RFC4855]. | * Incorporated case-insensitivity rules from [RFC4855]. | |||
* Revised sections that incorrectly referenced NTP (Section 5.2, | * Revised sections that incorrectly referenced NTP (Section 5.2, | |||
Section 5.9, Section 5.10, and Section 5.11). | Section 5.9, Section 5.10, and Section 5.11). | |||
* Clarified the explanation of the impact and use of "a=charset" | * Clarified the explanation of the impact and use of the | |||
(Section 6.10). | "a=charset:" attribute (Section 6.10). | |||
* Revised the description of "a=type" to remove implication that it | * Revised the description of the "a=type:" attribute to remove | |||
sometimes changes the default media direction to something other | implication that it sometimes changes the default media direction | |||
than sendrecv (Section 6.9). | to something other than "a=sendrecv" (Section 6.9). | |||
11. References | 11. References | |||
11.1. Normative References | 11.1. Normative References | |||
[E164] International Telecommunication Union, "E.164 : The | [E164] International Telecommunication Union, "E.164 : The | |||
international public telecommunication numbering plan", | international public telecommunication numbering plan", | |||
ITU Recommendation E.164, November 2010, | ITU Recommendation E.164, November 2010, | |||
<https://www.itu.int/rec/T-REC-E.164-201011-I/en>. | <https://www.itu.int/rec/T-REC-E.164-201011-I/en>. | |||
skipping to change at line 2767 ¶ | skipping to change at line 2796 ¶ | |||
<https://www.rfc-editor.org/rfc/rfc8864>. | <https://www.rfc-editor.org/rfc/rfc8864>. | |||
11.2. Informative References | 11.2. Informative References | |||
[ITU.H332.1998] | [ITU.H332.1998] | |||
International Telecommunication Union, "H.332 : H.323 | International Telecommunication Union, "H.332 : H.323 | |||
extended for loosely coupled conferences", ITU | extended for loosely coupled conferences", ITU | |||
Recommendation H.332, September 1998, | Recommendation H.332, September 1998, | |||
<https://www.itu.int/rec/T-REC-H.332-199809-I/en>. | <https://www.itu.int/rec/T-REC-H.332-199809-I/en>. | |||
[MSRP-DATACHANNEL] | ||||
Recio, J. and C. Holmberg, "MSRP over Data Channels", Work | ||||
in Progress, Internet-Draft, draft-ietf-mmusic-msrp-usage- | ||||
data-channel-20, 30 June 2020, | ||||
<https://tools.ietf.org/html/draft-ietf-mmusic-msrp-usage- | ||||
data-channel-20>. | ||||
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |||
Extensions (MIME) Part One: Format of Internet Message | Extensions (MIME) Part One: Format of Internet Message | |||
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, | Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, | |||
<https://www.rfc-editor.org/info/rfc2045>. | <https://www.rfc-editor.org/info/rfc2045>. | |||
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description | [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description | |||
Protocol", RFC 2327, DOI 10.17487/RFC2327, April 1998, | Protocol", RFC 2327, DOI 10.17487/RFC2327, April 1998, | |||
<https://www.rfc-editor.org/info/rfc2327>. | <https://www.rfc-editor.org/info/rfc2327>. | |||
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session | [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session | |||
skipping to change at line 2834 ¶ | skipping to change at line 2856 ¶ | |||
"Indicating User Agent Capabilities in the Session | "Indicating User Agent Capabilities in the Session | |||
Initiation Protocol (SIP)", RFC 3840, | Initiation Protocol (SIP)", RFC 3840, | |||
DOI 10.17487/RFC3840, August 2004, | DOI 10.17487/RFC3840, August 2004, | |||
<https://www.rfc-editor.org/info/rfc3840>. | <https://www.rfc-editor.org/info/rfc3840>. | |||
[RFC3890] Westerlund, M., "A Transport Independent Bandwidth | [RFC3890] Westerlund, M., "A Transport Independent Bandwidth | |||
Modifier for the Session Description Protocol (SDP)", | Modifier for the Session Description Protocol (SDP)", | |||
RFC 3890, DOI 10.17487/RFC3890, September 2004, | RFC 3890, DOI 10.17487/RFC3890, September 2004, | |||
<https://www.rfc-editor.org/info/rfc3890>. | <https://www.rfc-editor.org/info/rfc3890>. | |||
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in | ||||
the Session Description Protocol (SDP)", RFC 4145, | ||||
DOI 10.17487/RFC4145, September 2005, | ||||
<https://www.rfc-editor.org/info/rfc4145>. | ||||
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session | [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session | |||
Description Protocol (SDP) Security Descriptions for Media | Description Protocol (SDP) Security Descriptions for Media | |||
Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, | Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, | |||
<https://www.rfc-editor.org/info/rfc4568>. | <https://www.rfc-editor.org/info/rfc4568>. | |||
[RFC4855] Casner, S., "Media Type Registration of RTP Payload | [RFC4855] Casner, S., "Media Type Registration of RTP Payload | |||
Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, | Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, | |||
<https://www.rfc-editor.org/info/rfc4855>. | <https://www.rfc-editor.org/info/rfc4855>. | |||
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for | ||||
Real-time Transport Control Protocol (RTCP)-Based Feedback | ||||
(RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February | ||||
2008, <https://www.rfc-editor.org/info/rfc5124>. | ||||
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, | [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, | |||
DOI 10.17487/RFC5322, October 2008, | DOI 10.17487/RFC5322, October 2008, | |||
<https://www.rfc-editor.org/info/rfc5322>. | <https://www.rfc-editor.org/info/rfc5322>. | |||
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", | [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", | |||
RFC 5735, DOI 10.17487/RFC5735, January 2010, | RFC 5735, DOI 10.17487/RFC5735, January 2010, | |||
<https://www.rfc-editor.org/info/rfc5735>. | <https://www.rfc-editor.org/info/rfc5735>. | |||
[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for | [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for | |||
IPv4 Multicast Address Assignments", BCP 51, RFC 5771, | IPv4 Multicast Address Assignments", BCP 51, RFC 5771, | |||
skipping to change at line 2871 ¶ | skipping to change at line 2893 ¶ | |||
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description | [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description | |||
Protocol (SDP) Grouping Framework", RFC 5888, | Protocol (SDP) Grouping Framework", RFC 5888, | |||
DOI 10.17487/RFC5888, June 2010, | DOI 10.17487/RFC5888, June 2010, | |||
<https://www.rfc-editor.org/info/rfc5888>. | <https://www.rfc-editor.org/info/rfc5888>. | |||
[RFC5954] Gurbani, V., Ed., Carpenter, B., Ed., and B. Tate, Ed., | [RFC5954] Gurbani, V., Ed., Carpenter, B., Ed., and B. Tate, Ed., | |||
"Essential Correction for IPv6 ABNF and URI Comparison in | "Essential Correction for IPv6 ABNF and URI Comparison in | |||
RFC 3261", RFC 5954, DOI 10.17487/RFC5954, August 2010, | RFC 3261", RFC 5954, DOI 10.17487/RFC5954, August 2010, | |||
<https://www.rfc-editor.org/info/rfc5954>. | <https://www.rfc-editor.org/info/rfc5954>. | |||
[RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model | ||||
for the Message Session Relay Protocol (MSRP)", RFC 6135, | ||||
DOI 10.17487/RFC6135, February 2011, | ||||
<https://www.rfc-editor.org/info/rfc6135>. | ||||
[RFC6466] Salgueiro, G., "IANA Registration of the 'image' Media | [RFC6466] Salgueiro, G., "IANA Registration of the 'image' Media | |||
Type for the Session Description Protocol (SDP)", | Type for the Session Description Protocol (SDP)", | |||
RFC 6466, DOI 10.17487/RFC6466, December 2011, | RFC 6466, DOI 10.17487/RFC6466, December 2011, | |||
<https://www.rfc-editor.org/info/rfc6466>. | <https://www.rfc-editor.org/info/rfc6466>. | |||
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type | [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type | |||
Specifications and Registration Procedures", BCP 13, | Specifications and Registration Procedures", BCP 13, | |||
RFC 6838, DOI 10.17487/RFC6838, January 2013, | RFC 6838, DOI 10.17487/RFC6838, January 2013, | |||
<https://www.rfc-editor.org/info/rfc6838>. | <https://www.rfc-editor.org/info/rfc6838>. | |||
skipping to change at line 2956 ¶ | skipping to change at line 2973 ¶ | |||
Email: ali.begen@networked.media | Email: ali.begen@networked.media | |||
Paul Kyzivat | Paul Kyzivat | |||
United States of America | United States of America | |||
Email: pkyzivat@alum.mit.edu | Email: pkyzivat@alum.mit.edu | |||
Colin Perkins | Colin Perkins | |||
University of Glasgow | University of Glasgow | |||
School of Computing Science | School of Computing Science | |||
University of Glasgow | ||||
Glasgow | Glasgow | |||
G12 8QQ | G12 8QQ | |||
United Kingdom | United Kingdom | |||
Email: csp@csperkins.org | Email: csp@csperkins.org | |||
Mark Handley | Mark Handley | |||
University College London | University College London | |||
Department of Computer Science | Department of Computer Science | |||
London | London | |||
End of changes. 129 change blocks. | ||||
266 lines changed or deleted | 282 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |