idnits 2.17.1 draft-ietf-mmusic-rfc4566bis-29.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 (June 5, 2018) is 2142 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 2179, but not defined == Missing Reference: 'RFC2848' is mentioned on line 2180, but not defined == Missing Reference: 'RFC3108' is mentioned on line 2185, but not defined == Missing Reference: 'RFC7195' is mentioned on line 2186, but not defined == Missing Reference: 'RFC4145' is mentioned on line 2214, but not defined == Missing Reference: 'RFC6135' is mentioned on line 2215, but not defined == Unused Reference: 'RFC2978' is defined on line 2547, 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-19 == 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 (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-52 -- Obsolete informational reference (is this intentional?): RFC 2327 (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) 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: December 7, 2018 C. Perkins 7 University of Glasgow 8 M. Handley 9 UCL 10 June 5, 2018 12 SDP: Session Description Protocol 13 draft-ietf-mmusic-rfc4566bis-29 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 December 7, 2018. 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=") . . . . . . . . . . . . . . . . . 11 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=") . . . . . . . . . . . . . . . . . 20 94 5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 21 95 5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 22 96 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 24 97 6.1. cat (category) . . . . . . . . . . . . . . . . . . . . . 25 98 6.2. keywds (keywords) . . . . . . . . . . . . . . . . . . . . 25 99 6.3. tool . . . . . . . . . . . . . . . . . . . . . . . . . . 26 100 6.4. ptime (packet time) . . . . . . . . . . . . . . . . . . . 26 101 6.5. maxptime (maximum packet time) . . . . . . . . . . . . . 27 102 6.6. rtpmap . . . . . . . . . . . . . . . . . . . . . . . . . 27 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) . . . . . . . . . . . . . . . . 30 107 6.7.4. inactive . . . . . . . . . . . . . . . . . . . . . . 31 108 6.8. orient (orientation) . . . . . . . . . . . . . . . . . . 31 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) . . . . . . . . . . . . . . . . . . . . . 34 113 6.13. framerate (frame rate) . . . . . . . . . . . . . . . . . 36 114 6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 36 115 6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 37 116 7. Security Considerations . . . . . . . . . . . . . . . . . . . 37 117 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 118 8.1. The "application/sdp" Media Type . . . . . . . . . . . . 39 119 8.2. Registration of Parameters . . . . . . . . . . . . . . . 40 120 8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 41 121 8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 41 122 8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 42 123 8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 42 124 8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 45 125 8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 45 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 . . . . . . . 47 131 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 48 132 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 53 133 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54 134 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 135 12.1. Normative References . . . . . . . . . . . . . . . . . . 54 136 12.2. Informative References . . . . . . . . . . . . . . . . . 55 137 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 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, and the Hypertext Transport Protocol (HTTP). 155 SDP is intended to be general purpose so that it can be used in a 156 wide range of network environments and applications. However, it is 157 not intended to support negotiation of session content or media 158 encodings: this is viewed as outside the scope of session 159 description. 161 This memo obsoletes [RFC4566]. The changes relative to [RFC4566] are 162 limited to essential corrections, and are outlined in Section 10 of 163 this memo. 165 2. Glossary of Terms 167 The following terms are used in this document and have specific 168 meaning within the context of this document. 170 Session Description: A well-defined format for conveying sufficient 171 information to discover and participate in a multimedia session. 173 Media Description: A media description starts with an "m=" line and 174 is terminated by either the next "m=" line or by the end of the 175 session description. 177 Session-level Section: This refers to the parts that are not media 178 descriptions, whereas the session description refers to the whole 179 body that includes the session-level section and the media 180 description(s). 182 The terms "multimedia conference" and "multimedia session" are used 183 in this document as defined in [RFC7656]. The terms "session" and 184 "multimedia session" are used interchangeably in this document. 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 188 "OPTIONAL" in this document are to be interpreted as described in BCP 189 14 [RFC2119] [RFC8174] when, and only when, they appear in all 190 capitals, as shown here. 192 3. Examples of SDP Usage 194 3.1. Session Initiation 196 The Session Initiation Protocol (SIP) [RFC3261] is an application- 197 layer control protocol for creating, modifying, and terminating 198 sessions such as Internet multimedia conferences, Internet telephone 199 calls, and multimedia distribution. The SIP messages used to create 200 sessions carry session descriptions that allow participants to agree 201 on a set of compatible media types. These session descriptions are 202 commonly formatted using SDP. When used with SIP, the offer/answer 203 model [RFC3264] provides a limited framework for negotiation using 204 SDP. 206 3.2. Streaming Media 208 The Real Time Streaming Protocol (RTSP) [RFC7826], is an application- 209 level protocol for control over the delivery of data with real-time 210 properties. RTSP provides an extensible framework to enable 211 controlled, on-demand delivery of real-time data, such as audio and 212 video. An RTSP client and server negotiate an appropriate set of 213 parameters for media delivery, partially using SDP syntax to describe 214 those parameters. 216 3.3. Email and the World Wide Web 218 Alternative means of conveying session descriptions include 219 electronic mail and the World Wide Web (WWW). For both email and WWW 220 distribution, the media type "application/sdp" is used. This enables 221 the automatic launching of applications for participation in the 222 session from the WWW client or mail reader in a standard manner. 224 Note that announcements of multicast sessions made only via email or 225 the WWW do not have the property that the receiver of a session 226 announcement can necessarily receive the session because the 227 multicast sessions may be restricted in scope, and access to the WWW 228 server or reception of email is possible outside this scope. 230 3.4. Multicast Session Announcement 232 In order to assist the advertisement of multicast multimedia 233 conferences and other multicast sessions, and to communicate the 234 relevant session setup information to prospective participants, a 235 distributed session directory may be used. An instance of such a 236 session directory periodically sends packets containing a description 237 of the session to a well-known multicast group. These advertisements 238 are received by other session directories such that potential remote 239 participants can use the session description to start the tools 240 required to participate in the session. 242 One protocol used to implement such a distributed directory is the 243 SAP [RFC2974]. SDP provides the recommended session description 244 format for such session announcements. 246 4. Requirements and Recommendations 248 The purpose of SDP is to convey information about media streams in 249 multimedia sessions to allow the recipients of a session description 250 to participate in the session. SDP is primarily intended for use in 251 an internetwork, although it is sufficiently general that it can 252 describe multimedia conferences in other network environments. Media 253 streams can be many-to-many. Sessions need not be continually 254 active. 256 Thus far, multicast-based sessions on the Internet have differed from 257 many other forms of conferencing in that anyone receiving the traffic 258 can join the session (unless the session traffic is encrypted). In 259 such an environment, SDP serves two primary purposes. It is a means 260 to communicate the existence of a session, and it is a means to 261 convey sufficient information to enable joining and participating in 262 the session. In a unicast environment, only the latter purpose is 263 likely to be relevant. 265 An SDP description includes the following: 267 o Session name and purpose 269 o Time(s) the session is active 271 o The media comprising the session 273 o Information needed to receive those media (addresses, ports, 274 formats, etc.) 276 As resources necessary to participate in a session may be limited, 277 some additional information may also be desirable: 279 o Information about the bandwidth to be used by the session 281 o Contact information for the person responsible for the session 283 In general, SDP must convey sufficient information to enable 284 applications to join a session (with the possible exception of 285 encryption keys) and to announce the resources to be used to any non- 286 participants that may need to know. (This latter feature is 287 primarily useful when SDP is used with a multicast session 288 announcement protocol.) 290 4.1. Media and Transport Information 292 An SDP description includes the following media information: 294 o The type of media (video, audio, etc.) 296 o The media transport protocol (RTP/UDP/IP, H.320, etc.) 298 o The format of the media (H.261 video, MPEG video, etc.) 300 In addition to media format and transport protocol, SDP conveys 301 address and port details. For an IP multicast session, these 302 comprise: 304 o The multicast group address for media 306 o The transport port for media 308 This address and port is the destination address and destination port 309 of the multicast stream, whether being sent, received, or both. 311 For unicast IP sessions, the following are conveyed: 313 o The remote address for media 315 o The remote transport port for media 317 The semantics of this address and port depend on the media and 318 transport protocol defined. By default, this SHOULD be the remote 319 address and remote port to which data is sent. Some media types may 320 redefine this behaviour, but this is NOT RECOMMENDED since it 321 complicates implementations (including middleboxes that must parse 322 the addresses to open Network Address Translation (NAT) or firewall 323 pinholes). 325 4.2. Timing Information 327 Sessions may be either bounded or unbounded in time. Whether or not 328 they are bounded, they may be only active at specific times. SDP can 329 convey: 331 o An arbitrary list of start and stop times bounding the session 333 o For each bound, repeat times such as "every Wednesday at 10am for 334 one hour" 336 This timing information is globally consistent, irrespective of local 337 time zone or daylight saving time (see Section 5.9). 339 4.3. Obtaining Further Information about a Session 341 A session description could convey enough information to decide 342 whether or not to participate in a session. SDP may include 343 additional pointers in the form of Uniform Resource Identifiers 344 (URIs) for more information about the session. 346 4.4. Categorization 348 When many session descriptions are being distributed by an 349 advertisement mechanism, it may be desirable to filter session 350 announcements that are of interest from those that are not. SDP 351 supports a categorization mechanism for sessions that is capable of 352 being automated (the "a=cat:" attribute; see Section 6). 354 4.5. Internationalization 356 The SDP specification recommends the use of the ISO 10646 character 357 set in the UTF-8 encoding [RFC3629] to allow many different languages 358 to be represented. However, to assist in compact representations, 359 SDP also allows other character sets such as ISO 8859-1 to be used 360 when desired. Internationalization only applies to free-text sub- 361 fields (session name and background information), and not to SDP as a 362 whole. 364 5. SDP Specification 366 An SDP description is denoted by the media type "application/sdp" 367 (See Section 8). 369 An SDP description is entirely textual. SDP field names and 370 attribute names use only the US-ASCII subset of UTF-8, but textual 371 fields and attribute values MAY use the full ISO 10646 character set 372 in UTF-8 encoding, or some other character set defined by the 373 "a=charset:" attribute. Field and attribute values that use the full 374 UTF-8 character set are never directly compared, hence there is no 375 requirement for UTF-8 normalization. The textual form, as opposed to 376 a binary encoding such as ASN.1 or XDR, was chosen to enhance 377 portability, to enable a variety of transports to be used, and to 378 allow flexible, text-based toolkits to be used to generate and 379 process session descriptions. However, since SDP may be used in 380 environments where the maximum permissible size of a session 381 description is limited, the encoding is deliberately compact. Also, 382 since announcements may be transported via very unreliable means or 383 damaged by an intermediate caching server, the encoding was designed 384 with strict order and formatting rules so that most errors would 385 result in malformed session announcements that could be detected 386 easily and discarded. This also allows rapid discarding of encrypted 387 session announcements for which a receiver does not have the correct 388 key. 390 An SDP description consists of a number of lines of text of the form: 392 = 394 where MUST be exactly one case-significant character and 395 is structured text whose format depends on . In 396 general, is either a number of sub-fields delimited by a 397 single space character or a free format string, and is case- 398 significant unless a specific field defines otherwise. Whitespace 399 separators MUST NOT be used on either side of the "=" sign, however, 400 the value can contain a leading whitespace as part of its syntax, 401 i.e., that whitespace is part of the value. 403 An SDP description consists of a session-level section followed by 404 zero or more media descriptions. The session-level section starts 405 with a "v=" line and continues to the first media description (or the 406 end of the whole description, whichever comes first). Each media 407 description starts with an "m=" line and continues to the next media 408 description or the end of the whole session description - whichever 409 comes first. In general, session-level values are the default for 410 all media unless overridden by an equivalent media-level value. 412 Some lines in each description are REQUIRED and some are OPTIONAL, 413 but all MUST appear in exactly the order given here (the fixed order 414 greatly enhances error detection and allows for a simple parser). 415 OPTIONAL items are marked with a "*". 417 Session description 418 v= (protocol version) 419 o= (originator and session identifier) 420 s= (session name) 421 i=* (session information) 422 u=* (URI of description) 423 e=* (email address) 424 p=* (phone number) 425 c=* (connection information -- not required if included in 426 all media descriptions) 427 b=* (zero or more bandwidth information lines) 428 One or more time descriptions: 429 ("t=", "r=" and "z=" lines; see below) 430 k=* (encryption key) 431 a=* (zero or more session attribute lines) 432 Zero or more media descriptions 434 Time description 435 t= (time the session is active) 436 r=* (zero or more repeat times) 437 z= (optional time zone offset line) 439 Media description, if present 440 m= (media name and transport address) 441 i=* (media title) 442 c=* (connection information -- optional if included at 443 session level) 444 b=* (zero or more bandwidth information lines) 445 k=* (encryption key) 446 a=* (zero or more media attribute lines) 448 The set of type letters is deliberately small and not intended to be 449 extensible -- an SDP parser MUST completely ignore any session 450 description that contains a type letter that it does not understand. 451 The attribute mechanism ("a=" described below) is the primary means 452 for extending SDP and tailoring it to particular applications or 453 media. Some attributes (the ones listed in Section 6 of this memo) 454 have a defined meaning, but others may be added on an application-, 455 media-, or session-specific basis. An SDP parser MUST ignore any 456 attribute it doesn't understand. 458 An SDP description may contain URIs that reference external content 459 in the "u=", "k=", and "a=" lines. These URIs may be dereferenced in 460 some cases, making the session description non-self-contained. 462 The connection ("c=") information in the session-level section 463 applies to all the media descriptions of that session unless 464 overridden by connection information in the media description. For 465 instance, in the example below, each audio media description behaves 466 as if it were given a "c=IN IP4 233.252.0.2". 468 An example SDP description is: 470 v=0 471 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 472 s=SDP Seminar 473 i=A Seminar on the session description protocol 474 u=http://www.example.com/seminars/sdp.pdf 475 e=j.doe@example.com (Jane Doe) 476 c=IN IP4 233.252.0.2 477 t=2873397496 2873404696 478 a=recvonly 479 m=audio 49170 RTP/AVP 0 480 m=audio 49180 RTP/AVP 0 481 m=video 51372 RTP/AVP 99 482 c=IN IP4 233.252.0.1/127 483 a=rtpmap:99 h263-1998/90000 485 Text containing fields such as the session-name-field and 486 information-field are octet strings that may contain any octet with 487 the exceptions of 0x00 (Nul), 0x0a (ASCII newline), and 0x0d (ASCII 488 carriage return). The sequence CRLF (0x0d0a) is used to end a 489 record, although parsers SHOULD be tolerant and also accept records 490 terminated with a single newline character. If the "a=charset" 491 attribute is not present, these octet strings MUST be interpreted as 492 containing ISO-10646 characters in UTF-8 encoding (the presence of 493 the "a=charset" attribute may force some fields to be interpreted 494 differently). 496 A session description can contain domain names in the "o=", "u=", 497 "e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply 498 with [RFC1034], [RFC1035]. Internationalized domain names (IDNs) 499 MUST be represented using the ASCII Compatible Encoding (ACE) form 500 defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or 501 any other encoding (this requirement is for compatibility with 502 [RFC2327] and other early SDP-related standards, which predate the 503 development of internationalized domain names). 505 5.1. Protocol Version ("v=") 507 v=0 509 The "v=" line (version-field) gives the version of the Session 510 Description Protocol. This memo defines version 0. There is no 511 minor version number. 513 5.2. Origin ("o=") 515 o= 516 518 The "o=" line (origin-field) gives the originator of the session (her 519 username and the address of the user's host) plus a session 520 identifier and version number: 522 is the user's login on the originating host, or it is "-" 523 if the originating host does not support the concept of user IDs. 524 The MUST NOT contain spaces. 526 is a numeric string such that the tuple of , 527 , , , and forms a 528 globally unique identifier for the session. The method of allocation is up to the creating tool, but it has been 530 suggested that a Network Time Protocol (NTP) format timestamp be 531 used to ensure uniqueness [RFC5905]. 533 is a version number for this session description. 534 Its usage is up to the creating tool, so long as is 535 increased when a modification is made to the session data. Again, 536 it is RECOMMENDED that an NTP format timestamp is used. 538 is a text string giving the type of network. Initially 539 "IN" is defined to have the meaning "Internet", but other values 540 MAY be registered in the future (see Section 8). 542 is a text string giving the type of the address that 543 follows. Initially "IP4" and "IP6" are defined, but other values 544 MAY be registered in the future (see Section 8). 546 is an address of the machine from which the 547 session was created. For an address type of IP4, this is either a 548 fully qualified domain name of the machine or the dotted-decimal 549 representation of an IP version 4 address of the machine. For an 550 address type of IP6, this is either a fully qualified domain name 551 of the machine or the compressed textual representation of an IP 552 version 6 address of the machine. For both IP4 and IP6, the fully 553 qualified domain name is the form that SHOULD be given unless this 554 is unavailable, in which case a globally unique address MAY be 555 substituted. Unless an SDP extension for NAT traversal is used 556 (e.g., ICE [RFC5245], ICE TCP [RFC6544]), a local IP address MUST 557 NOT be used in any context where the SDP description might leave 558 the scope in which the address is meaningful (for example, a local 559 address MUST NOT be included in an application-level referral that 560 might leave the scope). 562 In general, the "o=" line serves as a globally unique identifier for 563 this version of the session description, and the sub-fields excepting 564 the version, taken together identify the session irrespective of any 565 modifications. 567 For privacy reasons, it is sometimes desirable to obfuscate the 568 username and IP address of the session originator. If this is a 569 concern, an arbitrary and private MAY be 570 chosen to populate the "o=" line, provided that these are selected in 571 a manner that does not affect the global uniqueness of the field. 573 5.3. Session Name ("s=") 575 s= 577 The "s=" line (session-name-field) is the textual session name. 578 There MUST be one and only one "s=" line per session description. 579 The "s=" line MUST NOT be empty and SHOULD contain ISO 10646 580 characters (but see also the "a=charset" attribute). If a session 581 has no meaningful name, the "s= " line SHOULD be used (i.e., a single 582 space as the session name). 584 5.4. Session Information ("i=") 586 i= 588 The "i=" line (information-field) provides textual information about 589 the session. There MUST be at most one session-level "i=" line per 590 session description, and at most one "i=" line in each media 591 description. Unless a media level "i=" line is provided, the 592 session-level "i=" line applies to that media description. If the 593 "a=charset" attribute is present, it specifies the character set used 594 in the "i=" line. If the "a=charset" attribute is not present, the 595 "i=" line MUST contain ISO 10646 characters in UTF-8 encoding. 597 At most one "i=" line can be used for each media description. In 598 media definitions, "i=" lines are primarily intended for labelling 599 media streams. As such, they are most likely to be useful when a 600 single session has more than one distinct media stream of the same 601 media type. An example would be two different whiteboards, one for 602 slides and one for feedback and questions. 604 The "i=" line is intended to provide a free-form human-readable 605 description of the session or the purpose of a media stream. It is 606 not suitable for parsing by automata. 608 5.5. URI ("u=") 610 u= 612 The "u=" line (uri-field) provides URI (Uniform Resource Identifier) 613 as used by WWW clients [RFC3986]. The URI should be a pointer to 614 additional information about the session. This line is OPTIONAL. No 615 more than one "u=" line is allowed per session description. 617 5.6. Email Address and Phone Number ("e=" and "p=") 619 e= 620 p= 622 The "e=" line (email-field) and "p=" line (phone-field) specify 623 contact information for the person responsible for the session. This 624 is not necessarily the same person that created the session 625 description. 627 Inclusion of an email address or phone number is OPTIONAL. 629 If an email address or phone number is present, it MUST be specified 630 before the first media description. More than one email or phone 631 line can be given for a session description. 633 Phone numbers SHOULD be given in the form of an international public 634 telecommunication number (see ITU-T Recommendation E.164 [E164]) 635 preceded by a "+". Spaces and hyphens may be used to split up a 636 phone-field to aid readability if desired. For example: 638 p=+1 617 555-6011 640 Both email addresses and phone numbers can have an OPTIONAL free text 641 string associated with them, normally giving the name of the person 642 who may be contacted. This MUST be enclosed in parentheses if it is 643 present. For example: 645 e=j.doe@example.com (Jane Doe) 647 The alternative [RFC5322] name quoting convention is also allowed for 648 both email addresses and phone numbers. For example: 650 e=Jane Doe 652 The free text string SHOULD be in the ISO-10646 character set with 653 UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if 654 the appropriate session-level "a=charset" attribute is set. 656 5.7. Connection Information ("c=") 658 c= 660 The "c=" line (connection-field) contains connection data. 662 A session description MUST contain either at least one "c=" line in 663 each media description or a single "c=" line at the session level. 664 It MAY contain a single session-level "c=" line and additional "c=" 665 line(s) per media description, in which case the per-media values 666 override the session-level settings for the respective media. 668 The first sub-field ("") is the network type, which is a 669 text string giving the type of network. Initially, "IN" is defined 670 to have the meaning "Internet", but other values MAY be registered in 671 the future (see Section 8). 673 The second sub-field ("") is the address type. This allows 674 SDP to be used for sessions that are not IP based. This memo only 675 defines IP4 and IP6, but other values MAY be registered in the future 676 (see Section 8). 678 The third sub-field ("") is the connection 679 address. Additional sub-fields MAY be added after the connection 680 address depending on the value of the sub-field. 682 When the is IP4 and IP6, the connection address is defined 683 as follows: 685 o If the session is multicast, the connection address will be an IP 686 multicast group address. If the session is not multicast, then 687 the connection address contains the unicast IP address of the 688 expected data source, data relay or data sink as determined by 689 additional attribute-fields. It is not expected that unicast 690 addresses will be given in a session description that is 691 communicated by a multicast announcement, though this is not 692 prohibited. 694 o Sessions using an IP4 multicast connection address MUST also have 695 a time to live (TTL) value present in addition to the multicast 696 address. The TTL and the address together define the scope with 697 which multicast packets sent in this session will be sent. TTL 698 values MUST be in the range 0-255. Although the TTL MUST be 699 specified, its use to scope multicast traffic is deprecated; 700 applications SHOULD use an administratively scoped address 701 instead. 703 The TTL for the session is appended to the address using a slash as a 704 separator. An example is: 706 c=IN IP4 233.252.0.1/127 708 IP6 multicast does not use TTL scoping, and hence the TTL value MUST 709 NOT be present for IP6 multicast. It is expected that IP6 scoped 710 addresses will be used to limit the scope of multimedia conferences. 712 Hierarchical or layered encoding schemes are data streams where the 713 encoding from a single media source is split into a number of layers. 714 The receiver can choose the desired quality (and hence bandwidth) by 715 only subscribing to a subset of these layers. Such layered encodings 716 are normally transmitted in multiple multicast groups to allow 717 multicast pruning. This technique keeps unwanted traffic from sites 718 only requiring certain levels of the hierarchy. For applications 719 requiring multiple multicast groups, we allow the following notation 720 to be used for the connection address: 722 [/]/ 724 If the number of addresses is not given, it is assumed to be one. 725 Multicast addresses so assigned are contiguously allocated above the 726 base address, so that, for example: 728 c=IN IP4 233.252.0.1/127/3 730 would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3 731 are to be used with a TTL of 127. This is semantically identical to 732 including multiple "c=" lines in a media description: 734 c=IN IP4 233.252.0.1/127 735 c=IN IP4 233.252.0.2/127 736 c=IN IP4 233.252.0.3/127 738 Similarly, an IP6 example would be: 740 c=IN IP6 FF15::101/3 742 which is semantically equivalent to: 744 c=IN IP6 FF15::101 745 c=IN IP6 FF15::102 746 c=IN IP6 FF15::103 748 (remembering that the TTL sub-field is not present in IP6 multicast). 750 Multiple addresses or "c=" lines MAY be specified on a per media 751 description basis only if they provide multicast addresses for 752 different layers in a hierarchical or layered encoding scheme. They 753 MUST NOT be specified for a session-level "c=" line. 755 The slash notation for multiple addresses described above MUST NOT be 756 used for IP unicast addresses. 758 5.8. Bandwidth Information ("b=") 760 b=: 762 The OPTIONAL "b=" line (bandwidth-field) denotes the proposed 763 bandwidth to be used by the session or media description. The 764 is an alphanumeric modifier giving the meaning of the 765 figure. Two values are defined in this specification, 766 but other values MAY be registered in the future (see Section 8 and 767 [RFC3556], [RFC3890]): 769 CT If the bandwidth of a session is different from the bandwidth 770 implicit from the scope, a "b=CT:..." line SHOULD be supplied for 771 the session giving the proposed upper limit to the bandwidth used 772 (the "conference total" bandwidth). Similarly, if the bandwidth 773 of bundled media streams in an m line is different from the 774 implicit value from the scope, a "b=CT:..." line SHOULD be 775 supplied in the media level. The primary purpose of this is to 776 give an approximate idea as to whether two or more sessions (or 777 bundled media streams) can coexist simultaneously. Note that CT 778 gives a total bandwidth figure for all the media at all endpoints. 780 AS The bandwidth is interpreted to be application specific (it will 781 be the application's concept of maximum bandwidth). Normally, 782 this will coincide with what is set on the application's "maximum 783 bandwidth" control if applicable. For RTP-based applications, AS 784 gives the RTP "session bandwidth" as defined in Section 6.2 of 785 [RFC3550]. Note that AS gives a bandwidth figure for a single 786 media at a single endpoint, although there may be many endpoints 787 sending simultaneously. 789 A prefix "X-" is defined for names. This is intended for 790 experimental purposes only. For example: 792 b=X-YZ:128 794 Use of the "X-" prefix is NOT RECOMMENDED: instead new (non "X-" 795 prefix) names SHOULD be defined, and then MUST be registered 796 with IANA in the standard namespace. SDP parsers MUST ignore 797 bandwidth-fields with unknown names. The names 798 MUST be alphanumeric and, although no length limit is given, it is 799 recommended that they be short. 801 The is interpreted as kilobits per second by default 802 (including the transport and network-layer but not the link-layer 803 overhead). The definition of a new modifier MAY specify 804 that the bandwidth is to be interpreted in some alternative unit (the 805 "CT" and "AS" modifiers defined in this memo use the default units). 807 5.9. Time Active ("t=") 809 t= 811 A "t=" line (time-field) initiates a time description that specifies 812 the start and stop times for a session. Multiple time descriptions 813 MAY be used if a session is active at multiple irregularly spaced 814 times; each additional time description specifies additional periods 815 of time for which the session will be active. If the session is 816 active at regular repeat times, a repeat description, initiated by an 817 "r=" line (see below) can be included following the time-field -- in 818 which case the time-field specifies the start and stop times of the 819 entire repeat sequence. 821 The first and second sub-fields of the time-field give the start and 822 stop times, respectively, for the session. These values are the 823 decimal representation of Network Time Protocol (NTP) time values in 824 seconds since 1900 [RFC5905]. To convert these values to UNIX time 825 (UTC), subtract decimal 2208988800. 827 NTP timestamps are elsewhere represented by 64-bit values, which wrap 828 sometime in the year 2036. Since SDP uses an arbitrary length 829 decimal representation, this should not cause an issue (SDP 830 timestamps MUST continue counting seconds since 1900 - NTP will use 831 the value modulo the 64-bit limit). 833 If the is set to zero, then the session is not bounded, 834 though it will not become active until after the . If 835 the is also zero, the session is regarded as permanent. 837 User interfaces SHOULD strongly discourage the creation of unbounded 838 and permanent sessions as they give no information about when the 839 session is actually going to terminate, and so make scheduling 840 difficult. 842 The general assumption may be made, when displaying unbounded 843 sessions that have not timed out to the user, that an unbounded 844 session will only be active until half an hour from the current time 845 or the session start time, whichever is the later. If behaviour 846 other than this is required, an end-time SHOULD be given and modified 847 as appropriate when new information becomes available about when the 848 session should really end. 850 Permanent sessions may be shown to the user as never being active 851 unless there are associated repeat times that state precisely when 852 the session will be active. 854 5.10. Repeat Times ("r=") 856 r= 858 An"r=" line (repeat-field) specifies repeat times for a session. If 859 needed to express complex schedules, multiple repeat-fields may be 860 included. For example, if a session is active at 10am on Monday and 861 11am on Tuesday for one hour each week for three months, then the 862 in the corresponding "t=" line would be the NTP 863 representation of 10am on the first Monday, the 864 would be 1 week, the would be 1 hour, and the 865 offsets would be zero and 25 hours. The corresponding "t=" line stop 866 time would be the NTP representation of the end of the last session 867 three months later. By default, all sub-fields are in seconds, so 868 the "r=" and "t=" lines might be the following: 870 t=3034423619 3042462419 871 r=604800 3600 0 90000 873 To make the description more compact, times may also be given in 874 units of days, hours, or minutes. The syntax for these is a number 875 immediately followed by a single case-sensitive character. 876 Fractional units are not allowed -- a smaller unit should be used 877 instead. The following unit specification characters are allowed: 879 d - days (86400 seconds) 880 h - hours (3600 seconds) 881 m - minutes (60 seconds) 882 s - seconds (allowed for completeness) 884 Thus, the above session announcement could also have been written: 886 r=7d 1h 0 25h 888 Monthly and yearly repeats cannot be directly specified with a single 889 SDP repeat time; instead, separate time-descriptions should be used 890 to explicitly list the session times. 892 5.11. Time Zone Adjustment ("z=") 894 z= .... 896 A "z=" line (zone-field) is an optional modifier to the repeat-fields 897 it immediately follows. It does not apply to any other fields. 899 To schedule a repeated session that spans a change from daylight 900 saving time to standard time or vice versa, it is necessary to 901 specify offsets from the base time. This is required because 902 different time zones change time at different times of day, different 903 countries change to or from daylight saving time on different dates, 904 and some countries do not have daylight saving time at all. 906 Thus, in order to schedule a session that is at the same time winter 907 and summer, it must be possible to specify unambiguously by whose 908 time zone a session is scheduled. To simplify this task for 909 receivers, we allow the sender to specify the NTP time that a time 910 zone adjustment happens and the offset from the time when the session 911 was first scheduled. The "z=" line allows the sender to specify a 912 list of these adjustment times and offsets from the base time. 914 An example might be the following: 916 z=2882844526 -1h 2898848070 0 918 This specifies that at time 2882844526, the time base by which the 919 session's repeat times are calculated is shifted back by 1 hour, and 920 that at time 2898848070, the session's original time base is 921 restored. Adjustments are always relative to the specified start 922 time -- they are not cumulative. Adjustments apply to all "t=" and 923 "r=" lines in a session description. 925 If a session is likely to last several years, it is expected that the 926 session description will be modified periodically rather than 927 transmit several years' worth of adjustments in one session 928 description. 930 5.12. Encryption Keys ("k=") 932 k= 933 k=: 935 The "k=" line (key-field) is obsolete and MUST NOT be used. It is 936 included in this document for legacy reasons. One MUST NOT include a 937 "k=" line in an SDP, and MUST discard it if it is received in an SDP. 939 5.13. Attributes ("a=") 941 a= 942 a=: 944 Attributes are the primary means for extending SDP. Attributes may 945 be defined to be used as "session-level" attributes, "media-level" 946 attributes, or both. 948 A media description may contain any number of "a=" lines (attribute- 949 fields) that are media description specific. These are referred to 950 as "media-level" attributes and add information about the media 951 description. Attribute-fields can also be added before the first 952 media description; these "session-level" attributes convey additional 953 information that applies to the session as a whole rather than to 954 individual media descriptions. 956 Attribute-fields may be of two forms: 958 o A property attribute is simply of the form "a=". These 959 are binary attributes, and the presence of the attribute conveys 960 that the attribute is a property of the session. An example might 961 be "a=recvonly". 963 o A value attribute is of the form "a=:". For 964 example, a whiteboard could have the value attribute 965 "a=orient:landscape" 967 Attribute interpretation depends on the media tool being invoked. 968 Thus receivers of session descriptions should be configurable in 969 their interpretation of session descriptions in general and of 970 attributes in particular. 972 Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. 974 Attribute values are octet strings, and MAY use any octet value 975 except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute 976 values are to be interpreted as in ISO-10646 character set with UTF-8 977 encoding. Unlike other text fields, attribute values are NOT 978 normally affected by the "charset" attribute as this would make 979 comparisons against known values problematic. However, when an 980 attribute is defined, it can be defined to be charset dependent, in 981 which case its value should be interpreted in the session charset 982 rather than in ISO-10646. 984 Attributes MUST be registered with IANA (see Section 8). If an 985 attribute is received that is not understood, it MUST be ignored by 986 the receiver. 988 5.14. Media Descriptions ("m=") 990 m= ... 992 A session description may contain a number of media descriptions. 993 Each media description starts with an "m=" line (media-field) and is 994 terminated by either the next "m=" line or by the end of the session 995 description. A media-field has several sub-fields: 997 is the media type. This document defines the values 998 "audio", "video", "text", "application", and "message". This list 999 is extended by other memos and may be further extended by 1000 additional memos registering media types in the future (see 1001 Section 8). For example, [RFC6466] defined the "image" media 1002 type. 1004 is the transport port to which the media stream is sent. The 1005 meaning of the transport port depends on the network being used as 1006 specified in the relevant "c=" line, and on the transport protocol 1007 defined in the sub-field of the media-field. Other ports 1008 used by the media application (such as the RTP Control Protocol 1009 (RTCP) port [RFC3550]) MAY be derived algorithmically from the 1010 base media port or MAY be specified in a separate attribute (for 1011 example, "a=rtcp:" as defined in [RFC3605]). 1013 If non-contiguous ports are used or if they don't follow the 1014 parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" 1015 attribute MUST be used. Applications that are requested to send 1016 media to a that is odd and where the "a=rtcp:" is present 1017 MUST NOT subtract 1 from the RTP port: that is, they MUST send the 1018 RTP to the port indicated in and send the RTCP to the port 1019 indicated in the "a=rtcp" attribute. 1021 For applications where hierarchically encoded streams are being 1022 sent to a unicast address, it may be necessary to specify multiple 1023 transport ports. This is done using a similar notation to that 1024 used for IP multicast addresses in the "c=" line: 1026 m= / ... 1028 In such a case, the ports used depend on the transport protocol. 1029 For RTP, the default is that only the even-numbered ports are used 1030 for data with the corresponding one-higher odd ports used for the 1031 RTCP belonging to the RTP session, and the 1032 denoting the number of RTP sessions. For example: 1034 m=video 49170/2 RTP/AVP 31 1036 would specify that ports 49170 and 49171 form one RTP/RTCP pair 1037 and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the 1038 transport protocol and 31 is the format (see below). If non- 1039 contiguous ports are required, they must be signalled using a 1040 separate attribute (for example, "a=rtcp:" as defined in 1041 [RFC3605]). 1043 If multiple addresses are specified in the "c=" line and multiple 1044 ports are specified in the "m=" line, a one-to-one mapping from 1045 port to the corresponding address is implied. For example: 1047 c=IN IP4 233.252.0.1/127/2 1048 m=video 49170/2 RTP/AVP 31 1050 would imply that address 233.252.0.1 is used with ports 49170 and 1051 49171, and address 233.252.0.2 is used with ports 49172 and 49173. 1053 This document provides no semantics for using multiple "m=" lines 1054 using the same transport address. This implies that, unlike 1055 limited past practice, there is no implicit grouping defined by 1056 such means and an explicit grouping framework (for example, 1057 [RFC5888]) should instead be used to express the intended 1058 semantics. Such semantics may alo be added as extensions. For 1059 instance, see [I-D.ietf-mmusic-sdp-bundle-negotiation]. 1061 is the transport protocol. The meaning of the transport 1062 protocol is dependent on the address type sub-field in the 1063 relevant "c=" line. Thus a "c=" line with an address type of IP4 1064 indicates that the transport protocol runs over IP4. The 1065 following transport protocols are defined, but may be extended 1066 through registration of new protocols with IANA (see Section 8): 1068 * udp: denotes that the data is transported directly in UDP with 1069 no additional framing. 1071 * RTP/AVP: denotes RTP [RFC3550] used under the RTP Profile for 1072 Audio and Video Conferences with Minimal Control [RFC3551] 1073 running over UDP. 1075 * RTP/SAVP: denotes the Secure Real-time Transport Protocol 1076 [RFC3711] running over UDP. 1078 The main reason to specify the transport protocol in addition to 1079 the media format is that the same standard media formats may be 1080 carried over different transport protocols even when the network 1081 protocol is the same -- a historical example is VAT (MBone's 1082 popular multimedia audio tool) Pulse Code Modulation (PCM) audio 1083 and RTP PCM audio; another might be TCP/RTP PCM audio. In 1084 addition, relays and monitoring tools that are transport-protocol- 1085 specific but format-independent are possible. 1087 is a media format description. The fourth and any subsequent 1088 sub-fields describe the format of the media. The interpretation 1089 of the media format depends on the value of the sub-field. 1091 If the sub-field is "RTP/AVP" or "RTP/SAVP" the sub- 1092 fields contain RTP payload type numbers. When a list of payload 1093 type numbers is given, this implies that all of these payload 1094 formats MAY be used in the session, but the first of these formats 1095 SHOULD be used as the default format for the session. For dynamic 1096 payload type assignments the "a=rtpmap:" attribute (see Section 6) 1097 SHOULD be used to map from an RTP payload type number to a media 1098 encoding name that identifies the payload format. The "a=fmtp:" 1099 attribute MAY be used to specify format parameters (see 1100 Section 6). 1102 If the sub-field is "udp" the sub-fields MUST 1103 reference a media type describing the format under the "audio", 1104 "video", "text", "application", or "message" top-level media 1105 types. The media type registration SHOULD define the packet 1106 format for use with UDP transport. 1108 For media using other transport protocols, the sub-field is 1109 protocol specific. Rules for interpretation of the sub- 1110 field MUST be defined when registering new protocols (see 1111 Section 8.2.2). 1113 Section 3 of [RFC4855] states that the payload format (encoding) 1114 names defined in the RTP Profile are commonly shown in upper case, 1115 while media subtype names are commonly shown in lower case. It 1116 also states that both of these names are case-insensitive in both 1117 places, similar to parameter names which are case-insensitive both 1118 in media type strings and in the default mapping to the SDP a=fmtp 1119 attribute. 1121 6. SDP Attributes 1123 The following attributes are defined. Since application writers may 1124 add new attributes as they are required, this list is not exhaustive. 1125 Registration procedures for new attributes are defined in 1126 Section 8.2.4. Syntax is provided using ABNF [RFC7405] with some of 1127 the rules defined further in Section 9. 1129 6.1. cat (category) 1131 Name: cat 1133 Value: cat-value 1135 Usage Level: session 1137 Charset Dependent: no 1139 Syntax: 1141 cat-value = category 1142 category = non-ws-string 1144 Example: 1146 a=cat:foo.bar 1148 This attribute gives the dot-separated hierarchical category of the 1149 session. This is to enable a receiver to filter unwanted sessions by 1150 category. There is no central registry of categories. This 1151 attribute is obsoleted. 1153 6.2. keywds (keywords) 1155 Name: keywds 1157 Value: keywds-value 1159 Usage Level: session 1161 Charset Dependent: yes 1163 Syntax: 1165 keywds-value = keywords 1166 keywords = text 1168 Example: 1170 a=keywds:SDP session description protocol 1172 Like the cat attribute, this is to assist identifying wanted sessions 1173 at the receiver. This allows a receiver to select interesting 1174 sessions based on keywords describing the purpose of the session; 1175 there is no central registry of keywords. Its value should be 1176 interpreted in the charset specified for the session description if 1177 one is specified, or by default in ISO 10646/UTF-8. This attribute 1178 is obsoleted. 1180 6.3. tool 1182 Name: tool 1184 Value: tool-value 1186 Usage Level: session 1188 Charset Dependent: no 1190 Syntax: 1192 tool-value = tool-name-and-version 1193 tool-name-and-version = text 1195 Example: 1197 a=tool:foobar V3.2 1199 This gives the name and version number of the tool used to create the 1200 session description. 1202 6.4. ptime (packet time) 1204 Name: ptime 1206 Value: ptime-value 1208 Usage Level: media 1210 Charset Dependent: no 1212 Syntax: 1214 ptime-value = non-zero-int-or-real 1216 Example: 1218 a=ptime:20 1220 This gives the length of time in milliseconds represented by the 1221 media in a packet. This is probably only meaningful for audio data, 1222 but may be used with other media types if it makes sense. It should 1223 not be necessary to know ptime to decode RTP or vat audio, and it is 1224 intended as a recommendation for the encoding/packetization of audio. 1226 6.5. maxptime (maximum packet time) 1228 Name: maxptime 1230 Value: maxptime-value 1232 Usage Level: media 1234 Charset Dependent: no 1236 Syntax: 1238 maxptime-value = non-zero-int-or-real 1240 Example: 1242 a=maxptime:20 1244 This gives the maximum amount of media that can be encapsulated in 1245 each packet, expressed as time in milliseconds. The time SHALL be 1246 calculated as the sum of the time the media present in the packet 1247 represents. For frame-based codecs, the time SHOULD be an integer 1248 multiple of the frame size. This attribute is probably only 1249 meaningful for audio data, but may be used with other media types if 1250 it makes sense. Note that this attribute was introduced after 1251 [RFC2327], and non-updated implementations will ignore this 1252 attribute. 1254 6.6. rtpmap 1256 Name: rtpmap 1258 Value: rtpmap-value 1260 Usage Level: media 1262 Charset Dependent: no 1264 Syntax: 1266 rtpmap-value = payload-type SP encoding-name 1267 "/" clock-rate [ "/" encoding-params ] 1268 payload-type = zero-based-integer 1269 encoding-name = token 1270 clock-rate = integer 1271 encoding-params = channels 1272 channels = integer 1274 This attribute maps from an RTP payload type number (as used in an 1275 "m=" line) to an encoding name denoting the payload format to be 1276 used. It also provides information on the clock rate and encoding 1277 parameters. Note that the payload type number is indicated in a 1278 7-bit field, limiting the values to incusively between 0 and 127. 1280 Although an RTP profile can make static assignments of payload type 1281 numbers to payload formats, it is more common for that assignment to 1282 be done dynamically using "a=rtpmap:" attributes. As an example of a 1283 static payload type, consider u-law PCM coded single-channel audio 1284 sampled at 8 kHz. This is completely defined in the RTP Audio/Video 1285 profile as payload type 0, so there is no need for an "a=rtpmap:" 1286 attribute, and the media for such a stream sent to UDP port 49232 can 1287 be specified as: 1289 m=audio 49232 RTP/AVP 0 1291 An example of a dynamic payload type is 16-bit linear encoded stereo 1292 audio sampled at 16 kHz. If we wish to use the dynamic RTP/AVP 1293 payload type 98 for this stream, additional information is required 1294 to decode it: 1296 m=audio 49232 RTP/AVP 98 1297 a=rtpmap:98 L16/16000/2 1299 Up to one rtpmap attribute can be defined for each media format 1300 specified. Thus, we might have the following: 1302 m=audio 49230 RTP/AVP 96 97 98 1303 a=rtpmap:96 L8/8000 1304 a=rtpmap:97 L16/8000 1305 a=rtpmap:98 L16/11025/2 1307 RTP profiles that specify the use of dynamic payload types MUST 1308 define the set of valid encoding names and/or a means to register 1309 encoding names if that profile is to be used with SDP. The "RTP/AVP" 1310 and "RTP/SAVP" profiles use media subtypes for encoding names, under 1311 the top-level media type denoted in the "m=" line. In the example 1312 above, the media types are "audio/L8" and "audio/L16". 1314 For audio streams, encoding-params indicates the number of audio 1315 channels. This parameter is OPTIONAL and may be omitted if the 1316 number of channels is one, provided that no additional parameters are 1317 needed. 1319 For video streams, no encoding parameters are currently specified. 1321 Additional encoding parameters MAY be defined in the future, but 1322 codec-specific parameters SHOULD NOT be added. Parameters added to 1323 an "a=rtpmap:" attribute SHOULD only be those required for a session 1324 directory to make the choice of appropriate media to participate in a 1325 session. Codec-specific parameters should be added in other 1326 attributes (for example, "a=fmtp:"). 1328 Note: RTP audio formats typically do not include information about 1329 the number of samples per packet. If a non-default (as defined in 1330 the RTP Audio/Video Profile [RFC3551]) packetization is required, the 1331 "ptime" attribute is used as given above. 1333 6.7. Media Direction Attributes 1335 At most one of recvonly/sendrecv/sendonly/inactive MAY appear at 1336 session level, and at most one MAY appear in each media description. 1338 If any one of these appears in a media description then it applies 1339 for that media description. If none appear in a media description 1340 then the one from session level, if any, applies to that media 1341 description. 1343 If none of the media direction attributes is present at either 1344 session level or media level, "sendrecv" SHOULD be assumed as the 1345 default for sessions that are not of the multimedia conference type 1346 "broadcast" or "H332" (see below). 1348 Within the following SDP example, the "inactive" attribute applies to 1349 audio media and the "recvonly" attribute applies to video media. 1351 v=0 1352 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 1353 s=SDP Seminar 1354 i=A Seminar on the session description protocol 1355 u=http://www.example.com/seminars/sdp.pdf 1356 e=j.doe@example.com (Jane Doe) 1357 c=IN IP4 233.252.0.1/127 1358 t=2873397496 2873404696 1359 a=inactive 1360 m=audio 49170 RTP/AVP 0 1361 m=video 51372 RTP/AVP 99 1362 a=rtpmap:99 h263-1998/90000 1363 a=recvonly 1365 6.7.1. recvonly (receive-only) 1367 Name: recvonly 1369 Value: 1371 Usage Level: session, media 1373 Charset Dependent: no 1375 Example: 1377 a=recvonly 1379 This specifies that the tools should be started in receive-only mode 1380 where applicable. Note that recvonly applies to the media only, not 1381 to any associated control protocol (e.g., an RTP-based system in 1382 recvonly mode SHOULD still send RTCP packets). 1384 6.7.2. sendrecv (send-receive) 1386 Name: sendrecv 1388 Value: 1390 Usage Level: session, media 1392 Charset Dependent: no 1394 Example: 1396 a=sendrecv 1398 This specifies that the tools should be started in send and receive 1399 mode. This is necessary for interactive multimedia conferences with 1400 tools that default to receive-only mode. 1402 6.7.3. sendonly (send-only) 1404 Name: sendonly 1406 Value: 1408 Usage Level: session, media 1410 Charset Dependent: no 1411 Example: 1413 a=sendonly 1415 This specifies that the tools should be started in send-only mode. 1416 An example may be where a different unicast address is to be used for 1417 a traffic destination than for a traffic source. In such a case, two 1418 media descriptions may be used, one sendonly and one recvonly. Note 1419 that sendonly applies only to the media, and any associated control 1420 protocol (e.g., RTCP) SHOULD still be received and processed as 1421 normal. 1423 6.7.4. inactive 1425 Name: inactive 1427 Value: 1429 Usage Level: session, media 1431 Charset Dependent: no 1433 Example: 1435 a=inactive 1437 This specifies that the tools should be started in inactive mode. 1438 This is necessary for interactive multimedia conferences where users 1439 can put other users on hold. No media is sent over an inactive media 1440 stream. Note that an RTP-based system MUST still send RTCP (if RTCP 1441 is used), even if started inactive. 1443 6.8. orient (orientation) 1445 Name: orient 1447 Value: orient-value 1449 Usage Level: media 1451 Charset Dependent: no 1452 Syntax: 1454 orient-value = portrait / landscape / seascape 1455 portrait = %s"portrait" 1456 landscape = %s"landscape" 1457 seascape = %s"seascape" 1458 ; NOTE: These names are case-sensitive. 1460 Example: 1462 a=orient:portrait 1464 Normally this is only used for a whiteboard or presentation tool. It 1465 specifies the orientation of the workspace on the screen. Permitted 1466 values are "portrait", "landscape", and "seascape" (upside-down 1467 landscape). 1469 6.9. type (conference type) 1471 Name: type 1473 Value: type-value 1475 Usage Level: session 1477 Charset Dependent: no 1479 Syntax: 1481 type-value = conference-type 1482 conference-type = broadcast / meeting / moderated / test / 1483 H332 1484 broadcast = %s"broadcast" 1485 meeting = %s"meeting" 1486 moderated = %s"moderated" 1487 test = %s"test" 1488 H332 = %s"H332" 1489 ; NOTE: These names are case-sensitive. 1491 Example: 1493 a=type:moderated 1495 This specifies the type of the multimedia conference. Suggested 1496 values are "broadcast", "meeting", "moderated", "test", and "H332". 1497 "recvonly" should be the default for "type:broadcast" sessions, 1498 "type:meeting" should imply "sendrecv", and "type:moderated" should 1499 indicate the use of a floor control tool and that the media tools are 1500 started so as to mute new sites joining the multimedia conference. 1502 Specifying the attribute "type:H332" indicates that this loosely 1503 coupled session is part of an H.332 session as defined in the ITU 1504 H.332 specification [ITU.H332.1998]. Media tools should be started 1505 "recvonly". 1507 Specifying the attribute "type:test" is suggested as a hint that, 1508 unless explicitly requested otherwise, receivers can safely avoid 1509 displaying this session description to users. 1511 6.10. charset (character set) 1513 Name: charset 1515 Value: charset-value 1517 Usage Level: session 1519 Charset Dependent: no 1521 Syntax: 1523 charset-value = mime-charset 1524 (as defined in [RFC 2978]) 1526 This specifies the character set to be used to display the session 1527 name and information data. By default, the ISO-10646 character set 1528 in UTF-8 encoding is used. If a more compact representation is 1529 required, other character sets may be used. For example, the ISO 1530 8859-1 is specified with the following SDP attribute: 1532 a=charset:ISO-8859-1 1534 The charset specified MUST be one of those registered in the IANA 1535 Character Sets registry (http://www.iana.org/assignments/character- 1536 sets), such as ISO-8859-1. The character set identifier is a US- 1537 ASCII string and MUST be compared against identifiers from the "Name" 1538 or "Preferred MIME Name" field of the registry using a case- 1539 insensitive comparison. If the identifier is not recognised or not 1540 supported, all strings that are affected by it SHOULD be regarded as 1541 octet strings. 1543 Note that a character set specified MUST still prohibit the use of 1544 bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets requiring 1545 the use of these characters MUST define a quoting mechanism that 1546 prevents these bytes from appearing within text fields. 1548 6.11. sdplang (SDP language) 1550 Name: sdplang 1552 Value: sdplang-value 1554 Usage Level: session, media 1556 Charset Dependent: no 1558 Syntax: 1560 sdplang-value = Language-Tag 1561 ; Language-Tag defined in RFC5646 1563 Example: 1565 a=sdplang:fr 1567 Multiple sdplang attributes can be provided either at session or 1568 media level if the session description or media use multiple 1569 languages. 1571 As a session-level attribute, it specifies the language for the 1572 session description (not the language of the media). As a media- 1573 level attribute, it specifies the language for any media-level SDP 1574 information-field associated with that media (again not the language 1575 of the media), overriding any sdplang attributes specified at session 1576 level. 1578 In general, sending session descriptions consisting of multiple 1579 languages is discouraged. Instead, multiple sesssion descriptions 1580 SHOULD be sent describing the session, one in each language. 1581 However, this is not possible with all transport mechanisms, and so 1582 multiple sdplang attributes are allowed although NOT RECOMMENDED. 1584 The "sdplang" attribute value must be a single [RFC5646] language tag 1585 in US-ASCII. An "sdplang" attribute SHOULD be specified when a 1586 session is distributed with sufficient scope to cross geographic 1587 boundaries, where the language of recipients cannot be assumed, or 1588 where the session is in a different language from the locally assumed 1589 norm. 1591 6.12. lang (language) 1593 Name: lang 1595 Value: lang-value 1596 Usage Level: session, media 1598 Charset Dependent: no 1600 Syntax: 1602 lang-value = Language-Tag 1603 ; Language-Tag defined in RFC5646 1605 Example: 1607 a=lang:de 1609 Multiple lang attributes can be provided either at session or media 1610 level if the session or media has capabilities in more than one 1611 language, in which case the order of the attributes indicates the 1612 order of preference of the various languages in the session or media, 1613 from most preferred to least preferred. 1615 As a session-level attribute, lang specifies a language capability 1616 for the session being described. As a media-level attribute, it 1617 specifies a language capability for that media, overriding any 1618 session-level language(s) specified. 1620 The "lang" attribute value must be a single [RFC5646] language tag in 1621 US-ASCII. A "lang" attribute SHOULD be specified when a session is 1622 of sufficient scope to cross geographic boundaries where the language 1623 of participants cannot be assumed, or where the session has 1624 capabilities in languages different from the locally assumed norm. 1626 The "lang" attribute is supposed to be used for setting the initial 1627 language(s) used in the session. Events during the session may 1628 influence which language(s) are used, and the participants are not 1629 strictly bound to only use the declared languages. 1631 Most real-time use cases start with just one language used, while 1632 other cases involve a range of languages, e.g. an interpreted or 1633 subtitled session. When more than one 'lang' attribute is specified, 1634 the "lang" attribute itself does not provide any information about 1635 multiple languages being intended to be used during the session, or 1636 if the intention is to only select one of the languages. If needed, 1637 a new attribute can be defined and used to indicate such intentions. 1638 Without such semantics, it is assumed that for a negotiated session 1639 one of the declared languages will be selected and used. 1641 6.13. framerate (frame rate) 1643 Name: framerate 1645 Value: framerate-value 1647 Usage Level: media 1649 Charset Dependent: no 1651 Syntax: 1653 framerate-value = non-zero-int-or-real 1655 Example: 1657 a=framerate:60 1659 This gives the maximum video frame rate in frames/sec. It is 1660 intended as a recommendation for the encoding of video data. Decimal 1661 representations of fractional values are allowed. It is defined only 1662 for video media. 1664 6.14. quality 1666 Name: quality 1668 Value: quality-value 1670 Usage Level: media 1672 Charset Dependent: no 1674 Syntax: 1676 quality-value = zero-based-integer 1678 Example: 1680 a=quality:10 1682 This gives a suggestion for the quality of the encoding as an integer 1683 value. The intention of the quality attribute for video is to 1684 specify a non-default trade-off between frame-rate and still-image 1685 quality. For video, the value is in the range 0 to 10, with the 1686 following suggested meaning: 1688 10 - the best still-image quality the compression scheme 1689 can give. 1690 5 - the default behaviour given no quality suggestion. 1691 0 - the worst still-image quality the codec designer 1692 thinks is still usable. 1694 6.15. fmtp (format parameters) 1696 Name: fmtp 1698 Value: fmtp-value 1700 Usage Level: media 1702 Charset Dependent: no 1704 Syntax: 1706 fmtp-value = fmt SP format-specific-params 1707 format-specific-params = byte-string 1708 ; Notes: 1709 ; - The format parameters are media type parameters and 1710 need to reflect their syntax. 1712 Example: 1714 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1716 This attribute allows parameters that are specific to a particular 1717 format to be conveyed in a way that SDP does not have to understand 1718 them. The format must be one of the formats specified for the media. 1719 Format-specific parameters, semicolon separated, may be any set of 1720 parameters required to be conveyed by SDP and given unchanged to the 1721 media tool that will use this format. At most one instance of this 1722 attribute is allowed for each format. 1724 The fmtp attribute may be used to specify parameters for any protocol 1725 and format that defines use of such parameters. 1727 7. Security Considerations 1729 SDP is frequently used with the Session Initiation Protocol [RFC3261] 1730 using the offer/answer model [RFC3264] to agree on parameters for 1731 unicast sessions. When used in this manner, the security 1732 considerations of those protocols apply. 1734 SDP is a session description format that describes multimedia 1735 sessions. Entities receiving and acting upon an SDP message SHOULD 1736 be aware that a session description cannot be trusted unless it has 1737 been obtained by an authenticated and integrity-protected transport 1738 protocol from a known and trusted source. Many different transport 1739 protocols may be used to distribute session descriptions, and the 1740 nature of the authentication and integrity-protection will differ 1741 from transport to transport. For some transports, security features 1742 are often not deployed. In case a session description has not been 1743 obtained in a trusted manner, the endpoint SHOULD exercise care 1744 because, among other attacks, the media sessions received may not be 1745 the intended ones, the destination where media is sent to may not be 1746 the expected one, any of the parameters of the session may be 1747 incorrect, or the media security may be compromised. It is up to the 1748 endpoint to make a sensible decision taking into account the security 1749 risks of the application and the user preferences - the endpoint may 1750 decide to ask the user whether or not to accept the session. 1752 On receiving a session description over an unauthenticated transport 1753 mechanism or from an untrusted party, software parsing the session 1754 should take a few precautions. Similar concerns apply if integrity 1755 protection is not in place. Session descriptions contain information 1756 required to start software on the receiver's system. Software that 1757 parses a session description MUST NOT be able to start other software 1758 except that which is specifically configured as appropriate software 1759 to participate in multimedia sessions. It is normally considered 1760 inappropriate for software parsing a session description to start, on 1761 a user's system, software that is appropriate to participate in 1762 multimedia sessions, without the user first being informed that such 1763 software will be started and giving the user's consent. Thus, a 1764 session description arriving by session announcement, email, session 1765 invitation, or WWW page MUST NOT deliver the user into an interactive 1766 multimedia session unless the user has explicitly pre-authorised such 1767 action. As it is not always simple to tell whether or not a session 1768 is interactive, applications that are unsure should assume sessions 1769 are interactive. 1771 In this specification, there are no attributes that would allow the 1772 recipient of a session description to be informed to start multimedia 1773 tools in a mode where they default to transmitting. Under some 1774 circumstances it might be appropriate to define such attributes. If 1775 this is done, an application parsing a session description containing 1776 such attributes SHOULD either ignore them or inform the user that 1777 joining this session will result in the automatic transmission of 1778 multimedia data. The default behaviour for an unknown attribute is 1779 to ignore it. 1781 In certain environments, it has become common for intermediary 1782 systems to intercept and analyse session descriptions contained 1783 within other signalling protocols. This is done for a range of 1784 purposes, including but not limited to opening holes in firewalls to 1785 allow media streams to pass, or to mark, prioritize, or block traffic 1786 selectively. In some cases, such intermediary systems may modify the 1787 session description, for example, to have the contents of the session 1788 description match NAT bindings dynamically created. These behaviours 1789 are NOT RECOMMENDED unless the session description is conveyed in 1790 such a manner that allows the intermediary system to conduct proper 1791 checks to establish the authenticity of the session description, and 1792 the authority of its source to establish such communication sessions. 1793 SDP by itself does not include sufficient information to enable these 1794 checks: they depend on the encapsulating protocol (e.g., SIP or 1795 RTSP). 1797 Use of the "k=" line poses a significant security risk, since it 1798 conveys session encryption keys in the clear. SDP MUST NOT be used 1799 to convey keying material, unless it can be guaranteed that the 1800 channel over which the SDP is delivered is both private and 1801 authenticated. Moreover, the "k=" line provides no way to indicate 1802 or negotiate cryptographic key algorithms. As it provides for only a 1803 single symmetric key, rather than separate keys for confidentiality 1804 and integrity, its utility is severely limited. The "k=" line MUST 1805 NOT be used, as discussed in Section 5.12. 1807 8. IANA Considerations 1809 8.1. The "application/sdp" Media Type 1811 One media type registration from [RFC4566] is to be updated, as 1812 defined below. 1814 To: ietf-types@iana.org 1815 Subject: Registration of media type "application/sdp" 1817 Type name: application 1819 Subtype name: sdp 1821 Required parameters: None. 1823 Optional parameters: None. 1825 Encoding considerations: 1826 SDP files are primarily UTF-8 format text. The "a=charset:" 1827 attribute may be used to signal the presence of other character 1828 sets in certain parts of an SDP file (see Section 6 of RFC 1829 XXXX). Arbitrary binary content cannot be directly 1830 represented in SDP. 1832 Security considerations: 1833 See Section 7 of RFC XXXX. 1835 Interoperability considerations: 1836 See RFC XXXX. 1838 Published specification: 1839 See RFC XXXX. 1841 Applications which use this media type: 1842 Voice over IP, video teleconferencing, streaming media, instant 1843 messaging, among others. See also Section 3 of RFC XXXX. 1845 Fragment identifier considerations: None 1847 Additional information: 1849 Deprecated alias names for this type: N/A 1850 Magic number(s): None. 1851 File extension(s): The extension ".sdp" is commonly used. 1852 Macintosh File Type Code(s): "sdp " 1854 Person & email address to contact for further information: 1855 IETF MMUSIC working group 1857 Intended usage: COMMON 1859 Restrictions on usage: None 1861 Author/Change controller: 1862 Authors of RFC XXXX 1863 IETF MMUSIC working group delegated from the IESG 1865 8.2. Registration of Parameters 1867 This specification establishes and initializes IANA parameter 1868 registries for seven named SDP sub-fields. Using the terminology in 1869 the SDP specification Augmented Backus-Naur Form (ABNF), they are 1870 "media", "proto", "fmt", "att-field", "bwtype", "nettype", and 1871 "addrtype". 1873 The contact address for all parameters registered below is: 1875 IETF MMUSIC working group 1877 8.2.1. Media Types ("media") 1879 The set of media types is intended to be small and SHOULD NOT be 1880 extended except under rare circumstances. The same rules should 1881 apply for media names as for top-level media types, and where 1882 possible the same name should be registered for SDP as for MIME. For 1883 media other than existing top-level media types, a Standards Track 1884 RFC MUST be produced for a new top-level media type to be registered, 1885 and the registration MUST provide good justification why no existing 1886 media name is appropriate (the "Standards Action" policy of 1887 [RFC8126]). 1889 This memo registers the media types "audio", "video", "text", 1890 "application", and "message". 1892 Note: The media types "control" and "data" were listed as valid in an 1893 early version of this specification (RFC 2327); however, their 1894 semantics were never fully specified and they are not widely used. 1895 These media types have been removed in this specification, although 1896 they still remain valid media type capabilities for a SIP user agent 1897 as defined in [RFC3840]. If these media types are considered useful 1898 in the future, a Standards Track RFC MUST be produced to document 1899 their use. Until that is done, applications SHOULD NOT use these 1900 types and SHOULD NOT declare support for them in SIP capabilities 1901 declarations (even though they exist in the registry created by 1902 [RFC3840]). Also note that [RFC6466] defined the "image" media type. 1904 8.2.2. Transport Protocols ("proto") 1906 The "proto" sub-field describes the transport protocol used. The 1907 registration procedure for this registry is "RFC Required". 1909 This document registers two values: "RTP/AVP" is a reference to 1910 [RFC3550] used under the RTP Profile for Audio and Video Conferences 1911 with Minimal Control [RFC3551] running over UDP/IP, and "udp" 1912 indicates direct use of the UDP protocol. 1914 New transport protocols MAY be defined, and MUST be registered with 1915 IANA. Registrations MUST reference an RFC describing the protocol. 1916 Such an RFC MAY be Experimental or Informational, although it is 1917 preferable that it be Standards Track. The RFC defining a new 1918 protocol MUST define the rules by which the "fmt" (see below) 1919 namespace is managed. 1921 "proto" names starting with "RTP/" MUST only be used for defining 1922 transport protocols that are profiles of the RTP protocol. For 1923 example, a profile whose short name is "XYZ" would be denoted by a 1924 "proto" sub-field of "RTP/XYZ". 1926 8.2.3. Media Formats ("fmt") 1928 Each transport protocol, defined by the "proto" sub-field, has an 1929 associated "fmt" namespace that describes the media formats that may 1930 be conveyed by that protocol. Formats cover all the possible 1931 encodings that could be transported in a multimedia session. 1933 RTP payload formats under the "RTP/AVP" and other "RTP/*" profiles 1934 MUST use the payload type number as their "fmt" value. If the 1935 payload type number is dynamically assigned by this session 1936 description, an additional "rtpmap" attribute MUST be included to 1937 specify the format name and parameters as defined by the media type 1938 registration for the payload format. It is RECOMMENDED that other 1939 RTP profiles that are registered (in combination with RTP) as SDP 1940 transport protocols specify the same rules for the "fmt" namespace. 1942 For the "udp" protocol, allowed "fmt" values are media subtypes from 1943 the IANA Media Types registry. The media type and subtype 1944 combination / specifies the format of the body of UDP 1945 packets. Use of an existing media subtype for the format is 1946 encouraged. If no suitable media subtype exists, it is RECOMMENDED 1947 that a new one be registered through the IETF process [RFC6838] by 1948 production of, or reference to, a standards-track RFC that defines 1949 the format. 1951 For other protocols, formats MAY be registered according to the rules 1952 of the associated "proto" specification. 1954 Registrations of new formats MUST specify which transport protocols 1955 they apply to. 1957 8.2.4. Attribute Names ("att-field") 1959 8.2.4.1. New Attributes 1961 Attribute-field names ("att-field") MUST be registered with IANA and 1962 documented, to avoid any issues due to conflicting attribute 1963 definitions under the same name. Unknown attributes in SDP are 1964 simply ignored, but conflicting ones that fragment the protocol are a 1965 serious problem. 1967 New attribute registrations are accepted according to the 1968 "Specification Required" policy of [RFC8126], provided that the 1969 specification includes the following information: 1971 o Contact Name. 1973 o Contact Email Address. 1975 o Attribute Name: The name of the attribute that will appear in 1976 SDP). This MUST conform to the definition of . 1978 o Attribute Syntax: For a value attribute (see clause 5.13), an ABNF 1979 definition of the attribute value syntax (See 1980 Section 9) MUST be provided. The syntax MUST follow the rule form 1981 as per Section 2.2 of [RFC5234] and [RFC7405]. This SHALL define 1982 the allowable values that the attribute might take. It MAY also 1983 define an extension method for the addition of future values. For 1984 a property attribute, the ABNF definition is omitted as the 1985 property attribute takes no values. 1987 o Attribute Semantics: For a value attribute, a semantic description 1988 of the values that the attribute might take MUST be provided. The 1989 usage of a property attribute is described under purpose below. 1991 o Attribute Value: The name of an ABNF syntax rule defining the 1992 syntax of the value. Absence of a rule name indicates that the 1993 attribute takes no values. Enclosing the rule name in "[" and "]" 1994 indicates that a value is optional. 1996 o Usage Level: Usage level(s) of the attribute. One or more of: 1997 session, media, source, dcsa, dcsa(subprotocol). For a definition 1998 of source level attributes, see [RFC5576]. For a definition of 1999 dcsa attributes see: [I-D.ietf-mmusic-data-channel-sdpneg]. 2001 o Charset Dependent: Whether the attribute value is subject to the 2002 charset attribute or not (Yes/No). 2004 o Purpose: An explanation of the purpose and usage of the attribute. 2006 o O/A Procedures: Offer/Answer procedures as explained in [RFC3264]. 2008 o Mux Category: Indication of which multiplexing "category" 2009 [I-D.ietf-mmusic-sdp-mux-attributes] an attribute is associated 2010 with. 2012 o Reference: A reference to the specification defining the 2013 attribute. 2015 The above is the minimum that IANA will accept. Attributes that are 2016 expected to see widespread use and interoperability SHOULD be 2017 documented with a standards-track RFC that specifies the attribute 2018 more precisely. 2020 Submitters of registrations should ensure that the specification is 2021 in the spirit of SDP attributes, most notably that the attribute is 2022 platform independent in the sense that it makes no implicit 2023 assumptions about operating systems and does not name specific pieces 2024 of software in a manner that might inhibit interoperability. 2026 Submitters of registrations should also carefully choose the 2027 attribute usage level. They should not choose only "session" when 2028 the attribute can have different values when media is disaggregated, 2029 i.e., when each m= section has its own IP address on a different 2030 endpoint. In that case the attribute type chosen should be "session, 2031 media" or "media" (depending on desired semantics). The default rule 2032 is that for all new SDP attributes that can occur both in session and 2033 media level, the media level overrides the session level. When this 2034 is not the case for a new SDP attribute, it MUST be explicitly 2035 stated. 2037 IANA has registered the initial set of attribute names ("att-field" 2038 values) with definitions as in Section 6 of this memo (these 2039 definitions replace those in [RFC4566]). 2041 8.2.4.2. Updates to Existing Attributes 2043 Updated attribute registrations are accepted according to the 2044 "Specification Required" policy of [RFC8126], provided that the 2045 specification updating the attribute (for example, by adding a new 2046 value) considers the registration information items from 2047 Section 8.2.4.1 according to the following bullets: 2049 o Contact Name: A name MUST be provided. 2051 o Contact Email Address: An email address MUST be provided. 2053 o Attribute Name: MUST be provided and MUST NOT be changed. 2054 Otherwise it is a new attribute. 2056 o Attribute Syntax: The existing rule syntax with the syntax 2057 extensions MUST be provided if there is a change to the syntax. A 2058 revision to an existing attribute usage MAY extend the syntax of 2059 an attribute, but MUST be backward compatible. 2061 o Attribute Semantics: A semantic description of new additional 2062 attributes values or a semantic extension of existing values. 2063 Existing attribute values semantics MUST only be extended in a 2064 backward compatible manner. 2066 o Usage Level: Updates MAY only add additional levels. 2068 o Charset Dependent: MUST NOT be changed. 2070 o Purpose: MAY be extended according to the updated usage. 2072 o O/A Procedures: MAY be updated in a backward compatible manner 2073 and/or it applies to a new usage level only. 2075 o Mux Category: No change unless from "TBD" to another value (see 2076 [I-D.ietf-mmusic-sdp-mux-attributes]. It MAY also change if 2077 'media' level is being added to the definition of an attribute 2078 that previously did not include it. 2080 o Reference: A new reference MUST be provided. 2082 Items SHOULD be omitted if there is no impact to them as a result of 2083 the attribute update. 2085 8.2.5. Bandwidth Specifiers ("bwtype") 2087 A proliferation of bandwidth specifiers is strongly discouraged. 2089 New bandwidth specifiers ( sub-field values) MUST be 2090 registered with IANA. The submission MUST reference a standards- 2091 track RFC specifying the semantics of the bandwidth specifier 2092 precisely, and indicating when it should be used, and why the 2093 existing registered bandwidth specifiers do not suffice. 2095 IANA has registered the bandwidth specifiers "CT" and "AS" with 2096 definitions as in Section 5.8 of this memo (these definitions update 2097 those in [RFC4566]). 2099 8.2.6. Network Types ("nettype") 2101 New network types ( sub-field values) MUST be registered 2102 with IANA if SDP needs to be used in the context of non-Internet 2103 environments. The registration is subject to the "RFC Required" 2104 policy of [RFC8126]. Although these are not normally the preserve of 2105 IANA, there may be circumstances when an Internet application needs 2106 to interoperate with a non-Internet application, such as when 2107 gatewaying an Internet telephone call into the Public Switched 2108 Telephone Network (PSTN). The number of network types should be 2109 small and should be rarely extended. A new network type cannot be 2110 registered without registering at least one address type to be used 2111 with that network type. A new network type registration MUST 2112 reference an RFC that gives details of the network type and address 2113 type(s) and specifies how and when they would be used. 2115 IANA has registered the network type "IN" to represent the Internet, 2116 with definition as in Sections 5.2 and 5.7 of this memo (these 2117 definitions update those in [RFC4566]). 2119 8.2.7. Address Types ("addrtype") 2121 New address types ("addrtype") MUST be registered with IANA. The 2122 registration is subject to the "RFC Required" policy of [RFC8126]. 2123 An address type is only meaningful in the context of a network type, 2124 and any registration of an address type MUST specify a registered 2125 network type or be submitted along with a network type registration. 2126 A new address type registration MUST reference an RFC giving details 2127 of the syntax of the address type. Address types are not expected to 2128 be registered frequently. 2130 IANA has registered the address types "IP4" and "IP6" with 2131 definitions as in Sections 5.2 and 5.7 of this memo (these 2132 definitions update those in [RFC4566]). 2134 8.2.8. Registration Procedure 2136 In the RFC specifications that register new values for SDP "media", 2137 "proto", "fmt", "bwtype", "nettype", and "addrtype" parameters, the 2138 authors MUST include the following information for IANA to place in 2139 the appropriate registry: 2141 o contact name, email address, and telephone number 2143 o name being registered (as it will appear in SDP) 2145 o long-form name in English 2147 o type of name ("media", "proto", "fmt", "bwtype", "nettype", or 2148 "addrtype") 2150 o a one-paragraph explanation of the purpose of the registered name 2152 o a reference to the specification for the registered name (this 2153 will typically be an RFC number) 2155 In the case of a new addrtype registration, the author has to check 2156 whether the new address type is usable with the existing network 2157 types. If yes, the "nettype" registry MUST be updated accordingly. 2158 In the case of a new nettype registration, the author MUST specify 2159 the usable address type(s). 2161 IANA may refer any registration to the IESG for review, and may 2162 request revisions to be made before a registration will be made. 2164 8.3. Encryption Key Access Methods 2166 The IANA previously maintained a table of SDP encryption key access 2167 method ("enckey") names. This table is obsolete, since the "k=" line 2168 is not extensible. New registrations MUST NOT be accepted. 2170 8.4. Reorganization of the nettype Registry 2172 This document adds a new column in the "nettype" registry with the 2173 title "Usable addrtype Values" and updates the "nettype" registry as 2174 follows: 2176 -------------------------------------------------------------------- 2177 |Type | SDP Name | Usable addrtype Values | Reference | 2178 -------------------------------------------------------------------- 2179 |nettype | IN | IP4, IP6 | [RFCXXXX] | 2180 |nettype | TN | RFC2543 | [RFC2848] | 2181 |nettype | ATM | NSAP, GWID, E164 | [RFC3108] | 2182 |nettype | PSTN | E164 | [RFC7195] | 2183 -------------------------------------------------------------------- 2185 Note that both [RFC7195] and [RFC3108] registered "E164" as an 2186 address type, although [RFC7195] mentions that the "E164" address 2187 type has a different context for ATM and PSTN networks. 2189 8.5. Reorganization of the att-field Registries 2191 This document combines all of the (currently) five "att-field" 2192 registries into one registry called "att-field" registry, and updates 2193 the columns to reflect the name, usage level(s), charset dependency 2194 and reference. As such IANA is requested to create a new combined 2195 registry using the following columns: 2197 Name | Usage Level | Dependent on Charset? | Mux Category | Reference 2199 The "Name" column reflects the attribute name (as it will appear in 2200 the SDP). The "Usage Level" column MUST indicate one or more of the 2201 following: session, media, source, dcsa and dcsa(subprotocol). The 2202 "Dependent on Charset?" column MUST indicate "Yes" or "No" depending 2203 on whether the attribute value is subject to the charset attribute. 2204 The "Mux Category" column MUST indicate one of the following 2205 categories: NORMAL, NOT RECOMMENDED, IDENTICAL, SUM, TRANSPORT, 2206 INHERIT, IDENTICAL-PER-PT, SPECIAL or TBD as defined by 2207 [I-D.ietf-mmusic-sdp-mux-attributes]. Finally, the "Reference" 2208 column indicates the specification(s) where the attribute is defined. 2210 For example, the attribute "setup" which is defined for both session 2211 and media level, will be listed in the new registry as follows: 2213 Name | Usage Level | Dependent on Charset?|Mux Category| Reference | 2214 setup | session,media, | No |IDENTICAL | [RFC4145] | 2215 | dcsa,dcsa(msrp)| | | [RFC6135] | 2216 | | | | [I-D.mmusic 2217 | | | |-msrp-usage- 2218 | | | |data-channel 2219 | | | |] | 2221 9. SDP Grammar 2223 This section provides an Augmented BNF grammar for SDP. ABNF is 2224 defined in [RFC5234] and [RFC7405]. 2226 ; SDP Syntax 2227 session-description = version-field 2228 origin-field 2229 session-name-field 2230 [information-field] 2231 [uri-field] 2232 *email-field 2233 *phone-field 2234 [connection-field] 2235 *bandwidth-field 2236 1*time-description 2237 [key-field] 2238 *attribute-field 2239 *media-description 2241 version-field = %s"v" "=" 1*DIGIT CRLF 2242 ;this memo describes version 0 2244 origin-field = %s"o" "=" username SP sess-id SP sess-version SP 2245 nettype SP addrtype SP unicast-address CRLF 2247 session-name-field = %s"s" "=" text CRLF 2249 information-field = %s"i" "=" text CRLF 2251 uri-field = %s"u" "=" uri CRLF 2253 email-field = %s"e" "=" email-address CRLF 2255 phone-field = %s"p" "=" phone-number CRLF 2257 connection-field = %s"c" "=" nettype SP addrtype SP 2258 connection-address CRLF 2259 ;a connection field must be present 2260 ;in every media description or at the 2261 ;session-level 2263 bandwidth-field = %s"b" "=" bwtype ":" bandwidth CRLF 2265 time-description = time-field 2266 [repeat-description] 2268 repeat-description = 1*repeat-field 2269 [zone-field] 2271 time-field = %s"t" "=" start-time SP stop-time CRLF 2273 repeat-field = %s"r" "=" repeat-interval SP typed-time 2274 1*(SP typed-time) CRLF 2276 zone-field = %s"z" "=" time SP ["-"] typed-time 2277 *(SP time SP ["-"] typed-time) CRLF 2279 key-field = %s"k" "=" key-type CRLF 2281 attribute-field = %s"a" "=" attribute CRLF 2283 media-description = media-field 2284 [information-field] 2285 *connection-field 2286 *bandwidth-field 2287 [key-field] 2288 *attribute-field 2290 media-field = %s"m" "=" media SP port ["/" integer] 2291 SP proto 1*(SP fmt) CRLF 2293 ; sub-rules of 'o=' 2294 username = non-ws-string 2295 ;pretty wide definition, but doesn't 2296 ;include space 2298 sess-id = 1*DIGIT 2299 ;should be unique for this username/host 2301 sess-version = 1*DIGIT 2303 nettype = token 2304 ;typically "IN" 2306 addrtype = token 2307 ;typically "IP4" or "IP6" 2309 ; sub-rules of 'u=' 2310 uri = URI-reference 2311 ; see RFC 3986 2313 ; sub-rules of 'e=', see RFC 5322 for definitions 2314 email-address = address-and-comment / dispname-and-address 2315 / addr-spec 2316 address-and-comment = addr-spec 1*SP "(" 1*email-safe ")" 2317 dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">" 2319 ; sub-rules of 'p=' 2320 phone-number = phone *SP "(" 1*email-safe ")" / 2321 1*email-safe "<" phone ">" / 2322 phone 2324 phone = ["+"] DIGIT 1*(SP / "-" / DIGIT) 2326 ; sub-rules of 'c=' 2327 connection-address = multicast-address / unicast-address 2329 ; sub-rules of 'b=' 2330 bwtype = token 2332 bandwidth = 1*DIGIT 2334 ; sub-rules of 't=' 2335 start-time = time / "0" 2337 stop-time = time / "0" 2339 time = POS-DIGIT 9*DIGIT 2340 ; Decimal representation of NTP time in 2341 ; seconds since 1900. The representation 2342 ; of NTP time is an unbounded length field 2343 ; containing at least 10 digits. Unlike the 2344 ; 64-bit representation used elsewhere, time 2345 ; in SDP does not wrap in the year 2036. 2347 ; sub-rules of 'r=' and 'z=' 2348 repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] 2350 typed-time = 1*DIGIT [fixed-len-time-unit] 2352 fixed-len-time-unit = %s"d" / %s"h" / %s"m" / %s"s" 2353 ; NOTE: These units are case-sensitive. 2355 ; sub-rules of 'k=' 2356 key-type = %s"prompt" / 2357 %s"clear:" text / 2358 %s"base64:" base64 / 2359 %s"uri:" uri 2360 ; NOTE: These names are case-sensitive. 2362 base64 = *base64-unit [base64-pad] 2363 base64-unit = 4base64-char 2364 base64-pad = 2base64-char "==" / 3base64-char "=" 2365 base64-char = ALPHA / DIGIT / "+" / "/" 2367 ; sub-rules of 'a=' 2368 attribute = (att-field ":" att-value) / att-field 2370 att-field = token 2372 att-value = byte-string 2374 ; sub-rules of 'm=' 2375 media = token 2376 ;typically "audio", "video", "text", "image" 2377 ;or "application" 2379 fmt = token 2380 ;typically an RTP payload type for audio 2381 ;and video media 2383 proto = token *("/" token) 2384 ;typically "RTP/AVP" or "udp" 2386 port = 1*DIGIT 2388 ; generic sub-rules: addressing 2389 unicast-address = IP4-address / IP6-address / FQDN / extn-addr 2391 multicast-address = IP4-multicast / IP6-multicast / FQDN 2392 / extn-addr 2394 IP4-multicast = m1 3( "." decimal-uchar ) 2395 "/" ttl [ "/" numaddr ] 2396 ; IP4 multicast addresses may be in the 2397 ; range 224.0.0.0 to 239.255.255.255 2399 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / 2400 ("23" DIGIT ) 2402 IP6-multicast = IP6-address [ "/" numaddr ] 2403 ; IP6 address starting with FF 2405 numaddr = integer 2407 ttl = (POS-DIGIT *2DIGIT) / "0" 2409 FQDN = 4*(alpha-numeric / "-" / ".") 2410 ; fully qualified domain name as specified 2411 ; in RFC 1035 (and updates) 2413 IP4-address = b1 3("." decimal-uchar) 2415 b1 = decimal-uchar 2416 ; less than "224" 2418 IP6-address = 6( h16 ":" ) ls32 2419 / "::" 5( h16 ":" ) ls32 2420 / [ h16 ] "::" 4( h16 ":" ) ls32 2421 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 2422 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 2423 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 2424 / [ *4( h16 ":" ) h16 ] "::" ls32 2425 / [ *5( h16 ":" ) h16 ] "::" h16 2426 / [ *6( h16 ":" ) h16 ] "::" 2428 h16 = 1*4HEXDIG 2430 ls32 = ( h16 ":" h16 ) / IP4-address 2432 ; Generic for other address families 2433 extn-addr = non-ws-string 2435 ; generic sub-rules: datatypes 2436 text = byte-string 2437 ;default is to interpret this as UTF8 text. 2438 ;ISO 8859-1 requires "a=charset:ISO-8859-1" 2439 ;session-level attribute to be used 2441 byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) 2442 ;any byte except NUL, CR, or LF 2444 non-ws-string = 1*(VCHAR/%x80-FF) 2445 ;string of visible characters 2447 token-char = ALPHA / DIGIT 2448 / "!" / "#" / "$" / "%" / "&" 2449 / "'" ; (single quote) 2450 / "*" / "+" / "-" / "." / "^" / "_" 2451 / "`" ; (Grave accent) 2452 / "{" / "|" / "}" / "~" 2454 token = 1*(token-char) 2456 email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF 2457 ;any byte except NUL, CR, LF, or the quoting 2458 ;characters ()<> 2460 integer = POS-DIGIT *DIGIT 2462 zero-based-integer = "0" / integer 2464 non-zero-int-or-real = integer / non-zero-real 2466 non-zero-real = zero-based-integer "." *DIGIT POS-DIGIT 2468 ; generic sub-rules: primitives 2469 alpha-numeric = ALPHA / DIGIT 2471 POS-DIGIT = %x31-39 ; 1 - 9 2473 decimal-uchar = DIGIT 2474 / POS-DIGIT DIGIT 2475 / ("1" 2*(DIGIT)) 2476 / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) 2477 / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) 2479 ; external references: 2480 ALPHA = 2481 DIGIT = 2482 CRLF = 2483 HEXDIG = 2484 SP = 2485 VCHAR = 2486 URI-reference = 2487 addr-spec = 2489 10. Summary of Changes from RFC 4566 2491 The ABNF rule for IP6-address has been corrected. As a result, the 2492 ABNF rule for IP6-multicast has changed, and the (now unused) rules 2493 for hexpart, hexseq, and hex4 have been removed. 2495 IP4 unicast and multicast addresses in the example SDP descriptions 2496 have been revised per RFCs 5735 and 5771. 2498 Text in Section 5.2 has been revised to clarify the use of local 2499 addresses in case of ICE-like SDP extensions. 2501 Normative and informative references have been updated. 2503 The text regarding the session vs. media-level attribute usage has 2504 been clarified. 2506 The case-insensitivity rules from RFC 4855 have been included in this 2507 document. 2509 11. Acknowledgements 2511 Many people in the IETF Multiparty Multimedia Session Control 2512 (MMUSIC) working group have made comments and suggestions 2513 contributing to this document. 2515 12. References 2517 12.1. Normative References 2519 [E164] International Telecommunication Union, "E.164 : The 2520 international public telecommunication numbering plan", 2521 ITU Recommendation E.164, November 2010. 2523 [I-D.ietf-mmusic-data-channel-sdpneg] 2524 Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., 2525 Marcon, J., and R. Even, "SDP-based Data Channel 2526 Negotiation", draft-ietf-mmusic-data-channel-sdpneg-19 2527 (work in progress), May 2018. 2529 [I-D.ietf-mmusic-sdp-mux-attributes] 2530 Nandakumar, S., "A Framework for SDP Attributes when 2531 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 2532 (work in progress), February 2018. 2534 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2535 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 2536 . 2538 [RFC1035] Mockapetris, P., "Domain names - implementation and 2539 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2540 November 1987, . 2542 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2543 Requirement Levels", BCP 14, RFC 2119, 2544 DOI 10.17487/RFC2119, March 1997, 2545 . 2547 [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration 2548 Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978, 2549 October 2000, . 2551 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2552 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2553 2003, . 2555 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2556 Resource Identifier (URI): Generic Syntax", STD 66, 2557 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2558 . 2560 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2561 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2562 July 2006, . 2564 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2565 Specifications: ABNF", STD 68, RFC 5234, 2566 DOI 10.17487/RFC5234, January 2008, 2567 . 2569 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2570 Media Attributes in the Session Description Protocol 2571 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 2572 . 2574 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 2575 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 2576 September 2009, . 2578 [RFC5890] Klensin, J., "Internationalized Domain Names for 2579 Applications (IDNA): Definitions and Document Framework", 2580 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2581 . 2583 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2584 Writing an IANA Considerations Section in RFCs", BCP 26, 2585 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2586 . 2588 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2589 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2590 May 2017, . 2592 12.2. Informative References 2594 [I-D.ietf-mmusic-sdp-bundle-negotiation] 2595 Holmberg, C., Alvestrand, H., and C. Jennings, 2596 "Negotiating Media Multiplexing Using the Session 2597 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 2598 negotiation-52 (work in progress), May 2018. 2600 [ITU.H332.1998] 2601 International Telecommunication Union, "H.323 extended for 2602 loosely coupled conferences", ITU Recommendation H.332, 2603 September 1998. 2605 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 2606 Protocol", RFC 2327, DOI 10.17487/RFC2327, April 1998, 2607 . 2609 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 2610 Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, 2611 October 2000, . 2613 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2614 A., Peterson, J., Sparks, R., Handley, M., and E. 2615 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2616 DOI 10.17487/RFC3261, June 2002, 2617 . 2619 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2620 with Session Description Protocol (SDP)", RFC 3264, 2621 DOI 10.17487/RFC3264, June 2002, 2622 . 2624 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2625 Jacobson, "RTP: A Transport Protocol for Real-Time 2626 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2627 July 2003, . 2629 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 2630 Video Conferences with Minimal Control", STD 65, RFC 3551, 2631 DOI 10.17487/RFC3551, July 2003, 2632 . 2634 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 2635 Modifiers for RTP Control Protocol (RTCP) Bandwidth", 2636 RFC 3556, DOI 10.17487/RFC3556, July 2003, 2637 . 2639 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2640 in Session Description Protocol (SDP)", RFC 3605, 2641 DOI 10.17487/RFC3605, October 2003, 2642 . 2644 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2645 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2646 RFC 3711, DOI 10.17487/RFC3711, March 2004, 2647 . 2649 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 2650 "Indicating User Agent Capabilities in the Session 2651 Initiation Protocol (SIP)", RFC 3840, 2652 DOI 10.17487/RFC3840, August 2004, 2653 . 2655 [RFC3890] Westerlund, M., "A Transport Independent Bandwidth 2656 Modifier for the Session Description Protocol (SDP)", 2657 RFC 3890, DOI 10.17487/RFC3890, September 2004, 2658 . 2660 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 2661 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 2662 . 2664 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 2665 (ICE): A Protocol for Network Address Translator (NAT) 2666 Traversal for Offer/Answer Protocols", RFC 5245, 2667 DOI 10.17487/RFC5245, April 2010, 2668 . 2670 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 2671 DOI 10.17487/RFC5322, October 2008, 2672 . 2674 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2675 Protocol (SDP) Grouping Framework", RFC 5888, 2676 DOI 10.17487/RFC5888, June 2010, 2677 . 2679 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 2680 "Network Time Protocol Version 4: Protocol and Algorithms 2681 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 2682 . 2684 [RFC6466] Salgueiro, G., "IANA Registration of the 'image' Media 2685 Type for the Session Description Protocol (SDP)", 2686 RFC 6466, DOI 10.17487/RFC6466, December 2011, 2687 . 2689 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 2690 "TCP Candidates with Interactive Connectivity 2691 Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, 2692 March 2012, . 2694 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2695 Specifications and Registration Procedures", BCP 13, 2696 RFC 6838, DOI 10.17487/RFC6838, January 2013, 2697 . 2699 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 2700 RFC 7405, DOI 10.17487/RFC7405, December 2014, 2701 . 2703 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 2704 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 2705 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 2706 DOI 10.17487/RFC7656, November 2015, 2707 . 2709 [RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 2710 and M. Stiemerling, Ed., "Real-Time Streaming Protocol 2711 Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December 2712 2016, . 2714 Authors' Addresses 2716 Ali Begen 2717 Networked Media 2718 Konya 2719 Turkey 2721 EMail: ali.begen@networked.media 2723 Paul Kyzivat 2724 USA 2726 EMail: pkyzivat@alum.mit.edu 2728 Colin Perkins 2729 University of Glasgow 2730 School of Computing Science 2731 University of Glasgow 2732 Glasgow G12 8QQ 2733 UK 2735 EMail: csp@csperkins.org 2736 Mark Handley 2737 University College London 2738 Department of Computer Science 2739 London WC1E 6BT 2740 UK 2742 EMail: M.Handley@cs.ucl.ac.uk