idnits 2.17.1 draft-ietf-mmusic-rfc4566bis-31.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 (December 17, 2018) is 1929 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 2199, but not defined == Missing Reference: 'RFC2848' is mentioned on line 2200, but not defined == Missing Reference: 'RFC3108' is mentioned on line 2205, but not defined == Missing Reference: 'RFC7195' is mentioned on line 2206, but not defined == Missing Reference: 'RFC4145' is mentioned on line 2235, but not defined == Missing Reference: 'RFC6135' is mentioned on line 2236, but not defined == Unused Reference: 'RFC2978' is defined on line 2568, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'E164' == Outdated reference: A later version (-28) exists of draft-ietf-mmusic-data-channel-sdpneg-22 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-17 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-39) exists of draft-ietf-mmusic-ice-sip-sdp-24 -- Obsolete informational reference (is this intentional?): RFC 2327 (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Begen 3 Internet-Draft Networked Media 4 Obsoletes: 4566 (if approved) P. Kyzivat 5 Intended status: Standards Track 6 Expires: June 20, 2019 C. Perkins 7 University of Glasgow 8 M. Handley 9 UCL 10 December 17, 2018 12 SDP: Session Description Protocol 13 draft-ietf-mmusic-rfc4566bis-31 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 June 20, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . . 5 71 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 5 72 3.2. Streaming Media . . . . . . . . . . . . . . . . . . . . . 5 73 3.3. Email and the World Wide Web . . . . . . . . . . . . . . 5 74 3.4. Multicast Session Announcement . . . . . . . . . . . . . 5 75 4. Requirements and Recommendations . . . . . . . . . . . . . . 6 76 4.1. Media and Transport Information . . . . . . . . . . . . . 7 77 4.2. Timing Information . . . . . . . . . . . . . . . . . . . 7 78 4.3. Obtaining Further Information about a Session . . . . . . 8 79 4.4. Categorization . . . . . . . . . . . . . . . . . . . . . 8 80 4.5. Internationalization . . . . . . . . . . . . . . . . . . 8 81 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . . 8 82 5.1. Protocol Version ("v=") . . . . . . . . . . . . . . . . . 12 83 5.2. Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 12 84 5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 13 85 5.4. Session Information ("i=") . . . . . . . . . . . . . . . 13 86 5.5. URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . 14 87 5.6. Email Address and Phone Number ("e=" and "p=") . . . . . 14 88 5.7. Connection Information ("c=") . . . . . . . . . . . . . . 15 89 5.8. Bandwidth Information ("b=") . . . . . . . . . . . . . . 17 90 5.9. Time Active ("t=") . . . . . . . . . . . . . . . . . . . 18 91 5.10. Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . 19 92 5.11. Time Zone Adjustment ("z=") . . . . . . . . . . . . . . . 20 93 5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 21 94 5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 21 95 5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 22 96 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 25 97 6.1. cat (category) . . . . . . . . . . . . . . . . . . . . . 25 98 6.2. keywds (keywords) . . . . . . . . . . . . . . . . . . . . 26 99 6.3. tool . . . . . . . . . . . . . . . . . . . . . . . . . . 26 100 6.4. ptime (packet time) . . . . . . . . . . . . . . . . . . . 27 101 6.5. maxptime (maximum packet time) . . . . . . . . . . . . . 27 102 6.6. rtpmap . . . . . . . . . . . . . . . . . . . . . . . . . 28 103 6.7. Media Direction Attributes . . . . . . . . . . . . . . . 29 104 6.7.1. recvonly (receive-only) . . . . . . . . . . . . . . . 30 105 6.7.2. sendrecv (send-receive) . . . . . . . . . . . . . . . 30 106 6.7.3. sendonly (send-only) . . . . . . . . . . . . . . . . 31 107 6.7.4. inactive . . . . . . . . . . . . . . . . . . . . . . 31 108 6.8. orient (orientation) . . . . . . . . . . . . . . . . . . 32 109 6.9. type (conference type) . . . . . . . . . . . . . . . . . 32 110 6.10. charset (character set) . . . . . . . . . . . . . . . . . 33 111 6.11. sdplang (SDP language) . . . . . . . . . . . . . . . . . 34 112 6.12. lang (language) . . . . . . . . . . . . . . . . . . . . . 35 113 6.13. framerate (frame rate) . . . . . . . . . . . . . . . . . 36 114 6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 37 115 6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 37 116 7. Security Considerations . . . . . . . . . . . . . . . . . . . 38 117 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 118 8.1. The "application/sdp" Media Type . . . . . . . . . . . . 40 119 8.2. Registration of Parameters . . . . . . . . . . . . . . . 41 120 8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 41 121 8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 42 122 8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 42 123 8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 43 124 8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 45 125 8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 46 126 8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 46 127 8.2.8. Registration Procedure . . . . . . . . . . . . . . . 46 128 8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 47 129 8.4. Reorganization of the nettype Registry . . . . . . . . . 47 130 8.5. Reorganization of the att-field Registries . . . . . . . 48 131 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 48 132 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 54 133 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54 134 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 135 12.1. Normative References . . . . . . . . . . . . . . . . . . 54 136 12.2. Informative References . . . . . . . . . . . . . . . . . 56 137 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 139 1. Introduction 141 When initiating multimedia teleconferences, voice-over-IP calls, 142 streaming video, or other sessions, there is a requirement to convey 143 media details, transport addresses, and other session description 144 metadata to the participants. 146 SDP provides a standard representation for such information, 147 irrespective of how that information is transported. SDP is purely a 148 format for session description -- it does not incorporate a transport 149 protocol, and it is intended to use different transport protocols as 150 appropriate, including the Session Announcement Protocol (SAP) 151 [RFC2974], Session Initiation Protocol (SIP) [RFC3261], Real Time 152 Streaming Protocol (RTSP) [RFC7826], electronic mail using the MIME 153 extensions [RFC5322], and the Hypertext Transport Protocol (HTTP) 154 [RFC7230]. 156 SDP is intended to be general purpose so that it can be used in a 157 wide range of network environments and applications. However, it is 158 not intended to support negotiation of session content or media 159 encodings: this is viewed as outside the scope of session 160 description. 162 This memo obsoletes [RFC4566]. The changes relative to [RFC4566] are 163 limited to essential corrections, and are outlined in Section 10 of 164 this memo. 166 2. Glossary of Terms 168 The following terms are used in this document and have specific 169 meaning within the context of this document. 171 Session Description: A well-defined format for conveying sufficient 172 information to discover and participate in a multimedia session. 174 Media Description: A media description starts with an "m=" line and 175 is terminated by either the next "m=" line or by the end of the 176 session description. 178 Session-level Section: This refers to the parts that are not media 179 descriptions, whereas the session description refers to the whole 180 body that includes the session-level section and the media 181 description(s). 183 The terms "multimedia conference" and "multimedia session" are used 184 in this document as defined in [RFC7656]. The terms "session" and 185 "multimedia session" are used interchangeably in this document. 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 189 "OPTIONAL" in this document are to be interpreted as described in BCP 190 14 [RFC2119] [RFC8174] when, and only when, they appear in all 191 capitals, as shown here. 193 3. Examples of SDP Usage 195 3.1. Session Initiation 197 The Session Initiation Protocol (SIP) [RFC3261] is an application- 198 layer control protocol for creating, modifying, and terminating 199 sessions such as Internet multimedia conferences, Internet telephone 200 calls, and multimedia distribution. The SIP messages used to create 201 sessions carry session descriptions that allow participants to agree 202 on a set of compatible media types. These session descriptions are 203 commonly formatted using SDP. When used with SIP, the offer/answer 204 model [RFC3264] provides a limited framework for negotiation using 205 SDP. 207 3.2. Streaming Media 209 The Real Time Streaming Protocol (RTSP) [RFC7826], is an application- 210 level protocol for control over the delivery of data with real-time 211 properties. RTSP provides an extensible framework to enable 212 controlled, on-demand delivery of real-time data, such as audio and 213 video. An RTSP client and server negotiate an appropriate set of 214 parameters for media delivery, partially using SDP syntax to describe 215 those parameters. 217 3.3. Email and the World Wide Web 219 Alternative means of conveying session descriptions include 220 electronic mail and the World Wide Web (WWW). For both email and WWW 221 distribution, the media type "application/sdp" is used. This enables 222 the automatic launching of applications for participation in the 223 session from the WWW client or mail reader in a standard manner. 225 Note that descriptions of multicast sessions made only via email or 226 the WWW do not have the property that the receiver of a session 227 description can necessarily receive the session because the multicast 228 sessions may be restricted in scope, and access to the WWW server or 229 reception of email is possible outside this scope. 231 3.4. Multicast Session Announcement 233 In order to assist the advertisement of multicast multimedia 234 conferences and other multicast sessions, and to communicate the 235 relevant session setup information to prospective participants, a 236 distributed session directory may be used. An instance of such a 237 session directory periodically sends packets containing a description 238 of the session to a well-known multicast group. These advertisements 239 are received by other session directories such that potential remote 240 participants can use the session description to start the tools 241 required to participate in the session. 243 One protocol used to implement such a distributed directory is the 244 SAP [RFC2974]. SDP provides the recommended session description 245 format for such session announcements. 247 4. Requirements and Recommendations 249 The purpose of SDP is to convey information about media streams in 250 multimedia sessions to allow the recipients of a session description 251 to participate in the session. SDP is primarily intended for use in 252 an internetwork, although it is sufficiently general that it can 253 describe multimedia conferences in other network environments. Media 254 streams can be many-to-many. Sessions need not be continually 255 active. 257 Thus far, multicast-based sessions on the Internet have differed from 258 many other forms of conferencing in that anyone receiving the traffic 259 can join the session (unless the session traffic is encrypted). In 260 such an environment, SDP serves two primary purposes. It is a means 261 to communicate the existence of a session, and it is a means to 262 convey sufficient information to enable joining and participating in 263 the session. In a unicast environment, only the latter purpose is 264 likely to be relevant. 266 An SDP description includes the following: 268 o Session name and purpose 270 o Time(s) the session is active 272 o The media comprising the session 274 o Information needed to receive those media (addresses, ports, 275 formats, etc.) 277 As resources necessary to participate in a session may be limited, 278 some additional information may also be desirable: 280 o Information about the bandwidth to be used by the session 282 o Contact information for the person responsible for the session 284 In general, SDP must convey sufficient information to enable 285 applications to join a session (with the possible exception of 286 encryption keys) and to announce the resources to be used to any non- 287 participants that may need to know. (This latter feature is 288 primarily useful when SDP is used with a multicast session 289 announcement protocol.) 291 4.1. Media and Transport Information 293 An SDP description includes the following media information: 295 o The type of media (video, audio, etc.) 297 o The media transport protocol (RTP/UDP/IP, H.320, etc.) 299 o The format of the media (H.261 video, MPEG video, etc.) 301 In addition to media format and transport protocol, SDP conveys 302 address and port details. For an IP multicast session, these 303 comprise: 305 o The multicast group address for media 307 o The transport port for media 309 This address and port is the destination address and destination port 310 of the multicast stream, whether being sent, received, or both. 312 For unicast IP sessions, the following are conveyed: 314 o The remote address for media 316 o The remote transport port for media 318 The semantics of this address and port depend on the media and 319 transport protocol defined. By default, this SHOULD be the remote 320 address and remote port to which media is sent. Some media types may 321 redefine this behavior, but this is NOT RECOMMENDED since it 322 complicates implementations (including middleboxes that must parse 323 the addresses to open Network Address Translation (NAT) or firewall 324 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 334 o For each bound, repeat times such as "every Wednesday at 10am for 335 one hour" 337 This timing information is globally consistent, irrespective of local 338 time zone or daylight saving time (see Section 5.9). 340 4.3. Obtaining Further Information about a Session 342 A session description could convey enough information to decide 343 whether or not to participate in a session. SDP may include 344 additional pointers in the form of Uniform Resource Identifiers 345 (URIs) for more information about the session. 347 4.4. Categorization 349 When many session descriptions are being distributed by an 350 advertisement mechanism, it may be desirable to filter session 351 descriptions that are of interest from those that are not. SDP 352 supports a categorization mechanism for sessions that is capable of 353 being automated (the "a=cat:" attribute; see Section 6). 355 4.5. Internationalization 357 The SDP specification recommends the use of the ISO 10646 character 358 set in the UTF-8 encoding [RFC3629] to allow many different languages 359 to be represented. However, to assist in compact representations, 360 SDP also allows other character sets such as ISO 8859-1 to be used 361 when desired. Internationalization only applies to free-text sub- 362 fields (session name and background information), and not to SDP as a 363 whole. 365 5. SDP Specification 367 An SDP description is denoted by the media type "application/sdp" 368 (See Section 8). 370 An SDP description is entirely textual. SDP field names and 371 attribute names use only the US-ASCII subset of UTF-8, but textual 372 fields and attribute values MAY use the full ISO 10646 character set 373 in UTF-8 encoding, or some other character set defined by the 374 "a=charset:" attribute. Field and attribute values that use the full 375 UTF-8 character set are never directly compared, hence there is no 376 requirement for UTF-8 normalization. The textual form, as opposed to 377 a binary encoding such as ASN.1 or XDR, was chosen to enhance 378 portability, to enable a variety of transports to be used, and to 379 allow flexible, text-based toolkits to be used to generate and 380 process session descriptions. However, since SDP may be used in 381 environments where the maximum permissible size of a session 382 description is limited, the encoding is deliberately compact. Also, 383 since descriptions may be transported via very unreliable means or 384 damaged by an intermediate caching server, the encoding was designed 385 with strict order and formatting rules so that most errors would 386 result in malformed session descriptions that could be detected 387 easily and discarded. This also allows rapid discarding of encrypted 388 session descriptions for which a receiver does not have the correct 389 key. 391 An SDP description consists of a number of lines of text of the form: 393 = 395 where MUST be exactly one case-significant character and 396 is structured text whose format depends on . In 397 general, is either a number of sub-fields delimited by a 398 single space character or a free format string, and is case- 399 significant unless a specific field defines otherwise. Whitespace 400 separators MUST NOT be used on either side of the "=" sign, however, 401 the value can contain a leading whitespace as part of its syntax, 402 i.e., that whitespace is part of the value. 404 An SDP description consists of a session-level section followed by 405 zero or more media descriptions. The session-level section starts 406 with a "v=" line and continues to the first media description (or the 407 end of the whole description, whichever comes first). Each media 408 description starts with an "m=" line and continues to the next media 409 description or the end of the whole session description - whichever 410 comes first. In general, session-level values are the default for 411 all media unless overridden by an equivalent media-level value. 413 Some lines in each description are REQUIRED and some are OPTIONAL, 414 but all MUST appear in exactly the order given here (the fixed order 415 greatly enhances error detection and allows for a simple parser). In 416 the following overview OPTIONAL items are marked with a "*". (For 417 details, see the formal grammar in Section 9.) 418 Session description 419 v= (protocol version) 420 o= (originator and session identifier) 421 s= (session name) 422 i=* (session information) 423 u=* (URI of description) 424 e=* (email address) 425 p=* (phone number) 426 c=* (connection information -- not required if included in 427 all media descriptions) 428 b=* (zero or more bandwidth information lines) 429 One or more time descriptions: 430 ("t=", "r=" and "z=" lines; see below) 431 k=* (encryption key) 432 a=* (zero or more session attribute lines) 433 Zero or more media descriptions 435 Time description 436 t= (time the session is active) 437 r=* (zero or more repeat times) 438 z=* (optional time zone offset line) 440 Media description, if present 441 m= (media name and transport address) 442 i=* (media title) 443 c=* (connection information -- optional if included at 444 session level) 445 b=* (zero or more bandwidth information lines) 446 k=* (encryption key) 447 a=* (zero or more media attribute lines) 449 The set of type letters is deliberately small and not intended to be 450 extensible -- an SDP parser MUST completely ignore any session 451 description that contains a type letter that it does not understand. 452 The attribute mechanism ("a=" described below) is the primary means 453 for extending SDP and tailoring it to particular applications or 454 media. Some attributes (the ones listed in Section 6 of this memo) 455 have a defined meaning, but others may be added on a media-, or 456 session-specific basis. (Attribute scopes in addition to media- and 457 session- specific may also be defined in extensions to this document. 458 E.g., [RFC5576], [I-D.ietf-mmusic-data-channel-sdpneg].) An SDP 459 parser MUST ignore any attribute it doesn't understand. 461 An SDP description may contain URIs that reference external content 462 in the "u=", "k=", and "a=" lines. These URIs may be dereferenced in 463 some cases, making the session description non-self-contained. 465 The connection ("c=") information in the session-level section 466 applies to all the media descriptions of that session unless 467 overridden by connection information in the media description. For 468 instance, in the example below, each audio media description behaves 469 as if it were given a "c=IN IP4 233.252.0.2". 471 An example SDP description is: 473 v=0 474 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 475 s=SDP Seminar 476 i=A Seminar on the session description protocol 477 u=http://www.example.com/seminars/sdp.pdf 478 e=j.doe@example.com (Jane Doe) 479 c=IN IP4 233.252.0.2 480 t=2873397496 2873404696 481 a=recvonly 482 m=audio 49170 RTP/AVP 0 483 m=audio 49180 RTP/AVP 0 484 m=video 51372 RTP/AVP 99 485 c=IN IP4 233.252.0.1/127 486 a=rtpmap:99 h263-1998/90000 488 Text containing fields such as the session-name-field and 489 information-field are octet strings that may contain any octet with 490 the exceptions of 0x00 (Nul), 0x0a (ASCII newline), and 0x0d (ASCII 491 carriage return). The sequence CRLF (0x0d0a) is used to end a line, 492 although parsers SHOULD be tolerant and also accept lines terminated 493 with a single newline character. If the "a=charset" attribute is not 494 present, these octet strings MUST be interpreted as containing 495 ISO-10646 characters in UTF-8 encoding (the presence of the 496 "a=charset" attribute may force some fields to be interpreted 497 differently). 499 A session description can contain domain names in the "o=", "u=", 500 "e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply 501 with [RFC1034], [RFC1035]. Internationalized domain names (IDNs) 502 MUST be represented using the ASCII Compatible Encoding (ACE) form 503 defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or 504 any other encoding (this requirement is for compatibility with 505 [RFC2327] and other early SDP-related standards, which predate the 506 development of internationalized domain names). 508 5.1. Protocol Version ("v=") 510 v=0 512 The "v=" line (version-field) gives the version of the Session 513 Description Protocol. This memo defines version 0. There is no 514 minor version number. 516 5.2. Origin ("o=") 518 o= 519 521 The "o=" line (origin-field) gives the originator of the session (her 522 username and the address of the user's host) plus a session 523 identifier and version number: 525 is the user's login on the originating host, or it is "-" 526 if the originating host does not support the concept of user IDs. 527 The MUST NOT contain spaces. 529 is a numeric string such that the tuple of , 530 , , , and forms a 531 globally unique identifier for the session. The method of allocation is up to the creating tool, but it has been 533 suggested that a Network Time Protocol (NTP) format timestamp be 534 used to ensure uniqueness [RFC5905]. 536 is a version number for this session description. 537 Its usage is up to the creating tool, so long as is 538 increased when a modification is made to the session description. 539 Again, it is RECOMMENDED that an NTP format timestamp is used. 541 is a text string giving the type of network. Initially 542 "IN" is defined to have the meaning "Internet", but other values 543 MAY be registered in the future (see Section 8). 545 is a text string giving the type of the address that 546 follows. Initially "IP4" and "IP6" are defined, but other values 547 MAY be registered in the future (see Section 8). 549 is an address of the machine from which the 550 session was created. For an address type of IP4, this is either a 551 fully qualified domain name of the machine or the dotted-decimal 552 representation of an IP version 4 address of the machine. For an 553 address type of IP6, this is either a fully qualified domain name 554 of the machine or the compressed textual representation of an IP 555 version 6 address of the machine. For both IP4 and IP6, the fully 556 qualified domain name is the form that SHOULD be given unless this 557 is unavailable, in which case a globally unique address MAY be 558 substituted. Unless an SDP extension for NAT traversal is used 559 (e.g., ICE [RFC8445], ICE TCP [RFC6544]), a local IP address MUST 560 NOT be used in any context where the SDP description might leave 561 the scope in which the address is meaningful (for example, a local 562 address MUST NOT be included in an application-level referral that 563 might leave the scope). 565 In general, the "o=" line serves as a globally unique identifier for 566 this version of the session description, and the sub-fields excepting 567 the version, taken together identify the session irrespective of any 568 modifications. 570 For privacy reasons, it is sometimes desirable to obfuscate the 571 username and IP address of the session originator. If this is a 572 concern, an arbitrary and private MAY be 573 chosen to populate the "o=" line, provided that these are selected in 574 a manner that does not affect the global uniqueness of the field. 576 5.3. Session Name ("s=") 578 s= 580 The "s=" line (session-name-field) is the textual session name. 581 There MUST be one and only one "s=" line per session description. 582 The "s=" line MUST NOT be empty and SHOULD contain ISO 10646 583 characters (but see also the "a=charset" attribute). If a session 584 has no meaningful name, the "s= " line SHOULD be used (i.e., a single 585 space as the session name). 587 5.4. Session Information ("i=") 589 i= 591 The "i=" line (information-field) provides textual information about 592 the session. There MUST be at most one session-level "i=" line per 593 session description, and at most one "i=" line in each media 594 description. Unless a media level "i=" line is provided, the 595 session-level "i=" line applies to that media description. If the 596 "a=charset" attribute is present, it specifies the character set used 597 in the "i=" line. If the "a=charset" attribute is not present, the 598 "i=" line MUST contain ISO 10646 characters in UTF-8 encoding. 600 At most one "i=" line can be used for each media description. In 601 media definitions, "i=" lines are primarily intended for labelling 602 media streams. As such, they are most likely to be useful when a 603 single session has more than one distinct media stream of the same 604 media type. An example would be two different whiteboards, one for 605 slides and one for feedback and questions. 607 The "i=" line is intended to provide a free-form human-readable 608 description of the session or the purpose of a media stream. It is 609 not suitable for parsing by automata. 611 5.5. URI ("u=") 613 u= 615 The "u=" line (uri-field) provides URI (Uniform Resource Identifier) 616 as used by WWW clients [RFC3986]. The URI should be a pointer to 617 additional information about the session. This line is OPTIONAL. No 618 more than one "u=" line is allowed per session description. 620 5.6. Email Address and Phone Number ("e=" and "p=") 622 e= 623 p= 625 The "e=" line (email-field) and "p=" line (phone-field) specify 626 contact information for the person responsible for the session. This 627 is not necessarily the same person that created the session 628 description. 630 Inclusion of an email address or phone number is OPTIONAL. 632 If an email address or phone number is present, it MUST be specified 633 before the first media description. More than one email or phone 634 line can be given for a session description. 636 Phone numbers SHOULD be given in the form of an international public 637 telecommunication number (see ITU-T Recommendation E.164 [E164]) 638 preceded by a "+". Spaces and hyphens may be used to split up a 639 phone-field to aid readability if desired. For example: 641 p=+1 617 555-6011 643 Both email addresses and phone numbers can have an OPTIONAL free text 644 string associated with them, normally giving the name of the person 645 who may be contacted. This MUST be enclosed in parentheses if it is 646 present. For example: 648 e=j.doe@example.com (Jane Doe) 650 The alternative [RFC5322] name quoting convention is also allowed for 651 both email addresses and phone numbers. For example: 653 e=Jane Doe 655 The free text string SHOULD be in the ISO-10646 character set with 656 UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if 657 the appropriate session-level "a=charset" attribute is set. 659 5.7. Connection Information ("c=") 661 c= 663 The "c=" line (connection-field) contains connection data. 665 A session description MUST contain either at least one "c=" line in 666 each media description or a single "c=" line at the session level. 667 It MAY contain a single session-level "c=" line and additional "c=" 668 line(s) per media description, in which case the per-media values 669 override the session-level settings for the respective media. 671 The first sub-field ("") is the network type, which is a 672 text string giving the type of network. Initially, "IN" is defined 673 to have the meaning "Internet", but other values MAY be registered in 674 the future (see Section 8). 676 The second sub-field ("") is the address type. This allows 677 SDP to be used for sessions that are not IP based. This memo only 678 defines IP4 and IP6, but other values MAY be registered in the future 679 (see Section 8). 681 The third sub-field ("") is the connection 682 address. Additional sub-fields MAY be added after the connection 683 address depending on the value of the sub-field. 685 When the is IP4 or IP6, the connection address is defined 686 as follows: 688 o If the session is multicast, the connection address will be an IP 689 multicast group address. If the session is not multicast, then 690 the connection address contains the unicast IP address of the 691 expected data source, data relay or data sink as determined by 692 additional attribute-fields. It is not expected that unicast 693 addresses will be given in a session description that is 694 communicated by a multicast announcement, though this is not 695 prohibited. 697 o Sessions using an IP4 multicast connection address MUST also have 698 a time to live (TTL) value present in addition to the multicast 699 address. The TTL and the address together define the scope with 700 which multicast packets sent in this session will be sent. TTL 701 values MUST be in the range 0-255. Although the TTL MUST be 702 specified, its use to scope multicast traffic is deprecated; 703 applications SHOULD use an administratively scoped address 704 instead. 706 The TTL for the session is appended to the address using a slash as a 707 separator. An example is: 709 c=IN IP4 233.252.0.1/127 711 IP6 multicast does not use TTL scoping, and hence the TTL value MUST 712 NOT be present for IP6 multicast. It is expected that IP6 scoped 713 addresses will be used to limit the scope of multimedia conferences. 715 Hierarchical or layered encoding schemes are data streams where the 716 encoding from a single media source is split into a number of layers. 717 The receiver can choose the desired quality (and hence bandwidth) by 718 only subscribing to a subset of these layers. Such layered encodings 719 are normally transmitted in multiple multicast groups to allow 720 multicast pruning. This technique keeps unwanted traffic from sites 721 only requiring certain levels of the hierarchy. For applications 722 requiring multiple multicast groups, we allow the following notation 723 to be used for the connection address: 725 [/]/ 727 If the number of addresses is not given, it is assumed to be one. 728 Multicast addresses so assigned are contiguously allocated above the 729 base address, so that, for example: 731 c=IN IP4 233.252.0.1/127/3 733 would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3 734 are to be used with a TTL of 127. This is semantically identical to 735 including multiple "c=" lines in a media description: 737 c=IN IP4 233.252.0.1/127 738 c=IN IP4 233.252.0.2/127 739 c=IN IP4 233.252.0.3/127 741 Similarly, an IP6 example would be: 743 c=IN IP6 FF15::101/3 745 which is semantically equivalent to: 747 c=IN IP6 FF15::101 748 c=IN IP6 FF15::102 749 c=IN IP6 FF15::103 751 (remembering that the TTL sub-field is not present in IP6 multicast). 753 Multiple addresses or "c=" lines MAY be specified on a per media 754 description basis only if they provide multicast addresses for 755 different layers in a hierarchical or layered encoding scheme. They 756 MUST NOT be specified for a session-level "c=" line. 758 The slash notation for multiple addresses described above MUST NOT be 759 used for IP unicast addresses. 761 5.8. Bandwidth Information ("b=") 763 b=: 765 The OPTIONAL "b=" line (bandwidth-field) denotes the proposed 766 bandwidth to be used by the session or media description. The 767 is an alphanumeric modifier giving the meaning of the 768 figure. Two values are defined in this specification, 769 but other values MAY be registered in the future (see Section 8 and 770 [RFC3556], [RFC3890]): 772 CT If the bandwidth of a session is different from the bandwidth 773 implicit from the scope, a "b=CT:..." line SHOULD be supplied for 774 the session giving the proposed upper limit to the bandwidth used 775 (the "conference total" bandwidth). Similarly, if the bandwidth 776 of bundled media streams in an "m=" line is different from the 777 implicit value from the scope, a "b=CT:..." line SHOULD be 778 supplied in the media level. The primary purpose of this is to 779 give an approximate idea as to whether two or more sessions (or 780 bundled media streams) can coexist simultaneously. Note that CT 781 gives a total bandwidth figure for all the media at all endpoints. 783 AS The bandwidth is interpreted to be application specific (it will 784 be the application's concept of maximum bandwidth). Normally, 785 this will coincide with what is set on the application's "maximum 786 bandwidth" control if applicable. For RTP-based applications, AS 787 gives the RTP "session bandwidth" as defined in Section 6.2 of 788 [RFC3550]. Note that AS gives a bandwidth figure for a single 789 media at a single endpoint, although there may be many endpoints 790 sending simultaneously. 792 A prefix "X-" is defined for names. This is intended for 793 experimental purposes only. For example: 795 b=X-YZ:128 797 Use of the "X-" prefix is NOT RECOMMENDED: instead new (non "X-" 798 prefix) names SHOULD be defined, and then MUST be registered 799 with IANA in the standard namespace. SDP parsers MUST ignore 800 bandwidth-fields with unknown names. The names 801 MUST be alphanumeric and, although no length limit is given, it is 802 recommended that they be short. 804 The is interpreted as kilobits per second by default 805 (including the transport and network-layer but not the link-layer 806 overhead). The definition of a new modifier MAY specify 807 that the bandwidth is to be interpreted in some alternative unit (the 808 "CT" and "AS" modifiers defined in this memo use the default units). 810 5.9. Time Active ("t=") 812 t= 814 A "t=" line (time-field) initiates a time description that specifies 815 the start and stop times for a session. Multiple time descriptions 816 MAY be used if a session is active at multiple irregularly spaced 817 times; each additional time description specifies additional periods 818 of time for which the session will be active. If the session is 819 active at regular repeat times, a repeat description, initiated by an 820 "r=" line (see below) can be included following the time-field -- in 821 which case the time-field specifies the start and stop times of the 822 entire repeat sequence. 824 The following example specifies two active intervals: 826 t=3724394400 3724398000 ; Mon 8-Jan-2018 10:00-11:00 UTC 827 t=3724484400 3724488000 ; Tue 9-Jan-2018 11:00-12:00 UTC 829 The first and second sub-fields of the time-field give the start and 830 stop times, respectively, for the session. These values are the 831 decimal representation of Network Time Protocol (NTP) time values in 832 seconds since 1900 [RFC5905]. To convert these values to UNIX time 833 (UTC), subtract decimal 2208988800. 835 NTP timestamps are elsewhere represented by 64-bit values, which wrap 836 sometime in the year 2036. Since SDP uses an arbitrary length 837 decimal representation, this should not cause an issue (SDP 838 timestamps MUST continue counting seconds since 1900 - NTP will use 839 the value modulo the 64-bit limit). 841 If the is set to zero, then the session is not bounded, 842 though it will not become active until after the . If 843 the is also zero, the session is regarded as permanent. 845 User interfaces SHOULD strongly discourage the creation of unbounded 846 and permanent sessions as they give no information about when the 847 session is actually going to terminate, and so make scheduling 848 difficult. 850 The general assumption may be made, when displaying unbounded 851 sessions that have not timed out to the user, that an unbounded 852 session will only be active until half an hour from the current time 853 or the session start time, whichever is the later. If behavior other 854 than this is required, an end-time SHOULD be given and modified as 855 appropriate when new information becomes available about when the 856 session should really end. 858 Permanent sessions may be shown to the user as never being active 859 unless there are associated repeat times that state precisely when 860 the session will be active. 862 5.10. Repeat Times ("r=") 864 r= 866 An"r=" line (repeat-field) specifies repeat times for a session. If 867 needed to express complex schedules, multiple repeat-fields may be 868 included. For example, if a session is active at 10am on Monday and 869 11am on Tuesday for one hour each week for three months, then the 870 in the corresponding "t=" line would be the NTP 871 representation of 10am on the first Monday, the 872 would be 1 week, the would be 1 hour, and the 873 offsets would be zero and 25 hours. The corresponding "t=" line stop 874 time would be the NTP representation of the end of the last session 875 three months later. By default, all sub-fields are in seconds, so 876 the "r=" and "t=" lines might be the following: 878 t=3724394400 3730536000 ; Mon 8-Jan-2018 10:00-11:00 UTC 879 ; Tues 20-Mar-2018 12:00 UTC 880 r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours 882 To make the description more compact, times may also be given in 883 units of days, hours, or minutes. The syntax for these is a number 884 immediately followed by a single case-sensitive character. 885 Fractional units are not allowed -- a smaller unit should be used 886 instead. The following unit specification characters are allowed: 888 d - days (86400 seconds) 889 h - hours (3600 seconds) 890 m - minutes (60 seconds) 891 s - seconds (allowed for completeness) 893 Thus, the above repeat-field could also have been written: 895 r=7d 1h 0 25h 897 Monthly and yearly repeats cannot be directly specified with a single 898 SDP repeat time; instead, separate time-descriptions should be used 899 to explicitly list the session times. 901 5.11. Time Zone Adjustment ("z=") 903 z= .... 905 A "z=" line (zone-field) is an optional modifier to the repeat-fields 906 it immediately follows. It does not apply to any other fields. 908 To schedule a repeated session that spans a change from daylight 909 saving time to standard time or vice versa, it is necessary to 910 specify offsets from the base time. This is required because 911 different time zones change time at different times of day, different 912 countries change to or from daylight saving time on different dates, 913 and some countries do not have daylight saving time at all. 915 Thus, in order to schedule a session that is at the same time winter 916 and summer, it must be possible to specify unambiguously by whose 917 time zone a session is scheduled. To simplify this task for 918 receivers, we allow the sender to specify the NTP time that a time 919 zone adjustment happens and the offset from the time when the session 920 was first scheduled. The "z=" line allows the sender to specify a 921 list of these adjustment times and offsets from the base time. 923 An example might be the following: 925 t=3724394400 3754123200 ; Mon 8-Jan-2018 10:00 UTC 926 ; Tues 18-Dec-2018 12:00 UTC 927 r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours 928 z=3730928400 -1h 3749680800 0 ; Sun 25-Mar-2018 1:00 UTC, 929 ; offset 1 hour, 930 ; Sun 28-Oct-2018 2:00 UTC, no offset 932 This specifies that at time 3730928400 (Sun 25-Mar-2018 1:00 UTC, the 933 onset of British Summer Time) the time base by which the session's 934 repeat times are calculated is shifted back by 1 hour, and that at 935 time 3749680800 (Sun 28-Oct-2018 2:00 UTC, the end of British Summer 936 Time) the session's original time base is restored. Adjustments are 937 always relative to the specified start time -- they are not 938 cumulative. 940 If a session is likely to last several years, it is expected that the 941 session description will be modified periodically rather than 942 transmit several years' worth of adjustments in one session 943 description. 945 5.12. Encryption Keys ("k=") 947 k= 948 k=: 950 The "k=" line (key-field) is obsolete and MUST NOT be used. It is 951 included in this document for legacy reasons. One MUST NOT include a 952 "k=" line in an SDP, and MUST discard it if it is received in an SDP. 954 5.13. Attributes ("a=") 956 a= 957 a=: 959 Attributes are the primary means for extending SDP. Attributes may 960 be defined to be used as "session-level" attributes, "media-level" 961 attributes, or both. (Attribute scopes in addition to media- and 962 session- specific may also be defined in extensions to this document. 963 E.g., [RFC5576], [I-D.ietf-mmusic-data-channel-sdpneg].) 965 A media description may contain any number of "a=" lines (attribute- 966 fields) that are media description specific. These are referred to 967 as "media-level" attributes and add information about the media 968 description. Attribute-fields can also be added before the first 969 media description; these "session-level" attributes convey additional 970 information that applies to the session as a whole rather than to 971 individual media descriptions. 973 Attribute-fields may be of two forms: 975 o A property attribute is simply of the form "a=". These 976 are binary attributes, and the presence of the attribute conveys 977 that the attribute is a property of the session. An example might 978 be "a=recvonly". 980 o A value attribute is of the form "a=:". For 981 example, a whiteboard could have the value attribute 982 "a=orient:landscape" 984 Attribute interpretation depends on the media tool being invoked. 985 Thus receivers of session descriptions should be configurable in 986 their interpretation of session descriptions in general and of 987 attributes in particular. 989 Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. 991 Attribute values are octet strings, and MAY use any octet value 992 except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute 993 values are to be interpreted as in ISO-10646 character set with UTF-8 994 encoding. Unlike other text fields, attribute values are NOT 995 normally affected by the "charset" attribute as this would make 996 comparisons against known values problematic. However, when an 997 attribute is defined, it can be defined to be charset dependent, in 998 which case its value should be interpreted in the session charset 999 rather than in ISO-10646. 1001 Attributes MUST be registered with IANA (see Section 8). If an 1002 attribute is received that is not understood, it MUST be ignored by 1003 the receiver. 1005 5.14. Media Descriptions ("m=") 1007 m= ... 1009 A session description may contain a number of media descriptions. 1010 Each media description starts with an "m=" line (media-field) and is 1011 terminated by either the next "m=" line or by the end of the session 1012 description. A media-field has several sub-fields: 1014 is the media type. This document defines the values 1015 "audio", "video", "text", "application", and "message". This list 1016 is extended by other memos and may be further extended by 1017 additional memos registering media types in the future (see 1018 Section 8). For example, [RFC6466] defined the "image" media 1019 type. 1021 is the transport port to which the media stream is sent. The 1022 meaning of the transport port depends on the network being used as 1023 specified in the relevant "c=" line, and on the transport protocol 1024 defined in the sub-field of the media-field. Other ports 1025 used by the media application (such as the RTP Control Protocol 1026 (RTCP) port [RFC3550]) MAY be derived algorithmically from the 1027 base media port or MAY be specified in a separate attribute (for 1028 example, "a=rtcp:" as defined in [RFC3605]). 1030 If non-contiguous ports are used or if they don't follow the 1031 parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" 1032 attribute MUST be used. Applications that are requested to send 1033 media to a that is odd and where the "a=rtcp:" is present 1034 MUST NOT subtract 1 from the RTP port: that is, they MUST send the 1035 RTP to the port indicated in and send the RTCP to the port 1036 indicated in the "a=rtcp" attribute. 1038 For applications where hierarchically encoded streams are being 1039 sent to a unicast address, it may be necessary to specify multiple 1040 transport ports. This is done using a similar notation to that 1041 used for IP multicast addresses in the "c=" line: 1043 m= / ... 1045 In such a case, the ports used depend on the transport protocol. 1046 For RTP, the default is that only the even-numbered ports are used 1047 for data with the corresponding one-higher odd ports used for the 1048 RTCP belonging to the RTP session, and the 1049 denoting the number of RTP sessions. For example: 1051 m=video 49170/2 RTP/AVP 31 1053 would specify that ports 49170 and 49171 form one RTP/RTCP pair 1054 and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the 1055 transport protocol and 31 is the format (see below). If non- 1056 contiguous ports are required, they must be signaled using a 1057 separate attribute. (There is currently no attribute defined that 1058 can accomplish this. The "a=rtcp:" defined in [RFC3605] does not 1059 handle hierarchical encoding.) 1061 If multiple addresses are specified in the "c=" line and multiple 1062 ports are specified in the "m=" line, a one-to-one mapping from 1063 port to the corresponding address is implied. For example: 1065 c=IN IP4 233.252.0.1/127/2 1066 m=video 49170/2 RTP/AVP 31 1068 would imply that address 233.252.0.1 is used with ports 49170 and 1069 49171, and address 233.252.0.2 is used with ports 49172 and 49173. 1071 This document provides no semantics for using multiple "m=" lines 1072 using the same transport address. This implies that, unlike 1073 limited past practice, there is no implicit grouping defined by 1074 such means and an explicit grouping framework (for example, 1075 [RFC5888]) should instead be used to express the intended 1076 semantics. Such semantics may alo be added as extensions. For 1077 instance, see [I-D.ietf-mmusic-sdp-bundle-negotiation]. 1079 is the transport protocol. The meaning of the transport 1080 protocol is dependent on the address type sub-field in the 1081 relevant "c=" line. Thus a "c=" line with an address type of IP4 1082 indicates that the transport protocol runs over IP4. The 1083 following transport protocols are defined, but may be extended 1084 through registration of new protocols with IANA (see Section 8): 1086 * udp: denotes that the data is transported directly in UDP with 1087 no additional framing. 1089 * RTP/AVP: denotes RTP [RFC3550] used under the RTP Profile for 1090 Audio and Video Conferences with Minimal Control [RFC3551] 1091 running over UDP. 1093 * RTP/SAVP: denotes the Secure Real-time Transport Protocol 1094 [RFC3711] running over UDP. 1096 The main reason to specify the transport protocol in addition to 1097 the media format is that the same standard media formats may be 1098 carried over different transport protocols even when the network 1099 protocol is the same -- a historical example is VAT (MBone's 1100 popular multimedia audio tool) Pulse Code Modulation (PCM) audio 1101 and RTP PCM audio; another might be TCP/RTP PCM audio. In 1102 addition, relays and monitoring tools that are transport-protocol- 1103 specific but format-independent are possible. 1105 is a media format description. The fourth and any subsequent 1106 sub-fields describe the format of the media. The interpretation 1107 of the media format depends on the value of the sub-field. 1109 If the sub-field is "RTP/AVP" or "RTP/SAVP" the sub- 1110 fields contain RTP payload type numbers. When a list of payload 1111 type numbers is given, this implies that all of these payload 1112 formats MAY be used in the session, but the first of these formats 1113 SHOULD be used as the default format for the session. For dynamic 1114 payload type assignments the "a=rtpmap:" attribute (see Section 6) 1115 SHOULD be used to map from an RTP payload type number to a media 1116 encoding name that identifies the payload format. The "a=fmtp:" 1117 attribute MAY be used to specify format parameters (see 1118 Section 6). 1120 If the sub-field is "udp" the sub-fields MUST 1121 reference a media type describing the format under the "audio", 1122 "video", "text", "application", or "message" top-level media 1123 types. The media type registration SHOULD define the packet 1124 format for use with UDP transport. 1126 For media using other transport protocols, the sub-field is 1127 protocol specific. Rules for interpretation of the sub- 1128 field MUST be defined when registering new protocols (see 1129 Section 8.2.2). 1131 Section 3 of [RFC4855] states that the payload format (encoding) 1132 names defined in the RTP Profile are commonly shown in upper case, 1133 while media subtype names are commonly shown in lower case. It 1134 also states that both of these names are case-insensitive in both 1135 places, similar to parameter names which are case-insensitive both 1136 in media type strings and in the default mapping to the SDP a=fmtp 1137 attribute. 1139 6. SDP Attributes 1141 The following attributes are defined. Since application writers may 1142 add new attributes as they are required, this list is not exhaustive. 1143 Registration procedures for new attributes are defined in 1144 Section 8.2.4. Syntax is provided using ABNF [RFC7405] with some of 1145 the rules defined further in Section 9. 1147 6.1. cat (category) 1149 Name: cat 1151 Value: cat-value 1153 Usage Level: session 1155 Charset Dependent: no 1157 Syntax: 1159 cat-value = category 1160 category = non-ws-string 1162 Example: 1164 a=cat:foo.bar 1166 This attribute gives the dot-separated hierarchical category of the 1167 session. This is to enable a receiver to filter unwanted sessions by 1168 category. There is no central registry of categories. This 1169 attribute is obsoleted. 1171 6.2. keywds (keywords) 1173 Name: keywds 1175 Value: keywds-value 1177 Usage Level: session 1179 Charset Dependent: yes 1181 Syntax: 1183 keywds-value = keywords 1184 keywords = text 1186 Example: 1188 a=keywds:SDP session description protocol 1190 Like the cat attribute, this is to assist identifying wanted sessions 1191 at the receiver. This allows a receiver to select interesting 1192 sessions based on keywords describing the purpose of the session; 1193 there is no central registry of keywords. Its value should be 1194 interpreted in the charset specified for the session description if 1195 one is specified, or by default in ISO 10646/UTF-8. This attribute 1196 is obsoleted. 1198 6.3. tool 1200 Name: tool 1202 Value: tool-value 1204 Usage Level: session 1206 Charset Dependent: no 1208 Syntax: 1210 tool-value = tool-name-and-version 1211 tool-name-and-version = text 1213 Example: 1215 a=tool:foobar V3.2 1217 This gives the name and version number of the tool used to create the 1218 session description. 1220 6.4. ptime (packet time) 1222 Name: ptime 1224 Value: ptime-value 1226 Usage Level: media 1228 Charset Dependent: no 1230 Syntax: 1232 ptime-value = non-zero-int-or-real 1234 Example: 1236 a=ptime:20 1238 This gives the length of time in milliseconds represented by the 1239 media in a packet. This is probably only meaningful for audio data, 1240 but may be used with other media types if it makes sense. It should 1241 not be necessary to know ptime to decode RTP or vat audio, and it is 1242 intended as a recommendation for the encoding/packetization of audio. 1244 6.5. maxptime (maximum packet time) 1246 Name: maxptime 1248 Value: maxptime-value 1250 Usage Level: media 1252 Charset Dependent: no 1254 Syntax: 1256 maxptime-value = non-zero-int-or-real 1258 Example: 1260 a=maxptime:20 1262 This gives the maximum amount of media that can be encapsulated in 1263 each packet, expressed as time in milliseconds. The time SHALL be 1264 calculated as the sum of the time the media present in the packet 1265 represents. For frame-based codecs, the time SHOULD be an integer 1266 multiple of the frame size. This attribute is probably only 1267 meaningful for audio data, but may be used with other media types if 1268 it makes sense. Note that this attribute was introduced after 1269 [RFC2327], and non-updated implementations will ignore this 1270 attribute. 1272 6.6. rtpmap 1274 Name: rtpmap 1276 Value: rtpmap-value 1278 Usage Level: media 1280 Charset Dependent: no 1282 Syntax: 1284 rtpmap-value = payload-type SP encoding-name 1285 "/" clock-rate [ "/" encoding-params ] 1286 payload-type = zero-based-integer 1287 encoding-name = token 1288 clock-rate = integer 1289 encoding-params = channels 1290 channels = integer 1292 This attribute maps from an RTP payload type number (as used in an 1293 "m=" line) to an encoding name denoting the payload format to be 1294 used. It also provides information on the clock rate and encoding 1295 parameters. Note that the payload type number is indicated in a 1296 7-bit field, limiting the values to inclusively between 0 and 127. 1298 Although an RTP profile can make static assignments of payload type 1299 numbers to payload formats, it is more common for that assignment to 1300 be done dynamically using "a=rtpmap:" attributes. As an example of a 1301 static payload type, consider u-law PCM coded single-channel audio 1302 sampled at 8 kHz. This is completely defined in the RTP Audio/Video 1303 profile as payload type 0, so there is no need for an "a=rtpmap:" 1304 attribute, and the media for such a stream sent to UDP port 49232 can 1305 be specified as: 1307 m=audio 49232 RTP/AVP 0 1309 An example of a dynamic payload type is 16-bit linear encoded stereo 1310 audio sampled at 16 kHz. If we wish to use the dynamic RTP/AVP 1311 payload type 98 for this stream, additional information is required 1312 to decode it: 1314 m=audio 49232 RTP/AVP 98 1315 a=rtpmap:98 L16/16000/2 1317 Up to one rtpmap attribute can be defined for each media format 1318 specified. Thus, we might have the following: 1320 m=audio 49230 RTP/AVP 96 97 98 1321 a=rtpmap:96 L8/8000 1322 a=rtpmap:97 L16/8000 1323 a=rtpmap:98 L16/11025/2 1325 RTP profiles that specify the use of dynamic payload types MUST 1326 define the set of valid encoding names and/or a means to register 1327 encoding names if that profile is to be used with SDP. The "RTP/AVP" 1328 and "RTP/SAVP" profiles use media subtypes for encoding names, under 1329 the top-level media type denoted in the "m=" line. In the example 1330 above, the media types are "audio/L8" and "audio/L16". 1332 For audio streams, encoding-params indicates the number of audio 1333 channels. This parameter is OPTIONAL and may be omitted if the 1334 number of channels is one, provided that no additional parameters are 1335 needed. 1337 For video streams, no encoding parameters are currently specified. 1339 Additional encoding parameters MAY be defined in the future, but 1340 codec-specific parameters SHOULD NOT be added. Parameters added to 1341 an "a=rtpmap:" attribute SHOULD only be those required for a session 1342 directory to make the choice of appropriate media to participate in a 1343 session. Codec-specific parameters should be added in other 1344 attributes (for example, "a=fmtp:"). 1346 Note: RTP audio formats typically do not include information about 1347 the number of samples per packet. If a non-default (as defined in 1348 the RTP Audio/Video Profile [RFC3551]) packetization is required, the 1349 "ptime" attribute is used as given above. 1351 6.7. Media Direction Attributes 1353 At most one of recvonly/sendrecv/sendonly/inactive MAY appear at 1354 session level, and at most one MAY appear in each media description. 1356 If any one of these appears in a media description then it applies 1357 for that media description. If none appear in a media description 1358 then the one from session level, if any, applies to that media 1359 description. 1361 If none of the media direction attributes is present at either 1362 session level or media level, "sendrecv" SHOULD be assumed as the 1363 default for sessions that are not of the multimedia conference type 1364 "broadcast" or "H332" (see below). 1366 Within the following SDP example, the "inactive" attribute applies to 1367 audio media and the "recvonly" attribute applies to video media. 1369 v=0 1370 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 1371 s=SDP Seminar 1372 i=A Seminar on the session description protocol 1373 u=http://www.example.com/seminars/sdp.pdf 1374 e=j.doe@example.com (Jane Doe) 1375 c=IN IP4 233.252.0.1/127 1376 t=2873397496 2873404696 1377 a=inactive 1378 m=audio 49170 RTP/AVP 0 1379 m=video 51372 RTP/AVP 99 1380 a=rtpmap:99 h263-1998/90000 1381 a=recvonly 1383 6.7.1. recvonly (receive-only) 1385 Name: recvonly 1387 Value: 1389 Usage Level: session, media 1391 Charset Dependent: no 1393 Example: 1395 a=recvonly 1397 This specifies that the tools should be started in receive-only mode 1398 where applicable. Note that recvonly applies to the media only, not 1399 to any associated control protocol (e.g., an RTP-based system in 1400 recvonly mode SHOULD still send RTCP packets). 1402 6.7.2. sendrecv (send-receive) 1404 Name: sendrecv 1406 Value: 1408 Usage Level: session, media 1410 Charset Dependent: no 1411 Example: 1413 a=sendrecv 1415 This specifies that the tools should be started in send and receive 1416 mode. This is necessary for interactive multimedia conferences with 1417 tools that default to receive-only mode. 1419 6.7.3. sendonly (send-only) 1421 Name: sendonly 1423 Value: 1425 Usage Level: session, media 1427 Charset Dependent: no 1429 Example: 1431 a=sendonly 1433 This specifies that the tools should be started in send-only mode. 1434 An example may be where a different unicast address is to be used for 1435 a traffic destination than for a traffic source. In such a case, two 1436 media descriptions may be used, one sendonly and one recvonly. Note 1437 that sendonly applies only to the media, and any associated control 1438 protocol (e.g., RTCP) SHOULD still be received and processed as 1439 normal. 1441 6.7.4. inactive 1443 Name: inactive 1445 Value: 1447 Usage Level: session, media 1449 Charset Dependent: no 1451 Example: 1453 a=inactive 1455 This specifies that the tools should be started in inactive mode. 1456 This is necessary for interactive multimedia conferences where users 1457 can put other users on hold. No media is sent over an inactive media 1458 stream. Note that an RTP-based system MUST still send RTCP (if RTCP 1459 is used), even if started inactive. 1461 6.8. orient (orientation) 1463 Name: orient 1465 Value: orient-value 1467 Usage Level: media 1469 Charset Dependent: no 1471 Syntax: 1473 orient-value = portrait / landscape / seascape 1474 portrait = %s"portrait" 1475 landscape = %s"landscape" 1476 seascape = %s"seascape" 1477 ; NOTE: These names are case-sensitive. 1479 Example: 1481 a=orient:portrait 1483 Normally this is only used for a whiteboard or presentation tool. It 1484 specifies the orientation of the workspace on the screen. Permitted 1485 values are "portrait", "landscape", and "seascape" (upside-down 1486 landscape). 1488 6.9. type (conference type) 1490 Name: type 1492 Value: type-value 1494 Usage Level: session 1496 Charset Dependent: no 1497 Syntax: 1499 type-value = conference-type 1500 conference-type = broadcast / meeting / moderated / test / 1501 H332 1502 broadcast = %s"broadcast" 1503 meeting = %s"meeting" 1504 moderated = %s"moderated" 1505 test = %s"test" 1506 H332 = %s"H332" 1507 ; NOTE: These names are case-sensitive. 1509 Example: 1511 a=type:moderated 1513 This specifies the type of the multimedia conference. Suggested 1514 values are "broadcast", "meeting", "moderated", "test", and "H332". 1515 "recvonly" should be the default for "type:broadcast" sessions, 1516 "type:meeting" should imply "sendrecv", and "type:moderated" should 1517 indicate the use of a floor control tool and that the media tools are 1518 started so as to mute new sites joining the multimedia conference. 1520 Specifying the attribute "type:H332" indicates that this loosely 1521 coupled session is part of an H.332 session as defined in the ITU 1522 H.332 specification [ITU.H332.1998]. Media tools should be started 1523 "recvonly". 1525 Specifying the attribute "type:test" is suggested as a hint that, 1526 unless explicitly requested otherwise, receivers can safely avoid 1527 displaying this session description to users. 1529 6.10. charset (character set) 1531 Name: charset 1533 Value: charset-value 1535 Usage Level: session 1537 Charset Dependent: no 1539 Syntax: 1541 charset-value = mime-charset 1542 (as defined in [RFC 2978]) 1544 This specifies the character set to be used to display the session 1545 name and information data. By default, the ISO-10646 character set 1546 in UTF-8 encoding is used. If a more compact representation is 1547 required, other character sets may be used. For example, the ISO 1548 8859-1 is specified with the following SDP attribute: 1550 a=charset:ISO-8859-1 1552 The charset specified MUST be one of those registered in the IANA 1553 Character Sets registry (http://www.iana.org/assignments/character- 1554 sets), such as ISO-8859-1. The character set identifier is a US- 1555 ASCII string and MUST be compared against identifiers from the "Name" 1556 or "Preferred MIME Name" field of the registry using a case- 1557 insensitive comparison. If the identifier is not recognised or not 1558 supported, all strings that are affected by it SHOULD be regarded as 1559 octet strings. 1561 Note that a character set specified MUST still prohibit the use of 1562 bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets requiring 1563 the use of these characters MUST define a quoting mechanism that 1564 prevents these bytes from appearing within text fields. 1566 6.11. sdplang (SDP language) 1568 Name: sdplang 1570 Value: sdplang-value 1572 Usage Level: session, media 1574 Charset Dependent: no 1576 Syntax: 1578 sdplang-value = Language-Tag 1579 ; Language-Tag defined in RFC5646 1581 Example: 1583 a=sdplang:fr 1585 Multiple sdplang attributes can be provided either at session or 1586 media level if the session description or media use multiple 1587 languages. 1589 As a session-level attribute, it specifies the language for the 1590 session description (not the language of the media). As a media- 1591 level attribute, it specifies the language for any media-level SDP 1592 information-field associated with that media (again not the language 1593 of the media), overriding any sdplang attributes specified at session 1594 level. 1596 In general, sending session descriptions consisting of multiple 1597 languages is discouraged. Instead, multiple sesssion descriptions 1598 SHOULD be sent describing the session, one in each language. 1599 However, this is not possible with all transport mechanisms, and so 1600 multiple sdplang attributes are allowed although NOT RECOMMENDED. 1602 The "sdplang" attribute value must be a single [RFC5646] language tag 1603 in US-ASCII. An "sdplang" attribute SHOULD be specified when a 1604 session is distributed with sufficient scope to cross geographic 1605 boundaries, where the language of recipients cannot be assumed, or 1606 where the session is in a different language from the locally assumed 1607 norm. 1609 6.12. lang (language) 1611 Name: lang 1613 Value: lang-value 1615 Usage Level: session, media 1617 Charset Dependent: no 1619 Syntax: 1621 lang-value = Language-Tag 1622 ; Language-Tag defined in RFC5646 1624 Example: 1626 a=lang:de 1628 Multiple lang attributes can be provided either at session or media 1629 level if the session or media has capabilities in more than one 1630 language, in which case the order of the attributes indicates the 1631 order of preference of the various languages in the session or media, 1632 from most preferred to least preferred. 1634 As a session-level attribute, lang specifies a language capability 1635 for the session being described. As a media-level attribute, it 1636 specifies a language capability for that media, overriding any 1637 session-level language(s) specified. 1639 The "lang" attribute value must be a single [RFC5646] language tag in 1640 US-ASCII. A "lang" attribute SHOULD be specified when a session is 1641 of sufficient scope to cross geographic boundaries where the language 1642 of participants cannot be assumed, or where the session has 1643 capabilities in languages different from the locally assumed norm. 1645 The "lang" attribute is supposed to be used for setting the initial 1646 language(s) used in the session. Events during the session may 1647 influence which language(s) are used, and the participants are not 1648 strictly bound to only use the declared languages. 1650 Most real-time use cases start with just one language used, while 1651 other cases involve a range of languages, e.g. an interpreted or 1652 subtitled session. When more than one 'lang' attribute is specified, 1653 the "lang" attribute itself does not provide any information about 1654 multiple languages being intended to be used during the session, or 1655 if the intention is to only select one of the languages. If needed, 1656 a new attribute can be defined and used to indicate such intentions. 1657 Without such semantics, it is assumed that for a negotiated session 1658 one of the declared languages will be selected and used. 1660 6.13. framerate (frame rate) 1662 Name: framerate 1664 Value: framerate-value 1666 Usage Level: media 1668 Charset Dependent: no 1670 Syntax: 1672 framerate-value = non-zero-int-or-real 1674 Example: 1676 a=framerate:60 1678 This gives the maximum video frame rate in frames/sec. It is 1679 intended as a recommendation for the encoding of video data. Decimal 1680 representations of fractional values are allowed. It is defined only 1681 for video media. 1683 6.14. quality 1685 Name: quality 1687 Value: quality-value 1689 Usage Level: media 1691 Charset Dependent: no 1693 Syntax: 1695 quality-value = zero-based-integer 1697 Example: 1699 a=quality:10 1701 This gives a suggestion for the quality of the encoding as an integer 1702 value. The intention of the quality attribute for video is to 1703 specify a non-default trade-off between frame-rate and still-image 1704 quality. For video, the value is in the range 0 to 10, with the 1705 following suggested meaning: 1707 10 - the best still-image quality the compression scheme 1708 can give. 1709 5 - the default behavior given no quality suggestion. 1710 0 - the worst still-image quality the codec designer 1711 thinks is still usable. 1713 6.15. fmtp (format parameters) 1715 Name: fmtp 1717 Value: fmtp-value 1719 Usage Level: media 1721 Charset Dependent: no 1723 Syntax: 1725 fmtp-value = fmt SP format-specific-params 1726 format-specific-params = byte-string 1727 ; Notes: 1728 ; - The format parameters are media type parameters and 1729 ; need to reflect their syntax. 1731 Example: 1733 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1735 This attribute allows parameters that are specific to a particular 1736 format to be conveyed in a way that SDP does not have to understand 1737 them. The format must be one of the formats specified for the media. 1738 Format-specific parameters, semicolon separated, may be any set of 1739 parameters required to be conveyed by SDP and given unchanged to the 1740 media tool that will use this format. At most one instance of this 1741 attribute is allowed for each format. 1743 The fmtp attribute may be used to specify parameters for any protocol 1744 and format that defines use of such parameters. 1746 7. Security Considerations 1748 SDP is frequently used with the Session Initiation Protocol [RFC3261] 1749 using the offer/answer model [RFC3264] to agree on parameters for 1750 unicast sessions. When used in this manner, the security 1751 considerations of those protocols apply. 1753 SDP is a session description format that describes multimedia 1754 sessions. Entities receiving and acting upon an SDP message SHOULD 1755 be aware that a session description cannot be trusted unless it has 1756 been obtained by an authenticated and integrity-protected transport 1757 protocol from a known and trusted source. Many different transport 1758 protocols may be used to distribute session descriptions, and the 1759 nature of the authentication and integrity-protection will differ 1760 from transport to transport. For some transports, security features 1761 are often not deployed. In case a session description has not been 1762 obtained in a trusted manner, the endpoint SHOULD exercise care 1763 because, among other attacks, the media sessions received may not be 1764 the intended ones, the destination where media is sent to may not be 1765 the expected one, any of the parameters of the session may be 1766 incorrect, or the media security may be compromised. It is up to the 1767 endpoint to make a sensible decision taking into account the security 1768 risks of the application and the user preferences - the endpoint may 1769 decide to ask the user whether or not to accept the session. 1771 On receiving a session description over an unauthenticated transport 1772 mechanism or from an untrusted party, software parsing the session 1773 should take a few precautions. Similar concerns apply if integrity 1774 protection is not in place. Session descriptions contain information 1775 required to start software on the receiver's system. Software that 1776 parses a session description MUST NOT be able to start other software 1777 except that which is specifically configured as appropriate software 1778 to participate in multimedia sessions. It is normally considered 1779 inappropriate for software parsing a session description to start, on 1780 a user's system, software that is appropriate to participate in 1781 multimedia sessions, without the user first being informed that such 1782 software will be started and giving the user's consent. Thus, a 1783 session description arriving by session announcement, email, session 1784 invitation, or WWW page MUST NOT deliver the user into an interactive 1785 multimedia session unless the user has explicitly pre-authorized such 1786 action. As it is not always simple to tell whether or not a session 1787 is interactive, applications that are unsure should assume sessions 1788 are interactive. 1790 In this specification, there are no attributes that would allow the 1791 recipient of a session description to be informed to start multimedia 1792 tools in a mode where they default to transmitting. Under some 1793 circumstances it might be appropriate to define such attributes. If 1794 this is done, an application parsing a session description containing 1795 such attributes SHOULD either ignore them or inform the user that 1796 joining this session will result in the automatic transmission of 1797 multimedia data. The default behavior for an unknown attribute is to 1798 ignore it. 1800 In certain environments, it has become common for intermediary 1801 systems to intercept and analyze session descriptions contained 1802 within other signaling protocols. This is done for a range of 1803 purposes, including but not limited to opening holes in firewalls to 1804 allow media streams to pass, or to mark, prioritize, or block traffic 1805 selectively. In some cases, such intermediary systems may modify the 1806 session description, for example, to have the contents of the session 1807 description match NAT bindings dynamically created. These behaviors 1808 are NOT RECOMMENDED unless the session description is conveyed in 1809 such a manner that allows the intermediary system to conduct proper 1810 checks to establish the authenticity of the session description, and 1811 the authority of its source to establish such communication sessions. 1812 SDP by itself does not include sufficient information to enable these 1813 checks: they depend on the encapsulating protocol (e.g., SIP or 1814 RTSP). Use of some procedures and SDP extensions (e.g., ICE 1815 [RFC8445] and ICE-SIP-SDP [I-D.ietf-mmusic-ice-sip-sdp]) may avoid 1816 the need for intermediaries to modify SDP. 1818 Use of the "k=" line poses a significant security risk, since it 1819 conveys session encryption keys in the clear. SDP MUST NOT be used 1820 to convey keying material, unless it can be guaranteed that the 1821 channel over which the SDP is delivered is both private and 1822 authenticated. Moreover, the "k=" line provides no way to indicate 1823 or negotiate cryptographic key algorithms. As it provides for only a 1824 single symmetric key, rather than separate keys for confidentiality 1825 and integrity, its utility is severely limited. The "k=" line MUST 1826 NOT be used, as discussed in Section 5.12. 1828 8. IANA Considerations 1830 8.1. The "application/sdp" Media Type 1832 One media type registration from [RFC4566] is to be updated, as 1833 defined below. 1835 To: ietf-types@iana.org 1836 Subject: Registration of media type "application/sdp" 1838 Type name: application 1840 Subtype name: sdp 1842 Required parameters: None. 1844 Optional parameters: None. 1846 Encoding considerations: 1847 SDP files are primarily UTF-8 format text. The "a=charset:" 1848 attribute may be used to signal the presence of other character 1849 sets in certain parts of an SDP file (see Section 6 of RFC 1850 XXXX). Arbitrary binary content cannot be directly 1851 represented in SDP. 1853 Security considerations: 1854 See Section 7 of RFC XXXX. 1856 Interoperability considerations: 1857 See RFC XXXX. 1859 Published specification: 1860 See RFC XXXX. 1862 Applications which use this media type: 1863 Voice over IP, video teleconferencing, streaming media, instant 1864 messaging, among others. See also Section 3 of RFC XXXX. 1866 Fragment identifier considerations: None 1868 Additional information: 1870 Deprecated alias names for this type: N/A 1871 Magic number(s): None. 1872 File extension(s): The extension ".sdp" is commonly used. 1873 Macintosh File Type Code(s): "sdp " 1875 Person & email address to contact for further information: 1877 IETF MMUSIC working group 1879 Intended usage: COMMON 1881 Restrictions on usage: None 1883 Author/Change controller: 1884 Authors of RFC XXXX 1885 IETF MMUSIC working group delegated from the IESG 1887 8.2. Registration of Parameters 1889 This specification establishes and initializes IANA parameter 1890 registries for seven named SDP sub-fields. Using the terminology in 1891 the SDP specification Augmented Backus-Naur Form (ABNF), they are 1892 "media", "proto", "att-field", "bwtype", "nettype", and "addrtype". 1894 The contact address for all parameters registered below is: 1896 IETF MMUSIC working group 1898 8.2.1. Media Types ("media") 1900 The set of media types is intended to be small and SHOULD NOT be 1901 extended except under rare circumstances. The same rules should 1902 apply for media names as for top-level media types, and where 1903 possible the same name should be registered for SDP as for MIME. For 1904 media other than existing top-level media types, a Standards Track 1905 RFC MUST be produced for a new top-level media type to be registered, 1906 and the registration MUST provide good justification why no existing 1907 media name is appropriate (the "Standards Action" policy of 1908 [RFC8126]). 1910 This memo registers the media types "audio", "video", "text", 1911 "application", and "message". 1913 Note: The media types "control" and "data" were listed as valid in an 1914 early version of this specification (RFC 2327); however, their 1915 semantics were never fully specified and they are not widely used. 1916 These media types have been removed in this specification, although 1917 they still remain valid media type capabilities for a SIP user agent 1918 as defined in [RFC3840]. If these media types are considered useful 1919 in the future, a Standards Track RFC MUST be produced to document 1920 their use. Until that is done, applications SHOULD NOT use these 1921 types and SHOULD NOT declare support for them in SIP capabilities 1922 declarations (even though they exist in the registry created by 1923 [RFC3840]). Also note that [RFC6466] defined the "image" media type. 1925 8.2.2. Transport Protocols ("proto") 1927 The "proto" sub-field describes the transport protocol used. The 1928 registration procedure for this registry is "RFC Required". 1930 This document registers two values: "RTP/AVP" is a reference to 1931 [RFC3550] used under the RTP Profile for Audio and Video Conferences 1932 with Minimal Control [RFC3551] running over UDP/IP, and "udp" 1933 indicates direct use of the UDP protocol. 1935 New transport protocols MAY be defined, and MUST be registered with 1936 IANA. Registrations MUST reference an RFC describing the protocol. 1937 Such an RFC MAY be Experimental or Informational, although it is 1938 preferable that it be Standards Track. The RFC defining a new 1939 protocol MUST define the rules by which the "fmt" (see below) 1940 namespace is managed. 1942 "proto" names starting with "RTP/" MUST only be used for defining 1943 transport protocols that are profiles of the RTP protocol. For 1944 example, a profile whose short name is "XYZ" would be denoted by a 1945 "proto" sub-field of "RTP/XYZ". 1947 8.2.3. Media Formats ("fmt") 1949 Each transport protocol, defined by the "proto" sub-field, has an 1950 associated "fmt" namespace that describes the media formats that may 1951 be conveyed by that protocol. Formats cover all the possible 1952 encodings that could be transported in a multimedia session. 1954 RTP payload formats under the "RTP/AVP" and other "RTP/*" profiles 1955 MUST use the payload type number as their "fmt" value. If the 1956 payload type number is dynamically assigned by this session 1957 description, an additional "rtpmap" attribute MUST be included to 1958 specify the format name and parameters as defined by the media type 1959 registration for the payload format. It is RECOMMENDED that other 1960 RTP profiles that are registered (in combination with RTP) as SDP 1961 transport protocols specify the same rules for the "fmt" namespace. 1963 For the "udp" protocol, allowed "fmt" values are media subtypes from 1964 the IANA Media Types registry. The media type and subtype 1965 combination / specifies the format of the body of UDP 1966 packets. Use of an existing media subtype for the format is 1967 encouraged. If no suitable media subtype exists, it is RECOMMENDED 1968 that a new one be registered through the IETF process [RFC6838] by 1969 production of, or reference to, a standards-track RFC that defines 1970 the format. 1972 For other protocols, formats MAY be registered according to the rules 1973 of the associated "proto" specification. 1975 Registrations of new formats MUST specify which transport protocols 1976 they apply to. 1978 8.2.4. Attribute Names ("att-field") 1980 8.2.4.1. New Attributes 1982 Attribute-field names ("att-field") MUST be registered with IANA and 1983 documented, to avoid any issues due to conflicting attribute 1984 definitions under the same name. Unknown attributes in SDP are 1985 simply ignored, but conflicting ones that fragment the protocol are a 1986 serious problem. 1988 New attribute registrations are accepted according to the 1989 "Specification Required" policy of [RFC8126], provided that the 1990 specification includes the following information: 1992 o Contact Name. 1994 o Contact Email Address. 1996 o Attribute Name: The name of the attribute that will appear in 1997 SDP). This MUST conform to the definition of . 1999 o Attribute Syntax: For a value attribute (see clause 5.13), an ABNF 2000 definition of the attribute value syntax (see 2001 Section 9) MUST be provided. The syntax MUST follow the rule form 2002 as per Section 2.2 of [RFC5234] and [RFC7405]. This SHALL define 2003 the allowable values that the attribute might take. It MAY also 2004 define an extension method for the addition of future values. For 2005 a property attribute, the ABNF definition is omitted as the 2006 property attribute takes no values. 2008 o Attribute Semantics: For a value attribute, a semantic description 2009 of the values that the attribute might take MUST be provided. The 2010 usage of a property attribute is described under purpose below. 2012 o Attribute Value: The name of an ABNF syntax rule defining the 2013 syntax of the value. Absence of a rule name indicates that the 2014 attribute takes no values. Enclosing the rule name in "[" and "]" 2015 indicates that a value is optional. 2017 o Usage Level: Usage level(s) of the attribute. One or more of: 2018 session, media, source, dcsa, dcsa(subprotocol). For a definition 2019 of source level attributes, see [RFC5576]. For a definition of 2020 dcsa attributes see: [I-D.ietf-mmusic-data-channel-sdpneg]. 2022 o Charset Dependent: Whether the attribute value is subject to the 2023 charset attribute or not (Yes/No). 2025 o Purpose: An explanation of the purpose and usage of the attribute. 2027 o O/A Procedures: Offer/Answer procedures as explained in [RFC3264]. 2029 o Mux Category: Indication of which multiplexing "category" 2030 [I-D.ietf-mmusic-sdp-mux-attributes] an attribute is associated 2031 with. 2033 o Reference: A reference to the specification defining the 2034 attribute. 2036 The above is the minimum that IANA will accept. Attributes that are 2037 expected to see widespread use and interoperability SHOULD be 2038 documented with a standards-track RFC that specifies the attribute 2039 more precisely. 2041 Submitters of registrations should ensure that the specification is 2042 in the spirit of SDP attributes, most notably that the attribute is 2043 platform independent in the sense that it makes no implicit 2044 assumptions about operating systems and does not name specific pieces 2045 of software in a manner that might inhibit interoperability. 2047 Submitters of registrations should also carefully choose the 2048 attribute usage level. They should not choose only "session" when 2049 the attribute can have different values when media is disaggregated, 2050 i.e., when each m= section has its own IP address on a different 2051 endpoint. In that case the attribute type chosen should be "session, 2052 media" or "media" (depending on desired semantics). The default rule 2053 is that for all new SDP attributes that can occur both in session and 2054 media level, the media level overrides the session level. When this 2055 is not the case for a new SDP attribute, it MUST be explicitly 2056 stated. 2058 IANA has registered the initial set of attribute names ("att-field" 2059 values) with definitions as in Section 6 of this memo (these 2060 definitions replace those in [RFC4566]). 2062 8.2.4.2. Updates to Existing Attributes 2064 Updated attribute registrations are accepted according to the 2065 "Specification Required" policy of [RFC8126], provided that the 2066 specification updating the attribute (for example, by adding a new 2067 value) considers the registration information items from 2068 Section 8.2.4.1 according to the following bullets: 2070 o Contact Name: A name MUST be provided. 2072 o Contact Email Address: An email address MUST be provided. 2074 o Attribute Name: MUST be provided and MUST NOT be changed. 2075 Otherwise it is a new attribute. 2077 o Attribute Syntax: The existing rule syntax with the syntax 2078 extensions MUST be provided if there is a change to the syntax. A 2079 revision to an existing attribute usage MAY extend the syntax of 2080 an attribute, but MUST be backward compatible. 2082 o Attribute Semantics: A semantic description of new additional 2083 attribute values or a semantic extension of existing values. 2084 Existing attribute values semantics MUST only be extended in a 2085 backward compatible manner. 2087 o Usage Level: Updates MAY only add additional levels. 2089 o Charset Dependent: MUST NOT be changed. 2091 o Purpose: MAY be extended according to the updated usage. 2093 o O/A Procedures: MAY be updated in a backward compatible manner 2094 and/or it applies to a new usage level only. 2096 o Mux Category: No change unless from "TBD" to another value (see 2097 [I-D.ietf-mmusic-sdp-mux-attributes]. It MAY also change if 2098 'media' level is being added to the definition of an attribute 2099 that previously did not include it. 2101 o Reference: A new reference MUST be provided. 2103 Items SHOULD be omitted if there is no impact to them as a result of 2104 the attribute update. 2106 8.2.5. Bandwidth Specifiers ("bwtype") 2108 A proliferation of bandwidth specifiers is strongly discouraged. 2110 New bandwidth specifiers ( sub-field values) MUST be 2111 registered with IANA. The submission MUST reference a standards- 2112 track RFC specifying the semantics of the bandwidth specifier 2113 precisely, and indicating when it should be used, and why the 2114 existing registered bandwidth specifiers do not suffice. 2116 IANA has registered the bandwidth specifiers "CT" and "AS" with 2117 definitions as in Section 5.8 of this memo (these definitions update 2118 those in [RFC4566]). 2120 8.2.6. Network Types ("nettype") 2122 New network types ( sub-field values) MUST be registered 2123 with IANA if SDP needs to be used in the context of non-Internet 2124 environments. The registration is subject to the "RFC Required" 2125 policy of [RFC8126]. Although these are not normally the preserve of 2126 IANA, there may be circumstances when an Internet application needs 2127 to interoperate with a non-Internet application, such as when 2128 gatewaying an Internet telephone call into the Public Switched 2129 Telephone Network (PSTN). The number of network types should be 2130 small and should be rarely extended. A new network type cannot be 2131 registered without registering at least one address type to be used 2132 with that network type. A new network type registration MUST 2133 reference an RFC that gives details of the network type and address 2134 type(s) and specifies how and when they would be used. 2136 IANA has registered the network type "IN" to represent the Internet, 2137 with definition as in Sections 5.2 and 5.7 of this memo (these 2138 definitions update those in [RFC4566]). 2140 8.2.7. Address Types ("addrtype") 2142 New address types ("addrtype") MUST be registered with IANA. The 2143 registration is subject to the "RFC Required" policy of [RFC8126]. 2144 An address type is only meaningful in the context of a network type, 2145 and any registration of an address type MUST specify a registered 2146 network type or be submitted along with a network type registration. 2147 A new address type registration MUST reference an RFC giving details 2148 of the syntax of the address type. Address types are not expected to 2149 be registered frequently. 2151 IANA has registered the address types "IP4" and "IP6" with 2152 definitions as in Sections 5.2 and 5.7 of this memo (these 2153 definitions update those in [RFC4566]). 2155 8.2.8. Registration Procedure 2157 In the RFC specifications that register new values for SDP "media", 2158 "proto", "fmt", "bwtype", "nettype", and "addrtype" parameters, the 2159 authors MUST include the following information for IANA to place in 2160 the appropriate registry: 2162 o contact name, email address, and telephone number 2163 o name being registered (as it will appear in SDP) 2165 o long-form name in English 2167 o type of name ("media", "proto", "fmt", "bwtype", "nettype", or 2168 "addrtype") 2170 o a one-paragraph explanation of the purpose of the registered name 2172 o a reference to the specification for the registered name (this 2173 will typically be an RFC number) 2175 In the case of a new addrtype registration, the author has to check 2176 whether the new address type is usable with the existing network 2177 types. If yes, the "nettype" registry MUST be updated accordingly. 2178 In the case of a new nettype registration, the author MUST specify 2179 the usable address type(s). 2181 IANA may refer any registration to the IESG for review, and may 2182 request revisions to be made before a registration will be made. 2184 8.3. Encryption Key Access Methods 2186 The IANA previously maintained a table of SDP encryption key access 2187 method ("enckey") names. This table is obsolete, since the "k=" line 2188 is not extensible. New registrations MUST NOT be accepted. 2190 8.4. Reorganization of the nettype Registry 2192 This document adds a new column in the "nettype" registry with the 2193 title "Usable addrtype Values" and updates the "nettype" registry as 2194 follows: 2196 -------------------------------------------------------------------- 2197 |Type | SDP Name | Usable addrtype Values | Reference | 2198 -------------------------------------------------------------------- 2199 |nettype | IN | IP4, IP6 | [RFCXXXX] | 2200 |nettype | TN | RFC2543 | [RFC2848] | 2201 |nettype | ATM | NSAP, GWID, E164 | [RFC3108] | 2202 |nettype | PSTN | E164 | [RFC7195] | 2203 -------------------------------------------------------------------- 2205 Note that both [RFC7195] and [RFC3108] registered "E164" as an 2206 address type, although [RFC7195] mentions that the "E164" address 2207 type has a different context for ATM and PSTN networks. 2209 8.5. Reorganization of the att-field Registries 2211 This document combines all of the (currently) five "att-field" 2212 registries into one registry called "att-field" registry, and updates 2213 the columns to reflect the name, usage level(s), charset dependency 2214 and reference. As such IANA is requested to create a new combined 2215 registry using the following columns: 2217 Name | Usage Level | Dependent on Charset? | Mux Category | Reference 2219 The "Name" column reflects the attribute name (as it will appear in 2220 the SDP). The "Usage Level" column MUST indicate one or more of the 2221 following: session, media, source, dcsa and dcsa(subprotocol). The 2222 "Dependent on Charset?" column MUST indicate "Yes" or "No" depending 2223 on whether the attribute value is subject to the charset attribute. 2224 The "Mux Category" column MUST indicate one of the following 2225 categories: NORMAL, NOT RECOMMENDED, IDENTICAL, SUM, TRANSPORT, 2226 INHERIT, IDENTICAL-PER-PT, SPECIAL or TBD as defined by 2227 [I-D.ietf-mmusic-sdp-mux-attributes]. Finally, the "Reference" 2228 column indicates the specification(s) where the attribute is defined. 2230 For example, the attribute "setup" which is defined for both session 2231 and media level, will be listed in the new registry as follows: 2233 Name | Usage Level | Dependent on Charset?|Mux Category| Reference | 2234 ------|----------------|----------------------|------------|-----------| 2235 setup | session,media, | No |IDENTICAL | [RFC4145] | 2236 | dcsa,dcsa(msrp)| | | [RFC6135] | 2237 | | | | [I-D.mmusic 2238 | | | |-msrp-usage- 2239 | | | |data-channel 2240 | | | |] | 2242 9. SDP Grammar 2244 This section provides an Augmented BNF grammar for SDP. ABNF is 2245 defined in [RFC5234] and [RFC7405]. 2247 ; SDP Syntax 2248 session-description = version-field 2249 origin-field 2250 session-name-field 2251 [information-field] 2252 [uri-field] 2253 *email-field 2254 *phone-field 2255 [connection-field] 2256 *bandwidth-field 2257 1*time-description 2258 [key-field] 2259 *attribute-field 2260 *media-description 2262 version-field = %s"v" "=" 1*DIGIT CRLF 2263 ;this memo describes version 0 2265 origin-field = %s"o" "=" username SP sess-id SP sess-version SP 2266 nettype SP addrtype SP unicast-address CRLF 2268 session-name-field = %s"s" "=" text CRLF 2270 information-field = %s"i" "=" text CRLF 2272 uri-field = %s"u" "=" uri CRLF 2274 email-field = %s"e" "=" email-address CRLF 2276 phone-field = %s"p" "=" phone-number CRLF 2278 connection-field = %s"c" "=" nettype SP addrtype SP 2279 connection-address CRLF 2280 ;a connection field must be present 2281 ;in every media description or at the 2282 ;session-level 2284 bandwidth-field = %s"b" "=" bwtype ":" bandwidth CRLF 2286 time-description = time-field 2287 [repeat-description] 2289 repeat-description = 1*repeat-field 2290 [zone-field] 2292 time-field = %s"t" "=" start-time SP stop-time CRLF 2294 repeat-field = %s"r" "=" repeat-interval SP typed-time 2295 1*(SP typed-time) CRLF 2297 zone-field = %s"z" "=" time SP ["-"] typed-time 2298 *(SP time SP ["-"] typed-time) CRLF 2300 key-field = %s"k" "=" key-type CRLF 2302 attribute-field = %s"a" "=" attribute CRLF 2304 media-description = media-field 2306 [information-field] 2307 *connection-field 2308 *bandwidth-field 2309 [key-field] 2310 *attribute-field 2312 media-field = %s"m" "=" media SP port ["/" integer] 2313 SP proto 1*(SP fmt) CRLF 2315 ; sub-rules of 'o=' 2316 username = non-ws-string 2317 ;pretty wide definition, but doesn't 2318 ;include space 2320 sess-id = 1*DIGIT 2321 ;should be unique for this username/host 2323 sess-version = 1*DIGIT 2325 nettype = token 2326 ;typically "IN" 2328 addrtype = token 2329 ;typically "IP4" or "IP6" 2331 ; sub-rules of 'u=' 2332 uri = URI-reference 2333 ; see RFC 3986 2335 ; sub-rules of 'e=', see RFC 5322 for definitions 2336 email-address = address-and-comment / dispname-and-address 2337 / addr-spec 2338 address-and-comment = addr-spec 1*SP "(" 1*email-safe ")" 2339 dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">" 2341 ; sub-rules of 'p=' 2342 phone-number = phone *SP "(" 1*email-safe ")" / 2343 1*email-safe "<" phone ">" / 2344 phone 2346 phone = ["+"] DIGIT 1*(SP / "-" / DIGIT) 2348 ; sub-rules of 'c=' 2349 connection-address = multicast-address / unicast-address 2351 ; sub-rules of 'b=' 2352 bwtype = token 2353 bandwidth = 1*DIGIT 2355 ; sub-rules of 't=' 2356 start-time = time / "0" 2358 stop-time = time / "0" 2360 time = POS-DIGIT 9*DIGIT 2361 ; Decimal representation of NTP time in 2362 ; seconds since 1900. The representation 2363 ; of NTP time is an unbounded length field 2364 ; containing at least 10 digits. Unlike the 2365 ; 64-bit representation used elsewhere, time 2366 ; in SDP does not wrap in the year 2036. 2368 ; sub-rules of 'r=' and 'z=' 2369 repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] 2371 typed-time = 1*DIGIT [fixed-len-time-unit] 2373 fixed-len-time-unit = %s"d" / %s"h" / %s"m" / %s"s" 2374 ; NOTE: These units are case-sensitive. 2376 ; sub-rules of 'k=' 2377 key-type = %s"prompt" / 2378 %s"clear:" text / 2379 %s"base64:" base64 / 2380 %s"uri:" uri 2381 ; NOTE: These names are case-sensitive. 2383 base64 = *base64-unit [base64-pad] 2384 base64-unit = 4base64-char 2385 base64-pad = 2base64-char "==" / 3base64-char "=" 2386 base64-char = ALPHA / DIGIT / "+" / "/" 2388 ; sub-rules of 'a=' 2389 attribute = (att-field ":" att-value) / att-field 2391 att-field = token 2393 att-value = byte-string 2395 ; sub-rules of 'm=' 2396 media = token 2397 ;typically "audio", "video", "text", "image" 2398 ;or "application" 2400 fmt = token 2401 ;typically an RTP payload type for audio 2402 ;and video media 2404 proto = token *("/" token) 2405 ;typically "RTP/AVP" or "udp" 2407 port = 1*DIGIT 2409 ; generic sub-rules: addressing 2410 unicast-address = IP4-address / IP6-address / FQDN / extn-addr 2412 multicast-address = IP4-multicast / IP6-multicast / FQDN 2413 / extn-addr 2415 IP4-multicast = m1 3( "." decimal-uchar ) 2416 "/" ttl [ "/" numaddr ] 2417 ; IP4 multicast addresses may be in the 2418 ; range 224.0.0.0 to 239.255.255.255 2420 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / 2421 ("23" DIGIT ) 2423 IP6-multicast = IP6-address [ "/" numaddr ] 2424 ; IP6 address starting with FF 2426 numaddr = integer 2428 ttl = (POS-DIGIT *2DIGIT) / "0" 2430 FQDN = 4*(alpha-numeric / "-" / ".") 2431 ; fully qualified domain name as specified 2432 ; in RFC 1035 (and updates) 2434 IP4-address = b1 3("." decimal-uchar) 2436 b1 = decimal-uchar 2437 ; less than "224" 2439 IP6-address = 6( h16 ":" ) ls32 2440 / "::" 5( h16 ":" ) ls32 2441 / [ h16 ] "::" 4( h16 ":" ) ls32 2442 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 2443 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 2444 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 2445 / [ *4( h16 ":" ) h16 ] "::" ls32 2446 / [ *5( h16 ":" ) h16 ] "::" h16 2447 / [ *6( h16 ":" ) h16 ] "::" 2449 h16 = 1*4HEXDIG 2451 ls32 = ( h16 ":" h16 ) / IP4-address 2453 ; Generic for other address families 2454 extn-addr = non-ws-string 2456 ; generic sub-rules: datatypes 2457 text = byte-string 2458 ;default is to interpret this as UTF8 text. 2459 ;ISO 8859-1 requires "a=charset:ISO-8859-1" 2460 ;session-level attribute to be used 2462 byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) 2463 ;any byte except NUL, CR, or LF 2465 non-ws-string = 1*(VCHAR/%x80-FF) 2466 ;string of visible characters 2468 token-char = ALPHA / DIGIT 2469 / "!" / "#" / "$" / "%" / "&" 2470 / "'" ; (single quote) 2471 / "*" / "+" / "-" / "." / "^" / "_" 2472 / "`" ; (Grave accent) 2473 / "{" / "|" / "}" / "~" 2475 token = 1*(token-char) 2477 email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF 2478 ;any byte except NUL, CR, LF, or the quoting 2479 ;characters ()<> 2481 integer = POS-DIGIT *DIGIT 2483 zero-based-integer = "0" / integer 2485 non-zero-int-or-real = integer / non-zero-real 2487 non-zero-real = zero-based-integer "." *DIGIT POS-DIGIT 2489 ; generic sub-rules: primitives 2490 alpha-numeric = ALPHA / DIGIT 2492 POS-DIGIT = %x31-39 ; 1 - 9 2494 decimal-uchar = DIGIT 2495 / POS-DIGIT DIGIT 2496 / ("1" 2*(DIGIT)) 2497 / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) 2498 / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) 2500 ; external references: 2501 ALPHA = 2502 DIGIT = 2503 CRLF = 2504 HEXDIG = 2505 SP = 2506 VCHAR = 2507 URI-reference = 2508 addr-spec = 2510 10. Summary of Changes from RFC 4566 2512 The ABNF rule for IP6-address has been corrected. As a result, the 2513 ABNF rule for IP6-multicast has changed, and the (now unused) rules 2514 for hexpart, hexseq, and hex4 have been removed. 2516 IP4 unicast and multicast addresses in the example SDP descriptions 2517 have been revised per RFCs 5735 and 5771. 2519 Text in Section 5.2 has been revised to clarify the use of local 2520 addresses in case of ICE-like SDP extensions. 2522 Normative and informative references have been updated. 2524 The text regarding the session vs. media-level attribute usage has 2525 been clarified. 2527 The case-insensitivity rules from RFC 4855 have been included in this 2528 document. 2530 11. Acknowledgements 2532 Many people in the IETF Multiparty Multimedia Session Control 2533 (MMUSIC) working group have made comments and suggestions 2534 contributing to this document. 2536 12. References 2538 12.1. Normative References 2540 [E164] International Telecommunication Union, "E.164 : The 2541 international public telecommunication numbering plan", 2542 ITU Recommendation E.164, November 2010. 2544 [I-D.ietf-mmusic-data-channel-sdpneg] 2545 Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., 2546 Marcon, J., and R. Even, "SDP-based Data Channel 2547 Negotiation", draft-ietf-mmusic-data-channel-sdpneg-22 2548 (work in progress), November 2018. 2550 [I-D.ietf-mmusic-sdp-mux-attributes] 2551 Nandakumar, S., "A Framework for SDP Attributes when 2552 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 2553 (work in progress), February 2018. 2555 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2556 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 2557 . 2559 [RFC1035] Mockapetris, P., "Domain names - implementation and 2560 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2561 November 1987, . 2563 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2564 Requirement Levels", BCP 14, RFC 2119, 2565 DOI 10.17487/RFC2119, March 1997, 2566 . 2568 [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration 2569 Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978, 2570 October 2000, . 2572 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2573 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2574 2003, . 2576 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2577 Resource Identifier (URI): Generic Syntax", STD 66, 2578 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2579 . 2581 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2582 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2583 July 2006, . 2585 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2586 Specifications: ABNF", STD 68, RFC 5234, 2587 DOI 10.17487/RFC5234, January 2008, 2588 . 2590 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2591 Media Attributes in the Session Description Protocol 2592 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 2593 . 2595 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 2596 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 2597 September 2009, . 2599 [RFC5890] Klensin, J., "Internationalized Domain Names for 2600 Applications (IDNA): Definitions and Document Framework", 2601 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2602 . 2604 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2605 Writing an IANA Considerations Section in RFCs", BCP 26, 2606 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2607 . 2609 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2610 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2611 May 2017, . 2613 12.2. Informative References 2615 [I-D.ietf-mmusic-ice-sip-sdp] 2616 Petit-Huguenin, M., Nandakumar, S., and A. Keranen, 2617 "Session Description Protocol (SDP) Offer/Answer 2618 procedures for Interactive Connectivity Establishment 2619 (ICE)", draft-ietf-mmusic-ice-sip-sdp-24 (work in 2620 progress), November 2018. 2622 [I-D.ietf-mmusic-sdp-bundle-negotiation] 2623 Holmberg, C., Alvestrand, H., and C. Jennings, 2624 "Negotiating Media Multiplexing Using the Session 2625 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 2626 negotiation-54 (work in progress), December 2018. 2628 [ITU.H332.1998] 2629 International Telecommunication Union, "H.323 extended for 2630 loosely coupled conferences", ITU Recommendation H.332, 2631 September 1998. 2633 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 2634 Protocol", RFC 2327, DOI 10.17487/RFC2327, April 1998, 2635 . 2637 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 2638 Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, 2639 October 2000, . 2641 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2642 A., Peterson, J., Sparks, R., Handley, M., and E. 2643 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2644 DOI 10.17487/RFC3261, June 2002, 2645 . 2647 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2648 with Session Description Protocol (SDP)", RFC 3264, 2649 DOI 10.17487/RFC3264, June 2002, 2650 . 2652 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2653 Jacobson, "RTP: A Transport Protocol for Real-Time 2654 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2655 July 2003, . 2657 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 2658 Video Conferences with Minimal Control", STD 65, RFC 3551, 2659 DOI 10.17487/RFC3551, July 2003, 2660 . 2662 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 2663 Modifiers for RTP Control Protocol (RTCP) Bandwidth", 2664 RFC 3556, DOI 10.17487/RFC3556, July 2003, 2665 . 2667 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2668 in Session Description Protocol (SDP)", RFC 3605, 2669 DOI 10.17487/RFC3605, October 2003, 2670 . 2672 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2673 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2674 RFC 3711, DOI 10.17487/RFC3711, March 2004, 2675 . 2677 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 2678 "Indicating User Agent Capabilities in the Session 2679 Initiation Protocol (SIP)", RFC 3840, 2680 DOI 10.17487/RFC3840, August 2004, 2681 . 2683 [RFC3890] Westerlund, M., "A Transport Independent Bandwidth 2684 Modifier for the Session Description Protocol (SDP)", 2685 RFC 3890, DOI 10.17487/RFC3890, September 2004, 2686 . 2688 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 2689 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 2690 . 2692 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 2693 DOI 10.17487/RFC5322, October 2008, 2694 . 2696 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2697 Protocol (SDP) Grouping Framework", RFC 5888, 2698 DOI 10.17487/RFC5888, June 2010, 2699 . 2701 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 2702 "Network Time Protocol Version 4: Protocol and Algorithms 2703 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 2704 . 2706 [RFC6466] Salgueiro, G., "IANA Registration of the 'image' Media 2707 Type for the Session Description Protocol (SDP)", 2708 RFC 6466, DOI 10.17487/RFC6466, December 2011, 2709 . 2711 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 2712 "TCP Candidates with Interactive Connectivity 2713 Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, 2714 March 2012, . 2716 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2717 Specifications and Registration Procedures", BCP 13, 2718 RFC 6838, DOI 10.17487/RFC6838, January 2013, 2719 . 2721 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2722 Protocol (HTTP/1.1): Message Syntax and Routing", 2723 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2724 . 2726 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 2727 RFC 7405, DOI 10.17487/RFC7405, December 2014, 2728 . 2730 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 2731 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 2732 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 2733 DOI 10.17487/RFC7656, November 2015, 2734 . 2736 [RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 2737 and M. Stiemerling, Ed., "Real-Time Streaming Protocol 2738 Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December 2739 2016, . 2741 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 2742 Connectivity Establishment (ICE): A Protocol for Network 2743 Address Translator (NAT) Traversal", RFC 8445, 2744 DOI 10.17487/RFC8445, July 2018, 2745 . 2747 Authors' Addresses 2749 Ali Begen 2750 Networked Media 2751 Konya 2752 Turkey 2754 EMail: ali.begen@networked.media 2756 Paul Kyzivat 2757 USA 2759 EMail: pkyzivat@alum.mit.edu 2761 Colin Perkins 2762 University of Glasgow 2763 School of Computing Science 2764 University of Glasgow 2765 Glasgow G12 8QQ 2766 UK 2768 EMail: csp@csperkins.org 2769 Mark Handley 2770 University College London 2771 Department of Computer Science 2772 London WC1E 6BT 2773 UK 2775 EMail: M.Handley@cs.ucl.ac.uk