idnits 2.17.1 draft-ietf-mmusic-rfc4566bis-24.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 (October 7, 2017) is 2385 days in the past. Is this intentional? 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: 'RFC 2978' is mentioned on line 1500, but not defined == Missing Reference: 'RFC2848' is mentioned on line 2155, but not defined == Missing Reference: 'RFC3108' is mentioned on line 2160, but not defined == Missing Reference: 'RFC7195' is mentioned on line 2161, but not defined == Missing Reference: 'RFC4145' is mentioned on line 2189, but not defined == Missing Reference: 'RFC6135' is mentioned on line 2190, but not defined == Unused Reference: 'RFC2978' is defined on line 2508, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-mmusic-data-channel-sdpneg-13 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-16 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- 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 (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Handley 3 Internet-Draft UCL 4 Obsoletes: 4566 (if approved) C. Perkins 5 Intended status: Standards Track University of Glasgow 6 Expires: April 10, 2018 A. Begen 7 Networked Media 8 October 7, 2017 10 SDP: Session Description Protocol 11 draft-ietf-mmusic-rfc4566bis-24 13 Abstract 15 This memo defines the Session Description Protocol (SDP). SDP is 16 intended for describing multimedia sessions for the purposes of 17 session announcement, session invitation, and other forms of 18 multimedia session initiation. This document obsoletes RFC 4566. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 10, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 5 70 3.2. Streaming Media . . . . . . . . . . . . . . . . . . . . . 5 71 3.3. Email and the World Wide Web . . . . . . . . . . . . . . 5 72 3.4. Multicast Session Announcement . . . . . . . . . . . . . 5 73 4. Requirements and Recommendations . . . . . . . . . . . . . . 6 74 4.1. Media and Transport Information . . . . . . . . . . . . . 7 75 4.2. Timing Information . . . . . . . . . . . . . . . . . . . 7 76 4.3. Obtaining Further Information about a Session . . . . . . 8 77 4.4. Categorisation . . . . . . . . . . . . . . . . . . . . . 8 78 4.5. Internationalisation . . . . . . . . . . . . . . . . . . 8 79 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . . 8 80 5.1. Protocol Version ("v=") . . . . . . . . . . . . . . . . . 11 81 5.2. Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 12 82 5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 13 83 5.4. Session Information ("i=") . . . . . . . . . . . . . . . 13 84 5.5. URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . 14 85 5.6. Email Address and Phone Number ("e=" and "p=") . . . . . 14 86 5.7. Connection Data ("c=") . . . . . . . . . . . . . . . . . 15 87 5.8. Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . 17 88 5.9. Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 18 89 5.10. Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . 19 90 5.11. Time Zones ("z=") . . . . . . . . . . . . . . . . . . . . 19 91 5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 20 92 5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 20 93 5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 21 94 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 24 95 6.1. cat (category) . . . . . . . . . . . . . . . . . . . . . 24 96 6.2. keywds (keywords) . . . . . . . . . . . . . . . . . . . . 25 97 6.3. tool . . . . . . . . . . . . . . . . . . . . . . . . . . 25 98 6.4. ptime (packet time) . . . . . . . . . . . . . . . . . . . 26 99 6.5. maxptime (maximum packet time) . . . . . . . . . . . . . 26 100 6.6. rtpmap . . . . . . . . . . . . . . . . . . . . . . . . . 27 101 6.7. Media Direction Attributes . . . . . . . . . . . . . . . 28 102 6.7.1. recvonly (receive-only) . . . . . . . . . . . . . . . 29 103 6.7.2. sendrecv (send-receive) . . . . . . . . . . . . . . . 30 104 6.7.3. sendonly (send-only) . . . . . . . . . . . . . . . . 30 105 6.7.4. inactive . . . . . . . . . . . . . . . . . . . . . . 30 106 6.8. orient (orientation) . . . . . . . . . . . . . . . . . . 31 107 6.9. type (conference type) . . . . . . . . . . . . . . . . . 31 108 6.10. charset (character set) . . . . . . . . . . . . . . . . . 32 109 6.11. sdplang (SDP language) . . . . . . . . . . . . . . . . . 33 110 6.12. lang (language) . . . . . . . . . . . . . . . . . . . . . 34 111 6.13. framerate (frame rate) . . . . . . . . . . . . . . . . . 35 112 6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 36 113 6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 36 114 7. Security Considerations . . . . . . . . . . . . . . . . . . . 37 115 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 116 8.1. The "application/sdp" Media Type . . . . . . . . . . . . 39 117 8.2. Registration of Parameters . . . . . . . . . . . . . . . 41 118 8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 41 119 8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 41 120 8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 42 121 8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 42 122 8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 45 123 8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 45 124 8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 46 125 8.2.8. Registration Procedure . . . . . . . . . . . . . . . 46 126 8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 47 127 8.4. Reorganization of the nettype Registry . . . . . . . . . 47 128 8.5. Reorganization of the att-field Registries . . . . . . . 47 129 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 48 130 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 53 131 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54 132 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 133 12.1. Normative References . . . . . . . . . . . . . . . . . . 54 134 12.2. Informative References . . . . . . . . . . . . . . . . . 55 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 137 1. Introduction 139 When initiating multimedia teleconferences, voice-over-IP calls, 140 streaming video, or other sessions, there is a requirement to convey 141 media details, transport addresses, and other session description 142 metadata to the participants. 144 SDP provides a standard representation for such information, 145 irrespective of how that information is transported. SDP is purely a 146 format for session description -- it does not incorporate a transport 147 protocol, and it is intended to use different transport protocols as 148 appropriate, including the Session Announcement Protocol (SAP) 149 [RFC2974], Session Initiation Protocol (SIP) [RFC3261], Real Time 150 Streaming Protocol (RTSP) [RFC7826], electronic mail using the MIME 151 extensions, and the Hypertext Transport Protocol (HTTP). 153 SDP is intended to be general purpose so that it can be used in a 154 wide range of network environments and applications. However, it is 155 not intended to support negotiation of session content or media 156 encodings: this is viewed as outside the scope of session 157 description. 159 This memo obsoletes [RFC4566]. The changes relative to [RFC4566] are 160 limited to essential corrections, and are outlined in Section 10 of 161 this memo. 163 2. Glossary of Terms 165 The following terms are used in this document and has specific 166 meaning within the context of this document. 168 Session Description: A well-defined format for conveying sufficient 169 information to discover and participate in a multimedia session. 171 Media Description: A media description starts with an "m=" line and 172 is terminated by either the next "m=" line or by the end of the 173 session description. 175 Session-level Section: This refers to the parts that are not media 176 descriptions, whereas the session description refers to the whole 177 body that includes the session-level section and the media 178 description(s). 180 The terms "multimedia conference" and "multimedia session" are used 181 in this document as defined in [RFC7656]. The terms "session" and 182 "multimedia session" are used interchangeably in this document. 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 186 "OPTIONAL" in this document are to be interpreted as described in 187 [RFC2119]. 189 3. Examples of SDP Usage 191 3.1. Session Initiation 193 The Session Initiation Protocol (SIP) [RFC3261] is an application- 194 layer control protocol for creating, modifying, and terminating 195 sessions such as Internet multimedia conferences, Internet telephone 196 calls, and multimedia distribution. The SIP messages used to create 197 sessions carry session descriptions that allow participants to agree 198 on a set of compatible media types. These session descriptions are 199 commonly formatted using SDP. When used with SIP, the offer/answer 200 model [RFC3264] provides a limited framework for negotiation using 201 SDP. 203 3.2. Streaming Media 205 The Real Time Streaming Protocol (RTSP) [RFC7826], is an application- 206 level protocol for control over the delivery of data with real-time 207 properties. RTSP provides an extensible framework to enable 208 controlled, on-demand delivery of real-time data, such as audio and 209 video. An RTSP client and server negotiate an appropriate set of 210 parameters for media delivery, partially using SDP syntax to describe 211 those parameters. 213 3.3. Email and the World Wide Web 215 Alternative means of conveying session descriptions include 216 electronic mail and the World Wide Web (WWW). For both email and WWW 217 distribution, the media type "application/sdp" is used. This enables 218 the automatic launching of applications for participation in the 219 session from the WWW client or mail reader in a standard manner. 221 Note that announcements of multicast sessions made only via email or 222 the WWW do not have the property that the receiver of a session 223 announcement can necessarily receive the session because the 224 multicast sessions may be restricted in scope, and access to the WWW 225 server or reception of email is possible outside this scope. 227 3.4. Multicast Session Announcement 229 In order to assist the advertisement of multicast multimedia 230 conferences and other multicast sessions, and to communicate the 231 relevant session setup information to prospective participants, a 232 distributed session directory may be used. An instance of such a 233 session directory periodically sends packets containing a description 234 of the session to a well-known multicast group. These advertisements 235 are received by other session directories such that potential remote 236 participants can use the session description to start the tools 237 required to participate in the session. 239 One protocol used to implement such a distributed directory is the 240 SAP [RFC2974]. SDP provides the recommended session description 241 format for such session announcements. 243 4. Requirements and Recommendations 245 The purpose of SDP is to convey information about media streams in 246 multimedia sessions to allow the recipients of a session description 247 to participate in the session. SDP is primarily intended for use in 248 an internetwork, although it is sufficiently general that it can 249 describe multimedia conferences in other network environments. Media 250 streams can be many-to-many. Sessions need not be continually 251 active. 253 Thus far, multicast-based sessions on the Internet have differed from 254 many other forms of conferencing in that anyone receiving the traffic 255 can join the session (unless the session traffic is encrypted). In 256 such an environment, SDP serves two primary purposes. It is a means 257 to communicate the existence of a session, and it is a means to 258 convey sufficient information to enable joining and participating in 259 the session. In a unicast environment, only the latter purpose is 260 likely to be relevant. 262 An SDP description includes the following: 264 o Session name and purpose 266 o Time(s) the session is active 268 o The media comprising the session 270 o Information needed to receive those media (addresses, ports, 271 formats, etc.) 273 As resources necessary to participate in a session may be limited, 274 some additional information may also be desirable: 276 o Information about the bandwidth to be used by the session 278 o Contact information for the person responsible for the session 280 In general, SDP must convey sufficient information to enable 281 applications to join a session (with the possible exception of 282 encryption keys) and to announce the resources to be used to any non- 283 participants that may need to know. (This latter feature is 284 primarily useful when SDP is used with a multicast session 285 announcement protocol.) 287 4.1. Media and Transport Information 289 An SDP description includes the following media information: 291 o The type of media (video, audio, etc.) 293 o The media transport protocol (RTP/UDP/IP, H.320, etc.) 295 o The format of the media (H.261 video, MPEG video, etc.) 297 In addition to media format and transport protocol, SDP conveys 298 address and port details. For an IP multicast session, these 299 comprise: 301 o The multicast group address for media 303 o The transport port for media 305 This address and port are the destination address and destination 306 port of the multicast stream, whether being sent, received, or both. 308 For unicast IP sessions, the following are conveyed: 310 o The remote address for media 312 o The remote transport port for media 314 The semantics of this address and port depend on the media and 315 transport protocol defined. By default, this SHOULD be the remote 316 address and remote port to which data is sent. Some media types may 317 redefine this behaviour, but this is NOT RECOMMENDED since it 318 complicates implementations (including middleboxes that must parse 319 the addresses to open Network Address Translation (NAT) or firewall 320 pinholes). 322 4.2. Timing Information 324 Sessions may be either bounded or unbounded in time. Whether or not 325 they are bounded, they may be only active at specific times. SDP can 326 convey: 328 o An arbitrary list of start and stop times bounding the session 330 o For each bound, repeat times such as "every Wednesday at 10am for 331 one hour" 333 This timing information is globally consistent, irrespective of local 334 time zone or daylight saving time (see Section 5.9). 336 4.3. Obtaining Further Information about a Session 338 A session description could convey enough information to decide 339 whether or not to participate in a session. SDP may include 340 additional pointers in the form of Uniform Resource Identifiers 341 (URIs) for more information about the session. 343 4.4. Categorisation 345 When many session descriptions are being distributed by SAP, or any 346 other advertisement mechanism, it may be desirable to filter session 347 announcements that are of interest from those that are not. SDP 348 supports a categorisation mechanism for sessions that is capable of 349 being automated (the "a=cat:" attribute; see Section 6). 351 4.5. Internationalisation 353 The SDP specification recommends the use of the ISO 10646 character 354 set in the UTF-8 encoding [RFC3629] to allow many different languages 355 to be represented. However, to assist in compact representations, 356 SDP also allows other character sets such as ISO 8859-1 to be used 357 when desired. Internationalisation only applies to free-text fields 358 (session name and background information), and not to SDP as a whole. 360 5. SDP Specification 362 An SDP description is denoted by the media type "application/sdp" 363 (See Section 8). 365 An SDP description is entirely textual. SDP field names and 366 attribute names use only the US-ASCII subset of UTF-8, but textual 367 fields and attribute values MAY use the full ISO 10646 character set 368 in UTF-8 encoding, or some other character set defined by the 369 "a=charset:" attribute. Field and attribute values that use the full 370 UTF-8 character set are never directly compared, hence there is no 371 requirement for UTF-8 normalisation. The textual form, as opposed to 372 a binary encoding such as ASN.1 or XDR, was chosen to enhance 373 portability, to enable a variety of transports to be used, and to 374 allow flexible, text-based toolkits to be used to generate and 375 process session descriptions. However, since SDP may be used in 376 environments where the maximum permissible size of a session 377 description is limited, the encoding is deliberately compact. Also, 378 since announcements may be transported via very unreliable means or 379 damaged by an intermediate caching server, the encoding was designed 380 with strict order and formatting rules so that most errors would 381 result in malformed session announcements that could be detected 382 easily and discarded. This also allows rapid discarding of encrypted 383 session announcements for which a receiver does not have the correct 384 key. 386 An SDP description consists of a number of lines of text of the form: 388 = 390 where MUST be exactly one case-significant character and 391 is structured text whose format depends on . In 392 general, is either a number of fields delimited by a single 393 space character or a free format string, and is case-significant 394 unless a specific field defines otherwise. Whitespace separators 395 MUST NOT be used on either side of the "=" sign, however, if the 396 value can contain a leading whitespace as part of its syntax, i.e., 397 that whitespace is part of the value. 399 An SDP description consists of a session-level section followed by 400 zero or more media descriptions. The session-level section starts 401 with a "v=" line and continues to the first media description (or the 402 end of the whole description, whichever comes first). Each media 403 description starts with an "m=" line and continues to the next media 404 description or the end of the whole session description - whichever 405 comes first. In general, session-level values are the default for 406 all media unless overridden by an equivalent media-level value. 408 Some lines in each description are REQUIRED and some are OPTIONAL, 409 but all MUST appear in exactly the order given here (the fixed order 410 greatly enhances error detection and allows for a simple parser). 411 OPTIONAL items are marked with a "*". 413 Session description 414 v= (protocol version) 415 o= (originator and session identifier) 416 s= (session name) 417 i=* (session information) 418 u=* (URI of description) 419 e=* (email address) 420 p=* (phone number) 421 c=* (connection information -- not required if included in 422 all media descriptions) 423 b=* (zero or more bandwidth information lines) 424 One or more time descriptions ("t=" and "r=" lines; see below) 425 z=* (time zone adjustments) 426 k=* (encryption key) 427 a=* (zero or more session attribute lines) 428 Zero or more media descriptions 430 Time description 431 t= (time the session is active) 432 r=* (zero or more repeat times) 434 Media description, if present 435 m= (media name and transport address) 436 i=* (media title) 437 c=* (connection information -- optional if included at 438 session level) 439 b=* (zero or more bandwidth information lines) 440 k=* (encryption key) 441 a=* (zero or more media attribute lines) 443 The set of type letters is deliberately small and not intended to be 444 extensible -- an SDP parser MUST completely ignore any session 445 description that contains a type letter that it does not understand. 446 The attribute mechanism ("a=" described below) is the primary means 447 for extending SDP and tailoring it to particular applications or 448 media. Some attributes (the ones listed in Section 6 of this memo) 449 have a defined meaning, but others may be added on an application-, 450 media-, or session-specific basis. An SDP parser MUST ignore any 451 attribute it doesn't understand. 453 An SDP description may contain URIs that reference external content 454 in the "u=", "k=", and "a=" lines. These URIs may be dereferenced in 455 some cases, making the session description non-self- contained. 457 The connection ("c=") information in the session-level section 458 applies to all the media of that session unless overridden by 459 connection information in the media description. For instance, in 460 the example below, each audio media description behaves as if it were 461 given a "c=IN IP4 233.252.0.2". 463 An example SDP description is: 465 v=0 466 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 467 s=SDP Seminar 468 i=A Seminar on the session description protocol 469 u=http://www.example.com/seminars/sdp.pdf 470 e=j.doe@example.com (Jane Doe) 471 c=IN IP4 233.252.0.2 472 t=2873397496 2873404696 473 a=recvonly 474 m=audio 49170 RTP/AVP 0 475 m=audio 49180 RTP/AVP 0 476 m=video 51372 RTP/AVP 99 477 c=IN IP4 233.252.0.1/127 478 a=rtpmap:99 h263-1998/90000 480 Text fields such as the session name and information are octet 481 strings that may contain any octet with the exceptions of 0x00 (Nul), 482 0x0a (ASCII newline), and 0x0d (ASCII carriage return). The sequence 483 CRLF (0x0d0a) is used to end a record, although parsers SHOULD be 484 tolerant and also accept records terminated with a single newline 485 character. If the "a=charset" attribute is not present, these octet 486 strings MUST be interpreted as containing ISO-10646 characters in 487 UTF-8 encoding (the presence of the "a=charset" attribute may force 488 some fields to be interpreted differently). 490 A session description can contain domain names in the "o=", "u=", 491 "e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply 492 with [RFC1034], [RFC1035]. Internationalised domain names (IDNs) 493 MUST be represented using the ASCII Compatible Encoding (ACE) form 494 defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or 495 any other encoding (this requirement is for compatibility with 496 [RFC2327] and other early SDP-related standards, which predate the 497 development of internationalised domain names). 499 5.1. Protocol Version ("v=") 501 v=0 503 The "v=" line gives the version of the Session Description Protocol. 504 This memo defines version 0. There is no minor version number. 506 5.2. Origin ("o=") 508 o= 509 511 The "o=" line gives the originator of the session (her username and 512 the address of the user's host) plus a session identifier and version 513 number: 515 is the user's login on the originating host, or it is "-" 516 if the originating host does not support the concept of user IDs. 517 The MUST NOT contain spaces. 519 is a numeric string such that the tuple of , 520 , , , and forms a 521 globally unique identifier for the session. The method of allocation is up to the creating tool, but it has been 523 suggested that a Network Time Protocol (NTP) format timestamp be 524 used to ensure uniqueness [RFC5905]. 526 is a version number for this session description. 527 Its usage is up to the creating tool, so long as is 528 increased when a modification is made to the session data. Again, 529 it is RECOMMENDED that an NTP format timestamp is used. 531 is a text string giving the type of network. Initially 532 "IN" is defined to have the meaning "Internet", but other values 533 MAY be registered in the future (see Section 8). 535 is a text string giving the type of the address that 536 follows. Initially "IP4" and "IP6" are defined, but other values 537 MAY be registered in the future (see Section 8). 539 is an address of the machine from which the 540 session was created. For an address type of IP4, this is either a 541 fully qualified domain name of the machine or the dotted-decimal 542 representation of an IP version 4 address of the machine. For an 543 address type of IP6, this is either a fully qualified domain name 544 of the machine or the compressed textual representation of an IP 545 version 6 address of the machine. For both IP4 and IP6, the fully 546 qualified domain name is the form that SHOULD be given unless this 547 is unavailable, in which case a globally unique address MAY be 548 substituted. Unless an SDP extension for NAT traversal is used 549 (e.g., ICE [RFC5245], ICE TCP [RFC6544]), a local IP address MUST 550 NOT be used in any context where the SDP description might leave 551 the scope in which the address is meaningful (for example, a local 552 address MUST NOT be included in an application-level referral that 553 might leave the scope). 555 In general, the "o=" line serves as a globally unique identifier for 556 this version of this session description, and the sub-fields 557 excepting the version taken together identify the session 558 irrespective of any modifications. 560 For privacy reasons, it is sometimes desirable to obfuscate the 561 username and IP address of the session originator. If this is a 562 concern, an arbitrary and private MAY be 563 chosen to populate the "o=" line, provided that these are selected in 564 a manner that does not affect the global uniqueness of the field. 566 5.3. Session Name ("s=") 568 s= 570 The "s=" line is the textual session name. There MUST be one and 571 only one "s=" line per session description. The "s=" line MUST NOT 572 be empty and SHOULD contain ISO 10646 characters (but see also the 573 "a=charset" attribute). If a session has no meaningful name, the 574 value "s= " SHOULD be used (i.e., a single space as the session 575 name). 577 5.4. Session Information ("i=") 579 i= 581 The "i=" line provides textual information about the session. There 582 MUST be at most one session-level "i=" line per session description, 583 and at most one "i=" line per media description/definition. Unless a 584 media level "i="" line is used, the session-level "i="" line applies 585 to that media description. If the "a=charset" attribute is present, 586 it specifies the character set used in the "i=" line. If the 587 "a=charset" attribute is not present, the "i=" line MUST contain ISO 588 10646 characters in UTF-8 encoding. 590 A single "i=" line can be used for each media definition. In media 591 definitions, "i=" lines are primarily intended for labelling media 592 streams. As such, they are most likely to be useful when a single 593 session has more than one distinct media stream of the same media 594 type. An example would be two different whiteboards, one for slides 595 and one for feedback and questions. 597 The "i=" line is intended to provide a free-form human-readable 598 description of the session or the purpose of a media stream. It is 599 not suitable for parsing by automata. 601 5.5. URI ("u=") 603 u= 605 A URI is a Uniform Resource Identifier as used by WWW clients 606 [RFC3986]. The URI should be a pointer to additional information 607 about the session. This line is OPTIONAL. No more than one URI line 608 is allowed per session description. 610 5.6. Email Address and Phone Number ("e=" and "p=") 612 e= 613 p= 615 The "e=" and "p=" lines specify contact information for the person 616 responsible for the session. This is not necessarily the same person 617 that created the session description. 619 Inclusion of an email address or phone number is OPTIONAL. 621 If an email address or phone number is present, it MUST be specified 622 before the first media field. More than one email or phone line can 623 be given for a session description. 625 Phone numbers SHOULD be given in the form of an international public 626 telecommunication number (see ITU-T Recommendation E.164) preceded by 627 a "+". Spaces and hyphens may be used to split up a phone field to 628 aid readability if desired. For example: 630 p=+1 617 555-6011 632 Both email addresses and phone numbers can have an OPTIONAL free text 633 string associated with them, normally giving the name of the person 634 who may be contacted. This MUST be enclosed in parentheses if it is 635 present. For example: 637 e=j.doe@example.com (Jane Doe) 639 The alternative [RFC5322] name quoting convention is also allowed for 640 both email addresses and phone numbers. For example: 642 e=Jane Doe 644 The free text string SHOULD be in the ISO-10646 character set with 645 UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if 646 the appropriate session-level "a=charset" attribute is set. 648 5.7. Connection Data ("c=") 650 c= 652 The "c=" line contains connection data. 654 A session description MUST contain either at least one "c=" line in 655 each media description or a single "c=" line at the session level. 656 It MAY contain a single session-level "c=" line and additional "c=" 657 line(s) per media description, in which case the per-media values 658 override the session-level settings for the respective media. 660 The first sub-field ("") is the network type, which is a 661 text string giving the type of network. Initially, "IN" is defined 662 to have the meaning "Internet", but other values MAY be registered in 663 the future (see Section 8). 665 The second sub-field ("") is the address type. This allows 666 SDP to be used for sessions that are not IP based. This memo only 667 defines IP4 and IP6, but other values MAY be registered in the future 668 (see Section 8). 670 The third sub-field ("") is the connection 671 address. OPTIONAL sub-fields MAY be added after the connection 672 address depending on the value of the field. 674 When the is IP4 and IP6, the connection address is defined 675 as follows: 677 o If the session is multicast, the connection address will be an IP 678 multicast group address. If the session is not multicast, then 679 the connection address contains the unicast IP address of the 680 expected data source or data relay or data sink as determined by 681 additional attribute fields. It is not expected that unicast 682 addresses will be given in a session description that is 683 communicated by a multicast announcement, though this is not 684 prohibited. 686 o Sessions using an IP4 multicast connection address MUST also have 687 a time to live (TTL) value present in addition to the multicast 688 address. The TTL and the address together define the scope with 689 which multicast packets sent in this session will be sent. TTL 690 values MUST be in the range 0-255. Although the TTL MUST be 691 specified, its use to scope multicast traffic is deprecated; 692 applications SHOULD use an administratively scoped address 693 instead. 695 The TTL for the session is appended to the address using a slash as a 696 separator. An example is: 698 c=IN IP4 233.252.0.1/127 700 IP6 multicast does not use TTL scoping, and hence the TTL value MUST 701 NOT be present for IP6 multicast. It is expected that IP6 scoped 702 addresses will be used to limit the scope of multimedia conferences. 704 Hierarchical or layered encoding schemes are data streams where the 705 encoding from a single media source is split into a number of layers. 706 The receiver can choose the desired quality (and hence bandwidth) by 707 only subscribing to a subset of these layers. Such layered encodings 708 are normally transmitted in multiple multicast groups to allow 709 multicast pruning. This technique keeps unwanted traffic from sites 710 only requiring certain levels of the hierarchy. For applications 711 requiring multiple multicast groups, we allow the following notation 712 to be used for the connection address: 714 [/]/ 716 If the number of addresses is not given, it is assumed to be one. 717 Multicast addresses so assigned are contiguously allocated above the 718 base address, so that, for example: 720 c=IN IP4 233.252.0.1/127/3 722 would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3 723 are to be used at a TTL of 127. This is semantically identical to 724 including multiple "c=" lines in a media description: 726 c=IN IP4 233.252.0.1/127 727 c=IN IP4 233.252.0.2/127 728 c=IN IP4 233.252.0.3/127 730 Similarly, an IP6 example would be: 732 c=IN IP6 FF15::101/3 734 which is semantically equivalent to: 736 c=IN IP6 FF15::101 737 c=IN IP6 FF15::102 738 c=IN IP6 FF15::103 740 (remembering that the TTL field is not present in IP6 multicast). 742 Multiple addresses or "c=" lines MAY be specified on a per-media 743 basis only if they provide multicast addresses for different layers 744 in a hierarchical or layered encoding scheme. They MUST NOT be 745 specified for a session-level "c=" line. 747 The slash notation for multiple addresses described above MUST NOT be 748 used for IP unicast addresses. 750 5.8. Bandwidth ("b=") 752 b=: 754 This OPTIONAL line denotes the proposed bandwidth to be used by the 755 session or media. The is an alphanumeric modifier giving 756 the meaning of the figure. Two values are defined in 757 this specification, but other values MAY be registered in the future 758 (see Section 8 and [RFC3556], [RFC3890]): 760 CT If the bandwidth of a session is different from the bandwidth 761 implicit from the scope, a "b=CT:..." line SHOULD be supplied for 762 the session giving the proposed upper limit to the bandwidth used 763 (the "conference total" bandwidth). Similarly, if the bandwidth 764 of bundled media streams in an m line is different from the 765 implicit value from the scope, a "b=CT:..." line SHOULD be 766 supplied in the media level. The primary purpose of this is to 767 give an approximate idea as to whether two or more sessions (or 768 bundled media streams) can coexist simultaneously. Note that CT 769 gives a total bandwidth figure for all the media at all endpoints. 771 AS The bandwidth is interpreted to be application specific (it will 772 be the application's concept of maximum bandwidth). Normally, 773 this will coincide with what is set on the application's "maximum 774 bandwidth" control if applicable. For RTP-based applications, AS 775 gives the RTP "session bandwidth" as defined in Section 6.2 of 776 [RFC3550]. Note that AS gives a bandwidth figure for a single 777 media at a single endpoint, although there may be many endpoints 778 sending simultaneously. 780 A prefix "X-" is defined for names. This is intended for 781 experimental purposes only. For example: 783 b=X-YZ:128 785 Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers 786 SHOULD be registered with IANA in the standard namespace. SDP 787 parsers MUST ignore bandwidth fields with unknown modifiers. 788 Modifiers MUST be alphanumeric and, although no length limit is 789 given, it is recommended that they be short. 791 The is interpreted as kilobits per second by default. 792 The definition of a new modifier MAY specify that the 793 bandwidth is to be interpreted in some alternative unit (the "CT" and 794 "AS" modifiers defined in this memo use the default units). 796 5.9. Timing ("t=") 798 t= 800 The "t=" lines specify the start and stop times for a session. 801 Multiple "t=" lines MAY be used if a session is active at multiple 802 irregularly spaced times; each additional "t=" line specifies an 803 additional period of time for which the session will be active. If 804 the session is active at regular times, an "r=" line (see below) 805 should be used in addition to, and following, a "t=" line -- in which 806 case the "t=" line specifies the start and stop times of the repeat 807 sequence. 809 The first and second sub-fields give the start and stop times, 810 respectively, for the session. These values are the decimal 811 representation of Network Time Protocol (NTP) time values in seconds 812 since 1900 [RFC5905]. To convert these values to UNIX time, subtract 813 decimal 2208988800. 815 NTP timestamps are elsewhere represented by 64-bit values, which wrap 816 sometime in the year 2036. Since SDP uses an arbitrary length 817 decimal representation, this should not cause an issue (SDP 818 timestamps MUST continue counting seconds since 1900, NTP will use 819 the value modulo the 64-bit limit). 821 If the is set to zero, then the session is not bounded, 822 though it will not become active until after the . If 823 the is also zero, the session is regarded as permanent. 825 User interfaces SHOULD strongly discourage the creation of unbounded 826 and permanent sessions as they give no information about when the 827 session is actually going to terminate, and so make scheduling 828 difficult. 830 The general assumption may be made, when displaying unbounded 831 sessions that have not timed out to the user, that an unbounded 832 session will only be active until half an hour from the current time 833 or the session start time, whichever is the later. If behaviour 834 other than this is required, an end-time SHOULD be given and modified 835 as appropriate when new information becomes available about when the 836 session should really end. 838 Permanent sessions may be shown to the user as never being active 839 unless there are associated repeat times that state precisely when 840 the session will be active. 842 5.10. Repeat Times ("r=") 844 r= 846 "r=" line specifies repeat times for a session. For example, if a 847 session is active at 10am on Monday and 11am on Tuesday for one hour 848 each week for three months, then the in the 849 corresponding "t=" line would be the NTP representation of 10am on 850 the first Monday, the would be 1 week, the would be 1 hour, and the offsets would be zero and 25 852 hours. The corresponding "t=" line stop time would be the NTP 853 representation of the end of the last session three months later. By 854 default, all fields are in seconds, so the "r=" and "t=" lines might 855 be the following: 857 t=3034423619 3042462419 858 r=604800 3600 0 90000 860 To make the description more compact, times may also be given in 861 units of days, hours, or minutes. The syntax for these is a number 862 immediately followed by a single case-sensitive character. 863 Fractional units are not allowed -- a smaller unit should be used 864 instead. The following unit specification characters are allowed: 866 d - days (86400 seconds) 867 h - hours (3600 seconds) 868 m - minutes (60 seconds) 869 s - seconds (allowed for completeness) 871 Thus, the above session announcement could also have been written: 873 r=7d 1h 0 25h 875 Monthly and yearly repeats cannot be directly specified with a single 876 SDP repeat time; instead, separate "t=" lines should be used to 877 explicitly list the session times. 879 5.11. Time Zones ("z=") 881 z= .... 883 To schedule a repeated session that spans a change from daylight 884 saving time to standard time or vice versa, it is necessary to 885 specify offsets from the base time. This is required because 886 different time zones change time at different times of day, different 887 countries change to or from daylight saving time on different dates, 888 and some countries do not have daylight saving time at all. 890 Thus, in order to schedule a session that is at the same time winter 891 and summer, it must be possible to specify unambiguously by whose 892 time zone a session is scheduled. To simplify this task for 893 receivers, we allow the sender to specify the NTP time that a time 894 zone adjustment happens and the offset from the time when the session 895 was first scheduled. The "z=" line allows the sender to specify a 896 list of these adjustment times and offsets from the base time. 898 An example might be the following: 900 z=2882844526 -1h 2898848070 0 902 This specifies that at time 2882844526, the time base by which the 903 session's repeat times are calculated is shifted back by 1 hour, and 904 that at time 2898848070, the session's original time base is 905 restored. Adjustments are always relative to the specified start 906 time -- they are not cumulative. Adjustments apply to all "t=" and 907 "r=" lines in a session description. 909 If a session is likely to last several years, it is expected that the 910 session description will be modified periodically rather than 911 transmit several years' worth of adjustments in one session 912 description. 914 5.12. Encryption Keys ("k=") 916 k= 917 k=: 919 The "k=" line is obsolete and MUST NOT be used. It is included in 920 this document for legacy reasons. One MUST NOT include a "k=" line 921 in an SDP, and MUST discard it if it is received in an SDP. 923 5.13. Attributes ("a=") 925 a= 926 a=: 928 Attributes are the primary means for extending SDP. Attributes may 929 be defined to be used as "session-level" attributes, "media-level" 930 attributes, or both. 932 A media description may have any number of attributes ("a=" lines) 933 that are media specific. These are referred to as "media-level" 934 attributes and add information about the media stream. Attribute 935 lines can also be added before the first media field; these "session- 936 level" attributes convey additional information that applies to the 937 session as a whole rather than to individual media. 939 Attribute lines may be of two forms: 941 o A property attribute is simply of the form "a=". These are 942 binary attributes, and the presence of the attribute conveys that 943 the attribute is a property of the session. An example might be 944 "a=recvonly". 946 o A value attribute is of the form "a=:". For 947 example, a whiteboard could have the value attribute 948 "a=orient:landscape" 950 Attribute interpretation depends on the media tool being invoked. 951 Thus receivers of session descriptions should be configurable in 952 their interpretation of session descriptions in general and of 953 attributes in particular. 955 Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. 957 Attribute values are octet strings, and MAY use any octet value 958 except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute 959 values are to be interpreted as in ISO-10646 character set with UTF-8 960 encoding. Unlike other text fields, attribute values are NOT 961 normally affected by the "charset" attribute as this would make 962 comparisons against known values problematic. However, when an 963 attribute is defined, it can be defined to be charset dependent, in 964 which case its value should be interpreted in the session charset 965 rather than in ISO-10646. 967 Attributes MUST be registered with IANA (see Section 8). If an 968 attribute is received that is not understood, it MUST be ignored by 969 the receiver. 971 5.14. Media Descriptions ("m=") 973 m= ... 975 A session description may contain a number of media descriptions. 976 Each media description starts with an "m=" line and is terminated by 977 either the next "m=" line or by the end of the session description. 978 A media field has several sub-fields: 980 is the media type. This document defines the values 981 "audio", "video", "text", "application", and "message". This list 982 is extended and may be further extended by other memos registering 983 media types in the future (see Section 8). For example, [RFC6466] 984 defined the "image" media type. 986 is the transport port to which the media stream is sent. The 987 meaning of the transport port depends on the network being used as 988 specified in the relevant "c=" line, and on the transport protocol 989 defined in the sub-field of the media field. Other ports 990 used by the media application (such as the RTP Control Protocol 991 (RTCP) port [RFC3550]) MAY be derived algorithmically from the 992 base media port or MAY be specified in a separate attribute (for 993 example, "a=rtcp:" as defined in [RFC3605]). 995 If non-contiguous ports are used or if they don't follow the 996 parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" 997 attribute MUST be used. Applications that are requested to send 998 media to a that is odd and where the "a=rtcp:" is present 999 MUST NOT subtract 1 from the RTP port: that is, they MUST send the 1000 RTP to the port indicated in and send the RTCP to the port 1001 indicated in the "a=rtcp" attribute. 1003 For applications where hierarchically encoded streams are being 1004 sent to a unicast address, it may be necessary to specify multiple 1005 transport ports. This is done using a similar notation to that 1006 used for IP multicast addresses in the "c=" line: 1008 m= / ... 1010 In such a case, the ports used depend on the transport protocol. 1011 For RTP, the default is that only the even-numbered ports are used 1012 for data with the corresponding one-higher odd ports used for the 1013 RTCP belonging to the RTP session, and the 1014 denoting the number of RTP sessions. For example: 1016 m=video 49170/2 RTP/AVP 31 1018 would specify that ports 49170 and 49171 form one RTP/RTCP pair 1019 and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the 1020 transport protocol and 31 is the format (see below). If non- 1021 contiguous ports are required, they must be signalled using a 1022 separate attribute (for example, "a=rtcp:" as defined in 1023 [RFC3605]). 1025 If multiple addresses are specified in the "c=" line and multiple 1026 ports are specified in the "m=" line, a one-to-one mapping from 1027 port to the corresponding address is implied. For example: 1029 c=IN IP4 233.252.0.1/127/2 1030 m=video 49170/2 RTP/AVP 31 1032 would imply that address 233.252.0.1 is used with ports 49170 and 1033 49171, and address 233.252.0.2 is used with ports 49172 and 49173. 1035 The semantics of multiple "m=" lines using the same transport 1036 address are undefined. This implies that, unlike limited past 1037 practice, there is no implicit grouping defined by such means and 1038 an explicit grouping framework (for example, [RFC5888]) should 1039 instead be used to express the intended semantics. 1041 is the transport protocol. The meaning of the transport 1042 protocol is dependent on the address type field in the relevant 1043 "c=" line. Thus a "c=" field of IP4 indicates that the transport 1044 protocol runs over IP4. The following transport protocols are 1045 defined, but may be extended through registration of new protocols 1046 with IANA (see Section 8): 1048 * udp: denotes an unspecified protocol running over UDP. 1050 * RTP/AVP: denotes RTP [RFC3550] used under the RTP Profile for 1051 Audio and Video Conferences with Minimal Control [RFC3551] 1052 running over UDP. 1054 * RTP/SAVP: denotes the Secure Real-time Transport Protocol 1055 [RFC3711] running over UDP. 1057 The main reason to specify the transport protocol in addition to 1058 the media format is that the same standard media formats may be 1059 carried over different transport protocols even when the network 1060 protocol is the same -- a historical example is vat Pulse Code 1061 Modulation (PCM) audio and RTP PCM audio; another might be TCP/RTP 1062 PCM audio. In addition, relays and monitoring tools that are 1063 transport-protocol-specific but format-independent are possible. 1065 is a media format description. The fourth and any subsequent 1066 sub-fields describe the format of the media. The interpretation 1067 of the media format depends on the value of the sub-field. 1069 If the sub-field is "RTP/AVP" or "RTP/SAVP" the sub- 1070 fields contain RTP payload type numbers. When a list of payload 1071 type numbers is given, this implies that all of these payload 1072 formats MAY be used in the session, but the first of these formats 1073 SHOULD be used as the default format for the session. For dynamic 1074 payload type assignments the "a=rtpmap:" attribute (see Section 6) 1075 SHOULD be used to map from an RTP payload type number to a media 1076 encoding name that identifies the payload format. The "a=fmtp:" 1077 attribute MAY be used to specify format parameters (see 1078 Section 6). 1080 If the sub-field is "udp" the sub-fields MUST 1081 reference a media type describing the format under the "audio", 1082 "video", "text", "application", or "message" top-level media 1083 types. The media type registration SHOULD define the packet 1084 format for use with UDP transport. 1086 For media using other transport protocols, the field is 1087 protocol specific. Rules for interpretation of the sub- 1088 field MUST be defined when registering new protocols (see 1089 Section 8.2.2). 1091 Section 3 of [RFC4855] states that the payload format (encoding) 1092 names defined in the RTP Profile are commonly shown in upper case, 1093 while media subtype names are commonly shown in lower case. It 1094 also states that both of these names are case-insensitive in both 1095 places, similar to parameter names which are case-insensitive both 1096 in media type strings and in the default mapping to the SDP a=fmtp 1097 attribute. 1099 6. SDP Attributes 1101 The following attributes are defined. Since application writers may 1102 add new attributes as they are required, this list is not exhaustive. 1103 Registration procedures for new attributes are defined in 1104 Section 8.2.4. 1106 6.1. cat (category) 1108 Name: cat 1110 Value: cat-value 1112 Usage Level: session 1114 Charset Dependent: no 1116 Syntax: 1118 cat-value = category 1119 category = non-ws-string 1121 Example: 1123 a=cat:foo.bar 1125 This attribute gives the dot-separated hierarchical category of the 1126 session. This is to enable a receiver to filter unwanted sessions by 1127 category. There is no central registry of categories. This 1128 attribute is obsoleted. 1130 6.2. keywds (keywords) 1132 Name: keywds 1134 Value: keywds-value 1136 Usage Level: session 1138 Charset Dependent: yes 1140 Syntax: 1142 keywds-value = keywords 1143 keywords = text 1145 Example: 1147 a=keywds:SDP session description protocol 1149 Like the cat attribute, this is to assist identifying wanted sessions 1150 at the receiver. This allows a receiver to select interesting 1151 session based on keywords describing the purpose of the session; 1152 there is no central registry of keywords. Its value should be 1153 interpreted in the charset specified for the session description if 1154 one is specified, or by default in ISO 10646/UTF-8. This attribute 1155 is obsoleted. 1157 6.3. tool 1159 Name: tool 1161 Value: tool-value 1163 Usage Level: session 1165 Charset Dependent: no 1167 Syntax: 1169 tool-value = tool-name-and-version 1170 tool-name-and-version = text 1172 Example: 1174 a=tool:foobar V3.2 1176 This gives the name and version number of the tool used to create the 1177 session description. 1179 6.4. ptime (packet time) 1181 Name: ptime 1183 Value: ptime-value 1185 Usage Level: media 1187 Charset Dependent: no 1189 Syntax: 1191 ptime-value = non-zero-int-or-real 1193 Example: 1195 a=ptime:20 1197 This gives the length of time in milliseconds represented by the 1198 media in a packet. This is probably only meaningful for audio data, 1199 but may be used with other media types if it makes sense. It should 1200 not be necessary to know ptime to decode RTP or vat audio, and it is 1201 intended as a recommendation for the encoding/packetisation of audio. 1203 6.5. maxptime (maximum packet time) 1205 Name: maxptime 1207 Value: maxptime-value 1209 Usage Level: media 1211 Charset Dependent: no 1213 Syntax: 1215 maxptime-value = non-zero-int-or-real 1217 Example: 1219 a=maxptime:20 1221 This gives the maximum amount of media that can be encapsulated in 1222 each packet, expressed as time in milliseconds. The time SHALL be 1223 calculated as the sum of the time the media present in the packet 1224 represents. For frame-based codecs, the time SHOULD be an integer 1225 multiple of the frame size. This attribute is probably only 1226 meaningful for audio data, but may be used with other media types if 1227 it makes sense. Note that this attribute was introduced after 1228 [RFC2327], and non-updated implementations will ignore this 1229 attribute. 1231 6.6. rtpmap 1233 Name: rtpmap 1235 Value: rtpmap-value 1237 Usage Level: media 1239 Charset Dependent: no 1241 Syntax: 1243 rtpmap-value = payload-type SP encoding-name 1244 "/" clock-rate [ "/" encoding-params ] 1245 payload-type = zero-based-integer 1246 encoding-name = token 1247 clock-rate = integer 1248 encoding-params = channels 1249 channels = integer 1251 This attribute maps from an RTP payload type number (as used in an 1252 "m=" line) to an encoding name denoting the payload format to be 1253 used. It also provides information on the clock rate and encoding 1254 parameters. Note that the payload type number is indicated in a 1255 7-bit field, limiting the values to incusively between 0 and 127. 1257 Although an RTP profile can make static assignments of payload type 1258 numbers to payload formats, it is more common for that assignment to 1259 be done dynamically using "a=rtpmap:" attributes. As an example of a 1260 static payload type, consider u-law PCM coded single-channel audio 1261 sampled at 8 kHz. This is completely defined in the RTP Audio/Video 1262 profile as payload type 0, so there is no need for an "a=rtpmap:" 1263 attribute, and the media for such a stream sent to UDP port 49232 can 1264 be specified as: 1266 m=audio 49232 RTP/AVP 0 1268 An example of a dynamic payload type is 16-bit linear encoded stereo 1269 audio sampled at 16 kHz. If we wish to use the dynamic RTP/AVP 1270 payload type 98 for this stream, additional information is required 1271 to decode it: 1273 m=audio 49232 RTP/AVP 98 1274 a=rtpmap:98 L16/16000/2 1276 Up to one rtpmap attribute can be defined for each media format 1277 specified. Thus, we might have the following: 1279 m=audio 49230 RTP/AVP 96 97 98 1280 a=rtpmap:96 L8/8000 1281 a=rtpmap:97 L16/8000 1282 a=rtpmap:98 L16/11025/2 1284 RTP profiles that specify the use of dynamic payload types MUST 1285 define the set of valid encoding names and/or a means to register 1286 encoding names if that profile is to be used with SDP. The "RTP/AVP" 1287 and "RTP/SAVP" profiles use media subtypes for encoding names, under 1288 the top-level media type denoted in the "m=" line. In the example 1289 above, the media types are "audio/l8" and "audio/l16". 1291 For audio streams, indicates the number of 1292 audio channels. This parameter is OPTIONAL and may be omitted if the 1293 number of channels is one, provided that no additional parameters are 1294 needed. 1296 For video streams, no encoding parameters are currently specified. 1298 Additional encoding parameters MAY be defined in the future, but 1299 codec-specific parameters SHOULD NOT be added. Parameters added to 1300 an "a=rtpmap:" attribute SHOULD only be those required for a session 1301 directory to make the choice of appropriate media to participate in a 1302 session. Codec-specific parameters should be added in other 1303 attributes (for example, "a=fmtp:"). 1305 Note: RTP audio formats typically do not include information about 1306 the number of samples per packet. If a non-default (as defined in 1307 the RTP Audio/Video Profile) packetisation is required, the "ptime" 1308 attribute is used as given above. 1310 6.7. Media Direction Attributes 1312 At most one of recvonly/sendrecv/sendonly/inactive MAY appear at 1313 session level, and at most one MAY appear in each media section. 1315 If any one of these appears in a media section then it applies for 1316 that media section. If none appear in a media section then the one 1317 from session level, if any, applies to that media section. 1319 If none of the media direction attributes is present at either 1320 session level or media level, "sendrecv" SHOULD be assumed as the 1321 default for sessions that are not of the multimedia conference type 1322 "broadcast" or "H332" (see below). 1324 Within the following SDP example, the "inactive" attribute applies to 1325 audio media and the "recvonly" attribute applies to video media. 1327 v=0 1328 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 1329 s=SDP Seminar 1330 i=A Seminar on the session description protocol 1331 u=http://www.example.com/seminars/sdp.pdf 1332 e=j.doe@example.com (Jane Doe) 1333 c=IN IP4 233.252.0.1/127 1334 t=2873397496 2873404696 1335 a=inactive 1336 m=audio 49170 RTP/AVP 0 1337 m=video 51372 RTP/AVP 99 1338 a=rtpmap:99 h263-1998/90000 1339 a=recvonly 1341 6.7.1. recvonly (receive-only) 1343 Name: recvonly 1345 Value: 1347 Usage Level: session, media 1349 Charset Dependent: no 1351 Example: 1353 a=recvonly 1355 This specifies that the tools should be started in receive-only mode 1356 where applicable. Note that recvonly applies to the media only, not 1357 to any associated control protocol (e.g., an RTP-based system in 1358 recvonly mode SHOULD still send RTCP packets). 1360 6.7.2. sendrecv (send-receive) 1362 Name: sendrecv 1364 Value: 1366 Usage Level: session, media 1368 Charset Dependent: no 1370 Example: 1372 a=sendrecv 1374 This specifies that the tools should be started in send and receive 1375 mode. This is necessary for interactive multimedia conferences with 1376 tools that default to receive-only mode. 1378 6.7.3. sendonly (send-only) 1380 Name: sendonly 1382 Value: 1384 Usage Level: session, media 1386 Charset Dependent: no 1388 Example: 1390 a=sendonly 1392 This specifies that the tools should be started in send-only mode. 1393 An example may be where a different unicast address is to be used for 1394 a traffic destination than for a traffic source. In such a case, two 1395 media descriptions may be used, one sendonly and one recvonly. Note 1396 that sendonly applies only to the media, and any associated control 1397 protocol (e.g., RTCP) SHOULD still be received and processed as 1398 normal. 1400 6.7.4. inactive 1402 Name: inactive 1404 Value: 1406 Usage Level: session, media 1407 Charset Dependent: no 1409 Example: 1411 a=inactive 1413 This specifies that the tools should be started in inactive mode. 1414 This is necessary for interactive multimedia conferences where users 1415 can put other users on hold. No media is sent over an inactive media 1416 stream. Note that an RTP-based system MUST still send RTCP (if RTCP 1417 is used), even if started inactive. 1419 6.8. orient (orientation) 1421 Name: orient 1423 Value: orient-value 1425 Usage Level: media 1427 Charset Dependent: no 1429 Syntax: 1431 orient-value = portrait / landscape / seascape 1432 portrait = %s"portrait" 1433 landscape = %s"landscape" 1434 seascape = %s"seascape" 1435 ; NOTE: These names are case-sensitive. 1437 Example: 1439 a=orient:portrait 1441 Normally this is only used for a whiteboard or presentation tool. It 1442 specifies the orientation of the workspace on the screen. Permitted 1443 values are "portrait", "landscape", and "seascape" (upside-down 1444 landscape). 1446 6.9. type (conference type) 1448 Name: type 1450 Value: type-value 1452 Usage Level: session 1454 Charset Dependent: no 1455 Syntax: 1457 type-value = conference-type 1458 conference-type = broadcast / meeting / moderated / test / 1459 H332 1460 broadcast = %s"broadcast" 1461 meeting = %s"meeting" 1462 moderated = %s"moderated" 1463 test = %s"test" 1464 H332 = %s"H332" 1465 ; NOTE: These names are case-sensitive. 1467 Example: 1469 a=type:moderated 1471 This specifies the type of the multimedia conference. Suggested 1472 values are "broadcast", "meeting", "moderated", "test", and "H332". 1473 "recvonly" should be the default for "type:broadcast" sessions, 1474 "type:meeting" should imply "sendrecv", and "type:moderated" should 1475 indicate the use of a floor control tool and that the media tools are 1476 started so as to mute new sites joining the multimedia conference. 1478 Specifying the attribute "type:H332" indicates that this loosely 1479 coupled session is part of an H.332 session as defined in the ITU 1480 H.332 specification [ITU.H332.1998]. Media tools should be started 1481 "recvonly". 1483 Specifying the attribute "type:test" is suggested as a hint that, 1484 unless explicitly requested otherwise, receivers can safely avoid 1485 displaying this session description to users. 1487 6.10. charset (character set) 1489 Name: charset 1491 Value: charset-value 1493 Usage Level: session 1495 Charset Dependent: no 1497 Syntax: 1499 charset-value = mime-charset 1500 (as defined in [RFC 2978]) 1502 This specifies the character set to be used to display the session 1503 name and information data. By default, the ISO-10646 character set 1504 in UTF-8 encoding is used. If a more compact representation is 1505 required, other character sets may be used. For example, the ISO 1506 8859-1 is specified with the following SDP attribute: 1508 a=charset:ISO-8859-1 1510 The charset specified MUST be one of those registered in the IANA 1511 Character Sets registry (http://www.iana.org/assignments/character- 1512 sets), such as ISO-8859-1. The character set identifier is a US- 1513 ASCII string and MUST be compared against identifiers from the "Name" 1514 or "Preferred MIME Name" field of the registry using a case- 1515 insensitive comparison. If the identifier is not recognised or not 1516 supported, all strings that are affected by it SHOULD be regarded as 1517 octet strings. 1519 Note that a character set specified MUST still prohibit the use of 1520 bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets requiring 1521 the use of these characters MUST define a quoting mechanism that 1522 prevents these bytes from appearing within text fields. 1524 6.11. sdplang (SDP language) 1526 Name: sdplang 1528 Value: sdplang-value 1530 Usage Level: session, media 1532 Charset Dependent: no 1534 Syntax: 1536 sdplang-value = Language-Tag 1537 ; Language-Tag defined in RFC5646 1539 Example: 1541 a=sdplang:fr 1543 Multiple sdplang attributes can be provided either at session or 1544 media level if the session description or media use multiple 1545 languages. 1547 As a session-level attribute, it specifies the language for the 1548 session description (not the language of the media). As a media- 1549 level attribute, it specifies the language for any media-level SDP 1550 information field associated with that media (again not the language 1551 of the media), overriding any sdplang attributes specified at session 1552 level. 1554 In general, sending session descriptions consisting of multiple 1555 languages is discouraged. Instead, multiple descriptions SHOULD be 1556 sent describing the session, one in each language. However, this is 1557 not possible with all transport mechanisms, and so multiple sdplang 1558 attributes are allowed although NOT RECOMMENDED. 1560 The "sdplang" attribute value must be a single [RFC5646] language tag 1561 in US-ASCII. An "sdplang" attribute SHOULD be specified when a 1562 session is distributed with sufficient scope to cross geographic 1563 boundaries, where the language of recipients cannot be assumed, or 1564 where the session is in a different language from the locally assumed 1565 norm. 1567 6.12. lang (language) 1569 Name: lang 1571 Value: lang-value 1573 Usage Level: session, media 1575 Charset Dependent: no 1577 Syntax: 1579 lang-value = Language-Tag 1580 ; Language-Tag defined in RFC5646 1582 Example: 1584 a=lang:de 1586 Multiple lang attributes can be provided either at session or media 1587 level if the session or media has capabilities in more than one 1588 language, in which case the order of the attributes indicates the 1589 order of preference of the various languages in the session or media, 1590 from most preferred to least preferred. 1592 As a session-level attribute, lang specifies a language capability 1593 for the session being described. As a media-level attribute, it 1594 specifies a language capability for that media, overriding any 1595 session-level language(s) specified. 1597 The "lang" attribute value must be a single [RFC5646] language tag in 1598 US-ASCII. A "lang" attribute SHOULD be specified when a session is 1599 of sufficient scope to cross geographic boundaries where the language 1600 of participants cannot be assumed, or where the session has 1601 capabilities in languages different from the locally assumed norm. 1603 The "lang" attribute is supposed to be used for settling the initial 1604 language(s) used in the session. Events during the session may 1605 influence which language(s) are used, and the participants are not 1606 strictly bound to only use the declared languages. 1608 Most real-time use cases start with just one language used, while 1609 other cases involve a range of languages, e.g. an interpreted or 1610 subtitled session. When more than one 'lang' attribute is specified, 1611 the "lang" attribute itself does not provide any information about if 1612 multiple languages are intended to be used during the session, or if 1613 the intention is to only select one language. Other attributes or 1614 the semantics in which the "lang" attributes are used might indicate 1615 such conditions. Without such indications of usage intent, it is 1616 assumed that for a negotiated session one of the declared languages 1617 will be selected and used. 1619 6.13. framerate (frame rate) 1621 Name: framerate 1623 Value: framerate-value 1625 Usage Level: media 1627 Charset Dependent: no 1629 Syntax: 1631 framerate-value = non-zero-int-or-real 1633 Example: 1635 a=framerate:60 1637 This gives the maximum video frame rate in frames/sec. It is 1638 intended as a recommendation for the encoding of video data. Decimal 1639 representations of fractional values are allowed. It is defined only 1640 for video media. 1642 6.14. quality 1644 Name: quality 1646 Value: quality-value 1648 Usage Level: media 1650 Charset Dependent: no 1652 Syntax: 1654 quality-value = zero-based-integer 1656 Example: 1658 a=quality:10 1660 This gives a suggestion for the quality of the encoding as an integer 1661 value. The intention of the quality attribute for video is to 1662 specify a non-default trade-off between frame-rate and still-image 1663 quality. For video, the value is in the range 0 to 10, with the 1664 following suggested meaning: 1666 10 - the best still-image quality the compression scheme 1667 can give. 1668 5 - the default behaviour given no quality suggestion. 1669 0 - the worst still-image quality the codec designer 1670 thinks is still usable. 1672 Editor's note: The usage should be checked with the SIP Forum to see 1673 whether anybody is using this. Otherwise, the recommendation will be 1674 not to use this attribute and the receiver ignores it upon reception. 1676 6.15. fmtp (format parameters) 1678 Name: fmtp 1680 Value: fmtp-value 1682 Usage Level: media 1684 Charset Dependent: no 1685 Syntax: 1687 fmtp-value = fmt SP format-specific-params 1688 format-specific-params = byte-string 1689 ; Notes: 1690 ; - The format parameters are media type parameters and 1691 need to reflect their syntax. 1693 Example: 1695 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1697 This attribute allows parameters that are specific to a particular 1698 format to be conveyed in a way that SDP does not have to understand 1699 them. The format must be one of the formats specified for the media. 1700 Format-specific parameters may be any set of parameters required to 1701 be conveyed by SDP and given unchanged to the media tool that will 1702 use this format. At most one instance of this attribute is allowed 1703 for each format. 1705 7. Security Considerations 1707 SDP is frequently used with the Session Initiation Protocol [RFC3261] 1708 using the offer/answer model [RFC3264] to agree on parameters for 1709 unicast sessions. When used in this manner, the security 1710 considerations of those protocols apply. 1712 SDP is a session description format that describes multimedia 1713 sessions. Entities receiving and acting upon an SDP message SHOULD 1714 be aware that a session description cannot be trusted unless it has 1715 been obtained by an authenticated transport protocol from a known and 1716 trusted source. Many different transport protocols may be used to 1717 distribute session descriptions, and the nature of the authentication 1718 will differ from transport to transport. For some transports, 1719 security features are often not deployed. In case a session 1720 description has not been obtained in a trusted manner, the endpoint 1721 SHOULD exercise care because, among other attacks, the media sessions 1722 received may not be the intended ones, the destination where media is 1723 sent to may not be the expected one, any of the parameters of the 1724 session may be incorrect, or the media security may be compromised. 1725 It is up to the endpoint to make a sensible decision taking into 1726 account the security risks of the application and the user 1727 preferences and may decide to ask the user whether or not to accept 1728 the session. 1730 One transport that can be used to distribute session descriptions is 1731 the SAP. SAP provides both encryption and authentication mechanisms, 1732 but due to the nature of session announcements it is likely that 1733 there are many occasions where the originator of a session 1734 announcement cannot be authenticated because the originator is 1735 previously unknown to the receiver of the announcement and because no 1736 common public key infrastructure is available. 1738 On receiving a session description over an unauthenticated transport 1739 mechanism or from an untrusted party, software parsing the session 1740 should take a few precautions. Session descriptions contain 1741 information required to start software on the receiver's system. 1742 Software that parses a session description MUST NOT be able to start 1743 other software except that which is specifically configured as 1744 appropriate software to participate in multimedia sessions. It is 1745 normally considered inappropriate for software parsing a session 1746 description to start, on a user's system, software that is 1747 appropriate to participate in multimedia sessions, without the user 1748 first being informed that such software will be started and giving 1749 the user's consent. Thus, a session description arriving by session 1750 announcement, email, session invitation, or WWW page MUST NOT deliver 1751 the user into an interactive multimedia session unless the user has 1752 explicitly pre-authorised such action. As it is not always simple to 1753 tell whether or not a session is interactive, applications that are 1754 unsure should assume sessions are interactive. 1756 In this specification, there are no attributes that would allow the 1757 recipient of a session description to be informed to start multimedia 1758 tools in a mode where they default to transmitting. Under some 1759 circumstances it might be appropriate to define such attributes. If 1760 this is done, an application parsing a session description containing 1761 such attributes SHOULD either ignore them or inform the user that 1762 joining this session will result in the automatic transmission of 1763 multimedia data. The default behaviour for an unknown attribute is 1764 to ignore it. 1766 In certain environments, it has become common for intermediary 1767 systems to intercept and analyse session descriptions contained 1768 within other signalling protocols. This is done for a range of 1769 purposes, including but not limited to opening holes in firewalls to 1770 allow media streams to pass, or to mark, prioritize, or block traffic 1771 selectively. In some cases, such intermediary systems may modify the 1772 session description, for example, to have the contents of the session 1773 description match NAT bindings dynamically created. These behaviours 1774 are NOT RECOMMENDED unless the session description is conveyed in 1775 such a manner that allows the intermediary system to conduct proper 1776 checks to establish the authenticity of the session description, and 1777 the authority of its source to establish such communication sessions. 1778 SDP by itself does not include sufficient information to enable these 1779 checks: they depend on the encapsulating protocol (e.g., SIP or 1780 RTSP). 1782 Use of the "k=" line poses a significant security risk, since it 1783 conveys session encryption keys in the clear. SDP MUST NOT be used 1784 to convey key material, unless it can be guaranteed that the channel 1785 over which the SDP is delivered is both private and authenticated. 1786 Moreover, the "k=" line provides no way to indicate or negotiate 1787 cryptographic key algorithms. As it provides for only a single 1788 symmetric key, rather than separate keys for confidentiality and 1789 integrity, its utility is severely limited. The use of the "k=" line 1790 is NOT RECOMMENDED, as discussed in Section 5.12. 1792 8. IANA Considerations 1794 8.1. The "application/sdp" Media Type 1796 One media type registration from [RFC4566] is to be updated, as 1797 defined below. 1799 To: ietf-types@iana.org 1800 Subject: Registration of media type "application/sdp" 1802 Type name: application 1804 Subtype name: sdp 1806 Required parameters: None. 1808 Optional parameters: None. 1810 Encoding considerations: 1811 SDP files are primarily UTF-8 format text. The "a=charset:" 1812 attribute may be used to signal the presence of other character 1813 sets in certain parts of an SDP file (see Section 6 of RFC 1814 XXXX). Arbitrary binary content cannot be directly 1815 represented in SDP. 1817 Security considerations: 1818 See Section 7 of RFC XXXX. 1820 Interoperability considerations: 1821 See RFC XXXX. 1823 Published specification: 1824 See RFC XXXX. 1826 Applications which use this media type: 1827 Voice over IP, video teleconferencing, streaming media, instant 1828 messaging, among others. See also Section 3 of RFC XXXX. 1830 Additional information: 1832 Magic number(s): None. 1833 File extension(s): The extension ".sdp" is commonly used. 1834 Macintosh File Type Code(s): "sdp " 1836 Person & email address to contact for further information: 1837 IETF MMUSIC working group 1839 Intended usage: COMMON 1841 Author/Change controller: 1842 Authors of RFC XXXX 1843 IETF MMUSIC working group delegated from the IESG 1845 8.2. Registration of Parameters 1847 There are seven field names that are registered with IANA. Using the 1848 terminology in the SDP specification Backus-Naur Form (BNF), they are 1849 "media", "proto", "fmt", "att-field", "bwtype", "nettype", and 1850 "addrtype". 1852 The contact address for all parameters registered below is: 1854 IETF MMUSIC working group 1856 8.2.1. Media Types ("media") 1858 The set of media types is intended to be small and SHOULD NOT be 1859 extended except under rare circumstances. The same rules should 1860 apply for media names as for top-level media types, and where 1861 possible the same name should be registered for SDP as for MIME. For 1862 media other than existing top-level media types, a Standards Track 1863 RFC MUST be produced for a new top-level media type to be registered, 1864 and the registration MUST provide good justification why no existing 1865 media name is appropriate (the "Standards Action" policy of 1866 [RFC8126]. 1868 This memo registers the media types "audio", "video", "text", 1869 "application", and "message". 1871 Note: The media types "control" and "data" were listed as valid in an 1872 early version of this specification (RFC 2327); however, their 1873 semantics were never fully specified and they are not widely used. 1874 These media types have been removed in this specification, although 1875 they still remain valid media type capabilities for a SIP user agent 1876 as defined in [RFC3840]. If these media types are considered useful 1877 in the future, a Standards Track RFC MUST be produced to document 1878 their use. Until that is done, applications SHOULD NOT use these 1879 types and SHOULD NOT declare support for them in SIP capabilities 1880 declarations (even though they exist in the registry created by 1881 [RFC3840]). Also note that [RFC6466] defined the "image" media type. 1883 8.2.2. Transport Protocols ("proto") 1885 The "proto" field describes the transport protocol used. This SHOULD 1886 reference a standards-track protocol RFC. This memo registers three 1887 values: "RTP/AVP" is a reference to [RFC3550] used under the RTP 1888 Profile for Audio and Video Conferences with Minimal Control 1889 [RFC3551] running over UDP/IP, "RTP/SAVP" is a reference to the 1890 Secure Real-time Transport Protocol [RFC3711], and "udp" indicates an 1891 unspecified protocol over UDP. 1893 If other RTP profiles are defined in the future, their "proto" name 1894 SHOULD be specified in the same manner. For example, an RTP profile 1895 whose short name is "XYZ" would be denoted by a "proto" field of 1896 "RTP/XYZ". 1898 New transport protocols SHOULD be registered with IANA. 1899 Registrations MUST reference an RFC describing the protocol. Such an 1900 RFC MAY be Experimental or Informational, although it is preferable 1901 that it be Standards Track. Registrations MUST also define the rules 1902 by which their "fmt" namespace is managed (see below). 1904 8.2.3. Media Formats ("fmt") 1906 Each transport protocol, defined by the "proto" field, has an 1907 associated "fmt" namespace that describes the media formats that may 1908 be conveyed by that protocol. Formats cover all the possible 1909 encodings that could be transported in a multimedia session. 1911 RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST 1912 use the payload type number as their "fmt" value. If the payload 1913 type number is dynamically assigned by this session description, an 1914 additional "rtpmap" attribute MUST be included to specify the format 1915 name and parameters as defined by the media type registration for the 1916 payload format. It is RECOMMENDED that other RTP profiles that are 1917 registered (in combination with RTP) as SDP transport protocols 1918 specify the same rules for the "fmt" namespace. 1920 For the "udp" protocol, new formats SHOULD be registered. Use of an 1921 existing media subtype for the format is encouraged. If no media 1922 subtype exists, it is RECOMMENDED that a suitable one be registered 1923 through the IETF process [RFC6838] by production of, or reference to, 1924 a standards-track RFC that defines the transport protocol for the 1925 format. 1927 For other protocols, formats MAY be registered according to the rules 1928 of the associated "proto" specification. 1930 Registrations of new formats MUST specify which transport protocols 1931 they apply to. 1933 8.2.4. Attribute Names ("att-field") 1935 8.2.4.1. New Attributes 1937 Attribute field names ("att-field") MUST be registered with IANA and 1938 documented, because of noticeable issues due to conflicting 1939 attributes under the same name. Unknown attributes in SDP are simply 1940 ignored, but conflicting ones that fragment the protocol are a 1941 serious problem. 1943 New attribute registrations are accepted according to the 1944 "Specification Required" policy of [RFC8126], provided that the 1945 specification includes the following information: 1947 o Contact Name. 1949 o Contact Email Address. 1951 o Attribute Name: The name of the attribute that will appear in 1952 SDP). This MUST conform to the definition of . 1954 o Attribute Syntax: For a value attribute (see clause 5.13), an ABNF 1955 definition of the attribute value syntax (See 1956 Section Section 9) MUST be provided. The syntax MUST follow the 1957 rule form as per Section 2.2 of [RFC5234]. This SHALL define the 1958 allowable values that the attribute might take. It MAY also 1959 define an extension method for the addition of future values. For 1960 a property attribute, the ABNF definition is omitted as the 1961 property attribute takes no values. 1963 o Attribute Semantics: For a value attribute, a semantic description 1964 of the values that the attribute might take MUST be provided. The 1965 usage of a property attribute is described under purpose below. 1967 o Attribute Value: The name of an ABNF syntax rule defining the 1968 syntax of the value. Absence of a rule name indicates that the 1969 attribute takes no values. Enclosing the rule name in "[" and "]" 1970 indicates that a value is optional. 1972 o Usage Level: Usage level(s) of the attribute. One or more of: 1973 session, media, source, dcsa, dcsa(subprotocol). For a definition 1974 of source level attributes, see [RFC5576]. For a definition of 1975 dcsa attributes see: [I-D.ietf-mmusic-data-channel-sdpneg]. 1977 o Charset Dependent: Whether the attribute value is subject to the 1978 charset attribute or not (Yes/No). 1980 o Purpose: An explanation of the purpose and usage of the attribute. 1982 o O/A Procedures: Offer/Answer procedures as explained in [RFC3264]. 1984 o Mux Category: Indication of which multiplexing "category" 1985 [I-D.ietf-mmusic-sdp-mux-attributes] an attribute is associated 1986 with. 1988 o Reference: A reference to the specification defining the 1989 attribute. 1991 The above is the minimum that IANA will accept. Attributes that are 1992 expected to see widespread use and interoperability SHOULD be 1993 documented with a standards-track RFC that specifies the attribute 1994 more precisely. 1996 Submitters of registrations should ensure that the specification is 1997 in the spirit of SDP attributes, most notably that the attribute is 1998 platform independent in the sense that it makes no implicit 1999 assumptions about operating systems and does not name specific pieces 2000 of software in a manner that might inhibit interoperability. 2002 Submitters of registrations should also carefully choose the 2003 attribute usage level. They should not choose only "session" when 2004 the attribute can have different values when media is disaggregated, 2005 i.e., when each m= section has its own IP address on a different 2006 endpoint. In that case the attribute type chosen should be "session, 2007 media". The default rule is that for all new SDP attributes that can 2008 occur both in session and media level, the media level overrides the 2009 session level. When this is not the case for a new SDP attribute, it 2010 MUST be explicitly stated. 2012 IANA has registered the initial set of attribute names ("att-field" 2013 values), with definitions as in Section 6 of this memo (these 2014 definitions replace those in [RFC4566]). 2016 8.2.4.2. Updates to Existing Attributes 2018 Updated attribute registrations are accepted according to the 2019 "Specification Required" policy of [RFC8126], provided that the 2020 specification updating the attribute (for example, by adding a new 2021 value) considers the registration information items from 2022 Section Section 8.2.4.1 according to the following bullets: 2024 o Contact Name: A name MUST be provided. 2026 o Contact Email Address: An email address MUST be provided. 2028 o Attribute Name: MUST be provided and MUST NOT be changed. 2029 Otherwise it is a new attribute. 2031 o Attribute Syntax: The existing rule syntax with the syntax 2032 extensions MUST be provided if there is a change to the syntax. A 2033 revision to an existing attribute usage MAY extend the syntax of 2034 an attribute, but MUST be backward compatible. 2036 o Attribute Semantics: A semantic description of new additional 2037 attributes values or a semantic extension of existing values. 2038 Existing attribute values semantics MUST only be extended in a 2039 backward compatible manner. 2041 o Usage Level: Updates MAY only add additional levels. 2043 o Charset Dependent: MUST NOT be changed. 2045 o Purpose: MAY be extended according to the updated usage. 2047 o O/A Procedures: MAY be updated in a backward compatible manner 2048 and/or it applies to a new usage level only. 2050 o Mux Category: No change unless from TBD to another value. It MAY 2051 also change if 'media' level is being added to the definition of 2052 an attribute that previously did not include it. 2054 o Reference: A new reference MUST be provided. 2056 Items SHOULD be omitted if there is no impact to them as a result of 2057 the attribute update. 2059 8.2.5. Bandwidth Specifiers ("bwtype") 2061 A proliferation of bandwidth specifiers is strongly discouraged. 2063 New bandwidth specifiers ("bwtype" fields) MUST be registered with 2064 IANA. The submission MUST reference a standards-track RFC specifying 2065 the semantics of the bandwidth specifier precisely, and indicating 2066 when it should be used, and why the existing registered bandwidth 2067 specifiers do not suffice. 2069 IANA has registered the bandwidth specifiers "CT" and "AS" with 2070 definitions as in Section 5.8 of this memo (these definitions update 2071 those in [RFC4566]). 2073 8.2.6. Network Types ("nettype") 2075 New network types (the "nettype" field) MUST be registered with IANA 2076 if SDP needs to be used in the context of non-Internet environments. 2077 The registration is subject to the RFC Required - RFC publication 2078 policy of [RFC8126]. Although these are not normally the preserve of 2079 IANA, there may be circumstances when an Internet application needs 2080 to interoperate with a non-Internet application, such as when 2081 gatewaying an Internet telephone call into the Public Switched 2082 Telephone Network (PSTN). The number of network types should be 2083 small and should be rarely extended. A new network type cannot be 2084 registered without registering at least one address type to be used 2085 with that network type. A new network type registration MUST 2086 reference an RFC that gives details of the network type and address 2087 type(s) and specifies how and when they would be used. 2089 IANA has registered the network type "IN" to represent the Internet, 2090 with definition as in Sections 5.2 and 5.7 of this memo (these 2091 definitions update those in [RFC4566]). 2093 8.2.7. Address Types ("addrtype") 2095 New address types ("addrtype") MUST be registered with IANA. The 2096 registration is subject to the RFC Required - RFC publication policy 2097 of [RFC8126]. An address type is only meaningful in the context of a 2098 network type, and any registration of an address type MUST specify a 2099 registered network type or be submitted along with a network type 2100 registration. A new address type registration MUST reference an RFC 2101 giving details of the syntax of the address type. Address types are 2102 not expected to be registered frequently. 2104 IANA has registered the address types "IP4" and "IP6" with 2105 definitions as in Sections 5.2 and 5.7 of this memo (these 2106 definitions update those in [RFC4566]). 2108 8.2.8. Registration Procedure 2110 In the RFC documentation that registers SDP "media", "proto", "fmt", 2111 "bwtype", "nettype", and "addrtype" fields, the authors MUST include 2112 the following information for IANA to place in the appropriate 2113 registry: 2115 o contact name, email address, and telephone number 2117 o name being registered (as it will appear in SDP) 2119 o long-form name in English 2121 o type of name ("media", "proto", "fmt", "bwtype", "nettype", or 2122 "addrtype") 2124 o a one-paragraph explanation of the purpose of the registered name 2126 o a reference to the specification for the registered name (this 2127 will typically be an RFC number) 2129 In the case of a new addrtype registration, the author has to check 2130 whether the new address type is usable with the existing network 2131 types. If yes, the "nettype" registry MUST be updated accordingly. 2133 In the case of a new nettype registration, the author MUST specify 2134 the usable address type(s). 2136 IANA may refer any registration to the IESG for review, and may 2137 request revisions to be made before a registration will be made. 2139 8.3. Encryption Key Access Methods 2141 The IANA previously maintained a table of SDP encryption key access 2142 method ("enckey") names. This table is obsolete, since the "k=" line 2143 is not extensible. New registrations MUST NOT be accepted. 2145 8.4. Reorganization of the nettype Registry 2147 This document adds a new column in the "nettype" registry with the 2148 title "Usable addrtype Values" and updates the "nettype" registry as 2149 follows: 2151 -------------------------------------------------------------------- 2152 |Type | SDP Name | Usable addrtype Values | Reference | 2153 -------------------------------------------------------------------- 2154 |nettype | IN | IP4, IP6 | [RFC4566] | 2155 |nettype | TN | RFC2543 | [RFC2848] | 2156 |nettype | ATM | NSAP, GWID, E164 | [RFC3108] | 2157 |nettype | PSTN | E164 | [RFC7195] | 2158 -------------------------------------------------------------------- 2160 Note that both [RFC7195] and [RFC3108] registered "E164" as an 2161 address type, although [RFC7195] mentions that the "E164" address 2162 type has a different context for ATM and PSTN networks. 2164 8.5. Reorganization of the att-field Registries 2166 This document combines all of the (currently) five "att-field" 2167 registries into one registry called "att-field" registry, and updates 2168 the columns to reflect the name, usage level(s), charset dependency 2169 and reference. As such IANA is requested to create a new combined 2170 registry using the following columns: 2172 Name | Usage Level | Dependent on Charset? | Mux Category | Reference 2174 The "Name" column reflects the attribute name (as it will appear in 2175 the SDP). The "Usage Level" column MUST indicate one or more of the 2176 following: session, media, source, dcsa and dcsa(subprotocol). The 2177 "Dependent on Charset?" column MUST indicate "Yes" or "No" depending 2178 on whether the attribute value is subject to the charset attribute. 2179 The "Mux Category" column MUST indicate one of the following 2180 categories: NORMAL, NOT RECOMMENDED, IDENTICAL, SUM, TRANSPORT, 2181 INHERIT, IDENTICAL-PER-PT, SPECIAL or TBD as defined by 2182 [I-D.ietf-mmusic-sdp-mux-attributes]. Finally, the "Reference" 2183 column indicates the specification(s) where the attribute is defined. 2185 For example, the attribute "setup" which is defined for both session 2186 and media level, will be listed in the new registry as follows: 2188 Name | Usage Level | Dependent on Charset?|Mux Category| Reference | 2189 setup | session,media, | No |IDENTICAL | [RFC4145] | 2190 | dcsa,dcsa(msrp)| | | [RFC6135] | 2191 | | | | [I-D.mmusic 2192 | | | |-msrp-usage- 2193 | | | |data-channel 2194 | | | |] | 2196 9. SDP Grammar 2198 This section provides an Augmented BNF grammar for SDP. ABNF is 2199 defined in [RFC5234] and [RFC7405]. 2201 ; SDP Syntax 2202 session-description = proto-version 2203 origin-field 2204 session-name-field 2205 [information-field] 2206 [uri-field] 2207 *email-field 2208 *phone-field 2209 [connection-field] 2210 *bandwidth-field 2211 1*time-field 2212 [key-field] 2213 *attribute-field 2214 *media-description 2216 proto-version = %s"v" "=" 1*DIGIT CRLF 2217 ;this memo describes version 0 2219 origin-field = %s"o" "=" username SP sess-id SP sess-version SP 2220 nettype SP addrtype SP unicast-address CRLF 2222 session-name-field = %s"s" "=" text CRLF 2224 information-field = %s"i" "=" text CRLF 2226 uri-field = %s"u" "=" uri CRLF 2228 email-field = %s"e" "=" email-address CRLF 2229 phone-field = %s"p" "=" phone-number CRLF 2231 connection-field = %s"c" "=" nettype SP addrtype SP 2232 connection-address CRLF 2233 ;a connection field must be present 2234 ;in every media description or at the 2235 ;session-level 2237 bandwidth-field = %s"b" "=" bwtype ":" bandwidth CRLF 2239 time-field = %s"t" "=" start-time SP stop-time 2240 *(CRLF repeat-fields) CRLF 2241 [zone-adjustments CRLF] 2243 repeat-fields = %s"r" "=" repeat-interval SP typed-time 2244 1*(SP typed-time) 2246 zone-adjustments = %s"z" "=" time SP ["-"] typed-time 2247 *(SP time SP ["-"] typed-time) 2249 key-field = %s"k" "=" key-type CRLF 2251 attribute-field = %s"a" "=" attribute CRLF 2253 media-description = media-field 2254 [information-field] 2255 *connection-field 2256 *bandwidth-field 2257 [key-field] 2258 *attribute-field 2260 media-field = %s"m" "=" media SP port ["/" integer] 2261 SP proto 1*(SP fmt) CRLF 2263 ; sub-rules of 'o=' 2264 username = non-ws-string 2265 ;pretty wide definition, but doesn't 2266 ;include space 2268 sess-id = 1*DIGIT 2269 ;should be unique for this username/host 2271 sess-version = 1*DIGIT 2273 nettype = token 2274 ;typically "IN" 2276 addrtype = token 2277 ;typically "IP4" or "IP6" 2279 ; sub-rules of 'u=' 2280 uri = URI-reference 2281 ; see RFC 3986 2283 ; sub-rules of 'e=', see RFC 5322 for definitions 2284 email-address = address-and-comment / dispname-and-address 2285 / addr-spec 2286 address-and-comment = addr-spec 1*SP "(" 1*email-safe ")" 2287 dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">" 2289 ; sub-rules of 'p=' 2290 phone-number = phone *SP "(" 1*email-safe ")" / 2291 1*email-safe "<" phone ">" / 2292 phone 2294 phone = ["+"] DIGIT 1*(SP / "-" / DIGIT) 2296 ; sub-rules of 'c=' 2297 connection-address = multicast-address / unicast-address 2299 ; sub-rules of 'b=' 2300 bwtype = token 2302 bandwidth = 1*DIGIT 2304 ; sub-rules of 't=' 2305 start-time = time / "0" 2307 stop-time = time / "0" 2309 time = POS-DIGIT 9*DIGIT 2310 ; Decimal representation of NTP time in 2311 ; seconds since 1900. The representation 2312 ; of NTP time is an unbounded length field 2313 ; containing at least 10 digits. Unlike the 2314 ; 64-bit representation used elsewhere, time 2315 ; in SDP does not wrap in the year 2036. 2317 ; sub-rules of 'r=' and 'z=' 2318 repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] 2320 typed-time = 1*DIGIT [fixed-len-time-unit] 2322 fixed-len-time-unit = %s"d" / %s"h" / %s"m" / %s"s" 2323 ; NOTE: These units are case-sensitive. 2325 ; sub-rules of 'k=' 2326 key-type = %s"prompt" / 2327 %s"clear:" text / 2328 %s"base64:" base64 / 2329 %s"uri:" uri 2330 ; NOTE: These names are case-sensitive. 2332 base64 = *base64-unit [base64-pad] 2333 base64-unit = 4base64-char 2334 base64-pad = 2base64-char "==" / 3base64-char "=" 2335 base64-char = ALPHA / DIGIT / "+" / "/" 2337 ; sub-rules of 'a=' 2338 attribute = (att-field ":" att-value) / att-field 2340 att-field = token 2342 att-value = byte-string 2344 ; sub-rules of 'm=' 2345 media = token 2346 ;typically "audio", "video", "text", "image" 2347 ;or "application" 2349 fmt = token 2350 ;typically an RTP payload type for audio 2351 ;and video media 2353 proto = token *("/" token) 2354 ;typically "RTP/AVP" or "udp" 2356 port = 1*DIGIT 2358 ; generic sub-rules: addressing 2359 unicast-address = IP4-address / IP6-address / FQDN / extn-addr 2361 multicast-address = IP4-multicast / IP6-multicast / FQDN 2362 / extn-addr 2364 IP4-multicast = m1 3( "." decimal-uchar ) 2365 "/" ttl [ "/" numaddr ] 2366 ; IP4 multicast addresses may be in the 2367 ; range 224.0.0.0 to 239.255.255.255 2369 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / 2370 ("23" DIGIT ) 2372 IP6-multicast = IP6-address [ "/" numaddr ] 2373 ; IP6 address starting with FF 2375 numaddr = integer 2377 ttl = (POS-DIGIT *2DIGIT) / "0" 2379 FQDN = 4*(alpha-numeric / "-" / ".") 2380 ; fully qualified domain name as specified 2381 ; in RFC 1035 (and updates) 2383 IP4-address = b1 3("." decimal-uchar) 2385 b1 = decimal-uchar 2386 ; less than "224" 2388 IP6-address = 6( h16 ":" ) ls32 2389 / "::" 5( h16 ":" ) ls32 2390 / [ h16 ] "::" 4( h16 ":" ) ls32 2391 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 2392 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 2393 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 2394 / [ *4( h16 ":" ) h16 ] "::" ls32 2395 / [ *5( h16 ":" ) h16 ] "::" h16 2396 / [ *6( h16 ":" ) h16 ] "::" 2398 h16 = 1*4HEXDIG 2400 ls32 = ( h16 ":" h16 ) / IP4-address 2402 ; Generic for other address families 2403 extn-addr = non-ws-string 2405 ; generic sub-rules: datatypes 2406 text = byte-string 2407 ;default is to interpret this as UTF8 text. 2408 ;ISO 8859-1 requires "a=charset:ISO-8859-1" 2409 ;session-level attribute to be used 2411 byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) 2412 ;any byte except NUL, CR, or LF 2414 non-ws-string = 1*(VCHAR/%x80-FF) 2415 ;string of visible characters 2417 token-char = ALPHA / DIGIT 2418 / "!" / "#" / "$" / "%" / "&" 2419 / "'" ; (single quote) 2420 / "*" / "+" / "-" / "." / "^" / "_" 2421 / "`" ; (Grave accent) 2422 / "{" / "|" / "}" / "~" 2424 token = 1*(token-char) 2426 email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF 2427 ;any byte except NUL, CR, LF, or the quoting 2428 ;characters ()<> 2430 integer = POS-DIGIT *DIGIT 2432 zero-based-integer = "0" / integer 2434 non-zero-int-or-real = integer / non-zero-real 2436 non-zero-real = zero-based-integer "." *DIGIT POS-DIGIT 2438 ; generic sub-rules: primitives 2439 alpha-numeric = ALPHA / DIGIT 2441 POS-DIGIT = %x31-39 ; 1 - 9 2443 decimal-uchar = DIGIT 2444 / POS-DIGIT DIGIT 2445 / ("1" 2*(DIGIT)) 2446 / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) 2447 / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) 2449 ; external references: 2450 ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 5234 2451 ; URI-reference: from RFC 3986 2452 ; addr-spec: from RFC 5322 2454 10. Summary of Changes from RFC 4566 2456 The ABNF rule for IP6-address has been corrected. As a result, the 2457 ABNF rule for IP6-multicast has changed, and the (now unused) rules 2458 for hexpart, hexseq, and hex4 have been removed. 2460 IP4 unicast and multicast addresses in the example SDP descriptions 2461 have been revised per RFCs 5735 and 5771. 2463 Text in Section 5.2 has been revised to clarify the use of local 2464 addresses in case of ICE-like SDP extensions. 2466 Normative and informative references have been updated. 2468 The text regarding the session vs. media-level attribute usage has 2469 been clarified. 2471 The case-insensitivity rules from RFC 4855 have been included in this 2472 document. 2474 11. Acknowledgements 2476 Many people in the IETF Multiparty Multimedia Session Control 2477 (MMUSIC) working group have made comments and suggestions 2478 contributing to this document. 2480 12. References 2482 12.1. Normative References 2484 [I-D.ietf-mmusic-data-channel-sdpneg] 2485 Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., 2486 and J. Marcon, "SDP-based Data Channel Negotiation", 2487 draft-ietf-mmusic-data-channel-sdpneg-13 (work in 2488 progress), September 2017. 2490 [I-D.ietf-mmusic-sdp-mux-attributes] 2491 Nandakumar, S., "A Framework for SDP Attributes when 2492 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 2493 (work in progress), December 2016. 2495 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2496 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 2497 . 2499 [RFC1035] Mockapetris, P., "Domain names - implementation and 2500 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2501 November 1987, . 2503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2504 Requirement Levels", BCP 14, RFC 2119, 2505 DOI 10.17487/RFC2119, March 1997, 2506 . 2508 [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration 2509 Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978, 2510 October 2000, . 2512 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2513 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2514 2003, . 2516 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2517 Resource Identifier (URI): Generic Syntax", STD 66, 2518 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2519 . 2521 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2522 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2523 July 2006, . 2525 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2526 Specifications: ABNF", STD 68, RFC 5234, 2527 DOI 10.17487/RFC5234, January 2008, 2528 . 2530 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2531 Media Attributes in the Session Description Protocol 2532 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 2533 . 2535 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 2536 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 2537 September 2009, . 2539 [RFC5890] Klensin, J., "Internationalized Domain Names for 2540 Applications (IDNA): Definitions and Document Framework", 2541 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2542 . 2544 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2545 Writing an IANA Considerations Section in RFCs", BCP 26, 2546 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2547 . 2549 12.2. Informative References 2551 [ITU.H332.1998] 2552 International Telecommunication Union, "H.323 extended for 2553 loosely coupled conferences", ITU Recommendation H.332, 2554 September 1998. 2556 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 2557 Protocol", RFC 2327, DOI 10.17487/RFC2327, April 1998, 2558 . 2560 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 2561 Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, 2562 October 2000, . 2564 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2565 A., Peterson, J., Sparks, R., Handley, M., and E. 2566 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2567 DOI 10.17487/RFC3261, June 2002, 2568 . 2570 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2571 with Session Description Protocol (SDP)", RFC 3264, 2572 DOI 10.17487/RFC3264, June 2002, 2573 . 2575 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2576 Jacobson, "RTP: A Transport Protocol for Real-Time 2577 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2578 July 2003, . 2580 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 2581 Video Conferences with Minimal Control", STD 65, RFC 3551, 2582 DOI 10.17487/RFC3551, July 2003, 2583 . 2585 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 2586 Modifiers for RTP Control Protocol (RTCP) Bandwidth", 2587 RFC 3556, DOI 10.17487/RFC3556, July 2003, 2588 . 2590 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2591 in Session Description Protocol (SDP)", RFC 3605, 2592 DOI 10.17487/RFC3605, October 2003, 2593 . 2595 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2596 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2597 RFC 3711, DOI 10.17487/RFC3711, March 2004, 2598 . 2600 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 2601 "Indicating User Agent Capabilities in the Session 2602 Initiation Protocol (SIP)", RFC 3840, 2603 DOI 10.17487/RFC3840, August 2004, 2604 . 2606 [RFC3890] Westerlund, M., "A Transport Independent Bandwidth 2607 Modifier for the Session Description Protocol (SDP)", 2608 RFC 3890, DOI 10.17487/RFC3890, September 2004, 2609 . 2611 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 2612 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 2613 . 2615 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 2616 (ICE): A Protocol for Network Address Translator (NAT) 2617 Traversal for Offer/Answer Protocols", RFC 5245, 2618 DOI 10.17487/RFC5245, April 2010, 2619 . 2621 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 2622 DOI 10.17487/RFC5322, October 2008, 2623 . 2625 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2626 Protocol (SDP) Grouping Framework", RFC 5888, 2627 DOI 10.17487/RFC5888, June 2010, 2628 . 2630 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 2631 "Network Time Protocol Version 4: Protocol and Algorithms 2632 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 2633 . 2635 [RFC6466] Salgueiro, G., "IANA Registration of the 'image' Media 2636 Type for the Session Description Protocol (SDP)", 2637 RFC 6466, DOI 10.17487/RFC6466, December 2011, 2638 . 2640 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 2641 "TCP Candidates with Interactive Connectivity 2642 Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, 2643 March 2012, . 2645 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2646 Specifications and Registration Procedures", BCP 13, 2647 RFC 6838, DOI 10.17487/RFC6838, January 2013, 2648 . 2650 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 2651 RFC 7405, DOI 10.17487/RFC7405, December 2014, 2652 . 2654 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 2655 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 2656 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 2657 DOI 10.17487/RFC7656, November 2015, 2658 . 2660 [RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 2661 and M. Stiemerling, Ed., "Real-Time Streaming Protocol 2662 Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December 2663 2016, . 2665 Authors' Addresses 2667 Mark Handley 2668 University College London 2669 Department of Computer Science 2670 London WC1E 6BT 2671 UK 2673 EMail: M.Handley@cs.ucl.ac.uk 2675 Colin Perkins 2676 University of Glasgow 2677 School of Computing Science 2678 University of Glasgow 2679 Glasgow G12 8QQ 2680 UK 2682 EMail: csp@csperkins.org 2684 Ali Begen 2685 Networked Media 2686 Konya 2687 Turkey 2689 EMail: ali.begen@networked.media