idnits 2.17.1 draft-ietf-mmusic-rfc4566bis-25.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 (February 19, 2018) is 2250 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: 'RFCXXXX' is mentioned on line 2164, but not defined == Missing Reference: 'RFC2848' is mentioned on line 2165, but not defined == Missing Reference: 'RFC3108' is mentioned on line 2170, but not defined == Missing Reference: 'RFC7195' is mentioned on line 2171, but not defined == Missing Reference: 'RFC4145' is mentioned on line 2199, but not defined == Missing Reference: 'RFC6135' is mentioned on line 2200, but not defined == Unused Reference: 'RFC2978' is defined on line 2522, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'E164' == Outdated reference: A later version (-28) exists of draft-ietf-mmusic-data-channel-sdpneg-16 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-16 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-48 -- Obsolete informational reference (is this intentional?): RFC 2327 (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Begen 3 Internet-Draft Networked Media 4 Obsoletes: 4566 (if approved) P. Kyzivat 5 Intended status: Standards Track 6 Expires: August 23, 2018 C. Perkins 7 University of Glasgow 8 M. Handley 9 UCL 10 February 19, 2018 12 SDP: Session Description Protocol 13 draft-ietf-mmusic-rfc4566bis-25 15 Abstract 17 This memo defines the Session Description Protocol (SDP). SDP is 18 intended for describing multimedia sessions for the purposes of 19 session announcement, session invitation, and other forms of 20 multimedia session initiation. This document obsoletes RFC 4566. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 23, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . . 5 71 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 5 72 3.2. Streaming Media . . . . . . . . . . . . . . . . . . . . . 5 73 3.3. Email and the World Wide Web . . . . . . . . . . . . . . 5 74 3.4. Multicast Session Announcement . . . . . . . . . . . . . 5 75 4. Requirements and Recommendations . . . . . . . . . . . . . . 6 76 4.1. Media and Transport Information . . . . . . . . . . . . . 7 77 4.2. Timing Information . . . . . . . . . . . . . . . . . . . 7 78 4.3. Obtaining Further Information about a Session . . . . . . 8 79 4.4. Categorization . . . . . . . . . . . . . . . . . . . . . 8 80 4.5. Internationalization . . . . . . . . . . . . . . . . . . 8 81 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . . 8 82 5.1. Protocol Version ("v=") . . . . . . . . . . . . . . . . . 11 83 5.2. Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 12 84 5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 13 85 5.4. Session Information ("i=") . . . . . . . . . . . . . . . 13 86 5.5. URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . 14 87 5.6. Email Address and Phone Number ("e=" and "p=") . . . . . 14 88 5.7. Connection Information ("c=") . . . . . . . . . . . . . . 15 89 5.8. Bandwidth Information ("b=") . . . . . . . . . . . . . . 17 90 5.9. Time Active ("t=") . . . . . . . . . . . . . . . . . . . 18 91 5.10. Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . 19 92 5.11. Time Zones ("z=") . . . . . . . . . . . . . . . . . . . . 19 93 5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 20 94 5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 20 95 5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 21 96 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 24 97 6.1. cat (category) . . . . . . . . . . . . . . . . . . . . . 24 98 6.2. keywds (keywords) . . . . . . . . . . . . . . . . . . . . 25 99 6.3. tool . . . . . . . . . . . . . . . . . . . . . . . . . . 25 100 6.4. ptime (packet time) . . . . . . . . . . . . . . . . . . . 26 101 6.5. maxptime (maximum packet time) . . . . . . . . . . . . . 26 102 6.6. rtpmap . . . . . . . . . . . . . . . . . . . . . . . . . 27 103 6.7. Media Direction Attributes . . . . . . . . . . . . . . . 29 104 6.7.1. recvonly (receive-only) . . . . . . . . . . . . . . . 29 105 6.7.2. sendrecv (send-receive) . . . . . . . . . . . . . . . 30 106 6.7.3. sendonly (send-only) . . . . . . . . . . . . . . . . 30 107 6.7.4. inactive . . . . . . . . . . . . . . . . . . . . . . 30 108 6.8. orient (orientation) . . . . . . . . . . . . . . . . . . 31 109 6.9. type (conference type) . . . . . . . . . . . . . . . . . 31 110 6.10. charset (character set) . . . . . . . . . . . . . . . . . 32 111 6.11. sdplang (SDP language) . . . . . . . . . . . . . . . . . 33 112 6.12. lang (language) . . . . . . . . . . . . . . . . . . . . . 34 113 6.13. framerate (frame rate) . . . . . . . . . . . . . . . . . 35 114 6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 36 115 6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 36 116 7. Security Considerations . . . . . . . . . . . . . . . . . . . 37 117 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 118 8.1. The "application/sdp" Media Type . . . . . . . . . . . . 39 119 8.2. Registration of Parameters . . . . . . . . . . . . . . . 40 120 8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 40 121 8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 41 122 8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 41 123 8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 42 124 8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 44 125 8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 45 126 8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 45 127 8.2.8. Registration Procedure . . . . . . . . . . . . . . . 45 128 8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 46 129 8.4. Reorganization of the nettype Registry . . . . . . . . . 46 130 8.5. Reorganization of the att-field Registries . . . . . . . 47 131 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 47 132 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 53 133 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 53 134 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 135 12.1. Normative References . . . . . . . . . . . . . . . . . . 53 136 12.2. Informative References . . . . . . . . . . . . . . . . . 55 137 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 139 1. Introduction 141 When initiating multimedia teleconferences, voice-over-IP calls, 142 streaming video, or other sessions, there is a requirement to convey 143 media details, transport addresses, and other session description 144 metadata to the participants. 146 SDP provides a standard representation for such information, 147 irrespective of how that information is transported. SDP is purely a 148 format for session description -- it does not incorporate a transport 149 protocol, and it is intended to use different transport protocols as 150 appropriate, including the Session Announcement Protocol (SAP) 151 [RFC2974], Session Initiation Protocol (SIP) [RFC3261], Real Time 152 Streaming Protocol (RTSP) [RFC7826], electronic mail using the MIME 153 extensions, and the Hypertext Transport Protocol (HTTP). 155 SDP is intended to be general purpose so that it can be used in a 156 wide range of network environments and applications. However, it is 157 not intended to support negotiation of session content or media 158 encodings: this is viewed as outside the scope of session 159 description. 161 This memo obsoletes [RFC4566]. The changes relative to [RFC4566] are 162 limited to essential corrections, and are outlined in Section 10 of 163 this memo. 165 2. Glossary of Terms 167 The following terms are used in this document and have specific 168 meaning within the context of this document. 170 Session Description: A well-defined format for conveying sufficient 171 information to discover and participate in a multimedia session. 173 Media Description: A media description starts with an "m=" line and 174 is terminated by either the next "m=" line or by the end of the 175 session description. 177 Session-level Section: This refers to the parts that are not media 178 descriptions, whereas the session description refers to the whole 179 body that includes the session-level section and the media 180 description(s). 182 The terms "multimedia conference" and "multimedia session" are used 183 in this document as defined in [RFC7656]. The terms "session" and 184 "multimedia session" are used interchangeably in this document. 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 188 "OPTIONAL" in this document are to be interpreted as described in BCP 189 14 [RFC2119] [RFC8174] when, and only when, they appear in all 190 capitals, as shown here. 192 3. Examples of SDP Usage 194 3.1. Session Initiation 196 The Session Initiation Protocol (SIP) [RFC3261] is an application- 197 layer control protocol for creating, modifying, and terminating 198 sessions such as Internet multimedia conferences, Internet telephone 199 calls, and multimedia distribution. The SIP messages used to create 200 sessions carry session descriptions that allow participants to agree 201 on a set of compatible media types. These session descriptions are 202 commonly formatted using SDP. When used with SIP, the offer/answer 203 model [RFC3264] provides a limited framework for negotiation using 204 SDP. 206 3.2. Streaming Media 208 The Real Time Streaming Protocol (RTSP) [RFC7826], is an application- 209 level protocol for control over the delivery of data with real-time 210 properties. RTSP provides an extensible framework to enable 211 controlled, on-demand delivery of real-time data, such as audio and 212 video. An RTSP client and server negotiate an appropriate set of 213 parameters for media delivery, partially using SDP syntax to describe 214 those parameters. 216 3.3. Email and the World Wide Web 218 Alternative means of conveying session descriptions include 219 electronic mail and the World Wide Web (WWW). For both email and WWW 220 distribution, the media type "application/sdp" is used. This enables 221 the automatic launching of applications for participation in the 222 session from the WWW client or mail reader in a standard manner. 224 Note that announcements of multicast sessions made only via email or 225 the WWW do not have the property that the receiver of a session 226 announcement can necessarily receive the session because the 227 multicast sessions may be restricted in scope, and access to the WWW 228 server or reception of email is possible outside this scope. 230 3.4. Multicast Session Announcement 232 In order to assist the advertisement of multicast multimedia 233 conferences and other multicast sessions, and to communicate the 234 relevant session setup information to prospective participants, a 235 distributed session directory may be used. An instance of such a 236 session directory periodically sends packets containing a description 237 of the session to a well-known multicast group. These advertisements 238 are received by other session directories such that potential remote 239 participants can use the session description to start the tools 240 required to participate in the session. 242 One protocol used to implement such a distributed directory is the 243 SAP [RFC2974]. SDP provides the recommended session description 244 format for such session announcements. 246 4. Requirements and Recommendations 248 The purpose of SDP is to convey information about media streams in 249 multimedia sessions to allow the recipients of a session description 250 to participate in the session. SDP is primarily intended for use in 251 an internetwork, although it is sufficiently general that it can 252 describe multimedia conferences in other network environments. Media 253 streams can be many-to-many. Sessions need not be continually 254 active. 256 Thus far, multicast-based sessions on the Internet have differed from 257 many other forms of conferencing in that anyone receiving the traffic 258 can join the session (unless the session traffic is encrypted). In 259 such an environment, SDP serves two primary purposes. It is a means 260 to communicate the existence of a session, and it is a means to 261 convey sufficient information to enable joining and participating in 262 the session. In a unicast environment, only the latter purpose is 263 likely to be relevant. 265 An SDP description includes the following: 267 o Session name and purpose 269 o Time(s) the session is active 271 o The media comprising the session 273 o Information needed to receive those media (addresses, ports, 274 formats, etc.) 276 As resources necessary to participate in a session may be limited, 277 some additional information may also be desirable: 279 o Information about the bandwidth to be used by the session 281 o Contact information for the person responsible for the session 283 In general, SDP must convey sufficient information to enable 284 applications to join a session (with the possible exception of 285 encryption keys) and to announce the resources to be used to any non- 286 participants that may need to know. (This latter feature is 287 primarily useful when SDP is used with a multicast session 288 announcement protocol.) 290 4.1. Media and Transport Information 292 An SDP description includes the following media information: 294 o The type of media (video, audio, etc.) 296 o The media transport protocol (RTP/UDP/IP, H.320, etc.) 298 o The format of the media (H.261 video, MPEG video, etc.) 300 In addition to media format and transport protocol, SDP conveys 301 address and port details. For an IP multicast session, these 302 comprise: 304 o The multicast group address for media 306 o The transport port for media 308 This address and port is the destination address and destination port 309 of the multicast stream, whether being sent, received, or both. 311 For unicast IP sessions, the following are conveyed: 313 o The remote address for media 315 o The remote transport port for media 317 The semantics of this address and port depend on the media and 318 transport protocol defined. By default, this SHOULD be the remote 319 address and remote port to which data is sent. Some media types may 320 redefine this behaviour, but this is NOT RECOMMENDED since it 321 complicates implementations (including middleboxes that must parse 322 the addresses to open Network Address Translation (NAT) or firewall 323 pinholes). 325 4.2. Timing Information 327 Sessions may be either bounded or unbounded in time. Whether or not 328 they are bounded, they may be only active at specific times. SDP can 329 convey: 331 o An arbitrary list of start and stop times bounding the session 333 o For each bound, repeat times such as "every Wednesday at 10am for 334 one hour" 336 This timing information is globally consistent, irrespective of local 337 time zone or daylight saving time (see Section 5.9). 339 4.3. Obtaining Further Information about a Session 341 A session description could convey enough information to decide 342 whether or not to participate in a session. SDP may include 343 additional pointers in the form of Uniform Resource Identifiers 344 (URIs) for more information about the session. 346 4.4. Categorization 348 When many session descriptions are being distributed by SAP, or any 349 other advertisement mechanism, it may be desirable to filter session 350 announcements that are of interest from those that are not. SDP 351 supports a categorization mechanism for sessions that is capable of 352 being automated (the "a=cat:" attribute; see Section 6). 354 4.5. Internationalization 356 The SDP specification recommends the use of the ISO 10646 character 357 set in the UTF-8 encoding [RFC3629] to allow many different languages 358 to be represented. However, to assist in compact representations, 359 SDP also allows other character sets such as ISO 8859-1 to be used 360 when desired. Internationalization only applies to free-text fields 361 (session name and background information), and not to SDP as a whole. 363 5. SDP Specification 365 An SDP description is denoted by the media type "application/sdp" 366 (See Section 8). 368 An SDP description is entirely textual. SDP field names and 369 attribute names use only the US-ASCII subset of UTF-8, but textual 370 fields and attribute values MAY use the full ISO 10646 character set 371 in UTF-8 encoding, or some other character set defined by the 372 "a=charset:" attribute. Field and attribute values that use the full 373 UTF-8 character set are never directly compared, hence there is no 374 requirement for UTF-8 normalization. The textual form, as opposed to 375 a binary encoding such as ASN.1 or XDR, was chosen to enhance 376 portability, to enable a variety of transports to be used, and to 377 allow flexible, text-based toolkits to be used to generate and 378 process session descriptions. However, since SDP may be used in 379 environments where the maximum permissible size of a session 380 description is limited, the encoding is deliberately compact. Also, 381 since announcements may be transported via very unreliable means or 382 damaged by an intermediate caching server, the encoding was designed 383 with strict order and formatting rules so that most errors would 384 result in malformed session announcements that could be detected 385 easily and discarded. This also allows rapid discarding of encrypted 386 session announcements for which a receiver does not have the correct 387 key. 389 An SDP description consists of a number of lines of text of the form: 391 = 393 where MUST be exactly one case-significant character and 394 is structured text whose format depends on . In 395 general, is either a number of fields delimited by a single 396 space character or a free format string, and is case-significant 397 unless a specific field defines otherwise. Whitespace separators 398 MUST NOT be used on either side of the "=" sign, however, the value 399 can contain a leading whitespace as part of its syntax, i.e., that 400 whitespace is part of the value. 402 An SDP description consists of a session-level section followed by 403 zero or more media descriptions. The session-level section starts 404 with a "v=" line and continues to the first media description (or the 405 end of the whole description, whichever comes first). Each media 406 description starts with an "m=" line and continues to the next media 407 description or the end of the whole session description - whichever 408 comes first. In general, session-level values are the default for 409 all media unless overridden by an equivalent media-level value. 411 Some lines in each description are REQUIRED and some are OPTIONAL, 412 but all MUST appear in exactly the order given here (the fixed order 413 greatly enhances error detection and allows for a simple parser). 414 OPTIONAL items are marked with a "*". 416 Session description 417 v= (protocol version) 418 o= (originator and session identifier) 419 s= (session name) 420 i=* (session information) 421 u=* (URI of description) 422 e=* (email address) 423 p=* (phone number) 424 c=* (connection information -- not required if included in 425 all media descriptions) 426 b=* (zero or more bandwidth information lines) 427 One or more time descriptions ("t=" and "r=" lines; see below) 428 z=* (time zone adjustments) 429 k=* (encryption key) 430 a=* (zero or more session attribute lines) 431 Zero or more media descriptions 433 Time description 434 t= (time the session is active) 435 r=* (zero or more repeat times) 437 Media description, if present 438 m= (media name and transport address) 439 i=* (media title) 440 c=* (connection information -- optional if included at 441 session level) 442 b=* (zero or more bandwidth information lines) 443 k=* (encryption key) 444 a=* (zero or more media attribute lines) 446 The set of type letters is deliberately small and not intended to be 447 extensible -- an SDP parser MUST completely ignore any session 448 description that contains a type letter that it does not understand. 449 The attribute mechanism ("a=" described below) is the primary means 450 for extending SDP and tailoring it to particular applications or 451 media. Some attributes (the ones listed in Section 6 of this memo) 452 have a defined meaning, but others may be added on an application-, 453 media-, or session-specific basis. An SDP parser MUST ignore any 454 attribute it doesn't understand. 456 An SDP description may contain URIs that reference external content 457 in the "u=", "k=", and "a=" lines. These URIs may be dereferenced in 458 some cases, making the session description non-self-contained. 460 The connection ("c=") information in the session-level section 461 applies to all the media descriptions of that session unless 462 overridden by connection information in the media description. For 463 instance, in the example below, each audio media description behaves 464 as if it were given a "c=IN IP4 233.252.0.2". 466 An example SDP description is: 468 v=0 469 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 470 s=SDP Seminar 471 i=A Seminar on the session description protocol 472 u=http://www.example.com/seminars/sdp.pdf 473 e=j.doe@example.com (Jane Doe) 474 c=IN IP4 233.252.0.2 475 t=2873397496 2873404696 476 a=recvonly 477 m=audio 49170 RTP/AVP 0 478 m=audio 49180 RTP/AVP 0 479 m=video 51372 RTP/AVP 99 480 c=IN IP4 233.252.0.1/127 481 a=rtpmap:99 h263-1998/90000 483 Text fields such as the session name and information are octet 484 strings that may contain any octet with the exceptions of 0x00 (Nul), 485 0x0a (ASCII newline), and 0x0d (ASCII carriage return). The sequence 486 CRLF (0x0d0a) is used to end a record, although parsers SHOULD be 487 tolerant and also accept records terminated with a single newline 488 character. If the "a=charset" attribute is not present, these octet 489 strings MUST be interpreted as containing ISO-10646 characters in 490 UTF-8 encoding (the presence of the "a=charset" attribute may force 491 some fields to be interpreted differently). 493 A session description can contain domain names in the "o=", "u=", 494 "e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply 495 with [RFC1034], [RFC1035]. Internationalized domain names (IDNs) 496 MUST be represented using the ASCII Compatible Encoding (ACE) form 497 defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or 498 any other encoding (this requirement is for compatibility with 499 [RFC2327] and other early SDP-related standards, which predate the 500 development of internationalized domain names). 502 5.1. Protocol Version ("v=") 504 v=0 506 The "v=" line gives the version of the Session Description Protocol. 507 This memo defines version 0. There is no minor version number. 509 5.2. Origin ("o=") 511 o= 512 514 The "o=" line gives the originator of the session (her username and 515 the address of the user's host) plus a session identifier and version 516 number: 518 is the user's login on the originating host, or it is "-" 519 if the originating host does not support the concept of user IDs. 520 The MUST NOT contain spaces. 522 is a numeric string such that the tuple of , 523 , , , and forms a 524 globally unique identifier for the session. The method of allocation is up to the creating tool, but it has been 526 suggested that a Network Time Protocol (NTP) format timestamp be 527 used to ensure uniqueness [RFC5905]. 529 is a version number for this session description. 530 Its usage is up to the creating tool, so long as is 531 increased when a modification is made to the session data. Again, 532 it is RECOMMENDED that an NTP format timestamp is used. 534 is a text string giving the type of network. Initially 535 "IN" is defined to have the meaning "Internet", but other values 536 MAY be registered in the future (see Section 8). 538 is a text string giving the type of the address that 539 follows. Initially "IP4" and "IP6" are defined, but other values 540 MAY be registered in the future (see Section 8). 542 is an address of the machine from which the 543 session was created. For an address type of IP4, this is either a 544 fully qualified domain name of the machine or the dotted-decimal 545 representation of an IP version 4 address of the machine. For an 546 address type of IP6, this is either a fully qualified domain name 547 of the machine or the compressed textual representation of an IP 548 version 6 address of the machine. For both IP4 and IP6, the fully 549 qualified domain name is the form that SHOULD be given unless this 550 is unavailable, in which case a globally unique address MAY be 551 substituted. Unless an SDP extension for NAT traversal is used 552 (e.g., ICE [RFC5245], ICE TCP [RFC6544]), a local IP address MUST 553 NOT be used in any context where the SDP description might leave 554 the scope in which the address is meaningful (for example, a local 555 address MUST NOT be included in an application-level referral that 556 might leave the scope). 558 In general, the "o=" line serves as a globally unique identifier for 559 this version of the session description, and the sub-fields excepting 560 the version, taken together identify the session irrespective of any 561 modifications. 563 For privacy reasons, it is sometimes desirable to obfuscate the 564 username and IP address of the session originator. If this is a 565 concern, an arbitrary and private MAY be 566 chosen to populate the "o=" line, provided that these are selected in 567 a manner that does not affect the global uniqueness of the field. 569 5.3. Session Name ("s=") 571 s= 573 The "s=" line is the textual session name. There MUST be one and 574 only one "s=" line per session description. The "s=" line MUST NOT 575 be empty and SHOULD contain ISO 10646 characters (but see also the 576 "a=charset" attribute). If a session has no meaningful name, the "s= 577 " line SHOULD be used (i.e., a single space as the session name). 579 5.4. Session Information ("i=") 581 i= 583 The "i=" line provides textual information about the session. There 584 MUST be at most one session-level "i=" line per session description, 585 and at most one "i=" line in each media description. Unless a media 586 level "i= line is provided, the session-level "i= line applies to 587 that media description. If the "a=charset" attribute is present, it 588 specifies the character set used in the "i=" line. If the 589 "a=charset" attribute is not present, the "i=" line MUST contain ISO 590 10646 characters in UTF-8 encoding. 592 At most one "i=" line can be used for each media description. In 593 media definitions, "i=" lines are primarily intended for labelling 594 media streams. As such, they are most likely to be useful when a 595 single session has more than one distinct media stream of the same 596 media type. An example would be two different whiteboards, one for 597 slides and one for feedback and questions. 599 The "i=" line is intended to provide a free-form human-readable 600 description of the session or the purpose of a media stream. It is 601 not suitable for parsing by automata. 603 5.5. URI ("u=") 605 u= 607 A URI is a Uniform Resource Identifier as used by WWW clients 608 [RFC3986]. The URI should be a pointer to additional information 609 about the session. This line is OPTIONAL. No more than one URI line 610 is allowed per session description. 612 5.6. Email Address and Phone Number ("e=" and "p=") 614 e= 615 p= 617 The "e=" and "p=" lines specify contact information for the person 618 responsible for the session. This is not necessarily the same person 619 that created the session description. 621 Inclusion of an email address or phone number is OPTIONAL. 623 If an email address or phone number is present, it MUST be specified 624 before the first media description. More than one email or phone 625 line can be given for a session description. 627 Phone numbers SHOULD be given in the form of an international public 628 telecommunication number (see ITU-T Recommendation E.164 [E164]) 629 preceded by a "+". Spaces and hyphens may be used to split up a 630 phone field to aid readability if desired. For example: 632 p=+1 617 555-6011 634 Both email addresses and phone numbers can have an OPTIONAL free text 635 string associated with them, normally giving the name of the person 636 who may be contacted. This MUST be enclosed in parentheses if it is 637 present. For example: 639 e=j.doe@example.com (Jane Doe) 641 The alternative [RFC5322] name quoting convention is also allowed for 642 both email addresses and phone numbers. For example: 644 e=Jane Doe 646 The free text string SHOULD be in the ISO-10646 character set with 647 UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if 648 the appropriate session-level "a=charset" attribute is set. 650 5.7. Connection Information ("c=") 652 c= 654 The "c=" line contains connection data. 656 A session description MUST contain either at least one "c=" line in 657 each media description or a single "c=" line at the session level. 658 It MAY contain a single session-level "c=" line and additional "c=" 659 line(s) per media description, in which case the per-media values 660 override the session-level settings for the respective media. 662 The first sub-field ("") is the network type, which is a 663 text string giving the type of network. Initially, "IN" is defined 664 to have the meaning "Internet", but other values MAY be registered in 665 the future (see Section 8). 667 The second sub-field ("") is the address type. This allows 668 SDP to be used for sessions that are not IP based. This memo only 669 defines IP4 and IP6, but other values MAY be registered in the future 670 (see Section 8). 672 The third sub-field ("") is the connection 673 address. Additional sub-fields MAY be added after the connection 674 address depending on the value of the field. 676 When the is IP4 and IP6, the connection address is defined 677 as follows: 679 o If the session is multicast, the connection address will be an IP 680 multicast group address. If the session is not multicast, then 681 the connection address contains the unicast IP address of the 682 expected data source, data relay or data sink as determined by 683 additional attribute fields. It is not expected that unicast 684 addresses will be given in a session description that is 685 communicated by a multicast announcement, though this is not 686 prohibited. 688 o Sessions using an IP4 multicast connection address MUST also have 689 a time to live (TTL) value present in addition to the multicast 690 address. The TTL and the address together define the scope with 691 which multicast packets sent in this session will be sent. TTL 692 values MUST be in the range 0-255. Although the TTL MUST be 693 specified, its use to scope multicast traffic is deprecated; 694 applications SHOULD use an administratively scoped address 695 instead. 697 The TTL for the session is appended to the address using a slash as a 698 separator. An example is: 700 c=IN IP4 233.252.0.1/127 702 IP6 multicast does not use TTL scoping, and hence the TTL value MUST 703 NOT be present for IP6 multicast. It is expected that IP6 scoped 704 addresses will be used to limit the scope of multimedia conferences. 706 Hierarchical or layered encoding schemes are data streams where the 707 encoding from a single media source is split into a number of layers. 708 The receiver can choose the desired quality (and hence bandwidth) by 709 only subscribing to a subset of these layers. Such layered encodings 710 are normally transmitted in multiple multicast groups to allow 711 multicast pruning. This technique keeps unwanted traffic from sites 712 only requiring certain levels of the hierarchy. For applications 713 requiring multiple multicast groups, we allow the following notation 714 to be used for the connection address: 716 [/]/ 718 If the number of addresses is not given, it is assumed to be one. 719 Multicast addresses so assigned are contiguously allocated above the 720 base address, so that, for example: 722 c=IN IP4 233.252.0.1/127/3 724 would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3 725 are to be used with a TTL of 127. This is semantically identical to 726 including multiple "c=" lines in a media description: 728 c=IN IP4 233.252.0.1/127 729 c=IN IP4 233.252.0.2/127 730 c=IN IP4 233.252.0.3/127 732 Similarly, an IP6 example would be: 734 c=IN IP6 FF15::101/3 736 which is semantically equivalent to: 738 c=IN IP6 FF15::101 739 c=IN IP6 FF15::102 740 c=IN IP6 FF15::103 742 (remembering that the TTL field is not present in IP6 multicast). 744 Multiple addresses or "c=" lines MAY be specified on a per media 745 description basis only if they provide multicast addresses for 746 different layers in a hierarchical or layered encoding scheme. They 747 MUST NOT be specified for a session-level "c=" line. 749 The slash notation for multiple addresses described above MUST NOT be 750 used for IP unicast addresses. 752 5.8. Bandwidth Information ("b=") 754 b=: 756 This OPTIONAL line denotes the proposed bandwidth to be used by the 757 session or media description. The is an alphanumeric 758 modifier giving the meaning of the figure. Two values 759 are defined in this specification, but other values MAY be registered 760 in the future (see Section 8 and [RFC3556], [RFC3890]): 762 CT If the bandwidth of a session is different from the bandwidth 763 implicit from the scope, a "b=CT:..." line SHOULD be supplied for 764 the session giving the proposed upper limit to the bandwidth used 765 (the "conference total" bandwidth). Similarly, if the bandwidth 766 of bundled media streams in an m line is different from the 767 implicit value from the scope, a "b=CT:..." line SHOULD be 768 supplied in the media level. The primary purpose of this is to 769 give an approximate idea as to whether two or more sessions (or 770 bundled media streams) can coexist simultaneously. Note that CT 771 gives a total bandwidth figure for all the media at all endpoints. 773 AS The bandwidth is interpreted to be application specific (it will 774 be the application's concept of maximum bandwidth). Normally, 775 this will coincide with what is set on the application's "maximum 776 bandwidth" control if applicable. For RTP-based applications, AS 777 gives the RTP "session bandwidth" as defined in Section 6.2 of 778 [RFC3550]. Note that AS gives a bandwidth figure for a single 779 media at a single endpoint, although there may be many endpoints 780 sending simultaneously. 782 A prefix "X-" is defined for names. This is intended for 783 experimental purposes only. For example: 785 b=X-YZ:128 787 Use of the "X-" prefix is NOT RECOMMENDED: instead new names 788 SHOULD be registered with IANA in the standard namespace. SDP 789 parsers MUST ignore bandwidth fields with unknown names. 790 The names MUST be alphanumeric and, although no length limit 791 is given, it is recommended that they be short. 793 The is interpreted as kilobits per second by default. 794 The definition of a new modifier MAY specify that the 795 bandwidth is to be interpreted in some alternative unit (the "CT" and 796 "AS" modifiers defined in this memo use the default units). 798 5.9. Time Active ("t=") 800 t= 802 The "t=" lines specify the start and stop times for a session. 803 Multiple "t=" lines MAY be used if a session is active at multiple 804 irregularly spaced times; each additional "t=" line specifies an 805 additional period of time for which the session will be active. If 806 the session is active at regular repeat times, an "r=" line (see 807 below) should be used in addition to, and following, a "t=" line -- 808 in which case the "t=" line specifies the start and stop times of the 809 entire repeat sequence. 811 The first and second sub-fields give the start and stop times, 812 respectively, for the session. These values are the decimal 813 representation of Network Time Protocol (NTP) time values in seconds 814 since 1900 [RFC5905]. To convert these values to UNIX time, subtract 815 decimal 2208988800. 817 NTP timestamps are elsewhere represented by 64-bit values, which wrap 818 sometime in the year 2036. Since SDP uses an arbitrary length 819 decimal representation, this should not cause an issue (SDP 820 timestamps MUST continue counting seconds since 1900 - NTP will use 821 the value modulo the 64-bit limit). 823 If the is set to zero, then the session is not bounded, 824 though it will not become active until after the . If 825 the is also zero, the session is regarded as permanent. 827 User interfaces SHOULD strongly discourage the creation of unbounded 828 and permanent sessions as they give no information about when the 829 session is actually going to terminate, and so make scheduling 830 difficult. 832 The general assumption may be made, when displaying unbounded 833 sessions that have not timed out to the user, that an unbounded 834 session will only be active until half an hour from the current time 835 or the session start time, whichever is the later. If behaviour 836 other than this is required, an end-time SHOULD be given and modified 837 as appropriate when new information becomes available about when the 838 session should really end. 840 Permanent sessions may be shown to the user as never being active 841 unless there are associated repeat times that state precisely when 842 the session will be active. 844 5.10. Repeat Times ("r=") 846 r= 848 An "r=" line specifies repeat times for a session. For example, if a 849 session is active at 10am on Monday and 11am on Tuesday for one hour 850 each week for three months, then the in the 851 corresponding "t=" line would be the NTP representation of 10am on 852 the first Monday, the would be 1 week, the would be 1 hour, and the offsets would be zero and 25 854 hours. The corresponding "t=" line stop time would be the NTP 855 representation of the end of the last session three months later. By 856 default, all fields are in seconds, so the "r=" and "t=" lines might 857 be the following: 859 t=3034423619 3042462419 860 r=604800 3600 0 90000 862 To make the description more compact, times may also be given in 863 units of days, hours, or minutes. The syntax for these is a number 864 immediately followed by a single case-sensitive character. 865 Fractional units are not allowed -- a smaller unit should be used 866 instead. The following unit specification characters are allowed: 868 d - days (86400 seconds) 869 h - hours (3600 seconds) 870 m - minutes (60 seconds) 871 s - seconds (allowed for completeness) 873 Thus, the above session announcement could also have been written: 875 r=7d 1h 0 25h 877 Monthly and yearly repeats cannot be directly specified with a single 878 SDP repeat time; instead, separate "t=" lines should be used to 879 explicitly list the session times. 881 5.11. Time Zones ("z=") 883 z= .... 885 To schedule a repeated session that spans a change from daylight 886 saving time to standard time or vice versa, it is necessary to 887 specify offsets from the base time. This is required because 888 different time zones change time at different times of day, different 889 countries change to or from daylight saving time on different dates, 890 and some countries do not have daylight saving time at all. 892 Thus, in order to schedule a session that is at the same time winter 893 and summer, it must be possible to specify unambiguously by whose 894 time zone a session is scheduled. To simplify this task for 895 receivers, we allow the sender to specify the NTP time that a time 896 zone adjustment happens and the offset from the time when the session 897 was first scheduled. The "z=" line allows the sender to specify a 898 list of these adjustment times and offsets from the base time. 900 An example might be the following: 902 z=2882844526 -1h 2898848070 0 904 This specifies that at time 2882844526, the time base by which the 905 session's repeat times are calculated is shifted back by 1 hour, and 906 that at time 2898848070, the session's original time base is 907 restored. Adjustments are always relative to the specified start 908 time -- they are not cumulative. Adjustments apply to all "t=" and 909 "r=" lines in a session description. 911 If a session is likely to last several years, it is expected that the 912 session description will be modified periodically rather than 913 transmit several years' worth of adjustments in one session 914 description. 916 5.12. Encryption Keys ("k=") 918 k= 919 k=: 921 The "k=" line is obsolete and MUST NOT be used. It is included in 922 this document for legacy reasons. One MUST NOT include a "k=" line 923 in an SDP, and MUST discard it if it is received in an SDP. 925 5.13. Attributes ("a=") 927 a= 928 a=: 930 Attributes are the primary means for extending SDP. Attributes may 931 be defined to be used as "session-level" attributes, "media-level" 932 attributes, or both. 934 A media description may have any number of attributes ("a=" lines) 935 that are media description specific. These are referred to as 936 "media-level" attributes and add information about the media 937 description. Attribute lines can also be added before the first 938 media description; these "session-level" attributes convey additional 939 information that applies to the session as a whole rather than to 940 individual media descriptions. 942 Attribute lines may be of two forms: 944 o A property attribute is simply of the form "a=". These 945 are binary attributes, and the presence of the attribute conveys 946 that the attribute is a property of the session. An example might 947 be "a=recvonly". 949 o A value attribute is of the form "a=:". For 950 example, a whiteboard could have the value attribute 951 "a=orient:landscape" 953 Attribute interpretation depends on the media tool being invoked. 954 Thus receivers of session descriptions should be configurable in 955 their interpretation of session descriptions in general and of 956 attributes in particular. 958 Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. 960 Attribute values are octet strings, and MAY use any octet value 961 except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute 962 values are to be interpreted as in ISO-10646 character set with UTF-8 963 encoding. Unlike other text fields, attribute values are NOT 964 normally affected by the "charset" attribute as this would make 965 comparisons against known values problematic. However, when an 966 attribute is defined, it can be defined to be charset dependent, in 967 which case its value should be interpreted in the session charset 968 rather than in ISO-10646. 970 Attributes MUST be registered with IANA (see Section 8). If an 971 attribute is received that is not understood, it MUST be ignored by 972 the receiver. 974 5.14. Media Descriptions ("m=") 976 m= ... 978 A session description may contain a number of media descriptions. 979 Each media description starts with an "m=" line (media field) and is 980 terminated by either the next "m=" line or by the end of the session 981 description. A media field has several sub-fields: 983 is the media type. This document defines the values 984 "audio", "video", "text", "application", and "message". This list 985 is extended by other memos and may be further extended by 986 additional memos registering media types in the future (see 987 Section 8). For example, [RFC6466] defined the "image" media 988 type. 990 is the transport port to which the media stream is sent. The 991 meaning of the transport port depends on the network being used as 992 specified in the relevant "c=" line, and on the transport protocol 993 defined in the sub-field of the media field. Other ports 994 used by the media application (such as the RTP Control Protocol 995 (RTCP) port [RFC3550]) MAY be derived algorithmically from the 996 base media port or MAY be specified in a separate attribute (for 997 example, "a=rtcp:" as defined in [RFC3605]). 999 If non-contiguous ports are used or if they don't follow the 1000 parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" 1001 attribute MUST be used. Applications that are requested to send 1002 media to a that is odd and where the "a=rtcp:" is present 1003 MUST NOT subtract 1 from the RTP port: that is, they MUST send the 1004 RTP to the port indicated in and send the RTCP to the port 1005 indicated in the "a=rtcp" attribute. 1007 For applications where hierarchically encoded streams are being 1008 sent to a unicast address, it may be necessary to specify multiple 1009 transport ports. This is done using a similar notation to that 1010 used for IP multicast addresses in the "c=" line: 1012 m= / ... 1014 In such a case, the ports used depend on the transport protocol. 1015 For RTP, the default is that only the even-numbered ports are used 1016 for data with the corresponding one-higher odd ports used for the 1017 RTCP belonging to the RTP session, and the 1018 denoting the number of RTP sessions. For example: 1020 m=video 49170/2 RTP/AVP 31 1022 would specify that ports 49170 and 49171 form one RTP/RTCP pair 1023 and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the 1024 transport protocol and 31 is the format (see below). If non- 1025 contiguous ports are required, they must be signalled using a 1026 separate attribute (for example, "a=rtcp:" as defined in 1027 [RFC3605]). 1029 If multiple addresses are specified in the "c=" line and multiple 1030 ports are specified in the "m=" line, a one-to-one mapping from 1031 port to the corresponding address is implied. For example: 1033 c=IN IP4 233.252.0.1/127/2 1034 m=video 49170/2 RTP/AVP 31 1036 would imply that address 233.252.0.1 is used with ports 49170 and 1037 49171, and address 233.252.0.2 is used with ports 49172 and 49173. 1039 This document provides no semantics for using multiple "m=" lines 1040 using the same transport address. This implies that, unlike 1041 limited past practice, there is no implicit grouping defined by 1042 such means and an explicit grouping framework (for example, 1043 [RFC5888]) should instead be used to express the intended 1044 semantics. Such semantics may alo be added as extensions. For 1045 instance, see [I-D.ietf-mmusic-sdp-bundle-negotiation]. 1047 is the transport protocol. The meaning of the transport 1048 protocol is dependent on the address type field in the relevant 1049 "c=" line. Thus a "c=" field of IP4 indicates that the transport 1050 protocol runs over IP4. The following transport protocols are 1051 defined, but may be extended through registration of new protocols 1052 with IANA (see Section 8): 1054 * udp: denotes an unspecified protocol running over UDP. 1056 * RTP/AVP: denotes RTP [RFC3550] used under the RTP Profile for 1057 Audio and Video Conferences with Minimal Control [RFC3551] 1058 running over UDP. 1060 * RTP/SAVP: denotes the Secure Real-time Transport Protocol 1061 [RFC3711] running over UDP. 1063 The main reason to specify the transport protocol in addition to 1064 the media format is that the same standard media formats may be 1065 carried over different transport protocols even when the network 1066 protocol is the same -- a historical example is VAT (MBone's 1067 popular multimedia audio tool) Pulse Code Modulation (PCM) audio 1068 and RTP PCM audio; another might be TCP/RTP PCM audio. In 1069 addition, relays and monitoring tools that are transport-protocol- 1070 specific but format-independent are possible. 1072 is a media format description. The fourth and any subsequent 1073 sub-fields describe the format of the media. The interpretation 1074 of the media format depends on the value of the sub-field. 1076 If the sub-field is "RTP/AVP" or "RTP/SAVP" the sub- 1077 fields contain RTP payload type numbers. When a list of payload 1078 type numbers is given, this implies that all of these payload 1079 formats MAY be used in the session, but the first of these formats 1080 SHOULD be used as the default format for the session. For dynamic 1081 payload type assignments the "a=rtpmap:" attribute (see Section 6) 1082 SHOULD be used to map from an RTP payload type number to a media 1083 encoding name that identifies the payload format. The "a=fmtp:" 1084 attribute MAY be used to specify format parameters (see 1085 Section 6). 1087 If the sub-field is "udp" the sub-fields MUST 1088 reference a media type describing the format under the "audio", 1089 "video", "text", "application", or "message" top-level media 1090 types. The media type registration SHOULD define the packet 1091 format for use with UDP transport. 1093 For media using other transport protocols, the field is 1094 protocol specific. Rules for interpretation of the sub- 1095 field MUST be defined when registering new protocols (see 1096 Section 8.2.2). 1098 Section 3 of [RFC4855] states that the payload format (encoding) 1099 names defined in the RTP Profile are commonly shown in upper case, 1100 while media subtype names are commonly shown in lower case. It 1101 also states that both of these names are case-insensitive in both 1102 places, similar to parameter names which are case-insensitive both 1103 in media type strings and in the default mapping to the SDP a=fmtp 1104 attribute. 1106 6. SDP Attributes 1108 The following attributes are defined. Since application writers may 1109 add new attributes as they are required, this list is not exhaustive. 1110 Registration procedures for new attributes are defined in 1111 Section 8.2.4. Syntax is provided using ABNF [RFC7405] with some of 1112 the rules defined further in Section 9. 1114 6.1. cat (category) 1116 Name: cat 1118 Value: cat-value 1120 Usage Level: session 1122 Charset Dependent: no 1123 Syntax: 1125 cat-value = category 1126 category = non-ws-string 1128 Example: 1130 a=cat:foo.bar 1132 This attribute gives the dot-separated hierarchical category of the 1133 session. This is to enable a receiver to filter unwanted sessions by 1134 category. There is no central registry of categories. This 1135 attribute is obsoleted. 1137 6.2. keywds (keywords) 1139 Name: keywds 1141 Value: keywds-value 1143 Usage Level: session 1145 Charset Dependent: yes 1147 Syntax: 1149 keywds-value = keywords 1150 keywords = text 1152 Example: 1154 a=keywds:SDP session description protocol 1156 Like the cat attribute, this is to assist identifying wanted sessions 1157 at the receiver. This allows a receiver to select interesting 1158 sessions based on keywords describing the purpose of the session; 1159 there is no central registry of keywords. Its value should be 1160 interpreted in the charset specified for the session description if 1161 one is specified, or by default in ISO 10646/UTF-8. This attribute 1162 is obsoleted. 1164 6.3. tool 1166 Name: tool 1168 Value: tool-value 1170 Usage Level: session 1171 Charset Dependent: no 1173 Syntax: 1175 tool-value = tool-name-and-version 1176 tool-name-and-version = text 1178 Example: 1180 a=tool:foobar V3.2 1182 This gives the name and version number of the tool used to create the 1183 session description. 1185 6.4. ptime (packet time) 1187 Name: ptime 1189 Value: ptime-value 1191 Usage Level: media 1193 Charset Dependent: no 1195 Syntax: 1197 ptime-value = non-zero-int-or-real 1199 Example: 1201 a=ptime:20 1203 This gives the length of time in milliseconds represented by the 1204 media in a packet. This is probably only meaningful for audio data, 1205 but may be used with other media types if it makes sense. It should 1206 not be necessary to know ptime to decode RTP or vat audio, and it is 1207 intended as a recommendation for the encoding/packetization of audio. 1209 6.5. maxptime (maximum packet time) 1211 Name: maxptime 1213 Value: maxptime-value 1215 Usage Level: media 1217 Charset Dependent: no 1218 Syntax: 1220 maxptime-value = non-zero-int-or-real 1222 Example: 1224 a=maxptime:20 1226 This gives the maximum amount of media that can be encapsulated in 1227 each packet, expressed as time in milliseconds. The time SHALL be 1228 calculated as the sum of the time the media present in the packet 1229 represents. For frame-based codecs, the time SHOULD be an integer 1230 multiple of the frame size. This attribute is probably only 1231 meaningful for audio data, but may be used with other media types if 1232 it makes sense. Note that this attribute was introduced after 1233 [RFC2327], and non-updated implementations will ignore this 1234 attribute. 1236 6.6. rtpmap 1238 Name: rtpmap 1240 Value: rtpmap-value 1242 Usage Level: media 1244 Charset Dependent: no 1246 Syntax: 1248 rtpmap-value = payload-type SP encoding-name 1249 "/" clock-rate [ "/" encoding-params ] 1250 payload-type = zero-based-integer 1251 encoding-name = token 1252 clock-rate = integer 1253 encoding-params = channels 1254 channels = integer 1256 This attribute maps from an RTP payload type number (as used in an 1257 "m=" line) to an encoding name denoting the payload format to be 1258 used. It also provides information on the clock rate and encoding 1259 parameters. Note that the payload type number is indicated in a 1260 7-bit field, limiting the values to incusively between 0 and 127. 1262 Although an RTP profile can make static assignments of payload type 1263 numbers to payload formats, it is more common for that assignment to 1264 be done dynamically using "a=rtpmap:" attributes. As an example of a 1265 static payload type, consider u-law PCM coded single-channel audio 1266 sampled at 8 kHz. This is completely defined in the RTP Audio/Video 1267 profile as payload type 0, so there is no need for an "a=rtpmap:" 1268 attribute, and the media for such a stream sent to UDP port 49232 can 1269 be specified as: 1271 m=audio 49232 RTP/AVP 0 1273 An example of a dynamic payload type is 16-bit linear encoded stereo 1274 audio sampled at 16 kHz. If we wish to use the dynamic RTP/AVP 1275 payload type 98 for this stream, additional information is required 1276 to decode it: 1278 m=audio 49232 RTP/AVP 98 1279 a=rtpmap:98 L16/16000/2 1281 Up to one rtpmap attribute can be defined for each media format 1282 specified. Thus, we might have the following: 1284 m=audio 49230 RTP/AVP 96 97 98 1285 a=rtpmap:96 L8/8000 1286 a=rtpmap:97 L16/8000 1287 a=rtpmap:98 L16/11025/2 1289 RTP profiles that specify the use of dynamic payload types MUST 1290 define the set of valid encoding names and/or a means to register 1291 encoding names if that profile is to be used with SDP. The "RTP/AVP" 1292 and "RTP/SAVP" profiles use media subtypes for encoding names, under 1293 the top-level media type denoted in the "m=" line. In the example 1294 above, the media types are "audio/L8" and "audio/L16". 1296 For audio streams, encoding-params indicates the number of audio 1297 channels. This parameter is OPTIONAL and may be omitted if the 1298 number of channels is one, provided that no additional parameters are 1299 needed. 1301 For video streams, no encoding parameters are currently specified. 1303 Additional encoding parameters MAY be defined in the future, but 1304 codec-specific parameters SHOULD NOT be added. Parameters added to 1305 an "a=rtpmap:" attribute SHOULD only be those required for a session 1306 directory to make the choice of appropriate media to participate in a 1307 session. Codec-specific parameters should be added in other 1308 attributes (for example, "a=fmtp:"). 1310 Note: RTP audio formats typically do not include information about 1311 the number of samples per packet. If a non-default (as defined in 1312 the RTP Audio/Video Profile [RFC3551]) packetization is required, the 1313 "ptime" attribute is used as given above. 1315 6.7. Media Direction Attributes 1317 At most one of recvonly/sendrecv/sendonly/inactive MAY appear at 1318 session level, and at most one MAY appear in each media description. 1320 If any one of these appears in a media description then it applies 1321 for that media description. If none appear in a media description 1322 then the one from session level, if any, applies to that media 1323 description. 1325 If none of the media direction attributes is present at either 1326 session level or media level, "sendrecv" SHOULD be assumed as the 1327 default for sessions that are not of the multimedia conference type 1328 "broadcast" or "H332" (see below). 1330 Within the following SDP example, the "inactive" attribute applies to 1331 audio media and the "recvonly" attribute applies to video media. 1333 v=0 1334 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 1335 s=SDP Seminar 1336 i=A Seminar on the session description protocol 1337 u=http://www.example.com/seminars/sdp.pdf 1338 e=j.doe@example.com (Jane Doe) 1339 c=IN IP4 233.252.0.1/127 1340 t=2873397496 2873404696 1341 a=inactive 1342 m=audio 49170 RTP/AVP 0 1343 m=video 51372 RTP/AVP 99 1344 a=rtpmap:99 h263-1998/90000 1345 a=recvonly 1347 6.7.1. recvonly (receive-only) 1349 Name: recvonly 1351 Value: 1353 Usage Level: session, media 1355 Charset Dependent: no 1357 Example: 1359 a=recvonly 1361 This specifies that the tools should be started in receive-only mode 1362 where applicable. Note that recvonly applies to the media only, not 1363 to any associated control protocol (e.g., an RTP-based system in 1364 recvonly mode SHOULD still send RTCP packets). 1366 6.7.2. sendrecv (send-receive) 1368 Name: sendrecv 1370 Value: 1372 Usage Level: session, media 1374 Charset Dependent: no 1376 Example: 1378 a=sendrecv 1380 This specifies that the tools should be started in send and receive 1381 mode. This is necessary for interactive multimedia conferences with 1382 tools that default to receive-only mode. 1384 6.7.3. sendonly (send-only) 1386 Name: sendonly 1388 Value: 1390 Usage Level: session, media 1392 Charset Dependent: no 1394 Example: 1396 a=sendonly 1398 This specifies that the tools should be started in send-only mode. 1399 An example may be where a different unicast address is to be used for 1400 a traffic destination than for a traffic source. In such a case, two 1401 media descriptions may be used, one sendonly and one recvonly. Note 1402 that sendonly applies only to the media, and any associated control 1403 protocol (e.g., RTCP) SHOULD still be received and processed as 1404 normal. 1406 6.7.4. inactive 1408 Name: inactive 1410 Value: 1412 Usage Level: session, media 1414 Charset Dependent: no 1416 Example: 1418 a=inactive 1420 This specifies that the tools should be started in inactive mode. 1421 This is necessary for interactive multimedia conferences where users 1422 can put other users on hold. No media is sent over an inactive media 1423 stream. Note that an RTP-based system MUST still send RTCP (if RTCP 1424 is used), even if started inactive. 1426 6.8. orient (orientation) 1428 Name: orient 1430 Value: orient-value 1432 Usage Level: media 1434 Charset Dependent: no 1436 Syntax: 1438 orient-value = portrait / landscape / seascape 1439 portrait = %s"portrait" 1440 landscape = %s"landscape" 1441 seascape = %s"seascape" 1442 ; NOTE: These names are case-sensitive. 1444 Example: 1446 a=orient:portrait 1448 Normally this is only used for a whiteboard or presentation tool. It 1449 specifies the orientation of the workspace on the screen. Permitted 1450 values are "portrait", "landscape", and "seascape" (upside-down 1451 landscape). 1453 6.9. type (conference type) 1455 Name: type 1457 Value: type-value 1459 Usage Level: session 1460 Charset Dependent: no 1462 Syntax: 1464 type-value = conference-type 1465 conference-type = broadcast / meeting / moderated / test / 1466 H332 1467 broadcast = %s"broadcast" 1468 meeting = %s"meeting" 1469 moderated = %s"moderated" 1470 test = %s"test" 1471 H332 = %s"H332" 1472 ; NOTE: These names are case-sensitive. 1474 Example: 1476 a=type:moderated 1478 This specifies the type of the multimedia conference. Suggested 1479 values are "broadcast", "meeting", "moderated", "test", and "H332". 1480 "recvonly" should be the default for "type:broadcast" sessions, 1481 "type:meeting" should imply "sendrecv", and "type:moderated" should 1482 indicate the use of a floor control tool and that the media tools are 1483 started so as to mute new sites joining the multimedia conference. 1485 Specifying the attribute "type:H332" indicates that this loosely 1486 coupled session is part of an H.332 session as defined in the ITU 1487 H.332 specification [ITU.H332.1998]. Media tools should be started 1488 "recvonly". 1490 Specifying the attribute "type:test" is suggested as a hint that, 1491 unless explicitly requested otherwise, receivers can safely avoid 1492 displaying this session description to users. 1494 6.10. charset (character set) 1496 Name: charset 1498 Value: charset-value 1500 Usage Level: session 1502 Charset Dependent: no 1504 Syntax: 1506 charset-value = mime-charset 1507 (as defined in [RFC 2978]) 1509 This specifies the character set to be used to display the session 1510 name and information data. By default, the ISO-10646 character set 1511 in UTF-8 encoding is used. If a more compact representation is 1512 required, other character sets may be used. For example, the ISO 1513 8859-1 is specified with the following SDP attribute: 1515 a=charset:ISO-8859-1 1517 The charset specified MUST be one of those registered in the IANA 1518 Character Sets registry (http://www.iana.org/assignments/character- 1519 sets), such as ISO-8859-1. The character set identifier is a US- 1520 ASCII string and MUST be compared against identifiers from the "Name" 1521 or "Preferred MIME Name" field of the registry using a case- 1522 insensitive comparison. If the identifier is not recognised or not 1523 supported, all strings that are affected by it SHOULD be regarded as 1524 octet strings. 1526 Note that a character set specified MUST still prohibit the use of 1527 bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets requiring 1528 the use of these characters MUST define a quoting mechanism that 1529 prevents these bytes from appearing within text fields. 1531 6.11. sdplang (SDP language) 1533 Name: sdplang 1535 Value: sdplang-value 1537 Usage Level: session, media 1539 Charset Dependent: no 1541 Syntax: 1543 sdplang-value = Language-Tag 1544 ; Language-Tag defined in RFC5646 1546 Example: 1548 a=sdplang:fr 1550 Multiple sdplang attributes can be provided either at session or 1551 media level if the session description or media use multiple 1552 languages. 1554 As a session-level attribute, it specifies the language for the 1555 session description (not the language of the media). As a media- 1556 level attribute, it specifies the language for any media-level SDP 1557 information field associated with that media (again not the language 1558 of the media), overriding any sdplang attributes specified at session 1559 level. 1561 In general, sending session descriptions consisting of multiple 1562 languages is discouraged. Instead, multiple sesssion descriptions 1563 SHOULD be sent describing the session, one in each language. 1564 However, this is not possible with all transport mechanisms, and so 1565 multiple sdplang attributes are allowed although NOT RECOMMENDED. 1567 The "sdplang" attribute value must be a single [RFC5646] language tag 1568 in US-ASCII. An "sdplang" attribute SHOULD be specified when a 1569 session is distributed with sufficient scope to cross geographic 1570 boundaries, where the language of recipients cannot be assumed, or 1571 where the session is in a different language from the locally assumed 1572 norm. 1574 6.12. lang (language) 1576 Name: lang 1578 Value: lang-value 1580 Usage Level: session, media 1582 Charset Dependent: no 1584 Syntax: 1586 lang-value = Language-Tag 1587 ; Language-Tag defined in RFC5646 1589 Example: 1591 a=lang:de 1593 Multiple lang attributes can be provided either at session or media 1594 level if the session or media has capabilities in more than one 1595 language, in which case the order of the attributes indicates the 1596 order of preference of the various languages in the session or media, 1597 from most preferred to least preferred. 1599 As a session-level attribute, lang specifies a language capability 1600 for the session being described. As a media-level attribute, it 1601 specifies a language capability for that media, overriding any 1602 session-level language(s) specified. 1604 The "lang" attribute value must be a single [RFC5646] language tag in 1605 US-ASCII. A "lang" attribute SHOULD be specified when a session is 1606 of sufficient scope to cross geographic boundaries where the language 1607 of participants cannot be assumed, or where the session has 1608 capabilities in languages different from the locally assumed norm. 1610 The "lang" attribute is supposed to be used for setting the initial 1611 language(s) used in the session. Events during the session may 1612 influence which language(s) are used, and the participants are not 1613 strictly bound to only use the declared languages. 1615 Most real-time use cases start with just one language used, while 1616 other cases involve a range of languages, e.g. an interpreted or 1617 subtitled session. When more than one 'lang' attribute is specified, 1618 the "lang" attribute itself does not provide any information about 1619 multiple languages being intended to be used during the session, or 1620 if the intention is to only select one of the languages. If needed, 1621 a new attribute can be defined and used to indicate such intentions. 1622 Without such semantics, it is assumed that for a negotiated session 1623 one of the declared languages will be selected and used. 1625 6.13. framerate (frame rate) 1627 Name: framerate 1629 Value: framerate-value 1631 Usage Level: media 1633 Charset Dependent: no 1635 Syntax: 1637 framerate-value = non-zero-int-or-real 1639 Example: 1641 a=framerate:60 1643 This gives the maximum video frame rate in frames/sec. It is 1644 intended as a recommendation for the encoding of video data. Decimal 1645 representations of fractional values are allowed. It is defined only 1646 for video media. 1648 6.14. quality 1650 Name: quality 1652 Value: quality-value 1654 Usage Level: media 1656 Charset Dependent: no 1658 Syntax: 1660 quality-value = zero-based-integer 1662 Example: 1664 a=quality:10 1666 This gives a suggestion for the quality of the encoding as an integer 1667 value. The intention of the quality attribute for video is to 1668 specify a non-default trade-off between frame-rate and still-image 1669 quality. For video, the value is in the range 0 to 10, with the 1670 following suggested meaning: 1672 10 - the best still-image quality the compression scheme 1673 can give. 1674 5 - the default behaviour given no quality suggestion. 1675 0 - the worst still-image quality the codec designer 1676 thinks is still usable. 1678 6.15. fmtp (format parameters) 1680 Name: fmtp 1682 Value: fmtp-value 1684 Usage Level: media 1686 Charset Dependent: no 1688 Syntax: 1690 fmtp-value = fmt SP format-specific-params 1691 format-specific-params = byte-string 1692 ; Notes: 1693 ; - The format parameters are media type parameters and 1694 need to reflect their syntax. 1696 Example: 1698 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1700 This attribute allows parameters that are specific to a particular 1701 format to be conveyed in a way that SDP does not have to understand 1702 them. The format must be one of the formats specified for the media. 1703 Format-specific parameters may be any set of parameters required to 1704 be conveyed by SDP and given unchanged to the media tool that will 1705 use this format. At most one instance of this attribute is allowed 1706 for each format. 1708 7. Security Considerations 1710 SDP is frequently used with the Session Initiation Protocol [RFC3261] 1711 using the offer/answer model [RFC3264] to agree on parameters for 1712 unicast sessions. When used in this manner, the security 1713 considerations of those protocols apply. 1715 SDP is a session description format that describes multimedia 1716 sessions. Entities receiving and acting upon an SDP message SHOULD 1717 be aware that a session description cannot be trusted unless it has 1718 been obtained by an authenticated and integrity-protected transport 1719 protocol from a known and trusted source. Many different transport 1720 protocols may be used to distribute session descriptions, and the 1721 nature of the authentication and integrity-protection will differ 1722 from transport to transport. For some transports, security features 1723 are often not deployed. In case a session description has not been 1724 obtained in a trusted manner, the endpoint SHOULD exercise care 1725 because, among other attacks, the media sessions received may not be 1726 the intended ones, the destination where media is sent to may not be 1727 the expected one, any of the parameters of the session may be 1728 incorrect, or the media security may be compromised. It is up to the 1729 endpoint to make a sensible decision taking into account the security 1730 risks of the application and the user preferences - the endpoint may 1731 decide to ask the user whether or not to accept the session. 1733 One transport that can be used to distribute session descriptions is 1734 the SAP. SAP provides both encryption and authentication mechanisms, 1735 but due to the nature of session announcements it is likely that 1736 there are many occasions where the originator of a session 1737 announcement cannot be authenticated because the originator is 1738 previously unknown to the receiver of the announcement and because no 1739 common public key infrastructure is available. 1741 On receiving a session description over an unauthenticated transport 1742 mechanism or from an untrusted party, software parsing the session 1743 should take a few precautions. Similar concerns apply if integrity 1744 protection is not in place. Session descriptions contain information 1745 required to start software on the receiver's system. Software that 1746 parses a session description MUST NOT be able to start other software 1747 except that which is specifically configured as appropriate software 1748 to participate in multimedia sessions. It is normally considered 1749 inappropriate for software parsing a session description to start, on 1750 a user's system, software that is appropriate to participate in 1751 multimedia sessions, without the user first being informed that such 1752 software will be started and giving the user's consent. Thus, a 1753 session description arriving by session announcement, email, session 1754 invitation, or WWW page MUST NOT deliver the user into an interactive 1755 multimedia session unless the user has explicitly pre-authorised such 1756 action. As it is not always simple to tell whether or not a session 1757 is interactive, applications that are unsure should assume sessions 1758 are interactive. 1760 In this specification, there are no attributes that would allow the 1761 recipient of a session description to be informed to start multimedia 1762 tools in a mode where they default to transmitting. Under some 1763 circumstances it might be appropriate to define such attributes. If 1764 this is done, an application parsing a session description containing 1765 such attributes SHOULD either ignore them or inform the user that 1766 joining this session will result in the automatic transmission of 1767 multimedia data. The default behaviour for an unknown attribute is 1768 to ignore it. 1770 In certain environments, it has become common for intermediary 1771 systems to intercept and analyse session descriptions contained 1772 within other signalling protocols. This is done for a range of 1773 purposes, including but not limited to opening holes in firewalls to 1774 allow media streams to pass, or to mark, prioritize, or block traffic 1775 selectively. In some cases, such intermediary systems may modify the 1776 session description, for example, to have the contents of the session 1777 description match NAT bindings dynamically created. These behaviours 1778 are NOT RECOMMENDED unless the session description is conveyed in 1779 such a manner that allows the intermediary system to conduct proper 1780 checks to establish the authenticity of the session description, and 1781 the authority of its source to establish such communication sessions. 1782 SDP by itself does not include sufficient information to enable these 1783 checks: they depend on the encapsulating protocol (e.g., SIP or 1784 RTSP). 1786 Use of the "k=" line poses a significant security risk, since it 1787 conveys session encryption keys in the clear. SDP MUST NOT be used 1788 to convey keying material, unless it can be guaranteed that the 1789 channel over which the SDP is delivered is both private and 1790 authenticated. Moreover, the "k=" line provides no way to indicate 1791 or negotiate cryptographic key algorithms. As it provides for only a 1792 single symmetric key, rather than separate keys for confidentiality 1793 and integrity, its utility is severely limited. The "k=" line MUST 1794 NOT be used, as discussed in Section 5.12. 1796 8. IANA Considerations 1798 8.1. The "application/sdp" Media Type 1800 One media type registration from [RFC4566] is to be updated, as 1801 defined below. 1803 To: ietf-types@iana.org 1804 Subject: Registration of media type "application/sdp" 1806 Type name: application 1808 Subtype name: sdp 1810 Required parameters: None. 1812 Optional parameters: None. 1814 Encoding considerations: 1815 SDP files are primarily UTF-8 format text. The "a=charset:" 1816 attribute may be used to signal the presence of other character 1817 sets in certain parts of an SDP file (see Section 6 of RFC 1818 XXXX). Arbitrary binary content cannot be directly 1819 represented in SDP. 1821 Security considerations: 1822 See Section 7 of RFC XXXX. 1824 Interoperability considerations: 1825 See RFC XXXX. 1827 Published specification: 1828 See RFC XXXX. 1830 Applications which use this media type: 1831 Voice over IP, video teleconferencing, streaming media, instant 1832 messaging, among others. See also Section 3 of RFC XXXX. 1834 Fragment identifier considerations: None 1836 Additional information: 1838 Deprecated alias names for this type: N/A 1839 Magic number(s): None. 1841 File extension(s): The extension ".sdp" is commonly used. 1842 Macintosh File Type Code(s): "sdp " 1844 Person & email address to contact for further information: 1845 IETF MMUSIC working group 1847 Intended usage: COMMON 1849 Restrictions on usage: None 1851 Author/Change controller: 1852 Authors of RFC XXXX 1853 IETF MMUSIC working group delegated from the IESG 1855 8.2. Registration of Parameters 1857 There are seven field names that are registered with IANA. Using the 1858 terminology in the SDP specification Augmented Backus-Naur Form 1859 (ABNF), they are "media", "proto", "fmt", "att-field", "bwtype", 1860 "nettype", and "addrtype". 1862 The contact address for all parameters registered below is: 1864 IETF MMUSIC working group 1866 8.2.1. Media Types ("media") 1868 The set of media types is intended to be small and SHOULD NOT be 1869 extended except under rare circumstances. The same rules should 1870 apply for media names as for top-level media types, and where 1871 possible the same name should be registered for SDP as for MIME. For 1872 media other than existing top-level media types, a Standards Track 1873 RFC MUST be produced for a new top-level media type to be registered, 1874 and the registration MUST provide good justification why no existing 1875 media name is appropriate (the "Standards Action" policy of 1876 [RFC8126]). 1878 This memo registers the media types "audio", "video", "text", 1879 "application", and "message". 1881 Note: The media types "control" and "data" were listed as valid in an 1882 early version of this specification (RFC 2327); however, their 1883 semantics were never fully specified and they are not widely used. 1884 These media types have been removed in this specification, although 1885 they still remain valid media type capabilities for a SIP user agent 1886 as defined in [RFC3840]. If these media types are considered useful 1887 in the future, a Standards Track RFC MUST be produced to document 1888 their use. Until that is done, applications SHOULD NOT use these 1889 types and SHOULD NOT declare support for them in SIP capabilities 1890 declarations (even though they exist in the registry created by 1891 [RFC3840]). Also note that [RFC6466] defined the "image" media type. 1893 8.2.2. Transport Protocols ("proto") 1895 The "proto" field describes the transport protocol used. This SHOULD 1896 reference a standards-track protocol RFC. This memo registers three 1897 values: "RTP/AVP" is a reference to [RFC3550] used under the RTP 1898 Profile for Audio and Video Conferences with Minimal Control 1899 [RFC3551] running over UDP/IP, "RTP/SAVP" is a reference to the 1900 Secure Real-time Transport Protocol [RFC3711], and "udp" indicates an 1901 unspecified protocol over UDP. 1903 If other RTP profiles are defined in the future, their "proto" name 1904 SHOULD be specified in the same manner. For example, an RTP profile 1905 whose short name is "XYZ" would be denoted by a "proto" field of 1906 "RTP/XYZ". 1908 New transport protocols SHOULD be registered with IANA. 1909 Registrations MUST reference an RFC describing the protocol. Such an 1910 RFC MAY be Experimental or Informational, although it is preferable 1911 that it be Standards Track. Registrations MUST also define the rules 1912 by which their "fmt" namespace is managed (see below). 1914 8.2.3. Media Formats ("fmt") 1916 Each transport protocol, defined by the "proto" field, has an 1917 associated "fmt" namespace that describes the media formats that may 1918 be conveyed by that protocol. Formats cover all the possible 1919 encodings that could be transported in a multimedia session. 1921 RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST 1922 use the payload type number as their "fmt" value. If the payload 1923 type number is dynamically assigned by this session description, an 1924 additional "rtpmap" attribute MUST be included to specify the format 1925 name and parameters as defined by the media type registration for the 1926 payload format. It is RECOMMENDED that other RTP profiles that are 1927 registered (in combination with RTP) as SDP transport protocols 1928 specify the same rules for the "fmt" namespace. 1930 For the "udp" protocol, new formats SHOULD be registered. Use of an 1931 existing media subtype for the format is encouraged. If no media 1932 subtype exists, it is RECOMMENDED that a suitable one be registered 1933 through the IETF process [RFC6838] by production of, or reference to, 1934 a standards-track RFC that defines the transport protocol for the 1935 format. 1937 For other protocols, formats MAY be registered according to the rules 1938 of the associated "proto" specification. 1940 Registrations of new formats MUST specify which transport protocols 1941 they apply to. 1943 8.2.4. Attribute Names ("att-field") 1945 8.2.4.1. New Attributes 1947 Attribute field names ("att-field") MUST be registered with IANA and 1948 documented, to avoid any issues due to conflicting attribute 1949 definitions under the same name. Unknown attributes in SDP are 1950 simply ignored, but conflicting ones that fragment the protocol are a 1951 serious problem. 1953 New attribute registrations are accepted according to the 1954 "Specification Required" policy of [RFC8126], provided that the 1955 specification includes the following information: 1957 o Contact Name. 1959 o Contact Email Address. 1961 o Attribute Name: The name of the attribute that will appear in 1962 SDP). This MUST conform to the definition of . 1964 o Attribute Syntax: For a value attribute (see clause 5.13), an ABNF 1965 definition of the attribute value syntax (See 1966 Section 9) MUST be provided. The syntax MUST follow the rule form 1967 as per Section 2.2 of [RFC5234] and [RFC7405]. This SHALL define 1968 the allowable values that the attribute might take. It MAY also 1969 define an extension method for the addition of future values. For 1970 a property attribute, the ABNF definition is omitted as the 1971 property attribute takes no values. 1973 o Attribute Semantics: For a value attribute, a semantic description 1974 of the values that the attribute might take MUST be provided. The 1975 usage of a property attribute is described under purpose below. 1977 o Attribute Value: The name of an ABNF syntax rule defining the 1978 syntax of the value. Absence of a rule name indicates that the 1979 attribute takes no values. Enclosing the rule name in "[" and "]" 1980 indicates that a value is optional. 1982 o Usage Level: Usage level(s) of the attribute. One or more of: 1983 session, media, source, dcsa, dcsa(subprotocol). For a definition 1984 of source level attributes, see [RFC5576]. For a definition of 1985 dcsa attributes see: [I-D.ietf-mmusic-data-channel-sdpneg]. 1987 o Charset Dependent: Whether the attribute value is subject to the 1988 charset attribute or not (Yes/No). 1990 o Purpose: An explanation of the purpose and usage of the attribute. 1992 o O/A Procedures: Offer/Answer procedures as explained in [RFC3264]. 1994 o Mux Category: Indication of which multiplexing "category" 1995 [I-D.ietf-mmusic-sdp-mux-attributes] an attribute is associated 1996 with. 1998 o Reference: A reference to the specification defining the 1999 attribute. 2001 The above is the minimum that IANA will accept. Attributes that are 2002 expected to see widespread use and interoperability SHOULD be 2003 documented with a standards-track RFC that specifies the attribute 2004 more precisely. 2006 Submitters of registrations should ensure that the specification is 2007 in the spirit of SDP attributes, most notably that the attribute is 2008 platform independent in the sense that it makes no implicit 2009 assumptions about operating systems and does not name specific pieces 2010 of software in a manner that might inhibit interoperability. 2012 Submitters of registrations should also carefully choose the 2013 attribute usage level. They should not choose only "session" when 2014 the attribute can have different values when media is disaggregated, 2015 i.e., when each m= section has its own IP address on a different 2016 endpoint. In that case the attribute type chosen should be "session, 2017 media" or "media" (depending on desired semantics). The default rule 2018 is that for all new SDP attributes that can occur both in session and 2019 media level, the media level overrides the session level. When this 2020 is not the case for a new SDP attribute, it MUST be explicitly 2021 stated. 2023 IANA has registered the initial set of attribute names ("att-field" 2024 values) with definitions as in Section 6 of this memo (these 2025 definitions replace those in [RFC4566]). 2027 8.2.4.2. Updates to Existing Attributes 2029 Updated attribute registrations are accepted according to the 2030 "Specification Required" policy of [RFC8126], provided that the 2031 specification updating the attribute (for example, by adding a new 2032 value) considers the registration information items from 2033 Section 8.2.4.1 according to the following bullets: 2035 o Contact Name: A name MUST be provided. 2037 o Contact Email Address: An email address MUST be provided. 2039 o Attribute Name: MUST be provided and MUST NOT be changed. 2040 Otherwise it is a new attribute. 2042 o Attribute Syntax: The existing rule syntax with the syntax 2043 extensions MUST be provided if there is a change to the syntax. A 2044 revision to an existing attribute usage MAY extend the syntax of 2045 an attribute, but MUST be backward compatible. 2047 o Attribute Semantics: A semantic description of new additional 2048 attributes values or a semantic extension of existing values. 2049 Existing attribute values semantics MUST only be extended in a 2050 backward compatible manner. 2052 o Usage Level: Updates MAY only add additional levels. 2054 o Charset Dependent: MUST NOT be changed. 2056 o Purpose: MAY be extended according to the updated usage. 2058 o O/A Procedures: MAY be updated in a backward compatible manner 2059 and/or it applies to a new usage level only. 2061 o Mux Category: No change unless from "TBD" to another value (see 2062 [I-D.ietf-mmusic-sdp-mux-attributes]. It MAY also change if 2063 'media' level is being added to the definition of an attribute 2064 that previously did not include it. 2066 o Reference: A new reference MUST be provided. 2068 Items SHOULD be omitted if there is no impact to them as a result of 2069 the attribute update. 2071 8.2.5. Bandwidth Specifiers ("bwtype") 2073 A proliferation of bandwidth specifiers is strongly discouraged. 2075 New bandwidth specifiers ("bwtype" fields) MUST be registered with 2076 IANA. The submission MUST reference a standards-track RFC specifying 2077 the semantics of the bandwidth specifier precisely, and indicating 2078 when it should be used, and why the existing registered bandwidth 2079 specifiers do not suffice. 2081 IANA has registered the bandwidth specifiers "CT" and "AS" with 2082 definitions as in Section 5.8 of this memo (these definitions update 2083 those in [RFC4566]). 2085 8.2.6. Network Types ("nettype") 2087 New network types (the "nettype" field) MUST be registered with IANA 2088 if SDP needs to be used in the context of non-Internet environments. 2089 The registration is subject to the "RFC Required" policy of 2090 [RFC8126]. Although these are not normally the preserve of IANA, 2091 there may be circumstances when an Internet application needs to 2092 interoperate with a non-Internet application, such as when gatewaying 2093 an Internet telephone call into the Public Switched Telephone Network 2094 (PSTN). The number of network types should be small and should be 2095 rarely extended. A new network type cannot be registered without 2096 registering at least one address type to be used with that network 2097 type. A new network type registration MUST reference an RFC that 2098 gives details of the network type and address type(s) and specifies 2099 how and when they would be used. 2101 IANA has registered the network type "IN" to represent the Internet, 2102 with definition as in Sections 5.2 and 5.7 of this memo (these 2103 definitions update those in [RFC4566]). 2105 8.2.7. Address Types ("addrtype") 2107 New address types ("addrtype") MUST be registered with IANA. The 2108 registration is subject to the "RFC Required" policy of [RFC8126]. 2109 An address type is only meaningful in the context of a network type, 2110 and any registration of an address type MUST specify a registered 2111 network type or be submitted along with a network type registration. 2112 A new address type registration MUST reference an RFC giving details 2113 of the syntax of the address type. Address types are not expected to 2114 be registered frequently. 2116 IANA has registered the address types "IP4" and "IP6" with 2117 definitions as in Sections 5.2 and 5.7 of this memo (these 2118 definitions update those in [RFC4566]). 2120 8.2.8. Registration Procedure 2122 In the RFC documentation that registers SDP "media", "proto", "fmt", 2123 "bwtype", "nettype", and "addrtype" fields, the authors MUST include 2124 the following information for IANA to place in the appropriate 2125 registry: 2127 o contact name, email address, and telephone number 2128 o name being registered (as it will appear in SDP) 2130 o long-form name in English 2132 o type of name ("media", "proto", "fmt", "bwtype", "nettype", or 2133 "addrtype") 2135 o a one-paragraph explanation of the purpose of the registered name 2137 o a reference to the specification for the registered name (this 2138 will typically be an RFC number) 2140 In the case of a new addrtype registration, the author has to check 2141 whether the new address type is usable with the existing network 2142 types. If yes, the "nettype" registry MUST be updated accordingly. 2143 In the case of a new nettype registration, the author MUST specify 2144 the usable address type(s). 2146 IANA may refer any registration to the IESG for review, and may 2147 request revisions to be made before a registration will be made. 2149 8.3. Encryption Key Access Methods 2151 The IANA previously maintained a table of SDP encryption key access 2152 method ("enckey") names. This table is obsolete, since the "k=" line 2153 is not extensible. New registrations MUST NOT be accepted. 2155 8.4. Reorganization of the nettype Registry 2157 This document adds a new column in the "nettype" registry with the 2158 title "Usable addrtype Values" and updates the "nettype" registry as 2159 follows: 2161 -------------------------------------------------------------------- 2162 |Type | SDP Name | Usable addrtype Values | Reference | 2163 -------------------------------------------------------------------- 2164 |nettype | IN | IP4, IP6 | [RFCXXXX] | 2165 |nettype | TN | RFC2543 | [RFC2848] | 2166 |nettype | ATM | NSAP, GWID, E164 | [RFC3108] | 2167 |nettype | PSTN | E164 | [RFC7195] | 2168 -------------------------------------------------------------------- 2170 Note that both [RFC7195] and [RFC3108] registered "E164" as an 2171 address type, although [RFC7195] mentions that the "E164" address 2172 type has a different context for ATM and PSTN networks. 2174 8.5. Reorganization of the att-field Registries 2176 This document combines all of the (currently) five "att-field" 2177 registries into one registry called "att-field" registry, and updates 2178 the columns to reflect the name, usage level(s), charset dependency 2179 and reference. As such IANA is requested to create a new combined 2180 registry using the following columns: 2182 Name | Usage Level | Dependent on Charset? | Mux Category | Reference 2184 The "Name" column reflects the attribute name (as it will appear in 2185 the SDP). The "Usage Level" column MUST indicate one or more of the 2186 following: session, media, source, dcsa and dcsa(subprotocol). The 2187 "Dependent on Charset?" column MUST indicate "Yes" or "No" depending 2188 on whether the attribute value is subject to the charset attribute. 2189 The "Mux Category" column MUST indicate one of the following 2190 categories: NORMAL, NOT RECOMMENDED, IDENTICAL, SUM, TRANSPORT, 2191 INHERIT, IDENTICAL-PER-PT, SPECIAL or TBD as defined by 2192 [I-D.ietf-mmusic-sdp-mux-attributes]. Finally, the "Reference" 2193 column indicates the specification(s) where the attribute is defined. 2195 For example, the attribute "setup" which is defined for both session 2196 and media level, will be listed in the new registry as follows: 2198 Name | Usage Level | Dependent on Charset?|Mux Category| Reference | 2199 setup | session,media, | No |IDENTICAL | [RFC4145] | 2200 | dcsa,dcsa(msrp)| | | [RFC6135] | 2201 | | | | [I-D.mmusic 2202 | | | |-msrp-usage- 2203 | | | |data-channel 2204 | | | |] | 2206 9. SDP Grammar 2208 This section provides an Augmented BNF grammar for SDP. ABNF is 2209 defined in [RFC5234] and [RFC7405]. 2211 ; SDP Syntax 2212 session-description = proto-version 2213 origin-field 2214 session-name-field 2215 [information-field] 2216 [uri-field] 2217 *email-field 2218 *phone-field 2219 [connection-field] 2220 *bandwidth-field 2221 1*time-field 2223 [key-field] 2224 *attribute-field 2225 *media-description 2227 proto-version = %s"v" "=" 1*DIGIT CRLF 2228 ;this memo describes version 0 2230 origin-field = %s"o" "=" username SP sess-id SP sess-version SP 2231 nettype SP addrtype SP unicast-address CRLF 2233 session-name-field = %s"s" "=" text CRLF 2235 information-field = %s"i" "=" text CRLF 2237 uri-field = %s"u" "=" uri CRLF 2239 email-field = %s"e" "=" email-address CRLF 2241 phone-field = %s"p" "=" phone-number CRLF 2243 connection-field = %s"c" "=" nettype SP addrtype SP 2244 connection-address CRLF 2245 ;a connection field must be present 2246 ;in every media description or at the 2247 ;session-level 2249 bandwidth-field = %s"b" "=" bwtype ":" bandwidth CRLF 2251 time-field = %s"t" "=" start-time SP stop-time 2252 *(CRLF repeat-fields) CRLF 2253 [zone-adjustments CRLF] 2255 repeat-fields = %s"r" "=" repeat-interval SP typed-time 2256 1*(SP typed-time) 2258 zone-adjustments = %s"z" "=" time SP ["-"] typed-time 2259 *(SP time SP ["-"] typed-time) 2261 key-field = %s"k" "=" key-type CRLF 2263 attribute-field = %s"a" "=" attribute CRLF 2265 media-description = media-field 2266 [information-field] 2267 *connection-field 2268 *bandwidth-field 2269 [key-field] 2270 *attribute-field 2272 media-field = %s"m" "=" media SP port ["/" integer] 2273 SP proto 1*(SP fmt) CRLF 2275 ; sub-rules of 'o=' 2276 username = non-ws-string 2277 ;pretty wide definition, but doesn't 2278 ;include space 2280 sess-id = 1*DIGIT 2281 ;should be unique for this username/host 2283 sess-version = 1*DIGIT 2285 nettype = token 2286 ;typically "IN" 2288 addrtype = token 2289 ;typically "IP4" or "IP6" 2291 ; sub-rules of 'u=' 2292 uri = URI-reference 2293 ; see RFC 3986 2295 ; sub-rules of 'e=', see RFC 5322 for definitions 2296 email-address = address-and-comment / dispname-and-address 2297 / addr-spec 2298 address-and-comment = addr-spec 1*SP "(" 1*email-safe ")" 2299 dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">" 2301 ; sub-rules of 'p=' 2302 phone-number = phone *SP "(" 1*email-safe ")" / 2303 1*email-safe "<" phone ">" / 2304 phone 2306 phone = ["+"] DIGIT 1*(SP / "-" / DIGIT) 2308 ; sub-rules of 'c=' 2309 connection-address = multicast-address / unicast-address 2311 ; sub-rules of 'b=' 2312 bwtype = token 2314 bandwidth = 1*DIGIT 2316 ; sub-rules of 't=' 2317 start-time = time / "0" 2319 stop-time = time / "0" 2320 time = POS-DIGIT 9*DIGIT 2321 ; Decimal representation of NTP time in 2322 ; seconds since 1900. The representation 2323 ; of NTP time is an unbounded length field 2324 ; containing at least 10 digits. Unlike the 2325 ; 64-bit representation used elsewhere, time 2326 ; in SDP does not wrap in the year 2036. 2328 ; sub-rules of 'r=' and 'z=' 2329 repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] 2331 typed-time = 1*DIGIT [fixed-len-time-unit] 2333 fixed-len-time-unit = %s"d" / %s"h" / %s"m" / %s"s" 2334 ; NOTE: These units are case-sensitive. 2336 ; sub-rules of 'k=' 2337 key-type = %s"prompt" / 2338 %s"clear:" text / 2339 %s"base64:" base64 / 2340 %s"uri:" uri 2341 ; NOTE: These names are case-sensitive. 2343 base64 = *base64-unit [base64-pad] 2344 base64-unit = 4base64-char 2345 base64-pad = 2base64-char "==" / 3base64-char "=" 2346 base64-char = ALPHA / DIGIT / "+" / "/" 2348 ; sub-rules of 'a=' 2349 attribute = (att-field ":" att-value) / att-field 2351 att-field = token 2353 att-value = byte-string 2355 ; sub-rules of 'm=' 2356 media = token 2357 ;typically "audio", "video", "text", "image" 2358 ;or "application" 2360 fmt = token 2361 ;typically an RTP payload type for audio 2362 ;and video media 2364 proto = token *("/" token) 2365 ;typically "RTP/AVP" or "udp" 2367 port = 1*DIGIT 2368 ; generic sub-rules: addressing 2369 unicast-address = IP4-address / IP6-address / FQDN / extn-addr 2371 multicast-address = IP4-multicast / IP6-multicast / FQDN 2372 / extn-addr 2374 IP4-multicast = m1 3( "." decimal-uchar ) 2375 "/" ttl [ "/" numaddr ] 2376 ; IP4 multicast addresses may be in the 2377 ; range 224.0.0.0 to 239.255.255.255 2379 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / 2380 ("23" DIGIT ) 2382 IP6-multicast = IP6-address [ "/" numaddr ] 2383 ; IP6 address starting with FF 2385 numaddr = integer 2387 ttl = (POS-DIGIT *2DIGIT) / "0" 2389 FQDN = 4*(alpha-numeric / "-" / ".") 2390 ; fully qualified domain name as specified 2391 ; in RFC 1035 (and updates) 2393 IP4-address = b1 3("." decimal-uchar) 2395 b1 = decimal-uchar 2396 ; less than "224" 2398 IP6-address = 6( h16 ":" ) ls32 2399 / "::" 5( h16 ":" ) ls32 2400 / [ h16 ] "::" 4( h16 ":" ) ls32 2401 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 2402 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 2403 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 2404 / [ *4( h16 ":" ) h16 ] "::" ls32 2405 / [ *5( h16 ":" ) h16 ] "::" h16 2406 / [ *6( h16 ":" ) h16 ] "::" 2408 h16 = 1*4HEXDIG 2410 ls32 = ( h16 ":" h16 ) / IP4-address 2412 ; Generic for other address families 2413 extn-addr = non-ws-string 2415 ; generic sub-rules: datatypes 2416 text = byte-string 2417 ;default is to interpret this as UTF8 text. 2418 ;ISO 8859-1 requires "a=charset:ISO-8859-1" 2419 ;session-level attribute to be used 2421 byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) 2422 ;any byte except NUL, CR, or LF 2424 non-ws-string = 1*(VCHAR/%x80-FF) 2425 ;string of visible characters 2427 token-char = ALPHA / DIGIT 2428 / "!" / "#" / "$" / "%" / "&" 2429 / "'" ; (single quote) 2430 / "*" / "+" / "-" / "." / "^" / "_" 2431 / "`" ; (Grave accent) 2432 / "{" / "|" / "}" / "~" 2434 token = 1*(token-char) 2436 email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF 2437 ;any byte except NUL, CR, LF, or the quoting 2438 ;characters ()<> 2440 integer = POS-DIGIT *DIGIT 2442 zero-based-integer = "0" / integer 2444 non-zero-int-or-real = integer / non-zero-real 2446 non-zero-real = zero-based-integer "." *DIGIT POS-DIGIT 2448 ; generic sub-rules: primitives 2449 alpha-numeric = ALPHA / DIGIT 2451 POS-DIGIT = %x31-39 ; 1 - 9 2453 decimal-uchar = DIGIT 2454 / POS-DIGIT DIGIT 2455 / ("1" 2*(DIGIT)) 2456 / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) 2457 / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) 2459 ; external references: 2460 ; ALPHA, DIGIT, CRLF, HEXDIG, SP, VCHAR: from RFC 5234 2461 ; URI-reference: from RFC 3986 2462 ; addr-spec: from RFC 5322 2464 10. Summary of Changes from RFC 4566 2466 The ABNF rule for IP6-address has been corrected. As a result, the 2467 ABNF rule for IP6-multicast has changed, and the (now unused) rules 2468 for hexpart, hexseq, and hex4 have been removed. 2470 IP4 unicast and multicast addresses in the example SDP descriptions 2471 have been revised per RFCs 5735 and 5771. 2473 Text in Section 5.2 has been revised to clarify the use of local 2474 addresses in case of ICE-like SDP extensions. 2476 Normative and informative references have been updated. 2478 The text regarding the session vs. media-level attribute usage has 2479 been clarified. 2481 The case-insensitivity rules from RFC 4855 have been included in this 2482 document. 2484 11. Acknowledgements 2486 Many people in the IETF Multiparty Multimedia Session Control 2487 (MMUSIC) working group have made comments and suggestions 2488 contributing to this document. 2490 12. References 2492 12.1. Normative References 2494 [E164] International Telecommunication Union, "E.164 : The 2495 international public telecommunication numbering plan", 2496 ITU Recommendation E.164, November 2010. 2498 [I-D.ietf-mmusic-data-channel-sdpneg] 2499 Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., 2500 Marcon, J., and R. Even, "SDP-based Data Channel 2501 Negotiation", draft-ietf-mmusic-data-channel-sdpneg-16 2502 (work in progress), December 2017. 2504 [I-D.ietf-mmusic-sdp-mux-attributes] 2505 Nandakumar, S., "A Framework for SDP Attributes when 2506 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 2507 (work in progress), December 2016. 2509 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2510 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 2511 . 2513 [RFC1035] Mockapetris, P., "Domain names - implementation and 2514 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2515 November 1987, . 2517 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2518 Requirement Levels", BCP 14, RFC 2119, 2519 DOI 10.17487/RFC2119, March 1997, 2520 . 2522 [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration 2523 Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978, 2524 October 2000, . 2526 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2527 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2528 2003, . 2530 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2531 Resource Identifier (URI): Generic Syntax", STD 66, 2532 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2533 . 2535 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2536 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2537 July 2006, . 2539 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2540 Specifications: ABNF", STD 68, RFC 5234, 2541 DOI 10.17487/RFC5234, January 2008, 2542 . 2544 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2545 Media Attributes in the Session Description Protocol 2546 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 2547 . 2549 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 2550 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 2551 September 2009, . 2553 [RFC5890] Klensin, J., "Internationalized Domain Names for 2554 Applications (IDNA): Definitions and Document Framework", 2555 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2556 . 2558 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2559 Writing an IANA Considerations Section in RFCs", BCP 26, 2560 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2561 . 2563 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2564 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2565 May 2017, . 2567 12.2. Informative References 2569 [I-D.ietf-mmusic-sdp-bundle-negotiation] 2570 Holmberg, C., Alvestrand, H., and C. Jennings, 2571 "Negotiating Media Multiplexing Using the Session 2572 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 2573 negotiation-48 (work in progress), January 2018. 2575 [ITU.H332.1998] 2576 International Telecommunication Union, "H.323 extended for 2577 loosely coupled conferences", ITU Recommendation H.332, 2578 September 1998. 2580 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 2581 Protocol", RFC 2327, DOI 10.17487/RFC2327, April 1998, 2582 . 2584 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 2585 Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, 2586 October 2000, . 2588 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2589 A., Peterson, J., Sparks, R., Handley, M., and E. 2590 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2591 DOI 10.17487/RFC3261, June 2002, 2592 . 2594 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2595 with Session Description Protocol (SDP)", RFC 3264, 2596 DOI 10.17487/RFC3264, June 2002, 2597 . 2599 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2600 Jacobson, "RTP: A Transport Protocol for Real-Time 2601 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2602 July 2003, . 2604 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 2605 Video Conferences with Minimal Control", STD 65, RFC 3551, 2606 DOI 10.17487/RFC3551, July 2003, 2607 . 2609 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 2610 Modifiers for RTP Control Protocol (RTCP) Bandwidth", 2611 RFC 3556, DOI 10.17487/RFC3556, July 2003, 2612 . 2614 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2615 in Session Description Protocol (SDP)", RFC 3605, 2616 DOI 10.17487/RFC3605, October 2003, 2617 . 2619 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2620 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2621 RFC 3711, DOI 10.17487/RFC3711, March 2004, 2622 . 2624 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 2625 "Indicating User Agent Capabilities in the Session 2626 Initiation Protocol (SIP)", RFC 3840, 2627 DOI 10.17487/RFC3840, August 2004, 2628 . 2630 [RFC3890] Westerlund, M., "A Transport Independent Bandwidth 2631 Modifier for the Session Description Protocol (SDP)", 2632 RFC 3890, DOI 10.17487/RFC3890, September 2004, 2633 . 2635 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 2636 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 2637 . 2639 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 2640 (ICE): A Protocol for Network Address Translator (NAT) 2641 Traversal for Offer/Answer Protocols", RFC 5245, 2642 DOI 10.17487/RFC5245, April 2010, 2643 . 2645 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 2646 DOI 10.17487/RFC5322, October 2008, 2647 . 2649 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2650 Protocol (SDP) Grouping Framework", RFC 5888, 2651 DOI 10.17487/RFC5888, June 2010, 2652 . 2654 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 2655 "Network Time Protocol Version 4: Protocol and Algorithms 2656 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 2657 . 2659 [RFC6466] Salgueiro, G., "IANA Registration of the 'image' Media 2660 Type for the Session Description Protocol (SDP)", 2661 RFC 6466, DOI 10.17487/RFC6466, December 2011, 2662 . 2664 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 2665 "TCP Candidates with Interactive Connectivity 2666 Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, 2667 March 2012, . 2669 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2670 Specifications and Registration Procedures", BCP 13, 2671 RFC 6838, DOI 10.17487/RFC6838, January 2013, 2672 . 2674 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 2675 RFC 7405, DOI 10.17487/RFC7405, December 2014, 2676 . 2678 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 2679 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 2680 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 2681 DOI 10.17487/RFC7656, November 2015, 2682 . 2684 [RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 2685 and M. Stiemerling, Ed., "Real-Time Streaming Protocol 2686 Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December 2687 2016, . 2689 Authors' Addresses 2691 Ali Begen 2692 Networked Media 2693 Konya 2694 Turkey 2696 EMail: ali.begen@networked.media 2697 Paul Kyzivat 2698 USA 2700 EMail: pkyzivat@alum.mit.edu 2702 Colin Perkins 2703 University of Glasgow 2704 School of Computing Science 2705 University of Glasgow 2706 Glasgow G12 8QQ 2707 UK 2709 EMail: csp@csperkins.org 2711 Mark Handley 2712 University College London 2713 Department of Computer Science 2714 London WC1E 6BT 2715 UK 2717 EMail: M.Handley@cs.ucl.ac.uk