idnits 2.17.00 (12 Aug 2021) /tmp/idnits20026/draft-ietf-mmusic-rfc4566bis-37.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 (August 9, 2019) is 1009 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 2264, but not defined == Unused Reference: 'RFC2978' is defined on line 2688, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'E164' == Outdated reference: draft-ietf-mmusic-data-channel-sdpneg has been published as RFC 8864 == Outdated reference: draft-ietf-mmusic-sdp-mux-attributes has been published as RFC 8859 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: draft-ietf-mmusic-ice-sip-sdp has been published as RFC 8839 == Outdated reference: draft-ietf-mmusic-sdp-bundle-negotiation has been published as RFC 8843 -- Obsolete informational reference (is this intentional?): RFC 2327 (Obsoleted by RFC 4566) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 5 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: February 10, 2020 C. Perkins 7 University of Glasgow 8 M. Handley 9 UCL 10 August 9, 2019 12 SDP: Session Description Protocol 13 draft-ietf-mmusic-rfc4566bis-37 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 February 10, 2020. 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. Internationalization . . . . . . . . . . . . . . . . . . 8 80 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . . 8 81 5.1. Protocol Version ("v=") . . . . . . . . . . . . . . . . . 12 82 5.2. Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 12 83 5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 13 84 5.4. Session Information ("i=") . . . . . . . . . . . . . . . 13 85 5.5. URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . 14 86 5.6. Email Address and Phone Number ("e=" and "p=") . . . . . 14 87 5.7. Connection Information ("c=") . . . . . . . . . . . . . . 15 88 5.8. Bandwidth Information ("b=") . . . . . . . . . . . . . . 17 89 5.9. Time Active ("t=") . . . . . . . . . . . . . . . . . . . 18 90 5.10. Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . 19 91 5.11. Time Zone Adjustment ("z=") . . . . . . . . . . . . . . . 20 92 5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 21 93 5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 21 94 5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 22 95 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 25 96 6.1. cat (category) . . . . . . . . . . . . . . . . . . . . . 26 97 6.2. keywds (keywords) . . . . . . . . . . . . . . . . . . . . 26 98 6.3. tool . . . . . . . . . . . . . . . . . . . . . . . . . . 27 99 6.4. ptime (packet time) . . . . . . . . . . . . . . . . . . . 27 100 6.5. maxptime (maximum packet time) . . . . . . . . . . . . . 28 101 6.6. rtpmap . . . . . . . . . . . . . . . . . . . . . . . . . 28 102 6.7. Media Direction Attributes . . . . . . . . . . . . . . . 30 103 6.7.1. recvonly (receive-only) . . . . . . . . . . . . . . . 31 104 6.7.2. sendrecv (send-receive) . . . . . . . . . . . . . . . 31 105 6.7.3. sendonly (send-only) . . . . . . . . . . . . . . . . 32 106 6.7.4. inactive . . . . . . . . . . . . . . . . . . . . . . 32 107 6.8. orient (orientation) . . . . . . . . . . . . . . . . . . 33 108 6.9. type (conference type) . . . . . . . . . . . . . . . . . 33 109 6.10. charset (character set) . . . . . . . . . . . . . . . . . 34 110 6.11. sdplang (SDP language) . . . . . . . . . . . . . . . . . 35 111 6.12. lang (language) . . . . . . . . . . . . . . . . . . . . . 36 112 6.13. framerate (frame rate) . . . . . . . . . . . . . . . . . 37 113 6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 37 114 6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 38 115 7. Security Considerations . . . . . . . . . . . . . . . . . . . 39 116 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 117 8.1. The "application/sdp" Media Type . . . . . . . . . . . . 40 118 8.2. Registration of SDP Parameters with IANA . . . . . . . . 42 119 8.2.1. Registration Procedure . . . . . . . . . . . . . . . 42 120 8.2.2. Media Types ("media") . . . . . . . . . . . . . . . . 43 121 8.2.3. Transport Protocols ("proto") . . . . . . . . . . . . 43 122 8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 44 123 8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 48 124 8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 48 125 8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 49 126 8.3. Encryption Key Access Methods (OBSOLETE) . . . . . . . . 50 127 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 50 128 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 55 129 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57 130 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 131 12.1. Normative References . . . . . . . . . . . . . . . . . . 57 132 12.2. Informative References . . . . . . . . . . . . . . . . . 60 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62 135 1. Introduction 137 When initiating multimedia teleconferences, voice-over-IP calls, 138 streaming video, or other sessions, there is a requirement to convey 139 media details, transport addresses, and other session description 140 metadata to the participants. 142 SDP provides a standard representation for such information, 143 irrespective of how that information is transported. SDP is purely a 144 format for session description -- it does not incorporate a transport 145 protocol, and it is intended to use different transport protocols as 146 appropriate, including the Session Announcement Protocol (SAP) 147 [RFC2974], Session Initiation Protocol (SIP) [RFC3261], Real Time 148 Streaming Protocol (RTSP) [RFC7826], electronic mail [RFC5322] using 149 the MIME extensions [RFC2045], and the Hypertext Transport Protocol 150 (HTTP) [RFC7230]. 152 SDP is intended to be general purpose so that it can be used in a 153 wide range of network environments and applications. However, it is 154 not intended to support negotiation of session content or media 155 encodings: this is viewed as outside the scope of session 156 description. 158 This memo obsoletes [RFC4566]. The changes relative to [RFC4566] are 159 outlined in Section 10 of this memo. 161 2. Glossary of Terms 163 The following terms are used in this document and have specific 164 meaning within the context of this document. 166 Session Description: A well-defined format for conveying sufficient 167 information to discover and participate in a multimedia session. 169 Media Description: A Media Description contains the information 170 needed for one party to establish an application layer network 171 protocol connection to another party. It starts with an "m=" line 172 and is terminated by either the next "m=" line or by the end of 173 the session description. 175 Session-level Section: This refers to the parts that are not media 176 descriptions, whereas the session description refers to the whole 177 body that includes the session-level section and the media 178 description(s). 180 The terms "multimedia conference" and "multimedia session" are used 181 in this document as defined in [RFC7656]. The terms "session" and 182 "multimedia session" are used interchangeably in this document. 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 186 "OPTIONAL" in this document are to be interpreted as described in BCP 187 14 [RFC2119] [RFC8174] when, and only when, they appear in all 188 capitals, as shown here. 190 3. Examples of SDP Usage 192 3.1. Session Initiation 194 The Session Initiation Protocol (SIP) [RFC3261] is an application- 195 layer control protocol for creating, modifying, and terminating 196 sessions such as Internet multimedia conferences, Internet telephone 197 calls, and multimedia distribution. The SIP messages used to create 198 sessions carry session descriptions that allow participants to agree 199 on a set of compatible media types [RFC6838]. These session 200 descriptions are commonly formatted using SDP. When used with SIP, 201 the offer/answer model [RFC3264] provides a limited framework for 202 negotiation using SDP. 204 3.2. Streaming Media 206 The Real Time Streaming Protocol (RTSP) [RFC7826], is an application- 207 level protocol for control over the delivery of data with real-time 208 properties. RTSP provides an extensible framework to enable 209 controlled, on-demand delivery of real-time data, such as audio and 210 video. An RTSP client and server negotiate an appropriate set of 211 parameters for media delivery, partially using SDP syntax to describe 212 those parameters. 214 3.3. Email and the World Wide Web 216 Alternative means of conveying session descriptions include 217 electronic mail and the World Wide Web (WWW). For both email and WWW 218 distribution, the media type "application/sdp" is used. This enables 219 the automatic launching of applications for participation in the 220 session from the WWW client or mail reader in a standard manner. 222 Note that descriptions of multicast sessions sent only via email or 223 the WWW do not have the property that the receiver of a session 224 description can necessarily receive the session because the multicast 225 sessions may be restricted in scope, and access to the WWW server or 226 reception of email is possible outside this scope. 228 3.4. Multicast Session Announcement 230 In order to assist the advertisement of multicast multimedia 231 conferences and other multicast sessions, and to communicate the 232 relevant session setup information to prospective participants, a 233 distributed session directory may be used. An instance of such a 234 session directory periodically sends packets containing a description 235 of the session to a well-known multicast group. These advertisements 236 are received by other session directories such that potential remote 237 participants can use the session description to start the tools 238 required to participate in the session. 240 One protocol used to implement such a distributed directory is the 241 SAP [RFC2974]. SDP provides the recommended session description 242 format for such session announcements. 244 4. Requirements and Recommendations 246 The purpose of SDP is to convey information about media streams in 247 multimedia sessions to allow the recipients of a session description 248 to participate in the session. SDP is primarily intended for use 249 with Internet protocols, although it is sufficiently general that it 250 can describe multimedia conferences in other network environments. 251 Media streams can be many-to-many. Sessions need not be continually 252 active. 254 Thus far, multicast-based sessions on the Internet have differed from 255 many other forms of conferencing in that anyone receiving the traffic 256 can join the session (unless the session traffic is encrypted). In 257 such an environment, SDP serves two primary purposes. It is a means 258 to communicate the existence of a session, and it is a means to 259 convey sufficient information to enable joining and participating in 260 the session. In a unicast environment, only the latter purpose is 261 likely to be relevant. 263 An SDP description includes the following: 265 o Session name and purpose 267 o Time(s) the session is active 269 o The media comprising the session 271 o Information needed to receive those media (addresses, ports, 272 formats, etc.) 274 As resources necessary to participate in a session may be limited, 275 some additional information may also be desirable: 277 o Information about the bandwidth to be used by the session 279 o Contact information for the person responsible for the session 281 In general, SDP must convey sufficient information to enable 282 applications to join a session (with the possible exception of 283 encryption keys) and to announce the resources to be used to any non- 284 participants that may need to know. (This latter feature is 285 primarily useful when SDP is used with a multicast session 286 announcement protocol.) 288 4.1. Media and Transport Information 290 An SDP description includes the following media information: 292 o The type of media (video, audio, etc.) 294 o The media transport protocol (RTP/UDP/IP, H.320, etc.) 296 o The format of the media (H.261 video, MPEG video, etc.) 298 In addition to media format and transport protocol, SDP conveys 299 address and port details. For an IP multicast session, these 300 comprise: 302 o The multicast group address for media 304 o The transport port for media 306 This address and port are the destination address and destination 307 port of the multicast stream, whether being sent, received, or both. 309 For unicast IP sessions, the following are conveyed: 311 o The remote address for media 313 o The remote transport port for media 315 The semantics of the address and port depend on context. Typically, 316 this SHOULD be the remote address and remote port to which media is 317 to be sent or received. Details may differ based on the network 318 type, address type, protocol and media specified, and whether the SDP 319 is being distributed as an advertisement or negotiated in an offer/ 320 answer [RFC3264] exchange. (E.g., Some address types or protocols 321 may not have a notion of port.) Deviating from typical behavior 322 should be done cautiously since this complicates implementations 323 (including middleboxes that must parse the addresses to open Network 324 Address Translation (NAT) or firewall pinholes). 326 4.2. Timing Information 328 Sessions may be either bounded or unbounded in time. Whether or not 329 they are bounded, they may be only active at specific times. SDP can 330 convey: 332 o An arbitrary list of start and stop times bounding the session 333 o For each bound, repeat times such as "every Wednesday at 10am for 334 one hour" 336 This timing information is globally consistent, irrespective of local 337 time zone or daylight saving time (see Section 5.9). 339 4.3. Obtaining Further Information about a Session 341 A session description could convey enough information to decide 342 whether or not to participate in a session. SDP may include 343 additional pointers in the form of Uniform Resource Identifiers 344 (URIs) [RFC3986] for more information about the session. (Note that 345 use of URIs to indicate remote resources is subject to the security 346 considerations from [RFC3986].) 348 4.4. Internationalization 350 The SDP specification recommends the use of the ISO 10646 character 351 set in the UTF-8 encoding [RFC3629] to allow many different languages 352 to be represented. However, to assist in compact representations, 353 SDP also allows other character sets such as [ISO.8859-1.1998] to be 354 used when desired. Internationalization only applies to free-text 355 sub-fields (session name and background information), and not to SDP 356 as a whole. 358 5. SDP Specification 360 An SDP description is denoted by the media type "application/sdp" 361 (See Section 8). 363 An SDP description is entirely textual. SDP field names and 364 attribute names use only the US-ASCII subset of UTF-8 [RFC3629], but 365 textual fields and attribute values MAY use the full ISO 10646 366 character set in UTF-8 encoding, or some other character set defined 367 by the "a=charset:" attribute. Field and attribute values that use 368 the full UTF-8 character set are never directly compared, hence there 369 is no requirement for UTF-8 normalization. The textual form, as 370 opposed to a binary encoding such as ASN.1 or XDR, was chosen to 371 enhance portability, to enable a variety of transports to be used, 372 and to allow flexible, text-based toolkits to be used to generate and 373 process session descriptions. However, since SDP may be used in 374 environments where the maximum permissible size of a session 375 description is limited, the encoding is deliberately compact. Also, 376 since descriptions may be transported via very unreliable means or 377 damaged by an intermediate caching server, the encoding was designed 378 with strict order and formatting rules so that most errors would 379 result in malformed session descriptions that could be detected 380 easily and discarded. 382 An SDP description consists of a number of lines of text of the form: 384 = 386 where is exactly one case-significant character and is 387 structured text whose format depends on . In general, 388 is either a number of sub-fields delimited by a single space 389 character or a free format string, and is case-significant unless a 390 specific field defines otherwise. Whitespace separators are not used 391 on either side of the "=" sign, however, the value can contain a 392 leading whitespace as part of its syntax, i.e., that whitespace is 393 part of the value. 395 An SDP description MUST conform to the syntax defined in Section 9. 396 The following is an overview of the syntax: 398 An SDP description consists of a session-level section followed by 399 zero or more media descriptions. The session-level section starts 400 with a "v=" line and continues to the first media description (or the 401 end of the whole description, whichever comes first). Each media 402 description starts with an "m=" line and continues to the next media 403 description or the end of the whole session description, whichever 404 comes first. In general, session-level values are the default for 405 all media unless overridden by an equivalent media-level value. 407 Some lines in each description are required and some are optional, 408 but when present must appear in exactly the order given here. (The 409 fixed order greatly enhances error detection and allows for a simple 410 parser). In the following overview optional items are marked with a 411 "*". 413 Session description 414 v= (protocol version) 415 o= (originator and session identifier) 416 s= (session name) 417 i=* (session information) 418 u=* (URI of description) 419 e=* (email address) 420 p=* (phone number) 421 c=* (connection information -- not required if included in 422 all media descriptions) 423 b=* (zero or more bandwidth information lines) 424 One or more time descriptions: 425 ("t=", "r=" and "z=" lines; see below) 426 k=* (obsolete) 427 a=* (zero or more session attribute lines) 428 Zero or more media descriptions 430 Time description 431 t= (time the session is active) 432 r=* (zero or more repeat times) 433 z=* (optional time zone offset line) 435 Media description, if present 436 m= (media name and transport address) 437 i=* (media title) 438 c=* (connection information -- optional if included at 439 session level) 440 b=* (zero or more bandwidth information lines) 441 k=* (obsolete) 442 a=* (zero or more media attribute lines) 444 The set of type letters is deliberately small and not intended to be 445 extensible -- an SDP parser MUST completely ignore or reject any 446 session description that contains a type letter that it does not 447 understand. The attribute mechanism ("a=" described below) is the 448 primary means for extending SDP and tailoring it to particular 449 applications or media. Some attributes (the ones listed in Section 6 450 of this memo) have a defined meaning, but others may be added on a 451 media- or session-specific basis. (Attribute scopes in addition to 452 media-specific and session-specific may also be defined in extensions 453 to this document. E.g., [RFC5576], 454 [I-D.ietf-mmusic-data-channel-sdpneg].) An SDP parser MUST ignore 455 any attribute it doesn't understand. 457 An SDP description may contain URIs that reference external content 458 in the "u=", "k=", and "a=" lines. These URIs may be dereferenced in 459 some cases, making the session description non-self-contained. 461 The connection ("c=") information in the session-level section 462 applies to all the media descriptions of that session unless 463 overridden by connection information in the media description. For 464 instance, in the example below, each audio media description behaves 465 as if it were given a "c=IN IP4 198.51.100.1". 467 An example SDP description is: 469 v=0 470 o=jdoe 3724394400 3724394405 IN IP4 198.51.100.1 471 s=Call to John Smith 472 i=SDP Offer #1 473 u=http://www.jdoe.example.com/home.html 474 e=Jane Doe 475 p=+1 617 555-6011 476 c=IN IP4 198.51.100.1 477 t=0 0 478 m=audio 49170 RTP/AVP 0 479 m=audio 49180 RTP/AVP 0 480 m=video 51372 RTP/AVP 99 481 c=IN IP6 2001:db8::2 482 a=rtpmap:99 h263-1998/90000 484 Text-containing fields such as the session-name-field and 485 information-field are octet strings that may contain any octet with 486 the exceptions of 0x00 (Nul), 0x0a (ASCII newline), and 0x0d (ASCII 487 carriage return). The sequence CRLF (0x0d0a) is used to end a line, 488 although parsers SHOULD be tolerant and also accept lines terminated 489 with a single newline character. If the "a=charset" attribute is not 490 present, these octet strings MUST be interpreted as containing 491 ISO-10646 characters in UTF-8 encoding. When the "a=charset" 492 attribute is present the session-name-field, information-field, and 493 some attribute fields are interpreted according to the selected 494 character set. 496 A session description can contain domain names in the "o=", "u=", 497 "e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply 498 with [RFC1034] and [RFC1035]. Internationalized domain names (IDNs) 499 MUST be represented using the ASCII Compatible Encoding (ACE) form 500 defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or 501 any other encoding (this requirement is for compatibility with 502 [RFC2327] and other early SDP-related standards, which predate the 503 development of internationalized domain names). 505 5.1. Protocol Version ("v=") 507 v=0 509 The "v=" line (version-field) gives the version of the Session 510 Description Protocol. This memo defines version 0. There is no 511 minor version number. 513 5.2. Origin ("o=") 515 o= 516 518 The "o=" line (origin-field) gives the originator of the session (her 519 username and the address of the user's host) plus a session 520 identifier and version number: 522 is the user's login on the originating host, or it is "-" 523 if the originating host does not support the concept of user IDs. 524 The MUST NOT contain spaces. 526 is a numeric string such that the tuple of , 527 , , , and forms a 528 globally unique identifier for the session. The method of allocation is up to the creating tool, but a timestamp, in 530 seconds since January 1, 1900 UTC, is recommended to ensure 531 uniqueness. 533 is a version number for this session description. 534 Its usage is up to the creating tool, so long as is 535 increased when a modification is made to the session description. 536 Again, as with it is RECOMMENDED that a timestamp be 537 used. 539 is a text string giving the type of network. Initially 540 "IN" is defined to have the meaning "Internet", but other values 541 MAY be registered in the future (see Section 8). 543 is a text string giving the type of the address that 544 follows. Initially "IP4" and "IP6" are defined, but other values 545 MAY be registered in the future (see Section 8). 547 is an address of the machine from which the 548 session was created. For an address type of IP4, this is either a 549 fully qualified domain name of the machine or the dotted-decimal 550 representation of an IP version 4 address of the machine. For an 551 address type of IP6, this is either a fully qualified domain name 552 of the machine or the address of the machine represented as 553 specified in Section 4 of [RFC5952]. For both IP4 and IP6, the 554 fully qualified domain name is the form that SHOULD be given 555 unless this is unavailable, in which case a globally unique 556 address MAY be substituted. 558 In general, the "o=" line serves as a globally unique identifier for 559 this version of the session description, and the sub-fields excepting 560 the version, taken together identify the session irrespective of any 561 modifications. 563 For privacy reasons, it is sometimes desirable to obfuscate the 564 username and IP address of the session originator. If this is a 565 concern, an arbitrary and private MAY be 566 chosen to populate the "o=" line, provided that these are selected in 567 a manner that does not affect the global uniqueness of the field. 569 5.3. Session Name ("s=") 571 s= 573 The "s=" line (session-name-field) is the textual session name. 574 There MUST be one and only one "s=" line per session description. 575 The "s=" line MUST NOT be empty. If a session has no meaningful 576 name, then "s= " or "s=-" (i.e., a single space or dash as the 577 session name) is RECOMMENDED. If a session-level "a=charset" 578 attribute is present, it specifies the character set used in the "s=" 579 field. If a session-level "a=charset" attribute is not present, the 580 "s=" field MUST contain ISO 10646 characters in UTF-8 encoding. 582 5.4. Session Information ("i=") 584 i= 586 The "i=" line (information-field) provides textual information about 587 the session. There can be at most one session-level "i=" line per 588 session description, and at most one "i=" line in each media 589 description. Unless a media-level "i=" line is provided, the 590 session-level "i=" line applies to that media description. If the 591 "a=charset" attribute is present, it specifies the character set used 592 in the "i=" line. If the "a=charset" attribute is not present, the 593 "i=" line MUST contain ISO 10646 characters in UTF-8 encoding. 595 At most one "i=" line can be used for each media description. In 596 media definitions, "i=" lines are primarily intended for labelling 597 media streams. As such, they are most likely to be useful when a 598 single session has more than one distinct media stream of the same 599 media type. An example would be two different whiteboards, one for 600 slides and one for feedback and questions. 602 The "i=" line is intended to provide a free-form human-readable 603 description of the session or the purpose of a media stream. It is 604 not suitable for parsing by automata. 606 5.5. URI ("u=") 608 u= 610 The "u=" line (uri-field) provides a URI (Uniform Resource 611 Identifier) [RFC3986]. The URI should be a pointer to additional 612 human readable information about the session. This line is OPTIONAL. 613 No more than one "u=" line is allowed per session description. 615 5.6. Email Address and Phone Number ("e=" and "p=") 617 e= 618 p= 620 The "e=" line (email-field) and "p=" line (phone-field) specify 621 contact information for the person responsible for the session. This 622 is not necessarily the same person that created the session 623 description. 625 Inclusion of an email address or phone number is OPTIONAL. 627 If an email address or phone number is present, it MUST be specified 628 before the first media description. More than one email or phone 629 line can be given for a session description. 631 Phone numbers SHOULD be given in the form of an international public 632 telecommunication number (see ITU-T Recommendation E.164 [E164]) 633 preceded by a "+". Spaces and hyphens may be used to split up a 634 phone-field to aid readability if desired. For example: 636 p=+1 617 555-6011 638 Both email addresses and phone numbers can have an OPTIONAL free text 639 string associated with them, normally giving the name of the person 640 who may be contacted. This MUST be enclosed in parentheses if it is 641 present. For example: 643 e=j.doe@example.com (Jane Doe) 645 The alternative [RFC5322] name quoting convention is also allowed for 646 both email addresses and phone numbers. For example: 648 e=Jane Doe 650 The free text string SHOULD be in the ISO-10646 character set with 651 UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if 652 the appropriate session-level "a=charset" attribute is set. 654 5.7. Connection Information ("c=") 656 c= 658 The "c=" line (connection-field) contains information necessary to 659 establish a network connection. 661 A session description MUST contain either at least one "c=" line in 662 each media description or a single "c=" line at the session level. 663 It MAY contain a single session-level "c=" line and additional media- 664 level "c=" line(s) per-media-description, in which case the media- 665 level values override the session-level settings for the respective 666 media. 668 The first sub-field ("") is the network type, which is a 669 text string giving the type of network. Initially, "IN" is defined 670 to have the meaning "Internet", but other values MAY be registered in 671 the future (see Section 8). 673 The second sub-field ("") is the address type. This allows 674 SDP to be used for sessions that are not IP based. This memo only 675 defines IP4 and IP6, but other values MAY be registered in the future 676 (see Section 8). 678 The third sub-field ("") is the connection 679 address. Additional sub-fields MAY be added after the connection 680 address depending on the value of the sub-field. 682 When the is IP4 or IP6, the connection address is defined 683 as follows: 685 o If the session is multicast, the connection address will be an IP 686 multicast group address. If the session is not multicast, then 687 the connection address contains the unicast IP address of the 688 expected data source, data relay or data sink as determined by 689 additional attribute-fields. It is not expected that unicast 690 addresses will be given in a session description that is 691 communicated by a multicast announcement, though this is not 692 prohibited. 694 o Sessions using an IP4 multicast connection address MUST also have 695 a time to live (TTL) value present in addition to the multicast 696 address. The TTL and the address together define the scope with 697 which multicast packets sent in this session will be sent. TTL 698 values MUST be in the range 0-255. Although the TTL MUST be 699 specified, its use to scope multicast traffic is deprecated; 700 applications SHOULD use an administratively scoped address 701 instead. 703 The TTL for the session is appended to the address using a slash as a 704 separator. An example is: 706 c=IN IP4 233.252.0.1/127 708 IP6 multicast does not use TTL scoping, and hence the TTL value MUST 709 NOT be present for IP6 multicast. It is expected that IPv6 scoped 710 addresses will be used to limit the scope of multimedia conferences. 712 Hierarchical or layered encoding schemes are data streams where the 713 encoding from a single media source is split into a number of layers. 714 The receiver can choose the desired quality (and hence bandwidth) by 715 only subscribing to a subset of these layers. Such layered encodings 716 are normally transmitted in multiple multicast groups to allow 717 multicast pruning. This technique keeps unwanted traffic from sites 718 only requiring certain levels of the hierarchy. For applications 719 requiring multiple multicast groups, we allow the following notation 720 to be used for the connection address: 722 [/]/ 724 If the number of addresses is not given, it is assumed to be one. 725 Multicast addresses so assigned are contiguously allocated above the 726 base address, so that, for example: 728 c=IN IP4 233.252.0.1/127/3 730 would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3 731 are to be used with a TTL of 127. This is semantically identical to 732 including multiple "c=" lines in a media description: 734 c=IN IP4 233.252.0.1/127 735 c=IN IP4 233.252.0.2/127 736 c=IN IP4 233.252.0.3/127 738 Similarly, an IPv6 example would be: 740 c=IN IP6 ff00::db8:0:101/3 742 which is semantically equivalent to: 744 c=IN IP6 ff00::db8:0:101 745 c=IN IP6 ff00::db8:0:102 746 c=IN IP6 ff00::db8:0:103 748 (remembering that the TTL sub-field is not present in IP6 multicast). 750 Multiple addresses or "c=" lines MAY be specified on a per media 751 description basis only if they provide multicast addresses for 752 different layers in a hierarchical or layered encoding scheme. 753 Multiple addresses or "c=" lines MUST NOT be specified at session 754 level. 756 The slash notation for multiple addresses described above MUST NOT be 757 used for IP unicast addresses. 759 5.8. Bandwidth Information ("b=") 761 b=: 763 The OPTIONAL "b=" line (bandwidth-field) denotes the proposed 764 bandwidth to be used by the session or media description. The 765 is an alphanumeric modifier giving the meaning of the 766 figure. Two values are defined in this specification, 767 but other values MAY be registered in the future (see Section 8 and 768 [RFC3556], [RFC3890]): 770 CT If the bandwidth of a session is different from the bandwidth 771 implicit from the scope, a "b=CT:..." line SHOULD be supplied for 772 the session giving the proposed upper limit to the bandwidth used 773 (the "conference total" bandwidth). Similarly, if the bandwidth 774 of bundled media streams [I-D.ietf-mmusic-sdp-bundle-negotiation] 775 in an "m=" line is different from the implicit value from the 776 scope, a "b=CT:..." line SHOULD be supplied in the media level. 777 The primary purpose of this is to give an approximate idea as to 778 whether two or more sessions (or bundled media streams) can 779 coexist simultaneously. Note that CT gives a total bandwidth 780 figure for all the media at all endpoints. 782 The Mux Category for CT is NORMAL. This is discussed in 783 [I-D.ietf-mmusic-sdp-mux-attributes]. 785 AS The bandwidth is interpreted to be application specific (it will 786 be the application's concept of maximum bandwidth). Normally, 787 this will coincide with what is set on the application's "maximum 788 bandwidth" control if applicable. For RTP-based applications, AS 789 gives the RTP "session bandwidth" as defined in Section 6.2 of 790 [RFC3550]. Note that AS gives a bandwidth figure for a single 791 media at a single endpoint, although there may be many endpoints 792 sending simultaneously. 794 The Mux Category for AS is SUM. This is discussed in 795 [I-D.ietf-mmusic-sdp-mux-attributes]. 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 are the decimal 836 representation of time values in seconds since January 1, 1900 UTC. 837 To convert these values to UNIX time (UTC), subtract decimal 838 2208988800. 840 Some time representations will wrap in the year 2036. Because SDP 841 uses an arbitrary length decimal representation, it does not have 842 this issue. Implementations of SDP need to be prepared to handle 843 these larger values. 845 If the is set to zero, then the session is not bounded, 846 though it will not become active until after the . If 847 the is also zero, the session is regarded as permanent. 849 User interfaces SHOULD strongly discourage the creation of unbounded 850 and permanent sessions as they give no information about when the 851 session is actually going to terminate, and so make scheduling 852 difficult. 854 The general assumption may be made, when displaying unbounded 855 sessions that have not timed out to the user, that an unbounded 856 session will only be active until half an hour from the current time 857 or the session start time, whichever is the later. If behavior other 858 than this is required, an end-time SHOULD be given and modified as 859 appropriate when new information becomes available about when the 860 session should really end. 862 Permanent sessions may be shown to the user as never being active 863 unless there are associated repeat times that state precisely when 864 the session will be active. 866 5.10. Repeat Times ("r=") 868 r= 870 An"r=" line (repeat-field) specifies repeat times for a session. If 871 needed to express complex schedules, multiple repeat-fields may be 872 included. For example, if a session is active at 10am on Monday and 873 11am on Tuesday for one hour each week for three months, then the 874 in the corresponding "t=" line would be the 875 representation of 10am on the first Monday, the 876 would be 1 week, the would be 1 hour, and the 877 offsets would be zero and 25 hours. The corresponding "t=" line stop 878 time would be the representation of the end of the last session three 879 months later. By default, all sub-fields are in seconds, so the "r=" 880 and "t=" lines might be the following: 882 t=3724394400 3730536000 ; Mon 8-Jan-2018 10:00-11:00 UTC 883 ; Tues 20-Mar-2018 12:00 UTC 884 r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours 886 To make the description more compact, times may also be given in 887 units of days, hours, or minutes. The syntax for these is a number 888 immediately followed by a single case-sensitive character. 889 Fractional units are not allowed -- a smaller unit should be used 890 instead. The following unit specification characters are allowed: 892 d - days (86400 seconds) 893 h - hours (3600 seconds) 894 m - minutes (60 seconds) 895 s - seconds (allowed for completeness) 897 Thus, the above repeat-field could also have been written: 899 r=7d 1h 0 25h 901 Monthly and yearly repeats cannot be directly specified with a single 902 SDP repeat time; instead, separate time-descriptions should be used 903 to explicitly list the session times. 905 5.11. Time Zone Adjustment ("z=") 907 z= .... 909 A "z=" line (zone-field) is an optional modifier to the repeat-fields 910 it immediately follows. It does not apply to any other fields. 912 To schedule a repeated session that spans a change from daylight 913 saving time to standard time or vice versa, it is necessary to 914 specify offsets from the base time. This is required because 915 different time zones change time at different times of day, different 916 countries change to or from daylight saving time on different dates, 917 and some countries do not have daylight saving time at all. 919 Thus, in order to schedule a session that is at the same time winter 920 and summer, it must be possible to specify unambiguously by whose 921 time zone a session is scheduled. To simplify this task for 922 receivers, we allow the sender to specify the time (represented as 923 seconds since January 1, 1900 UTC) that a time zone adjustment 924 happens and the offset from the time when the session was first 925 scheduled. The "z=" line allows the sender to specify a list of 926 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, 936 ; no offset 938 This specifies that at time 3730928400 (Sun 25-Mar-2018 1:00 UTC, the 939 onset of British Summer Time) the time base by which the session's 940 repeat times are calculated is shifted back by 1 hour, and that at 941 time 3749680800 (Sun 28-Oct-2018 2:00 UTC, the end of British Summer 942 Time) the session's original time base is restored. Adjustments are 943 always relative to the specified start time -- they are not 944 cumulative. 946 If a session is likely to last several years, it is expected that the 947 session description will be modified periodically rather than 948 transmit several years' worth of adjustments in one session 949 description. 951 5.12. Encryption Keys ("k=") 953 k= 954 k=: 956 The "k=" line (key-field) is obsolete and MUST NOT be used. It is 957 included in this document for legacy reasons. One MUST NOT include a 958 "k=" line in an SDP, and MUST discard it if it is received in an SDP. 960 5.13. Attributes ("a=") 962 a= 963 a=: 965 Attributes are the primary means for extending SDP. Attributes may 966 be defined to be used as "session-level" attributes, "media-level" 967 attributes, or both. (Attribute scopes in addition to media- and 968 session- level may also be defined in extensions to this document. 969 E.g., [RFC5576], [I-D.ietf-mmusic-data-channel-sdpneg].) 971 A media description may contain any number of "a=" lines (attribute- 972 fields) that are media description specific. These are referred to 973 as "media-level" attributes and add information about the media 974 description. Attribute-fields can also be added before the first 975 media description; these "session-level" attributes convey additional 976 information that applies to the session as a whole rather than to 977 individual media descriptions. 979 Attribute-fields may be of two forms: 981 o A property attribute is simply of the form "a=". These 982 are binary attributes, and the presence of the attribute conveys 983 that the attribute is a property of the session. An example might 984 be "a=recvonly". 986 o A value attribute is of the form "a=:". For 987 example, a whiteboard could have the value attribute 988 "a=orient:landscape" 990 Attribute interpretation depends on the media tool being invoked. 991 Thus receivers of session descriptions should be configurable in 992 their interpretation of session descriptions in general and of 993 attributes in particular. 995 Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. 997 Attribute values are octet strings, and MAY use any octet value 998 except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute 999 values are to be interpreted as in ISO-10646 character set with UTF-8 1000 encoding. Unlike other text fields, attribute values are NOT 1001 normally affected by the "charset" attribute as this would make 1002 comparisons against known values problematic. However, when an 1003 attribute is defined, it can be defined to be charset dependent, in 1004 which case its value should be interpreted in the session charset 1005 rather than in ISO-10646. 1007 Attributes MUST be registered with IANA (see Section 8). If an 1008 attribute is received that is not understood, it MUST be ignored by 1009 the receiver. 1011 5.14. Media Descriptions ("m=") 1013 m= ... 1015 A session description may contain a number of media descriptions. 1016 Each media description starts with an "m=" line (media-field) and is 1017 terminated by either the next "m=" line or by the end of the session 1018 description. A media-field has several sub-fields: 1020 is the media type. This document defines the values 1021 "audio", "video", "text", "application", and "message". This list 1022 is extended by other memos and may be further extended by 1023 additional memos registering media types in the future (see 1024 Section 8). For example, [RFC6466] defined the "image" media 1025 type. 1027 is the transport port to which the media stream is sent. The 1028 meaning of the transport port depends on the network being used as 1029 specified in the relevant "c=" line, and on the transport protocol 1030 defined in the sub-field of the media-field. Other ports 1031 used by the media application (such as the RTP Control Protocol 1032 (RTCP) port [RFC3550]) MAY be derived algorithmically from the 1033 base media port or MAY be specified in a separate attribute (for 1034 example, "a=rtcp:" as defined in [RFC3605]). 1036 If non-contiguous ports are used or if they don't follow the 1037 parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" 1038 attribute MUST be used. Applications that are requested to send 1039 media to a that is odd and where the "a=rtcp:" is present 1040 MUST NOT subtract 1 from the RTP port: that is, they MUST send the 1041 RTP to the port indicated in and send the RTCP to the port 1042 indicated in the "a=rtcp" attribute. 1044 For applications where hierarchically encoded streams are being 1045 sent to a unicast address, it may be necessary to specify multiple 1046 transport ports. This is done using a similar notation to that 1047 used for IP multicast addresses in the "c=" line: 1049 m= / ... 1051 In such a case, the ports used depend on the transport protocol. 1052 For RTP, the default is that only the even-numbered ports are used 1053 for data with the corresponding one-higher odd ports used for the 1054 RTCP belonging to the RTP session, and the 1055 denoting the number of RTP sessions. For example: 1057 m=video 49170/2 RTP/AVP 31 1059 would specify that ports 49170 and 49171 form one RTP/RTCP pair 1060 and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the 1061 transport protocol and 31 is the format (see below). 1063 This document does not include a mechanism for declaring 1064 hierarchically encoded streams using non-contiguous ports. (There 1065 is currently no attribute defined that can accomplish this. The 1066 "a=rtcp:" defined in [RFC3605] does not handle hierarchical 1067 encoding.) If a need arises to declare non-contiguous ports then 1068 it will be necessary to define a new attribute to do so. 1070 If multiple addresses are specified in the "c=" line and multiple 1071 ports are specified in the "m=" line, a one-to-one mapping from 1072 port to the corresponding address is implied. For example: 1074 m=video 49170/2 RTP/AVP 31 1075 c=IN IP4 233.252.0.1/127/2 1077 would imply that address 233.252.0.1 is used with ports 49170 and 1078 49171, and address 233.252.0.2 is used with ports 49172 and 49173. 1080 The mapping is similar if multiple addresses are specified using 1081 multiple "c=" lines. For example: 1083 m=video 49170/2 RTP/AVP 31 1084 c=IN IP6 ff00::db8:0:101 1085 c=IN IP6 ff00::db8:0:102 1087 would imply that address ff00::db8:0:101 is used with ports 49170 1088 and 49171, and address ff00::db8:0:102 is used with ports 49172 1089 and 49173. 1091 This document gives no meaning to assigning the same media address 1092 to multiple media-descriptions. Doing so does not implicitly 1093 group those media-descriptions in any way. An explicit grouping 1094 framework (for example, [RFC5888]) should instead be used to 1095 express the intended semantics. For instance, see 1096 [I-D.ietf-mmusic-sdp-bundle-negotiation]. 1098 is the transport protocol. The meaning of the transport 1099 protocol is dependent on the address type sub-field in the 1100 relevant "c=" line. Thus a "c=" line with an address type of IP4 1101 indicates that the transport protocol runs over IPv4. The 1102 following transport protocols are defined, but may be extended 1103 through registration of new protocols with IANA (see Section 8): 1105 * udp: denotes that the data is transported directly in UDP with 1106 no additional framing. 1108 * RTP/AVP: denotes RTP [RFC3550] used under the RTP Profile for 1109 Audio and Video Conferences with Minimal Control [RFC3551] 1110 running over UDP. 1112 * RTP/SAVP: denotes the Secure Real-time Transport Protocol 1113 [RFC3711] running over UDP. 1115 The main reason to specify the transport protocol in addition to 1116 the media format is that the same standard media formats may be 1117 carried over different transport protocols even when the network 1118 protocol is the same -- a historical example is VAT (MBone's 1119 popular multimedia audio tool) Pulse Code Modulation (PCM) audio 1120 and RTP PCM audio; another might be TCP/RTP PCM audio. In 1121 addition, relays and monitoring tools that are transport-protocol- 1122 specific but format-independent are possible. 1124 is a media format description. The fourth and any subsequent 1125 sub-fields describe the format of the media. The interpretation 1126 of the media format depends on the value of the sub-field. 1128 If the sub-field is "RTP/AVP" or "RTP/SAVP" the sub- 1129 fields contain RTP payload type numbers. When a list of payload 1130 type numbers is given, this implies that all of these payload 1131 formats MAY be used in the session, but the first of these formats 1132 SHOULD be used as the default format for the session. For dynamic 1133 payload type assignments the "a=rtpmap:" attribute (see Section 6) 1134 SHOULD be used to map from an RTP payload type number to a media 1135 encoding name that identifies the payload format. The "a=fmtp:" 1136 attribute MAY be used to specify format parameters (see 1137 Section 6). 1139 If the sub-field is "udp" the sub-fields MUST 1140 reference a media type describing the format under the "audio", 1141 "video", "text", "application", or "message" top-level media 1142 types. The media type registration SHOULD define the packet 1143 format for use with UDP transport. 1145 For media using other transport protocols, the sub-field is 1146 protocol specific. Rules for interpretation of the sub- 1147 field MUST be defined when registering new protocols (see 1148 Section 8.2.2). 1150 Section 3 of [RFC4855] states that the payload format (encoding) 1151 names defined in the RTP Profile are commonly shown in upper case, 1152 while media subtype names are commonly shown in lower case. It 1153 also states that both of these names are case-insensitive in both 1154 places, similar to parameter names which are case-insensitive both 1155 in media type strings and in the default mapping to the SDP a=fmtp 1156 attribute. 1158 6. SDP Attributes 1160 The following attributes are defined. Since application writers may 1161 add new attributes as they are required, this list is not exhaustive. 1162 Registration procedures for new attributes are defined in 1163 Section 8.2.4. Syntax is provided using ABNF [RFC7405] with some of 1164 the rules defined further in Section 9. 1166 6.1. cat (category) 1168 Name: cat 1170 Value: cat-value 1172 Usage Level: session 1174 Charset Dependent: no 1176 Syntax: 1178 cat-value = category 1179 category = non-ws-string 1181 Example: 1183 a=cat:foo.bar 1185 This attribute gives the dot-separated hierarchical category of the 1186 session. This is to enable a receiver to filter unwanted sessions by 1187 category. There is no central registry of categories. This 1188 attribute is obsolete and SHOULD NOT be used. It SHOULD be ignored 1189 if received. 1191 6.2. keywds (keywords) 1193 Name: keywds 1195 Value: keywds-value 1197 Usage Level: session 1199 Charset Dependent: yes 1201 Syntax: 1203 keywds-value = keywords 1204 keywords = text 1206 Example: 1208 a=keywds:SDP session description protocol 1210 Like the cat attribute, this was intended to assist identifying 1211 wanted sessions at the receiver. This allows a receiver to select 1212 interesting sessions based on keywords describing the purpose of the 1213 session; there is no central registry of keywords. Its value should 1214 be interpreted in the charset specified for the session description 1215 if one is specified, or by default in ISO 10646/UTF-8. This 1216 attribute is obsolete and SHOULD NOT be used. It SHOULD be ignored 1217 if received. 1219 6.3. tool 1221 Name: tool 1223 Value: tool-value 1225 Usage Level: session 1227 Charset Dependent: no 1229 Syntax: 1231 tool-value = tool-name-and-version 1232 tool-name-and-version = text 1234 Example: 1236 a=tool:foobar V3.2 1238 This gives the name and version number of the tool used to create the 1239 session description. 1241 6.4. ptime (packet time) 1243 Name: ptime 1245 Value: ptime-value 1247 Usage Level: media 1249 Charset Dependent: no 1251 Syntax: 1253 ptime-value = non-zero-int-or-real 1255 Example: 1257 a=ptime:20 1259 This gives the length of time in milliseconds represented by the 1260 media in a packet. This is probably only meaningful for audio data, 1261 but may be used with other media types if it makes sense. It should 1262 not be necessary to know ptime to decode RTP or vat audio, and it is 1263 intended as a recommendation for the encoding/packetization of audio. 1265 6.5. maxptime (maximum packet time) 1267 Name: maxptime 1269 Value: maxptime-value 1271 Usage Level: media 1273 Charset Dependent: no 1275 Syntax: 1277 maxptime-value = non-zero-int-or-real 1279 Example: 1281 a=maxptime:20 1283 This gives the maximum amount of media that can be encapsulated in 1284 each packet, expressed as time in milliseconds. The time SHALL be 1285 calculated as the sum of the time the media present in the packet 1286 represents. For frame-based codecs, the time SHOULD be an integer 1287 multiple of the frame size. This attribute is probably only 1288 meaningful for audio data, but may be used with other media types if 1289 it makes sense. Note that this attribute was introduced after 1290 [RFC2327], and non-updated implementations will ignore this 1291 attribute. 1293 6.6. rtpmap 1295 Name: rtpmap 1297 Value: rtpmap-value 1299 Usage Level: media 1301 Charset Dependent: no 1302 Syntax: 1304 rtpmap-value = payload-type SP encoding-name 1305 "/" clock-rate [ "/" encoding-params ] 1306 payload-type = zero-based-integer 1307 encoding-name = token 1308 clock-rate = integer 1309 encoding-params = channels 1310 channels = integer 1312 This attribute maps from an RTP payload type number (as used in an 1313 "m=" line) to an encoding name denoting the payload format to be 1314 used. It also provides information on the clock rate and encoding 1315 parameters. Note that the payload type number is indicated in a 1316 7-bit field, limiting the values to inclusively between 0 and 127. 1318 Although an RTP profile can make static assignments of payload type 1319 numbers to payload formats, it is more common for that assignment to 1320 be done dynamically using "a=rtpmap:" attributes. As an example of a 1321 static payload type, consider u-law PCM coded single-channel audio 1322 sampled at 8 kHz. This is completely defined in the RTP Audio/Video 1323 profile as payload type 0, so there is no need for an "a=rtpmap:" 1324 attribute, and the media for such a stream sent to UDP port 49232 can 1325 be specified as: 1327 m=audio 49232 RTP/AVP 0 1329 An example of a dynamic payload type is 16-bit linear encoded stereo 1330 audio sampled at 16 kHz. If we wish to use the dynamic RTP/AVP 1331 payload type 98 for this stream, additional information is required 1332 to decode it: 1334 m=audio 49232 RTP/AVP 98 1335 a=rtpmap:98 L16/16000/2 1337 Up to one rtpmap attribute can be defined for each media format 1338 specified. Thus, we might have the following: 1340 m=audio 49230 RTP/AVP 96 97 98 1341 a=rtpmap:96 L8/8000 1342 a=rtpmap:97 L16/8000 1343 a=rtpmap:98 L16/11025/2 1345 RTP profiles that specify the use of dynamic payload types MUST 1346 define the set of valid encoding names and/or a means to register 1347 encoding names if that profile is to be used with SDP. The "RTP/AVP" 1348 and "RTP/SAVP" profiles use media subtypes for encoding names, under 1349 the top-level media type denoted in the "m=" line. In the example 1350 above, the media types are "audio/L8" and "audio/L16". 1352 For audio streams, encoding-params indicates the number of audio 1353 channels. This parameter is OPTIONAL and may be omitted if the 1354 number of channels is one, provided that no additional parameters are 1355 needed. 1357 For video streams, no encoding parameters are currently specified. 1359 Additional encoding parameters MAY be defined in the future, but 1360 codec-specific parameters SHOULD NOT be added. Parameters added to 1361 an "a=rtpmap:" attribute SHOULD only be those required for a session 1362 directory to make the choice of appropriate media to participate in a 1363 session. Codec-specific parameters should be added in other 1364 attributes (for example, "a=fmtp:"). 1366 Note: RTP audio formats typically do not include information about 1367 the number of samples per packet. If a non-default (as defined in 1368 the RTP Audio/Video Profile [RFC3551]) packetization is required, the 1369 "ptime" attribute is used as given above. 1371 6.7. Media Direction Attributes 1373 At most one occurrence of recvonly, sendrecv, sendonly, or inactive 1374 MAY appear at session level, and at most one MAY appear in each media 1375 description. 1377 If any one of these appears in a media description then it applies 1378 for that media description. If none appear in a media description 1379 then the one from session level, if any, applies to that media 1380 description. 1382 If none of the media direction attributes is present at either 1383 session level or media level, "sendrecv" SHOULD be assumed as the 1384 default. 1386 Within the following SDP example, the "sendrecv" attribute applies to 1387 the first audio media and the "inactive" attribute applies to the 1388 others. 1390 v=0 1391 o=jdoe 3724395000 3724395001 IN IP6 2001:db8::1 1392 s=- 1393 c=IN IP6 2001:db8::1 1394 t=0 0 1395 a=inactive 1396 m=audio 49170 RTP/AVP 0 1397 a=sendrecv 1398 m=audio 49180 RTP/AVP 0 1399 m=video 51372 RTP/AVP 99 1400 a=rtpmap:99 h263-1998/90000 1402 6.7.1. recvonly (receive-only) 1404 Name: recvonly 1406 Value: 1408 Usage Level: session, media 1410 Charset Dependent: no 1412 Example: 1414 a=recvonly 1416 This specifies that the tools should be started in receive-only mode 1417 where applicable. Note that recvonly applies to the media only, not 1418 to any associated control protocol. An RTP-based system in recvonly 1419 mode MUST still send RTCP packets as described in [RFC3550] 1420 Section 6. 1422 6.7.2. sendrecv (send-receive) 1424 Name: sendrecv 1426 Value: 1428 Usage Level: session, media 1430 Charset Dependent: no 1432 Example: 1434 a=sendrecv 1436 This specifies that the tools should be started in send and receive 1437 mode. This is necessary for interactive multimedia conferences with 1438 tools that default to receive-only mode. 1440 6.7.3. sendonly (send-only) 1442 Name: sendonly 1444 Value: 1446 Usage Level: session, media 1448 Charset Dependent: no 1450 Example: 1452 a=sendonly 1454 This specifies that the tools should be started in send-only mode. 1455 An example may be where a different unicast address is to be used for 1456 a traffic destination than for a traffic source. In such a case, two 1457 media descriptions may be used, one sendonly and one recvonly. Note 1458 that sendonly applies only to the media, and any associated control 1459 protocol (e.g., RTCP) SHOULD still be received and processed as 1460 normal. 1462 6.7.4. inactive 1464 Name: inactive 1466 Value: 1468 Usage Level: session, media 1470 Charset Dependent: no 1472 Example: 1474 a=inactive 1476 This specifies that the tools should be started in inactive mode. 1477 This is necessary for interactive multimedia conferences where users 1478 can put other users on hold. No media is sent over an inactive media 1479 stream. Note that an RTP-based system MUST still send RTCP (if RTCP 1480 is used), even if started inactive. 1482 6.8. orient (orientation) 1484 Name: orient 1486 Value: orient-value 1488 Usage Level: media 1490 Charset Dependent: no 1492 Syntax: 1494 orient-value = portrait / landscape / seascape 1495 portrait = %s"portrait" 1496 landscape = %s"landscape" 1497 seascape = %s"seascape" 1498 ; NOTE: These names are case-sensitive. 1500 Example: 1502 a=orient:portrait 1504 Normally this is only used for a whiteboard or presentation tool. It 1505 specifies the orientation of the workspace on the screen. Permitted 1506 values are "portrait", "landscape", and "seascape" (upside-down 1507 landscape). 1509 6.9. type (conference type) 1511 Name: type 1513 Value: type-value 1515 Usage Level: session 1517 Charset Dependent: no 1519 Syntax: 1521 type-value = conference-type 1522 conference-type = broadcast / meeting / moderated / test / 1523 H332 1524 broadcast = %s"broadcast" 1525 meeting = %s"meeting" 1526 moderated = %s"moderated" 1527 test = %s"test" 1528 H332 = %s"H332" 1529 ; NOTE: These names are case-sensitive. 1531 Example: 1533 a=type:moderated 1535 This specifies the type of the multimedia conference. Allowed values 1536 are "broadcast", "meeting", "moderated", "test", and "H332". These 1537 values have implications for other options that are likely to be 1538 appropriate: 1540 o When "a=type:broadcast" is specified, "a=recvonly" is probably 1541 appropriate for those connecting. 1543 o When "a=type:meeting" is specified, "a=sendrecv" is likely to be 1544 appropriate. 1546 o "a=type:moderated" suggests the use of a floor control tool and 1547 that the media tools be started so as to mute new sites joining 1548 the multimedia conference. 1550 o Specifying "a=type:H332" indicates that this loosely coupled 1551 session is part of an H.332 session as defined in the ITU H.332 1552 specification [ITU.H332.1998]. Media tools should be started 1553 using "a=recvonly". 1555 o Specifying "a=type:test" is suggested as a hint that, unless 1556 explicitly requested otherwise, receivers can safely avoid 1557 displaying this session description to users. 1559 6.10. charset (character set) 1561 Name: charset 1563 Value: charset-value 1565 Usage Level: session 1567 Charset Dependent: no 1569 Syntax: 1571 charset-value = 1573 This specifies the character set to be used to display the session 1574 name and information data. By default, the ISO-10646 character set 1575 in UTF-8 encoding is used. If a more compact representation is 1576 required, other character sets may be used. For example, the ISO 1577 8859-1 is specified with the following SDP attribute: 1579 a=charset:ISO-8859-1 1581 The charset specified MUST be one of those registered in the IANA 1582 Character Sets registry (http://www.iana.org/assignments/character- 1583 sets), such as ISO-8859-1. The character set identifier is a string 1584 that MUST be compared against identifiers from the "Name" or 1585 "Preferred MIME Name" field of the registry using a case-insensitive 1586 comparison. If the identifier is not recognized or not supported, 1587 all strings that are affected by it SHOULD be regarded as octet 1588 strings. 1590 Charset-dependent fields MUST contain only sequences of bytes that 1591 are valid according to the definition of the selected character set. 1592 Furthermore, charset-dependent fields MUST NOT contain the bytes 0x00 1593 (Nul), 0x0A (LF), and 0x0d (CR). 1595 6.11. sdplang (SDP language) 1597 Name: sdplang 1599 Value: sdplang-value 1601 Usage Level: session, media 1603 Charset Dependent: no 1605 Syntax: 1607 sdplang-value = Language-Tag 1608 ; Language-Tag defined in RFC5646 1610 Example: 1612 a=sdplang:fr 1614 Multiple sdplang attributes can be provided either at session or 1615 media level if the session description or media use multiple 1616 languages. 1618 As a session-level attribute, it specifies the language for the 1619 session description (not the language of the media). As a media- 1620 level attribute, it specifies the language for any media-level SDP 1621 information-field associated with that media (again not the language 1622 of the media), overriding any sdplang attributes specified at session 1623 level. 1625 In general, sending session descriptions consisting of multiple 1626 languages is discouraged. Instead, multiple sesssion descriptions 1627 SHOULD be sent describing the session, one in each language. 1628 However, this is not possible with all transport mechanisms, and so 1629 multiple sdplang attributes are allowed although NOT RECOMMENDED. 1631 The "sdplang" attribute value must be a single [RFC5646] language 1632 tag. An "sdplang" attribute SHOULD be specified when a session is 1633 distributed with sufficient scope to cross geographic boundaries, 1634 where the language of recipients cannot be assumed, or where the 1635 session is in a different language from the locally assumed norm. 1637 6.12. lang (language) 1639 Name: lang 1641 Value: lang-value 1643 Usage Level: session, media 1645 Charset Dependent: no 1647 Syntax: 1649 lang-value = Language-Tag 1650 ; Language-Tag defined in RFC5646 1652 Example: 1654 a=lang:de 1656 Multiple lang attributes can be provided either at session or media 1657 level if the session or media has capabilities in more than one 1658 language, in which case the order of the attributes indicates the 1659 order of preference of the various languages in the session or media, 1660 from most preferred to least preferred. 1662 As a session-level attribute, lang specifies a language capability 1663 for the session being described. As a media-level attribute, it 1664 specifies a language capability for that media, overriding any 1665 session-level language(s) specified. 1667 The "lang" attribute value must be a single [RFC5646] language tag. 1668 A "lang" attribute SHOULD be specified when a session is of 1669 sufficient scope to cross geographic boundaries where the language of 1670 participants cannot be assumed, or where the session has capabilities 1671 in languages different from the locally assumed norm. 1673 The "lang" attribute is supposed to be used for setting the initial 1674 language(s) used in the session. Events during the session may 1675 influence which language(s) are used, and the participants are not 1676 strictly bound to only use the declared languages. 1678 Most real-time use cases start with just one language used, while 1679 other cases involve a range of languages, e.g. an interpreted or 1680 subtitled session. When more than one 'lang' attribute is specified, 1681 the "lang" attribute itself does not provide any information about 1682 multiple languages being intended to be used during the session, or 1683 if the intention is to only select one of the languages. If needed, 1684 a new attribute can be defined and used to indicate such intentions. 1685 Without such semantics, it is assumed that for a negotiated session 1686 one of the declared languages will be selected and used. 1688 6.13. framerate (frame rate) 1690 Name: framerate 1692 Value: framerate-value 1694 Usage Level: media 1696 Charset Dependent: no 1698 Syntax: 1700 framerate-value = non-zero-int-or-real 1702 Example: 1704 a=framerate:60 1706 This gives the maximum video frame rate in frames/sec. It is 1707 intended as a recommendation for the encoding of video data. Decimal 1708 representations of fractional values are allowed. It is defined only 1709 for video media. 1711 6.14. quality 1713 Name: quality 1715 Value: quality-value 1717 Usage Level: media 1719 Charset Dependent: no 1720 Syntax: 1722 quality-value = zero-based-integer 1724 Example: 1726 a=quality:10 1728 This gives a suggestion for the quality of the encoding as an integer 1729 value. The intention of the quality attribute for video is to 1730 specify a non-default trade-off between frame-rate and still-image 1731 quality. For video, the value is in the range 0 to 10, with the 1732 following suggested meaning: 1734 10 - the best still-image quality the compression scheme 1735 can give. 1736 5 - the default behavior given no quality suggestion. 1737 0 - the worst still-image quality the codec designer 1738 thinks is still usable. 1740 6.15. fmtp (format parameters) 1742 Name: fmtp 1744 Value: fmtp-value 1746 Usage Level: media 1748 Charset Dependent: no 1750 Syntax: 1752 fmtp-value = fmt SP format-specific-params 1753 format-specific-params = byte-string 1754 ; Notes: 1755 ; - The format parameters are media type parameters and 1756 ; need to reflect their syntax. 1758 Example: 1760 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1762 This attribute allows parameters that are specific to a particular 1763 format to be conveyed in a way that SDP does not have to understand 1764 them. The format must be one of the formats specified for the media. 1765 Format-specific parameters, semicolon separated, may be any set of 1766 parameters required to be conveyed by SDP and given unchanged to the 1767 media tool that will use this format. At most one instance of this 1768 attribute is allowed for each format. 1770 The fmtp attribute may be used to specify parameters for any protocol 1771 and format that defines use of such parameters. 1773 7. Security Considerations 1775 SDP is frequently used with the Session Initiation Protocol [RFC3261] 1776 using the offer/answer model [RFC3264] to agree on parameters for 1777 unicast sessions. When used in this manner, the security 1778 considerations of those protocols apply. 1780 SDP is a session description format that describes multimedia 1781 sessions. Entities receiving and acting upon an SDP message SHOULD 1782 be aware that a session description cannot be trusted unless it has 1783 been obtained by an authenticated and integrity-protected transport 1784 protocol from a known and trusted source. Many different transport 1785 protocols may be used to distribute session descriptions, and the 1786 nature of the authentication and integrity-protection will differ 1787 from transport to transport. For some transports, security features 1788 are often not deployed. In case a session description has not been 1789 obtained in a trusted manner, the endpoint SHOULD exercise care 1790 because, among other attacks, the media sessions received may not be 1791 the intended ones, the destination where media is sent to may not be 1792 the expected one, any of the parameters of the session may be 1793 incorrect, or the media security may be compromised. It is up to the 1794 endpoint to make a sensible decision taking into account the security 1795 risks of the application and the user preferences - the endpoint may 1796 decide to ask the user whether or not to accept the session. 1798 On receiving a session description over an unauthenticated transport 1799 mechanism or from an untrusted party, software parsing the session 1800 description should take a few precautions. Similar concerns apply if 1801 integrity protection is not in place. Session descriptions contain 1802 information required to start software on the receiver's system. 1803 Software that parses a session description MUST NOT be able to start 1804 other software except that which is specifically configured as 1805 appropriate software to participate in multimedia sessions. It is 1806 normally considered inappropriate for software parsing a session 1807 description to start, on a user's system, software that is 1808 appropriate to participate in multimedia sessions, without the user 1809 first being informed that such software will be started and giving 1810 the user's consent. Thus, a session description arriving by session 1811 announcement, email, session invitation, or WWW page MUST NOT deliver 1812 the user into an interactive multimedia session unless the user has 1813 explicitly pre-authorized such action. As it is not always simple to 1814 tell whether or not a session is interactive, applications that are 1815 unsure should assume sessions are interactive. Software processing 1816 URLs contained in session descriptions should also heed the security 1817 considerations identified in [RFC3986]. 1819 In this specification, there are no attributes that would allow the 1820 recipient of a session description to be informed to start multimedia 1821 tools in a mode where they default to transmitting. Under some 1822 circumstances it might be appropriate to define such attributes. If 1823 this is done, an application parsing a session description containing 1824 such attributes SHOULD either ignore them or inform the user that 1825 joining this session will result in the automatic transmission of 1826 multimedia data. The default behavior for an unknown attribute is to 1827 ignore it. 1829 In certain environments, it has become common for intermediary 1830 systems to intercept and analyze session descriptions contained 1831 within other signaling protocols. This is done for a range of 1832 purposes, including but not limited to opening holes in firewalls to 1833 allow media streams to pass, or to mark, prioritize, or block traffic 1834 selectively. In some cases, such intermediary systems may modify the 1835 session description, for example, to have the contents of the session 1836 description match NAT bindings dynamically created. These behaviors 1837 are NOT RECOMMENDED unless the session description is conveyed in 1838 such a manner that allows the intermediary system to conduct proper 1839 checks to establish the authenticity of the session description, and 1840 the authority of its source to establish such communication sessions. 1841 SDP by itself does not include sufficient information to enable these 1842 checks: they depend on the encapsulating protocol (e.g., SIP or 1843 RTSP). Use of some procedures and SDP extensions (e.g., ICE 1844 [RFC8445] and ICE-SIP-SDP [I-D.ietf-mmusic-ice-sip-sdp]) may avoid 1845 the need for intermediaries to modify SDP. 1847 SDP MUST NOT be used to convey keying material (e.g., using 1848 "a=crypto" [RFC4568]) unless it can be guaranteed that the channel 1849 over which the SDP is delivered is both private and authenticated. 1851 8. IANA Considerations 1853 8.1. The "application/sdp" Media Type 1855 One media type registration from [RFC4566] is to be updated, as 1856 defined below. 1858 To: ietf-types@iana.org 1859 Subject: Registration of media type "application/sdp" 1861 Type name: application 1862 Subtype name: sdp 1864 Required parameters: None. 1866 Optional parameters: None. 1868 Encoding considerations: 8-bit text. 1869 SDP files are primarily UTF-8 format text. The "a=charset:" 1870 attribute may be used to signal the presence of other character 1871 sets in certain parts of an SDP file (see Section 6 of RFC 1872 XXXX). Arbitrary binary content cannot be directly 1873 represented in SDP. 1875 Security considerations: 1876 See Section 7 of RFC XXXX. 1878 Interoperability considerations: 1879 See RFC XXXX. 1881 Published specification: 1882 See RFC XXXX. 1884 Applications which use this media type: 1885 Voice over IP, video teleconferencing, streaming media, instant 1886 messaging, among others. See also Section 3 of RFC XXXX. 1888 Fragment identifier considerations: None 1890 Additional information: 1892 Deprecated alias names for this type: N/A 1893 Magic number(s): None. 1894 File extension(s): The extension ".sdp" is commonly used. 1895 Macintosh File Type Code(s): "sdp " 1897 Person & email address to contact for further information: 1898 IETF MMUSIC working group 1900 Intended usage: COMMON 1902 Restrictions on usage: None 1904 Author/Change controller: 1905 Authors of RFC XXXX 1906 IETF MMUSIC working group delegated from the IESG 1908 8.2. Registration of SDP Parameters with IANA 1910 This document specifies IANA parameter registries for six named SDP 1911 sub-fields. Using the terminology in the SDP specification Augmented 1912 Backus-Naur Form (ABNF), they are "media", "proto", "att-field", 1913 "bwtype", "nettype", and "addrtype". 1915 This document also replaces and updates the definitions of all those 1916 parameters previously defined by [RFC4566]. 1918 IANA: Please change all references to RFC4566 in these registries to 1919 instead refer to this document. 1921 The contact name and email address for all parameters registered in 1922 this document is: 1924 The IETF MMUSIC working group or its successor 1925 as designated by the IESG. 1927 All of these registries have a common format: 1929 ---------------------------------------------------- 1930 | Type | SDP Name | [other fields] | Reference | 1931 ---------------------------------------------------- 1933 8.2.1. Registration Procedure 1935 A specification document that defines values for SDP "media", 1936 "proto", "att-field", "bwtype", "nettype", and "addrtype" parameters 1937 MUST include the following information: 1939 o contact name; 1941 o contact email address; 1943 o name being defined (as it will appear in SDP); 1945 o type of name ("media", "proto", "bwtype", "nettype", or 1946 "addrtype"); 1948 o a description of the purpose of the defined name; 1950 o a stable reference to the document containing this information and 1951 the definition of the value. (This will typically be an RFC 1952 number.) 1954 The subsections below specify what other information (if any) must be 1955 specified for particular parameters, and what other fields are to be 1956 included in the registry. 1958 8.2.2. Media Types ("media") 1960 The set of media types is intended to be small and SHOULD NOT be 1961 extended except under rare circumstances. The same rules should 1962 apply for media names as for top-level media types, and where 1963 possible the same name should be registered for SDP as for MIME. For 1964 media other than existing top-level media types, a Standards Track 1965 RFC MUST be produced for a new top-level media type to be registered, 1966 and the registration MUST provide good justification why no existing 1967 media name is appropriate (the "Standards Action" policy of 1968 [RFC8126]). 1970 This memo registers the media types "audio", "video", "text", 1971 "application", and "message". 1973 Note: The media types "control" and "data" were listed as valid in an 1974 early version of this specification (RFC 2327); however, their 1975 semantics were never fully specified and they are not widely used. 1976 These media types have been removed in this specification, although 1977 they still remain valid media type capabilities for a SIP user agent 1978 as defined in [RFC3840]. If these media types are considered useful 1979 in the future, a Standards Track RFC MUST be produced to document 1980 their use. Until that is done, applications SHOULD NOT use these 1981 types and SHOULD NOT declare support for them in SIP capabilities 1982 declarations (even though they exist in the registry created by 1983 [RFC3840]). Also note that [RFC6466] defined the "image" media type. 1985 8.2.3. Transport Protocols ("proto") 1987 The "proto" sub-field describes the transport protocol used. The 1988 registration procedure for this registry is "RFC Required". 1990 This document registers two values: 1992 o "RTP/AVP" is a reference to [RFC3550] used under the RTP Profile 1993 for Audio and Video Conferences with Minimal Control [RFC3551] 1994 running over UDP/IP, 1996 o "UDP" indicates direct use of the UDP protocol. 1998 New transport protocols MAY be defined, and MUST be registered with 1999 IANA. Registrations MUST reference an RFC describing the protocol. 2000 Such an RFC MAY be Experimental or Informational, although it is 2001 preferable that it be Standards Track. The RFC defining a new 2002 protocol MUST define the rules by which the "fmt" (see below) 2003 namespace is managed. 2005 "proto" names starting with "RTP/" MUST only be used for defining 2006 transport protocols that are profiles of the RTP protocol. For 2007 example, a profile whose short name is "XYZ" would be denoted by a 2008 "proto" sub-field of "RTP/XYZ". 2010 Each transport protocol, defined by the "proto" sub-field, has an 2011 associated "fmt" namespace that describes the media formats that may 2012 be conveyed by that protocol. Formats cover all the possible 2013 encodings that could be transported in a multimedia session. 2015 RTP payload formats under the "RTP/AVP" and other "RTP/*" profiles 2016 MUST use the payload type number as their "fmt" value. If the 2017 payload type number is dynamically assigned by this session 2018 description, an additional "rtpmap" attribute MUST be included to 2019 specify the format name and parameters as defined by the media type 2020 registration for the payload format. It is RECOMMENDED that other 2021 RTP profiles that are registered (in combination with RTP) as SDP 2022 transport protocols specify the same rules for the "fmt" namespace. 2024 For the "UDP" protocol, allowed "fmt" values are media subtypes from 2025 the IANA Media Types registry. The media type and subtype 2026 combination / specifies the format of the body of UDP 2027 packets. Use of an existing media subtype for the format is 2028 encouraged. If no suitable media subtype exists, it is RECOMMENDED 2029 that a new one be registered through the IETF process [RFC6838] by 2030 production of, or reference to, a standards-track RFC that defines 2031 the format. 2033 For other protocols, formats MAY be registered according to the rules 2034 of the associated "proto" specification. 2036 Registrations of new formats MUST specify which transport protocols 2037 they apply to. 2039 8.2.4. Attribute Names ("att-field") 2041 Attribute-field names ("att-field") MUST be registered with IANA and 2042 documented, to avoid any issues due to conflicting attribute 2043 definitions under the same name. (While unknown attributes in SDP 2044 are simply ignored, conflicting ones that fragment the protocol are a 2045 serious problem.) 2047 The format of the attribute registry is: 2049 ---------------------------------------------------------------------- 2050 | | | | Mux | | 2051 | Type | SDP Name | Usage Level | Category | Reference | 2052 ---------------------------------------------------------------------- 2054 For example, the attribute "setup" which is defined for both session 2055 and media level, will be listed in the new registry as follows: 2057 ---------------------------------------------------------------------- 2058 | | | | Mux | | 2059 | Type | SDP Name | Usage Level | Category | Reference | 2060 |----------|------------|----------------|----------|----------------| 2061 |attribute |setup | session,media, |IDENTICAL | [RFC4145] | 2062 | | | dcsa,dcsa(msrp)| | [RFC6135] | 2063 | | | | | [I-D.mmusic- | 2064 | | | | | msrp-usage- | 2065 | | | | | data-channel] | 2066 ---------------------------------------------------------------------- 2068 This one registry combines all of the previous usage-level-specific 2069 "att-field" registries, including updates made by 2070 [I-D.ietf-mmusic-sdp-mux-attributes]. IANA is requested to do the 2071 necessary reformatting. 2073 Section 6 of this document replaces the initial set of attribute 2074 definitions made by [RFC4566]. IANA is requested to update the 2075 registry accordingly. 2077 Documents can define new attributes and can also extend the 2078 definitions of previously defined attributes: 2080 8.2.4.1. New Attributes 2082 New attribute registrations are accepted according to the 2083 "Specification Required" policy of [RFC8126], provided that the 2084 specification includes the following information: 2086 o Contact Name. 2088 o Contact Email Address. 2090 o Attribute Name: The name of the attribute that will appear in 2091 SDP). This MUST conform to the definition of . 2093 o Attribute Syntax: For a value attribute (see clause 5.13), an ABNF 2094 definition of the attribute value syntax (see 2095 Section 9) MUST be provided. The syntax MUST follow the rule form 2096 as per Section 2.2 of [RFC5234] and [RFC7405]. This SHALL define 2097 the allowable values that the attribute might take. It MAY also 2098 define an extension method for the addition of future values. For 2099 a property attribute, the ABNF definition is omitted as the 2100 property attribute takes no values. 2102 o Attribute Semantics: For a value attribute, a semantic description 2103 of the values that the attribute might take MUST be provided. The 2104 usage of a property attribute is described under purpose below. 2106 o Attribute Value: The name of an ABNF syntax rule defining the 2107 syntax of the value. Absence of a rule name indicates that the 2108 attribute takes no values. Enclosing the rule name in "[" and "]" 2109 indicates that a value is optional. 2111 o Usage Level: Usage level(s) of the attribute. This MUST be one or 2112 more of the following: session, media, source, dcsa and 2113 dcsa(subprotocol). For a definition of source level attributes, 2114 see [RFC5576]. For a definition of dcsa attributes see: 2115 [I-D.ietf-mmusic-data-channel-sdpneg]. 2117 o Charset Dependent: This MUST be "Yes" or "No" depending on whether 2118 the attribute value is subject to the charset attribute. 2120 o Purpose: An explanation of the purpose and usage of the attribute. 2122 o O/A Procedures: Offer/Answer procedures as explained in [RFC3264]. 2124 o Mux Category: This MUST indicate one of the following categories: 2125 NORMAL, NOT RECOMMENDED, IDENTICAL, SUM, TRANSPORT, INHERIT, 2126 IDENTICAL-PER-PT, SPECIAL or TBD as defined by [I-D.ietf-mmusic- 2127 sdp-mux-attributes]. 2129 o Reference: A reference to the specification defining the 2130 attribute. 2132 The above is the minimum that IANA will accept. Attributes that are 2133 expected to see widespread use and interoperability SHOULD be 2134 documented with a standards-track RFC that specifies the attribute 2135 more precisely. 2137 Submitters of registrations should ensure that the specification is 2138 in the spirit of SDP attributes, most notably that the attribute is 2139 platform independent in the sense that it makes no implicit 2140 assumptions about operating systems and does not name specific pieces 2141 of software in a manner that might inhibit interoperability. 2143 Submitters of registrations should also carefully choose the 2144 attribute usage level. They should not choose only "session" when 2145 the attribute can have different values when media is disaggregated, 2146 i.e., when each m= section has its own IP address on a different 2147 endpoint. In that case the attribute type chosen should be "session, 2148 media" or "media" (depending on desired semantics). The default rule 2149 is that for all new SDP attributes that can occur both in session and 2150 media level, the media level overrides the session level. When this 2151 is not the case for a new SDP attribute, it MUST be explicitly 2152 stated. 2154 IANA has registered the initial set of attribute names ("att-field" 2155 values) with definitions as in Section 6 of this memo (these 2156 definitions replace those in [RFC4566]). 2158 8.2.4.2. Updates to Existing Attributes 2160 Updated attribute registrations are accepted according to the 2161 "Specification Required" policy of [RFC8126]. 2163 The Designated Expert reviewing the update is requested to evaluate 2164 whether the update is compatible with the prior intent and use of the 2165 attribute, and whether the new document is of sufficient maturity and 2166 authority in relation to the prior document. 2168 The specification updating the attribute (for example, by adding a 2169 new value) MUST update registration information items from 2170 Section 8.2.4.1 according to the following constraints: 2172 o Contact Name: A name for an entity responsible for the update MUST 2173 be provided. 2175 o Contact Email Address: An email address for an entity responsible 2176 for the update MUST be provided. 2178 o Attribute Name: MUST be provided and MUST NOT be changed. 2179 Otherwise it is a new attribute. 2181 o Attribute Syntax: The existing rule syntax with the syntax 2182 extensions MUST be provided if there is a change to the syntax. A 2183 revision to an existing attribute usage MAY extend the syntax of 2184 an attribute, but MUST be backward compatible. 2186 o Attribute Semantics: A semantic description of new additional 2187 attribute values or a semantic extension of existing values. 2188 Existing attribute values semantics MUST only be extended in a 2189 backward compatible manner. 2191 o Usage Level: Updates MAY only add additional levels. 2193 o Charset Dependent: MUST NOT be changed. 2195 o Purpose: MAY be extended according to the updated usage. 2197 o O/A Procedures: MAY be updated in a backward compatible manner 2198 and/or it applies to a new usage level only. 2200 o Mux Category: No change unless from "TBD" to another value (see 2201 [I-D.ietf-mmusic-sdp-mux-attributes]. It MAY also change if 2202 'media' level is being added to the definition of an attribute 2203 that previously did not include it. 2205 o Reference: A new (additional or replacement) reference MUST be 2206 provided. 2208 Items SHOULD be omitted if there is no impact to them as a result of 2209 the attribute update. 2211 8.2.5. Bandwidth Specifiers ("bwtype") 2213 A proliferation of bandwidth specifiers is strongly discouraged. 2215 New bandwidth specifiers ( sub-field values) MUST be 2216 registered with IANA. The submission MUST reference a standards- 2217 track RFC specifying the semantics of the bandwidth specifier 2218 precisely, and indicating when it should be used, and why the 2219 existing registered bandwidth specifiers do not suffice. 2221 The RFC MUST specify the Mux Category for this value as defined by 2222 [I-D.ietf-mmusic-sdp-mux-attributes]. 2224 The format of the "bwtype" registry is: 2226 -------------------------------------------------- 2227 | Type | SDP Name | Mux Category | Reference | 2228 -------------------------------------------------- 2230 IANA is requested to update the "bwtype" registry entries for the 2231 bandwidth specifiers "CT" and "AS" with the definitions in 2232 Section 5.8 of this memo (these definitions replace those in 2233 [RFC4566]). 2235 8.2.6. Network Types ("nettype") 2237 Network type "IN", representing the Internet, is defined in 2238 Section 5.2 and Section 5.7 of this memo. (This definition replaces 2239 that in [RFC4566].) 2240 To enable SDP to reference a new non-Internet environment a new 2241 network type ( sub-field value) MUST be registered with 2242 IANA. The registration is subject to the "RFC Required" policy of 2243 [RFC8126]. Although non-Internet environments are not normally the 2244 preserve of IANA, there may be circumstances when an Internet 2245 application needs to interoperate with a non-Internet application, 2246 such as when gatewaying an Internet telephone call into the Public 2247 Switched Telephone Network (PSTN). The number of network types 2248 should be small and should be rarely extended. A new network type 2249 registration MUST reference an RFC that gives details of the network 2250 type and the address type(s) that may be used with it. 2252 The format of the "nettype" registry is: 2254 -------------------------------------------------------------------- 2255 |Type | SDP Name | Usable addrtype Values | Reference | 2256 -------------------------------------------------------------------- 2258 IANA is requested to update the "nettype" registry to this new 2259 format. The following is the updated content of th registry: 2261 -------------------------------------------------------------------- 2262 |Type | SDP Name | Usable addrtype Values | Reference | 2263 -------------------------------------------------------------------- 2264 |nettype | IN | IP4, IP6 | [RFCXXXX] | 2265 |nettype | TN | RFC2543 | [RFC2848] | 2266 |nettype | ATM | NSAP, GWID, E164 | [RFC3108] | 2267 |nettype | PSTN | E164 | [RFC7195] | 2268 -------------------------------------------------------------------- 2270 Note that both [RFC7195] and [RFC3108] registered "E164" as an 2271 address type, although [RFC7195] mentions that the "E164" address 2272 type has a different context for ATM and PSTN networks. 2274 8.2.7. Address Types ("addrtype") 2276 New address types ("addrtype") MUST be registered with IANA. The 2277 registration is subject to the "RFC Required" policy of [RFC8126]. A 2278 new address type registration MUST reference an RFC giving details of 2279 the syntax of the address type. Address types are not expected to be 2280 registered frequently. 2282 Section 5.7 of this document gives new definitions of address types 2283 "IP4" and "IP6". 2285 8.3. Encryption Key Access Methods (OBSOLETE) 2287 The IANA previously maintained a table of SDP encryption key access 2288 method ("enckey") names. This table is obsolete, since the "k=" line 2289 is not extensible. New registrations MUST NOT be accepted. 2291 9. SDP Grammar 2293 This section provides an Augmented BNF grammar for SDP. ABNF is 2294 defined in [RFC5234] and [RFC7405]. 2296 ; SDP Syntax 2297 session-description = version-field 2298 origin-field 2299 session-name-field 2300 [information-field] 2301 [uri-field] 2302 *email-field 2303 *phone-field 2304 [connection-field] 2305 *bandwidth-field 2306 1*time-description 2307 [key-field] 2308 *attribute-field 2309 *media-description 2311 version-field = %s"v" "=" 1*DIGIT CRLF 2312 ;this memo describes version 0 2314 origin-field = %s"o" "=" username SP sess-id SP sess-version SP 2315 nettype SP addrtype SP unicast-address CRLF 2317 session-name-field = %s"s" "=" text CRLF 2319 information-field = %s"i" "=" text CRLF 2321 uri-field = %s"u" "=" uri CRLF 2323 email-field = %s"e" "=" email-address CRLF 2325 phone-field = %s"p" "=" phone-number CRLF 2327 connection-field = %s"c" "=" nettype SP addrtype SP 2328 connection-address CRLF 2329 ;a connection field must be present 2330 ;in every media description or at the 2331 ;session level 2333 bandwidth-field = %s"b" "=" bwtype ":" bandwidth CRLF 2335 time-description = time-field 2336 [repeat-description] 2338 repeat-description = 1*repeat-field 2339 [zone-field] 2341 time-field = %s"t" "=" start-time SP stop-time CRLF 2343 repeat-field = %s"r" "=" repeat-interval SP typed-time 2344 1*(SP typed-time) CRLF 2346 zone-field = %s"z" "=" time SP ["-"] typed-time 2347 *(SP time SP ["-"] typed-time) CRLF 2349 key-field = %s"k" "=" key-type CRLF 2351 attribute-field = %s"a" "=" attribute CRLF 2353 media-description = media-field 2354 [information-field] 2355 *connection-field 2356 *bandwidth-field 2357 [key-field] 2358 *attribute-field 2360 media-field = %s"m" "=" media SP port ["/" integer] 2361 SP proto 1*(SP fmt) CRLF 2363 ; sub-rules of 'o=' 2364 username = non-ws-string 2365 ;pretty wide definition, but doesn't 2366 ;include space 2368 sess-id = 1*DIGIT 2369 ;should be unique for this username/host 2371 sess-version = 1*DIGIT 2373 nettype = token 2374 ;typically "IN" 2376 addrtype = token 2377 ;typically "IP4" or "IP6" 2379 ; sub-rules of 'u=' 2380 uri = URI-reference 2381 ; see RFC 3986 2383 ; sub-rules of 'e=', see RFC 5322 for definitions 2384 email-address = address-and-comment / dispname-and-address 2385 / addr-spec 2386 address-and-comment = addr-spec 1*SP "(" 1*email-safe ")" 2387 dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">" 2389 ; sub-rules of 'p=' 2390 phone-number = phone *SP "(" 1*email-safe ")" / 2391 1*email-safe "<" phone ">" / 2392 phone 2394 phone = ["+"] DIGIT 1*(SP / "-" / DIGIT) 2396 ; sub-rules of 'c=' 2397 connection-address = multicast-address / unicast-address 2399 ; sub-rules of 'b=' 2400 bwtype = token 2402 bandwidth = 1*DIGIT 2404 ; sub-rules of 't=' 2405 start-time = time / "0" 2407 stop-time = time / "0" 2409 time = POS-DIGIT 9*DIGIT 2410 ; Decimal representation of time in 2411 ; seconds since January 1, 1900 UTC. 2412 ; The representation is an unbounded 2413 ; length field containing at least 2414 ; 10 digits. Unlike some representations 2415 ; used elsewhere, time in SDP does not 2416 ; wrap in the year 2036. 2418 ; sub-rules of 'r=' and 'z=' 2419 repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] 2421 typed-time = 1*DIGIT [fixed-len-time-unit] 2423 fixed-len-time-unit = %s"d" / %s"h" / %s"m" / %s"s" 2424 ; NOTE: These units are case-sensitive. 2426 ; sub-rules of 'k=' 2427 key-type = %s"prompt" / 2428 %s"clear:" text / 2429 %s"base64:" base64 / 2430 %s"uri:" uri 2431 ; NOTE: These names are case-sensitive. 2433 base64 = *base64-unit [base64-pad] 2434 base64-unit = 4base64-char 2435 base64-pad = 2base64-char "==" / 3base64-char "=" 2436 base64-char = ALPHA / DIGIT / "+" / "/" 2438 ; sub-rules of 'a=' 2439 attribute = (att-field ":" att-value) / att-field 2441 att-field = token 2443 att-value = byte-string 2445 ; sub-rules of 'm=' 2446 media = token 2447 ;typically "audio", "video", "text", "image" 2448 ;or "application" 2450 fmt = token 2451 ;typically an RTP payload type for audio 2452 ;and video media 2454 proto = token *("/" token) 2455 ;typically "RTP/AVP" or "udp" 2457 port = 1*DIGIT 2459 ; generic sub-rules: addressing 2460 unicast-address = IP4-address / IP6-address / FQDN / extn-addr 2462 multicast-address = IP4-multicast / IP6-multicast / FQDN 2463 / extn-addr 2465 IP4-multicast = m1 3( "." decimal-uchar ) 2466 "/" ttl [ "/" numaddr ] 2467 ; IP4 multicast addresses may be in the 2468 ; range 224.0.0.0 to 239.255.255.255 2470 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / 2471 ("23" DIGIT ) 2473 IP6-multicast = IP6-address [ "/" numaddr ] 2474 ; IP6 address starting with FF 2476 numaddr = integer 2477 ttl = (POS-DIGIT *2DIGIT) / "0" 2479 FQDN = 4*(alpha-numeric / "-" / ".") 2480 ; fully qualified domain name as specified 2481 ; in RFC 1035 (and updates) 2483 IP4-address = b1 3("." decimal-uchar) 2485 b1 = decimal-uchar 2486 ; less than "224" 2488 IP6-address = 6( h16 ":" ) ls32 2489 / "::" 5( h16 ":" ) ls32 2490 / [ h16 ] "::" 4( h16 ":" ) ls32 2491 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 2492 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 2493 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 2494 / [ *4( h16 ":" ) h16 ] "::" ls32 2495 / [ *5( h16 ":" ) h16 ] "::" h16 2496 / [ *6( h16 ":" ) h16 ] "::" 2498 h16 = 1*4HEXDIG 2500 ls32 = ( h16 ":" h16 ) / IP4-address 2502 ; Generic for other address families 2503 extn-addr = non-ws-string 2505 ; generic sub-rules: datatypes 2506 text = byte-string 2507 ;default is to interpret this as UTF8 text. 2508 ;ISO 8859-1 requires "a=charset:ISO-8859-1" 2509 ;session-level attribute to be used 2511 byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) 2512 ;any byte except NUL, CR, or LF 2514 non-ws-string = 1*(VCHAR/%x80-FF) 2515 ;string of visible characters 2517 token-char = ALPHA / DIGIT 2518 / "!" / "#" / "$" / "%" / "&" 2519 / "'" ; (single quote) 2520 / "*" / "+" / "-" / "." / "^" / "_" 2521 / "`" ; (Grave accent) 2522 / "{" / "|" / "}" / "~" 2524 token = 1*(token-char) 2525 email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF 2526 ;any byte except NUL, CR, LF, or the quoting 2527 ;characters ()<> 2529 integer = POS-DIGIT *DIGIT 2531 zero-based-integer = "0" / integer 2533 non-zero-int-or-real = integer / non-zero-real 2535 non-zero-real = zero-based-integer "." *DIGIT POS-DIGIT 2537 ; generic sub-rules: primitives 2538 alpha-numeric = ALPHA / DIGIT 2540 POS-DIGIT = %x31-39 ; 1 - 9 2542 decimal-uchar = DIGIT 2543 / POS-DIGIT DIGIT 2544 / ("1" 2(DIGIT)) 2545 / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) 2546 / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) 2548 ; external references: 2549 ALPHA = 2550 DIGIT = 2551 CRLF = 2552 HEXDIG = 2553 SP = 2554 VCHAR = 2555 URI-reference = 2556 addr-spec = 2558 10. Summary of Changes from RFC 4566 2560 o Generally clarified and refined terminology. 2562 o Identified now-obsolete items: "a=cat", "a=keywds", "k=". 2564 o Updated normative and informative references, and added references 2565 to additional relevant related RFCs. 2567 o Reformatted the SDP Attributes section for readability. The 2568 syntax of attribute values is now given in ABNF. 2570 o Made mandatory the sending of RTCP with inactive media streams. 2572 o Removed the section "Private Sessions". That section dates back 2573 to a time when the primary use of SDP was with SAP (Session 2574 Announcement Protocol). That has fallen out of use. Now the vast 2575 majority of uses of SDP is for establishment of private sessions. 2576 The considerations for that are covered in Section 7. 2578 o Expanded and clarified the specification of the "lang" and 2579 "sdplang" attributes. 2581 o Removed some references to SAP because it is no longer in 2582 widespread use. 2584 o Changed the way values for UDP transport are registered. 2586 o Changed the mechanism and documentation required for registering 2587 new attributes. 2589 o Tightened up IANA registration procedures for extensions. Removed 2590 phone number and long-form name. 2592 o Expanded the IANA nettype registry to identify valid addrtypes. 2594 o Reorganized the several IANA att-type registries into a single 2595 registry 2597 o Revised ABNF syntax for clarity. Backward compatibility is 2598 maintained with a few exceptions: 2600 * Revised the syntax of time descriptions ("t=", "r=", "z=") to 2601 remove ambiguities. Clarified that "z=" only modifies the 2602 immediately preceding "r=" lines. Made "z=" without a 2603 preceding "r=" a syntax error. (This is incompatible with 2604 certain aberrant usage.) 2606 * Updated the "IP6-address" and "IP6-multicast" rules, consistent 2607 with the syntax in RFC3986. (This mirrors a bug fix made to 2608 RFC3261 by RFC5964.) Removed rules that were unused as a 2609 result of this change. 2611 o Revised normative statements that were redundant with ABNF syntax, 2612 making the text non-normative. 2614 o Revised IPv4 unicast and multicast addresses in the example SDP 2615 descriptions per RFCs 5735 and 5771. 2617 o Changed some examples to use IPv6 addresses, and added additional 2618 examples using IPv6. 2620 o Incorporated case-insensitivity rules from RFC 4855. 2622 o Revised sections that incorrectly referenced NTP. 2624 o Clarified the explanation of the impact and use of a=charset. 2626 o Revised the description of a=type to remove implication that it 2627 sometimes changes the default media direction to something other 2628 than sendrecv. 2630 11. Acknowledgements 2632 Many people in the IETF Multiparty Multimedia Session Control 2633 (MMUSIC) working group have made comments and suggestions 2634 contributing to this document. 2636 In particular, we would like to thank the following people who 2637 contributed to the creation of this document or one of its 2638 predecessor documents: Adam Roach, Allison Mankin, Bernie Hoeneisen, 2639 Bill Fenner, Carsten Bormann, Eve Schooler, Flemming Andreasen, 2640 Gonzalo Camarillo, Joerg Ott, John Elwell, Jon Peterson, Jonathan 2641 Lennox, Jonathan Rosenberg, Keith Drage, Peter Parnes, Rob Lanphier, 2642 Ross Finlayson, Sean Olson, Spencer Dawkins, Steve Casner, Steve 2643 Hanna, Van Jacobson. 2645 12. References 2647 12.1. Normative References 2649 [E164] International Telecommunication Union, "E.164 : The 2650 international public telecommunication numbering plan", 2651 ITU Recommendation E.164, November 2010. 2653 [I-D.ietf-mmusic-data-channel-sdpneg] 2654 Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. 2655 Even, "SDP-based Data Channel Negotiation", draft-ietf- 2656 mmusic-data-channel-sdpneg-28 (work in progress), May 2657 2019. 2659 [I-D.ietf-mmusic-sdp-mux-attributes] 2660 Nandakumar, S., "A Framework for SDP Attributes when 2661 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 2662 (work in progress), February 2018. 2664 [ISO.8859-1.1998] 2665 International Organization for Standardization, 2666 "Information technology - 8-bit single byte coded graphic 2667 - character sets - Part 1: Latin alphabet No. 1, JTC1/ 2668 SC2", ISO/IEC Standard 8859-1, 1998. 2670 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2671 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 2672 . 2674 [RFC1035] Mockapetris, P., "Domain names - implementation and 2675 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2676 November 1987, . 2678 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2679 Requirement Levels", BCP 14, RFC 2119, 2680 DOI 10.17487/RFC2119, March 1997, 2681 . 2683 [RFC2848] Petrack, S. and L. Conroy, "The PINT Service Protocol: 2684 Extensions to SIP and SDP for IP Access to Telephone Call 2685 Services", RFC 2848, DOI 10.17487/RFC2848, June 2000, 2686 . 2688 [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration 2689 Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978, 2690 October 2000, . 2692 [RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the 2693 Session Description Protocol (SDP) for ATM Bearer 2694 Connections", RFC 3108, DOI 10.17487/RFC3108, May 2001, 2695 . 2697 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2698 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2699 2003, . 2701 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2702 Resource Identifier (URI): Generic Syntax", STD 66, 2703 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2704 . 2706 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 2707 the Session Description Protocol (SDP)", RFC 4145, 2708 DOI 10.17487/RFC4145, September 2005, 2709 . 2711 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2712 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2713 July 2006, . 2715 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2716 Specifications: ABNF", STD 68, RFC 5234, 2717 DOI 10.17487/RFC5234, January 2008, 2718 . 2720 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2721 Media Attributes in the Session Description Protocol 2722 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 2723 . 2725 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 2726 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 2727 September 2009, . 2729 [RFC5890] Klensin, J., "Internationalized Domain Names for 2730 Applications (IDNA): Definitions and Document Framework", 2731 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2732 . 2734 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 2735 Address Text Representation", RFC 5952, 2736 DOI 10.17487/RFC5952, August 2010, 2737 . 2739 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 2740 for the Message Session Relay Protocol (MSRP)", RFC 6135, 2741 DOI 10.17487/RFC6135, February 2011, 2742 . 2744 [RFC7195] Garcia-Martin, M. and S. Veikkolainen, "Session 2745 Description Protocol (SDP) Extension for Setting Audio and 2746 Video Media Streams over Circuit-Switched Bearers in the 2747 Public Switched Telephone Network (PSTN)", RFC 7195, 2748 DOI 10.17487/RFC7195, May 2014, 2749 . 2751 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2752 Writing an IANA Considerations Section in RFCs", BCP 26, 2753 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2754 . 2756 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2757 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2758 May 2017, . 2760 12.2. Informative References 2762 [I-D.ietf-mmusic-ice-sip-sdp] 2763 Petit-Huguenin, M., Nandakumar, S., Keranen, A., Shpount, 2764 R., and C. Holmberg, "Session Description Protocol (SDP) 2765 Offer/Answer procedures for Interactive Connectivity 2766 Establishment (ICE)", draft-ietf-mmusic-ice-sip-sdp-38 2767 (work in progress), August 2019. 2769 [I-D.ietf-mmusic-sdp-bundle-negotiation] 2770 Holmberg, C., Alvestrand, H., and C. Jennings, 2771 "Negotiating Media Multiplexing Using the Session 2772 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 2773 negotiation-54 (work in progress), December 2018. 2775 [ITU.H332.1998] 2776 International Telecommunication Union, "H.323 extended for 2777 loosely coupled conferences", ITU Recommendation H.332, 2778 September 1998. 2780 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2781 Extensions (MIME) Part One: Format of Internet Message 2782 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 2783 . 2785 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 2786 Protocol", RFC 2327, DOI 10.17487/RFC2327, April 1998, 2787 . 2789 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 2790 Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, 2791 October 2000, . 2793 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2794 A., Peterson, J., Sparks, R., Handley, M., and E. 2795 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2796 DOI 10.17487/RFC3261, June 2002, 2797 . 2799 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2800 with Session Description Protocol (SDP)", RFC 3264, 2801 DOI 10.17487/RFC3264, June 2002, 2802 . 2804 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2805 Jacobson, "RTP: A Transport Protocol for Real-Time 2806 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2807 July 2003, . 2809 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 2810 Video Conferences with Minimal Control", STD 65, RFC 3551, 2811 DOI 10.17487/RFC3551, July 2003, 2812 . 2814 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 2815 Modifiers for RTP Control Protocol (RTCP) Bandwidth", 2816 RFC 3556, DOI 10.17487/RFC3556, July 2003, 2817 . 2819 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2820 in Session Description Protocol (SDP)", RFC 3605, 2821 DOI 10.17487/RFC3605, October 2003, 2822 . 2824 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2825 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2826 RFC 3711, DOI 10.17487/RFC3711, March 2004, 2827 . 2829 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 2830 "Indicating User Agent Capabilities in the Session 2831 Initiation Protocol (SIP)", RFC 3840, 2832 DOI 10.17487/RFC3840, August 2004, 2833 . 2835 [RFC3890] Westerlund, M., "A Transport Independent Bandwidth 2836 Modifier for the Session Description Protocol (SDP)", 2837 RFC 3890, DOI 10.17487/RFC3890, September 2004, 2838 . 2840 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 2841 Description Protocol (SDP) Security Descriptions for Media 2842 Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, 2843 . 2845 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 2846 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 2847 . 2849 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 2850 DOI 10.17487/RFC5322, October 2008, 2851 . 2853 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2854 Protocol (SDP) Grouping Framework", RFC 5888, 2855 DOI 10.17487/RFC5888, June 2010, 2856 . 2858 [RFC6466] Salgueiro, G., "IANA Registration of the 'image' Media 2859 Type for the Session Description Protocol (SDP)", 2860 RFC 6466, DOI 10.17487/RFC6466, December 2011, 2861 . 2863 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2864 Specifications and Registration Procedures", BCP 13, 2865 RFC 6838, DOI 10.17487/RFC6838, January 2013, 2866 . 2868 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2869 Protocol (HTTP/1.1): Message Syntax and Routing", 2870 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2871 . 2873 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 2874 RFC 7405, DOI 10.17487/RFC7405, December 2014, 2875 . 2877 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 2878 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 2879 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 2880 DOI 10.17487/RFC7656, November 2015, 2881 . 2883 [RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 2884 and M. Stiemerling, Ed., "Real-Time Streaming Protocol 2885 Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December 2886 2016, . 2888 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 2889 Connectivity Establishment (ICE): A Protocol for Network 2890 Address Translator (NAT) Traversal", RFC 8445, 2891 DOI 10.17487/RFC8445, July 2018, 2892 . 2894 Authors' Addresses 2896 Ali Begen 2897 Networked Media 2898 Konya 2899 Turkey 2901 EMail: ali.begen@networked.media 2902 Paul Kyzivat 2903 USA 2905 EMail: pkyzivat@alum.mit.edu 2907 Colin Perkins 2908 University of Glasgow 2909 School of Computing Science 2910 University of Glasgow 2911 Glasgow G12 8QQ 2912 UK 2914 EMail: csp@csperkins.org 2916 Mark Handley 2917 University College London 2918 Department of Computer Science 2919 London WC1E 6BT 2920 UK 2922 EMail: M.Handley@cs.ucl.ac.uk