draft-ietf-mmusic-rfc4566bis-29.txt | draft-ietf-mmusic-rfc4566bis-30.txt | |||
---|---|---|---|---|
Network Working Group A. Begen | Network Working Group A. Begen | |||
Internet-Draft Networked Media | Internet-Draft Networked Media | |||
Obsoletes: 4566 (if approved) P. Kyzivat | Obsoletes: 4566 (if approved) P. Kyzivat | |||
Intended status: Standards Track | Intended status: Standards Track | |||
Expires: December 7, 2018 C. Perkins | Expires: January 2, 2019 C. Perkins | |||
University of Glasgow | University of Glasgow | |||
M. Handley | M. Handley | |||
UCL | UCL | |||
June 5, 2018 | July 1, 2018 | |||
SDP: Session Description Protocol | SDP: Session Description Protocol | |||
draft-ietf-mmusic-rfc4566bis-29 | draft-ietf-mmusic-rfc4566bis-30 | |||
Abstract | Abstract | |||
This memo defines the Session Description Protocol (SDP). SDP is | This memo defines the Session Description Protocol (SDP). SDP is | |||
intended for describing multimedia sessions for the purposes of | intended for describing multimedia sessions for the purposes of | |||
session announcement, session invitation, and other forms of | session announcement, session invitation, and other forms of | |||
multimedia session initiation. This document obsoletes RFC 4566. | multimedia session initiation. This document obsoletes RFC 4566. | |||
Status of This Memo | Status of This Memo | |||
skipping to change at page 1, line 38 ¶ | skipping to change at page 1, line 38 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on December 7, 2018. | This Internet-Draft will expire on January 2, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 48 ¶ | skipping to change at page 2, line 48 ¶ | |||
5.2. Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 12 | 5.2. Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 12 | |||
5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 13 | 5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 13 | |||
5.4. Session Information ("i=") . . . . . . . . . . . . . . . 13 | 5.4. Session Information ("i=") . . . . . . . . . . . . . . . 13 | |||
5.5. URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . 14 | 5.5. URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
5.6. Email Address and Phone Number ("e=" and "p=") . . . . . 14 | 5.6. Email Address and Phone Number ("e=" and "p=") . . . . . 14 | |||
5.7. Connection Information ("c=") . . . . . . . . . . . . . . 15 | 5.7. Connection Information ("c=") . . . . . . . . . . . . . . 15 | |||
5.8. Bandwidth Information ("b=") . . . . . . . . . . . . . . 17 | 5.8. Bandwidth Information ("b=") . . . . . . . . . . . . . . 17 | |||
5.9. Time Active ("t=") . . . . . . . . . . . . . . . . . . . 18 | 5.9. Time Active ("t=") . . . . . . . . . . . . . . . . . . . 18 | |||
5.10. Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . 19 | 5.10. Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . 19 | |||
5.11. Time Zone Adjustment ("z=") . . . . . . . . . . . . . . . 20 | 5.11. Time Zone Adjustment ("z=") . . . . . . . . . . . . . . . 20 | |||
5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 20 | 5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 21 | |||
5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 21 | 5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 21 | |||
5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 22 | 5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 22 | |||
6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 24 | 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
6.1. cat (category) . . . . . . . . . . . . . . . . . . . . . 25 | 6.1. cat (category) . . . . . . . . . . . . . . . . . . . . . 25 | |||
6.2. keywds (keywords) . . . . . . . . . . . . . . . . . . . . 25 | 6.2. keywds (keywords) . . . . . . . . . . . . . . . . . . . . 25 | |||
6.3. tool . . . . . . . . . . . . . . . . . . . . . . . . . . 26 | 6.3. tool . . . . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
6.4. ptime (packet time) . . . . . . . . . . . . . . . . . . . 26 | 6.4. ptime (packet time) . . . . . . . . . . . . . . . . . . . 26 | |||
6.5. maxptime (maximum packet time) . . . . . . . . . . . . . 27 | 6.5. maxptime (maximum packet time) . . . . . . . . . . . . . 27 | |||
6.6. rtpmap . . . . . . . . . . . . . . . . . . . . . . . . . 27 | 6.6. rtpmap . . . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
6.7. Media Direction Attributes . . . . . . . . . . . . . . . 29 | 6.7. Media Direction Attributes . . . . . . . . . . . . . . . 29 | |||
6.7.1. recvonly (receive-only) . . . . . . . . . . . . . . . 30 | 6.7.1. recvonly (receive-only) . . . . . . . . . . . . . . . 30 | |||
6.7.2. sendrecv (send-receive) . . . . . . . . . . . . . . . 30 | 6.7.2. sendrecv (send-receive) . . . . . . . . . . . . . . . 30 | |||
6.7.3. sendonly (send-only) . . . . . . . . . . . . . . . . 30 | 6.7.3. sendonly (send-only) . . . . . . . . . . . . . . . . 31 | |||
6.7.4. inactive . . . . . . . . . . . . . . . . . . . . . . 31 | 6.7.4. inactive . . . . . . . . . . . . . . . . . . . . . . 31 | |||
6.8. orient (orientation) . . . . . . . . . . . . . . . . . . 31 | 6.8. orient (orientation) . . . . . . . . . . . . . . . . . . 32 | |||
6.9. type (conference type) . . . . . . . . . . . . . . . . . 32 | 6.9. type (conference type) . . . . . . . . . . . . . . . . . 32 | |||
6.10. charset (character set) . . . . . . . . . . . . . . . . . 33 | 6.10. charset (character set) . . . . . . . . . . . . . . . . . 33 | |||
6.11. sdplang (SDP language) . . . . . . . . . . . . . . . . . 34 | 6.11. sdplang (SDP language) . . . . . . . . . . . . . . . . . 34 | |||
6.12. lang (language) . . . . . . . . . . . . . . . . . . . . . 34 | 6.12. lang (language) . . . . . . . . . . . . . . . . . . . . . 35 | |||
6.13. framerate (frame rate) . . . . . . . . . . . . . . . . . 36 | 6.13. framerate (frame rate) . . . . . . . . . . . . . . . . . 36 | |||
6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 36 | 6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 36 | |||
6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 37 | 6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 37 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 37 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 38 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 | |||
8.1. The "application/sdp" Media Type . . . . . . . . . . . . 39 | 8.1. The "application/sdp" Media Type . . . . . . . . . . . . 39 | |||
8.2. Registration of Parameters . . . . . . . . . . . . . . . 40 | 8.2. Registration of Parameters . . . . . . . . . . . . . . . 41 | |||
8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 41 | 8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 41 | |||
8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 41 | 8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 41 | |||
8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 42 | 8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 42 | |||
8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 42 | 8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 42 | |||
8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 45 | 8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 45 | |||
8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 45 | 8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 45 | |||
8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 46 | 8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 46 | |||
8.2.8. Registration Procedure . . . . . . . . . . . . . . . 46 | 8.2.8. Registration Procedure . . . . . . . . . . . . . . . 46 | |||
8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 47 | 8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 47 | |||
8.4. Reorganization of the nettype Registry . . . . . . . . . 47 | 8.4. Reorganization of the nettype Registry . . . . . . . . . 47 | |||
8.5. Reorganization of the att-field Registries . . . . . . . 47 | 8.5. Reorganization of the att-field Registries . . . . . . . 47 | |||
9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 48 | 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 48 | |||
10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 53 | 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 54 | |||
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54 | 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . 54 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 54 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . 55 | 12.2. Informative References . . . . . . . . . . . . . . . . . 56 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 | |||
1. Introduction | 1. Introduction | |||
When initiating multimedia teleconferences, voice-over-IP calls, | When initiating multimedia teleconferences, voice-over-IP calls, | |||
streaming video, or other sessions, there is a requirement to convey | streaming video, or other sessions, there is a requirement to convey | |||
media details, transport addresses, and other session description | media details, transport addresses, and other session description | |||
metadata to the participants. | metadata to the participants. | |||
SDP provides a standard representation for such information, | SDP provides a standard representation for such information, | |||
irrespective of how that information is transported. SDP is purely a | irrespective of how that information is transported. SDP is purely a | |||
skipping to change at page 5, line 37 ¶ | skipping to change at page 5, line 37 ¶ | |||
those parameters. | those parameters. | |||
3.3. Email and the World Wide Web | 3.3. Email and the World Wide Web | |||
Alternative means of conveying session descriptions include | Alternative means of conveying session descriptions include | |||
electronic mail and the World Wide Web (WWW). For both email and WWW | electronic mail and the World Wide Web (WWW). For both email and WWW | |||
distribution, the media type "application/sdp" is used. This enables | distribution, the media type "application/sdp" is used. This enables | |||
the automatic launching of applications for participation in the | the automatic launching of applications for participation in the | |||
session from the WWW client or mail reader in a standard manner. | session from the WWW client or mail reader in a standard manner. | |||
Note that announcements of multicast sessions made only via email or | Note that descriptions of multicast sessions made 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 | |||
announcement can necessarily receive the session because the | description can necessarily receive the session because the multicast | |||
multicast sessions may be restricted in scope, and access to the WWW | sessions may be restricted in scope, and access to the WWW server or | |||
server or reception of email is possible outside this scope. | reception of email is possible outside this scope. | |||
3.4. Multicast Session Announcement | 3.4. Multicast Session Announcement | |||
In order to assist the advertisement of multicast multimedia | In order to assist the advertisement of multicast multimedia | |||
conferences and other multicast sessions, and to communicate the | conferences and other multicast sessions, and to communicate the | |||
relevant session setup information to prospective participants, a | relevant session setup information to prospective participants, a | |||
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 page 7, line 36 ¶ | skipping to change at page 7, line 36 ¶ | |||
of the multicast stream, whether being sent, received, or both. | of the multicast stream, whether being sent, received, or both. | |||
For unicast IP sessions, the following are conveyed: | For unicast IP sessions, the following are conveyed: | |||
o The remote address for media | o The remote address for media | |||
o The remote transport port for media | o The remote transport port for media | |||
The semantics of this address and port depend on the media and | The semantics of this address and port depend on the media and | |||
transport protocol defined. By default, this SHOULD be the remote | transport protocol defined. By default, this SHOULD be the remote | |||
address and remote port to which data is sent. Some media types may | address and remote port to which media is sent. Some media types may | |||
redefine this behaviour, but this is NOT RECOMMENDED since it | redefine this behavior, but this is NOT RECOMMENDED since it | |||
complicates implementations (including middleboxes that must parse | complicates implementations (including middleboxes that must parse | |||
the addresses to open Network Address Translation (NAT) or firewall | the addresses to open Network Address Translation (NAT) or firewall | |||
pinholes). | pinholes). | |||
4.2. Timing Information | 4.2. Timing Information | |||
Sessions may be either bounded or unbounded in time. Whether or not | Sessions may be either bounded or unbounded in time. Whether or not | |||
they are bounded, they may be only active at specific times. SDP can | they are bounded, they may be only active at specific times. SDP can | |||
convey: | convey: | |||
skipping to change at page 8, line 19 ¶ | skipping to change at page 8, line 19 ¶ | |||
A session description could convey enough information to decide | A session description could convey enough information to decide | |||
whether or not to participate in a session. SDP may include | whether or not to participate in a session. SDP may include | |||
additional pointers in the form of Uniform Resource Identifiers | additional pointers in the form of Uniform Resource Identifiers | |||
(URIs) for more information about the session. | (URIs) for more information about the session. | |||
4.4. Categorization | 4.4. Categorization | |||
When many session descriptions are being distributed by an | When many session descriptions are being distributed by an | |||
advertisement mechanism, it may be desirable to filter session | advertisement mechanism, it may be desirable to filter session | |||
announcements that are of interest from those that are not. SDP | descriptions that are of interest from those that are not. SDP | |||
supports a categorization mechanism for sessions that is capable of | supports a categorization mechanism for sessions that is capable of | |||
being automated (the "a=cat:" attribute; see Section 6). | being automated (the "a=cat:" attribute; see Section 6). | |||
4.5. Internationalization | 4.5. 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 to be used | SDP also allows other character sets such as ISO 8859-1 to be used | |||
when desired. Internationalization only applies to free-text sub- | when desired. Internationalization only applies to free-text sub- | |||
skipping to change at page 8, line 51 ¶ | skipping to change at page 8, line 51 ¶ | |||
in UTF-8 encoding, or some other character set defined by the | in UTF-8 encoding, or some other character set defined by the | |||
"a=charset:" attribute. Field and attribute values that use the full | "a=charset:" attribute. Field and attribute values that use the full | |||
UTF-8 character set are never directly compared, hence there is no | UTF-8 character set are never directly compared, hence there is no | |||
requirement for UTF-8 normalization. The textual form, as opposed to | requirement for UTF-8 normalization. The textual form, as opposed to | |||
a binary encoding such as ASN.1 or XDR, was chosen to enhance | a binary encoding such as ASN.1 or XDR, was chosen to enhance | |||
portability, to enable a variety of transports to be used, and to | portability, to enable a variety of transports to be used, and to | |||
allow flexible, text-based toolkits to be used to generate and | allow flexible, text-based toolkits to be used to generate and | |||
process session descriptions. However, since SDP may be used in | process session descriptions. However, since SDP may be used in | |||
environments where the maximum permissible size of a session | environments where the maximum permissible size of a session | |||
description is limited, the encoding is deliberately compact. Also, | description is limited, the encoding is deliberately compact. Also, | |||
since announcements may be transported via very unreliable means or | since descriptions may be transported via very unreliable means or | |||
damaged by an intermediate caching server, the encoding was designed | damaged by an intermediate caching server, the encoding was designed | |||
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 announcements that could be detected | result in malformed session descriptions that could be detected | |||
easily and discarded. This also allows rapid discarding of encrypted | easily and discarded. This also allows rapid discarding of encrypted | |||
session announcements for which a receiver does not have the correct | session descriptions for which a receiver does not have the correct | |||
key. | key. | |||
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> MUST be exactly one case-significant character and | where <type> MUST be exactly one case-significant character and | |||
<value> is structured text whose format depends on <type>. In | <value> is structured text whose format depends on <type>. In | |||
general, <value> is either a number of sub-fields delimited by a | general, <value> is either a number of sub-fields delimited by a | |||
single space character or a free format string, and is case- | single space character or a free format string, and is case- | |||
skipping to change at page 11, line 27 ¶ | skipping to change at page 11, line 27 ¶ | |||
a=recvonly | a=recvonly | |||
m=audio 49170 RTP/AVP 0 | m=audio 49170 RTP/AVP 0 | |||
m=audio 49180 RTP/AVP 0 | m=audio 49180 RTP/AVP 0 | |||
m=video 51372 RTP/AVP 99 | m=video 51372 RTP/AVP 99 | |||
c=IN IP4 233.252.0.1/127 | c=IN IP4 233.252.0.1/127 | |||
a=rtpmap:99 h263-1998/90000 | a=rtpmap:99 h263-1998/90000 | |||
Text containing fields such as the session-name-field and | Text containing fields such as the session-name-field and | |||
information-field are octet strings that may contain any octet with | information-field are octet strings that may contain any octet with | |||
the exceptions of 0x00 (Nul), 0x0a (ASCII newline), and 0x0d (ASCII | the exceptions of 0x00 (Nul), 0x0a (ASCII newline), and 0x0d (ASCII | |||
carriage return). The sequence CRLF (0x0d0a) is used to end a | carriage return). The sequence CRLF (0x0d0a) is used to end a line, | |||
record, although parsers SHOULD be tolerant and also accept records | although parsers SHOULD be tolerant and also accept lines terminated | |||
terminated with a single newline character. If the "a=charset" | with a single newline character. If the "a=charset" attribute is not | |||
attribute is not present, these octet strings MUST be interpreted as | present, these octet strings MUST be interpreted as containing | |||
containing ISO-10646 characters in UTF-8 encoding (the presence of | ISO-10646 characters in UTF-8 encoding (the presence of the | |||
the "a=charset" attribute may force some fields to be interpreted | "a=charset" attribute may force some fields to be interpreted | |||
differently). | differently). | |||
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], [RFC1035]. Internationalized domain names (IDNs) | with [RFC1034], [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 | |||
[RFC2327] and other early SDP-related standards, which predate the | [RFC2327] and other early SDP-related standards, which predate the | |||
development of internationalized domain names). | development of internationalized domain names). | |||
skipping to change at page 12, line 27 ¶ | skipping to change at page 12, line 27 ¶ | |||
<sess-id> is a numeric string such that the tuple of <username>, | <sess-id> is a numeric string such that the tuple of <username>, | |||
<sess-id>, <nettype>, <addrtype>, and <unicast-address> forms a | <sess-id>, <nettype>, <addrtype>, and <unicast-address> forms a | |||
globally unique identifier for the session. The method of <sess- | globally unique identifier for the session. The method of <sess- | |||
id> allocation is up to the creating tool, but it has been | id> allocation is up to the creating tool, but it has been | |||
suggested that a Network Time Protocol (NTP) format timestamp be | suggested that a Network Time Protocol (NTP) format timestamp be | |||
used to ensure uniqueness [RFC5905]. | used to ensure uniqueness [RFC5905]. | |||
<sess-version> is a version number for this session description. | <sess-version> is a version number for this session description. | |||
Its usage is up to the creating tool, so long as <sess-version> is | Its usage is up to the creating tool, so long as <sess-version> is | |||
increased when a modification is made to the session data. Again, | increased when a modification is made to the session description. | |||
it is RECOMMENDED that an NTP format timestamp is used. | Again, it is RECOMMENDED that an NTP format timestamp is used. | |||
<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 | |||
skipping to change at page 15, line 31 ¶ | skipping to change at page 15, line 31 ¶ | |||
The second sub-field ("<addrtype>") is the address type. This allows | The second sub-field ("<addrtype>") is the address type. This allows | |||
SDP to be used for sessions that are not IP based. This memo only | SDP to be used for sessions that are not IP based. This memo only | |||
defines IP4 and IP6, but other values MAY be registered in the future | defines IP4 and IP6, but other values MAY be registered in the future | |||
(see Section 8). | (see Section 8). | |||
The third sub-field ("<connection-address>") is the connection | The third sub-field ("<connection-address>") is the connection | |||
address. Additional sub-fields MAY be added after the connection | address. Additional sub-fields MAY be added after the connection | |||
address depending on the value of the <addrtype> sub-field. | address depending on the value of the <addrtype> sub-field. | |||
When the <addrtype> is IP4 and IP6, the connection address is defined | When the <addrtype> is IP4 or IP6, the connection address is defined | |||
as follows: | as follows: | |||
o If the session is multicast, the connection address will be an IP | o 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. It is not expected that unicast | additional attribute-fields. It is not expected that unicast | |||
addresses will be given in a session description that is | addresses will be given in a session description that is | |||
communicated by a multicast announcement, though this is not | communicated by a multicast announcement, though this is not | |||
prohibited. | prohibited. | |||
skipping to change at page 18, line 27 ¶ | skipping to change at page 18, line 27 ¶ | |||
A "t=" line (time-field) initiates a time description that specifies | A "t=" line (time-field) initiates a time description that specifies | |||
the start and stop times for a session. Multiple time descriptions | the start and stop times for a session. Multiple time descriptions | |||
MAY be used if a session is active at multiple irregularly spaced | MAY be used if a session is active at multiple irregularly spaced | |||
times; each additional time description specifies additional periods | times; each additional time description specifies additional periods | |||
of time for which the session will be active. If the session is | of time for which the session will be active. If the session is | |||
active at regular repeat times, a repeat description, initiated by an | active at regular repeat times, a repeat description, initiated by an | |||
"r=" line (see below) can be included following the time-field -- in | "r=" line (see below) 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: | ||||
t=3724394400 3724398000 ; Mon 8-Jan-2018 10:00-11:00 UTC | ||||
t=3724484400 3724488000 ; Tue 9-Jan-2018 11:00-12:00 UTC | ||||
The first and second sub-fields of the time-field give the start and | The first and second sub-fields of the time-field give the start and | |||
stop times, respectively, for the session. These values are the | stop times, respectively, for the session. These values are the | |||
decimal representation of Network Time Protocol (NTP) time values in | decimal representation of Network Time Protocol (NTP) time values in | |||
seconds since 1900 [RFC5905]. To convert these values to UNIX time | seconds since 1900 [RFC5905]. To convert these values to UNIX time | |||
(UTC), subtract decimal 2208988800. | (UTC), subtract decimal 2208988800. | |||
NTP timestamps are elsewhere represented by 64-bit values, which wrap | NTP timestamps are elsewhere represented by 64-bit values, which wrap | |||
sometime in the year 2036. Since SDP uses an arbitrary length | sometime in the year 2036. Since SDP uses an arbitrary length | |||
decimal representation, this should not cause an issue (SDP | decimal representation, this should not cause an issue (SDP | |||
timestamps MUST continue counting seconds since 1900 - NTP will use | timestamps MUST continue counting seconds since 1900 - NTP will use | |||
skipping to change at page 18, line 51 ¶ | skipping to change at page 19, line 8 ¶ | |||
the <start-time> is also zero, the session is regarded as permanent. | the <start-time> is also zero, the session is regarded as permanent. | |||
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 behaviour | or the session start time, whichever is the later. If behavior other | |||
other than this is required, an end-time SHOULD be given and modified | than this is required, an end-time SHOULD be given and modified as | |||
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> | |||
skipping to change at page 19, line 28 ¶ | skipping to change at page 19, line 33 ¶ | |||
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 NTP | <start-time> in the corresponding "t=" line would be the NTP | |||
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 NTP representation of the end of the last session | time would be the NTP representation of the end of the last session | |||
three months later. By default, all sub-fields are in seconds, so | three months later. By default, all sub-fields are in seconds, so | |||
the "r=" and "t=" lines might be the following: | the "r=" and "t=" lines might be the following: | |||
t=3034423619 3042462419 | t=3724394400 3730536000 ; Mon 8-Jan-2018 10:00-11:00 UTC | |||
r=604800 3600 0 90000 | ; Tues 20-Mar-2018 12:00 UTC | |||
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 | |||
instead. The following unit specification characters are allowed: | instead. The following unit specification characters are allowed: | |||
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) | |||
Thus, the above session announcement 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=") | |||
z=<adjustment time> <offset> <adjustment time> <offset> .... | z=<adjustment time> <offset> <adjustment time> <offset> .... | |||
skipping to change at page 20, line 29 ¶ | skipping to change at page 20, line 33 ¶ | |||
Thus, in order to schedule a session that is at the same time winter | Thus, in order to schedule a session that is at the same time winter | |||
and summer, it must be possible to specify unambiguously by whose | and summer, it must be possible to specify unambiguously by whose | |||
time zone a session is scheduled. To simplify this task for | time zone a session is scheduled. To simplify this task for | |||
receivers, we allow the sender to specify the NTP time that a time | receivers, we allow the sender to specify the NTP time that a time | |||
zone adjustment happens and the offset from the time when the session | zone adjustment happens and the offset from the time when the session | |||
was first scheduled. The "z=" line allows the sender to specify a | was first scheduled. The "z=" line allows the sender to specify a | |||
list of these adjustment times and offsets from the base time. | list of these adjustment times and offsets from the base time. | |||
An example might be the following: | An example might be the following: | |||
z=2882844526 -1h 2898848070 0 | t=3724394400 3754123200 ; Mon 8-Jan-2018 10:00 UTC | |||
; Tues 18-Dec-2018 12:00 UTC | ||||
r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours | ||||
z=3730928400 -1h 3749680800 0 ; Sun 25-Mar-2018 1:00 UTC, | ||||
; offset 1 hour, | ||||
; Sun 28-Oct-2018 2:00 UTC, no offset | ||||
This specifies that at time 2882844526, the time base by which the | This specifies that at time 3730928400 (Sun 25-Mar-2018 1:00 UTC, the | |||
session's repeat times are calculated is shifted back by 1 hour, and | onset of British Summer Time) the time base by which the session's | |||
that at time 2898848070, the session's original time base is | repeat times are calculated is shifted back by 1 hour, and that at | |||
restored. Adjustments are always relative to the specified start | time 3749680800 (Sun 28-Oct-2018 2:00 UTC, the end of British Summer | |||
time -- they are not cumulative. Adjustments apply to all "t=" and | Time) the session's original time base is restored. Adjustments are | |||
"r=" lines in a session description. | always relative to the specified start time -- they are not | |||
cumulative. | ||||
If a session is likely to last several years, it is expected that the | If a session is likely to last several years, it is expected that the | |||
session description will be modified periodically rather than | session description will be modified periodically rather than | |||
transmit several years' worth of adjustments in one session | transmit several years' worth of adjustments in one session | |||
description. | description. | |||
5.12. Encryption Keys ("k=") | 5.12. Encryption Keys ("k=") | |||
k=<method> | k=<method> | |||
k=<method>:<encryption key> | k=<method>:<encryption key> | |||
skipping to change at page 23, line 8 ¶ | skipping to change at page 23, line 18 ¶ | |||
For RTP, the default is that only the even-numbered ports are used | For RTP, the default is that only the even-numbered ports are used | |||
for data with the corresponding one-higher odd ports used for the | for data with the corresponding one-higher odd ports used for the | |||
RTCP belonging to the RTP session, and the <number of ports> | RTCP belonging to the RTP session, and the <number of ports> | |||
denoting the number of RTP sessions. For example: | denoting the number of RTP sessions. For example: | |||
m=video 49170/2 RTP/AVP 31 | m=video 49170/2 RTP/AVP 31 | |||
would specify that ports 49170 and 49171 form one RTP/RTCP pair | would specify that ports 49170 and 49171 form one RTP/RTCP pair | |||
and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the | and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the | |||
transport protocol and 31 is the format (see below). If non- | transport protocol and 31 is the format (see below). If non- | |||
contiguous ports are required, they must be signalled using a | contiguous ports are required, they must be signaled using a | |||
separate attribute (for example, "a=rtcp:" as defined in | separate attribute. (There is currently no attribute defined that | |||
[RFC3605]). | can accomplish this. The "a=rtcp:" defined in [RFC3605] does not | |||
handle hierarchical encoding.) | ||||
If multiple addresses are specified in the "c=" line and multiple | If multiple addresses are specified in the "c=" line and multiple | |||
ports are specified in the "m=" line, a one-to-one mapping from | ports are specified in the "m=" line, a one-to-one mapping from | |||
port to the corresponding address is implied. For example: | port to the corresponding address is implied. For example: | |||
c=IN IP4 233.252.0.1/127/2 | c=IN IP4 233.252.0.1/127/2 | |||
m=video 49170/2 RTP/AVP 31 | m=video 49170/2 RTP/AVP 31 | |||
would imply that address 233.252.0.1 is used with ports 49170 and | would imply that address 233.252.0.1 is used with ports 49170 and | |||
49171, and address 233.252.0.2 is used with ports 49172 and 49173. | 49171, and address 233.252.0.2 is used with ports 49172 and 49173. | |||
skipping to change at page 37, line 7 ¶ | skipping to change at page 37, line 13 ¶ | |||
a=quality:10 | a=quality:10 | |||
This gives a suggestion for the quality of the encoding as an integer | This gives a suggestion for the quality of the encoding as an integer | |||
value. The intention of the quality attribute for video is to | value. The intention of the quality attribute for video is to | |||
specify a non-default trade-off between frame-rate and still-image | specify a non-default trade-off between frame-rate and still-image | |||
quality. For video, the value is in the range 0 to 10, with the | quality. For video, the value is in the range 0 to 10, with the | |||
following suggested meaning: | following suggested meaning: | |||
10 - the best still-image quality the compression scheme | 10 - the best still-image quality the compression scheme | |||
can give. | can give. | |||
5 - the default behaviour given no quality suggestion. | 5 - the default behavior given no quality suggestion. | |||
0 - the worst still-image quality the codec designer | 0 - the worst still-image quality the codec designer | |||
thinks is still usable. | thinks is still usable. | |||
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 | |||
skipping to change at page 38, line 34 ¶ | skipping to change at page 38, line 44 ¶ | |||
required to start software on the receiver's system. Software that | required to start software on the receiver's system. Software that | |||
parses a session description MUST NOT be able to start other software | parses a session description MUST NOT be able to start other software | |||
except that which is specifically configured as appropriate software | except that which is specifically configured as appropriate software | |||
to participate in multimedia sessions. It is normally considered | to participate in multimedia sessions. It is normally considered | |||
inappropriate for software parsing a session description to start, on | inappropriate for software parsing a session description to start, on | |||
a user's system, software that is appropriate to participate in | a user's system, software that is appropriate to participate in | |||
multimedia sessions, without the user first being informed that such | multimedia sessions, without the user first being informed that such | |||
software will be started and giving the user's consent. Thus, a | software will be started and giving the user's consent. Thus, a | |||
session description arriving by session announcement, email, session | session description arriving by session announcement, email, session | |||
invitation, or WWW page MUST NOT deliver the user into an interactive | invitation, or WWW page MUST NOT deliver the user into an interactive | |||
multimedia session unless the user has explicitly pre-authorised such | multimedia session unless the user has explicitly pre-authorized such | |||
action. As it is not always simple to tell whether or not a session | action. As it is not always simple to tell whether or not a session | |||
is interactive, applications that are unsure should assume sessions | is interactive, applications that are unsure should assume sessions | |||
are interactive. | are interactive. | |||
In this specification, there are no attributes that would allow the | In this specification, there are no attributes that would allow the | |||
recipient of a session description to be informed to start multimedia | recipient of a session description to be informed to start multimedia | |||
tools in a mode where they default to transmitting. Under some | tools in a mode where they default to transmitting. Under some | |||
circumstances it might be appropriate to define such attributes. If | circumstances it might be appropriate to define such attributes. If | |||
this is done, an application parsing a session description containing | this is done, an application parsing a session description containing | |||
such attributes SHOULD either ignore them or inform the user that | such attributes SHOULD either ignore them or inform the user that | |||
joining this session will result in the automatic transmission of | joining this session will result in the automatic transmission of | |||
multimedia data. The default behaviour for an unknown attribute is | multimedia data. The default behavior for an unknown attribute is to | |||
to ignore it. | ignore it. | |||
In certain environments, it has become common for intermediary | In certain environments, it has become common for intermediary | |||
systems to intercept and analyse session descriptions contained | systems to intercept and analyze session descriptions contained | |||
within other signalling protocols. This is done for a range of | within other signaling protocols. This is done for a range of | |||
purposes, including but not limited to opening holes in firewalls to | purposes, including but not limited to opening holes in firewalls to | |||
allow media streams to pass, or to mark, prioritize, or block traffic | allow media streams to pass, or to mark, prioritize, or block traffic | |||
selectively. In some cases, such intermediary systems may modify the | selectively. In some cases, such intermediary systems may modify the | |||
session description, for example, to have the contents of the session | session description, for example, to have the contents of the session | |||
description match NAT bindings dynamically created. These behaviours | description match NAT bindings dynamically created. These behaviors | |||
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). | RTSP). Use of some procedures and SDP extensions (e.g., ICE | |||
[RFC5245] and ICE-SIP-SDP [I-D.ietf-mmusic-ice-sip-sdp]) may avoid | ||||
the need for intermediaries to modify SDP. | ||||
Use of the "k=" line poses a significant security risk, since it | Use of the "k=" line poses a significant security risk, since it | |||
conveys session encryption keys in the clear. SDP MUST NOT be used | conveys session encryption keys in the clear. SDP MUST NOT be used | |||
to convey keying material, unless it can be guaranteed that the | to convey keying material, unless it can be guaranteed that the | |||
channel over which the SDP is delivered is both private and | channel over which the SDP is delivered is both private and | |||
authenticated. Moreover, the "k=" line provides no way to indicate | authenticated. Moreover, the "k=" line provides no way to indicate | |||
or negotiate cryptographic key algorithms. As it provides for only a | or negotiate cryptographic key algorithms. As it provides for only a | |||
single symmetric key, rather than separate keys for confidentiality | single symmetric key, rather than separate keys for confidentiality | |||
and integrity, its utility is severely limited. The "k=" line MUST | and integrity, its utility is severely limited. The "k=" line MUST | |||
NOT be used, as discussed in Section 5.12. | NOT be used, as discussed in Section 5.12. | |||
skipping to change at page 40, line 43 ¶ | skipping to change at page 41, line 10 ¶ | |||
Author/Change controller: | Author/Change controller: | |||
Authors of RFC XXXX | Authors of RFC XXXX | |||
IETF MMUSIC working group delegated from the IESG | IETF MMUSIC working group delegated from the IESG | |||
8.2. Registration of Parameters | 8.2. Registration of Parameters | |||
This specification establishes and initializes IANA parameter | This specification establishes and initializes IANA parameter | |||
registries for seven named SDP sub-fields. Using the terminology in | registries for seven named SDP sub-fields. Using the terminology in | |||
the SDP specification Augmented Backus-Naur Form (ABNF), they are | the SDP specification Augmented Backus-Naur Form (ABNF), they are | |||
"media", "proto", "fmt", "att-field", "bwtype", "nettype", and | "media", "proto", "att-field", "bwtype", "nettype", and "addrtype". | |||
"addrtype". | ||||
The contact address for all parameters registered below is: | The contact address for all parameters registered below is: | |||
IETF MMUSIC working group <mmusic@ietf.org> | IETF MMUSIC working group <mmusic@ietf.org> | |||
8.2.1. Media Types ("media") | 8.2.1. Media Types ("media") | |||
The set of media types is intended to be small and SHOULD NOT be | The set of media types is intended to be small and SHOULD NOT be | |||
extended except under rare circumstances. The same rules should | extended except under rare circumstances. The same rules should | |||
apply for media names as for top-level media types, and where | apply for media names as for top-level media types, and where | |||
skipping to change at page 43, line 9 ¶ | skipping to change at page 43, line 24 ¶ | |||
specification includes the following information: | specification includes the following information: | |||
o Contact Name. | o Contact Name. | |||
o Contact Email Address. | o Contact Email Address. | |||
o Attribute Name: The name of the attribute that will appear in | o Attribute Name: The name of the attribute that will appear in | |||
SDP). This MUST conform to the definition of <att-field>. | SDP). This MUST conform to the definition of <att-field>. | |||
o Attribute Syntax: For a value attribute (see clause 5.13), an ABNF | o Attribute Syntax: For a value attribute (see clause 5.13), an ABNF | |||
definition of the attribute value <att-value> syntax (See | definition of the attribute value <att-value> syntax (see | |||
Section 9) MUST be provided. The syntax MUST follow the rule form | Section 9) MUST be provided. The syntax MUST follow the rule form | |||
as per Section 2.2 of [RFC5234] and [RFC7405]. This SHALL define | as per Section 2.2 of [RFC5234] and [RFC7405]. This SHALL define | |||
the allowable values that the attribute might take. It MAY also | the allowable values that the attribute might take. It MAY also | |||
define an extension method for the addition of future values. For | define an extension method for the addition of future values. For | |||
a property attribute, the ABNF definition is omitted as the | a property attribute, the ABNF definition is omitted as the | |||
property attribute takes no values. | property attribute takes no values. | |||
o Attribute Semantics: For a value attribute, a semantic description | o Attribute Semantics: For a value attribute, a semantic description | |||
of the values that the attribute might take MUST be provided. The | of the values that the attribute might take MUST be provided. The | |||
usage of a property attribute is described under purpose below. | usage of a property attribute is described under purpose below. | |||
skipping to change at page 44, line 43 ¶ | skipping to change at page 45, line 11 ¶ | |||
o Attribute Name: MUST be provided and MUST NOT be changed. | o Attribute Name: MUST be provided and MUST NOT be changed. | |||
Otherwise it is a new attribute. | Otherwise it is a new attribute. | |||
o Attribute Syntax: The existing rule syntax with the syntax | o Attribute Syntax: The existing rule syntax with the syntax | |||
extensions MUST be provided if there is a change to the syntax. A | extensions MUST be provided if there is a change to the syntax. A | |||
revision to an existing attribute usage MAY extend the syntax of | revision to an existing attribute usage MAY extend the syntax of | |||
an attribute, but MUST be backward compatible. | an attribute, but MUST be backward compatible. | |||
o Attribute Semantics: A semantic description of new additional | o Attribute Semantics: A semantic description of new additional | |||
attributes values or a semantic extension of existing values. | attribute values or a semantic extension of existing values. | |||
Existing attribute values semantics MUST only be extended in a | Existing attribute values semantics MUST only be extended in a | |||
backward compatible manner. | backward compatible manner. | |||
o Usage Level: Updates MAY only add additional levels. | o Usage Level: Updates MAY only add additional levels. | |||
o Charset Dependent: MUST NOT be changed. | o Charset Dependent: MUST NOT be changed. | |||
o Purpose: MAY be extended according to the updated usage. | o Purpose: MAY be extended according to the updated usage. | |||
o O/A Procedures: MAY be updated in a backward compatible manner | o O/A Procedures: MAY be updated in a backward compatible manner | |||
skipping to change at page 54, line 28 ¶ | skipping to change at page 54, line 43 ¶ | |||
12.1. Normative References | 12.1. Normative References | |||
[E164] International Telecommunication Union, "E.164 : The | [E164] International Telecommunication Union, "E.164 : The | |||
international public telecommunication numbering plan", | international public telecommunication numbering plan", | |||
ITU Recommendation E.164, November 2010. | ITU Recommendation E.164, November 2010. | |||
[I-D.ietf-mmusic-data-channel-sdpneg] | [I-D.ietf-mmusic-data-channel-sdpneg] | |||
Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., | Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., | |||
Marcon, J., and R. Even, "SDP-based Data Channel | Marcon, J., and R. Even, "SDP-based Data Channel | |||
Negotiation", draft-ietf-mmusic-data-channel-sdpneg-19 | Negotiation", draft-ietf-mmusic-data-channel-sdpneg-20 | |||
(work in progress), May 2018. | (work in progress), June 2018. | |||
[I-D.ietf-mmusic-ice-sip-sdp] | ||||
Petit-Huguenin, M., Nandakumar, S., and A. Keranen, | ||||
"Session Description Protocol (SDP) Offer/Answer | ||||
procedures for Interactive Connectivity Establishment | ||||
(ICE)", draft-ietf-mmusic-ice-sip-sdp-21 (work in | ||||
progress), June 2018. | ||||
[I-D.ietf-mmusic-sdp-mux-attributes] | [I-D.ietf-mmusic-sdp-mux-attributes] | |||
Nandakumar, S., "A Framework for SDP Attributes when | Nandakumar, S., "A Framework for SDP Attributes when | |||
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 | Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 | |||
(work in progress), February 2018. | (work in progress), February 2018. | |||
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", | [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", | |||
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, | STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, | |||
<https://www.rfc-editor.org/info/rfc1034>. | <https://www.rfc-editor.org/info/rfc1034>. | |||
End of changes. 40 change blocks. | ||||
63 lines changed or deleted | 84 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |