idnits 2.17.1 draft-ietf-mmusic-rfc4566bis-22.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 2 instances of too long lines in the document, the longest one being 10 characters in excess of 72. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 30, 2017) is 2463 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2978' is mentioned on line 1569, but not defined == Missing Reference: 'RFC2848' is mentioned on line 2224, but not defined == Missing Reference: 'RFC3108' is mentioned on line 2229, but not defined == Missing Reference: 'RFC7195' is mentioned on line 2230, but not defined == Missing Reference: 'RFC4145' is mentioned on line 2258, but not defined == Missing Reference: 'RFC6135' is mentioned on line 2259, but not defined == Unused Reference: 'RFC2978' is defined on line 2577, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-mmusic-data-channel-sdpneg-12 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-16 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- 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: 3 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Handley 3 Internet-Draft UCL 4 Obsoletes: 4566 (if approved) V. Jacobson 5 Intended status: Standards Track 6 Expires: January 1, 2018 C. Perkins 7 University of Glasgow 8 A. Begen 9 Networked Media 10 June 30, 2017 12 SDP: Session Description Protocol 13 draft-ietf-mmusic-rfc4566bis-22 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 http://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 January 1, 2018. 39 Copyright Notice 41 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . . . . 4 71 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . 5 76 4.1. Media and Transport Information . . . . . . . . . . . . . 6 77 4.2. Timing Information . . . . . . . . . . . . . . . . . . . 7 78 4.3. Obtaining Further Information about a Session . . . . . . 7 79 4.4. Categorisation . . . . . . . . . . . . . . . . . . . . . 8 80 4.5. Internationalisation . . . . . . . . . . . . . . . . . . 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 Data ("c=") . . . . . . . . . . . . . . . . . 15 89 5.8. Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . 17 90 5.9. Timing ("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=") . . . . . . . . . . . . . . . . . . . . 22 95 5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 23 96 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 25 97 6.1. cat (category) . . . . . . . . . . . . . . . . . . . . . 26 98 6.2. keywds (keywords) . . . . . . . . . . . . . . . . . . . . 26 99 6.3. tool . . . . . . . . . . . . . . . . . . . . . . . . . . 27 100 6.4. ptime (packet time) . . . . . . . . . . . . . . . . . . . 27 101 6.5. maxptime (maximum packet time) . . . . . . . . . . . . . 28 102 6.6. rtpmap . . . . . . . . . . . . . . . . . . . . . . . . . 28 103 6.7. Media Direction Attributes . . . . . . . . . . . . . . . 30 104 6.7.1. recvonly (receive-only) . . . . . . . . . . . . . . . 31 105 6.7.2. sendrecv (send-receive) . . . . . . . . . . . . . . . 31 106 6.7.3. sendonly (send-only) . . . . . . . . . . . . . . . . 32 107 6.7.4. inactive . . . . . . . . . . . . . . . . . . . . . . 32 108 6.8. orient (orientation) . . . . . . . . . . . . . . . . . . 33 109 6.9. type (conference type) . . . . . . . . . . . . . . . . . 33 110 6.10. charset (character set) . . . . . . . . . . . . . . . . . 34 111 6.11. sdplang (SDP language) . . . . . . . . . . . . . . . . . 35 112 6.12. lang (language) . . . . . . . . . . . . . . . . . . . . . 36 113 6.13. framerate (frame rate) . . . . . . . . . . . . . . . . . 37 114 6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 38 115 6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 38 116 7. Security Considerations . . . . . . . . . . . . . . . . . . . 39 117 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 118 8.1. The "application/sdp" Media Type . . . . . . . . . . . . 41 119 8.2. Registration of Parameters . . . . . . . . . . . . . . . 43 120 8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 43 121 8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 43 122 8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 44 123 8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 44 124 8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 47 125 8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 47 126 8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 48 127 8.2.8. Registration Procedure . . . . . . . . . . . . . . . 48 128 8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 49 129 8.4. Reorganization of the nettype Registry . . . . . . . . . 49 130 8.5. Reorganization of the att-field Registries . . . . . . . 49 131 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 50 132 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 55 133 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56 134 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 135 12.1. Normative References . . . . . . . . . . . . . . . . . . 56 136 12.2. Informative References . . . . . . . . . . . . . . . . . 57 137 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 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 term is used in this document and has specific meaning 168 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 The terms "multimedia conference" and "multimedia session" are used 174 in this document as defined in [RFC7656]. The terms "session" and 175 "multimedia session" are used interchangeably in this document. 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 179 "OPTIONAL" in this document are to be interpreted as described in 180 [RFC2119]. 182 3. Examples of SDP Usage 184 3.1. Session Initiation 186 The Session Initiation Protocol (SIP) [RFC3261] is an application- 187 layer control protocol for creating, modifying, and terminating 188 sessions such as Internet multimedia conferences, Internet telephone 189 calls, and multimedia distribution. The SIP messages used to create 190 sessions carry session descriptions that allow participants to agree 191 on a set of compatible media types. These session descriptions are 192 commonly formatted using SDP. When used with SIP, the offer/answer 193 model [RFC3264] provides a limited framework for negotiation using 194 SDP. 196 3.2. Streaming Media 198 The Real Time Streaming Protocol (RTSP) [RFC7826], is an application- 199 level protocol for control over the delivery of data with real-time 200 properties. RTSP provides an extensible framework to enable 201 controlled, on-demand delivery of real-time data, such as audio and 202 video. An RTSP client and server negotiate an appropriate set of 203 parameters for media delivery, partially using SDP syntax to describe 204 those parameters. 206 3.3. Email and the World Wide Web 208 Alternative means of conveying session descriptions include 209 electronic mail and the World Wide Web (WWW). For both email and WWW 210 distribution, the media type "application/sdp" is used. This enables 211 the automatic launching of applications for participation in the 212 session from the WWW client or mail reader in a standard manner. 214 Note that announcements of multicast sessions made only via email or 215 the WWW do not have the property that the receiver of a session 216 announcement can necessarily receive the session because the 217 multicast sessions may be restricted in scope, and access to the WWW 218 server or reception of email is possible outside this scope. 220 3.4. Multicast Session Announcement 222 In order to assist the advertisement of multicast multimedia 223 conferences and other multicast sessions, and to communicate the 224 relevant session setup information to prospective participants, a 225 distributed session directory may be used. An instance of such a 226 session directory periodically sends packets containing a description 227 of the session to a well-known multicast group. These advertisements 228 are received by other session directories such that potential remote 229 participants can use the session description to start the tools 230 required to participate in the session. 232 One protocol used to implement such a distributed directory is the 233 SAP [RFC2974]. SDP provides the recommended session description 234 format for such session announcements. 236 4. Requirements and Recommendations 238 The purpose of SDP is to convey information about media streams in 239 multimedia sessions to allow the recipients of a session description 240 to participate in the session. SDP is primarily intended for use in 241 an internetwork, although it is sufficiently general that it can 242 describe multimedia conferences in other network environments. Media 243 streams can be many-to-many. Sessions need not be continually 244 active. 246 Thus far, multicast-based sessions on the Internet have differed from 247 many other forms of conferencing in that anyone receiving the traffic 248 can join the session (unless the session traffic is encrypted). In 249 such an environment, SDP serves two primary purposes. It is a means 250 to communicate the existence of a session, and it is a means to 251 convey sufficient information to enable joining and participating in 252 the session. In a unicast environment, only the latter purpose is 253 likely to be relevant. 255 An SDP description includes the following: 257 o Session name and purpose 259 o Time(s) the session is active 261 o The media comprising the session 263 o Information needed to receive those media (addresses, ports, 264 formats, etc.) 266 As resources necessary to participate in a session may be limited, 267 some additional information may also be desirable: 269 o Information about the bandwidth to be used by the session 271 o Contact information for the person responsible for the session 273 In general, SDP must convey sufficient information to enable 274 applications to join a session (with the possible exception of 275 encryption keys) and to announce the resources to be used to any non- 276 participants that may need to know. (This latter feature is 277 primarily useful when SDP is used with a multicast session 278 announcement protocol.) 280 4.1. Media and Transport Information 282 An SDP description includes the following media information: 284 o The type of media (video, audio, etc.) 286 o The media transport protocol (RTP/UDP/IP, H.320, etc.) 288 o The format of the media (H.261 video, MPEG video, etc.) 289 In addition to media format and transport protocol, SDP conveys 290 address and port details. For an IP multicast session, these 291 comprise: 293 o The multicast group address for media 295 o The transport port for media 297 This address and port are the destination address and destination 298 port of the multicast stream, whether being sent, received, or both. 300 For unicast IP sessions, the following are conveyed: 302 o The remote address for media 304 o The remote transport port for media 306 The semantics of this address and port depend on the media and 307 transport protocol defined. By default, this SHOULD be the remote 308 address and remote port to which data is sent. Some media types may 309 redefine this behaviour, but this is NOT RECOMMENDED since it 310 complicates implementations (including middleboxes that must parse 311 the addresses to open Network Address Translation (NAT) or firewall 312 pinholes). 314 4.2. Timing Information 316 Sessions may be either bounded or unbounded in time. Whether or not 317 they are bounded, they may be only active at specific times. SDP can 318 convey: 320 o An arbitrary list of start and stop times bounding the session 322 o For each bound, repeat times such as "every Wednesday at 10am for 323 one hour" 325 This timing information is globally consistent, irrespective of local 326 time zone or daylight saving time (see Section 5.9). 328 4.3. Obtaining Further Information about a Session 330 A session description could convey enough information to decide 331 whether or not to participate in a session. SDP may include 332 additional pointers in the form of Uniform Resource Identifiers 333 (URIs) for more information about the session. 335 4.4. Categorisation 337 When many session descriptions are being distributed by SAP, or any 338 other advertisement mechanism, it may be desirable to filter session 339 announcements that are of interest from those that are not. SDP 340 supports a categorisation mechanism for sessions that is capable of 341 being automated (the "a=cat:" attribute; see Section 6). 343 4.5. Internationalisation 345 The SDP specification recommends the use of the ISO 10646 character 346 set in the UTF-8 encoding [RFC3629] to allow many different languages 347 to be represented. However, to assist in compact representations, 348 SDP also allows other character sets such as ISO 8859-1 to be used 349 when desired. Internationalisation only applies to free-text fields 350 (session name and background information), and not to SDP as a whole. 352 5. SDP Specification 354 An SDP description is denoted by the media type "application/sdp" 355 (See Section 8). 357 An SDP description is entirely textual. SDP field names and 358 attribute names use only the US-ASCII subset of UTF-8, but textual 359 fields and attribute values MAY use the full ISO 10646 character set 360 in UTF-8 encoding, or some other character set defined by the 361 "a=charset:" attribute. Field and attribute values that use the full 362 UTF-8 character set are never directly compared, hence there is no 363 requirement for UTF-8 normalisation. The textual form, as opposed to 364 a binary encoding such as ASN.1 or XDR, was chosen to enhance 365 portability, to enable a variety of transports to be used, and to 366 allow flexible, text-based toolkits to be used to generate and 367 process session descriptions. However, since SDP may be used in 368 environments where the maximum permissible size of a session 369 description is limited, the encoding is deliberately compact. Also, 370 since announcements may be transported via very unreliable means or 371 damaged by an intermediate caching server, the encoding was designed 372 with strict order and formatting rules so that most errors would 373 result in malformed session announcements that could be detected 374 easily and discarded. This also allows rapid discarding of encrypted 375 session announcements for which a receiver does not have the correct 376 key. 378 An SDP description consists of a number of lines of text of the form: 380 = 382 where MUST be exactly one case-significant character and 383 is structured text whose format depends on . In 384 general, is either a number of fields delimited by a single 385 space character or a free format string, and is case-significant 386 unless a specific field defines otherwise. Whitespace separators 387 MUST NOT be used on either side of the "=" sign, however, if the 388 value can contain a leading whitespace as part of its syntax, i.e., 389 that whitespace is part of the value. 391 An SDP description consists of a session-level section followed by 392 zero or more media-level sections. The session-level part starts 393 with a "v=" line and continues to the first media-level section (or 394 the end of the whole description, whichever comes first). Each 395 media-level section starts with an "m=" line and continues to the 396 next media-level section or the end of the whole session description 397 - whichever comes first. In general, session-level values are the 398 default for all media unless overridden by an equivalent media-level 399 value. 401 Some lines in each description are REQUIRED and some are OPTIONAL, 402 but all MUST appear in exactly the order given here (the fixed order 403 greatly enhances error detection and allows for a simple parser). 404 OPTIONAL items are marked with a "*". 406 Session description 407 v= (protocol version) 408 o= (originator and session identifier) 409 s= (session name) 410 i=* (session information) 411 u=* (URI of description) 412 e=* (email address) 413 p=* (phone number) 414 c=* (connection information -- not required if included in 415 all media descriptions) 416 b=* (zero or more bandwidth information lines) 417 One or more time descriptions ("t=" and "r=" lines; see below) 418 z=* (time zone adjustments) 419 k=* (encryption key) 420 a=* (zero or more session attribute lines) 421 Zero or more media descriptions 423 Time description 424 t= (time the session is active) 425 r=* (zero or more repeat times) 427 Media description, if present 428 m= (media name and transport address) 429 i=* (media title) 430 c=* (connection information -- optional if included at 431 session level) 432 b=* (zero or more bandwidth information lines) 433 k=* (encryption key) 434 a=* (zero or more media attribute lines) 436 The set of type letters is deliberately small and not intended to be 437 extensible -- an SDP parser MUST completely ignore any session 438 description that contains a type letter that it does not understand. 439 The attribute mechanism ("a=" described below) is the primary means 440 for extending SDP and tailoring it to particular applications or 441 media. Some attributes (the ones listed in Section 6 of this memo) 442 have a defined meaning, but others may be added on an application-, 443 media-, or session-specific basis. An SDP parser MUST ignore any 444 attribute it doesn't understand. 446 An SDP description may contain URIs that reference external content 447 in the "u=", "k=", and "a=" lines. These URIs may be dereferenced in 448 some cases, making the session description non-self- contained. 450 The connection ("c=") information in the session-level section 451 applies to all the media of that session unless overridden by 452 connection information in the media description. For instance, in 453 the example below, each audio media description behaves as if it were 454 given a "c=IN IP4 233.252.0.2". 456 An example SDP description is: 458 v=0 459 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 460 s=SDP Seminar 461 i=A Seminar on the session description protocol 462 u=http://www.example.com/seminars/sdp.pdf 463 e=j.doe@example.com (Jane Doe) 464 c=IN IP4 233.252.0.2 465 t=2873397496 2873404696 466 a=recvonly 467 m=audio 49170 RTP/AVP 0 468 m=audio 49180 RTP/AVP 0 469 m=video 51372 RTP/AVP 99 470 c=IN IP4 233.252.0.1/127 471 a=rtpmap:99 h263-1998/90000 473 Text fields such as the session name and information are octet 474 strings that may contain any octet with the exceptions of 0x00 (Nul), 475 0x0a (ASCII newline), and 0x0d (ASCII carriage return). The sequence 476 CRLF (0x0d0a) is used to end a record, although parsers SHOULD be 477 tolerant and also accept records terminated with a single newline 478 character. If the "a=charset" attribute is not present, these octet 479 strings MUST be interpreted as containing ISO-10646 characters in 480 UTF-8 encoding (the presence of the "a=charset" attribute may force 481 some fields to be interpreted differently). 483 A session description can contain domain names in the "o=", "u=", 484 "e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply 485 with [RFC1034], [RFC1035]. Internationalised domain names (IDNs) 486 MUST be represented using the ASCII Compatible Encoding (ACE) form 487 defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or 488 any other encoding (this requirement is for compatibility with 489 [RFC2327] and other early SDP-related standards, which predate the 490 development of internationalised domain names). 492 5.1. Protocol Version ("v=") 494 v=0 496 The "v=" line gives the version of the Session Description Protocol. 497 This memo defines version 0. There is no minor version number. 499 5.2. Origin ("o=") 501 o= 502 504 The "o=" line gives the originator of the session (her username and 505 the address of the user's host) plus a session identifier and version 506 number: 508 is the user's login on the originating host, or it is "-" 509 if the originating host does not support the concept of user IDs. 510 The MUST NOT contain spaces. 512 is a numeric string such that the tuple of , 513 , , , and forms a 514 globally unique identifier for the session. The method of allocation is up to the creating tool, but it has been 516 suggested that a Network Time Protocol (NTP) format timestamp be 517 used to ensure uniqueness [RFC5905]. 519 is a version number for this session description. 520 Its usage is up to the creating tool, so long as is 521 increased when a modification is made to the session data. Again, 522 it is RECOMMENDED that an NTP format timestamp is used. 524 is a text string giving the type of network. Initially 525 "IN" is defined to have the meaning "Internet", but other values 526 MAY be registered in the future (see Section 8). 528 is a text string giving the type of the address that 529 follows. Initially "IP4" and "IP6" are defined, but other values 530 MAY be registered in the future (see Section 8). 532 is an address of the machine from which the 533 session was created. For an address type of IP4, this is either a 534 fully qualified domain name of the machine or the dotted-decimal 535 representation of an IP version 4 address of the machine. For an 536 address type of IP6, this is either a fully qualified domain name 537 of the machine or the compressed textual representation of an IP 538 version 6 address of the machine. For both IP4 and IP6, the fully 539 qualified domain name is the form that SHOULD be given unless this 540 is unavailable, in which case a globally unique address MAY be 541 substituted. Unless an SDP extension for NAT traversal is used 542 (e.g., ICE [RFC5245], ICE TCP [RFC6544]), a local IP address MUST 543 NOT be used in any context where the SDP description might leave 544 the scope in which the address is meaningful (for example, a local 545 address MUST NOT be included in an application-level referral that 546 might leave the scope). 548 In general, the "o=" line serves as a globally unique identifier for 549 this version of this session description, and the sub-fields 550 excepting the version taken together identify the session 551 irrespective of any modifications. 553 For privacy reasons, it is sometimes desirable to obfuscate the 554 username and IP address of the session originator. If this is a 555 concern, an arbitrary and private MAY be 556 chosen to populate the "o=" line, provided that these are selected in 557 a manner that does not affect the global uniqueness of the field. 559 5.3. Session Name ("s=") 561 s= 563 The "s=" line is the textual session name. There MUST be one and 564 only one "s=" line per session description. The "s=" line MUST NOT 565 be empty and SHOULD contain ISO 10646 characters (but see also the 566 "a=charset" attribute). If a session has no meaningful name, the 567 value "s= " SHOULD be used (i.e., a single space as the session 568 name). 570 5.4. Session Information ("i=") 572 i= 574 The "i=" line provides textual information about the session. There 575 MUST be at most one session-level "i=" line per session description, 576 and at most one "i=" line per media description/definition. Unless a 577 media level "i="" line is used, the session-level "i="" line applies 578 to that media description. If the "a=charset" attribute is present, 579 it specifies the character set used in the "i=" line. If the 580 "a=charset" attribute is not present, the "i=" line MUST contain ISO 581 10646 characters in UTF-8 encoding. 583 A single "i=" line can be used for each media definition. In media 584 definitions, "i=" lines are primarily intended for labelling media 585 streams. As such, they are most likely to be useful when a single 586 session has more than one distinct media stream of the same media 587 type. An example would be two different whiteboards, one for slides 588 and one for feedback and questions. 590 The "i=" line is intended to provide a free-form human-readable 591 description of the session or the purpose of a media stream. It is 592 not suitable for parsing by automata. 594 5.5. URI ("u=") 596 u= 598 A URI is a Uniform Resource Identifier as used by WWW clients 599 [RFC3986]. The URI should be a pointer to additional information 600 about the session. This line is OPTIONAL. No more than one URI line 601 is allowed per session description. 603 5.6. Email Address and Phone Number ("e=" and "p=") 605 e= 606 p= 608 The "e=" and "p=" lines specify contact information for the person 609 responsible for the session. This is not necessarily the same person 610 that created the session description. 612 Inclusion of an email address or phone number is OPTIONAL. 614 If an email address or phone number is present, it MUST be specified 615 before the first media field. More than one email or phone line can 616 be given for a session description. 618 Phone numbers SHOULD be given in the form of an international public 619 telecommunication number (see ITU-T Recommendation E.164) preceded by 620 a "+". Spaces and hyphens may be used to split up a phone field to 621 aid readability if desired. For example: 623 p=+1 617 555-6011 625 Both email addresses and phone numbers can have an OPTIONAL free text 626 string associated with them, normally giving the name of the person 627 who may be contacted. This MUST be enclosed in parentheses if it is 628 present. For example: 630 e=j.doe@example.com (Jane Doe) 632 The alternative [RFC5322] name quoting convention is also allowed for 633 both email addresses and phone numbers. For example: 635 e=Jane Doe 637 The free text string SHOULD be in the ISO-10646 character set with 638 UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if 639 the appropriate session-level "a=charset" attribute is set. 641 5.7. Connection Data ("c=") 643 c= 645 The "c=" line contains connection data. 647 A session description MUST contain either at least one "c=" line in 648 each media description or a single "c=" line at the session level. 649 It MAY contain a single session-level "c=" line and additional "c=" 650 line(s) per media description, in which case the per-media values 651 override the session-level settings for the respective media. 653 The first sub-field ("") is the network type, which is a 654 text string giving the type of network. Initially, "IN" is defined 655 to have the meaning "Internet", but other values MAY be registered in 656 the future (see Section 8). 658 The second sub-field ("") is the address type. This allows 659 SDP to be used for sessions that are not IP based. This memo only 660 defines IP4 and IP6, but other values MAY be registered in the future 661 (see Section 8). 663 The third sub-field ("") is the connection 664 address. OPTIONAL sub-fields MAY be added after the connection 665 address depending on the value of the field. 667 When the is IP4 and IP6, the connection address is defined 668 as follows: 670 o If the session is multicast, the connection address will be an IP 671 multicast group address. If the session is not multicast, then 672 the connection address contains the unicast IP address of the 673 expected data source or data relay or data sink as determined by 674 additional attribute fields. It is not expected that unicast 675 addresses will be given in a session description that is 676 communicated by a multicast announcement, though this is not 677 prohibited. 679 o Sessions using an IP4 multicast connection address MUST also have 680 a time to live (TTL) value present in addition to the multicast 681 address. The TTL and the address together define the scope with 682 which multicast packets sent in this session will be sent. TTL 683 values MUST be in the range 0-255. Although the TTL MUST be 684 specified, its use to scope multicast traffic is deprecated; 685 applications SHOULD use an administratively scoped address 686 instead. 688 The TTL for the session is appended to the address using a slash as a 689 separator. An example is: 691 c=IN IP4 233.252.0.1/127 693 IP6 multicast does not use TTL scoping, and hence the TTL value MUST 694 NOT be present for IP6 multicast. It is expected that IP6 scoped 695 addresses will be used to limit the scope of multimedia conferences. 697 Hierarchical or layered encoding schemes are data streams where the 698 encoding from a single media source is split into a number of layers. 699 The receiver can choose the desired quality (and hence bandwidth) by 700 only subscribing to a subset of these layers. Such layered encodings 701 are normally transmitted in multiple multicast groups to allow 702 multicast pruning. This technique keeps unwanted traffic from sites 703 only requiring certain levels of the hierarchy. For applications 704 requiring multiple multicast groups, we allow the following notation 705 to be used for the connection address: 707 [/]/ 709 If the number of addresses is not given, it is assumed to be one. 710 Multicast addresses so assigned are contiguously allocated above the 711 base address, so that, for example: 713 c=IN IP4 233.252.0.1/127/3 715 would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3 716 are to be used at a TTL of 127. This is semantically identical to 717 including multiple "c=" lines in a media description: 719 c=IN IP4 233.252.0.1/127 720 c=IN IP4 233.252.0.2/127 721 c=IN IP4 233.252.0.3/127 723 Similarly, an IP6 example would be: 725 c=IN IP6 FF15::101/3 727 which is semantically equivalent to: 729 c=IN IP6 FF15::101 730 c=IN IP6 FF15::102 731 c=IN IP6 FF15::103 733 (remembering that the TTL field is not present in IP6 multicast). 735 Multiple addresses or "c=" lines MAY be specified on a per-media 736 basis only if they provide multicast addresses for different layers 737 in a hierarchical or layered encoding scheme. They MUST NOT be 738 specified for a session-level "c=" line. 740 The slash notation for multiple addresses described above MUST NOT be 741 used for IP unicast addresses. 743 5.8. Bandwidth ("b=") 745 b=: 747 This OPTIONAL line denotes the proposed bandwidth to be used by the 748 session or media. The is an alphanumeric modifier giving 749 the meaning of the figure. Two values are defined in 750 this specification, but other values MAY be registered in the future 751 (see Section 8 and [RFC3556], [RFC3890]): 753 CT If the bandwidth of a session is different from the bandwidth 754 implicit from the scope, a "b=CT:..." line SHOULD be supplied for 755 the session giving the proposed upper limit to the bandwidth used 756 (the "conference total" bandwidth). Similarly, if the bandwidth 757 of bundled media streams in an m line is different from the 758 implicit value from the scope, a "b=CT:..." line SHOULD be 759 supplied in the media level. The primary purpose of this is to 760 give an approximate idea as to whether two or more sessions (or 761 bundled media streams) can coexist simultaneously. Note that CT 762 gives a total bandwidth figure for all the media at all endpoints. 764 AS The bandwidth is interpreted to be application specific (it will 765 be the application's concept of maximum bandwidth). Normally, 766 this will coincide with what is set on the application's "maximum 767 bandwidth" control if applicable. For RTP-based applications, AS 768 gives the RTP "session bandwidth" as defined in Section 6.2 of 769 [RFC3550]. Note that AS gives a bandwidth figure for a single 770 media at a single endpoint, although there may be many endpoints 771 sending simultaneously. 773 A prefix "X-" is defined for names. This is intended for 774 experimental purposes only. For example: 776 b=X-YZ:128 778 Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers 779 SHOULD be registered with IANA in the standard namespace. SDP 780 parsers MUST ignore bandwidth fields with unknown modifiers. 781 Modifiers MUST be alphanumeric and, although no length limit is 782 given, it is recommended that they be short. 784 The is interpreted as kilobits per second by default. 785 The definition of a new modifier MAY specify that the 786 bandwidth is to be interpreted in some alternative unit (the "CT" and 787 "AS" modifiers defined in this memo use the default units). 789 5.9. Timing ("t=") 791 t= 793 The "t=" lines specify the start and stop times for a session. 794 Multiple "t=" lines MAY be used if a session is active at multiple 795 irregularly spaced times; each additional "t=" line specifies an 796 additional period of time for which the session will be active. If 797 the session is active at regular times, an "r=" line (see below) 798 should be used in addition to, and following, a "t=" line -- in which 799 case the "t=" line specifies the start and stop times of the repeat 800 sequence. 802 The first and second sub-fields give the start and stop times, 803 respectively, for the session. These values are the decimal 804 representation of Network Time Protocol (NTP) time values in seconds 805 since 1900 [RFC5905]. To convert these values to UNIX time, subtract 806 decimal 2208988800. 808 NTP timestamps are elsewhere represented by 64-bit values, which wrap 809 sometime in the year 2036. Since SDP uses an arbitrary length 810 decimal representation, this should not cause an issue (SDP 811 timestamps MUST continue counting seconds since 1900, NTP will use 812 the value modulo the 64-bit limit). 814 If the is set to zero, then the session is not bounded, 815 though it will not become active until after the . If 816 the is also zero, the session is regarded as permanent. 818 User interfaces SHOULD strongly discourage the creation of unbounded 819 and permanent sessions as they give no information about when the 820 session is actually going to terminate, and so make scheduling 821 difficult. 823 The general assumption may be made, when displaying unbounded 824 sessions that have not timed out to the user, that an unbounded 825 session will only be active until half an hour from the current time 826 or the session start time, whichever is the later. If behaviour 827 other than this is required, an end-time SHOULD be given and modified 828 as appropriate when new information becomes available about when the 829 session should really end. 831 Permanent sessions may be shown to the user as never being active 832 unless there are associated repeat times that state precisely when 833 the session will be active. 835 5.10. Repeat Times ("r=") 837 r= 839 "r=" line specifies repeat times for a session. For example, if a 840 session is active at 10am on Monday and 11am on Tuesday for one hour 841 each week for three months, then the in the 842 corresponding "t=" line would be the NTP representation of 10am on 843 the first Monday, the would be 1 week, the would be 1 hour, and the offsets would be zero and 25 845 hours. The corresponding "t=" line stop time would be the NTP 846 representation of the end of the last session three months later. By 847 default, all fields are in seconds, so the "r=" and "t=" lines might 848 be the following: 850 t=3034423619 3042462419 851 r=604800 3600 0 90000 853 To make the description more compact, times may also be given in 854 units of days, hours, or minutes. The syntax for these is a number 855 immediately followed by a single case-sensitive character. 856 Fractional units are not allowed -- a smaller unit should be used 857 instead. The following unit specification characters are allowed: 859 d - days (86400 seconds) 860 h - hours (3600 seconds) 861 m - minutes (60 seconds) 862 s - seconds (allowed for completeness) 864 Thus, the above session announcement could also have been written: 866 r=7d 1h 0 25h 868 Monthly and yearly repeats cannot be directly specified with a single 869 SDP repeat time; instead, separate "t=" lines should be used to 870 explicitly list the session times. 872 5.11. Time Zones ("z=") 874 z= .... 876 To schedule a repeated session that spans a change from daylight 877 saving time to standard time or vice versa, it is necessary to 878 specify offsets from the base time. This is required because 879 different time zones change time at different times of day, different 880 countries change to or from daylight saving time on different dates, 881 and some countries do not have daylight saving time at all. 883 Thus, in order to schedule a session that is at the same time winter 884 and summer, it must be possible to specify unambiguously by whose 885 time zone a session is scheduled. To simplify this task for 886 receivers, we allow the sender to specify the NTP time that a time 887 zone adjustment happens and the offset from the time when the session 888 was first scheduled. The "z=" line allows the sender to specify a 889 list of these adjustment times and offsets from the base time. 891 An example might be the following: 893 z=2882844526 -1h 2898848070 0 895 This specifies that at time 2882844526, the time base by which the 896 session's repeat times are calculated is shifted back by 1 hour, and 897 that at time 2898848070, the session's original time base is 898 restored. Adjustments are always relative to the specified start 899 time -- they are not cumulative. Adjustments apply to all "t=" and 900 "r=" lines in a session description. 902 If a session is likely to last several years, it is expected that the 903 session description will be modified periodically rather than 904 transmit several years' worth of adjustments in one session 905 description. 907 5.12. Encryption Keys ("k=") 909 k= 910 k=: 912 If transported over a secure and trusted channel, the Session 913 Description Protocol MAY be used to convey encryption keys. A simple 914 mechanism for key exchange is provided by the key line ("k="), 915 although this is primarily supported for compatibility with older 916 implementations and its use is NOT RECOMMENDED. Work is in progress 917 to define new key exchange mechanisms for use with SDP [RFC4567] 918 [RFC4568], and it is expected that new applications will use those 919 mechanisms. 921 A key line is permitted before the first media entry (in which case 922 it applies to all media in the session), or for each media entry as 923 required. The format of keys and their usage are outside the scope 924 of this document, and the key field provides no way to indicate the 925 encryption algorithm to be used, key type, or other information about 926 the key: this is assumed to be provided by the higher-level protocol 927 using SDP. If there is a need to convey this information within SDP, 928 the extensions mentioned previously SHOULD be used. Many security 929 protocols require two keys: one for confidentiality, another for 930 integrity. This specification does not support transfer of two keys. 932 The method indicates the mechanism to be used to obtain a usable key 933 by external means, or from the encoded encryption key given. The 934 following methods are defined: 936 k=clear: 938 The encryption key is included untransformed in this key line. 939 This method MUST NOT be used unless it can be guaranteed that 940 the SDP is conveyed over a secure channel. The encryption key 941 is interpreted as text according to the charset attribute; use 942 the "k=base64:" method to convey characters that are otherwise 943 prohibited in SDP. 945 k=base64: 947 The encryption key is included in this key line but has been 948 base64 encoded [RFC4648] because it includes characters that 949 are prohibited in SDP. This method MUST NOT be used unless it 950 can be guaranteed that the SDP is conveyed over a secure 951 channel. 953 k=uri: 955 A Uniform Resource Identifier is included in the key line. The 956 URI refers to the data containing the key, and may require 957 additional authentication before the key can be returned. When 958 a request is made to the given URI, the reply should specify 959 the encoding for the key. The URI is often an Secure Socket 960 Layer/Transport Layer Security (SSL/TLS)-protected HTTP URI 961 ("https:"), although this is not required. 963 k=prompt 965 No key is included in this SDP description, but the session or 966 media stream referred to by this key line is encrypted. The 967 user should be prompted for the key when attempting to join the 968 session, and this user-supplied key should then be used to 969 decrypt the media streams. The use of user-specified keys is 970 NOT RECOMMENDED, since such keys tend to have weak security 971 properties. 973 The key line MUST NOT be used unless it can be guaranteed that the 974 SDP is conveyed over a secure and trusted channel. An example of 975 such a channel might be SDP embedded inside an S/MIME message or a 976 TLS-protected HTTP session. It is important to ensure that the 977 secure channel is with the party that is authorised to join the 978 session, not an intermediary: if a caching proxy server is used, it 979 is important to ensure that the proxy is either trusted or unable to 980 access the SDP. 982 5.13. Attributes ("a=") 984 a= 985 a=: 987 Attributes are the primary means for extending SDP. Attributes may 988 be defined to be used as "session-level" attributes, "media-level" 989 attributes, or both. 991 A media description may have any number of attributes ("a=" lines) 992 that are media specific. These are referred to as "media-level" 993 attributes and add information about the media stream. Attribute 994 lines can also be added before the first media field; these "session- 995 level" attributes convey additional information that applies to the 996 session as a whole rather than to individual media. 998 Attribute lines may be of two forms: 1000 o A property attribute is simply of the form "a=". These are 1001 binary attributes, and the presence of the attribute conveys that 1002 the attribute is a property of the session. An example might be 1003 "a=recvonly". 1005 o A value attribute is of the form "a=:". For 1006 example, a whiteboard could have the value attribute 1007 "a=orient:landscape" 1009 Attribute interpretation depends on the media tool being invoked. 1010 Thus receivers of session descriptions should be configurable in 1011 their interpretation of session descriptions in general and of 1012 attributes in particular. 1014 Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. 1016 Attribute values are octet strings, and MAY use any octet value 1017 except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute 1018 values are to be interpreted as in ISO-10646 character set with UTF-8 1019 encoding. Unlike other text fields, attribute values are NOT 1020 normally affected by the "charset" attribute as this would make 1021 comparisons against known values problematic. However, when an 1022 attribute is defined, it can be defined to be charset dependent, in 1023 which case its value should be interpreted in the session charset 1024 rather than in ISO-10646. 1026 Attributes MUST be registered with IANA (see Section 8). If an 1027 attribute is received that is not understood, it MUST be ignored by 1028 the receiver. 1030 5.14. Media Descriptions ("m=") 1032 m= ... 1034 A session description may contain a number of media descriptions. 1035 Each media description starts with an "m=" line and is terminated by 1036 either the next "m=" line or by the end of the session description. 1037 A media field has several sub-fields: 1039 is the media type. This document defines the values 1040 "audio", "video", "text", "application", and "message". This list 1041 is extended and may be further extended by other memos registering 1042 media types in the future (see Section 8). 1044 is the transport port to which the media stream is sent. The 1045 meaning of the transport port depends on the network being used as 1046 specified in the relevant "c=" line, and on the transport protocol 1047 defined in the sub-field of the media field. Other ports 1048 used by the media application (such as the RTP Control Protocol 1049 (RTCP) port [RFC3550]) MAY be derived algorithmically from the 1050 base media port or MAY be specified in a separate attribute (for 1051 example, "a=rtcp:" as defined in [RFC3605]). 1053 If non-contiguous ports are used or if they don't follow the 1054 parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" 1055 attribute MUST be used. Applications that are requested to send 1056 media to a that is odd and where the "a=rtcp:" is present 1057 MUST NOT subtract 1 from the RTP port: that is, they MUST send the 1058 RTP to the port indicated in and send the RTCP to the port 1059 indicated in the "a=rtcp" attribute. 1061 For applications where hierarchically encoded streams are being 1062 sent to a unicast address, it may be necessary to specify multiple 1063 transport ports. This is done using a similar notation to that 1064 used for IP multicast addresses in the "c=" line: 1066 m= / ... 1068 In such a case, the ports used depend on the transport protocol. 1069 For RTP, the default is that only the even-numbered ports are used 1070 for data with the corresponding one-higher odd ports used for the 1071 RTCP belonging to the RTP session, and the 1072 denoting the number of RTP sessions. For example: 1074 m=video 49170/2 RTP/AVP 31 1076 would specify that ports 49170 and 49171 form one RTP/RTCP pair 1077 and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the 1078 transport protocol and 31 is the format (see below). If non- 1079 contiguous ports are required, they must be signalled using a 1080 separate attribute (for example, "a=rtcp:" as defined in 1081 [RFC3605]). 1083 If multiple addresses are specified in the "c=" line and multiple 1084 ports are specified in the "m=" line, a one-to-one mapping from 1085 port to the corresponding address is implied. For example: 1087 c=IN IP4 233.252.0.1/127/2 1088 m=video 49170/2 RTP/AVP 31 1090 would imply that address 233.252.0.1 is used with ports 49170 and 1091 49171, and address 233.252.0.2 is used with ports 49172 and 49173. 1093 The semantics of multiple "m=" lines using the same transport 1094 address are undefined. This implies that, unlike limited past 1095 practice, there is no implicit grouping defined by such means and 1096 an explicit grouping framework (for example, [RFC5888]) should 1097 instead be used to express the intended semantics. 1099 is the transport protocol. The meaning of the transport 1100 protocol is dependent on the address type field in the relevant 1101 "c=" line. Thus a "c=" field of IP4 indicates that the transport 1102 protocol runs over IP4. The following transport protocols are 1103 defined, but may be extended through registration of new protocols 1104 with IANA (see Section 8): 1106 * udp: denotes an unspecified protocol running over UDP. 1108 * RTP/AVP: denotes RTP [RFC3550] used under the RTP Profile for 1109 Audio and Video Conferences with Minimal Control [RFC3551] 1110 running over UDP. 1112 * RTP/SAVP: denotes the Secure Real-time Transport Protocol 1113 [RFC3711] running over UDP. 1115 The main reason to specify the transport protocol in addition to 1116 the media format is that the same standard media formats may be 1117 carried over different transport protocols even when the network 1118 protocol is the same -- a historical example is vat Pulse Code 1119 Modulation (PCM) audio and RTP PCM audio; another might be TCP/RTP 1120 PCM audio. In addition, relays and monitoring tools that are 1121 transport-protocol-specific but format-independent are possible. 1123 is a media format description. The fourth and any subsequent 1124 sub-fields describe the format of the media. The interpretation 1125 of the media format depends on the value of the sub-field. 1127 If the sub-field is "RTP/AVP" or "RTP/SAVP" the sub- 1128 fields contain RTP payload type numbers. When a list of payload 1129 type numbers is given, this implies that all of these payload 1130 formats MAY be used in the session, but the first of these formats 1131 SHOULD be used as the default format for the session. For dynamic 1132 payload type assignments the "a=rtpmap:" attribute (see Section 6) 1133 SHOULD be used to map from an RTP payload type number to a media 1134 encoding name that identifies the payload format. The "a=fmtp:" 1135 attribute MAY be used to specify format parameters (see 1136 Section 6). 1138 If the sub-field is "udp" the sub-fields MUST 1139 reference a media type describing the format under the "audio", 1140 "video", "text", "application", or "message" top-level media 1141 types. The media type registration SHOULD define the packet 1142 format for use with UDP transport. 1144 For media using other transport protocols, the field is 1145 protocol specific. Rules for interpretation of the sub- 1146 field MUST be defined when registering new protocols (see 1147 Section 8.2.2). 1149 Section 3 of [RFC4855] states that the payload format (encoding) 1150 names defined in the RTP Profile are commonly shown in upper case, 1151 while media subtype names are commonly shown in lower case. It 1152 also states that both of these names are case-insensitive in both 1153 places, similar to parameter names which are case-insensitive both 1154 in media type strings and in the default mapping to the SDP a=fmtp 1155 attribute. 1157 6. SDP Attributes 1159 The following attributes are defined. Since application writers may 1160 add new attributes as they are required, this list is not exhaustive. 1161 Registration procedures for new attributes are defined in 1162 Section 8.2.4. 1164 6.1. cat (category) 1166 Name: cat 1168 Value: cat-value 1170 Usage Level: session 1172 Charset Dependent: no 1174 Syntax: 1176 cat-value = category 1177 category = non-ws-string 1179 Example: 1181 a=cat:foo.bar 1183 This attribute gives the dot-separated hierarchical category of the 1184 session. This is to enable a receiver to filter unwanted sessions by 1185 category. There is no central registry of categories. This 1186 attribute is obsoleted. 1188 6.2. keywds (keywords) 1190 Name: keywds 1192 Value: keywds-value 1194 Usage Level: session 1196 Charset Dependent: yes 1198 Syntax: 1200 keywds-value = keywords 1201 keywords = text 1203 Example: 1205 a=keywds:SDP session description protocol 1207 Like the cat attribute, this is to assist identifying wanted sessions 1208 at the receiver. This allows a receiver to select interesting 1209 session based on keywords describing the purpose of the session; 1210 there is no central registry of keywords. Its value should be 1211 interpreted in the charset specified for the session description if 1212 one is specified, or by default in ISO 10646/UTF-8. This attribute 1213 is obsoleted. 1215 6.3. tool 1217 Name: tool 1219 Value: tool-value 1221 Usage Level: session 1223 Charset Dependent: no 1225 Syntax: 1227 tool-value = tool-name-and-version 1228 tool-name-and-version = text 1230 Example: 1232 a=tool:foobar V3.2 1234 This gives the name and version number of the tool used to create the 1235 session description. 1237 6.4. ptime (packet time) 1239 Name: ptime 1241 Value: ptime-value 1243 Usage Level: media 1245 Charset Dependent: no 1247 Syntax: 1249 ptime-value = non-zero-int-or-real 1251 Example: 1253 a=ptime:20 1255 This gives the length of time in milliseconds represented by the 1256 media in a packet. This is probably only meaningful for audio data, 1257 but may be used with other media types if it makes sense. It should 1258 not be necessary to know ptime to decode RTP or vat audio, and it is 1259 intended as a recommendation for the encoding/packetisation of audio. 1261 6.5. maxptime (maximum packet time) 1263 Name: maxptime 1265 Value: maxptime-value 1267 Usage Level: media 1269 Charset Dependent: no 1271 Syntax: 1273 maxptime-value = non-zero-int-or-real 1275 Example: 1277 a=maxptime:20 1279 This gives the maximum amount of media that can be encapsulated in 1280 each packet, expressed as time in milliseconds. The time SHALL be 1281 calculated as the sum of the time the media present in the packet 1282 represents. For frame-based codecs, the time SHOULD be an integer 1283 multiple of the frame size. This attribute is probably only 1284 meaningful for audio data, but may be used with other media types if 1285 it makes sense. Note that this attribute was introduced after 1286 [RFC2327], and non-updated implementations will ignore this 1287 attribute. 1289 6.6. rtpmap 1291 Name: rtpmap 1293 Value: rtpmap-value 1295 Usage Level: media 1297 Charset Dependent: no 1298 Syntax: 1300 rtpmap-value = payload-type SP encoding-name 1301 "/" clock-rate [ "/" encoding-params ] 1302 payload-type = zero-based-integer 1303 encoding-name = token 1304 clock-rate = integer 1305 ; Editor's note: Do we want to define a limited range for this? 1306 encoding-params = channels 1307 ; Editor's note: 4566 is vague about what this can be. RFC4855 seems to be 1308 ; the authoritative source, and only allows the 1309 ; value of the media subtype "channels" parameter - the 1310 ; number of audio channels. 1311 ; Does anyone think this can be used for something else? 1312 ; (The implication that multiple parameters might be included 1313 ; seems a misdirection - additional parameters are 1314 ; to go into a=fmtp.) 1315 ; Does anyone have an example of other parameters 1316 ; using this field? If none, it will stay as it is. 1317 channels = integer 1318 ; Editor's note: Is there any reason to make this less restrictive? 1320 This attribute maps from an RTP payload type number (as used in an 1321 "m=" line) to an encoding name denoting the payload format to be 1322 used. It also provides information on the clock rate and encoding 1323 parameters. Note that the payload type number is indicated in a 1324 7-bit field, limiting the values to incusively between 0 and 127. 1326 Although an RTP profile can make static assignments of payload type 1327 numbers to payload formats, it is more common for that assignment to 1328 be done dynamically using "a=rtpmap:" attributes. As an example of a 1329 static payload type, consider u-law PCM coded single-channel audio 1330 sampled at 8 kHz. This is completely defined in the RTP Audio/Video 1331 profile as payload type 0, so there is no need for an "a=rtpmap:" 1332 attribute, and the media for such a stream sent to UDP port 49232 can 1333 be specified as: 1335 m=audio 49232 RTP/AVP 0 1337 An example of a dynamic payload type is 16-bit linear encoded stereo 1338 audio sampled at 16 kHz. If we wish to use the dynamic RTP/AVP 1339 payload type 98 for this stream, additional information is required 1340 to decode it: 1342 m=audio 49232 RTP/AVP 98 1343 a=rtpmap:98 L16/16000/2 1345 Up to one rtpmap attribute can be defined for each media format 1346 specified. Thus, we might have the following: 1348 m=audio 49230 RTP/AVP 96 97 98 1349 a=rtpmap:96 L8/8000 1350 a=rtpmap:97 L16/8000 1351 a=rtpmap:98 L16/11025/2 1353 RTP profiles that specify the use of dynamic payload types MUST 1354 define the set of valid encoding names and/or a means to register 1355 encoding names if that profile is to be used with SDP. The "RTP/AVP" 1356 and "RTP/SAVP" profiles use media subtypes for encoding names, under 1357 the top-level media type denoted in the "m=" line. In the example 1358 above, the media types are "audio/l8" and "audio/l16". 1360 For audio streams, indicates the number of 1361 audio channels. This parameter is OPTIONAL and may be omitted if the 1362 number of channels is one, provided that no additional parameters are 1363 needed. 1365 For video streams, no encoding parameters are currently specified. 1367 Additional encoding parameters MAY be defined in the future, but 1368 codec-specific parameters SHOULD NOT be added. Parameters added to 1369 an "a=rtpmap:" attribute SHOULD only be those required for a session 1370 directory to make the choice of appropriate media to participate in a 1371 session. Codec-specific parameters should be added in other 1372 attributes (for example, "a=fmtp:"). 1374 Note: RTP audio formats typically do not include information about 1375 the number of samples per packet. If a non-default (as defined in 1376 the RTP Audio/Video Profile) packetisation is required, the "ptime" 1377 attribute is used as given above. 1379 6.7. Media Direction Attributes 1381 At most one of recvonly/sendrecv/sendonly/inactive MAY appear at 1382 session level, and at most one MAY appear in each media section. 1384 If any one of these appears in a media section then it applies for 1385 that media section. If none appear in a media section then the one 1386 from session level, if any, applies to that media section. 1388 If none of the media direction attributes is present at either 1389 session level or media level, "sendrecv" SHOULD be assumed as the 1390 default for sessions that are not of the multimedia conference type 1391 "broadcast" or "H332" (see below). 1393 Within the following SDP example, the "inactive" attribute applies to 1394 audio media and the "recvonly" attribute applies to video media. 1396 v=0 1397 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 1398 s=SDP Seminar 1399 i=A Seminar on the session description protocol 1400 u=http://www.example.com/seminars/sdp.pdf 1401 e=j.doe@example.com (Jane Doe) 1402 c=IN IP4 233.252.0.1/127 1403 t=2873397496 2873404696 1404 a=inactive 1405 m=audio 49170 RTP/AVP 0 1406 m=video 51372 RTP/AVP 99 1407 a=rtpmap:99 h263-1998/90000 1408 a=recvonly 1410 6.7.1. recvonly (receive-only) 1412 Name: recvonly 1414 Value: 1416 Usage Level: session, media 1418 Charset Dependent: no 1420 Example: 1422 a=recvonly 1424 This specifies that the tools should be started in receive-only mode 1425 where applicable. Note that recvonly applies to the media only, not 1426 to any associated control protocol (e.g., an RTP-based system in 1427 recvonly mode SHOULD still send RTCP packets). 1429 6.7.2. sendrecv (send-receive) 1431 Name: sendrecv 1433 Value: 1435 Usage Level: session, media 1437 Charset Dependent: no 1438 Example: 1440 a=sendrecv 1442 This specifies that the tools should be started in send and receive 1443 mode. This is necessary for interactive multimedia conferences with 1444 tools that default to receive-only mode. 1446 6.7.3. sendonly (send-only) 1448 Name: sendonly 1450 Value: 1452 Usage Level: session, media 1454 Charset Dependent: no 1456 Example: 1458 a=sendonly 1460 This specifies that the tools should be started in send-only mode. 1461 An example may be where a different unicast address is to be used for 1462 a traffic destination than for a traffic source. In such a case, two 1463 media descriptions may be used, one sendonly and one recvonly. Note 1464 that sendonly applies only to the media, and any associated control 1465 protocol (e.g., RTCP) SHOULD still be received and processed as 1466 normal. 1468 6.7.4. inactive 1470 Name: inactive 1472 Value: 1474 Usage Level: session, media 1476 Charset Dependent: no 1478 Example: 1480 a=inactive 1482 This specifies that the tools should be started in inactive mode. 1483 This is necessary for interactive multimedia conferences where users 1484 can put other users on hold. No media is sent over an inactive media 1485 stream. Note that an RTP-based system MUST still send RTCP (if RTCP 1486 is used), even if started inactive. 1488 6.8. orient (orientation) 1490 Name: orient 1492 Value: orient-value 1494 Usage Level: media 1496 Charset Dependent: no 1498 Syntax: 1500 orient-value = portrait / landscape / seascape 1501 portrait = %s"portrait" 1502 landscape = %s"landscape" 1503 seascape = %s"seascape" 1504 ; NOTE: These names are case-sensitive. 1506 Example: 1508 a=orient:portrait 1510 Normally this is only used for a whiteboard or presentation tool. It 1511 specifies the orientation of the workspace on the screen. Permitted 1512 values are "portrait", "landscape", and "seascape" (upside-down 1513 landscape). 1515 6.9. type (conference type) 1517 Name: type 1519 Value: type-value 1521 Usage Level: session 1523 Charset Dependent: no 1524 Syntax: 1526 type-value = conference-type 1527 conference-type = broadcast / meeting / moderated / test / 1528 H332 1529 broadcast = %s"broadcast" 1530 meeting = %s"meeting" 1531 moderated = %s"moderated" 1532 test = %s"test" 1533 H332 = %s"H332" 1534 ; NOTE: These names are case-sensitive. 1536 Example: 1538 a=type:moderated 1540 This specifies the type of the multimedia conference. Suggested 1541 values are "broadcast", "meeting", "moderated", "test", and "H332". 1542 "recvonly" should be the default for "type:broadcast" sessions, 1543 "type:meeting" should imply "sendrecv", and "type:moderated" should 1544 indicate the use of a floor control tool and that the media tools are 1545 started so as to mute new sites joining the multimedia conference. 1547 Specifying the attribute "type:H332" indicates that this loosely 1548 coupled session is part of an H.332 session as defined in the ITU 1549 H.332 specification [ITU.H332.1998]. Media tools should be started 1550 "recvonly". 1552 Specifying the attribute "type:test" is suggested as a hint that, 1553 unless explicitly requested otherwise, receivers can safely avoid 1554 displaying this session description to users. 1556 6.10. charset (character set) 1558 Name: charset 1560 Value: charset-value 1562 Usage Level: session 1564 Charset Dependent: no 1566 Syntax: 1568 charset-value = mime-charset 1569 (as defined in [RFC 2978]) 1571 This specifies the character set to be used to display the session 1572 name and information data. By default, the ISO-10646 character set 1573 in UTF-8 encoding is used. If a more compact representation is 1574 required, other character sets may be used. For example, the ISO 1575 8859-1 is specified with the following SDP attribute: 1577 a=charset:ISO-8859-1 1579 The charset specified MUST be one of those registered in the IANA 1580 Character Sets registry (http://www.iana.org/assignments/character- 1581 sets), such as ISO-8859-1. The character set identifier is a US- 1582 ASCII string and MUST be compared against identifiers from the "Name" 1583 or "Preferred MIME Name" field of the registry using a case- 1584 insensitive comparison. If the identifier is not recognised or not 1585 supported, all strings that are affected by it SHOULD be regarded as 1586 octet strings. 1588 Note that a character set specified MUST still prohibit the use of 1589 bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets requiring 1590 the use of these characters MUST define a quoting mechanism that 1591 prevents these bytes from appearing within text fields. 1593 6.11. sdplang (SDP language) 1595 Name: sdplang 1597 Value: sdplang-value 1599 Usage Level: session, media 1601 Charset Dependent: no 1603 Syntax: 1605 sdplang-value = Language-Tag 1606 ; Language-Tag defined in RFC5646 1608 Example: 1610 a=sdplang:fr 1612 Multiple sdplang attributes can be provided either at session or 1613 media level if the session description or media use multiple 1614 languages. 1616 As a session-level attribute, it specifies the language for the 1617 session description (not the language of the media). As a media- 1618 level attribute, it specifies the language for any media-level SDP 1619 information field associated with that media (again not the language 1620 of the media), overriding any sdplang attributes specified at 1621 session-level. 1623 In general, sending session descriptions consisting of multiple 1624 languages is discouraged. Instead, multiple descriptions SHOULD be 1625 sent describing the session, one in each language. However, this is 1626 not possible with all transport mechanisms, and so multiple sdplang 1627 attributes are allowed although NOT RECOMMENDED. 1629 The "sdplang" attribute value must be a single [RFC5646] language tag 1630 in US-ASCII. An "sdplang" attribute SHOULD be specified when a 1631 session is distributed with sufficient scope to cross geographic 1632 boundaries, where the language of recipients cannot be assumed, or 1633 where the session is in a different language from the locally assumed 1634 norm. 1636 6.12. lang (language) 1638 Name: lang 1640 Value: lang-value 1642 Usage Level: session, media 1644 Charset Dependent: no 1646 Syntax: 1648 lang-value = Language-Tag 1649 ; Language-Tag defined in RFC5646 1651 Example: 1653 a=lang:de 1655 Multiple lang attributes can be provided either at session or media 1656 level if the session or media has capabilities in more than one 1657 language, in which case the order of the attributes indicates the 1658 order of preference of the various languages in the session or media, 1659 from most preferred to least preferred. 1661 As a session-level attribute, lang specifies a language capability 1662 for the session being described. As a media-level attribute, it 1663 specifies a language capability for that media, overriding any 1664 session-level language(s) specified. 1666 The "lang" attribute value must be a single [RFC5646] language tag in 1667 US-ASCII. A "lang" attribute SHOULD be specified when a session is 1668 of sufficient scope to cross geographic boundaries where the language 1669 of participants cannot be assumed, or where the session has 1670 capabilities in languages different from the locally assumed norm. 1672 The "lang" attribute is supposed to be used for settling the initial 1673 language(s) used in the session. Events during the session may 1674 influence which language(s) are used, and the participants are not 1675 strictly bound to only use the declared languages. 1677 Most real-time use cases start with just one language used, while 1678 other cases involve a range of languages, e.g. an interpreted or 1679 subtitled session. When more than one 'lang' attribute is specified, 1680 the "lang" attribute itself does not provide any information about if 1681 multiple languages are intended to be used during the session, or if 1682 the intention is to only select one language. Other attributes or 1683 the semantics in which the "lang" attributes are used might indicate 1684 such conditions. Without such indications of usage intent, it is 1685 assumed that for a negotiated session one of the declared languages 1686 will be selected and used. 1688 6.13. framerate (frame rate) 1690 Name: framerate 1692 Value: framerate-value 1694 Usage Level: media 1696 Charset Dependent: no 1698 Syntax: 1700 framerate-value = non-zero-int-or-real 1702 Example: 1704 a=framerate:60 1706 This gives the maximum video frame rate in frames/sec. It is 1707 intended as a recommendation for the encoding of video data. Decimal 1708 representations of fractional values are allowed. It is defined only 1709 for video media. 1711 6.14. quality 1713 Name: quality 1715 Value: quality-value 1717 Usage Level: media 1719 Charset Dependent: no 1721 Syntax: 1723 quality-value = zero-based-integer 1725 Example: 1727 a=quality:10 1729 This gives a suggestion for the quality of the encoding as an integer 1730 value. The intention of the quality attribute for video is to 1731 specify a non-default trade-off between frame-rate and still-image 1732 quality. For video, the value is in the range 0 to 10, with the 1733 following suggested meaning: 1735 10 - the best still-image quality the compression scheme 1736 can give. 1737 5 - the default behaviour given no quality suggestion. 1738 0 - the worst still-image quality the codec designer 1739 thinks is still usable. 1741 Editor's note: The usage should be checked with the SIP Forum to see 1742 whether anybody is using this. Otherwise, the recommendation will be 1743 not to use this attribute and the receiver ignores it upon reception. 1745 6.15. fmtp (format parameters) 1747 Name: fmtp 1749 Value: fmtp-value 1751 Usage Level: media 1753 Charset Dependent: no 1754 Syntax: 1756 fmtp-value = fmt SP format-specific-params 1757 format-specific-params = byte-string 1758 ; Notes: 1759 ; - The format parameters are media type parameters and 1760 need to reflect their syntax. 1762 Example: 1764 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1766 This attribute allows parameters that are specific to a particular 1767 format to be conveyed in a way that SDP does not have to understand 1768 them. The format must be one of the formats specified for the media. 1769 Format-specific parameters may be any set of parameters required to 1770 be conveyed by SDP and given unchanged to the media tool that will 1771 use this format. At most one instance of this attribute is allowed 1772 for each format. 1774 7. Security Considerations 1776 SDP is frequently used with the Session Initiation Protocol [RFC3261] 1777 using the offer/answer model [RFC3264] to agree on parameters for 1778 unicast sessions. When used in this manner, the security 1779 considerations of those protocols apply. 1781 SDP is a session description format that describes multimedia 1782 sessions. Entities receiving and acting upon an SDP message SHOULD 1783 be aware that a session description cannot be trusted unless it has 1784 been obtained by an authenticated transport protocol from a known and 1785 trusted source. Many different transport protocols may be used to 1786 distribute session descriptions, and the nature of the authentication 1787 will differ from transport to transport. For some transports, 1788 security features are often not deployed. In case a session 1789 description has not been obtained in a trusted manner, the endpoint 1790 SHOULD exercise care because, among other attacks, the media sessions 1791 received may not be the intended ones, the destination where media is 1792 sent to may not be the expected one, any of the parameters of the 1793 session may be incorrect, or the media security may be compromised. 1794 It is up to the endpoint to make a sensible decision taking into 1795 account the security risks of the application and the user 1796 preferences and may decide to ask the user whether or not to accept 1797 the session. 1799 One transport that can be used to distribute session descriptions is 1800 the SAP. SAP provides both encryption and authentication mechanisms, 1801 but due to the nature of session announcements it is likely that 1802 there are many occasions where the originator of a session 1803 announcement cannot be authenticated because the originator is 1804 previously unknown to the receiver of the announcement and because no 1805 common public key infrastructure is available. 1807 On receiving a session description over an unauthenticated transport 1808 mechanism or from an untrusted party, software parsing the session 1809 should take a few precautions. Session descriptions contain 1810 information required to start software on the receiver's system. 1811 Software that parses a session description MUST NOT be able to start 1812 other software except that which is specifically configured as 1813 appropriate software to participate in multimedia sessions. It is 1814 normally considered inappropriate for software parsing a session 1815 description to start, on a user's system, software that is 1816 appropriate to participate in multimedia sessions, without the user 1817 first being informed that such software will be started and giving 1818 the user's consent. Thus, a session description arriving by session 1819 announcement, email, session invitation, or WWW page MUST NOT deliver 1820 the user into an interactive multimedia session unless the user has 1821 explicitly pre-authorised such action. As it is not always simple to 1822 tell whether or not a session is interactive, applications that are 1823 unsure should assume sessions are interactive. 1825 In this specification, there are no attributes that would allow the 1826 recipient of a session description to be informed to start multimedia 1827 tools in a mode where they default to transmitting. Under some 1828 circumstances it might be appropriate to define such attributes. If 1829 this is done, an application parsing a session description containing 1830 such attributes SHOULD either ignore them or inform the user that 1831 joining this session will result in the automatic transmission of 1832 multimedia data. The default behaviour for an unknown attribute is 1833 to ignore it. 1835 In certain environments, it has become common for intermediary 1836 systems to intercept and analyse session descriptions contained 1837 within other signalling protocols. This is done for a range of 1838 purposes, including but not limited to opening holes in firewalls to 1839 allow media streams to pass, or to mark, prioritize, or block traffic 1840 selectively. In some cases, such intermediary systems may modify the 1841 session description, for example, to have the contents of the session 1842 description match NAT bindings dynamically created. These behaviours 1843 are NOT RECOMMENDED unless the session description is conveyed in 1844 such a manner that allows the intermediary system to conduct proper 1845 checks to establish the authenticity of the session description, and 1846 the authority of its source to establish such communication sessions. 1847 SDP by itself does not include sufficient information to enable these 1848 checks: they depend on the encapsulating protocol (e.g., SIP or 1849 RTSP). 1851 Use of the "k=" line poses a significant security risk, since it 1852 conveys session encryption keys in the clear. SDP MUST NOT be used 1853 to convey key material, unless it can be guaranteed that the channel 1854 over which the SDP is delivered is both private and authenticated. 1855 Moreover, the "k=" line provides no way to indicate or negotiate 1856 cryptographic key algorithms. As it provides for only a single 1857 symmetric key, rather than separate keys for confidentiality and 1858 integrity, its utility is severely limited. The use of the "k=" line 1859 is NOT RECOMMENDED, as discussed in Section 5.12. 1861 8. IANA Considerations 1863 8.1. The "application/sdp" Media Type 1865 One media type registration from [RFC4566] is to be updated, as 1866 defined below. 1868 To: ietf-types@iana.org 1869 Subject: Registration of media type "application/sdp" 1871 Type name: application 1873 Subtype name: sdp 1875 Required parameters: None. 1877 Optional parameters: None. 1879 Encoding considerations: 1880 SDP files are primarily UTF-8 format text. The "a=charset:" 1881 attribute may be used to signal the presence of other character 1882 sets in certain parts of an SDP file (see Section 6 of RFC 1883 XXXX). Arbitrary binary content cannot be directly 1884 represented in SDP. 1886 Security considerations: 1887 See Section 7 of RFC XXXX. 1889 Interoperability considerations: 1890 See RFC XXXX. 1892 Published specification: 1893 See RFC XXXX. 1895 Applications which use this media type: 1896 Voice over IP, video teleconferencing, streaming media, instant 1897 messaging, among others. See also Section 3 of RFC XXXX. 1899 Additional information: 1901 Magic number(s): None. 1902 File extension(s): The extension ".sdp" is commonly used. 1903 Macintosh File Type Code(s): "sdp " 1905 Person & email address to contact for further information: 1906 IETF MMUSIC working group 1908 Intended usage: COMMON 1910 Author/Change controller: 1911 Authors of RFC XXXX 1912 IETF MMUSIC working group delegated from the IESG 1914 8.2. Registration of Parameters 1916 There are seven field names that are registered with IANA. Using the 1917 terminology in the SDP specification Backus-Naur Form (BNF), they are 1918 "media", "proto", "fmt", "att-field", "bwtype", "nettype", and 1919 "addrtype". 1921 The contact address for all parameters registered below is: 1923 IETF MMUSIC working group 1925 8.2.1. Media Types ("media") 1927 The set of media types is intended to be small and SHOULD NOT be 1928 extended except under rare circumstances. The same rules should 1929 apply for media names as for top-level media types, and where 1930 possible the same name should be registered for SDP as for MIME. For 1931 media other than existing top-level media types, a Standards Track 1932 RFC MUST be produced for a new top-level media type to be registered, 1933 and the registration MUST provide good justification why no existing 1934 media name is appropriate (the "Standards Action" policy of 1935 [RFC5226]. 1937 This memo registers the media types "audio", "video", "text", 1938 "application", and "message". 1940 Note: The media types "control" and "data" were listed as valid in an 1941 early version of this specification (RFC 2327); however, their 1942 semantics were never fully specified and they are not widely used. 1943 These media types have been removed in this specification, although 1944 they still remain valid media type capabilities for a SIP user agent 1945 as defined in [RFC3840]. If these media types are considered useful 1946 in the future, a Standards Track RFC MUST be produced to document 1947 their use. Until that is done, applications SHOULD NOT use these 1948 types and SHOULD NOT declare support for them in SIP capabilities 1949 declarations (even though they exist in the registry created by 1950 [RFC3840]). 1952 8.2.2. Transport Protocols ("proto") 1954 The "proto" field describes the transport protocol used. This SHOULD 1955 reference a standards-track protocol RFC. This memo registers three 1956 values: "RTP/AVP" is a reference to [RFC3550] used under the RTP 1957 Profile for Audio and Video Conferences with Minimal Control 1958 [RFC3551] running over UDP/IP, "RTP/SAVP" is a reference to the 1959 Secure Real-time Transport Protocol [RFC3711], and "udp" indicates an 1960 unspecified protocol over UDP. 1962 If other RTP profiles are defined in the future, their "proto" name 1963 SHOULD be specified in the same manner. For example, an RTP profile 1964 whose short name is "XYZ" would be denoted by a "proto" field of 1965 "RTP/XYZ". 1967 New transport protocols SHOULD be registered with IANA. 1968 Registrations MUST reference an RFC describing the protocol. Such an 1969 RFC MAY be Experimental or Informational, although it is preferable 1970 that it be Standards Track. Registrations MUST also define the rules 1971 by which their "fmt" namespace is managed (see below). 1973 8.2.3. Media Formats ("fmt") 1975 Each transport protocol, defined by the "proto" field, has an 1976 associated "fmt" namespace that describes the media formats that may 1977 be conveyed by that protocol. Formats cover all the possible 1978 encodings that could be transported in a multimedia session. 1980 RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST 1981 use the payload type number as their "fmt" value. If the payload 1982 type number is dynamically assigned by this session description, an 1983 additional "rtpmap" attribute MUST be included to specify the format 1984 name and parameters as defined by the media type registration for the 1985 payload format. It is RECOMMENDED that other RTP profiles that are 1986 registered (in combination with RTP) as SDP transport protocols 1987 specify the same rules for the "fmt" namespace. 1989 For the "udp" protocol, new formats SHOULD be registered. Use of an 1990 existing media subtype for the format is encouraged. If no media 1991 subtype exists, it is RECOMMENDED that a suitable one be registered 1992 through the IETF process [RFC6838] by production of, or reference to, 1993 a standards-track RFC that defines the transport protocol for the 1994 format. 1996 For other protocols, formats MAY be registered according to the rules 1997 of the associated "proto" specification. 1999 Registrations of new formats MUST specify which transport protocols 2000 they apply to. 2002 8.2.4. Attribute Names ("att-field") 2004 8.2.4.1. New Attributes 2006 Attribute field names ("att-field") MUST be registered with IANA and 2007 documented, because of noticeable issues due to conflicting 2008 attributes under the same name. Unknown attributes in SDP are simply 2009 ignored, but conflicting ones that fragment the protocol are a 2010 serious problem. 2012 New attribute registrations are accepted according to the 2013 "Specification Required" policy of [RFC5226], provided that the 2014 specification includes the following information: 2016 o Contact Name. 2018 o Contact Email Address. 2020 o Attribute Name: The name of the attribute that will appear in 2021 SDP). This MUST conform to the definition of . 2023 o Attribute Syntax: For a value attribute (see clause 5.13), an ABNF 2024 definition of the attribute value syntax (See 2025 Section Section 9) MUST be provided. The syntax MUST follow the 2026 rule form as per Section 2.2 of [RFC5234]. This SHALL define the 2027 allowable values that the attribute might take. It MAY also 2028 define an extension method for the addition of future values. For 2029 a property attribute, the ABNF definition is omitted as the 2030 property attribute takes no values. 2032 o Attribute Semantics: For a value attribute, a semantic description 2033 of the values that the attribute might take MUST be provided. The 2034 usage of a property attribute is described under purpose below. 2036 o Attribute Value: The name of an ABNF syntax rule defining the 2037 syntax of the value. Absence of a rule name indicates that the 2038 attribute takes no values. Enclosing the rule name in "[" and "]" 2039 indicates that a value is optional. 2041 o Usage Level: Usage level(s) of the attribute. One or more of: 2042 session, media, source, dcsa, dcsa(subprotocol). For a definition 2043 of source level attributes, see [RFC5576]. For a definition of 2044 dcsa attributes see: [I-D.ietf-mmusic-data-channel-sdpneg]. 2046 o Charset Dependent: Whether the attribute value is subject to the 2047 charset attribute or not (Yes/No). 2049 o Purpose: An explanation of the purpose and usage of the attribute. 2051 o O/A Procedures: Offer/Answer procedures as explained in [RFC3264]. 2053 o Mux Category: Indication of which multiplexing "category" 2054 [I-D.ietf-mmusic-sdp-mux-attributes] an attribute is associated 2055 with. 2057 o Reference: A reference to the specification defining the 2058 attribute. 2060 The above is the minimum that IANA will accept. Attributes that are 2061 expected to see widespread use and interoperability SHOULD be 2062 documented with a standards-track RFC that specifies the attribute 2063 more precisely. 2065 Submitters of registrations should ensure that the specification is 2066 in the spirit of SDP attributes, most notably that the attribute is 2067 platform independent in the sense that it makes no implicit 2068 assumptions about operating systems and does not name specific pieces 2069 of software in a manner that might inhibit interoperability. 2071 Submitters of registrations should also carefully choose the 2072 attribute usage level. They should not choose only "session" when 2073 the attribute can have different values when media is disaggregated, 2074 i.e., when each m= section has its own IP address on a different 2075 endpoint. In that case the attribute type chosen should be "session, 2076 media". The default rule is that for all new SDP attributes that can 2077 occur both in session and media level, the media level overrides the 2078 session level. When this is not the case for a new SDP attribute, it 2079 MUST be explicitly stated. 2081 IANA has registered the initial set of attribute names ("att-field" 2082 values), with definitions as in Section 6 of this memo (these 2083 definitions replace those in [RFC4566]). 2085 8.2.4.2. Updates to Existing Attributes 2087 Updated attribute registrations are accepted according to the 2088 "Specification Required" policy of [RFC5226], provided that the 2089 specification updating the attribute (for example, by adding a new 2090 value) considers the registration information items from 2091 Section Section 8.2.4.1 according to the following bullets: 2093 o Contact Name: A name MUST be provided. 2095 o Contact Email Address: An email address MUST be provided. 2097 o Attribute Name: MUST be provided and MUST NOT be changed. 2098 Otherwise it is a new attribute. 2100 o Attribute Syntax: The existing rule syntax with the syntax 2101 extensions MUST be provided if there is a change to the syntax. A 2102 revision to an existing attribute usage MAY extend the syntax of 2103 an attribute, but MUST be backward compatible. 2105 o Attribute Semantics: A semantic description of new additional 2106 attributes values or a semantic extension of existing values. 2107 Existing attribute values semantics MUST only be extended in a 2108 backward compatible manner. 2110 o Usage Level: Updates MAY only add additional levels. 2112 o Charset Dependent: MUST NOT be changed. 2114 o Purpose: MAY be extended according to the updated usage. 2116 o O/A Procedures: MAY be updated in a backward compatible manner 2117 and/or it applies to a new usage level only. 2119 o Mux Category: No change unless from TBD to another value. It MAY 2120 also change if 'media' level is being added to the definition of 2121 an attribute that previously did not include it. 2123 o Reference: A new reference MUST be provided. 2125 Items SHOULD be omitted if there is no impact to them as a result of 2126 the attribute update. 2128 8.2.5. Bandwidth Specifiers ("bwtype") 2130 A proliferation of bandwidth specifiers is strongly discouraged. 2132 New bandwidth specifiers ("bwtype" fields) MUST be registered with 2133 IANA. The submission MUST reference a standards-track RFC specifying 2134 the semantics of the bandwidth specifier precisely, and indicating 2135 when it should be used, and why the existing registered bandwidth 2136 specifiers do not suffice. 2138 IANA has registered the bandwidth specifiers "CT" and "AS" with 2139 definitions as in Section 5.8 of this memo (these definitions update 2140 those in [RFC4566]). 2142 8.2.6. Network Types ("nettype") 2144 New network types (the "nettype" field) MUST be registered with IANA 2145 if SDP needs to be used in the context of non-Internet environments. 2146 The registration is subject to the RFC Required - RFC publication 2147 policy of [RFC5226]. Although these are not normally the preserve of 2148 IANA, there may be circumstances when an Internet application needs 2149 to interoperate with a non-Internet application, such as when 2150 gatewaying an Internet telephone call into the Public Switched 2151 Telephone Network (PSTN). The number of network types should be 2152 small and should be rarely extended. A new network type cannot be 2153 registered without registering at least one address type to be used 2154 with that network type. A new network type registration MUST 2155 reference an RFC that gives details of the network type and address 2156 type(s) and specifies how and when they would be used. 2158 IANA has registered the network type "IN" to represent the Internet, 2159 with definition as in Sections 5.2 and 5.7 of this memo (these 2160 definitions update those in [RFC4566]). 2162 8.2.7. Address Types ("addrtype") 2164 New address types ("addrtype") MUST be registered with IANA. The 2165 registration is subject to the RFC Required - RFC publication policy 2166 of [RFC5226]. An address type is only meaningful in the context of a 2167 network type, and any registration of an address type MUST specify a 2168 registered network type or be submitted along with a network type 2169 registration. A new address type registration MUST reference an RFC 2170 giving details of the syntax of the address type. Address types are 2171 not expected to be registered frequently. 2173 IANA has registered the address types "IP4" and "IP6" with 2174 definitions as in Sections 5.2 and 5.7 of this memo (these 2175 definitions update those in [RFC4566]). 2177 8.2.8. Registration Procedure 2179 In the RFC documentation that registers SDP "media", "proto", "fmt", 2180 "bwtype", "nettype", and "addrtype" fields, the authors MUST include 2181 the following information for IANA to place in the appropriate 2182 registry: 2184 o contact name, email address, and telephone number 2186 o name being registered (as it will appear in SDP) 2188 o long-form name in English 2190 o type of name ("media", "proto", "fmt", "bwtype", "nettype", or 2191 "addrtype") 2193 o a one-paragraph explanation of the purpose of the registered name 2195 o a reference to the specification for the registered name (this 2196 will typically be an RFC number) 2198 In the case of a new addrtype registration, the author has to check 2199 whether the new address type is usable with the existing network 2200 types. If yes, the "nettype" registry MUST be updated accordingly. 2202 In the case of a new nettype registration, the author MUST specify 2203 the usable address type(s). 2205 IANA may refer any registration to the IESG for review, and may 2206 request revisions to be made before a registration will be made. 2208 8.3. Encryption Key Access Methods 2210 The IANA previously maintained a table of SDP encryption key access 2211 method ("enckey") names. This table is obsolete, since the "k=" line 2212 is not extensible. New registrations MUST NOT be accepted. 2214 8.4. Reorganization of the nettype Registry 2216 This document adds a new column in the "nettype" registry with the 2217 title "Usable addrtype Values" and updates the "nettype" registry as 2218 follows: 2220 -------------------------------------------------------------------- 2221 |Type | SDP Name | Usable addrtype Values | Reference | 2222 -------------------------------------------------------------------- 2223 |nettype | IN | IP4, IP6 | [RFC4566] | 2224 |nettype | TN | RFC2543 | [RFC2848] | 2225 |nettype | ATM | NSAP, GWID, E164 | [RFC3108] | 2226 |nettype | PSTN | E164 | [RFC7195] | 2227 -------------------------------------------------------------------- 2229 Note that both [RFC7195] and [RFC3108] registered "E164" as an 2230 address type, although [RFC7195] mentions that the "E164" address 2231 type has a different context for ATM and PSTN networks. 2233 8.5. Reorganization of the att-field Registries 2235 This document combines all of the (currently) five "att-field" 2236 registries into one registry called "att-field" registry, and updates 2237 the columns to reflect the name, usage level(s), charset dependency 2238 and reference. As such IANA is requested to create a new combined 2239 registry using the following columns: 2241 Name | Usage Level | Dependent on Charset? | Mux Category | Reference 2243 The "Name" column reflects the attribute name (as it will appear in 2244 the SDP). The "Usage Level" column MUST indicate one or more of the 2245 following: session, media, source, dcsa and dcsa(subprotocol). The 2246 "Dependent on Charset?" column MUST indicate "Yes" or "No" depending 2247 on whether the attribute value is subject to the charset attribute. 2248 The "Mux Category" column MUST indicate one of the following 2249 categories: NORMAL, NOT RECOMMENDED, IDENTICAL, SUM, TRANSPORT, 2250 INHERIT, IDENTICAL-PER-PT, SPECIAL or TBD as defined by 2251 [I-D.ietf-mmusic-sdp-mux-attributes]. Finally, the "Reference" 2252 column indicates the specification(s) where the attribute is defined. 2254 For example, the attribute "setup" which is defined for both session 2255 and media level, will be listed in the new registry as follows: 2257 Name | Usage Level | Dependent on Charset?|Mux Category| Reference | 2258 setup | session,media, | No |IDENTICAL | [RFC4145] | 2259 | dcsa,dcsa(msrp)| | | [RFC6135] | 2260 | | | | [I-D.mmusic 2261 | | | |-msrp-usage- 2262 | | | |data-channel 2263 | | | |] | 2265 9. SDP Grammar 2267 This section provides an Augmented BNF grammar for SDP. ABNF is 2268 defined in [RFC5234] and [RFC7405]. 2270 ; SDP Syntax 2271 session-description = proto-version 2272 origin-field 2273 session-name-field 2274 [information-field] 2275 [uri-field] 2276 *email-field 2277 *phone-field 2278 [connection-field] 2279 *bandwidth-field 2280 1*time-field 2281 [key-field] 2282 *attribute-field 2283 *media-description 2285 proto-version = %s"v" "=" 1*DIGIT CRLF 2286 ;this memo describes version 0 2288 origin-field = %s"o" "=" username SP sess-id SP sess-version SP 2289 nettype SP addrtype SP unicast-address CRLF 2291 session-name-field = %s"s" "=" text CRLF 2293 information-field = %s"i" "=" text CRLF 2295 uri-field = %s"u" "=" uri CRLF 2297 email-field = %s"e" "=" email-address CRLF 2298 phone-field = %s"p" "=" phone-number CRLF 2300 connection-field = %s"c" "=" nettype SP addrtype SP 2301 connection-address CRLF 2302 ;a connection field must be present 2303 ;in every media description or at the 2304 ;session-level 2306 bandwidth-field = %s"b" "=" bwtype ":" bandwidth CRLF 2308 time-field = %s"t" "=" start-time SP stop-time 2309 *(CRLF repeat-fields) CRLF 2310 [zone-adjustments CRLF] 2312 repeat-fields = %s"r" "=" repeat-interval SP typed-time 2313 1*(SP typed-time) 2315 zone-adjustments = %s"z" "=" time SP ["-"] typed-time 2316 *(SP time SP ["-"] typed-time) 2318 key-field = %s"k" "=" key-type CRLF 2320 attribute-field = %s"a" "=" attribute CRLF 2322 media-description = media-field 2323 [information-field] 2324 *connection-field 2325 *bandwidth-field 2326 [key-field] 2327 *attribute-field 2329 media-field = %s"m" "=" media SP port ["/" integer] 2330 SP proto 1*(SP fmt) CRLF 2332 ; sub-rules of 'o=' 2333 username = non-ws-string 2334 ;pretty wide definition, but doesn't 2335 ;include space 2337 sess-id = 1*DIGIT 2338 ;should be unique for this username/host 2340 sess-version = 1*DIGIT 2342 nettype = token 2343 ;typically "IN" 2345 addrtype = token 2346 ;typically "IP4" or "IP6" 2348 ; sub-rules of 'u=' 2349 uri = URI-reference 2350 ; see RFC 3986 2352 ; sub-rules of 'e=', see RFC 5322 for definitions 2353 email-address = address-and-comment / dispname-and-address 2354 / addr-spec 2355 address-and-comment = addr-spec 1*SP "(" 1*email-safe ")" 2356 dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">" 2358 ; sub-rules of 'p=' 2359 phone-number = phone *SP "(" 1*email-safe ")" / 2360 1*email-safe "<" phone ">" / 2361 phone 2363 phone = ["+"] DIGIT 1*(SP / "-" / DIGIT) 2365 ; sub-rules of 'c=' 2366 connection-address = multicast-address / unicast-address 2368 ; sub-rules of 'b=' 2369 bwtype = token 2371 bandwidth = 1*DIGIT 2373 ; sub-rules of 't=' 2374 start-time = time / "0" 2376 stop-time = time / "0" 2378 time = POS-DIGIT 9*DIGIT 2379 ; Decimal representation of NTP time in 2380 ; seconds since 1900. The representation 2381 ; of NTP time is an unbounded length field 2382 ; containing at least 10 digits. Unlike the 2383 ; 64-bit representation used elsewhere, time 2384 ; in SDP does not wrap in the year 2036. 2386 ; sub-rules of 'r=' and 'z=' 2387 repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] 2389 typed-time = 1*DIGIT [fixed-len-time-unit] 2391 fixed-len-time-unit = %s"d" / %s"h" / %s"m" / %s"s" 2392 ; NOTE: These units are case-sensitive. 2394 ; sub-rules of 'k=' 2395 key-type = %s"prompt" / 2396 %s"clear:" text / 2397 %s"base64:" base64 / 2398 %s"uri:" uri 2399 ; NOTE: These names are case-sensitive. 2401 base64 = *base64-unit [base64-pad] 2402 base64-unit = 4base64-char 2403 base64-pad = 2base64-char "==" / 3base64-char "=" 2404 base64-char = ALPHA / DIGIT / "+" / "/" 2406 ; sub-rules of 'a=' 2407 attribute = (att-field ":" att-value) / att-field 2409 att-field = token 2411 att-value = byte-string 2413 ; sub-rules of 'm=' 2414 media = token 2415 ;typically "audio", "video", "text", "image" 2416 ;or "application" 2418 fmt = token 2419 ;typically an RTP payload type for audio 2420 ;and video media 2422 proto = token *("/" token) 2423 ;typically "RTP/AVP" or "udp" 2425 port = 1*DIGIT 2427 ; generic sub-rules: addressing 2428 unicast-address = IP4-address / IP6-address / FQDN / extn-addr 2430 multicast-address = IP4-multicast / IP6-multicast / FQDN 2431 / extn-addr 2433 IP4-multicast = m1 3( "." decimal-uchar ) 2434 "/" ttl [ "/" numaddr ] 2435 ; IP4 multicast addresses may be in the 2436 ; range 224.0.0.0 to 239.255.255.255 2438 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / 2439 ("23" DIGIT ) 2441 IP6-multicast = IP6-address [ "/" numaddr ] 2442 ; IP6 address starting with FF 2444 numaddr = integer 2446 ttl = (POS-DIGIT *2DIGIT) / "0" 2448 FQDN = 4*(alpha-numeric / "-" / ".") 2449 ; fully qualified domain name as specified 2450 ; in RFC 1035 (and updates) 2452 IP4-address = b1 3("." decimal-uchar) 2454 b1 = decimal-uchar 2455 ; less than "224" 2457 IP6-address = 6( h16 ":" ) ls32 2458 / "::" 5( h16 ":" ) ls32 2459 / [ h16 ] "::" 4( h16 ":" ) ls32 2460 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 2461 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 2462 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 2463 / [ *4( h16 ":" ) h16 ] "::" ls32 2464 / [ *5( h16 ":" ) h16 ] "::" h16 2465 / [ *6( h16 ":" ) h16 ] "::" 2467 h16 = 1*4HEXDIG 2469 ls32 = ( h16 ":" h16 ) / IP4-address 2471 ; Generic for other address families 2472 extn-addr = non-ws-string 2474 ; generic sub-rules: datatypes 2475 text = byte-string 2476 ;default is to interpret this as UTF8 text. 2477 ;ISO 8859-1 requires "a=charset:ISO-8859-1" 2478 ;session-level attribute to be used 2480 byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) 2481 ;any byte except NUL, CR, or LF 2483 non-ws-string = 1*(VCHAR/%x80-FF) 2484 ;string of visible characters 2486 token-char = ALPHA / DIGIT 2487 / "!" / "#" / "$" / "%" / "&" 2488 / "'" ; (single quote) 2489 / "*" / "+" / "-" / "." / "^" / "_" 2490 / "`" ; (Grave accent) 2491 / "{" / "|" / "}" / "~" 2493 token = 1*(token-char) 2495 email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF 2496 ;any byte except NUL, CR, LF, or the quoting 2497 ;characters ()<> 2499 integer = POS-DIGIT *DIGIT 2501 zero-based-integer = "0" / integer 2503 non-zero-int-or-real = integer / non-zero-real 2505 non-zero-real = zero-based-integer "." *DIGIT POS-DIGIT 2507 ; generic sub-rules: primitives 2508 alpha-numeric = ALPHA / DIGIT 2510 POS-DIGIT = %x31-39 ; 1 - 9 2512 decimal-uchar = DIGIT 2513 / POS-DIGIT DIGIT 2514 / ("1" 2*(DIGIT)) 2515 / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) 2516 / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) 2518 ; external references: 2519 ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 5234 2520 ; URI-reference: from RFC 3986 2521 ; addr-spec: from RFC 5322 2523 10. Summary of Changes from RFC 4566 2525 The ABNF rule for IP6-address has been corrected. As a result, the 2526 ABNF rule for IP6-multicast has changed, and the (now unused) rules 2527 for hexpart, hexseq, and hex4 have been removed. 2529 IP4 unicast and multicast addresses in the example SDP descriptions 2530 have been revised per RFCs 5735 and 5771. 2532 Text in Section 5.2 has been revised to clarify the use of local 2533 addresses in case of ICE-like SDP extensions. 2535 Normative and informative references have been updated. 2537 The text regarding the session vs. media-level attribute usage has 2538 been clarified. 2540 The case-insensitivity rules from RFC 4855 have been included in this 2541 document. 2543 11. Acknowledgements 2545 Many people in the IETF Multiparty Multimedia Session Control 2546 (MMUSIC) working group have made comments and suggestions 2547 contributing to this document. 2549 12. References 2551 12.1. Normative References 2553 [I-D.ietf-mmusic-data-channel-sdpneg] 2554 Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., 2555 and J. Marcon, "SDP-based Data Channel Negotiation", 2556 draft-ietf-mmusic-data-channel-sdpneg-12 (work in 2557 progress), March 2017. 2559 [I-D.ietf-mmusic-sdp-mux-attributes] 2560 Nandakumar, S., "A Framework for SDP Attributes when 2561 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 2562 (work in progress), December 2016. 2564 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2565 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 2566 . 2568 [RFC1035] Mockapetris, P., "Domain names - implementation and 2569 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2570 November 1987, . 2572 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2573 Requirement Levels", BCP 14, RFC 2119, 2574 DOI 10.17487/RFC2119, March 1997, 2575 . 2577 [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration 2578 Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978, 2579 October 2000, . 2581 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2582 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2583 2003, . 2585 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2586 Resource Identifier (URI): Generic Syntax", STD 66, 2587 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2588 . 2590 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2591 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2592 July 2006, . 2594 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2595 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 2596 . 2598 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2599 IANA Considerations Section in RFCs", RFC 5226, 2600 DOI 10.17487/RFC5226, May 2008, 2601 . 2603 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2604 Specifications: ABNF", STD 68, RFC 5234, 2605 DOI 10.17487/RFC5234, January 2008, 2606 . 2608 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2609 Media Attributes in the Session Description Protocol 2610 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 2611 . 2613 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 2614 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 2615 September 2009, . 2617 [RFC5890] Klensin, J., "Internationalized Domain Names for 2618 Applications (IDNA): Definitions and Document Framework", 2619 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2620 . 2622 12.2. Informative References 2624 [ITU.H332.1998] 2625 International Telecommunication Union, "H.323 extended for 2626 loosely coupled conferences", ITU Recommendation H.332, 2627 September 1998. 2629 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 2630 Protocol", RFC 2327, DOI 10.17487/RFC2327, April 1998, 2631 . 2633 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 2634 Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, 2635 October 2000, . 2637 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2638 A., Peterson, J., Sparks, R., Handley, M., and E. 2639 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2640 DOI 10.17487/RFC3261, June 2002, 2641 . 2643 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2644 with Session Description Protocol (SDP)", RFC 3264, 2645 DOI 10.17487/RFC3264, June 2002, 2646 . 2648 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2649 Jacobson, "RTP: A Transport Protocol for Real-Time 2650 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2651 July 2003, . 2653 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 2654 Video Conferences with Minimal Control", STD 65, RFC 3551, 2655 DOI 10.17487/RFC3551, July 2003, 2656 . 2658 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 2659 Modifiers for RTP Control Protocol (RTCP) Bandwidth", 2660 RFC 3556, DOI 10.17487/RFC3556, July 2003, 2661 . 2663 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2664 in Session Description Protocol (SDP)", RFC 3605, 2665 DOI 10.17487/RFC3605, October 2003, 2666 . 2668 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2669 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2670 RFC 3711, DOI 10.17487/RFC3711, March 2004, 2671 . 2673 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 2674 "Indicating User Agent Capabilities in the Session 2675 Initiation Protocol (SIP)", RFC 3840, 2676 DOI 10.17487/RFC3840, August 2004, 2677 . 2679 [RFC3890] Westerlund, M., "A Transport Independent Bandwidth 2680 Modifier for the Session Description Protocol (SDP)", 2681 RFC 3890, DOI 10.17487/RFC3890, September 2004, 2682 . 2684 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 2685 Carrara, "Key Management Extensions for Session 2686 Description Protocol (SDP) and Real Time Streaming 2687 Protocol (RTSP)", RFC 4567, DOI 10.17487/RFC4567, July 2688 2006, . 2690 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 2691 Description Protocol (SDP) Security Descriptions for Media 2692 Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, 2693 . 2695 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 2696 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 2697 . 2699 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 2700 (ICE): A Protocol for Network Address Translator (NAT) 2701 Traversal for Offer/Answer Protocols", RFC 5245, 2702 DOI 10.17487/RFC5245, April 2010, 2703 . 2705 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 2706 DOI 10.17487/RFC5322, October 2008, 2707 . 2709 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2710 Protocol (SDP) Grouping Framework", RFC 5888, 2711 DOI 10.17487/RFC5888, June 2010, 2712 . 2714 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 2715 "Network Time Protocol Version 4: Protocol and Algorithms 2716 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 2717 . 2719 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 2720 "TCP Candidates with Interactive Connectivity 2721 Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, 2722 March 2012, . 2724 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2725 Specifications and Registration Procedures", BCP 13, 2726 RFC 6838, DOI 10.17487/RFC6838, January 2013, 2727 . 2729 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 2730 RFC 7405, DOI 10.17487/RFC7405, December 2014, 2731 . 2733 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 2734 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 2735 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 2736 DOI 10.17487/RFC7656, November 2015, 2737 . 2739 [RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 2740 and M. Stiemerling, Ed., "Real-Time Streaming Protocol 2741 Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December 2742 2016, . 2744 Authors' Addresses 2746 Mark Handley 2747 University College London 2748 Department of Computer Science 2749 London WC1E 6BT 2750 UK 2752 EMail: M.Handley@cs.ucl.ac.uk 2754 Van Jacobson 2755 USA 2757 EMail: van@parc.com 2759 Colin Perkins 2760 University of Glasgow 2761 School of Computing Science 2762 University of Glasgow 2763 Glasgow G12 8QQ 2764 UK 2766 EMail: csp@csperkins.org 2767 Ali Begen 2768 Networked Media 2769 Konya 2770 Turkey 2772 EMail: ali.begen@networked.media