draft-ietf-mmusic-rfc4566bis-35.txt | draft-ietf-mmusic-rfc4566bis-36.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: November 4, 2019 C. Perkins | Expires: December 20, 2019 C. Perkins | |||
University of Glasgow | University of Glasgow | |||
M. Handley | M. Handley | |||
UCL | UCL | |||
May 3, 2019 | June 18, 2019 | |||
SDP: Session Description Protocol | SDP: Session Description Protocol | |||
draft-ietf-mmusic-rfc4566bis-35 | draft-ietf-mmusic-rfc4566bis-36 | |||
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 November 4, 2019. | This Internet-Draft will expire on December 20, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 34 ¶ | skipping to change at page 2, line 34 ¶ | |||
2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . . 5 | 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . . 5 | |||
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 5 | 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 5 | |||
3.2. Streaming Media . . . . . . . . . . . . . . . . . . . . . 5 | 3.2. Streaming Media . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.3. Email and the World Wide Web . . . . . . . . . . . . . . 5 | 3.3. Email and the World Wide Web . . . . . . . . . . . . . . 5 | |||
3.4. Multicast Session Announcement . . . . . . . . . . . . . 5 | 3.4. Multicast Session Announcement . . . . . . . . . . . . . 5 | |||
4. Requirements and Recommendations . . . . . . . . . . . . . . 6 | 4. Requirements and Recommendations . . . . . . . . . . . . . . 6 | |||
4.1. Media and Transport Information . . . . . . . . . . . . . 7 | 4.1. Media and Transport Information . . . . . . . . . . . . . 7 | |||
4.2. Timing Information . . . . . . . . . . . . . . . . . . . 7 | 4.2. Timing Information . . . . . . . . . . . . . . . . . . . 7 | |||
4.3. Obtaining Further Information about a Session . . . . . . 8 | 4.3. Obtaining Further Information about a Session . . . . . . 8 | |||
4.4. Categorization . . . . . . . . . . . . . . . . . . . . . 8 | 4.4. Internationalization . . . . . . . . . . . . . . . . . . 8 | |||
4.5. Internationalization . . . . . . . . . . . . . . . . . . 8 | ||||
5. SDP Specification . . . . . . . . . . . . . . . . . . . . . . 8 | 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . . 8 | |||
5.1. Protocol Version ("v=") . . . . . . . . . . . . . . . . . 12 | 5.1. Protocol Version ("v=") . . . . . . . . . . . . . . . . . 12 | |||
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 | |||
skipping to change at page 3, line 10 ¶ | skipping to change at page 3, line 9 ¶ | |||
5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 21 | 5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 21 | |||
5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 21 | 5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 21 | |||
5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 22 | 5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 22 | |||
6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 25 | 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
6.1. cat (category) . . . . . . . . . . . . . . . . . . . . . 25 | 6.1. cat (category) . . . . . . . . . . . . . . . . . . . . . 25 | |||
6.2. keywds (keywords) . . . . . . . . . . . . . . . . . . . . 26 | 6.2. keywds (keywords) . . . . . . . . . . . . . . . . . . . . 26 | |||
6.3. tool . . . . . . . . . . . . . . . . . . . . . . . . . . 26 | 6.3. tool . . . . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
6.4. ptime (packet time) . . . . . . . . . . . . . . . . . . . 27 | 6.4. ptime (packet time) . . . . . . . . . . . . . . . . . . . 27 | |||
6.5. maxptime (maximum packet time) . . . . . . . . . . . . . 27 | 6.5. maxptime (maximum packet time) . . . . . . . . . . . . . 27 | |||
6.6. rtpmap . . . . . . . . . . . . . . . . . . . . . . . . . 28 | 6.6. rtpmap . . . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
6.7. Media Direction Attributes . . . . . . . . . . . . . . . 29 | 6.7. Media Direction Attributes . . . . . . . . . . . . . . . 30 | |||
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) . . . . . . . . . . . . . . . 31 | |||
6.7.3. sendonly (send-only) . . . . . . . . . . . . . . . . 31 | 6.7.3. sendonly (send-only) . . . . . . . . . . . . . . . . 31 | |||
6.7.4. inactive . . . . . . . . . . . . . . . . . . . . . . 31 | 6.7.4. inactive . . . . . . . . . . . . . . . . . . . . . . 32 | |||
6.8. orient (orientation) . . . . . . . . . . . . . . . . . . 32 | 6.8. orient (orientation) . . . . . . . . . . . . . . . . . . 32 | |||
6.9. type (conference type) . . . . . . . . . . . . . . . . . 32 | 6.9. type (conference type) . . . . . . . . . . . . . . . . . 33 | |||
6.10. charset (character set) . . . . . . . . . . . . . . . . . 33 | 6.10. charset (character set) . . . . . . . . . . . . . . . . . 34 | |||
6.11. sdplang (SDP language) . . . . . . . . . . . . . . . . . 34 | 6.11. sdplang (SDP language) . . . . . . . . . . . . . . . . . 34 | |||
6.12. lang (language) . . . . . . . . . . . . . . . . . . . . . 35 | 6.12. lang (language) . . . . . . . . . . . . . . . . . . . . . 35 | |||
6.13. framerate (frame rate) . . . . . . . . . . . . . . . . . 36 | 6.13. framerate (frame rate) . . . . . . . . . . . . . . . . . 36 | |||
6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 36 | 6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 37 | |||
6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 37 | 6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 37 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 38 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 38 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 | |||
8.1. The "application/sdp" Media Type . . . . . . . . . . . . 40 | 8.1. The "application/sdp" Media Type . . . . . . . . . . . . 40 | |||
8.2. Registration of Parameters . . . . . . . . . . . . . . . 41 | 8.2. Registration of Parameters . . . . . . . . . . . . . . . 41 | |||
8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 41 | 8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 41 | |||
8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 42 | 8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 42 | |||
8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 42 | 8.2.3. Attribute Names ("att-field") . . . . . . . . . . . . 43 | |||
8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 43 | 8.2.4. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 46 | |||
8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 46 | 8.2.5. Network Types ("nettype") . . . . . . . . . . . . . . 46 | |||
8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 46 | 8.2.6. Address Types ("addrtype") . . . . . . . . . . . . . 47 | |||
8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 46 | 8.2.7. Registration Procedure . . . . . . . . . . . . . . . 47 | |||
8.2.8. Registration Procedure . . . . . . . . . . . . . . . 47 | ||||
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 and addrtype registries . . 48 | |||
8.5. Reorganization of the att-field Registries . . . . . . . 48 | 8.5. Reorganization of the att-field Registries . . . . . . . 48 | |||
9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 49 | 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 49 | |||
10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 54 | 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 54 | |||
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 55 | 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . 56 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 56 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . 58 | 12.2. Informative References . . . . . . . . . . . . . . . . . 59 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 | |||
1. Introduction | 1. Introduction | |||
When initiating multimedia teleconferences, voice-over-IP calls, | When initiating multimedia teleconferences, voice-over-IP calls, | |||
streaming video, or other sessions, there is a requirement to convey | streaming video, or other sessions, there is a requirement to convey | |||
media details, transport addresses, and other session description | media details, transport addresses, and other session description | |||
metadata to the participants. | metadata to the participants. | |||
SDP provides a standard representation for such information, | SDP provides a standard representation for such information, | |||
irrespective of how that information is transported. SDP is purely a | irrespective of how that information is transported. SDP is purely a | |||
format for session description -- it does not incorporate a transport | format for session description -- it does not incorporate a transport | |||
protocol, and it is intended to use different transport protocols as | protocol, and it is intended to use different transport protocols as | |||
appropriate, including the Session Announcement Protocol (SAP) | appropriate, including the Session Announcement Protocol (SAP) | |||
[RFC2974], Session Initiation Protocol (SIP) [RFC3261], Real Time | [RFC2974], Session Initiation Protocol (SIP) [RFC3261], Real Time | |||
Streaming Protocol (RTSP) [RFC7826], electronic mail using the MIME | Streaming Protocol (RTSP) [RFC7826], electronic mail [RFC5322] using | |||
extensions [RFC5322], and the Hypertext Transport Protocol (HTTP) | the MIME extensions [RFC2045], and the Hypertext Transport Protocol | |||
[RFC7230]. | (HTTP) [RFC7230]. | |||
SDP is intended to be general purpose so that it can be used in a | SDP is intended to be general purpose so that it can be used in a | |||
wide range of network environments and applications. However, it is | wide range of network environments and applications. However, it is | |||
not intended to support negotiation of session content or media | not intended to support negotiation of session content or media | |||
encodings: this is viewed as outside the scope of session | encodings: this is viewed as outside the scope of session | |||
description. | description. | |||
This memo obsoletes [RFC4566]. The changes relative to [RFC4566] are | This memo obsoletes [RFC4566]. The changes relative to [RFC4566] are | |||
outlined in Section 10 of this memo. | outlined in Section 10 of this memo. | |||
skipping to change at page 5, line 14 ¶ | skipping to change at page 5, line 14 ¶ | |||
3. Examples of SDP Usage | 3. Examples of SDP Usage | |||
3.1. Session Initiation | 3.1. Session Initiation | |||
The Session Initiation Protocol (SIP) [RFC3261] is an application- | The Session Initiation Protocol (SIP) [RFC3261] is an application- | |||
layer control protocol for creating, modifying, and terminating | layer control protocol for creating, modifying, and terminating | |||
sessions such as Internet multimedia conferences, Internet telephone | sessions such as Internet multimedia conferences, Internet telephone | |||
calls, and multimedia distribution. The SIP messages used to create | calls, and multimedia distribution. The SIP messages used to create | |||
sessions carry session descriptions that allow participants to agree | sessions carry session descriptions that allow participants to agree | |||
on a set of compatible media types. These session descriptions are | on a set of compatible media types [RFC6838]. These session | |||
commonly formatted using SDP. When used with SIP, the offer/answer | descriptions are commonly formatted using SDP. When used with SIP, | |||
model [RFC3264] provides a limited framework for negotiation using | the offer/answer model [RFC3264] provides a limited framework for | |||
SDP. | negotiation using SDP. | |||
3.2. Streaming Media | 3.2. Streaming Media | |||
The Real Time Streaming Protocol (RTSP) [RFC7826], is an application- | The Real Time Streaming Protocol (RTSP) [RFC7826], is an application- | |||
level protocol for control over the delivery of data with real-time | level protocol for control over the delivery of data with real-time | |||
properties. RTSP provides an extensible framework to enable | properties. RTSP provides an extensible framework to enable | |||
controlled, on-demand delivery of real-time data, such as audio and | controlled, on-demand delivery of real-time data, such as audio and | |||
video. An RTSP client and server negotiate an appropriate set of | video. An RTSP client and server negotiate an appropriate set of | |||
parameters for media delivery, partially using SDP syntax to describe | parameters for media delivery, partially using SDP syntax to describe | |||
those parameters. | those parameters. | |||
skipping to change at page 6, line 15 ¶ | skipping to change at page 6, line 15 ¶ | |||
required to participate in the session. | required to participate in the session. | |||
One protocol used to implement such a distributed directory is the | One protocol used to implement such a distributed directory is the | |||
SAP [RFC2974]. SDP provides the recommended session description | SAP [RFC2974]. SDP provides the recommended session description | |||
format for such session announcements. | format for such session announcements. | |||
4. Requirements and Recommendations | 4. Requirements and Recommendations | |||
The purpose of SDP is to convey information about media streams in | The purpose of SDP is to convey information about media streams in | |||
multimedia sessions to allow the recipients of a session description | multimedia sessions to allow the recipients of a session description | |||
to participate in the session. SDP is primarily intended for use in | to participate in the session. SDP is primarily intended for use | |||
an internetwork, although it is sufficiently general that it can | with Internet protocols, although it is sufficiently general that it | |||
describe multimedia conferences in other network environments. Media | can describe multimedia conferences in other network environments. | |||
streams can be many-to-many. Sessions need not be continually | Media streams can be many-to-many. Sessions need not be continually | |||
active. | active. | |||
Thus far, multicast-based sessions on the Internet have differed from | Thus far, multicast-based sessions on the Internet have differed from | |||
many other forms of conferencing in that anyone receiving the traffic | many other forms of conferencing in that anyone receiving the traffic | |||
can join the session (unless the session traffic is encrypted). In | can join the session (unless the session traffic is encrypted). In | |||
such an environment, SDP serves two primary purposes. It is a means | such an environment, SDP serves two primary purposes. It is a means | |||
to communicate the existence of a session, and it is a means to | to communicate the existence of a session, and it is a means to | |||
convey sufficient information to enable joining and participating in | convey sufficient information to enable joining and participating in | |||
the session. In a unicast environment, only the latter purpose is | the session. In a unicast environment, only the latter purpose is | |||
likely to be relevant. | likely to be relevant. | |||
skipping to change at page 7, line 34 ¶ | skipping to change at page 7, line 34 ¶ | |||
This address and port are the destination address and destination | This address and port are the destination address and destination | |||
port of the multicast stream, whether being sent, received, or both. | port 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 the address and port depend on context. Typically, | |||
transport protocol defined. By default, this SHOULD be the remote | this SHOULD be the remote address and remote port to which media is | |||
address and remote port to which media is sent. Some media types may | to be sent or received. Details may differ based on the network | |||
redefine this behavior, but this is NOT RECOMMENDED since it | type, address type, protocol and media specified, and whether the SDP | |||
complicates implementations (including middleboxes that must parse | is being distributed as an advertisement or negotiated in an offer/ | |||
the addresses to open Network Address Translation (NAT) or firewall | answer [RFC3264] exchange. (E.g., Some address types or protocols | |||
pinholes). | may not have a notion of port.) Deviating from typical behavior | |||
should be done cautiously since this complicates implementations | ||||
(including middleboxes that must parse the addresses to open Network | ||||
Address Translation (NAT) or firewall 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: | |||
o An arbitrary list of start and stop times bounding the session | o An arbitrary list of start and stop times bounding the session | |||
o For each bound, repeat times such as "every Wednesday at 10am for | o For each bound, repeat times such as "every Wednesday at 10am for | |||
one hour" | one hour" | |||
This timing information is globally consistent, irrespective of local | This timing information is globally consistent, irrespective of local | |||
time zone or daylight saving time (see Section 5.9). | time zone or daylight saving time (see Section 5.9). | |||
4.3. Obtaining Further Information about a Session | 4.3. Obtaining Further Information about a Session | |||
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 | |||
skipping to change at page 8, line 13 ¶ | skipping to change at page 8, line 15 ¶ | |||
one hour" | one hour" | |||
This timing information is globally consistent, irrespective of local | This timing information is globally consistent, irrespective of local | |||
time zone or daylight saving time (see Section 5.9). | time zone or daylight saving time (see Section 5.9). | |||
4.3. Obtaining Further Information about a Session | 4.3. Obtaining Further Information about a Session | |||
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) [RFC3986] for more information about the session. (Note that | |||
use of URIs to indicate remote resources is subject to the security | ||||
4.4. Categorization | considerations from [RFC3986].) | |||
When many session descriptions are being distributed by an | ||||
advertisement mechanism, it may be desirable to filter session | ||||
descriptions that are of interest from those that are not. SDP | ||||
supports a categorization mechanism for sessions that is capable of | ||||
being automated (the "a=cat:" attribute; see Section 6). | ||||
4.5. 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 to be used | SDP also allows other character sets such as [ISO.8859-1.1998] to be | |||
when desired. Internationalization only applies to free-text sub- | used when desired. Internationalization only applies to free-text | |||
fields (session name and background information), and not to SDP as a | sub-fields (session name and background information), and not to SDP | |||
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 | |||
character set in UTF-8 encoding, or some other character set defined | character set in UTF-8 encoding, or some other character set defined | |||
skipping to change at page 9, line 6 ¶ | skipping to change at page 8, line 51 ¶ | |||
opposed to a binary encoding such as ASN.1 or XDR, was chosen to | opposed to a binary encoding such as ASN.1 or XDR, was chosen to | |||
enhance portability, to enable a variety of transports to be used, | enhance portability, to enable a variety of transports to be used, | |||
and to allow flexible, text-based toolkits to be used to generate and | and to 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 descriptions 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 descriptions 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. | |||
session descriptions for which a receiver does not have the correct | ||||
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> is exactly one case-significant character and <value> is | |||
<value> is structured text whose format depends on <type>. In | structured text whose format depends on <type>. In general, <value> | |||
general, <value> is either a number of sub-fields delimited by a | is either a number of sub-fields delimited by a single space | |||
single space character or a free format string, and is case- | character or a free format string, and is case-significant unless a | |||
significant unless a specific field defines otherwise. Whitespace | specific field defines otherwise. Whitespace separators are not used | |||
separators MUST NOT be used on either side of the "=" sign, however, | on either side of the "=" sign, however, the value can contain a | |||
the value can contain a leading whitespace as part of its syntax, | leading whitespace as part of its syntax, i.e., that whitespace is | |||
i.e., that whitespace is part of the value. | part of 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 | |||
comes first. In general, session-level values are the default for | comes first. In general, session-level values are the default for | |||
all media unless overridden by an equivalent media-level value. | all media unless overridden by an equivalent media-level value. | |||
Some lines in each description are required and some are optional, | Some lines in each description are required and some are optional, | |||
but all must appear in exactly the order given here. (The fixed | but when present must appear in exactly the order given here. (The | |||
order greatly enhances error detection and allows for a simple | fixed order greatly enhances error detection and allows for a simple | |||
parser). In the following overview optional items are marked with a | parser). In the following overview optional items are marked with a | |||
"*". | "*". | |||
Session description | Session description | |||
v= (protocol version) | v= (protocol version) | |||
o= (originator and session identifier) | o= (originator and session identifier) | |||
s= (session name) | s= (session name) | |||
i=* (session information) | i=* (session information) | |||
u=* (URI of description) | u=* (URI of description) | |||
e=* (email address) | e=* (email address) | |||
skipping to change at page 10, line 37 ¶ | skipping to change at page 10, line 37 ¶ | |||
Media description, if present | Media description, if present | |||
m= (media name and transport address) | m= (media name and transport address) | |||
i=* (media title) | i=* (media title) | |||
c=* (connection information -- optional if included at | c=* (connection information -- optional if included at | |||
session level) | session level) | |||
b=* (zero or more bandwidth information lines) | b=* (zero or more bandwidth information lines) | |||
k=* (obsolete) | k=* (obsolete) | |||
a=* (zero or more media attribute lines) | a=* (zero or more media attribute lines) | |||
The set of type letters is deliberately small and not intended to be | The set of type letters is deliberately small and not intended to be | |||
extensible -- an SDP parser MUST completely ignore any session | extensible -- an SDP parser MUST completely ignore or reject any | |||
description that contains a type letter that it does not understand. | session description that contains a type letter that it does not | |||
The attribute mechanism ("a=" described below) is the primary means | understand. The attribute mechanism ("a=" described below) is the | |||
for extending SDP and tailoring it to particular applications or | primary means for extending SDP and tailoring it to particular | |||
media. Some attributes (the ones listed in Section 6 of this memo) | applications or media. Some attributes (the ones listed in Section 6 | |||
have a defined meaning, but others may be added on a media- or | of this memo) have a defined meaning, but others may be added on a | |||
session-specific basis. (Attribute scopes in addition to media- | media- or session-specific basis. (Attribute scopes in addition to | |||
specific and session-specific may also be defined in extensions to | media-specific and session-specific may also be defined in extensions | |||
this document. E.g., [RFC5576], | to this document. E.g., [RFC5576], | |||
[I-D.ietf-mmusic-data-channel-sdpneg].) An SDP parser MUST ignore | [I-D.ietf-mmusic-data-channel-sdpneg].) An SDP parser MUST ignore | |||
any attribute it doesn't understand. | any attribute it doesn't understand. | |||
An SDP description may contain URIs that reference external content | An SDP description may contain URIs that reference external content | |||
in the "u=", "k=", and "a=" lines. These URIs may be dereferenced in | in the "u=", "k=", and "a=" lines. These URIs may be dereferenced in | |||
some cases, making the session description non-self-contained. | some cases, making the session description non-self-contained. | |||
The connection ("c=") information in the session-level section | The connection ("c=") information in the session-level section | |||
applies to all the media descriptions of that session unless | applies to all the media descriptions of that session unless | |||
overridden by connection information in the media description. For | overridden by connection information in the media description. For | |||
instance, in the example below, each audio media description behaves | instance, in the example below, each audio media description behaves | |||
as if it were given a "c=IN IP4 233.252.0.2". | as if it were given a "c=IN IP4 198.51.100.1". | |||
An example SDP description is: | An example SDP description is: | |||
v=0 | v=0 | |||
o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 | o=jdoe 3724394400 3724394405 IN IP4 198.51.100.1 | |||
s=SDP Seminar | s=Call to John Smith | |||
i=A Seminar on the session description protocol | i=SDP Offer #1 | |||
u=http://www.example.com/seminars/sdp.pdf | u=http://www.jdoe.example.com/home.html | |||
e=j.doe@example.com (Jane Doe) | e=Jane Doe <jane@jdoe.example.com> | |||
c=IN IP4 233.252.0.2 | p=+1 617 555-6011 | |||
t=2873397496 2873404696 | c=IN IP4 198.51.100.1 | |||
a=recvonly | t=0 0 | |||
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 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 not | |||
present, these octet strings MUST be interpreted as containing | present, these octet strings MUST be interpreted as containing | |||
ISO-10646 characters in UTF-8 encoding (the presence of the | ISO-10646 characters in UTF-8 encoding. When the "a=charset" | |||
"a=charset" attribute may force some fields to be interpreted | attribute is present the session-name-field, information-field, and | |||
differently). | some attribute fields are interpreted according to the selected | |||
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], [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 | |||
[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). | |||
5.1. Protocol Version ("v=") | 5.1. Protocol Version ("v=") | |||
v=0 | v=0 | |||
skipping to change at page 12, line 29 ¶ | skipping to change at page 12, line 29 ¶ | |||
username and the address of the user's host) plus a session | username and the address of the user's host) plus a session | |||
identifier and version number: | identifier and version number: | |||
<username> is the user's login on the originating host, or it is "-" | <username> is the user's login on the originating host, or it is "-" | |||
if the originating host does not support the concept of user IDs. | if the originating host does not support the concept of user IDs. | |||
The <username> MUST NOT contain spaces. | The <username> MUST NOT contain spaces. | |||
<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 a timestamp, in | |||
suggested that a Network Time Protocol (NTP) format timestamp be | seconds since January 1, 1900 UTC, is recommended to ensure | |||
used to ensure uniqueness [RFC5905]. | uniqueness. | |||
<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 description. | increased when a modification is made to the session description. | |||
Again, it is RECOMMENDED that an NTP format timestamp is used. | Again, as with <sess-id> it is RECOMMENDED that a timestamp be | |||
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 | |||
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 a | |||
fully qualified domain name of the machine or the dotted-decimal | 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 name | |||
of the machine or the compressed textual representation of an IP | of the machine or the address of the machine represented as | |||
version 6 address of the machine. For both IP4 and IP6, the fully | specified in Section 4 of [RFC5952]. For both IP4 and IP6, the | |||
qualified domain name is the form that SHOULD be given unless this | fully qualified domain name is the form that SHOULD be given | |||
is unavailable, in which case a globally unique address MAY be | unless this is unavailable, in which case a globally unique | |||
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 sub-fields 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 and SHOULD contain ISO 10646 | The "s=" line MUST NOT be empty. If a session has no meaningful | |||
characters (but see also the "a=charset" attribute). If a session | name, then "s= " or "s=-" (i.e., a single space or dash as the | |||
has no meaningful name, the "s= " line SHOULD be used (i.e., a single | session name) is RECOMMENDED. If a session-level "a=charset" | |||
space as the session name). | attribute is present, it specifies the character set used in the "s=" | |||
field. If a session-level "a=charset" attribute is not present, the | ||||
"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 MUST 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 used | |||
in the "i=" line. If the "a=charset" attribute is not present, the | in the "i=" line. If the "a=charset" attribute is not present, the | |||
"i=" line MUST contain ISO 10646 characters in UTF-8 encoding. | "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 labelling | media definitions, "i=" lines are primarily intended for labelling | |||
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 | |||
skipping to change at page 14, line 14 ¶ | skipping to change at page 14, line 14 ¶ | |||
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 | |||
not suitable for parsing by automata. | not suitable for parsing by automata. | |||
5.5. URI ("u=") | 5.5. URI ("u=") | |||
u=<uri> | u=<uri> | |||
The "u=" line (uri-field) provides a URI (Uniform Resource | The "u=" line (uri-field) provides a URI (Uniform Resource | |||
Identifier) as used by WWW clients [RFC3986]. The URI should be a | Identifier) [RFC3986]. The URI should be a pointer to additional | |||
pointer to additional information about the session. This line is | human readable information about the session. This line is OPTIONAL. | |||
OPTIONAL. No more than one "u=" line is allowed per session | No more than one "u=" line is allowed per session description. | |||
description. | ||||
5.6. Email Address and Phone Number ("e=" and "p=") | 5.6. Email Address and Phone Number ("e=" and "p=") | |||
e=<email-address> | e=<email-address> | |||
p=<phone-number> | p=<phone-number> | |||
The "e=" line (email-field) and "p=" line (phone-field) specify | The "e=" line (email-field) and "p=" line (phone-field) specify | |||
contact information for the person responsible for the session. This | contact information for the person responsible for the session. This | |||
is not necessarily the same person that created the session | is not necessarily the same person that created the session | |||
description. | description. | |||
skipping to change at page 16, line 46 ¶ | skipping to change at page 16, line 46 ¶ | |||
would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3 | would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3 | |||
are to be used with a TTL of 127. This is semantically identical to | are to be used with a TTL of 127. This is semantically identical to | |||
including multiple "c=" lines in a media description: | including multiple "c=" lines in a media description: | |||
c=IN IP4 233.252.0.1/127 | c=IN IP4 233.252.0.1/127 | |||
c=IN IP4 233.252.0.2/127 | c=IN IP4 233.252.0.2/127 | |||
c=IN IP4 233.252.0.3/127 | c=IN IP4 233.252.0.3/127 | |||
Similarly, an IPv6 example would be: | Similarly, an IPv6 example would be: | |||
c=IN IP6 FF15::101/3 | c=IN IP6 ff00::db8:0:101/3 | |||
which is semantically equivalent to: | which is semantically equivalent to: | |||
c=IN IP6 FF15::101 | c=IN IP6 ff00::db8:0:101 | |||
c=IN IP6 FF15::102 | c=IN IP6 ff00::db8:0:102 | |||
c=IN IP6 FF15::103 | c=IN IP6 ff00::db8:0:103 | |||
(remembering that the TTL sub-field is not present in IP6 multicast). | (remembering that the TTL sub-field 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 | |||
skipping to change at page 17, line 35 ¶ | skipping to change at page 17, line 35 ¶ | |||
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 giving the meaning of the | <bwtype> is an alphanumeric modifier giving the meaning of the | |||
<bandwidth> figure. Two values are defined in this specification, | <bandwidth> figure. 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 session giving the proposed upper limit to the bandwidth used | the session giving the proposed upper limit to the bandwidth used | |||
(the "conference total" bandwidth). Similarly, if the bandwidth | (the "conference total" bandwidth). Similarly, if the bandwidth | |||
of bundled media streams in an "m=" line is different from the | of bundled media streams [I-D.ietf-mmusic-sdp-bundle-negotiation] | |||
implicit value from the scope, a "b=CT:..." line SHOULD be | in an "m=" line is different from the implicit value from the | |||
supplied in the media level. The primary purpose of this is to | scope, a "b=CT:..." line SHOULD be supplied in the media level. | |||
give an approximate idea as to whether two or more sessions (or | The primary purpose of this is to give an approximate idea as to | |||
bundled media streams) can coexist simultaneously. Note that CT | whether two or more sessions (or bundled media streams) can | |||
gives a total bandwidth figure for all the media at all endpoints. | coexist simultaneously. Note that CT gives a total bandwidth | |||
figure for all the media at all endpoints. | ||||
AS The bandwidth is interpreted to be application specific (it will | AS The bandwidth is interpreted to be application specific (it will | |||
be the application's concept of maximum bandwidth). Normally, | be the application's concept of maximum bandwidth). Normally, | |||
this will coincide with what is set on the application's "maximum | this will coincide with what is set on the application's "maximum | |||
bandwidth" control if applicable. For RTP-based applications, AS | bandwidth" control if applicable. For RTP-based applications, AS | |||
gives the RTP "session bandwidth" as defined in Section 6.2 of | gives the RTP "session bandwidth" as defined in Section 6.2 of | |||
[RFC3550]. Note that AS gives a bandwidth figure for a single | [RFC3550]. Note that AS gives a bandwidth figure for a single | |||
media at a single endpoint, although there may be many endpoints | media at a single endpoint, although there may be many endpoints | |||
sending simultaneously. | sending simultaneously. | |||
skipping to change at page 18, line 40 ¶ | skipping to change at page 18, line 43 ¶ | |||
(see below) can be included following the time-field -- in which case | (see below) can be included following the time-field -- in which case | |||
the time-field specifies the start and stop times of the entire | the time-field specifies the start and stop times of the entire | |||
repeat sequence. | 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 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 are the decimal | |||
decimal representation of Network Time Protocol (NTP) time values in | representation of time values in seconds since January 1, 1900 UTC. | |||
seconds since 1900 [RFC5905]. To convert these values to UNIX time | To convert these values to UNIX time (UTC), subtract decimal | |||
(UTC), subtract decimal 2208988800. | 2208988800. | |||
NTP timestamps are elsewhere represented by 64-bit values, which wrap | Some time representations will wrap in the year 2036. Because SDP | |||
sometime in the year 2036. Since SDP uses an arbitrary length | uses an arbitrary length decimal representation, it does not have | |||
decimal representation, this should not cause an issue (SDP | this issue. Implementations of SDP need to be prepared to handle | |||
timestamps MUST continue counting seconds since 1900 - NTP will use | these larger values. | |||
the value modulo the 64-bit limit). | ||||
If the <stop-time> is set to zero, then the session is not bounded, | If the <stop-time> is set to zero, then the session is not bounded, | |||
though it will not become active until after the <start-time>. If | though it will not become active until after the <start-time>. If | |||
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. | |||
skipping to change at page 19, line 34 ¶ | skipping to change at page 19, line 34 ¶ | |||
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 NTP | <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 NTP representation of the end of the last session | time would be the representation of the end of the last session three | |||
three months later. By default, all sub-fields are in seconds, so | months later. By default, all sub-fields are in seconds, so the "r=" | |||
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 | |||
instead. The following unit specification characters are allowed: | instead. The following unit specification characters are allowed: | |||
skipping to change at page 20, line 35 ¶ | skipping to change at page 20, line 35 ¶ | |||
To schedule a repeated session that spans a change from daylight | To schedule a repeated session that spans a change from daylight | |||
saving time to standard time or vice versa, it is necessary to | saving time to standard time or vice versa, it is necessary to | |||
specify offsets from the base time. This is required because | specify offsets from the base time. This is required because | |||
different time zones change time at different times of day, different | different time zones change time at different times of day, different | |||
countries change to or from daylight saving time on different dates, | countries change to or from daylight saving time on different dates, | |||
and some countries do not have daylight saving time at all. | and some countries do not have daylight saving time at all. | |||
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 time (represented as | |||
zone adjustment happens and the offset from the time when the session | seconds since January 1, 1900 UTC) that a time zone adjustment | |||
was first scheduled. The "z=" line allows the sender to specify a | happens and the offset from the time when the session was first | |||
list of these adjustment times and offsets from the base time. | scheduled. The "z=" line allows the sender to specify a list of | |||
these adjustment times and offsets from the base time. | ||||
An example might be the following: | An example might be the following: | |||
t=3724394400 3754123200 ; Mon 8-Jan-2018 10:00 UTC | t=3724394400 3754123200 ; Mon 8-Jan-2018 10:00 UTC | |||
; Tues 18-Dec-2018 12:00 UTC | ; Tues 18-Dec-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 | |||
z=3730928400 -1h 3749680800 0 ; Sun 25-Mar-2018 1:00 UTC, | z=3730928400 -1h 3749680800 0 ; Sun 25-Mar-2018 1:00 UTC, | |||
; offset 1 hour, | ; offset 1 hour, | |||
; Sun 28-Oct-2018 2:00 UTC, no offset | ; Sun 28-Oct-2018 2:00 UTC, | |||
; no offset | ||||
This specifies that at time 3730928400 (Sun 25-Mar-2018 1:00 UTC, the | This specifies that at time 3730928400 (Sun 25-Mar-2018 1:00 UTC, the | |||
onset of British Summer Time) the time base by which the session's | onset of British Summer Time) the time base by which the session's | |||
repeat times are calculated is shifted back by 1 hour, and that at | repeat times are calculated is shifted back by 1 hour, and that at | |||
time 3749680800 (Sun 28-Oct-2018 2:00 UTC, the end of British Summer | time 3749680800 (Sun 28-Oct-2018 2:00 UTC, the end of British Summer | |||
Time) the session's original time base is restored. Adjustments are | Time) the session's original time base is restored. Adjustments are | |||
always relative to the specified start time -- they are not | always relative to the specified start time -- they are not | |||
cumulative. | 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 | |||
skipping to change at page 23, line 40 ¶ | skipping to change at page 23, line 45 ¶ | |||
hierarchically encoded streams using non-contiguous ports. (There | hierarchically encoded streams using non-contiguous 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:" defined in [RFC3605] does not handle hierarchical | |||
encoding.) If a need arises to declare non-contiguous ports then | encoding.) If a need arises to declare non-contiguous ports then | |||
it will be necessary to define a new attribute to do so. | 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: | |||
c=IN IP4 233.252.0.1/127/2 | ||||
m=video 49170/2 RTP/AVP 31 | m=video 49170/2 RTP/AVP 31 | |||
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. | |||
The mapping is similar if multiple addresses are specified using | ||||
multiple "c=" lines. For example: | ||||
m=video 49170/2 RTP/AVP 31 | ||||
c=IN IP6 ff00::db8:0:101 | ||||
c=IN IP6 ff00::db8:0:102 | ||||
would imply that address ff00::db8:0:101 is used with ports 49170 | ||||
and 49171, and address ff00::db8:0:102 is used with ports 49172 | ||||
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 | express the intended semantics. For instance, see | |||
[I-D.ietf-mmusic-sdp-bundle-negotiation]. | [I-D.ietf-mmusic-sdp-bundle-negotiation]. | |||
<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 sub-field in the | |||
relevant "c=" line. Thus a "c=" line with an address type of IP4 | relevant "c=" line. Thus a "c=" line with an address type of IP4 | |||
skipping to change at page 26, line 24 ¶ | skipping to change at page 26, line 38 ¶ | |||
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 is to assist identifying wanted sessions | Like the cat attribute, this was intended to assist identifying | |||
at the receiver. This allows a receiver to select interesting | wanted sessions at the receiver. This allows a receiver to select | |||
sessions based on keywords describing the purpose of the session; | interesting sessions based on keywords describing the purpose of the | |||
there is no central registry of keywords. Its value should be | session; there is no central registry of keywords. Its value should | |||
interpreted in the charset specified for the session description if | be interpreted in the charset specified for the session description | |||
one is specified, or by default in ISO 10646/UTF-8. This attribute | if one is specified, or by default in ISO 10646/UTF-8. This | |||
is obsolete and SHOULD NOT be used. It SHOULD be ignored if | attribute is obsolete and SHOULD NOT be used. It SHOULD be ignored | |||
received. | if received. | |||
6.3. tool | 6.3. tool | |||
Name: tool | Name: tool | |||
Value: tool-value | Value: tool-value | |||
Usage Level: session | Usage Level: session | |||
Charset Dependent: no | Charset Dependent: no | |||
Syntax: | Syntax: | |||
tool-value = tool-name-and-version | tool-value = tool-name-and-version | |||
tool-name-and-version = text | tool-name-and-version = text | |||
Example: | Example: | |||
skipping to change at page 29, line 44 ¶ | skipping to change at page 30, line 9 ¶ | |||
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 above. | "ptime" attribute is used as given above. | |||
6.7. Media Direction Attributes | 6.7. Media Direction Attributes | |||
At most one occurence of recvonly, sendrecv, sendonly, or inactive | At most one occurrence of recvonly, sendrecv, sendonly, or inactive | |||
MAY appear at session level, and at most one MAY appear in each media | MAY appear at session level, and at most one MAY appear in each media | |||
description. | 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 appear in a media description | for that media description. If none appear 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, "sendrecv" SHOULD be assumed as the | |||
default for sessions that are not of the multimedia conference type | default. | |||
"broadcast" or "H332" (see below). | ||||
Within the following SDP example, the "inactive" attribute applies to | Within the following SDP example, the "sendrecv" attribute applies to | |||
audio media and the "recvonly" attribute applies to video media. | the first audio media and the "inactive" attribute applies to the | |||
others. | ||||
v=0 | v=0 | |||
o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 | o=jdoe 3724395000 3724395001 IN IP6 2001:db8::1 | |||
s=SDP Seminar | s=- | |||
i=A Seminar on the session description protocol | c=IN IP6 2001:db8::1 | |||
u=http://www.example.com/seminars/sdp.pdf | t=0 0 | |||
e=j.doe@example.com (Jane Doe) | a=inactive | |||
c=IN IP4 233.252.0.1/127 | m=audio 49170 RTP/AVP 0 | |||
t=2873397496 2873404696 | a=sendrecv | |||
a=inactive | m=audio 49180 RTP/AVP 0 | |||
m=audio 49170 RTP/AVP 0 | m=video 51372 RTP/AVP 99 | |||
m=video 51372 RTP/AVP 99 | a=rtpmap:99 h263-1998/90000 | |||
a=rtpmap:99 h263-1998/90000 | ||||
a=recvonly | ||||
6.7.1. recvonly (receive-only) | 6.7.1. recvonly (receive-only) | |||
Name: recvonly | Name: recvonly | |||
Value: | Value: | |||
Usage Level: session, media | Usage Level: session, media | |||
Charset Dependent: no | Charset Dependent: no | |||
skipping to change at page 33, line 20 ¶ | skipping to change at page 33, line 31 ¶ | |||
meeting = %s"meeting" | meeting = %s"meeting" | |||
moderated = %s"moderated" | moderated = %s"moderated" | |||
test = %s"test" | test = %s"test" | |||
H332 = %s"H332" | H332 = %s"H332" | |||
; NOTE: These names are case-sensitive. | ; NOTE: These names are case-sensitive. | |||
Example: | Example: | |||
a=type:moderated | a=type:moderated | |||
This specifies the type of the multimedia conference. Suggested | This specifies the type of the multimedia conference. Allowed values | |||
values are "broadcast", "meeting", "moderated", "test", and "H332". | are "broadcast", "meeting", "moderated", "test", and "H332". These | |||
"recvonly" should be the default for "type:broadcast" sessions, | values have implications for other options that are likely to be | |||
"type:meeting" should imply "sendrecv", and "type:moderated" should | appropriate: | |||
indicate the use of a floor control tool and that the media tools are | ||||
started so as to mute new sites joining the multimedia conference. | ||||
Specifying the attribute "type:H332" indicates that this loosely | o When "a=type:broadcast" is specified, "a=recvonly" is probably | |||
coupled session is part of an H.332 session as defined in the ITU | appropriate for those connecting. | |||
H.332 specification [ITU.H332.1998]. Media tools should be started | ||||
"recvonly". | ||||
Specifying the attribute "type:test" is suggested as a hint that, | o When "a=type:meeting" is specified, "a=sendrecv" is likely to be | |||
unless explicitly requested otherwise, receivers can safely avoid | appropriate. | |||
displaying this session description to users. | ||||
o "a=type:moderated" suggests the use of a floor control tool and | ||||
that the media tools be started so as to mute new sites joining | ||||
the multimedia conference. | ||||
o Specifying "a=type:H332" indicates that this loosely coupled | ||||
session is part of an H.332 session as defined in the ITU H.332 | ||||
specification [ITU.H332.1998]. Media tools should be started | ||||
using "a=recvonly". | ||||
o Specifying "a=type:test" is suggested as a hint that, unless | ||||
explicitly requested otherwise, receivers can safely avoid | ||||
displaying this session description to users. | ||||
6.10. charset (character set) | 6.10. charset (character set) | |||
Name: charset | Name: charset | |||
Value: charset-value | Value: charset-value | |||
Usage Level: session | Usage Level: session | |||
Charset Dependent: no | Charset Dependent: no | |||
skipping to change at page 34, line 13 ¶ | skipping to change at page 34, line 34 ¶ | |||
name and information data. By default, the ISO-10646 character set | name and information data. By default, the ISO-10646 character set | |||
in UTF-8 encoding is used. If a more compact representation is | in UTF-8 encoding is used. If a more compact representation is | |||
required, other character sets may be used. For example, the ISO | required, other character sets may be used. For example, the ISO | |||
8859-1 is specified with the following SDP attribute: | 8859-1 is specified with the following SDP attribute: | |||
a=charset:ISO-8859-1 | a=charset:ISO-8859-1 | |||
The charset specified MUST be one of those registered in the IANA | The charset specified MUST be one of those registered in the IANA | |||
Character Sets registry (http://www.iana.org/assignments/character- | Character Sets registry (http://www.iana.org/assignments/character- | |||
sets), such as ISO-8859-1. The character set identifier is a string | sets), such as ISO-8859-1. The character set identifier is a string | |||
in the US-ASCII subset of UTF-8 and MUST be compared against | that MUST be compared against identifiers from the "Name" or | |||
identifiers from the "Name" or "Preferred MIME Name" field of the | "Preferred MIME Name" field of the registry using a case-insensitive | |||
registry using a case-insensitive comparison. If the identifier is | comparison. If the identifier is not recognized or not supported, | |||
not recognised or not supported, all strings that are affected by it | all strings that are affected by it SHOULD be regarded as octet | |||
SHOULD be regarded as octet strings. | strings. | |||
Note that a character set specified MUST still prohibit the use of | Charset-dependent fields MUST contain only sequences of bytes that | |||
bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets requiring | are valid according to the definition of the selected character set. | |||
the use of these characters MUST define a quoting mechanism that | Furthermore, charset-dependent fields MUST NOT contain the bytes 0x00 | |||
prevents these bytes from appearing within text fields. | (Nul), 0x0A (LF), and 0x0d (CR). | |||
6.11. sdplang (SDP language) | 6.11. sdplang (SDP language) | |||
Name: sdplang | Name: sdplang | |||
Value: sdplang-value | Value: sdplang-value | |||
Usage Level: session, media | Usage Level: session, media | |||
Charset Dependent: no | Charset Dependent: no | |||
Syntax: | Syntax: | |||
sdplang-value = Language-Tag | sdplang-value = Language-Tag | |||
; Language-Tag defined in RFC5646 | ; Language-Tag defined in RFC5646 | |||
Example: | Example: | |||
a=sdplang:fr | a=sdplang:fr | |||
skipping to change at page 35, line 13 ¶ | skipping to change at page 35, line 32 ¶ | |||
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 sdplang attributes specified at session | |||
level. | level. | |||
In general, sending session descriptions consisting of multiple | In general, sending session descriptions consisting of multiple | |||
languages is discouraged. Instead, multiple sesssion descriptions | languages is discouraged. Instead, multiple sesssion 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 sdplang attributes are allowed although NOT RECOMMENDED. | |||
The "sdplang" attribute value must be a single [RFC5646] language tag | The "sdplang" attribute value must be a single [RFC5646] language | |||
in the US-ASCII subset of UTF-8. An "sdplang" attribute SHOULD be | tag. An "sdplang" attribute SHOULD be specified when a session is | |||
specified when a session is distributed with sufficient scope to | distributed with sufficient scope to cross geographic boundaries, | |||
cross geographic boundaries, where the language of recipients cannot | where the language of recipients cannot be assumed, or where the | |||
be assumed, or where the session is in a different language from the | session is in a different language from the locally assumed norm. | |||
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 | |||
skipping to change at page 35, line 50 ¶ | skipping to change at page 36, line 20 ¶ | |||
level if the session or media has capabilities in more than one | 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, lang specifies a language capability | |||
for the session being described. As a media-level attribute, it | for the session being described. As a media-level attribute, it | |||
specifies a language capability for that media, overriding any | specifies a language capability for that media, overriding any | |||
session-level language(s) specified. | session-level language(s) specified. | |||
The "lang" attribute value must be a single [RFC5646] language tag in | The "lang" attribute value must be a single [RFC5646] language tag. | |||
the US-ASCII subset of UTF-8. A "lang" attribute SHOULD be specified | A "lang" attribute SHOULD be specified when a session is of | |||
when a session is of sufficient scope to cross geographic boundaries | sufficient scope to cross geographic boundaries where the language of | |||
where the language of participants cannot be assumed, or where the | participants cannot be assumed, or where the session has capabilities | |||
session has capabilities in languages different from the locally | in languages different from the locally assumed norm. | |||
assumed norm. | ||||
The "lang" attribute is supposed to be used for setting the initial | The "lang" attribute is supposed to be used for setting the initial | |||
language(s) used in the session. Events during the session may | language(s) used in the session. Events during the session may | |||
influence which language(s) are used, and the participants are not | influence which language(s) are used, and the participants are not | |||
strictly bound to only use the declared languages. | 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 'lang' attribute is specified, | |||
the "lang" attribute itself does not provide any information about | the "lang" attribute itself does not provide any information about | |||
skipping to change at page 38, line 40 ¶ | skipping to change at page 39, line 10 ¶ | |||
because, among other attacks, the media sessions received may not be | because, among other attacks, the media sessions received may not be | |||
the intended ones, the destination where media is sent to may not be | the intended ones, the destination where media is sent to may not be | |||
the expected one, any of the parameters of the session may be | the expected one, any of the parameters of the session may be | |||
incorrect, or the media security may be compromised. It is up to the | incorrect, or the media security may be compromised. It is up to the | |||
endpoint to make a sensible decision taking into account the security | endpoint to make a sensible decision taking into account the security | |||
risks of the application and the user preferences - the endpoint may | risks of the application and the user preferences - the endpoint may | |||
decide to ask the user whether or not to accept the session. | decide to ask the user whether or not to accept the session. | |||
On receiving a session description over an unauthenticated transport | On receiving a session description over an unauthenticated transport | |||
mechanism or from an untrusted party, software parsing the session | mechanism or from an untrusted party, software parsing the session | |||
should take a few precautions. Similar concerns apply if integrity | description should take a few precautions. Similar concerns apply if | |||
protection is not in place. Session descriptions contain information | integrity protection is not in place. Session descriptions contain | |||
required to start software on the receiver's system. Software that | information required to start software on the receiver's system. | |||
parses a session description MUST NOT be able to start other software | Software that parses a session description MUST NOT be able to start | |||
except that which is specifically configured as appropriate software | other software except that which is specifically configured as | |||
to participate in multimedia sessions. It is normally considered | appropriate software to participate in multimedia sessions. It is | |||
inappropriate for software parsing a session description to start, on | normally considered inappropriate for software parsing a session | |||
a user's system, software that is appropriate to participate in | description to start, on a user's system, software that is | |||
multimedia sessions, without the user first being informed that such | appropriate to participate in multimedia sessions, without the user | |||
software will be started and giving the user's consent. Thus, a | first being informed that such software will be started and giving | |||
session description arriving by session announcement, email, session | the user's consent. Thus, a session description arriving by session | |||
invitation, or WWW page MUST NOT deliver the user into an interactive | announcement, email, session invitation, or WWW page MUST NOT deliver | |||
multimedia session unless the user has explicitly pre-authorized such | the user into an interactive multimedia session unless the user has | |||
action. As it is not always simple to tell whether or not a session | explicitly pre-authorized such action. As it is not always simple to | |||
is interactive, applications that are unsure should assume sessions | tell whether or not a session is interactive, applications that are | |||
are interactive. | unsure should assume sessions are interactive. Software processing | |||
URLs contained in session descriptions should also heed the security | ||||
considerations identified in [RFC3986]. | ||||
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 behavior for an unknown attribute is to | multimedia data. The default behavior for an unknown attribute is to | |||
ignore it. | ignore it. | |||
skipping to change at page 39, line 37 ¶ | skipping to change at page 40, line 9 ¶ | |||
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). Use of some procedures and SDP extensions (e.g., ICE | RTSP). Use of some procedures and SDP extensions (e.g., ICE | |||
[RFC8445] and ICE-SIP-SDP [I-D.ietf-mmusic-ice-sip-sdp]) may avoid | [RFC8445] and ICE-SIP-SDP [I-D.ietf-mmusic-ice-sip-sdp]) may avoid | |||
the need for intermediaries to modify SDP. | the need for intermediaries to modify SDP. | |||
Use of the "k=" line poses a significant security risk, since it | SDP MUST NOT be used to convey keying material (e.g., using | |||
conveys session encryption keys in the clear. SDP MUST NOT be used | "a=crypto" [RFC4568]) unless it can be guaranteed that the channel | |||
to convey keying material, 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. Moreover, the "k=" line provides no way to indicate | ||||
or negotiate cryptographic key algorithms. As it provides for only a | ||||
single symmetric key, rather than separate keys for confidentiality | ||||
and integrity, its utility is severely limited. The "k=" line MUST | ||||
NOT be used, as discussed in Section 5.12. | ||||
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. | |||
To: ietf-types@iana.org | To: ietf-types@iana.org | |||
Subject: Registration of media type "application/sdp" | Subject: Registration of media type "application/sdp" | |||
Type name: application | Type name: application | |||
skipping to change at page 40, line 20 ¶ | skipping to change at page 40, line 31 ¶ | |||
Subject: Registration of media type "application/sdp" | Subject: Registration of media type "application/sdp" | |||
Type name: application | Type name: application | |||
Subtype name: sdp | Subtype name: sdp | |||
Required parameters: None. | Required parameters: None. | |||
Optional parameters: None. | Optional parameters: None. | |||
Encoding considerations: | Encoding considerations: 8-bit text. | |||
SDP files are primarily UTF-8 format text. The "a=charset:" | SDP files are primarily UTF-8 format text. The "a=charset:" | |||
attribute may be used to signal the presence of other character | attribute may be used to signal the presence of other character | |||
sets in certain parts of an SDP file (see Section 6 of RFC | sets in certain parts of an SDP file (see Section 6 of RFC | |||
XXXX). Arbitrary binary content cannot be directly | XXXX). Arbitrary binary content cannot be directly | |||
represented in SDP. | represented in SDP. | |||
Security considerations: | Security considerations: | |||
See Section 7 of RFC XXXX. | See Section 7 of RFC XXXX. | |||
Interoperability considerations: | Interoperability considerations: | |||
skipping to change at page 42, line 30 ¶ | skipping to change at page 42, line 42 ¶ | |||
Such an RFC MAY be Experimental or Informational, although it is | Such an RFC MAY be Experimental or Informational, although it is | |||
preferable that it be Standards Track. The RFC defining a new | preferable that it be Standards Track. The RFC defining a new | |||
protocol MUST define the rules by which the "fmt" (see below) | protocol MUST define the rules by which the "fmt" (see below) | |||
namespace is managed. | namespace is managed. | |||
"proto" names starting with "RTP/" MUST only be used for defining | "proto" names starting with "RTP/" MUST only be used for defining | |||
transport protocols that are profiles of the RTP protocol. For | transport protocols that are profiles of the RTP protocol. For | |||
example, a profile whose short name is "XYZ" would be denoted by a | example, a profile whose short name is "XYZ" would be denoted by a | |||
"proto" sub-field of "RTP/XYZ". | "proto" sub-field of "RTP/XYZ". | |||
8.2.3. Media Formats ("fmt") | ||||
Each transport protocol, defined by the "proto" sub-field, has an | Each transport protocol, defined by the "proto" sub-field, 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 "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 | |||
skipping to change at page 43, line 13 ¶ | skipping to change at page 43, line 22 ¶ | |||
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.3. Attribute Names ("att-field") | |||
8.2.4.1. New Attributes | 8.2.3.1. New Attributes | |||
Attribute-field names ("att-field") MUST be registered with IANA and | Attribute-field names ("att-field") MUST be registered with IANA and | |||
documented, to avoid any issues due to conflicting attribute | documented, to avoid any issues due to conflicting attribute | |||
definitions under the same name. Unknown attributes in SDP are | definitions under the same name. Unknown attributes in SDP are | |||
simply ignored, but conflicting ones that fragment the protocol are a | simply ignored, but conflicting ones that fragment the protocol are a | |||
serious problem. | serious problem. | |||
New attribute registrations are accepted according to the | New attribute registrations are accepted according to the | |||
"Specification Required" policy of [RFC8126], provided that the | "Specification Required" policy of [RFC8126], provided that the | |||
specification includes the following information: | specification includes the following information: | |||
skipping to change at page 45, line 5 ¶ | skipping to change at page 45, line 11 ¶ | |||
media" or "media" (depending on desired semantics). The default rule | media" or "media" (depending on desired semantics). The default rule | |||
is that for all new SDP attributes that can occur both in session and | is that for all new SDP attributes that can occur both in session and | |||
media level, the media level overrides the session level. When this | media level, the media level overrides the session level. When this | |||
is not the case for a new SDP attribute, it MUST be explicitly | is not the case for a new SDP attribute, it MUST be explicitly | |||
stated. | stated. | |||
IANA has registered the initial set of attribute names ("att-field" | IANA has registered the initial set of attribute names ("att-field" | |||
values) with definitions as in Section 6 of this memo (these | values) with definitions as in Section 6 of this memo (these | |||
definitions replace those in [RFC4566]). | definitions replace those in [RFC4566]). | |||
8.2.4.2. Updates to Existing Attributes | 8.2.3.2. Updates to Existing Attributes | |||
Updated attribute registrations are accepted according to the | Updated attribute registrations are accepted according to the | |||
"Specification Required" policy of [RFC8126]. | "Specification Required" policy of [RFC8126]. | |||
The Designated Expert reviewing the update is requested to evaluate | The Designated Expert reviewing the update is requested to evaluate | |||
whether the update is compatible with the prior intent and use of the | whether the update is compatible with the prior intent and use of the | |||
attribute, and whether the new document is of sufficient maturity and | attribute, and whether the new document is of sufficient maturity and | |||
authority in relation to the prior document. | authority in relation to the prior document. | |||
The specification updating the attribute (for example, by adding a | The specification updating the attribute (for example, by adding a | |||
new value) MUST update registration information items from | new value) MUST update registration information items from | |||
Section 8.2.4.1 according to the following bullets: | Section 8.2.3.1 according to the following bullets: | |||
o Contact Name: A name MUST be provided. | o Contact Name: A name MUST be provided. | |||
o Contact Email Address: An email address MUST be provided. | o Contact Email Address: An email address MUST be provided. | |||
o Attribute Name: MUST be provided and MUST NOT be changed. | o Attribute Name: MUST be provided and MUST NOT be changed. | |||
Otherwise it is a new attribute. | Otherwise it is a new attribute. | |||
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 | |||
skipping to change at page 46, line 8 ¶ | skipping to change at page 46, line 15 ¶ | |||
o Mux Category: No change unless from "TBD" to another value (see | o Mux Category: No change unless from "TBD" to another value (see | |||
[I-D.ietf-mmusic-sdp-mux-attributes]. It MAY also change if | [I-D.ietf-mmusic-sdp-mux-attributes]. It MAY also change if | |||
'media' level is being added to the definition of an attribute | 'media' level is being added to the definition of an attribute | |||
that previously did not include it. | that previously did not include it. | |||
o Reference: A new reference MUST be provided. | o Reference: A new reference MUST be provided. | |||
Items SHOULD be omitted if there is no impact to them as a result of | Items SHOULD be omitted if there is no impact to them as a result of | |||
the attribute update. | the attribute update. | |||
8.2.5. Bandwidth Specifiers ("bwtype") | 8.2.4. Bandwidth Specifiers ("bwtype") | |||
A proliferation of bandwidth specifiers is strongly discouraged. | A proliferation of bandwidth specifiers is strongly discouraged. | |||
New bandwidth specifiers (<bwtype> sub-field values) MUST be | New bandwidth specifiers (<bwtype> sub-field values) MUST be | |||
registered with IANA. The submission MUST reference a standards- | registered with IANA. The submission MUST reference a standards- | |||
track RFC specifying the semantics of the bandwidth specifier | track RFC specifying the semantics of the bandwidth specifier | |||
precisely, and indicating when it should be used, and why the | precisely, and indicating when it should be used, and why the | |||
existing registered bandwidth specifiers do not suffice. | existing registered bandwidth specifiers do not suffice. | |||
IANA has registered the bandwidth specifiers "CT" and "AS" with | IANA has registered the bandwidth specifiers "CT" and "AS" with | |||
definitions as in Section 5.8 of this memo (these definitions update | definitions as in Section 5.8 of this memo (these definitions update | |||
those in [RFC4566]). | those in [RFC4566]). | |||
8.2.6. Network Types ("nettype") | 8.2.5. Network Types ("nettype") | |||
New network types (<nettype> sub-field values) MUST be registered | New network types (<nettype> sub-field values) MUST be registered | |||
with IANA if SDP needs to be used in the context of non-Internet | with IANA if SDP needs to be used in the context of non-Internet | |||
environments. The registration is subject to the "RFC Required" | environments. The registration is subject to the "RFC Required" | |||
policy of [RFC8126]. Although these are not normally the preserve of | policy of [RFC8126]. Although these are not normally the preserve of | |||
IANA, there may be circumstances when an Internet application needs | IANA, there may be circumstances when an Internet application needs | |||
to interoperate with a non-Internet application, such as when | to interoperate with a non-Internet application, such as when | |||
gatewaying an Internet telephone call into the Public Switched | gatewaying an Internet telephone call into the Public Switched | |||
Telephone Network (PSTN). The number of network types should be | Telephone Network (PSTN). The number of network types should be | |||
small and should be rarely extended. A new network type cannot be | small and should be rarely extended. A new network type cannot be | |||
registered without registering at least one address type to be used | registered without registering at least one address type to be used | |||
with that network type. A new network type registration MUST | with that network type. A new network type registration MUST | |||
reference an RFC that gives details of the network type and address | reference an RFC that gives details of the network type and address | |||
type(s) and specifies how and when they would be used. | type(s) and specifies how and when they would be used. | |||
IANA has registered the network type "IN" to represent the Internet, | IANA has registered the network type "IN" to represent the Internet, | |||
with definition as in Sections 5.2 and 5.7 of this memo (these | with definition as in Sections 5.2 and 5.7 of this memo (these | |||
definitions update those in [RFC4566]). | definitions update those in [RFC4566]). | |||
8.2.7. Address Types ("addrtype") | 8.2.6. 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]. | registration is subject to the "RFC Required" policy of [RFC8126]. | |||
An address type is only meaningful in the context of a network type, | An address type is only meaningful in the context of a network type, | |||
and any registration of an address type MUST specify a registered | and any registration of an address type MUST specify a registered | |||
network type or be submitted along with a network type registration. | network type or be submitted along with a network type registration. | |||
A new address type registration MUST reference an RFC giving details | A 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. | |||
IANA has registered the address types "IP4" and "IP6" with | Section 5.7 of this document gives new definitions of address types | |||
definitions as in Sections 5.2 and 5.7 of this memo (these | "IP4" and "IP6". The registries are to be correspondingly updated by | |||
definitions update those in [RFC4566]). | IANA. | |||
8.2.8. Registration Procedure | ||||
In the RFC specifications that register new values for SDP "media", | 8.2.7. Registration Procedure | |||
"proto", "fmt", "bwtype", "nettype", and "addrtype" parameters, the | ||||
authors MUST include the following information for IANA to place in | ||||
the appropriate registry: | ||||
o contact name | A specification document that defines new values for SDP "media", | |||
"proto", "bwtype", "nettype", and "addrtype" parameters MUST include | ||||
the following information: | ||||
o contact email address | o contact name; | |||
o name being registered (as it will appear in SDP) | o contact email address; | |||
o type of name ("media", "proto", "fmt", "bwtype", "nettype", or | o name being defined (as it will appear in SDP); | |||
"addrtype") | ||||
o a one-paragraph explanation of the purpose of the registered name | o type of name ("media", "proto", "bwtype", "nettype", or | |||
"addrtype"); | ||||
o a reference to the specification for the registered name (this | o a description of the purpose of the defined name; | |||
will typically be an RFC number) | ||||
In the case of a new addrtype registration, the author has to check | o a stable reference to the document containing this information and | |||
whether the new address type is usable with the existing network | the definition of the value. (This will typically be an RFC | |||
types. If yes, the "nettype" registry MUST be updated accordingly. | number.) | |||
In the case of a new nettype registration, the author MUST specify | ||||
the usable address type(s). | ||||
IANA may refer any registration to the IESG for review, and may | IANA will populate its registries with some or all of these values. | |||
request revisions to be made before a registration will be made. | ||||
8.3. Encryption Key Access Methods | 8.3. Encryption Key Access Methods | |||
The IANA previously maintained a table of SDP encryption key access | The IANA previously maintained a table of SDP encryption key access | |||
method ("enckey") names. This table is obsolete, since the "k=" line | method ("enckey") names. This table is obsolete, since the "k=" line | |||
is not extensible. New registrations MUST NOT be accepted. | is not extensible. New registrations MUST NOT be accepted. | |||
8.4. Reorganization of the nettype Registry | 8.4. Reorganization of the nettype and addrtype registries | |||
This document adds a new column in the "nettype" registry with the | This document adds a new column in the "nettype" registry with the | |||
title "Usable addrtype Values" and updates the "nettype" registry as | title "Usable addrtype Values", replacing the separate "addrtype" | |||
follows: | registry. The following is the revised "nettype" registry: | |||
-------------------------------------------------------------------- | -------------------------------------------------------------------- | |||
|Type | SDP Name | Usable addrtype Values | Reference | | |Type | SDP Name | Usable addrtype Values | Reference | | |||
-------------------------------------------------------------------- | -------------------------------------------------------------------- | |||
|nettype | IN | IP4, IP6 | [RFCXXXX] | | |nettype | IN | IP4, IP6 | [RFCXXXX] | | |||
|nettype | TN | RFC2543 | [RFC2848] | | |nettype | TN | RFC2543 | [RFC2848] | | |||
|nettype | ATM | NSAP, GWID, E164 | [RFC3108] | | |nettype | ATM | NSAP, GWID, E164 | [RFC3108] | | |||
|nettype | PSTN | E164 | [RFC7195] | | |nettype | PSTN | E164 | [RFC7195] | | |||
-------------------------------------------------------------------- | -------------------------------------------------------------------- | |||
skipping to change at page 48, line 26 ¶ | skipping to change at page 48, line 32 ¶ | |||
type has a different context for ATM and PSTN networks. | type has a different context for ATM and PSTN networks. | |||
8.5. Reorganization of the att-field Registries | 8.5. Reorganization of the att-field Registries | |||
This document combines all of the (currently) five "att-field" | This document combines all of the (currently) five "att-field" | |||
registries into one registry called "att-field" registry, and updates | registries into one registry called "att-field" registry, and updates | |||
the columns to reflect the name, usage level(s), charset dependency | the columns to reflect the name, usage level(s), charset dependency | |||
and reference. As such IANA is requested to create a new combined | and reference. As such IANA is requested to create a new combined | |||
registry using the following columns: | registry using the following columns: | |||
Name | Usage Level | Dependent on Charset? | Mux Category | Reference | | | Dependent | Mux | | | |||
Name | Usage Level | on Charset? | Category | Reference | | ||||
The "Name" column reflects the attribute name (as it will appear in | The "Name" column reflects the attribute name (as it will appear in | |||
the SDP). The "Usage Level" column MUST indicate one or more of the | the SDP). The "Usage Level" column MUST indicate one or more of the | |||
following: session, media, source, dcsa and dcsa(subprotocol). The | following: session, media, source, dcsa and dcsa(subprotocol). The | |||
"Dependent on Charset?" column MUST indicate "Yes" or "No" depending | "Dependent on Charset?" column MUST indicate "Yes" or "No" depending | |||
on whether the attribute value is subject to the charset attribute. | on whether the attribute value is subject to the charset attribute. | |||
The "Mux Category" column MUST indicate one of the following | The "Mux Category" column MUST indicate one of the following | |||
categories: NORMAL, NOT RECOMMENDED, IDENTICAL, SUM, TRANSPORT, | categories: NORMAL, NOT RECOMMENDED, IDENTICAL, SUM, TRANSPORT, | |||
INHERIT, IDENTICAL-PER-PT, SPECIAL or TBD as defined by | INHERIT, IDENTICAL-PER-PT, SPECIAL or TBD as defined by | |||
[I-D.ietf-mmusic-sdp-mux-attributes]. Finally, the "Reference" | [I-D.ietf-mmusic-sdp-mux-attributes]. Finally, the "Reference" | |||
column indicates the specification(s) where the attribute is defined. | column indicates the specification(s) where the attribute is defined. | |||
For example, the attribute "setup" which is defined for both session | For example, the attribute "setup" 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: | |||
Name | Usage Level | Dependent on Charset?|Mux Category| Reference | | | | Dependent | Mux | | | |||
setup | session,media, | No |IDENTICAL | [RFC4145] | | Name | Usage Level | on Charset? | Category | Reference | | |||
| dcsa,dcsa(msrp)| | | [RFC6135] | | ------|----------------|-------------|----------|----------------| | |||
| | | | [I-D.mmusic | setup | session,media, | No |IDENTICAL | [RFC4145] | | |||
| | | |-msrp-usage- | | dcsa,dcsa(msrp)| | | [RFC6135] | | |||
| | | |data-channel | | | | | [I-D.mmusic- | | |||
| | | |] | | | | | | msrp-usage- | | |||
| | | | data-channel] | | ||||
9. SDP Grammar | 9. SDP Grammar | |||
This section provides an Augmented BNF grammar for SDP. ABNF is | This section provides an Augmented BNF grammar for SDP. ABNF is | |||
defined in [RFC5234] and [RFC7405]. | defined in [RFC5234] and [RFC7405]. | |||
; SDP Syntax | ; SDP Syntax | |||
session-description = version-field | session-description = version-field | |||
origin-field | origin-field | |||
session-name-field | session-name-field | |||
skipping to change at page 51, line 27 ¶ | skipping to change at page 51, line 36 ¶ | |||
bwtype = token | bwtype = token | |||
bandwidth = 1*DIGIT | bandwidth = 1*DIGIT | |||
; sub-rules of 't=' | ; sub-rules of 't=' | |||
start-time = time / "0" | start-time = time / "0" | |||
stop-time = time / "0" | stop-time = time / "0" | |||
time = POS-DIGIT 9*DIGIT | time = POS-DIGIT 9*DIGIT | |||
; Decimal representation of NTP time in | ; Decimal representation of time in | |||
; seconds since 1900. The representation | ; seconds since January 1, 1900 UTC. | |||
; of NTP time is an unbounded length field | ; The representation is an unbounded | |||
; containing at least 10 digits. Unlike the | ; length field containing at least | |||
; 64-bit representation used elsewhere, time | ; 10 digits. Unlike some representations | |||
; in SDP does not wrap in the year 2036. | ; used elsewhere, time in SDP does not | |||
; wrap in the year 2036. | ||||
; sub-rules of 'r=' and 'z=' | ; sub-rules of 'r=' and 'z=' | |||
repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] | repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] | |||
typed-time = 1*DIGIT [fixed-len-time-unit] | typed-time = 1*DIGIT [fixed-len-time-unit] | |||
fixed-len-time-unit = %s"d" / %s"h" / %s"m" / %s"s" | fixed-len-time-unit = %s"d" / %s"h" / %s"m" / %s"s" | |||
; NOTE: These units are case-sensitive. | ; NOTE: These units are case-sensitive. | |||
; sub-rules of 'k=' | ; sub-rules of 'k=' | |||
skipping to change at page 54, line 17 ¶ | skipping to change at page 54, line 26 ¶ | |||
non-zero-real = zero-based-integer "." *DIGIT POS-DIGIT | non-zero-real = zero-based-integer "." *DIGIT POS-DIGIT | |||
; generic sub-rules: primitives | ; generic sub-rules: primitives | |||
alpha-numeric = ALPHA / DIGIT | alpha-numeric = ALPHA / DIGIT | |||
POS-DIGIT = %x31-39 ; 1 - 9 | POS-DIGIT = %x31-39 ; 1 - 9 | |||
decimal-uchar = DIGIT | decimal-uchar = DIGIT | |||
/ POS-DIGIT DIGIT | / POS-DIGIT DIGIT | |||
/ ("1" 2*(DIGIT)) | / ("1" 2(DIGIT)) | |||
/ ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) | / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) | |||
/ ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) | / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) | |||
; external references: | ; external references: | |||
ALPHA = <ALPHA definition from RFC5234> | ALPHA = <ALPHA definition from RFC5234> | |||
DIGIT = <DIGIT definition from RFC5234> | DIGIT = <DIGIT definition from RFC5234> | |||
CRLF = <CRLF definition from RFC5234> | CRLF = <CRLF definition from RFC5234> | |||
HEXDIG = <HEXDIG definition from RFC5234> | HEXDIG = <HEXDIG definition from RFC5234> | |||
SP = <SP definition from RFC5234> | SP = <SP definition from RFC5234> | |||
VCHAR = <VCHAR definition from RFC5234> | VCHAR = <VCHAR definition from RFC5234> | |||
skipping to change at page 55, line 38 ¶ | skipping to change at page 55, line 44 ¶ | |||
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. (This is incompatible with | preceding "r=" a syntax error. (This is incompatible with | |||
certain aberrant usage.) | 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. (This mirrors a bug fix made to | with the syntax in RFC3986. (This mirrors a bug fix made to | |||
RFC3261 by RFC5964.) Removed rules that were unused as a | RFC3261 by RFC5964.) Removed rules that were unused as a | |||
result of this change. | result of this change. | |||
o Revised normative statements that were redundant with ABNF syntax, | ||||
making the text non-normative. | ||||
o Revised IPv4 unicast and multicast addresses in the example SDP | o Revised IPv4 unicast and multicast addresses in the example SDP | |||
descriptions per RFCs 5735 and 5771. | descriptions per RFCs 5735 and 5771. | |||
o Changed some examples to use IPv6 addresses, and added additional | ||||
examples using IPv6. | ||||
o Incorporated case-insensitivity rules from RFC 4855. | o Incorporated case-insensitivity rules from RFC 4855. | |||
o Revised sections that incorrectly referenced NTP. | ||||
o Clarified the explanation of the impact and use of a=charset. | ||||
o Revised the description of a=type to remove implication that it | ||||
sometimes changes the default media direction to something other | ||||
than sendrecv. | ||||
11. Acknowledgements | 11. Acknowledgements | |||
Many people in the IETF Multiparty Multimedia Session Control | Many people in the IETF Multiparty Multimedia Session Control | |||
(MMUSIC) working group have made comments and suggestions | (MMUSIC) working group have made comments and suggestions | |||
contributing to this document. | contributing to this document. | |||
In particular, we would like to thank the following people who | In particular, we would like to thank the following people who | |||
contributed to the creation of this document or one of its | contributed to the creation of this document or one of its | |||
predecessor documents: Adam Roach, Allison Mankin, Bernie Hoeneisen, | predecessor documents: Adam Roach, Allison Mankin, Bernie Hoeneisen, | |||
Bill Fenner, Carsten Bormann, Eve Schooler, Flemming Andreasen, | Bill Fenner, Carsten Bormann, Eve Schooler, Flemming Andreasen, | |||
skipping to change at page 56, line 20 ¶ | skipping to change at page 56, line 41 ¶ | |||
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., Ejzak, R., Marcon, J., and R. | Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. | |||
Even, "SDP-based Data Channel Negotiation", draft-ietf- | Even, "SDP-based Data Channel Negotiation", draft-ietf- | |||
mmusic-data-channel-sdpneg-27 (work in progress), April | mmusic-data-channel-sdpneg-28 (work in progress), May | |||
2019. | 2019. | |||
[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. | |||
[ISO.8859-1.1998] | ||||
International Organization for Standardization, | ||||
"Information technology - 8-bit single byte coded graphic | ||||
- character sets - Part 1: Latin alphabet No. 1, JTC1/ | ||||
SC2", ISO/IEC Standard 8859-1, 1998. | ||||
[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>. | |||
[RFC1035] Mockapetris, P., "Domain names - implementation and | [RFC1035] Mockapetris, P., "Domain names - implementation and | |||
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, | specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, | |||
November 1987, <https://www.rfc-editor.org/info/rfc1035>. | November 1987, <https://www.rfc-editor.org/info/rfc1035>. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
skipping to change at page 57, line 47 ¶ | skipping to change at page 58, line 28 ¶ | |||
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying | [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying | |||
Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, | Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, | |||
September 2009, <https://www.rfc-editor.org/info/rfc5646>. | September 2009, <https://www.rfc-editor.org/info/rfc5646>. | |||
[RFC5890] Klensin, J., "Internationalized Domain Names for | [RFC5890] Klensin, J., "Internationalized Domain Names for | |||
Applications (IDNA): Definitions and Document Framework", | Applications (IDNA): Definitions and Document Framework", | |||
RFC 5890, DOI 10.17487/RFC5890, August 2010, | RFC 5890, DOI 10.17487/RFC5890, August 2010, | |||
<https://www.rfc-editor.org/info/rfc5890>. | <https://www.rfc-editor.org/info/rfc5890>. | |||
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 | ||||
Address Text Representation", RFC 5952, | ||||
DOI 10.17487/RFC5952, August 2010, | ||||
<https://www.rfc-editor.org/info/rfc5952>. | ||||
[RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model | [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model | |||
for the Message Session Relay Protocol (MSRP)", RFC 6135, | for the Message Session Relay Protocol (MSRP)", RFC 6135, | |||
DOI 10.17487/RFC6135, February 2011, | DOI 10.17487/RFC6135, February 2011, | |||
<https://www.rfc-editor.org/info/rfc6135>. | <https://www.rfc-editor.org/info/rfc6135>. | |||
[RFC7195] Garcia-Martin, M. and S. Veikkolainen, "Session | [RFC7195] Garcia-Martin, M. and S. Veikkolainen, "Session | |||
Description Protocol (SDP) Extension for Setting Audio and | Description Protocol (SDP) Extension for Setting Audio and | |||
Video Media Streams over Circuit-Switched Bearers in the | Video Media Streams over Circuit-Switched Bearers in the | |||
Public Switched Telephone Network (PSTN)", RFC 7195, | Public Switched Telephone Network (PSTN)", RFC 7195, | |||
DOI 10.17487/RFC7195, May 2014, | DOI 10.17487/RFC7195, May 2014, | |||
skipping to change at page 58, line 27 ¶ | skipping to change at page 59, line 11 ¶ | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
12.2. Informative References | 12.2. Informative References | |||
[I-D.ietf-mmusic-ice-sip-sdp] | [I-D.ietf-mmusic-ice-sip-sdp] | |||
Petit-Huguenin, M., Nandakumar, S., and A. Keranen, | Petit-Huguenin, M., Nandakumar, S., and A. Keranen, | |||
"Session Description Protocol (SDP) Offer/Answer | "Session Description Protocol (SDP) Offer/Answer | |||
procedures for Interactive Connectivity Establishment | procedures for Interactive Connectivity Establishment | |||
(ICE)", draft-ietf-mmusic-ice-sip-sdp-24 (work in | (ICE)", draft-ietf-mmusic-ice-sip-sdp-36 (work in | |||
progress), November 2018. | progress), June 2019. | |||
[I-D.ietf-mmusic-sdp-bundle-negotiation] | [I-D.ietf-mmusic-sdp-bundle-negotiation] | |||
Holmberg, C., Alvestrand, H., and C. Jennings, | Holmberg, C., Alvestrand, H., and C. Jennings, | |||
"Negotiating Media Multiplexing Using the Session | "Negotiating Media Multiplexing Using the Session | |||
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- | Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- | |||
negotiation-54 (work in progress), December 2018. | negotiation-54 (work in progress), December 2018. | |||
[ITU.H332.1998] | [ITU.H332.1998] | |||
International Telecommunication Union, "H.323 extended for | International Telecommunication Union, "H.323 extended for | |||
loosely coupled conferences", ITU Recommendation H.332, | loosely coupled conferences", ITU Recommendation H.332, | |||
September 1998. | September 1998. | |||
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | ||||
Extensions (MIME) Part One: Format of Internet Message | ||||
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, | ||||
<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 | |||
Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, | Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, | |||
October 2000, <https://www.rfc-editor.org/info/rfc2974>. | October 2000, <https://www.rfc-editor.org/info/rfc2974>. | |||
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, | [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, | |||
A., Peterson, J., Sparks, R., Handley, M., and E. | A., Peterson, J., Sparks, R., Handley, M., and E. | |||
skipping to change at page 60, line 5 ¶ | skipping to change at page 60, line 36 ¶ | |||
"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>. | |||
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session | ||||
Description Protocol (SDP) Security Descriptions for Media | ||||
Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, | ||||
<https://www.rfc-editor.org/info/rfc4568>. | ||||
[RFC4855] Casner, S., "Media Type Registration of RTP Payload | [RFC4855] Casner, S., "Media Type Registration of RTP Payload | |||
Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, | Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, | |||
<https://www.rfc-editor.org/info/rfc4855>. | <https://www.rfc-editor.org/info/rfc4855>. | |||
[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>. | |||
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description | [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description | |||
Protocol (SDP) Grouping Framework", RFC 5888, | Protocol (SDP) Grouping Framework", RFC 5888, | |||
DOI 10.17487/RFC5888, June 2010, | DOI 10.17487/RFC5888, June 2010, | |||
<https://www.rfc-editor.org/info/rfc5888>. | <https://www.rfc-editor.org/info/rfc5888>. | |||
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, | ||||
"Network Time Protocol Version 4: Protocol and Algorithms | ||||
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, | ||||
<https://www.rfc-editor.org/info/rfc5905>. | ||||
[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>. | |||
[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, | ||||
"TCP Candidates with Interactive Connectivity | ||||
Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, | ||||
March 2012, <https://www.rfc-editor.org/info/rfc6544>. | ||||
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type | [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type | |||
Specifications and Registration Procedures", BCP 13, | Specifications and Registration Procedures", BCP 13, | |||
RFC 6838, DOI 10.17487/RFC6838, January 2013, | RFC 6838, DOI 10.17487/RFC6838, January 2013, | |||
<https://www.rfc-editor.org/info/rfc6838>. | <https://www.rfc-editor.org/info/rfc6838>. | |||
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | |||
Protocol (HTTP/1.1): Message Syntax and Routing", | Protocol (HTTP/1.1): Message Syntax and Routing", | |||
RFC 7230, DOI 10.17487/RFC7230, June 2014, | RFC 7230, DOI 10.17487/RFC7230, June 2014, | |||
<https://www.rfc-editor.org/info/rfc7230>. | <https://www.rfc-editor.org/info/rfc7230>. | |||
End of changes. 102 change blocks. | ||||
300 lines changed or deleted | 326 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/ |