idnits 2.17.1 draft-ietf-mmusic-rfc4566bis-35.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 3, 2019) is 1819 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 2220, but not defined == Unused Reference: 'RFC2978' is defined on line 2641, but no explicit reference was found in the text == Unused Reference: 'RFC6544' is defined on line 2806, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'E164' == Outdated reference: A later version (-28) exists of draft-ietf-mmusic-data-channel-sdpneg-27 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-17 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-39) exists of draft-ietf-mmusic-ice-sip-sdp-24 -- Obsolete informational reference (is this intentional?): RFC 2327 (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Begen 3 Internet-Draft Networked Media 4 Obsoletes: 4566 (if approved) P. Kyzivat 5 Intended status: Standards Track 6 Expires: November 4, 2019 C. Perkins 7 University of Glasgow 8 M. Handley 9 UCL 10 May 3, 2019 12 SDP: Session Description Protocol 13 draft-ietf-mmusic-rfc4566bis-35 15 Abstract 17 This memo defines the Session Description Protocol (SDP). SDP is 18 intended for describing multimedia sessions for the purposes of 19 session announcement, session invitation, and other forms of 20 multimedia session initiation. This document obsoletes RFC 4566. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 4, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . . 5 71 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 5 72 3.2. Streaming Media . . . . . . . . . . . . . . . . . . . . . 5 73 3.3. Email and the World Wide Web . . . . . . . . . . . . . . 5 74 3.4. Multicast Session Announcement . . . . . . . . . . . . . 5 75 4. Requirements and Recommendations . . . . . . . . . . . . . . 6 76 4.1. Media and Transport Information . . . . . . . . . . . . . 7 77 4.2. Timing Information . . . . . . . . . . . . . . . . . . . 7 78 4.3. Obtaining Further Information about a Session . . . . . . 8 79 4.4. Categorization . . . . . . . . . . . . . . . . . . . . . 8 80 4.5. Internationalization . . . . . . . . . . . . . . . . . . 8 81 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . . 8 82 5.1. Protocol Version ("v=") . . . . . . . . . . . . . . . . . 12 83 5.2. Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 12 84 5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 13 85 5.4. Session Information ("i=") . . . . . . . . . . . . . . . 13 86 5.5. URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . 14 87 5.6. Email Address and Phone Number ("e=" and "p=") . . . . . 14 88 5.7. Connection Information ("c=") . . . . . . . . . . . . . . 15 89 5.8. Bandwidth Information ("b=") . . . . . . . . . . . . . . 17 90 5.9. Time Active ("t=") . . . . . . . . . . . . . . . . . . . 18 91 5.10. Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . 19 92 5.11. Time Zone Adjustment ("z=") . . . . . . . . . . . . . . . 20 93 5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 21 94 5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 21 95 5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 22 96 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 25 97 6.1. cat (category) . . . . . . . . . . . . . . . . . . . . . 25 98 6.2. keywds (keywords) . . . . . . . . . . . . . . . . . . . . 26 99 6.3. tool . . . . . . . . . . . . . . . . . . . . . . . . . . 26 100 6.4. ptime (packet time) . . . . . . . . . . . . . . . . . . . 27 101 6.5. maxptime (maximum packet time) . . . . . . . . . . . . . 27 102 6.6. rtpmap . . . . . . . . . . . . . . . . . . . . . . . . . 28 103 6.7. Media Direction Attributes . . . . . . . . . . . . . . . 29 104 6.7.1. recvonly (receive-only) . . . . . . . . . . . . . . . 30 105 6.7.2. sendrecv (send-receive) . . . . . . . . . . . . . . . 30 106 6.7.3. sendonly (send-only) . . . . . . . . . . . . . . . . 31 107 6.7.4. inactive . . . . . . . . . . . . . . . . . . . . . . 31 108 6.8. orient (orientation) . . . . . . . . . . . . . . . . . . 32 109 6.9. type (conference type) . . . . . . . . . . . . . . . . . 32 110 6.10. charset (character set) . . . . . . . . . . . . . . . . . 33 111 6.11. sdplang (SDP language) . . . . . . . . . . . . . . . . . 34 112 6.12. lang (language) . . . . . . . . . . . . . . . . . . . . . 35 113 6.13. framerate (frame rate) . . . . . . . . . . . . . . . . . 36 114 6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 36 115 6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 37 116 7. Security Considerations . . . . . . . . . . . . . . . . . . . 38 117 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 118 8.1. The "application/sdp" Media Type . . . . . . . . . . . . 40 119 8.2. Registration of Parameters . . . . . . . . . . . . . . . 41 120 8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 41 121 8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 42 122 8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 42 123 8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 43 124 8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 46 125 8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 46 126 8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 46 127 8.2.8. Registration Procedure . . . . . . . . . . . . . . . 47 128 8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 47 129 8.4. Reorganization of the nettype Registry . . . . . . . . . 47 130 8.5. Reorganization of the att-field Registries . . . . . . . 48 131 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 49 132 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 54 133 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 55 134 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 135 12.1. Normative References . . . . . . . . . . . . . . . . . . 56 136 12.2. Informative References . . . . . . . . . . . . . . . . . 58 137 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 139 1. Introduction 141 When initiating multimedia teleconferences, voice-over-IP calls, 142 streaming video, or other sessions, there is a requirement to convey 143 media details, transport addresses, and other session description 144 metadata to the participants. 146 SDP provides a standard representation for such information, 147 irrespective of how that information is transported. SDP is purely a 148 format for session description -- it does not incorporate a transport 149 protocol, and it is intended to use different transport protocols as 150 appropriate, including the Session Announcement Protocol (SAP) 151 [RFC2974], Session Initiation Protocol (SIP) [RFC3261], Real Time 152 Streaming Protocol (RTSP) [RFC7826], electronic mail using the MIME 153 extensions [RFC5322], and the Hypertext Transport Protocol (HTTP) 154 [RFC7230]. 156 SDP is intended to be general purpose so that it can be used in a 157 wide range of network environments and applications. However, it is 158 not intended to support negotiation of session content or media 159 encodings: this is viewed as outside the scope of session 160 description. 162 This memo obsoletes [RFC4566]. The changes relative to [RFC4566] are 163 outlined in Section 10 of this memo. 165 2. Glossary of Terms 167 The following terms are used in this document and have specific 168 meaning within the context of this document. 170 Session Description: A well-defined format for conveying sufficient 171 information to discover and participate in a multimedia session. 173 Media Description: A Media Description contains the information 174 needed for one party to establish an application layer network 175 protocol connection to another party. It starts with an "m=" line 176 and is terminated by either the next "m=" line or by the end of 177 the session description. 179 Session-level Section: This refers to the parts that are not media 180 descriptions, whereas the session description refers to the whole 181 body that includes the session-level section and the media 182 description(s). 184 The terms "multimedia conference" and "multimedia session" are used 185 in this document as defined in [RFC7656]. The terms "session" and 186 "multimedia session" are used interchangeably in this document. 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 190 "OPTIONAL" in this document are to be interpreted as described in BCP 191 14 [RFC2119] [RFC8174] when, and only when, they appear in all 192 capitals, as shown here. 194 3. Examples of SDP Usage 196 3.1. Session Initiation 198 The Session Initiation Protocol (SIP) [RFC3261] is an application- 199 layer control protocol for creating, modifying, and terminating 200 sessions such as Internet multimedia conferences, Internet telephone 201 calls, and multimedia distribution. The SIP messages used to create 202 sessions carry session descriptions that allow participants to agree 203 on a set of compatible media types. These session descriptions are 204 commonly formatted using SDP. When used with SIP, the offer/answer 205 model [RFC3264] provides a limited framework for negotiation using 206 SDP. 208 3.2. Streaming Media 210 The Real Time Streaming Protocol (RTSP) [RFC7826], is an application- 211 level protocol for control over the delivery of data with real-time 212 properties. RTSP provides an extensible framework to enable 213 controlled, on-demand delivery of real-time data, such as audio and 214 video. An RTSP client and server negotiate an appropriate set of 215 parameters for media delivery, partially using SDP syntax to describe 216 those parameters. 218 3.3. Email and the World Wide Web 220 Alternative means of conveying session descriptions include 221 electronic mail and the World Wide Web (WWW). For both email and WWW 222 distribution, the media type "application/sdp" is used. This enables 223 the automatic launching of applications for participation in the 224 session from the WWW client or mail reader in a standard manner. 226 Note that descriptions of multicast sessions sent only via email or 227 the WWW do not have the property that the receiver of a session 228 description can necessarily receive the session because the multicast 229 sessions may be restricted in scope, and access to the WWW server or 230 reception of email is possible outside this scope. 232 3.4. Multicast Session Announcement 234 In order to assist the advertisement of multicast multimedia 235 conferences and other multicast sessions, and to communicate the 236 relevant session setup information to prospective participants, a 237 distributed session directory may be used. An instance of such a 238 session directory periodically sends packets containing a description 239 of the session to a well-known multicast group. These advertisements 240 are received by other session directories such that potential remote 241 participants can use the session description to start the tools 242 required to participate in the session. 244 One protocol used to implement such a distributed directory is the 245 SAP [RFC2974]. SDP provides the recommended session description 246 format for such session announcements. 248 4. Requirements and Recommendations 250 The purpose of SDP is to convey information about media streams in 251 multimedia sessions to allow the recipients of a session description 252 to participate in the session. SDP is primarily intended for use in 253 an internetwork, although it is sufficiently general that it can 254 describe multimedia conferences in other network environments. Media 255 streams can be many-to-many. Sessions need not be continually 256 active. 258 Thus far, multicast-based sessions on the Internet have differed from 259 many other forms of conferencing in that anyone receiving the traffic 260 can join the session (unless the session traffic is encrypted). In 261 such an environment, SDP serves two primary purposes. It is a means 262 to communicate the existence of a session, and it is a means to 263 convey sufficient information to enable joining and participating in 264 the session. In a unicast environment, only the latter purpose is 265 likely to be relevant. 267 An SDP description includes the following: 269 o Session name and purpose 271 o Time(s) the session is active 273 o The media comprising the session 275 o Information needed to receive those media (addresses, ports, 276 formats, etc.) 278 As resources necessary to participate in a session may be limited, 279 some additional information may also be desirable: 281 o Information about the bandwidth to be used by the session 283 o Contact information for the person responsible for the session 285 In general, SDP must convey sufficient information to enable 286 applications to join a session (with the possible exception of 287 encryption keys) and to announce the resources to be used to any non- 288 participants that may need to know. (This latter feature is 289 primarily useful when SDP is used with a multicast session 290 announcement protocol.) 292 4.1. Media and Transport Information 294 An SDP description includes the following media information: 296 o The type of media (video, audio, etc.) 298 o The media transport protocol (RTP/UDP/IP, H.320, etc.) 300 o The format of the media (H.261 video, MPEG video, etc.) 302 In addition to media format and transport protocol, SDP conveys 303 address and port details. For an IP multicast session, these 304 comprise: 306 o The multicast group address for media 308 o The transport port for media 310 This address and port are the destination address and destination 311 port of the multicast stream, whether being sent, received, or both. 313 For unicast IP sessions, the following are conveyed: 315 o The remote address for media 317 o The remote transport port for media 319 The semantics of this address and port depend on the media and 320 transport protocol defined. By default, this SHOULD be the remote 321 address and remote port to which media is sent. Some media types may 322 redefine this behavior, but this is NOT RECOMMENDED since it 323 complicates implementations (including middleboxes that must parse 324 the addresses to open Network Address Translation (NAT) or firewall 325 pinholes). 327 4.2. Timing Information 329 Sessions may be either bounded or unbounded in time. Whether or not 330 they are bounded, they may be only active at specific times. SDP can 331 convey: 333 o An arbitrary list of start and stop times bounding the session 335 o For each bound, repeat times such as "every Wednesday at 10am for 336 one hour" 338 This timing information is globally consistent, irrespective of local 339 time zone or daylight saving time (see Section 5.9). 341 4.3. Obtaining Further Information about a Session 343 A session description could convey enough information to decide 344 whether or not to participate in a session. SDP may include 345 additional pointers in the form of Uniform Resource Identifiers 346 (URIs) for more information about the session. 348 4.4. Categorization 350 When many session descriptions are being distributed by an 351 advertisement mechanism, it may be desirable to filter session 352 descriptions that are of interest from those that are not. SDP 353 supports a categorization mechanism for sessions that is capable of 354 being automated (the "a=cat:" attribute; see Section 6). 356 4.5. Internationalization 358 The SDP specification recommends the use of the ISO 10646 character 359 set in the UTF-8 encoding [RFC3629] to allow many different languages 360 to be represented. However, to assist in compact representations, 361 SDP also allows other character sets such as ISO 8859-1 to be used 362 when desired. Internationalization only applies to free-text sub- 363 fields (session name and background information), and not to SDP as a 364 whole. 366 5. SDP Specification 368 An SDP description is denoted by the media type "application/sdp" 369 (See Section 8). 371 An SDP description is entirely textual. SDP field names and 372 attribute names use only the US-ASCII subset of UTF-8 [RFC3629], but 373 textual fields and attribute values MAY use the full ISO 10646 374 character set in UTF-8 encoding, or some other character set defined 375 by the "a=charset:" attribute. Field and attribute values that use 376 the full UTF-8 character set are never directly compared, hence there 377 is no requirement for UTF-8 normalization. The textual form, as 378 opposed to a binary encoding such as ASN.1 or XDR, was chosen to 379 enhance portability, to enable a variety of transports to be used, 380 and to allow flexible, text-based toolkits to be used to generate and 381 process session descriptions. However, since SDP may be used in 382 environments where the maximum permissible size of a session 383 description is limited, the encoding is deliberately compact. Also, 384 since descriptions may be transported via very unreliable means or 385 damaged by an intermediate caching server, the encoding was designed 386 with strict order and formatting rules so that most errors would 387 result in malformed session descriptions that could be detected 388 easily and discarded. This also allows rapid discarding of encrypted 389 session descriptions for which a receiver does not have the correct 390 key. 392 An SDP description consists of a number of lines of text of the form: 394 = 396 where MUST be exactly one case-significant character and 397 is structured text whose format depends on . In 398 general, is either a number of sub-fields delimited by a 399 single space character or a free format string, and is case- 400 significant unless a specific field defines otherwise. Whitespace 401 separators MUST NOT be used on either side of the "=" sign, however, 402 the value can contain a leading whitespace as part of its syntax, 403 i.e., that whitespace is part of the value. 405 An SDP description MUST conform to the syntax defined in Section 9. 406 The following is an overview of the syntax: 408 An SDP description consists of a session-level section followed by 409 zero or more media descriptions. The session-level section starts 410 with a "v=" line and continues to the first media description (or the 411 end of the whole description, whichever comes first). Each media 412 description starts with an "m=" line and continues to the next media 413 description or the end of the whole session description, whichever 414 comes first. In general, session-level values are the default for 415 all media unless overridden by an equivalent media-level value. 417 Some lines in each description are required and some are optional, 418 but all must appear in exactly the order given here. (The fixed 419 order greatly enhances error detection and allows for a simple 420 parser). In the following overview optional items are marked with a 421 "*". 423 Session description 424 v= (protocol version) 425 o= (originator and session identifier) 426 s= (session name) 427 i=* (session information) 428 u=* (URI of description) 429 e=* (email address) 430 p=* (phone number) 431 c=* (connection information -- not required if included in 432 all media descriptions) 433 b=* (zero or more bandwidth information lines) 434 One or more time descriptions: 435 ("t=", "r=" and "z=" lines; see below) 436 k=* (obsolete) 437 a=* (zero or more session attribute lines) 438 Zero or more media descriptions 440 Time description 441 t= (time the session is active) 442 r=* (zero or more repeat times) 443 z=* (optional time zone offset line) 445 Media description, if present 446 m= (media name and transport address) 447 i=* (media title) 448 c=* (connection information -- optional if included at 449 session level) 450 b=* (zero or more bandwidth information lines) 451 k=* (obsolete) 452 a=* (zero or more media attribute lines) 454 The set of type letters is deliberately small and not intended to be 455 extensible -- an SDP parser MUST completely ignore any session 456 description that contains a type letter that it does not understand. 457 The attribute mechanism ("a=" described below) is the primary means 458 for extending SDP and tailoring it to particular applications or 459 media. Some attributes (the ones listed in Section 6 of this memo) 460 have a defined meaning, but others may be added on a media- or 461 session-specific basis. (Attribute scopes in addition to media- 462 specific and session-specific may also be defined in extensions to 463 this document. E.g., [RFC5576], 464 [I-D.ietf-mmusic-data-channel-sdpneg].) An SDP parser MUST ignore 465 any attribute it doesn't understand. 467 An SDP description may contain URIs that reference external content 468 in the "u=", "k=", and "a=" lines. These URIs may be dereferenced in 469 some cases, making the session description non-self-contained. 471 The connection ("c=") information in the session-level section 472 applies to all the media descriptions of that session unless 473 overridden by connection information in the media description. For 474 instance, in the example below, each audio media description behaves 475 as if it were given a "c=IN IP4 233.252.0.2". 477 An example SDP description is: 479 v=0 480 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 481 s=SDP Seminar 482 i=A Seminar on the session description protocol 483 u=http://www.example.com/seminars/sdp.pdf 484 e=j.doe@example.com (Jane Doe) 485 c=IN IP4 233.252.0.2 486 t=2873397496 2873404696 487 a=recvonly 488 m=audio 49170 RTP/AVP 0 489 m=audio 49180 RTP/AVP 0 490 m=video 51372 RTP/AVP 99 491 c=IN IP4 233.252.0.1/127 492 a=rtpmap:99 h263-1998/90000 494 Text-containing fields such as the session-name-field and 495 information-field are octet strings that may contain any octet with 496 the exceptions of 0x00 (Nul), 0x0a (ASCII newline), and 0x0d (ASCII 497 carriage return). The sequence CRLF (0x0d0a) is used to end a line, 498 although parsers SHOULD be tolerant and also accept lines terminated 499 with a single newline character. If the "a=charset" attribute is not 500 present, these octet strings MUST be interpreted as containing 501 ISO-10646 characters in UTF-8 encoding (the presence of the 502 "a=charset" attribute may force some fields to be interpreted 503 differently). 505 A session description can contain domain names in the "o=", "u=", 506 "e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply 507 with [RFC1034], [RFC1035]. Internationalized domain names (IDNs) 508 MUST be represented using the ASCII Compatible Encoding (ACE) form 509 defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or 510 any other encoding (this requirement is for compatibility with 511 [RFC2327] and other early SDP-related standards, which predate the 512 development of internationalized domain names). 514 5.1. Protocol Version ("v=") 516 v=0 518 The "v=" line (version-field) gives the version of the Session 519 Description Protocol. This memo defines version 0. There is no 520 minor version number. 522 5.2. Origin ("o=") 524 o= 525 527 The "o=" line (origin-field) gives the originator of the session (her 528 username and the address of the user's host) plus a session 529 identifier and version number: 531 is the user's login on the originating host, or it is "-" 532 if the originating host does not support the concept of user IDs. 533 The MUST NOT contain spaces. 535 is a numeric string such that the tuple of , 536 , , , and forms a 537 globally unique identifier for the session. The method of allocation is up to the creating tool, but it has been 539 suggested that a Network Time Protocol (NTP) format timestamp be 540 used to ensure uniqueness [RFC5905]. 542 is a version number for this session description. 543 Its usage is up to the creating tool, so long as is 544 increased when a modification is made to the session description. 545 Again, it is RECOMMENDED that an NTP format timestamp is used. 547 is a text string giving the type of network. Initially 548 "IN" is defined to have the meaning "Internet", but other values 549 MAY be registered in the future (see Section 8). 551 is a text string giving the type of the address that 552 follows. Initially "IP4" and "IP6" are defined, but other values 553 MAY be registered in the future (see Section 8). 555 is an address of the machine from which the 556 session was created. For an address type of IP4, this is either a 557 fully qualified domain name of the machine or the dotted-decimal 558 representation of an IP version 4 address of the machine. For an 559 address type of IP6, this is either a fully qualified domain name 560 of the machine or the compressed textual representation of an IP 561 version 6 address of the machine. For both IP4 and IP6, the fully 562 qualified domain name is the form that SHOULD be given unless this 563 is unavailable, in which case a globally unique address MAY be 564 substituted. 566 In general, the "o=" line serves as a globally unique identifier for 567 this version of the session description, and the sub-fields excepting 568 the version, taken together identify the session irrespective of any 569 modifications. 571 For privacy reasons, it is sometimes desirable to obfuscate the 572 username and IP address of the session originator. If this is a 573 concern, an arbitrary and private MAY be 574 chosen to populate the "o=" line, provided that these are selected in 575 a manner that does not affect the global uniqueness of the field. 577 5.3. Session Name ("s=") 579 s= 581 The "s=" line (session-name-field) is the textual session name. 582 There MUST be one and only one "s=" line per session description. 583 The "s=" line MUST NOT be empty and SHOULD contain ISO 10646 584 characters (but see also the "a=charset" attribute). If a session 585 has no meaningful name, the "s= " line SHOULD be used (i.e., a single 586 space as the session name). 588 5.4. Session Information ("i=") 590 i= 592 The "i=" line (information-field) provides textual information about 593 the session. There MUST be at most one session-level "i=" line per 594 session description, and at most one "i=" line in each media 595 description. Unless a media-level "i=" line is provided, the 596 session-level "i=" line applies to that media description. If the 597 "a=charset" attribute is present, it specifies the character set used 598 in the "i=" line. If the "a=charset" attribute is not present, the 599 "i=" line MUST contain ISO 10646 characters in UTF-8 encoding. 601 At most one "i=" line can be used for each media description. In 602 media definitions, "i=" lines are primarily intended for labelling 603 media streams. As such, they are most likely to be useful when a 604 single session has more than one distinct media stream of the same 605 media type. An example would be two different whiteboards, one for 606 slides and one for feedback and questions. 608 The "i=" line is intended to provide a free-form human-readable 609 description of the session or the purpose of a media stream. It is 610 not suitable for parsing by automata. 612 5.5. URI ("u=") 614 u= 616 The "u=" line (uri-field) provides a URI (Uniform Resource 617 Identifier) as used by WWW clients [RFC3986]. The URI should be a 618 pointer to additional information about the session. This line is 619 OPTIONAL. No more than one "u=" line is allowed per session 620 description. 622 5.6. Email Address and Phone Number ("e=" and "p=") 624 e= 625 p= 627 The "e=" line (email-field) and "p=" line (phone-field) specify 628 contact information for the person responsible for the session. This 629 is not necessarily the same person that created the session 630 description. 632 Inclusion of an email address or phone number is OPTIONAL. 634 If an email address or phone number is present, it MUST be specified 635 before the first media description. More than one email or phone 636 line can be given for a session description. 638 Phone numbers SHOULD be given in the form of an international public 639 telecommunication number (see ITU-T Recommendation E.164 [E164]) 640 preceded by a "+". Spaces and hyphens may be used to split up a 641 phone-field to aid readability if desired. For example: 643 p=+1 617 555-6011 645 Both email addresses and phone numbers can have an OPTIONAL free text 646 string associated with them, normally giving the name of the person 647 who may be contacted. This MUST be enclosed in parentheses if it is 648 present. For example: 650 e=j.doe@example.com (Jane Doe) 652 The alternative [RFC5322] name quoting convention is also allowed for 653 both email addresses and phone numbers. For example: 655 e=Jane Doe 657 The free text string SHOULD be in the ISO-10646 character set with 658 UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if 659 the appropriate session-level "a=charset" attribute is set. 661 5.7. Connection Information ("c=") 663 c= 665 The "c=" line (connection-field) contains information necessary to 666 establish a network connection. 668 A session description MUST contain either at least one "c=" line in 669 each media description or a single "c=" line at the session level. 670 It MAY contain a single session-level "c=" line and additional media- 671 level "c=" line(s) per-media-description, in which case the media- 672 level values override the session-level settings for the respective 673 media. 675 The first sub-field ("") is the network type, which is a 676 text string giving the type of network. Initially, "IN" is defined 677 to have the meaning "Internet", but other values MAY be registered in 678 the future (see Section 8). 680 The second sub-field ("") is the address type. This allows 681 SDP to be used for sessions that are not IP based. This memo only 682 defines IP4 and IP6, but other values MAY be registered in the future 683 (see Section 8). 685 The third sub-field ("") is the connection 686 address. Additional sub-fields MAY be added after the connection 687 address depending on the value of the sub-field. 689 When the is IP4 or IP6, the connection address is defined 690 as follows: 692 o If the session is multicast, the connection address will be an IP 693 multicast group address. If the session is not multicast, then 694 the connection address contains the unicast IP address of the 695 expected data source, data relay or data sink as determined by 696 additional attribute-fields. It is not expected that unicast 697 addresses will be given in a session description that is 698 communicated by a multicast announcement, though this is not 699 prohibited. 701 o Sessions using an IP4 multicast connection address MUST also have 702 a time to live (TTL) value present in addition to the multicast 703 address. The TTL and the address together define the scope with 704 which multicast packets sent in this session will be sent. TTL 705 values MUST be in the range 0-255. Although the TTL MUST be 706 specified, its use to scope multicast traffic is deprecated; 707 applications SHOULD use an administratively scoped address 708 instead. 710 The TTL for the session is appended to the address using a slash as a 711 separator. An example is: 713 c=IN IP4 233.252.0.1/127 715 IP6 multicast does not use TTL scoping, and hence the TTL value MUST 716 NOT be present for IP6 multicast. It is expected that IPv6 scoped 717 addresses will be used to limit the scope of multimedia conferences. 719 Hierarchical or layered encoding schemes are data streams where the 720 encoding from a single media source is split into a number of layers. 721 The receiver can choose the desired quality (and hence bandwidth) by 722 only subscribing to a subset of these layers. Such layered encodings 723 are normally transmitted in multiple multicast groups to allow 724 multicast pruning. This technique keeps unwanted traffic from sites 725 only requiring certain levels of the hierarchy. For applications 726 requiring multiple multicast groups, we allow the following notation 727 to be used for the connection address: 729 [/]/ 731 If the number of addresses is not given, it is assumed to be one. 732 Multicast addresses so assigned are contiguously allocated above the 733 base address, so that, for example: 735 c=IN IP4 233.252.0.1/127/3 737 would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3 738 are to be used with a TTL of 127. This is semantically identical to 739 including multiple "c=" lines in a media description: 741 c=IN IP4 233.252.0.1/127 742 c=IN IP4 233.252.0.2/127 743 c=IN IP4 233.252.0.3/127 745 Similarly, an IPv6 example would be: 747 c=IN IP6 FF15::101/3 749 which is semantically equivalent to: 751 c=IN IP6 FF15::101 752 c=IN IP6 FF15::102 753 c=IN IP6 FF15::103 755 (remembering that the TTL sub-field is not present in IP6 multicast). 757 Multiple addresses or "c=" lines MAY be specified on a per media 758 description basis only if they provide multicast addresses for 759 different layers in a hierarchical or layered encoding scheme. 760 Multiple addresses or "c=" lines MUST NOT be specified at session 761 level. 763 The slash notation for multiple addresses described above MUST NOT be 764 used for IP unicast addresses. 766 5.8. Bandwidth Information ("b=") 768 b=: 770 The OPTIONAL "b=" line (bandwidth-field) denotes the proposed 771 bandwidth to be used by the session or media description. The 772 is an alphanumeric modifier giving the meaning of the 773 figure. Two values are defined in this specification, 774 but other values MAY be registered in the future (see Section 8 and 775 [RFC3556], [RFC3890]): 777 CT If the bandwidth of a session is different from the bandwidth 778 implicit from the scope, a "b=CT:..." line SHOULD be supplied for 779 the session giving the proposed upper limit to the bandwidth used 780 (the "conference total" bandwidth). Similarly, if the bandwidth 781 of bundled media streams in an "m=" line is different from the 782 implicit value from the scope, a "b=CT:..." line SHOULD be 783 supplied in the media level. The primary purpose of this is to 784 give an approximate idea as to whether two or more sessions (or 785 bundled media streams) can coexist simultaneously. Note that CT 786 gives a total bandwidth figure for all the media at all endpoints. 788 AS The bandwidth is interpreted to be application specific (it will 789 be the application's concept of maximum bandwidth). Normally, 790 this will coincide with what is set on the application's "maximum 791 bandwidth" control if applicable. For RTP-based applications, AS 792 gives the RTP "session bandwidth" as defined in Section 6.2 of 793 [RFC3550]. Note that AS gives a bandwidth figure for a single 794 media at a single endpoint, although there may be many endpoints 795 sending simultaneously. 797 [RFC4566] defined an "X-" prefix for names. This was 798 intended for experimental purposes only. For example: 800 b=X-YZ:128 802 Use of the "X-" prefix is NOT RECOMMENDED. Instead new (non "X-" 803 prefix) names SHOULD be defined, and then MUST be registered 804 with IANA in the standard namespace. SDP parsers MUST ignore 805 bandwidth-fields with unknown names. The names 806 MUST be alphanumeric and, although no length limit is given, it is 807 recommended that they be short. 809 The is interpreted as kilobits per second by default 810 (including the transport and network-layer but not the link-layer 811 overhead). The definition of a new modifier MAY specify 812 that the bandwidth is to be interpreted in some alternative unit (the 813 "CT" and "AS" modifiers defined in this memo use the default units). 815 5.9. Time Active ("t=") 817 t= 819 A "t=" line (time-field) begins a time description that specifies the 820 start and stop times for a session. Multiple time descriptions MAY 821 be used if a session is active at multiple irregularly spaced times; 822 each additional time description specifies additional periods of time 823 for which the session will be active. If the session is active at 824 regular repeat times, a repeat description, begun by an "r=" line 825 (see below) can be included following the time-field -- in which case 826 the time-field specifies the start and stop times of the entire 827 repeat sequence. 829 The following example specifies two active intervals: 831 t=3724394400 3724398000 ; Mon 8-Jan-2018 10:00-11:00 UTC 832 t=3724484400 3724488000 ; Tue 9-Jan-2018 11:00-12:00 UTC 834 The first and second sub-fields of the time-field give the start and 835 stop times, respectively, for the session. These values are the 836 decimal representation of Network Time Protocol (NTP) time values in 837 seconds since 1900 [RFC5905]. To convert these values to UNIX time 838 (UTC), subtract decimal 2208988800. 840 NTP timestamps are elsewhere represented by 64-bit values, which wrap 841 sometime in the year 2036. Since SDP uses an arbitrary length 842 decimal representation, this should not cause an issue (SDP 843 timestamps MUST continue counting seconds since 1900 - NTP will use 844 the value modulo the 64-bit limit). 846 If the is set to zero, then the session is not bounded, 847 though it will not become active until after the . If 848 the is also zero, the session is regarded as permanent. 850 User interfaces SHOULD strongly discourage the creation of unbounded 851 and permanent sessions as they give no information about when the 852 session is actually going to terminate, and so make scheduling 853 difficult. 855 The general assumption may be made, when displaying unbounded 856 sessions that have not timed out to the user, that an unbounded 857 session will only be active until half an hour from the current time 858 or the session start time, whichever is the later. If behavior other 859 than this is required, an end-time SHOULD be given and modified as 860 appropriate when new information becomes available about when the 861 session should really end. 863 Permanent sessions may be shown to the user as never being active 864 unless there are associated repeat times that state precisely when 865 the session will be active. 867 5.10. Repeat Times ("r=") 869 r= 871 An"r=" line (repeat-field) specifies repeat times for a session. If 872 needed to express complex schedules, multiple repeat-fields may be 873 included. For example, if a session is active at 10am on Monday and 874 11am on Tuesday for one hour each week for three months, then the 875 in the corresponding "t=" line would be the NTP 876 representation of 10am on the first Monday, the 877 would be 1 week, the would be 1 hour, and the 878 offsets would be zero and 25 hours. The corresponding "t=" line stop 879 time would be the NTP representation of the end of the last session 880 three months later. By default, all sub-fields are in seconds, so 881 the "r=" and "t=" lines might be the following: 883 t=3724394400 3730536000 ; Mon 8-Jan-2018 10:00-11:00 UTC 884 ; Tues 20-Mar-2018 12:00 UTC 885 r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours 887 To make the description more compact, times may also be given in 888 units of days, hours, or minutes. The syntax for these is a number 889 immediately followed by a single case-sensitive character. 890 Fractional units are not allowed -- a smaller unit should be used 891 instead. The following unit specification characters are allowed: 893 d - days (86400 seconds) 894 h - hours (3600 seconds) 895 m - minutes (60 seconds) 896 s - seconds (allowed for completeness) 898 Thus, the above repeat-field could also have been written: 900 r=7d 1h 0 25h 902 Monthly and yearly repeats cannot be directly specified with a single 903 SDP repeat time; instead, separate time-descriptions should be used 904 to explicitly list the session times. 906 5.11. Time Zone Adjustment ("z=") 908 z= .... 910 A "z=" line (zone-field) is an optional modifier to the repeat-fields 911 it immediately follows. It does not apply to any other fields. 913 To schedule a repeated session that spans a change from daylight 914 saving time to standard time or vice versa, it is necessary to 915 specify offsets from the base time. This is required because 916 different time zones change time at different times of day, different 917 countries change to or from daylight saving time on different dates, 918 and some countries do not have daylight saving time at all. 920 Thus, in order to schedule a session that is at the same time winter 921 and summer, it must be possible to specify unambiguously by whose 922 time zone a session is scheduled. To simplify this task for 923 receivers, we allow the sender to specify the NTP time that a time 924 zone adjustment happens and the offset from the time when the session 925 was first scheduled. The "z=" line allows the sender to specify a 926 list of these adjustment times and offsets from the base time. 928 An example might be the following: 930 t=3724394400 3754123200 ; Mon 8-Jan-2018 10:00 UTC 931 ; Tues 18-Dec-2018 12:00 UTC 932 r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours 933 z=3730928400 -1h 3749680800 0 ; Sun 25-Mar-2018 1:00 UTC, 934 ; offset 1 hour, 935 ; Sun 28-Oct-2018 2:00 UTC, no offset 937 This specifies that at time 3730928400 (Sun 25-Mar-2018 1:00 UTC, the 938 onset of British Summer Time) the time base by which the session's 939 repeat times are calculated is shifted back by 1 hour, and that at 940 time 3749680800 (Sun 28-Oct-2018 2:00 UTC, the end of British Summer 941 Time) the session's original time base is restored. Adjustments are 942 always relative to the specified start time -- they are not 943 cumulative. 945 If a session is likely to last several years, it is expected that the 946 session description will be modified periodically rather than 947 transmit several years' worth of adjustments in one session 948 description. 950 5.12. Encryption Keys ("k=") 952 k= 953 k=: 955 The "k=" line (key-field) is obsolete and MUST NOT be used. It is 956 included in this document for legacy reasons. One MUST NOT include a 957 "k=" line in an SDP, and MUST discard it if it is received in an SDP. 959 5.13. Attributes ("a=") 961 a= 962 a=: 964 Attributes are the primary means for extending SDP. Attributes may 965 be defined to be used as "session-level" attributes, "media-level" 966 attributes, or both. (Attribute scopes in addition to media- and 967 session- level may also be defined in extensions to this document. 968 E.g., [RFC5576], [I-D.ietf-mmusic-data-channel-sdpneg].) 970 A media description may contain any number of "a=" lines (attribute- 971 fields) that are media description specific. These are referred to 972 as "media-level" attributes and add information about the media 973 description. Attribute-fields can also be added before the first 974 media description; these "session-level" attributes convey additional 975 information that applies to the session as a whole rather than to 976 individual media descriptions. 978 Attribute-fields may be of two forms: 980 o A property attribute is simply of the form "a=". These 981 are binary attributes, and the presence of the attribute conveys 982 that the attribute is a property of the session. An example might 983 be "a=recvonly". 985 o A value attribute is of the form "a=:". For 986 example, a whiteboard could have the value attribute 987 "a=orient:landscape" 989 Attribute interpretation depends on the media tool being invoked. 990 Thus receivers of session descriptions should be configurable in 991 their interpretation of session descriptions in general and of 992 attributes in particular. 994 Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. 996 Attribute values are octet strings, and MAY use any octet value 997 except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute 998 values are to be interpreted as in ISO-10646 character set with UTF-8 999 encoding. Unlike other text fields, attribute values are NOT 1000 normally affected by the "charset" attribute as this would make 1001 comparisons against known values problematic. However, when an 1002 attribute is defined, it can be defined to be charset dependent, in 1003 which case its value should be interpreted in the session charset 1004 rather than in ISO-10646. 1006 Attributes MUST be registered with IANA (see Section 8). If an 1007 attribute is received that is not understood, it MUST be ignored by 1008 the receiver. 1010 5.14. Media Descriptions ("m=") 1012 m= ... 1014 A session description may contain a number of media descriptions. 1015 Each media description starts with an "m=" line (media-field) and is 1016 terminated by either the next "m=" line or by the end of the session 1017 description. A media-field has several sub-fields: 1019 is the media type. This document defines the values 1020 "audio", "video", "text", "application", and "message". This list 1021 is extended by other memos and may be further extended by 1022 additional memos registering media types in the future (see 1023 Section 8). For example, [RFC6466] defined the "image" media 1024 type. 1026 is the transport port to which the media stream is sent. The 1027 meaning of the transport port depends on the network being used as 1028 specified in the relevant "c=" line, and on the transport protocol 1029 defined in the sub-field of the media-field. Other ports 1030 used by the media application (such as the RTP Control Protocol 1031 (RTCP) port [RFC3550]) MAY be derived algorithmically from the 1032 base media port or MAY be specified in a separate attribute (for 1033 example, "a=rtcp:" as defined in [RFC3605]). 1035 If non-contiguous ports are used or if they don't follow the 1036 parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" 1037 attribute MUST be used. Applications that are requested to send 1038 media to a that is odd and where the "a=rtcp:" is present 1039 MUST NOT subtract 1 from the RTP port: that is, they MUST send the 1040 RTP to the port indicated in and send the RTCP to the port 1041 indicated in the "a=rtcp" attribute. 1043 For applications where hierarchically encoded streams are being 1044 sent to a unicast address, it may be necessary to specify multiple 1045 transport ports. This is done using a similar notation to that 1046 used for IP multicast addresses in the "c=" line: 1048 m= / ... 1050 In such a case, the ports used depend on the transport protocol. 1051 For RTP, the default is that only the even-numbered ports are used 1052 for data with the corresponding one-higher odd ports used for the 1053 RTCP belonging to the RTP session, and the 1054 denoting the number of RTP sessions. For example: 1056 m=video 49170/2 RTP/AVP 31 1058 would specify that ports 49170 and 49171 form one RTP/RTCP pair 1059 and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the 1060 transport protocol and 31 is the format (see below). 1062 This document does not include a mechanism for declaring 1063 hierarchically encoded streams using non-contiguous ports. (There 1064 is currently no attribute defined that can accomplish this. The 1065 "a=rtcp:" defined in [RFC3605] does not handle hierarchical 1066 encoding.) If a need arises to declare non-contiguous ports then 1067 it will be necessary to define a new attribute to do so. 1069 If multiple addresses are specified in the "c=" line and multiple 1070 ports are specified in the "m=" line, a one-to-one mapping from 1071 port to the corresponding address is implied. For example: 1073 c=IN IP4 233.252.0.1/127/2 1074 m=video 49170/2 RTP/AVP 31 1076 would imply that address 233.252.0.1 is used with ports 49170 and 1077 49171, and address 233.252.0.2 is used with ports 49172 and 49173. 1079 This document gives no meaning to assigning the same media address 1080 to multiple media-descriptions. Doing so does not implicitly 1081 group those media-descriptions in any way. An explicit grouping 1082 framework (for example, [RFC5888]) should instead be used to 1083 express the intended semantics. For instance, see 1084 [I-D.ietf-mmusic-sdp-bundle-negotiation]. 1086 is the transport protocol. The meaning of the transport 1087 protocol is dependent on the address type sub-field in the 1088 relevant "c=" line. Thus a "c=" line with an address type of IP4 1089 indicates that the transport protocol runs over IPv4. The 1090 following transport protocols are defined, but may be extended 1091 through registration of new protocols with IANA (see Section 8): 1093 * udp: denotes that the data is transported directly in UDP with 1094 no additional framing. 1096 * RTP/AVP: denotes RTP [RFC3550] used under the RTP Profile for 1097 Audio and Video Conferences with Minimal Control [RFC3551] 1098 running over UDP. 1100 * RTP/SAVP: denotes the Secure Real-time Transport Protocol 1101 [RFC3711] running over UDP. 1103 The main reason to specify the transport protocol in addition to 1104 the media format is that the same standard media formats may be 1105 carried over different transport protocols even when the network 1106 protocol is the same -- a historical example is VAT (MBone's 1107 popular multimedia audio tool) Pulse Code Modulation (PCM) audio 1108 and RTP PCM audio; another might be TCP/RTP PCM audio. In 1109 addition, relays and monitoring tools that are transport-protocol- 1110 specific but format-independent are possible. 1112 is a media format description. The fourth and any subsequent 1113 sub-fields describe the format of the media. The interpretation 1114 of the media format depends on the value of the sub-field. 1116 If the sub-field is "RTP/AVP" or "RTP/SAVP" the sub- 1117 fields contain RTP payload type numbers. When a list of payload 1118 type numbers is given, this implies that all of these payload 1119 formats MAY be used in the session, but the first of these formats 1120 SHOULD be used as the default format for the session. For dynamic 1121 payload type assignments the "a=rtpmap:" attribute (see Section 6) 1122 SHOULD be used to map from an RTP payload type number to a media 1123 encoding name that identifies the payload format. The "a=fmtp:" 1124 attribute MAY be used to specify format parameters (see 1125 Section 6). 1127 If the sub-field is "udp" the sub-fields MUST 1128 reference a media type describing the format under the "audio", 1129 "video", "text", "application", or "message" top-level media 1130 types. The media type registration SHOULD define the packet 1131 format for use with UDP transport. 1133 For media using other transport protocols, the sub-field is 1134 protocol specific. Rules for interpretation of the sub- 1135 field MUST be defined when registering new protocols (see 1136 Section 8.2.2). 1138 Section 3 of [RFC4855] states that the payload format (encoding) 1139 names defined in the RTP Profile are commonly shown in upper case, 1140 while media subtype names are commonly shown in lower case. It 1141 also states that both of these names are case-insensitive in both 1142 places, similar to parameter names which are case-insensitive both 1143 in media type strings and in the default mapping to the SDP a=fmtp 1144 attribute. 1146 6. SDP Attributes 1148 The following attributes are defined. Since application writers may 1149 add new attributes as they are required, this list is not exhaustive. 1150 Registration procedures for new attributes are defined in 1151 Section 8.2.4. Syntax is provided using ABNF [RFC7405] with some of 1152 the rules defined further in Section 9. 1154 6.1. cat (category) 1156 Name: cat 1158 Value: cat-value 1160 Usage Level: session 1162 Charset Dependent: no 1164 Syntax: 1166 cat-value = category 1167 category = non-ws-string 1169 Example: 1171 a=cat:foo.bar 1173 This attribute gives the dot-separated hierarchical category of the 1174 session. This is to enable a receiver to filter unwanted sessions by 1175 category. There is no central registry of categories. This 1176 attribute is obsolete and SHOULD NOT be used. It SHOULD be ignored 1177 if received. 1179 6.2. keywds (keywords) 1181 Name: keywds 1183 Value: keywds-value 1185 Usage Level: session 1187 Charset Dependent: yes 1189 Syntax: 1191 keywds-value = keywords 1192 keywords = text 1194 Example: 1196 a=keywds:SDP session description protocol 1198 Like the cat attribute, this is to assist identifying wanted sessions 1199 at the receiver. This allows a receiver to select interesting 1200 sessions based on keywords describing the purpose of the session; 1201 there is no central registry of keywords. Its value should be 1202 interpreted in the charset specified for the session description if 1203 one is specified, or by default in ISO 10646/UTF-8. This attribute 1204 is obsolete and SHOULD NOT be used. It SHOULD be ignored if 1205 received. 1207 6.3. tool 1209 Name: tool 1211 Value: tool-value 1213 Usage Level: session 1215 Charset Dependent: no 1217 Syntax: 1219 tool-value = tool-name-and-version 1220 tool-name-and-version = text 1222 Example: 1224 a=tool:foobar V3.2 1226 This gives the name and version number of the tool used to create the 1227 session description. 1229 6.4. ptime (packet time) 1231 Name: ptime 1233 Value: ptime-value 1235 Usage Level: media 1237 Charset Dependent: no 1239 Syntax: 1241 ptime-value = non-zero-int-or-real 1243 Example: 1245 a=ptime:20 1247 This gives the length of time in milliseconds represented by the 1248 media in a packet. This is probably only meaningful for audio data, 1249 but may be used with other media types if it makes sense. It should 1250 not be necessary to know ptime to decode RTP or vat audio, and it is 1251 intended as a recommendation for the encoding/packetization of audio. 1253 6.5. maxptime (maximum packet time) 1255 Name: maxptime 1257 Value: maxptime-value 1259 Usage Level: media 1261 Charset Dependent: no 1263 Syntax: 1265 maxptime-value = non-zero-int-or-real 1267 Example: 1269 a=maxptime:20 1271 This gives the maximum amount of media that can be encapsulated in 1272 each packet, expressed as time in milliseconds. The time SHALL be 1273 calculated as the sum of the time the media present in the packet 1274 represents. For frame-based codecs, the time SHOULD be an integer 1275 multiple of the frame size. This attribute is probably only 1276 meaningful for audio data, but may be used with other media types if 1277 it makes sense. Note that this attribute was introduced after 1278 [RFC2327], and non-updated implementations will ignore this 1279 attribute. 1281 6.6. rtpmap 1283 Name: rtpmap 1285 Value: rtpmap-value 1287 Usage Level: media 1289 Charset Dependent: no 1291 Syntax: 1293 rtpmap-value = payload-type SP encoding-name 1294 "/" clock-rate [ "/" encoding-params ] 1295 payload-type = zero-based-integer 1296 encoding-name = token 1297 clock-rate = integer 1298 encoding-params = channels 1299 channels = integer 1301 This attribute maps from an RTP payload type number (as used in an 1302 "m=" line) to an encoding name denoting the payload format to be 1303 used. It also provides information on the clock rate and encoding 1304 parameters. Note that the payload type number is indicated in a 1305 7-bit field, limiting the values to inclusively between 0 and 127. 1307 Although an RTP profile can make static assignments of payload type 1308 numbers to payload formats, it is more common for that assignment to 1309 be done dynamically using "a=rtpmap:" attributes. As an example of a 1310 static payload type, consider u-law PCM coded single-channel audio 1311 sampled at 8 kHz. This is completely defined in the RTP Audio/Video 1312 profile as payload type 0, so there is no need for an "a=rtpmap:" 1313 attribute, and the media for such a stream sent to UDP port 49232 can 1314 be specified as: 1316 m=audio 49232 RTP/AVP 0 1318 An example of a dynamic payload type is 16-bit linear encoded stereo 1319 audio sampled at 16 kHz. If we wish to use the dynamic RTP/AVP 1320 payload type 98 for this stream, additional information is required 1321 to decode it: 1323 m=audio 49232 RTP/AVP 98 1324 a=rtpmap:98 L16/16000/2 1326 Up to one rtpmap attribute can be defined for each media format 1327 specified. Thus, we might have the following: 1329 m=audio 49230 RTP/AVP 96 97 98 1330 a=rtpmap:96 L8/8000 1331 a=rtpmap:97 L16/8000 1332 a=rtpmap:98 L16/11025/2 1334 RTP profiles that specify the use of dynamic payload types MUST 1335 define the set of valid encoding names and/or a means to register 1336 encoding names if that profile is to be used with SDP. The "RTP/AVP" 1337 and "RTP/SAVP" profiles use media subtypes for encoding names, under 1338 the top-level media type denoted in the "m=" line. In the example 1339 above, the media types are "audio/L8" and "audio/L16". 1341 For audio streams, encoding-params indicates the number of audio 1342 channels. This parameter is OPTIONAL and may be omitted if the 1343 number of channels is one, provided that no additional parameters are 1344 needed. 1346 For video streams, no encoding parameters are currently specified. 1348 Additional encoding parameters MAY be defined in the future, but 1349 codec-specific parameters SHOULD NOT be added. Parameters added to 1350 an "a=rtpmap:" attribute SHOULD only be those required for a session 1351 directory to make the choice of appropriate media to participate in a 1352 session. Codec-specific parameters should be added in other 1353 attributes (for example, "a=fmtp:"). 1355 Note: RTP audio formats typically do not include information about 1356 the number of samples per packet. If a non-default (as defined in 1357 the RTP Audio/Video Profile [RFC3551]) packetization is required, the 1358 "ptime" attribute is used as given above. 1360 6.7. Media Direction Attributes 1362 At most one occurence of recvonly, sendrecv, sendonly, or inactive 1363 MAY appear at session level, and at most one MAY appear in each media 1364 description. 1366 If any one of these appears in a media description then it applies 1367 for that media description. If none appear in a media description 1368 then the one from session level, if any, applies to that media 1369 description. 1371 If none of the media direction attributes is present at either 1372 session level or media level, "sendrecv" SHOULD be assumed as the 1373 default for sessions that are not of the multimedia conference type 1374 "broadcast" or "H332" (see below). 1376 Within the following SDP example, the "inactive" attribute applies to 1377 audio media and the "recvonly" attribute applies to video media. 1379 v=0 1380 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 1381 s=SDP Seminar 1382 i=A Seminar on the session description protocol 1383 u=http://www.example.com/seminars/sdp.pdf 1384 e=j.doe@example.com (Jane Doe) 1385 c=IN IP4 233.252.0.1/127 1386 t=2873397496 2873404696 1387 a=inactive 1388 m=audio 49170 RTP/AVP 0 1389 m=video 51372 RTP/AVP 99 1390 a=rtpmap:99 h263-1998/90000 1391 a=recvonly 1393 6.7.1. recvonly (receive-only) 1395 Name: recvonly 1397 Value: 1399 Usage Level: session, media 1401 Charset Dependent: no 1403 Example: 1405 a=recvonly 1407 This specifies that the tools should be started in receive-only mode 1408 where applicable. Note that recvonly applies to the media only, not 1409 to any associated control protocol. An RTP-based system in recvonly 1410 mode MUST still send RTCP packets as described in [RFC3550] 1411 Section 6. 1413 6.7.2. sendrecv (send-receive) 1415 Name: sendrecv 1417 Value: 1419 Usage Level: session, media 1421 Charset Dependent: no 1423 Example: 1425 a=sendrecv 1427 This specifies that the tools should be started in send and receive 1428 mode. This is necessary for interactive multimedia conferences with 1429 tools that default to receive-only mode. 1431 6.7.3. sendonly (send-only) 1433 Name: sendonly 1435 Value: 1437 Usage Level: session, media 1439 Charset Dependent: no 1441 Example: 1443 a=sendonly 1445 This specifies that the tools should be started in send-only mode. 1446 An example may be where a different unicast address is to be used for 1447 a traffic destination than for a traffic source. In such a case, two 1448 media descriptions may be used, one sendonly and one recvonly. Note 1449 that sendonly applies only to the media, and any associated control 1450 protocol (e.g., RTCP) SHOULD still be received and processed as 1451 normal. 1453 6.7.4. inactive 1455 Name: inactive 1457 Value: 1459 Usage Level: session, media 1461 Charset Dependent: no 1463 Example: 1465 a=inactive 1467 This specifies that the tools should be started in inactive mode. 1468 This is necessary for interactive multimedia conferences where users 1469 can put other users on hold. No media is sent over an inactive media 1470 stream. Note that an RTP-based system MUST still send RTCP (if RTCP 1471 is used), even if started inactive. 1473 6.8. orient (orientation) 1475 Name: orient 1477 Value: orient-value 1479 Usage Level: media 1481 Charset Dependent: no 1483 Syntax: 1485 orient-value = portrait / landscape / seascape 1486 portrait = %s"portrait" 1487 landscape = %s"landscape" 1488 seascape = %s"seascape" 1489 ; NOTE: These names are case-sensitive. 1491 Example: 1493 a=orient:portrait 1495 Normally this is only used for a whiteboard or presentation tool. It 1496 specifies the orientation of the workspace on the screen. Permitted 1497 values are "portrait", "landscape", and "seascape" (upside-down 1498 landscape). 1500 6.9. type (conference type) 1502 Name: type 1504 Value: type-value 1506 Usage Level: session 1508 Charset Dependent: no 1509 Syntax: 1511 type-value = conference-type 1512 conference-type = broadcast / meeting / moderated / test / 1513 H332 1514 broadcast = %s"broadcast" 1515 meeting = %s"meeting" 1516 moderated = %s"moderated" 1517 test = %s"test" 1518 H332 = %s"H332" 1519 ; NOTE: These names are case-sensitive. 1521 Example: 1523 a=type:moderated 1525 This specifies the type of the multimedia conference. Suggested 1526 values are "broadcast", "meeting", "moderated", "test", and "H332". 1527 "recvonly" should be the default for "type:broadcast" sessions, 1528 "type:meeting" should imply "sendrecv", and "type:moderated" should 1529 indicate the use of a floor control tool and that the media tools are 1530 started so as to mute new sites joining the multimedia conference. 1532 Specifying the attribute "type:H332" indicates that this loosely 1533 coupled session is part of an H.332 session as defined in the ITU 1534 H.332 specification [ITU.H332.1998]. Media tools should be started 1535 "recvonly". 1537 Specifying the attribute "type:test" is suggested as a hint that, 1538 unless explicitly requested otherwise, receivers can safely avoid 1539 displaying this session description to users. 1541 6.10. charset (character set) 1543 Name: charset 1545 Value: charset-value 1547 Usage Level: session 1549 Charset Dependent: no 1551 Syntax: 1553 charset-value = 1555 This specifies the character set to be used to display the session 1556 name and information data. By default, the ISO-10646 character set 1557 in UTF-8 encoding is used. If a more compact representation is 1558 required, other character sets may be used. For example, the ISO 1559 8859-1 is specified with the following SDP attribute: 1561 a=charset:ISO-8859-1 1563 The charset specified MUST be one of those registered in the IANA 1564 Character Sets registry (http://www.iana.org/assignments/character- 1565 sets), such as ISO-8859-1. The character set identifier is a string 1566 in the US-ASCII subset of UTF-8 and MUST be compared against 1567 identifiers from the "Name" or "Preferred MIME Name" field of the 1568 registry using a case-insensitive comparison. If the identifier is 1569 not recognised or not supported, all strings that are affected by it 1570 SHOULD be regarded as octet strings. 1572 Note that a character set specified MUST still prohibit the use of 1573 bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets requiring 1574 the use of these characters MUST define a quoting mechanism that 1575 prevents these bytes from appearing within text fields. 1577 6.11. sdplang (SDP language) 1579 Name: sdplang 1581 Value: sdplang-value 1583 Usage Level: session, media 1585 Charset Dependent: no 1587 Syntax: 1589 sdplang-value = Language-Tag 1590 ; Language-Tag defined in RFC5646 1592 Example: 1594 a=sdplang:fr 1596 Multiple sdplang attributes can be provided either at session or 1597 media level if the session description or media use multiple 1598 languages. 1600 As a session-level attribute, it specifies the language for the 1601 session description (not the language of the media). As a media- 1602 level attribute, it specifies the language for any media-level SDP 1603 information-field associated with that media (again not the language 1604 of the media), overriding any sdplang attributes specified at session 1605 level. 1607 In general, sending session descriptions consisting of multiple 1608 languages is discouraged. Instead, multiple sesssion descriptions 1609 SHOULD be sent describing the session, one in each language. 1610 However, this is not possible with all transport mechanisms, and so 1611 multiple sdplang attributes are allowed although NOT RECOMMENDED. 1613 The "sdplang" attribute value must be a single [RFC5646] language tag 1614 in the US-ASCII subset of UTF-8. An "sdplang" attribute SHOULD be 1615 specified when a session is distributed with sufficient scope to 1616 cross geographic boundaries, where the language of recipients cannot 1617 be assumed, or where the session is in a different language from the 1618 locally assumed norm. 1620 6.12. lang (language) 1622 Name: lang 1624 Value: lang-value 1626 Usage Level: session, media 1628 Charset Dependent: no 1630 Syntax: 1632 lang-value = Language-Tag 1633 ; Language-Tag defined in RFC5646 1635 Example: 1637 a=lang:de 1639 Multiple lang attributes can be provided either at session or media 1640 level if the session or media has capabilities in more than one 1641 language, in which case the order of the attributes indicates the 1642 order of preference of the various languages in the session or media, 1643 from most preferred to least preferred. 1645 As a session-level attribute, lang specifies a language capability 1646 for the session being described. As a media-level attribute, it 1647 specifies a language capability for that media, overriding any 1648 session-level language(s) specified. 1650 The "lang" attribute value must be a single [RFC5646] language tag in 1651 the US-ASCII subset of UTF-8. A "lang" attribute SHOULD be specified 1652 when a session is of sufficient scope to cross geographic boundaries 1653 where the language of participants cannot be assumed, or where the 1654 session has capabilities in languages different from the locally 1655 assumed norm. 1657 The "lang" attribute is supposed to be used for setting the initial 1658 language(s) used in the session. Events during the session may 1659 influence which language(s) are used, and the participants are not 1660 strictly bound to only use the declared languages. 1662 Most real-time use cases start with just one language used, while 1663 other cases involve a range of languages, e.g. an interpreted or 1664 subtitled session. When more than one 'lang' attribute is specified, 1665 the "lang" attribute itself does not provide any information about 1666 multiple languages being intended to be used during the session, or 1667 if the intention is to only select one of the languages. If needed, 1668 a new attribute can be defined and used to indicate such intentions. 1669 Without such semantics, it is assumed that for a negotiated session 1670 one of the declared languages will be selected and used. 1672 6.13. framerate (frame rate) 1674 Name: framerate 1676 Value: framerate-value 1678 Usage Level: media 1680 Charset Dependent: no 1682 Syntax: 1684 framerate-value = non-zero-int-or-real 1686 Example: 1688 a=framerate:60 1690 This gives the maximum video frame rate in frames/sec. It is 1691 intended as a recommendation for the encoding of video data. Decimal 1692 representations of fractional values are allowed. It is defined only 1693 for video media. 1695 6.14. quality 1697 Name: quality 1699 Value: quality-value 1700 Usage Level: media 1702 Charset Dependent: no 1704 Syntax: 1706 quality-value = zero-based-integer 1708 Example: 1710 a=quality:10 1712 This gives a suggestion for the quality of the encoding as an integer 1713 value. The intention of the quality attribute for video is to 1714 specify a non-default trade-off between frame-rate and still-image 1715 quality. For video, the value is in the range 0 to 10, with the 1716 following suggested meaning: 1718 10 - the best still-image quality the compression scheme 1719 can give. 1720 5 - the default behavior given no quality suggestion. 1721 0 - the worst still-image quality the codec designer 1722 thinks is still usable. 1724 6.15. fmtp (format parameters) 1726 Name: fmtp 1728 Value: fmtp-value 1730 Usage Level: media 1732 Charset Dependent: no 1734 Syntax: 1736 fmtp-value = fmt SP format-specific-params 1737 format-specific-params = byte-string 1738 ; Notes: 1739 ; - The format parameters are media type parameters and 1740 ; need to reflect their syntax. 1742 Example: 1744 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1746 This attribute allows parameters that are specific to a particular 1747 format to be conveyed in a way that SDP does not have to understand 1748 them. The format must be one of the formats specified for the media. 1749 Format-specific parameters, semicolon separated, may be any set of 1750 parameters required to be conveyed by SDP and given unchanged to the 1751 media tool that will use this format. At most one instance of this 1752 attribute is allowed for each format. 1754 The fmtp attribute may be used to specify parameters for any protocol 1755 and format that defines use of such parameters. 1757 7. Security Considerations 1759 SDP is frequently used with the Session Initiation Protocol [RFC3261] 1760 using the offer/answer model [RFC3264] to agree on parameters for 1761 unicast sessions. When used in this manner, the security 1762 considerations of those protocols apply. 1764 SDP is a session description format that describes multimedia 1765 sessions. Entities receiving and acting upon an SDP message SHOULD 1766 be aware that a session description cannot be trusted unless it has 1767 been obtained by an authenticated and integrity-protected transport 1768 protocol from a known and trusted source. Many different transport 1769 protocols may be used to distribute session descriptions, and the 1770 nature of the authentication and integrity-protection will differ 1771 from transport to transport. For some transports, security features 1772 are often not deployed. In case a session description has not been 1773 obtained in a trusted manner, the endpoint SHOULD exercise care 1774 because, among other attacks, the media sessions received may not be 1775 the intended ones, the destination where media is sent to may not be 1776 the expected one, any of the parameters of the session may be 1777 incorrect, or the media security may be compromised. It is up to the 1778 endpoint to make a sensible decision taking into account the security 1779 risks of the application and the user preferences - the endpoint may 1780 decide to ask the user whether or not to accept the session. 1782 On receiving a session description over an unauthenticated transport 1783 mechanism or from an untrusted party, software parsing the session 1784 should take a few precautions. Similar concerns apply if integrity 1785 protection is not in place. Session descriptions contain information 1786 required to start software on the receiver's system. Software that 1787 parses a session description MUST NOT be able to start other software 1788 except that which is specifically configured as appropriate software 1789 to participate in multimedia sessions. It is normally considered 1790 inappropriate for software parsing a session description to start, on 1791 a user's system, software that is appropriate to participate in 1792 multimedia sessions, without the user first being informed that such 1793 software will be started and giving the user's consent. Thus, a 1794 session description arriving by session announcement, email, session 1795 invitation, or WWW page MUST NOT deliver the user into an interactive 1796 multimedia session unless the user has explicitly pre-authorized such 1797 action. As it is not always simple to tell whether or not a session 1798 is interactive, applications that are unsure should assume sessions 1799 are interactive. 1801 In this specification, there are no attributes that would allow the 1802 recipient of a session description to be informed to start multimedia 1803 tools in a mode where they default to transmitting. Under some 1804 circumstances it might be appropriate to define such attributes. If 1805 this is done, an application parsing a session description containing 1806 such attributes SHOULD either ignore them or inform the user that 1807 joining this session will result in the automatic transmission of 1808 multimedia data. The default behavior for an unknown attribute is to 1809 ignore it. 1811 In certain environments, it has become common for intermediary 1812 systems to intercept and analyze session descriptions contained 1813 within other signaling protocols. This is done for a range of 1814 purposes, including but not limited to opening holes in firewalls to 1815 allow media streams to pass, or to mark, prioritize, or block traffic 1816 selectively. In some cases, such intermediary systems may modify the 1817 session description, for example, to have the contents of the session 1818 description match NAT bindings dynamically created. These behaviors 1819 are NOT RECOMMENDED unless the session description is conveyed in 1820 such a manner that allows the intermediary system to conduct proper 1821 checks to establish the authenticity of the session description, and 1822 the authority of its source to establish such communication sessions. 1823 SDP by itself does not include sufficient information to enable these 1824 checks: they depend on the encapsulating protocol (e.g., SIP or 1825 RTSP). Use of some procedures and SDP extensions (e.g., ICE 1826 [RFC8445] and ICE-SIP-SDP [I-D.ietf-mmusic-ice-sip-sdp]) may avoid 1827 the need for intermediaries to modify SDP. 1829 Use of the "k=" line poses a significant security risk, since it 1830 conveys session encryption keys in the clear. SDP MUST NOT be used 1831 to convey keying material, unless it can be guaranteed that the 1832 channel over which the SDP is delivered is both private and 1833 authenticated. Moreover, the "k=" line provides no way to indicate 1834 or negotiate cryptographic key algorithms. As it provides for only a 1835 single symmetric key, rather than separate keys for confidentiality 1836 and integrity, its utility is severely limited. The "k=" line MUST 1837 NOT be used, as discussed in Section 5.12. 1839 8. IANA Considerations 1840 8.1. The "application/sdp" Media Type 1842 One media type registration from [RFC4566] is to be updated, as 1843 defined below. 1845 To: ietf-types@iana.org 1846 Subject: Registration of media type "application/sdp" 1848 Type name: application 1850 Subtype name: sdp 1852 Required parameters: None. 1854 Optional parameters: None. 1856 Encoding considerations: 1857 SDP files are primarily UTF-8 format text. The "a=charset:" 1858 attribute may be used to signal the presence of other character 1859 sets in certain parts of an SDP file (see Section 6 of RFC 1860 XXXX). Arbitrary binary content cannot be directly 1861 represented in SDP. 1863 Security considerations: 1864 See Section 7 of RFC XXXX. 1866 Interoperability considerations: 1867 See RFC XXXX. 1869 Published specification: 1870 See RFC XXXX. 1872 Applications which use this media type: 1873 Voice over IP, video teleconferencing, streaming media, instant 1874 messaging, among others. See also Section 3 of RFC XXXX. 1876 Fragment identifier considerations: None 1878 Additional information: 1880 Deprecated alias names for this type: N/A 1881 Magic number(s): None. 1882 File extension(s): The extension ".sdp" is commonly used. 1883 Macintosh File Type Code(s): "sdp " 1885 Person & email address to contact for further information: 1886 IETF MMUSIC working group 1888 Intended usage: COMMON 1890 Restrictions on usage: None 1892 Author/Change controller: 1893 Authors of RFC XXXX 1894 IETF MMUSIC working group delegated from the IESG 1896 8.2. Registration of Parameters 1898 This specification replaces and updates the definitions of IANA 1899 parameter registries for seven named SDP sub-fields originally 1900 defined in [RFC4566]. Using the terminology in the SDP specification 1901 Augmented Backus-Naur Form (ABNF), they are "media", "proto", "att- 1902 field", "bwtype", "nettype", and "addrtype". 1904 [EDITOR: Please change the RFC references to RFC4566 in these 1905 registries to instead refer to this document.] 1907 The contact address for all parameters registered below is: 1909 The IETF MMUSIC working group or its successor 1910 as designated by the IESG. 1912 8.2.1. Media Types ("media") 1914 The set of media types is intended to be small and SHOULD NOT be 1915 extended except under rare circumstances. The same rules should 1916 apply for media names as for top-level media types, and where 1917 possible the same name should be registered for SDP as for MIME. For 1918 media other than existing top-level media types, a Standards Track 1919 RFC MUST be produced for a new top-level media type to be registered, 1920 and the registration MUST provide good justification why no existing 1921 media name is appropriate (the "Standards Action" policy of 1922 [RFC8126]). 1924 This memo registers the media types "audio", "video", "text", 1925 "application", and "message". 1927 Note: The media types "control" and "data" were listed as valid in an 1928 early version of this specification (RFC 2327); however, their 1929 semantics were never fully specified and they are not widely used. 1930 These media types have been removed in this specification, although 1931 they still remain valid media type capabilities for a SIP user agent 1932 as defined in [RFC3840]. If these media types are considered useful 1933 in the future, a Standards Track RFC MUST be produced to document 1934 their use. Until that is done, applications SHOULD NOT use these 1935 types and SHOULD NOT declare support for them in SIP capabilities 1936 declarations (even though they exist in the registry created by 1937 [RFC3840]). Also note that [RFC6466] defined the "image" media type. 1939 8.2.2. Transport Protocols ("proto") 1941 The "proto" sub-field describes the transport protocol used. The 1942 registration procedure for this registry is "RFC Required". 1944 This document registers two values: "RTP/AVP" is a reference to 1945 [RFC3550] used under the RTP Profile for Audio and Video Conferences 1946 with Minimal Control [RFC3551] running over UDP/IP, and "udp" 1947 indicates direct use of the UDP protocol. 1949 New transport protocols MAY be defined, and MUST be registered with 1950 IANA. Registrations MUST reference an RFC describing the protocol. 1951 Such an RFC MAY be Experimental or Informational, although it is 1952 preferable that it be Standards Track. The RFC defining a new 1953 protocol MUST define the rules by which the "fmt" (see below) 1954 namespace is managed. 1956 "proto" names starting with "RTP/" MUST only be used for defining 1957 transport protocols that are profiles of the RTP protocol. For 1958 example, a profile whose short name is "XYZ" would be denoted by a 1959 "proto" sub-field of "RTP/XYZ". 1961 8.2.3. Media Formats ("fmt") 1963 Each transport protocol, defined by the "proto" sub-field, has an 1964 associated "fmt" namespace that describes the media formats that may 1965 be conveyed by that protocol. Formats cover all the possible 1966 encodings that could be transported in a multimedia session. 1968 RTP payload formats under the "RTP/AVP" and other "RTP/*" profiles 1969 MUST use the payload type number as their "fmt" value. If the 1970 payload type number is dynamically assigned by this session 1971 description, an additional "rtpmap" attribute MUST be included to 1972 specify the format name and parameters as defined by the media type 1973 registration for the payload format. It is RECOMMENDED that other 1974 RTP profiles that are registered (in combination with RTP) as SDP 1975 transport protocols specify the same rules for the "fmt" namespace. 1977 For the "udp" protocol, allowed "fmt" values are media subtypes from 1978 the IANA Media Types registry. The media type and subtype 1979 combination / specifies the format of the body of UDP 1980 packets. Use of an existing media subtype for the format is 1981 encouraged. If no suitable media subtype exists, it is RECOMMENDED 1982 that a new one be registered through the IETF process [RFC6838] by 1983 production of, or reference to, a standards-track RFC that defines 1984 the format. 1986 For other protocols, formats MAY be registered according to the rules 1987 of the associated "proto" specification. 1989 Registrations of new formats MUST specify which transport protocols 1990 they apply to. 1992 8.2.4. Attribute Names ("att-field") 1994 8.2.4.1. New Attributes 1996 Attribute-field names ("att-field") MUST be registered with IANA and 1997 documented, to avoid any issues due to conflicting attribute 1998 definitions under the same name. Unknown attributes in SDP are 1999 simply ignored, but conflicting ones that fragment the protocol are a 2000 serious problem. 2002 New attribute registrations are accepted according to the 2003 "Specification Required" policy of [RFC8126], provided that the 2004 specification includes the following information: 2006 o Contact Name. 2008 o Contact Email Address. 2010 o Attribute Name: The name of the attribute that will appear in 2011 SDP). This MUST conform to the definition of . 2013 o Attribute Syntax: For a value attribute (see clause 5.13), an ABNF 2014 definition of the attribute value syntax (see 2015 Section 9) MUST be provided. The syntax MUST follow the rule form 2016 as per Section 2.2 of [RFC5234] and [RFC7405]. This SHALL define 2017 the allowable values that the attribute might take. It MAY also 2018 define an extension method for the addition of future values. For 2019 a property attribute, the ABNF definition is omitted as the 2020 property attribute takes no values. 2022 o Attribute Semantics: For a value attribute, a semantic description 2023 of the values that the attribute might take MUST be provided. The 2024 usage of a property attribute is described under purpose below. 2026 o Attribute Value: The name of an ABNF syntax rule defining the 2027 syntax of the value. Absence of a rule name indicates that the 2028 attribute takes no values. Enclosing the rule name in "[" and "]" 2029 indicates that a value is optional. 2031 o Usage Level: Usage level(s) of the attribute. One or more of: 2032 session, media, source, dcsa, dcsa(subprotocol). For a definition 2033 of source level attributes, see [RFC5576]. For a definition of 2034 dcsa attributes see: [I-D.ietf-mmusic-data-channel-sdpneg]. 2036 o Charset Dependent: Whether the attribute value is subject to the 2037 charset attribute or not (Yes/No). 2039 o Purpose: An explanation of the purpose and usage of the attribute. 2041 o O/A Procedures: Offer/Answer procedures as explained in [RFC3264]. 2043 o Mux Category: Indication of which multiplexing "category" 2044 [I-D.ietf-mmusic-sdp-mux-attributes] an attribute is associated 2045 with. 2047 o Reference: A reference to the specification defining the 2048 attribute. 2050 The above is the minimum that IANA will accept. Attributes that are 2051 expected to see widespread use and interoperability SHOULD be 2052 documented with a standards-track RFC that specifies the attribute 2053 more precisely. 2055 Submitters of registrations should ensure that the specification is 2056 in the spirit of SDP attributes, most notably that the attribute is 2057 platform independent in the sense that it makes no implicit 2058 assumptions about operating systems and does not name specific pieces 2059 of software in a manner that might inhibit interoperability. 2061 Submitters of registrations should also carefully choose the 2062 attribute usage level. They should not choose only "session" when 2063 the attribute can have different values when media is disaggregated, 2064 i.e., when each m= section has its own IP address on a different 2065 endpoint. In that case the attribute type chosen should be "session, 2066 media" or "media" (depending on desired semantics). The default rule 2067 is that for all new SDP attributes that can occur both in session and 2068 media level, the media level overrides the session level. When this 2069 is not the case for a new SDP attribute, it MUST be explicitly 2070 stated. 2072 IANA has registered the initial set of attribute names ("att-field" 2073 values) with definitions as in Section 6 of this memo (these 2074 definitions replace those in [RFC4566]). 2076 8.2.4.2. Updates to Existing Attributes 2078 Updated attribute registrations are accepted according to the 2079 "Specification Required" policy of [RFC8126]. 2081 The Designated Expert reviewing the update is requested to evaluate 2082 whether the update is compatible with the prior intent and use of the 2083 attribute, and whether the new document is of sufficient maturity and 2084 authority in relation to the prior document. 2086 The specification updating the attribute (for example, by adding a 2087 new value) MUST update registration information items from 2088 Section 8.2.4.1 according to the following bullets: 2090 o Contact Name: A name MUST be provided. 2092 o Contact Email Address: An email address MUST be provided. 2094 o Attribute Name: MUST be provided and MUST NOT be changed. 2095 Otherwise it is a new attribute. 2097 o Attribute Syntax: The existing rule syntax with the syntax 2098 extensions MUST be provided if there is a change to the syntax. A 2099 revision to an existing attribute usage MAY extend the syntax of 2100 an attribute, but MUST be backward compatible. 2102 o Attribute Semantics: A semantic description of new additional 2103 attribute values or a semantic extension of existing values. 2104 Existing attribute values semantics MUST only be extended in a 2105 backward compatible manner. 2107 o Usage Level: Updates MAY only add additional levels. 2109 o Charset Dependent: MUST NOT be changed. 2111 o Purpose: MAY be extended according to the updated usage. 2113 o O/A Procedures: MAY be updated in a backward compatible manner 2114 and/or it applies to a new usage level only. 2116 o Mux Category: No change unless from "TBD" to another value (see 2117 [I-D.ietf-mmusic-sdp-mux-attributes]. It MAY also change if 2118 'media' level is being added to the definition of an attribute 2119 that previously did not include it. 2121 o Reference: A new reference MUST be provided. 2123 Items SHOULD be omitted if there is no impact to them as a result of 2124 the attribute update. 2126 8.2.5. Bandwidth Specifiers ("bwtype") 2128 A proliferation of bandwidth specifiers is strongly discouraged. 2130 New bandwidth specifiers ( sub-field values) MUST be 2131 registered with IANA. The submission MUST reference a standards- 2132 track RFC specifying the semantics of the bandwidth specifier 2133 precisely, and indicating when it should be used, and why the 2134 existing registered bandwidth specifiers do not suffice. 2136 IANA has registered the bandwidth specifiers "CT" and "AS" with 2137 definitions as in Section 5.8 of this memo (these definitions update 2138 those in [RFC4566]). 2140 8.2.6. Network Types ("nettype") 2142 New network types ( sub-field values) MUST be registered 2143 with IANA if SDP needs to be used in the context of non-Internet 2144 environments. The registration is subject to the "RFC Required" 2145 policy of [RFC8126]. Although these are not normally the preserve of 2146 IANA, there may be circumstances when an Internet application needs 2147 to interoperate with a non-Internet application, such as when 2148 gatewaying an Internet telephone call into the Public Switched 2149 Telephone Network (PSTN). The number of network types should be 2150 small and should be rarely extended. A new network type cannot be 2151 registered without registering at least one address type to be used 2152 with that network type. A new network type registration MUST 2153 reference an RFC that gives details of the network type and address 2154 type(s) and specifies how and when they would be used. 2156 IANA has registered the network type "IN" to represent the Internet, 2157 with definition as in Sections 5.2 and 5.7 of this memo (these 2158 definitions update those in [RFC4566]). 2160 8.2.7. Address Types ("addrtype") 2162 New address types ("addrtype") MUST be registered with IANA. The 2163 registration is subject to the "RFC Required" policy of [RFC8126]. 2164 An address type is only meaningful in the context of a network type, 2165 and any registration of an address type MUST specify a registered 2166 network type or be submitted along with a network type registration. 2167 A new address type registration MUST reference an RFC giving details 2168 of the syntax of the address type. Address types are not expected to 2169 be registered frequently. 2171 IANA has registered the address types "IP4" and "IP6" with 2172 definitions as in Sections 5.2 and 5.7 of this memo (these 2173 definitions update those in [RFC4566]). 2175 8.2.8. Registration Procedure 2177 In the RFC specifications that register new values for SDP "media", 2178 "proto", "fmt", "bwtype", "nettype", and "addrtype" parameters, the 2179 authors MUST include the following information for IANA to place in 2180 the appropriate registry: 2182 o contact name 2184 o contact email address 2186 o name being registered (as it will appear in SDP) 2188 o type of name ("media", "proto", "fmt", "bwtype", "nettype", or 2189 "addrtype") 2191 o a one-paragraph explanation of the purpose of the registered name 2193 o a reference to the specification for the registered name (this 2194 will typically be an RFC number) 2196 In the case of a new addrtype registration, the author has to check 2197 whether the new address type is usable with the existing network 2198 types. If yes, the "nettype" registry MUST be updated accordingly. 2199 In the case of a new nettype registration, the author MUST specify 2200 the usable address type(s). 2202 IANA may refer any registration to the IESG for review, and may 2203 request revisions to be made before a registration will be made. 2205 8.3. Encryption Key Access Methods 2207 The IANA previously maintained a table of SDP encryption key access 2208 method ("enckey") names. This table is obsolete, since the "k=" line 2209 is not extensible. New registrations MUST NOT be accepted. 2211 8.4. Reorganization of the nettype Registry 2213 This document adds a new column in the "nettype" registry with the 2214 title "Usable addrtype Values" and updates the "nettype" registry as 2215 follows: 2217 -------------------------------------------------------------------- 2218 |Type | SDP Name | Usable addrtype Values | Reference | 2219 -------------------------------------------------------------------- 2220 |nettype | IN | IP4, IP6 | [RFCXXXX] | 2221 |nettype | TN | RFC2543 | [RFC2848] | 2222 |nettype | ATM | NSAP, GWID, E164 | [RFC3108] | 2223 |nettype | PSTN | E164 | [RFC7195] | 2224 -------------------------------------------------------------------- 2226 Note that both [RFC7195] and [RFC3108] registered "E164" as an 2227 address type, although [RFC7195] mentions that the "E164" address 2228 type has a different context for ATM and PSTN networks. 2230 8.5. Reorganization of the att-field Registries 2232 This document combines all of the (currently) five "att-field" 2233 registries into one registry called "att-field" registry, and updates 2234 the columns to reflect the name, usage level(s), charset dependency 2235 and reference. As such IANA is requested to create a new combined 2236 registry using the following columns: 2238 Name | Usage Level | Dependent on Charset? | Mux Category | Reference 2240 The "Name" column reflects the attribute name (as it will appear in 2241 the SDP). The "Usage Level" column MUST indicate one or more of the 2242 following: session, media, source, dcsa and dcsa(subprotocol). The 2243 "Dependent on Charset?" column MUST indicate "Yes" or "No" depending 2244 on whether the attribute value is subject to the charset attribute. 2245 The "Mux Category" column MUST indicate one of the following 2246 categories: NORMAL, NOT RECOMMENDED, IDENTICAL, SUM, TRANSPORT, 2247 INHERIT, IDENTICAL-PER-PT, SPECIAL or TBD as defined by 2248 [I-D.ietf-mmusic-sdp-mux-attributes]. Finally, the "Reference" 2249 column indicates the specification(s) where the attribute is defined. 2251 For example, the attribute "setup" which is defined for both session 2252 and media level, will be listed in the new registry as follows: 2254 Name | Usage Level | Dependent on Charset?|Mux Category| Reference | 2255 ------|----------------|----------------------|------------|-----------| 2256 setup | session,media, | No |IDENTICAL | [RFC4145] | 2257 | dcsa,dcsa(msrp)| | | [RFC6135] | 2258 | | | | [I-D.mmusic 2259 | | | |-msrp-usage- 2260 | | | |data-channel 2261 | | | |] | 2263 9. SDP Grammar 2265 This section provides an Augmented BNF grammar for SDP. ABNF is 2266 defined in [RFC5234] and [RFC7405]. 2268 ; SDP Syntax 2269 session-description = version-field 2270 origin-field 2271 session-name-field 2272 [information-field] 2273 [uri-field] 2274 *email-field 2275 *phone-field 2276 [connection-field] 2277 *bandwidth-field 2278 1*time-description 2279 [key-field] 2280 *attribute-field 2281 *media-description 2283 version-field = %s"v" "=" 1*DIGIT CRLF 2284 ;this memo describes version 0 2286 origin-field = %s"o" "=" username SP sess-id SP sess-version SP 2287 nettype SP addrtype SP unicast-address CRLF 2289 session-name-field = %s"s" "=" text CRLF 2291 information-field = %s"i" "=" text CRLF 2293 uri-field = %s"u" "=" uri CRLF 2295 email-field = %s"e" "=" email-address CRLF 2297 phone-field = %s"p" "=" phone-number CRLF 2299 connection-field = %s"c" "=" nettype SP addrtype SP 2300 connection-address CRLF 2301 ;a connection field must be present 2302 ;in every media description or at the 2303 ;session level 2305 bandwidth-field = %s"b" "=" bwtype ":" bandwidth CRLF 2307 time-description = time-field 2308 [repeat-description] 2310 repeat-description = 1*repeat-field 2312 [zone-field] 2314 time-field = %s"t" "=" start-time SP stop-time CRLF 2316 repeat-field = %s"r" "=" repeat-interval SP typed-time 2317 1*(SP typed-time) CRLF 2319 zone-field = %s"z" "=" time SP ["-"] typed-time 2320 *(SP time SP ["-"] typed-time) CRLF 2322 key-field = %s"k" "=" key-type CRLF 2324 attribute-field = %s"a" "=" attribute CRLF 2326 media-description = media-field 2327 [information-field] 2328 *connection-field 2329 *bandwidth-field 2330 [key-field] 2331 *attribute-field 2333 media-field = %s"m" "=" media SP port ["/" integer] 2334 SP proto 1*(SP fmt) CRLF 2336 ; sub-rules of 'o=' 2337 username = non-ws-string 2338 ;pretty wide definition, but doesn't 2339 ;include space 2341 sess-id = 1*DIGIT 2342 ;should be unique for this username/host 2344 sess-version = 1*DIGIT 2346 nettype = token 2347 ;typically "IN" 2349 addrtype = token 2350 ;typically "IP4" or "IP6" 2352 ; sub-rules of 'u=' 2353 uri = URI-reference 2354 ; see RFC 3986 2356 ; sub-rules of 'e=', see RFC 5322 for definitions 2357 email-address = address-and-comment / dispname-and-address 2358 / addr-spec 2359 address-and-comment = addr-spec 1*SP "(" 1*email-safe ")" 2360 dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">" 2362 ; sub-rules of 'p=' 2363 phone-number = phone *SP "(" 1*email-safe ")" / 2364 1*email-safe "<" phone ">" / 2365 phone 2367 phone = ["+"] DIGIT 1*(SP / "-" / DIGIT) 2369 ; sub-rules of 'c=' 2370 connection-address = multicast-address / unicast-address 2372 ; sub-rules of 'b=' 2373 bwtype = token 2375 bandwidth = 1*DIGIT 2377 ; sub-rules of 't=' 2378 start-time = time / "0" 2380 stop-time = time / "0" 2382 time = POS-DIGIT 9*DIGIT 2383 ; Decimal representation of NTP time in 2384 ; seconds since 1900. The representation 2385 ; of NTP time is an unbounded length field 2386 ; containing at least 10 digits. Unlike the 2387 ; 64-bit representation used elsewhere, time 2388 ; in SDP does not wrap in the year 2036. 2390 ; sub-rules of 'r=' and 'z=' 2391 repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] 2393 typed-time = 1*DIGIT [fixed-len-time-unit] 2395 fixed-len-time-unit = %s"d" / %s"h" / %s"m" / %s"s" 2396 ; NOTE: These units are case-sensitive. 2398 ; sub-rules of 'k=' 2399 key-type = %s"prompt" / 2400 %s"clear:" text / 2401 %s"base64:" base64 / 2402 %s"uri:" uri 2403 ; NOTE: These names are case-sensitive. 2405 base64 = *base64-unit [base64-pad] 2406 base64-unit = 4base64-char 2407 base64-pad = 2base64-char "==" / 3base64-char "=" 2408 base64-char = ALPHA / DIGIT / "+" / "/" 2410 ; sub-rules of 'a=' 2411 attribute = (att-field ":" att-value) / att-field 2413 att-field = token 2415 att-value = byte-string 2417 ; sub-rules of 'm=' 2418 media = token 2419 ;typically "audio", "video", "text", "image" 2420 ;or "application" 2422 fmt = token 2423 ;typically an RTP payload type for audio 2424 ;and video media 2426 proto = token *("/" token) 2427 ;typically "RTP/AVP" or "udp" 2429 port = 1*DIGIT 2431 ; generic sub-rules: addressing 2432 unicast-address = IP4-address / IP6-address / FQDN / extn-addr 2434 multicast-address = IP4-multicast / IP6-multicast / FQDN 2435 / extn-addr 2437 IP4-multicast = m1 3( "." decimal-uchar ) 2438 "/" ttl [ "/" numaddr ] 2439 ; IP4 multicast addresses may be in the 2440 ; range 224.0.0.0 to 239.255.255.255 2442 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / 2443 ("23" DIGIT ) 2445 IP6-multicast = IP6-address [ "/" numaddr ] 2446 ; IP6 address starting with FF 2448 numaddr = integer 2450 ttl = (POS-DIGIT *2DIGIT) / "0" 2452 FQDN = 4*(alpha-numeric / "-" / ".") 2453 ; fully qualified domain name as specified 2454 ; in RFC 1035 (and updates) 2456 IP4-address = b1 3("." decimal-uchar) 2458 b1 = decimal-uchar 2459 ; less than "224" 2461 IP6-address = 6( h16 ":" ) ls32 2462 / "::" 5( h16 ":" ) ls32 2463 / [ h16 ] "::" 4( h16 ":" ) ls32 2464 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 2465 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 2466 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 2467 / [ *4( h16 ":" ) h16 ] "::" ls32 2468 / [ *5( h16 ":" ) h16 ] "::" h16 2469 / [ *6( h16 ":" ) h16 ] "::" 2471 h16 = 1*4HEXDIG 2473 ls32 = ( h16 ":" h16 ) / IP4-address 2475 ; Generic for other address families 2476 extn-addr = non-ws-string 2478 ; generic sub-rules: datatypes 2479 text = byte-string 2480 ;default is to interpret this as UTF8 text. 2481 ;ISO 8859-1 requires "a=charset:ISO-8859-1" 2482 ;session-level attribute to be used 2484 byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) 2485 ;any byte except NUL, CR, or LF 2487 non-ws-string = 1*(VCHAR/%x80-FF) 2488 ;string of visible characters 2490 token-char = ALPHA / DIGIT 2491 / "!" / "#" / "$" / "%" / "&" 2492 / "'" ; (single quote) 2493 / "*" / "+" / "-" / "." / "^" / "_" 2494 / "`" ; (Grave accent) 2495 / "{" / "|" / "}" / "~" 2497 token = 1*(token-char) 2499 email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF 2500 ;any byte except NUL, CR, LF, or the quoting 2501 ;characters ()<> 2503 integer = POS-DIGIT *DIGIT 2504 zero-based-integer = "0" / integer 2506 non-zero-int-or-real = integer / non-zero-real 2508 non-zero-real = zero-based-integer "." *DIGIT POS-DIGIT 2510 ; generic sub-rules: primitives 2511 alpha-numeric = ALPHA / DIGIT 2513 POS-DIGIT = %x31-39 ; 1 - 9 2515 decimal-uchar = DIGIT 2516 / POS-DIGIT DIGIT 2517 / ("1" 2*(DIGIT)) 2518 / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) 2519 / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) 2521 ; external references: 2522 ALPHA = 2523 DIGIT = 2524 CRLF = 2525 HEXDIG = 2526 SP = 2527 VCHAR = 2528 URI-reference = 2529 addr-spec = 2531 10. Summary of Changes from RFC 4566 2533 o Generally clarified and refined terminology. 2535 o Identified now-obsolete items: "a=cat", "a=keywds", "k=". 2537 o Updated normative and informative references, and added references 2538 to additional relevant related RFCs. 2540 o Reformatted the SDP Attributes section for readability. The 2541 syntax of attribute values is now given in ABNF. 2543 o Made mandatory the sending of RTCP with inactive media streams. 2545 o Removed the section "Private Sessions". That section dates back 2546 to a time when the primary use of SDP was with SAP (Session 2547 Announcement Protocol). That has fallen out of use. Now the vast 2548 majority of uses of SDP is for establishment of private sessions. 2549 The considerations for that are covered in Section 7. 2551 o Expanded and clarified the specification of the "lang" and 2552 "sdplang" attributes. 2554 o Removed some references to SAP because it is no longer in 2555 widespread use. 2557 o Changed the way values for UDP transport are registered. 2559 o Changed the mechanism and documentation required for registering 2560 new attributes. 2562 o Tightened up IANA registration procedures for extensions. Removed 2563 phone number and long-form name. 2565 o Reorganized the IANA nettype registry 2567 o Reorganized the several IANA att-type registries into a single 2568 registry 2570 o Revised ABNF syntax for clarity. Backward compatibility is 2571 maintained with a few exceptions: 2573 * Revised the syntax of time descriptions ("t=", "r=", "z=") to 2574 remove ambiguities. Clarified that "z=" only modifies the 2575 immediately preceding "r=" lines. Made "z=" without a 2576 preceding "r=" a syntax error. (This is incompatible with 2577 certain aberrant usage.) 2579 * Updated the "IP6-address" and "IP6-multicast" rules, consistent 2580 with the syntax in RFC3986. (This mirrors a bug fix made to 2581 RFC3261 by RFC5964.) Removed rules that were unused as a 2582 result of this change. 2584 o Revised IPv4 unicast and multicast addresses in the example SDP 2585 descriptions per RFCs 5735 and 5771. 2587 o Incorporated case-insensitivity rules from RFC 4855. 2589 11. Acknowledgements 2591 Many people in the IETF Multiparty Multimedia Session Control 2592 (MMUSIC) working group have made comments and suggestions 2593 contributing to this document. 2595 In particular, we would like to thank the following people who 2596 contributed to the creation of this document or one of its 2597 predecessor documents: Adam Roach, Allison Mankin, Bernie Hoeneisen, 2598 Bill Fenner, Carsten Bormann, Eve Schooler, Flemming Andreasen, 2599 Gonzalo Camarillo, Joerg Ott, John Elwell, Jon Peterson, Jonathan 2600 Lennox, Jonathan Rosenberg, Keith Drage, Peter Parnes, Rob Lanphier, 2601 Ross Finlayson, Sean Olson, Spencer Dawkins, Steve Casner, Steve 2602 Hanna, Van Jacobson. 2604 12. References 2606 12.1. Normative References 2608 [E164] International Telecommunication Union, "E.164 : The 2609 international public telecommunication numbering plan", 2610 ITU Recommendation E.164, November 2010. 2612 [I-D.ietf-mmusic-data-channel-sdpneg] 2613 Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. 2614 Even, "SDP-based Data Channel Negotiation", draft-ietf- 2615 mmusic-data-channel-sdpneg-27 (work in progress), April 2616 2019. 2618 [I-D.ietf-mmusic-sdp-mux-attributes] 2619 Nandakumar, S., "A Framework for SDP Attributes when 2620 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 2621 (work in progress), February 2018. 2623 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2624 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 2625 . 2627 [RFC1035] Mockapetris, P., "Domain names - implementation and 2628 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2629 November 1987, . 2631 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2632 Requirement Levels", BCP 14, RFC 2119, 2633 DOI 10.17487/RFC2119, March 1997, 2634 . 2636 [RFC2848] Petrack, S. and L. Conroy, "The PINT Service Protocol: 2637 Extensions to SIP and SDP for IP Access to Telephone Call 2638 Services", RFC 2848, DOI 10.17487/RFC2848, June 2000, 2639 . 2641 [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration 2642 Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978, 2643 October 2000, . 2645 [RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the 2646 Session Description Protocol (SDP) for ATM Bearer 2647 Connections", RFC 3108, DOI 10.17487/RFC3108, May 2001, 2648 . 2650 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2651 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2652 2003, . 2654 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2655 Resource Identifier (URI): Generic Syntax", STD 66, 2656 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2657 . 2659 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 2660 the Session Description Protocol (SDP)", RFC 4145, 2661 DOI 10.17487/RFC4145, September 2005, 2662 . 2664 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2665 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2666 July 2006, . 2668 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2669 Specifications: ABNF", STD 68, RFC 5234, 2670 DOI 10.17487/RFC5234, January 2008, 2671 . 2673 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2674 Media Attributes in the Session Description Protocol 2675 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 2676 . 2678 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 2679 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 2680 September 2009, . 2682 [RFC5890] Klensin, J., "Internationalized Domain Names for 2683 Applications (IDNA): Definitions and Document Framework", 2684 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2685 . 2687 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 2688 for the Message Session Relay Protocol (MSRP)", RFC 6135, 2689 DOI 10.17487/RFC6135, February 2011, 2690 . 2692 [RFC7195] Garcia-Martin, M. and S. Veikkolainen, "Session 2693 Description Protocol (SDP) Extension for Setting Audio and 2694 Video Media Streams over Circuit-Switched Bearers in the 2695 Public Switched Telephone Network (PSTN)", RFC 7195, 2696 DOI 10.17487/RFC7195, May 2014, 2697 . 2699 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2700 Writing an IANA Considerations Section in RFCs", BCP 26, 2701 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2702 . 2704 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2705 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2706 May 2017, . 2708 12.2. Informative References 2710 [I-D.ietf-mmusic-ice-sip-sdp] 2711 Petit-Huguenin, M., Nandakumar, S., and A. Keranen, 2712 "Session Description Protocol (SDP) Offer/Answer 2713 procedures for Interactive Connectivity Establishment 2714 (ICE)", draft-ietf-mmusic-ice-sip-sdp-24 (work in 2715 progress), November 2018. 2717 [I-D.ietf-mmusic-sdp-bundle-negotiation] 2718 Holmberg, C., Alvestrand, H., and C. Jennings, 2719 "Negotiating Media Multiplexing Using the Session 2720 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 2721 negotiation-54 (work in progress), December 2018. 2723 [ITU.H332.1998] 2724 International Telecommunication Union, "H.323 extended for 2725 loosely coupled conferences", ITU Recommendation H.332, 2726 September 1998. 2728 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 2729 Protocol", RFC 2327, DOI 10.17487/RFC2327, April 1998, 2730 . 2732 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 2733 Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, 2734 October 2000, . 2736 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2737 A., Peterson, J., Sparks, R., Handley, M., and E. 2738 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2739 DOI 10.17487/RFC3261, June 2002, 2740 . 2742 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2743 with Session Description Protocol (SDP)", RFC 3264, 2744 DOI 10.17487/RFC3264, June 2002, 2745 . 2747 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2748 Jacobson, "RTP: A Transport Protocol for Real-Time 2749 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2750 July 2003, . 2752 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 2753 Video Conferences with Minimal Control", STD 65, RFC 3551, 2754 DOI 10.17487/RFC3551, July 2003, 2755 . 2757 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 2758 Modifiers for RTP Control Protocol (RTCP) Bandwidth", 2759 RFC 3556, DOI 10.17487/RFC3556, July 2003, 2760 . 2762 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2763 in Session Description Protocol (SDP)", RFC 3605, 2764 DOI 10.17487/RFC3605, October 2003, 2765 . 2767 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2768 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2769 RFC 3711, DOI 10.17487/RFC3711, March 2004, 2770 . 2772 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 2773 "Indicating User Agent Capabilities in the Session 2774 Initiation Protocol (SIP)", RFC 3840, 2775 DOI 10.17487/RFC3840, August 2004, 2776 . 2778 [RFC3890] Westerlund, M., "A Transport Independent Bandwidth 2779 Modifier for the Session Description Protocol (SDP)", 2780 RFC 3890, DOI 10.17487/RFC3890, September 2004, 2781 . 2783 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 2784 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 2785 . 2787 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 2788 DOI 10.17487/RFC5322, October 2008, 2789 . 2791 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2792 Protocol (SDP) Grouping Framework", RFC 5888, 2793 DOI 10.17487/RFC5888, June 2010, 2794 . 2796 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 2797 "Network Time Protocol Version 4: Protocol and Algorithms 2798 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 2799 . 2801 [RFC6466] Salgueiro, G., "IANA Registration of the 'image' Media 2802 Type for the Session Description Protocol (SDP)", 2803 RFC 6466, DOI 10.17487/RFC6466, December 2011, 2804 . 2806 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 2807 "TCP Candidates with Interactive Connectivity 2808 Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, 2809 March 2012, . 2811 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2812 Specifications and Registration Procedures", BCP 13, 2813 RFC 6838, DOI 10.17487/RFC6838, January 2013, 2814 . 2816 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2817 Protocol (HTTP/1.1): Message Syntax and Routing", 2818 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2819 . 2821 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 2822 RFC 7405, DOI 10.17487/RFC7405, December 2014, 2823 . 2825 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 2826 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 2827 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 2828 DOI 10.17487/RFC7656, November 2015, 2829 . 2831 [RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 2832 and M. Stiemerling, Ed., "Real-Time Streaming Protocol 2833 Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December 2834 2016, . 2836 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 2837 Connectivity Establishment (ICE): A Protocol for Network 2838 Address Translator (NAT) Traversal", RFC 8445, 2839 DOI 10.17487/RFC8445, July 2018, 2840 . 2842 Authors' Addresses 2844 Ali Begen 2845 Networked Media 2846 Konya 2847 Turkey 2849 EMail: ali.begen@networked.media 2851 Paul Kyzivat 2852 USA 2854 EMail: pkyzivat@alum.mit.edu 2856 Colin Perkins 2857 University of Glasgow 2858 School of Computing Science 2859 University of Glasgow 2860 Glasgow G12 8QQ 2861 UK 2863 EMail: csp@csperkins.org 2865 Mark Handley 2866 University College London 2867 Department of Computer Science 2868 London WC1E 6BT 2869 UK 2871 EMail: M.Handley@cs.ucl.ac.uk