idnits 2.17.1 draft-ietf-mmusic-rfc4566bis-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 3, 2015) is 3096 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: 'RFC2848' is mentioned on line 2151, but not defined == Missing Reference: 'RFC3108' is mentioned on line 2156, but not defined == Missing Reference: 'RFC7195' is mentioned on line 2157, but not defined == Unused Reference: 'I-D.iana-charset-reg-procedure' is defined on line 2523, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Downref: Normative reference to an Informational draft: draft-ietf-avtext-rtp-grouping-taxonomy (ref. 'I-D.ietf-avtext-rtp-grouping-taxonomy') == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-10 -- Obsolete informational reference (is this intentional?): RFC 2327 (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 5 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 PARC 6 Expires: May 6, 2016 C. Perkins 7 University of Glasgow 8 A. Begen 9 Unaffiliated 10 November 3, 2015 12 SDP: Session Description Protocol 13 draft-ietf-mmusic-rfc4566bis-16 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 May 6, 2016. 39 Copyright Notice 41 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 37 115 6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 38 116 7. Security Considerations . . . . . . . . . . . . . . . . . . . 39 117 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 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") . . . . . . . . . . . 46 125 8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 46 126 8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 47 127 8.2.8. Registration Procedure . . . . . . . . . . . . . . . 47 128 8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 48 129 8.4. Reorganization of the nettype Registry . . . . . . . . . 48 130 8.5. Reorganization of the att-field Registries . . . . . . . 48 131 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 49 132 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 54 133 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54 134 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 135 12.1. Normative References . . . . . . . . . . . . . . . . . . 55 136 12.2. Informative References . . . . . . . . . . . . . . . . . 56 137 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 139 1. Introduction 141 When initiating multimedia teleconferences, voice-over-IP calls, 142 streaming video, or other sessions, there is a requirement to convey 143 media details, transport addresses, and other session description 144 metadata to the participants. 146 SDP provides a standard representation for such information, 147 irrespective of how that information is transported. SDP is purely a 148 format for session description -- it does not incorporate a transport 149 protocol, and it is intended to use different transport protocols as 150 appropriate, including the Session Announcement Protocol (SAP) 151 [RFC2974], Session Initiation Protocol (SIP) [RFC3261], Real Time 152 Streaming Protocol (RTSP) [RFC2326], 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 175 [I-D.ietf-avtext-rtp-grouping-taxonomy]. The terms "session" and 176 "multimedia session" are used interchangeably in this document. 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 180 "OPTIONAL" in this document are to be interpreted as described in 181 [RFC2119]. 183 3. Examples of SDP Usage 185 3.1. Session Initiation 187 The Session Initiation Protocol (SIP) [RFC3261] is an application- 188 layer control protocol for creating, modifying, and terminating 189 sessions such as Internet multimedia conferences, Internet telephone 190 calls, and multimedia distribution. The SIP messages used to create 191 sessions carry session descriptions that allow participants to agree 192 on a set of compatible media types. These session descriptions are 193 commonly formatted using SDP. When used with SIP, the offer/answer 194 model [RFC3264] provides a limited framework for negotiation using 195 SDP. 197 3.2. Streaming Media 199 The Real Time Streaming Protocol (RTSP) [RFC2326], is an application- 200 level protocol for control over the delivery of data with real-time 201 properties. RTSP provides an extensible framework to enable 202 controlled, on-demand delivery of real-time data, such as audio and 203 video. An RTSP client and server negotiate an appropriate set of 204 parameters for media delivery, partially using SDP syntax to describe 205 those parameters. 207 3.3. Email and the World Wide Web 209 Alternative means of conveying session descriptions include 210 electronic mail and the World Wide Web (WWW). For both email and WWW 211 distribution, the media type "application/sdp" is used. This enables 212 the automatic launching of applications for participation in the 213 session from the WWW client or mail reader in a standard manner. 215 Note that announcements of multicast sessions made only via email or 216 the WWW do not have the property that the receiver of a session 217 announcement can necessarily receive the session because the 218 multicast sessions may be restricted in scope, and access to the WWW 219 server or reception of email is possible outside this scope. 221 3.4. Multicast Session Announcement 223 In order to assist the advertisement of multicast multimedia 224 conferences and other multicast sessions, and to communicate the 225 relevant session setup information to prospective participants, a 226 distributed session directory may be used. An instance of such a 227 session directory periodically sends packets containing a description 228 of the session to a well-known multicast group. These advertisements 229 are received by other session directories such that potential remote 230 participants can use the session description to start the tools 231 required to participate in the session. 233 One protocol used to implement such a distributed directory is the 234 SAP [RFC2974]. SDP provides the recommended session description 235 format for such session announcements. 237 4. Requirements and Recommendations 239 The purpose of SDP is to convey information about media streams in 240 multimedia sessions to allow the recipients of a session description 241 to participate in the session. SDP is primarily intended for use in 242 an internetwork, although it is sufficiently general that it can 243 describe multimedia conferences in other network environments. Media 244 streams can be many-to-many. Sessions need not be continually 245 active. 247 Thus far, multicast-based sessions on the Internet have differed from 248 many other forms of conferencing in that anyone receiving the traffic 249 can join the session (unless the session traffic is encrypted). In 250 such an environment, SDP serves two primary purposes. It is a means 251 to communicate the existence of a session, and it is a means to 252 convey sufficient information to enable joining and participating in 253 the session. In a unicast environment, only the latter purpose is 254 likely to be relevant. 256 An SDP description includes the following: 258 o Session name and purpose 260 o Time(s) the session is active 262 o The media comprising the session 264 o Information needed to receive those media (addresses, ports, 265 formats, etc.) 267 As resources necessary to participate in a session may be limited, 268 some additional information may also be desirable: 270 o Information about the bandwidth to be used by the session 272 o Contact information for the person responsible for the session 274 In general, SDP must convey sufficient information to enable 275 applications to join a session (with the possible exception of 276 encryption keys) and to announce the resources to be used to any non- 277 participants that may need to know. (This latter feature is 278 primarily useful when SDP is used with a multicast session 279 announcement protocol.) 281 4.1. Media and Transport Information 283 An SDP description includes the following media information: 285 o The type of media (video, audio, etc.) 287 o The media transport protocol (RTP/UDP/IP, H.320, etc.) 289 o The format of the media (H.261 video, MPEG video, etc.) 290 In addition to media format and transport protocol, SDP conveys 291 address and port details. For an IP multicast session, these 292 comprise: 294 o The multicast group address for media 296 o The transport port for media 298 This address and port are the destination address and destination 299 port of the multicast stream, whether being sent, received, or both. 301 For unicast IP sessions, the following are conveyed: 303 o The remote address for media 305 o The remote transport port for media 307 The semantics of this address and port depend on the media and 308 transport protocol defined. By default, this SHOULD be the remote 309 address and remote port to which data is sent. Some media types may 310 redefine this behaviour, but this is NOT RECOMMENDED since it 311 complicates implementations (including middleboxes that must parse 312 the addresses to open Network Address Translation (NAT) or firewall 313 pinholes). 315 4.2. Timing Information 317 Sessions may be either bounded or unbounded in time. Whether or not 318 they are bounded, they may be only active at specific times. SDP can 319 convey: 321 o An arbitrary list of start and stop times bounding the session 323 o For each bound, repeat times such as "every Wednesday at 10am for 324 one hour" 326 This timing information is globally consistent, irrespective of local 327 time zone or daylight saving time (see Section 5.9). 329 4.3. Obtaining Further Information about a Session 331 A session description could convey enough information to decide 332 whether or not to participate in a session. SDP may include 333 additional pointers in the form of Uniform Resource Identifiers 334 (URIs) for more information about the session. 336 4.4. Categorisation 338 When many session descriptions are being distributed by SAP, or any 339 other advertisement mechanism, it may be desirable to filter session 340 announcements that are of interest from those that are not. SDP 341 supports a categorisation mechanism for sessions that is capable of 342 being automated (the "a=cat:" attribute; see Section 6). 344 4.5. Internationalisation 346 The SDP specification recommends the use of the ISO 10646 character 347 set in the UTF-8 encoding [RFC3629] to allow many different languages 348 to be represented. However, to assist in compact representations, 349 SDP also allows other character sets such as ISO 8859-1 to be used 350 when desired. Internationalisation only applies to free-text fields 351 (session name and background information), and not to SDP as a whole. 353 5. SDP Specification 355 An SDP description is denoted by the media type "application/sdp" 356 (See Section 8). 358 An SDP description is entirely textual. SDP field names and 359 attribute names use only the US-ASCII subset of UTF-8, but textual 360 fields and attribute values MAY use the full ISO 10646 character set 361 in UTF-8 encoding, or some other character set defined by the 362 "a=charset:" attribute. Field and attribute values that use the full 363 UTF-8 character set are never directly compared, hence there is no 364 requirement for UTF-8 normalisation. The textual form, as opposed to 365 a binary encoding such as ASN.1 or XDR, was chosen to enhance 366 portability, to enable a variety of transports to be used, and to 367 allow flexible, text-based toolkits to be used to generate and 368 process session descriptions. However, since SDP may be used in 369 environments where the maximum permissible size of a session 370 description is limited, the encoding is deliberately compact. Also, 371 since announcements may be transported via very unreliable means or 372 damaged by an intermediate caching server, the encoding was designed 373 with strict order and formatting rules so that most errors would 374 result in malformed session announcements that could be detected 375 easily and discarded. This also allows rapid discarding of encrypted 376 session announcements for which a receiver does not have the correct 377 key. 379 An SDP description consists of a number of lines of text of the form: 381 = 383 where MUST be exactly one case-significant character and 384 is structured text whose format depends on . In 385 general, is either a number of fields delimited by a single 386 space character or a free format string, and is case-significant 387 unless a specific field defines otherwise. Whitespace MUST NOT be 388 used on either side of the "=" sign. 390 An SDP description consists of a session-level section followed by 391 zero or more media-level sections. The session-level part starts 392 with a "v=" line and continues to the first media-level section (or 393 the end of the whole description, whichever comes first). Each 394 media-level section starts with an "m=" line and continues to the 395 next media-level section or the end of the whole session description 396 - whichever comes first. In general, session-level values are the 397 default for all media unless overridden by an equivalent media-level 398 value. 400 Some lines in each description are REQUIRED and some are OPTIONAL, 401 but all MUST appear in exactly the order given here (the fixed order 402 greatly enhances error detection and allows for a simple parser). 403 OPTIONAL items are marked with a "*". 405 Session description 406 v= (protocol version) 407 o= (originator and session identifier) 408 s= (session name) 409 i=* (session information) 410 u=* (URI of description) 411 e=* (email address) 412 p=* (phone number) 413 c=* (connection information -- not required if included in 414 all media descriptions) 415 b=* (zero or more bandwidth information lines) 416 One or more time descriptions ("t=" and "r=" lines; see below) 417 z=* (time zone adjustments) 418 k=* (encryption key) 419 a=* (zero or more session attribute lines) 420 Zero or more media descriptions 422 Time description 423 t= (time the session is active) 424 r=* (zero or more repeat times) 426 Media description, if present 427 m= (media name and transport address) 428 i=* (media title) 429 c=* (connection information -- optional if included at 430 session level) 431 b=* (zero or more bandwidth information lines) 432 k=* (encryption key) 433 a=* (zero or more media attribute lines) 435 The set of type letters is deliberately small and not intended to be 436 extensible -- an SDP parser MUST completely ignore any session 437 description that contains a type letter that it does not understand. 438 The attribute mechanism ("a=" described below) is the primary means 439 for extending SDP and tailoring it to particular applications or 440 media. Some attributes (the ones listed in Section 6 of this memo) 441 have a defined meaning, but others may be added on an application-, 442 media-, or session-specific basis. An SDP parser MUST ignore any 443 attribute it doesn't understand. 445 An SDP description may contain URIs that reference external content 446 in the "u=", "k=", and "a=" lines. These URIs may be dereferenced in 447 some cases, making the session description non-self- contained. 449 The connection ("c=") information in the session-level section 450 applies to all the media of that session unless overridden by 451 connection information in the media description. For instance, in 452 the example below, each audio media description behaves as if it were 453 given a "c=IN IP4 233.252.0.2". 455 An example SDP description is: 457 v=0 458 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 459 s=SDP Seminar 460 i=A Seminar on the session description protocol 461 u=http://www.example.com/seminars/sdp.pdf 462 e=j.doe@example.com (Jane Doe) 463 c=IN IP4 233.252.0.2 464 t=2873397496 2873404696 465 a=recvonly 466 m=audio 49170 RTP/AVP 0 467 m=audio 49180 RTP/AVP 0 468 m=video 51372 RTP/AVP 99 469 c=IN IP4 233.252.0.1/127 470 a=rtpmap:99 h263-1998/90000 472 Text fields such as the session name and information are octet 473 strings that may contain any octet with the exceptions of 0x00 (Nul), 474 0x0a (ASCII newline), and 0x0d (ASCII carriage return). The sequence 475 CRLF (0x0d0a) is used to end a record, although parsers SHOULD be 476 tolerant and also accept records terminated with a single newline 477 character. If the "a=charset" attribute is not present, these octet 478 strings MUST be interpreted as containing ISO-10646 characters in 479 UTF-8 encoding (the presence of the "a=charset" attribute may force 480 some fields to be interpreted differently). 482 A session description can contain domain names in the "o=", "u=", 483 "e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply 484 with [RFC1034], [RFC1035]. Internationalised domain names (IDNs) 485 MUST be represented using the ASCII Compatible Encoding (ACE) form 486 defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or 487 any other encoding (this requirement is for compatibility with 488 [RFC2327] and other early SDP-related standards, which predate the 489 development of internationalised domain names). 491 5.1. Protocol Version ("v=") 493 v=0 495 The "v=" line gives the version of the Session Description Protocol. 496 This memo defines version 0. There is no minor version number. 498 5.2. Origin ("o=") 500 o= 501 503 The "o=" line gives the originator of the session (her username and 504 the address of the user's host) plus a session identifier and version 505 number: 507 is the user's login on the originating host, or it is "-" 508 if the originating host does not support the concept of user IDs. 509 The MUST NOT contain spaces. 511 is a numeric string such that the tuple of , 512 , , , and forms a 513 globally unique identifier for the session. The method of allocation is up to the creating tool, but it has been 515 suggested that a Network Time Protocol (NTP) format timestamp be 516 used to ensure uniqueness [RFC5905]. 518 is a version number for this session description. 519 Its usage is up to the creating tool, so long as is 520 increased when a modification is made to the session data. Again, 521 it is RECOMMENDED that an NTP format timestamp is used. 523 is a text string giving the type of network. Initially 524 "IN" is defined to have the meaning "Internet", but other values 525 MAY be registered in the future (see Section 8). 527 is a text string giving the type of the address that 528 follows. Initially "IP4" and "IP6" are defined, but other values 529 MAY be registered in the future (see Section 8). 531 is an address of the machine from which the 532 session was created. For an address type of IP4, this is either a 533 fully qualified domain name of the machine or the dotted-decimal 534 representation of an IP version 4 address of the machine. For an 535 address type of IP6, this is either a fully qualified domain name 536 of the machine or the compressed textual representation of an IP 537 version 6 address of the machine. For both IP4 and IP6, the fully 538 qualified domain name is the form that SHOULD be given unless this 539 is unavailable, in which case a globally unique address MAY be 540 substituted. Unless an SDP extension for NAT traversal is used 541 (e.g., ICE [RFC5245], ICE TCP [RFC6544]), a local IP address MUST 542 NOT be used in any context where the SDP description might leave 543 the scope in which the address is meaningful (for example, a local 544 address MUST NOT be included in an application-level referral that 545 might leave the scope). 547 In general, the "o=" line serves as a globally unique identifier for 548 this version of this session description, and the subfields excepting 549 the version taken together identify the session irrespective of any 550 modifications. 552 For privacy reasons, it is sometimes desirable to obfuscate the 553 username and IP address of the session originator. If this is a 554 concern, an arbitrary and private MAY be 555 chosen to populate the "o=" line, provided that these are selected in 556 a manner that does not affect the global uniqueness of the field. 558 5.3. Session Name ("s=") 560 s= 562 The "s=" line is the textual session name. There MUST be one and 563 only one "s=" line per session description. The "s=" line MUST NOT 564 be empty and SHOULD contain ISO 10646 characters (but see also the 565 "a=charset" attribute). If a session has no meaningful name, the 566 value "s= " SHOULD be used (i.e., a single space as the session 567 name). 569 5.4. Session Information ("i=") 571 i= 573 The "i=" line provides textual information about the session. There 574 MUST be at most one session-level "i=" line per session description, 575 and at most one "i=" line per media description/definition. Unless a 576 media level "i="" line is used, the session-level "i="" line applies 577 to that media description. If the "a=charset" attribute is present, 578 it specifies the character set used in the "i=" line. If the 579 "a=charset" attribute is not present, the "i=" line MUST contain ISO 580 10646 characters in UTF-8 encoding. 582 A single "i=" line can be used for each media definition. In media 583 definitions, "i=" lines are primarily intended for labelling media 584 streams. As such, they are most likely to be useful when a single 585 session has more than one distinct media stream of the same media 586 type. An example would be two different whiteboards, one for slides 587 and one for feedback and questions. 589 The "i=" line is intended to provide a free-form human-readable 590 description of the session or the purpose of a media stream. It is 591 not suitable for parsing by automata. 593 5.5. URI ("u=") 595 u= 597 A URI is a Uniform Resource Identifier as used by WWW clients 598 [RFC3986]. The URI should be a pointer to additional information 599 about the session. This line is OPTIONAL. No more than one URI line 600 is allowed per session description. 602 5.6. Email Address and Phone Number ("e=" and "p=") 604 e= 605 p= 607 The "e=" and "p=" lines specify contact information for the person 608 responsible for the session. This is not necessarily the same person 609 that created the session description. 611 Inclusion of an email address or phone number is OPTIONAL. 613 If an email address or phone number is present, it MUST be specified 614 before the first media field. More than one email or phone line can 615 be given for a session description. 617 Phone numbers SHOULD be given in the form of an international public 618 telecommunication number (see ITU-T Recommendation E.164) preceded by 619 a "+". Spaces and hyphens may be used to split up a phone field to 620 aid readability if desired. For example: 622 p=+1 617 555-6011 624 Both email addresses and phone numbers can have an OPTIONAL free text 625 string associated with them, normally giving the name of the person 626 who may be contacted. This MUST be enclosed in parentheses if it is 627 present. For example: 629 e=j.doe@example.com (Jane Doe) 631 The alternative [RFC5322] name quoting convention is also allowed for 632 both email addresses and phone numbers. For example: 634 e=Jane Doe 636 The free text string SHOULD be in the ISO-10646 character set with 637 UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if 638 the appropriate session-level "a=charset" attribute is set. 640 5.7. Connection Data ("c=") 642 c= 644 The "c=" line contains connection data. 646 A session description MUST contain either at least one "c=" line in 647 each media description or a single "c=" line at the session level. 648 It MAY contain a single session-level "c=" line and additional "c=" 649 line(s) per media description, in which case the per-media values 650 override the session-level settings for the respective media. 652 The first sub-field ("") is the network type, which is a 653 text string giving the type of network. Initially, "IN" is defined 654 to have the meaning "Internet", but other values MAY be registered in 655 the future (see Section 8). 657 The second sub-field ("") is the address type. This allows 658 SDP to be used for sessions that are not IP based. This memo only 659 defines IP4 and IP6, but other values MAY be registered in the future 660 (see Section 8). 662 The third sub-field ("") is the connection 663 address. OPTIONAL sub-fields MAY be added after the connection 664 address depending on the value of the field. 666 When the is IP4 and IP6, the connection address is defined 667 as follows: 669 o If the session is multicast, the connection address will be an IP 670 multicast group address. If the session is not multicast, then 671 the connection address contains the unicast IP address of the 672 expected data source or data relay or data sink as determined by 673 additional attribute fields. It is not expected that unicast 674 addresses will be given in a session description that is 675 communicated by a multicast announcement, though this is not 676 prohibited. 678 o Sessions using an IP4 multicast connection address MUST also have 679 a time to live (TTL) value present in addition to the multicast 680 address. The TTL and the address together define the scope with 681 which multicast packets sent in this session will be sent. TTL 682 values MUST be in the range 0-255. Although the TTL MUST be 683 specified, its use to scope multicast traffic is deprecated; 684 applications SHOULD use an administratively scoped address 685 instead. 687 The TTL for the session is appended to the address using a slash as a 688 separator. An example is: 690 c=IN IP4 233.252.0.1/127 692 IP6 multicast does not use TTL scoping, and hence the TTL value MUST 693 NOT be present for IP6 multicast. It is expected that IP6 scoped 694 addresses will be used to limit the scope of multimedia conferences. 696 Hierarchical or layered encoding schemes are data streams where the 697 encoding from a single media source is split into a number of layers. 698 The receiver can choose the desired quality (and hence bandwidth) by 699 only subscribing to a subset of these layers. Such layered encodings 700 are normally transmitted in multiple multicast groups to allow 701 multicast pruning. This technique keeps unwanted traffic from sites 702 only requiring certain levels of the hierarchy. For applications 703 requiring multiple multicast groups, we allow the following notation 704 to be used for the connection address: 706 [/]/ 708 If the number of addresses is not given, it is assumed to be one. 709 Multicast addresses so assigned are contiguously allocated above the 710 base address, so that, for example: 712 c=IN IP4 233.252.0.1/127/3 714 would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3 715 are to be used at a TTL of 127. This is semantically identical to 716 including multiple "c=" lines in a media description: 718 c=IN IP4 233.252.0.1/127 719 c=IN IP4 233.252.0.2/127 720 c=IN IP4 233.252.0.3/127 722 Similarly, an IP6 example would be: 724 c=IN IP6 FF15::101/3 726 which is semantically equivalent to: 728 c=IN IP6 FF15::101 729 c=IN IP6 FF15::102 730 c=IN IP6 FF15::103 732 (remembering that the TTL field is not present in IP6 multicast). 734 Multiple addresses or "c=" lines MAY be specified on a per-media 735 basis only if they provide multicast addresses for different layers 736 in a hierarchical or layered encoding scheme. They MUST NOT be 737 specified for a session-level "c=" line. 739 The slash notation for multiple addresses described above MUST NOT be 740 used for IP unicast addresses. 742 5.8. Bandwidth ("b=") 744 b=: 746 This OPTIONAL line denotes the proposed bandwidth to be used by the 747 session or media. The is an alphanumeric modifier giving 748 the meaning of the figure. Two values are defined in 749 this specification, but other values MAY be registered in the future 750 (see Section 8 and [RFC3556], [RFC3890]): 752 CT If the bandwidth of a session is different from the bandwidth 753 implicit from the scope, a "b=CT:..." line SHOULD be supplied for 754 the session giving the proposed upper limit to the bandwidth used 755 (the "conference total" bandwidth). Similarly, if the bandwidth 756 of bundled media streams in an m line is different from the 757 implicit value from the scope, a "b=CT:..." line SHOULD be 758 supplied in the media level. The primary purpose of this is to 759 give an approximate idea as to whether two or more sessions (or 760 bundled media streams) can coexist simultaneously. Note that CT 761 gives a total bandwidth figure for all the media at all endpoints. 763 AS The bandwidth is interpreted to be application specific (it will 764 be the application's concept of maximum bandwidth). Normally, 765 this will coincide with what is set on the application's "maximum 766 bandwidth" control if applicable. For RTP-based applications, AS 767 gives the RTP "session bandwidth" as defined in Section 6.2 of 768 [RFC3550]. Note that AS gives a bandwidth figure for a single 769 media at a single endpoint, although there may be many endpoints 770 sending simultaneously. 772 A prefix "X-" is defined for names. This is intended for 773 experimental purposes only. For example: 775 b=X-YZ:128 777 Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers 778 SHOULD be registered with IANA in the standard namespace. SDP 779 parsers MUST ignore bandwidth fields with unknown modifiers. 780 Modifiers MUST be alphanumeric and, although no length limit is 781 given, it is recommended that they be short. 783 The is interpreted as kilobits per second by default. 784 The definition of a new modifier MAY specify that the 785 bandwidth is to be interpreted in some alternative unit (the "CT" and 786 "AS" modifiers defined in this memo use the default units). 788 5.9. Timing ("t=") 790 t= 792 The "t=" lines specify the start and stop times for a session. 793 Multiple "t=" lines MAY be used if a session is active at multiple 794 irregularly spaced times; each additional "t=" line specifies an 795 additional period of time for which the session will be active. If 796 the session is active at regular times, an "r=" line (see below) 797 should be used in addition to, and following, a "t=" line -- in which 798 case the "t=" line specifies the start and stop times of the repeat 799 sequence. 801 The first and second sub-fields give the start and stop times, 802 respectively, for the session. These values are the decimal 803 representation of Network Time Protocol (NTP) time values in seconds 804 since 1900 [RFC5905]. To convert these values to UNIX time, subtract 805 decimal 2208988800. 807 NTP timestamps are elsewhere represented by 64-bit values, which wrap 808 sometime in the year 2036. Since SDP uses an arbitrary length 809 decimal representation, this should not cause an issue (SDP 810 timestamps MUST continue counting seconds since 1900, NTP will use 811 the value modulo the 64-bit limit). 813 If the is set to zero, then the session is not bounded, 814 though it will not become active until after the . If 815 the is also zero, the session is regarded as permanent. 817 User interfaces SHOULD strongly discourage the creation of unbounded 818 and permanent sessions as they give no information about when the 819 session is actually going to terminate, and so make scheduling 820 difficult. 822 The general assumption may be made, when displaying unbounded 823 sessions that have not timed out to the user, that an unbounded 824 session will only be active until half an hour from the current time 825 or the session start time, whichever is the later. If behaviour 826 other than this is required, an end-time SHOULD be given and modified 827 as appropriate when new information becomes available about when the 828 session should really end. 830 Permanent sessions may be shown to the user as never being active 831 unless there are associated repeat times that state precisely when 832 the session will be active. 834 5.10. Repeat Times ("r=") 836 r= 838 "r=" line specifies repeat times for a session. For example, if a 839 session is active at 10am on Monday and 11am on Tuesday for one hour 840 each week for three months, then the in the 841 corresponding "t=" line would be the NTP representation of 10am on 842 the first Monday, the would be 1 week, the would be 1 hour, and the offsets would be zero and 25 844 hours. The corresponding "t=" line stop time would be the NTP 845 representation of the end of the last session three months later. By 846 default, all fields are in seconds, so the "r=" and "t=" lines might 847 be the following: 849 t=3034423619 3042462419 850 r=604800 3600 0 90000 852 To make the description more compact, times may also be given in 853 units of days, hours, or minutes. The syntax for these is a number 854 immediately followed by a single case-sensitive character. 855 Fractional units are not allowed -- a smaller unit should be used 856 instead. The following unit specification characters are allowed: 858 d - days (86400 seconds) 859 h - hours (3600 seconds) 860 m - minutes (60 seconds) 861 s - seconds (allowed for completeness) 863 Thus, the above session announcement could also have been written: 865 r=7d 1h 0 25h 867 Monthly and yearly repeats cannot be directly specified with a single 868 SDP repeat time; instead, separate "t=" lines should be used to 869 explicitly list the session times. 871 5.11. Time Zones ("z=") 873 z= .... 875 To schedule a repeated session that spans a change from daylight 876 saving time to standard time or vice versa, it is necessary to 877 specify offsets from the base time. This is required because 878 different time zones change time at different times of day, different 879 countries change to or from daylight saving time on different dates, 880 and some countries do not have daylight saving time at all. 882 Thus, in order to schedule a session that is at the same time winter 883 and summer, it must be possible to specify unambiguously by whose 884 time zone a session is scheduled. To simplify this task for 885 receivers, we allow the sender to specify the NTP time that a time 886 zone adjustment happens and the offset from the time when the session 887 was first scheduled. The "z=" line allows the sender to specify a 888 list of these adjustment times and offsets from the base time. 890 An example might be the following: 892 z=2882844526 -1h 2898848070 0 894 This specifies that at time 2882844526, the time base by which the 895 session's repeat times are calculated is shifted back by 1 hour, and 896 that at time 2898848070, the session's original time base is 897 restored. Adjustments are always relative to the specified start 898 time -- they are not cumulative. Adjustments apply to all "t=" and 899 "r=" lines in a session description. 901 If a session is likely to last several years, it is expected that the 902 session description will be modified periodically rather than 903 transmit several years' worth of adjustments in one session 904 description. 906 5.12. Encryption Keys ("k=") 908 k= 909 k=: 911 If transported over a secure and trusted channel, the Session 912 Description Protocol MAY be used to convey encryption keys. A simple 913 mechanism for key exchange is provided by the key line ("k="), 914 although this is primarily supported for compatibility with older 915 implementations and its use is NOT RECOMMENDED. Work is in progress 916 to define new key exchange mechanisms for use with SDP [RFC4567] 917 [RFC4568], and it is expected that new applications will use those 918 mechanisms. 920 A key line is permitted before the first media entry (in which case 921 it applies to all media in the session), or for each media entry as 922 required. The format of keys and their usage are outside the scope 923 of this document, and the key field provides no way to indicate the 924 encryption algorithm to be used, key type, or other information about 925 the key: this is assumed to be provided by the higher-level protocol 926 using SDP. If there is a need to convey this information within SDP, 927 the extensions mentioned previously SHOULD be used. Many security 928 protocols require two keys: one for confidentiality, another for 929 integrity. This specification does not support transfer of two keys. 931 The method indicates the mechanism to be used to obtain a usable key 932 by external means, or from the encoded encryption key given. The 933 following methods are defined: 935 k=clear: 937 The encryption key is included untransformed in this key line. 938 This method MUST NOT be used unless it can be guaranteed that 939 the SDP is conveyed over a secure channel. The encryption key 940 is interpreted as text according to the charset attribute; use 941 the "k=base64:" method to convey characters that are otherwise 942 prohibited in SDP. 944 k=base64: 946 The encryption key is included in this key line but has been 947 base64 encoded [RFC4648] because it includes characters that 948 are prohibited in SDP. This method MUST NOT be used unless it 949 can be guaranteed that the SDP is conveyed over a secure 950 channel. 952 k=uri: 954 A Uniform Resource Identifier is included in the key line. The 955 URI refers to the data containing the key, and may require 956 additional authentication before the key can be returned. When 957 a request is made to the given URI, the reply should specify 958 the encoding for the key. The URI is often an Secure Socket 959 Layer/Transport Layer Security (SSL/TLS)-protected HTTP URI 960 ("https:"), although this is not required. 962 k=prompt 964 No key is included in this SDP description, but the session or 965 media stream referred to by this key line is encrypted. The 966 user should be prompted for the key when attempting to join the 967 session, and this user-supplied key should then be used to 968 decrypt the media streams. The use of user-specified keys is 969 NOT RECOMMENDED, since such keys tend to have weak security 970 properties. 972 The key line MUST NOT be used unless it can be guaranteed that the 973 SDP is conveyed over a secure and trusted channel. An example of 974 such a channel might be SDP embedded inside an S/MIME message or a 975 TLS-protected HTTP session. It is important to ensure that the 976 secure channel is with the party that is authorised to join the 977 session, not an intermediary: if a caching proxy server is used, it 978 is important to ensure that the proxy is either trusted or unable to 979 access the SDP. 981 5.13. Attributes ("a=") 983 a= 984 a=: 986 Attributes are the primary means for extending SDP. Attributes may 987 be defined to be used as "session-level" attributes, "media-level" 988 attributes, or both. 990 A media description may have any number of attributes ("a=" lines) 991 that are media specific. These are referred to as "media-level" 992 attributes and add information about the media stream. Attribute 993 lines can also be added before the first media field; these "session- 994 level" attributes convey additional information that applies to the 995 session as a whole rather than to individual media. 997 Attribute lines may be of two forms: 999 o A property attribute is simply of the form "a=". These are 1000 binary attributes, and the presence of the attribute conveys that 1001 the attribute is a property of the session. An example might be 1002 "a=recvonly". 1004 o A value attribute is of the form "a=:". For 1005 example, a whiteboard could have the value attribute 1006 "a=orient:landscape" 1008 Attribute interpretation depends on the media tool being invoked. 1009 Thus receivers of session descriptions should be configurable in 1010 their interpretation of session descriptions in general and of 1011 attributes in particular. 1013 Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. 1015 Attribute values are octet strings, and MAY use any octet value 1016 except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute 1017 values are to be interpreted as in ISO-10646 character set with UTF-8 1018 encoding. Unlike other text fields, attribute values are NOT 1019 normally affected by the "charset" attribute as this would make 1020 comparisons against known values problematic. However, when an 1021 attribute is defined, it can be defined to be charset dependent, in 1022 which case its value should be interpreted in the session charset 1023 rather than in ISO-10646. 1025 Attributes MUST be registered with IANA (see Section 8). If an 1026 attribute is received that is not understood, it MUST be ignored by 1027 the receiver. 1029 5.14. Media Descriptions ("m=") 1031 m= ... 1033 A session description may contain a number of media descriptions. 1034 Each media description starts with an "m=" line and is terminated by 1035 either the next "m=" line or by the end of the session description. 1036 A media field has several sub-fields: 1038 is the media type. Currently defined media are "audio", 1039 "video", "text", "application", and "message", although this list 1040 may be extended in the future (see Section 8). 1042 is the transport port to which the media stream is sent. The 1043 meaning of the transport port depends on the network being used as 1044 specified in the relevant "c=" line, and on the transport protocol 1045 defined in the sub-field of the media field. Other ports 1046 used by the media application (such as the RTP Control Protocol 1047 (RTCP) port [RFC3550]) MAY be derived algorithmically from the 1048 base media port or MAY be specified in a separate attribute (for 1049 example, "a=rtcp:" as defined in [RFC3605]). 1051 If non-contiguous ports are used or if they don't follow the 1052 parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" 1053 attribute MUST be used. Applications that are requested to send 1054 media to a that is odd and where the "a=rtcp:" is present 1055 MUST NOT subtract 1 from the RTP port: that is, they MUST send the 1056 RTP to the port indicated in and send the RTCP to the port 1057 indicated in the "a=rtcp" attribute. 1059 For applications where hierarchically encoded streams are being 1060 sent to a unicast address, it may be necessary to specify multiple 1061 transport ports. This is done using a similar notation to that 1062 used for IP multicast addresses in the "c=" line: 1064 m= / ... 1066 In such a case, the ports used depend on the transport protocol. 1067 For RTP, the default is that only the even-numbered ports are used 1068 for data with the corresponding one-higher odd ports used for the 1069 RTCP belonging to the RTP session, and the 1070 denoting the number of RTP sessions. For example: 1072 m=video 49170/2 RTP/AVP 31 1074 would specify that ports 49170 and 49171 form one RTP/RTCP pair 1075 and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the 1076 transport protocol and 31 is the format (see below). If non- 1077 contiguous ports are required, they must be signalled using a 1078 separate attribute (for example, "a=rtcp:" as defined in 1079 [RFC3605]). 1081 If multiple addresses are specified in the "c=" line and multiple 1082 ports are specified in the "m=" line, a one-to-one mapping from 1083 port to the corresponding address is implied. For example: 1085 c=IN IP4 233.252.0.1/127/2 1086 m=video 49170/2 RTP/AVP 31 1088 would imply that address 233.252.0.1 is used with ports 49170 and 1089 49171, and address 233.252.0.2 is used with ports 49172 and 49173. 1091 The semantics of multiple "m=" lines using the same transport 1092 address are undefined. This implies that, unlike limited past 1093 practice, there is no implicit grouping defined by such means and 1094 an explicit grouping framework (for example, [RFC5888]) should 1095 instead be used to express the intended semantics. 1097 is the transport protocol. The meaning of the transport 1098 protocol is dependent on the address type field in the relevant 1099 "c=" line. Thus a "c=" field of IP4 indicates that the transport 1100 protocol runs over IP4. The following transport protocols are 1101 defined, but may be extended through registration of new protocols 1102 with IANA (see Section 8): 1104 * udp: denotes an unspecified protocol running over UDP. 1106 * RTP/AVP: denotes RTP [RFC3550] used under the RTP Profile for 1107 Audio and Video Conferences with Minimal Control [RFC3551] 1108 running over UDP. 1110 * RTP/SAVP: denotes the Secure Real-time Transport Protocol 1111 [RFC3711] running over UDP. 1113 The main reason to specify the transport protocol in addition to 1114 the media format is that the same standard media formats may be 1115 carried over different transport protocols even when the network 1116 protocol is the same -- a historical example is vat Pulse Code 1117 Modulation (PCM) audio and RTP PCM audio; another might be TCP/RTP 1118 PCM audio. In addition, relays and monitoring tools that are 1119 transport-protocol-specific but format-independent are possible. 1121 is a media format description. The fourth and any subsequent 1122 sub-fields describe the format of the media. The interpretation 1123 of the media format depends on the value of the sub-field. 1125 If the sub-field is "RTP/AVP" or "RTP/SAVP" the sub- 1126 fields contain RTP payload type numbers. When a list of payload 1127 type numbers is given, this implies that all of these payload 1128 formats MAY be used in the session, but the first of these formats 1129 SHOULD be used as the default format for the session. For dynamic 1130 payload type assignments the "a=rtpmap:" attribute (see Section 6) 1131 SHOULD be used to map from an RTP payload type number to a media 1132 encoding name that identifies the payload format. The "a=fmtp:" 1133 attribute MAY be used to specify format parameters (see 1134 Section 6). 1136 If the sub-field is "udp" the sub-fields MUST 1137 reference a media type describing the format under the "audio", 1138 "video", "text", "application", or "message" top-level media 1139 types. The media type registration SHOULD define the packet 1140 format for use with UDP transport. 1142 For media using other transport protocols, the field is 1143 protocol specific. Rules for interpretation of the sub- 1144 field MUST be defined when registering new protocols (see 1145 Section 8.2.2). 1147 Section 3 of [RFC4855] states that the payload format (encoding) 1148 names defined in the RTP Profile are commonly shown in upper case, 1149 while media subtype names are commonly shown in lower case. It 1150 also states that both of these names are case-insensitive in both 1151 places, similar to parameter names which are case-insensitive both 1152 in media type strings and in the default mapping to the SDP a=fmtp 1153 attribute. 1155 6. SDP Attributes 1157 The following attributes are defined. Since application writers may 1158 add new attributes as they are required, this list is not exhaustive. 1159 Registration procedures for new attributes are defined in 1160 Section 8.2.4. 1162 6.1. cat (category) 1164 Name: cat 1166 Value: cat-value 1168 Usage Level: session 1170 Charset Dependent: no 1172 Syntax: 1174 cat-value = category 1175 category = non-ws-string 1177 Example: 1179 a=cat:foo.bar 1181 This attribute gives the dot-separated hierarchical category of the 1182 session. This is to enable a receiver to filter unwanted sessions by 1183 category. There is no central registry of categories. This 1184 attribute is obsoleted. 1186 6.2. keywds (keywords) 1188 Name: keywds 1190 Value: keywds-value 1192 Usage Level: session 1194 Charset Dependent: yes 1196 Syntax: 1198 keywds-value = keywords 1199 keywords = text 1201 Example: 1203 a=keywds:SDP session description protocol 1205 Like the cat attribute, this is to assist identifying wanted sessions 1206 at the receiver. This allows a receiver to select interesting 1207 session based on keywords describing the purpose of the session; 1208 there is no central registry of keywords. Its value should be 1209 interpreted in the charset specified for the session description if 1210 one is specified, or by default in ISO 10646/UTF-8. This attribute 1211 is obsoleted. 1213 6.3. tool 1215 Name: tool 1217 Value: tool-value 1219 Usage Level: session 1221 Charset Dependent: no 1223 Syntax: 1225 tool-value = tool-name-and-version 1226 tool-name-and-version = text 1228 Example: 1230 a=tool:foobar V3.2 1232 This gives the name and version number of the tool used to create the 1233 session description. 1235 6.4. ptime (packet time) 1237 Name: ptime 1239 Value: ptime-value 1241 Usage Level: media 1243 Charset Dependent: no 1245 Syntax: 1247 ptime-value = non-zero-int-or-real 1249 Example: 1251 a=ptime:20 1253 This gives the length of time in milliseconds represented by the 1254 media in a packet. This is probably only meaningful for audio data, 1255 but may be used with other media types if it makes sense. It should 1256 not be necessary to know ptime to decode RTP or vat audio, and it is 1257 intended as a recommendation for the encoding/packetisation of audio. 1259 6.5. maxptime (maximum packet time) 1261 Name: maxptime 1263 Value: maxptime-value 1265 Usage Level: media 1267 Charset Dependent: no 1269 Syntax: 1271 maxptime-value = non-zero-int-or-real 1273 Example: 1275 a=maxptime:20 1277 This gives the maximum amount of media that can be encapsulated in 1278 each packet, expressed as time in milliseconds. The time SHALL be 1279 calculated as the sum of the time the media present in the packet 1280 represents. For frame-based codecs, the time SHOULD be an integer 1281 multiple of the frame size. This attribute is probably only 1282 meaningful for audio data, but may be used with other media types if 1283 it makes sense. Note that this attribute was introduced after 1284 [RFC2327], and non-updated implementations will ignore this 1285 attribute. 1287 6.6. rtpmap 1289 Name: rtpmap 1291 Value: rtpmap-value 1293 Usage Level: media 1295 Charset Dependent: no 1296 Syntax: 1298 rtpmap-value = payload-type SP encoding-name 1299 "/" clock-rate [ "/" encoding-params ] 1300 payload-type = zero-based-integer 1301 encoding-name = token 1302 clock-rate = integer 1303 ; do we want to define a limited range for this? 1304 encoding-params = channels 1305 ; 4566 is vague about what this can be. RFC4855 seems to be 1306 ; the authoritative source, and only allows the 1307 ; value of the media subtype "channels" parameter - the 1308 ; number of audio channels. 1309 ; Does anyone think this can be used for something else??? 1310 ; (The implication that multiple parameters might be included 1311 ; seems a misdirection - additional parameters are 1312 ; to go into a=fmtp.) 1313 ; Does anyone have an example of other parameters 1314 ; using this field? 1315 channels = integer 1316 ; Is there any reason to make this less restrictive? 1318 This attribute maps from an RTP payload type number (as used in an 1319 "m=" line) to an encoding name denoting the payload format to be 1320 used. It also provides information on the clock rate and encoding 1321 parameters. Note that the payload type number is indicated in a 1322 7-bit field, limiting the values to incusively between 0 and 127. 1324 Although an RTP profile can make static assignments of payload type 1325 numbers to payload formats, it is more common for that assignment to 1326 be done dynamically using "a=rtpmap:" attributes. As an example of a 1327 static payload type, consider u-law PCM coded single-channel audio 1328 sampled at 8 kHz. This is completely defined in the RTP Audio/Video 1329 profile as payload type 0, so there is no need for an "a=rtpmap:" 1330 attribute, and the media for such a stream sent to UDP port 49232 can 1331 be specified as: 1333 m=audio 49232 RTP/AVP 0 1335 An example of a dynamic payload type is 16-bit linear encoded stereo 1336 audio sampled at 16 kHz. If we wish to use the dynamic RTP/AVP 1337 payload type 98 for this stream, additional information is required 1338 to decode it: 1340 m=audio 49232 RTP/AVP 98 1341 a=rtpmap:98 L16/16000/2 1343 Up to one rtpmap attribute can be defined for each media format 1344 specified. Thus, we might have the following: 1346 m=audio 49230 RTP/AVP 96 97 98 1347 a=rtpmap:96 L8/8000 1348 a=rtpmap:97 L16/8000 1349 a=rtpmap:98 L16/11025/2 1351 RTP profiles that specify the use of dynamic payload types MUST 1352 define the set of valid encoding names and/or a means to register 1353 encoding names if that profile is to be used with SDP. The "RTP/AVP" 1354 and "RTP/SAVP" profiles use media subtypes for encoding names, under 1355 the top-level media type denoted in the "m=" line. In the example 1356 above, the media types are "audio/l8" and "audio/l16". 1358 For audio streams, indicates the number of 1359 audio channels. This parameter is OPTIONAL and may be omitted if the 1360 number of channels is one, provided that no additional parameters are 1361 needed. 1363 For video streams, no encoding parameters are currently specified. 1365 Additional encoding parameters MAY be defined in the future, but 1366 codec-specific parameters SHOULD NOT be added. Parameters added to 1367 an "a=rtpmap:" attribute SHOULD only be those required for a session 1368 directory to make the choice of appropriate media to participate in a 1369 session. Codec-specific parameters should be added in other 1370 attributes (for example, "a=fmtp:"). 1372 Note: RTP audio formats typically do not include information about 1373 the number of samples per packet. If a non-default (as defined in 1374 the RTP Audio/Video Profile) packetisation is required, the "ptime" 1375 attribute is used as given above. 1377 6.7. Media Direction Attributes 1379 At most one of recvonly/sendrecv/sendonly/inactive MAY appear at 1380 session level, and at most one MAY appear in each media section. 1382 If any one of these appears in a media section then it applies for 1383 that media section. If none appear in a media section then the one 1384 from session level, if any, applies to that media section. 1386 If none of the media direction attributes is present at either 1387 session level or media level, "sendrecv" SHOULD be assumed as the 1388 default for sessions that are not of the multimedia conference type 1389 "broadcast" or "H332" (see below). 1391 Within the following SDP example, the "inactive" attribute applies to 1392 audio media and the "recvonly" attribute applies to video media. 1394 v=0 1395 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 1396 s=SDP Seminar 1397 i=A Seminar on the session description protocol 1398 u=http://www.example.com/seminars/sdp.pdf 1399 e=j.doe@example.com (Jane Doe) 1400 c=IN IP4 233.252.0.1/127 1401 t=2873397496 2873404696 1402 a=inactive 1403 m=audio 49170 RTP/AVP 0 1404 m=video 51372 RTP/AVP 99 1405 a=rtpmap:99 h263-1998/90000 1406 a=recvonly 1408 6.7.1. recvonly (receive-only) 1410 Name: recvonly 1412 Value: 1414 Usage Level: session, media 1416 Charset Dependent: no 1418 Example: 1420 a=recvonly 1422 This specifies that the tools should be started in receive-only mode 1423 where applicable. Note that recvonly applies to the media only, not 1424 to any associated control protocol (e.g., an RTP-based system in 1425 recvonly mode SHOULD still send RTCP packets). 1427 6.7.2. sendrecv (send-receive) 1429 Name: sendrecv 1431 Value: 1433 Usage Level: session, media 1435 Charset Dependent: no 1436 Example: 1438 a=sendrecv 1440 This specifies that the tools should be started in send and receive 1441 mode. This is necessary for interactive multimedia conferences with 1442 tools that default to receive-only mode. 1444 6.7.3. sendonly (send-only) 1446 Name: sendonly 1448 Value: 1450 Usage Level: session, media 1452 Charset Dependent: no 1454 Example: 1456 a=sendonly 1458 This specifies that the tools should be started in send-only mode. 1459 An example may be where a different unicast address is to be used for 1460 a traffic destination than for a traffic source. In such a case, two 1461 media descriptions may be used, one sendonly and one recvonly. Note 1462 that sendonly applies only to the media, and any associated control 1463 protocol (e.g., RTCP) SHOULD still be received and processed as 1464 normal. 1466 6.7.4. inactive 1468 Name: inactive 1470 Value: 1472 Usage Level: session, media 1474 Charset Dependent: no 1476 Example: 1478 a=inactive 1480 This specifies that the tools should be started in inactive mode. 1481 This is necessary for interactive multimedia conferences where users 1482 can put other users on hold. No media is sent over an inactive media 1483 stream. Note that an RTP-based system MUST still send RTCP (if RTCP 1484 is used), even if started inactive. 1486 6.8. orient (orientation) 1488 Name: orient 1490 Value: orient-value 1492 Usage Level: media 1494 Charset Dependent: no 1496 Syntax: 1498 orient-value = portrait / landscape / seascape 1499 portrait = %s"portrait" 1500 landscape = %s"landscape" 1501 seascape = %s"seascape" 1502 ; NOTE: These names are case-sensitive. 1504 Example: 1506 a=orient:portrait 1508 Normally this is only used for a whiteboard or presentation tool. It 1509 specifies the orientation of a the workspace on the screen. 1510 Permitted values are "portrait", "landscape", and "seascape" (upside- 1511 down landscape). 1513 6.9. type (conference type) 1515 Name: type 1517 Value: type-value 1519 Usage Level: session 1521 Charset Dependent: no 1522 Syntax: 1524 type-value = conference-type 1525 conference-type = broadcast / meeting / moderated / test / 1526 H332 1527 broadcast = %s"broadcast" 1528 meeting = %s"meeting" 1529 moderated = %s"moderated" 1530 test = %s"test" 1531 H332 = %s"H332" 1532 ; NOTE: These names are case-sensitive. 1534 Example: 1536 a=type:moderated 1538 This specifies the type of the multimedia conference. Suggested 1539 values are "broadcast", "meeting", "moderated", "test", and "H332". 1540 "recvonly" should be the default for "type:broadcast" sessions, 1541 "type:meeting" should imply "sendrecv", and "type:moderated" should 1542 indicate the use of a floor control tool and that the media tools are 1543 started so as to mute new sites joining the multimedia conference. 1545 Specifying the attribute "type:H332" indicates that this loosely 1546 coupled session is part of an H.332 session as defined in the ITU 1547 H.332 specification [ITU.H332.1998]. Media tools should be started 1548 "recvonly". 1550 Specifying the attribute "type:test" is suggested as a hint that, 1551 unless explicitly requested otherwise, receivers can safely avoid 1552 displaying this session description to users. 1554 6.10. charset (character set) 1556 Name: charset 1558 Value: charset-value 1560 Usage Level: session 1562 Charset Dependent: no 1564 Syntax: 1566 charset-value = mime-charset 1567 (as defined in I-D.iana-charset-reg-procedure) 1569 This specifies the character set to be used to display the session 1570 name and information data. By default, the ISO-10646 character set 1571 in UTF-8 encoding is used. If a more compact representation is 1572 required, other character sets may be used. For example, the ISO 1573 8859-1 is specified with the following SDP attribute: 1575 a=charset:ISO-8859-1 1577 The charset specified MUST be one of those registered in the IANA 1578 Character Sets registry (http://www.iana.org/assignments/character- 1579 sets), such as ISO-8859-1. The character set identifier is a US- 1580 ASCII string and MUST be compared against identifiers from the "Name" 1581 or "Preferred MIME Name" field of the registry using a case- 1582 insensitive comparison. If the identifier is not recognised or not 1583 supported, all strings that are affected by it SHOULD be regarded as 1584 octet strings. 1586 Note that a character set specified MUST still prohibit the use of 1587 bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets requiring 1588 the use of these characters MUST define a quoting mechanism that 1589 prevents these bytes from appearing within text fields. 1591 6.11. sdplang (SDP language) 1593 Name: sdplang 1595 Value: sdplang-value 1597 Usage Level: session, media 1599 Charset Dependent: no 1601 Syntax: 1603 sdplang-value = Language-Tag 1604 ; Language-Tag defined in RFC5646 1606 Example: 1608 a=sdplang:fr 1610 Multiple sdplang attributes can be provided either at session or 1611 media level if the session description or media use multiple 1612 languages. 1614 As a session-level attribute, it specifies the language for the 1615 session description (not the language of the media). As a media- 1616 level attribute, it specifies the language for any media-level SDP 1617 information field associated with that media (again not the language 1618 of the media), overriding any sdplang attributes specified at 1619 session-level. 1621 In general, sending session descriptions consisting of multiple 1622 languages is discouraged. Instead, multiple descriptions SHOULD be 1623 sent describing the session, one in each language. However, this is 1624 not possible with all transport mechanisms, and so multiple sdplang 1625 attributes are allowed although NOT RECOMMENDED. 1627 The "sdplang" attribute value must be a single [RFC5646] language tag 1628 in US-ASCII. An "sdplang" attribute SHOULD be specified when a 1629 session is distributed with sufficient scope to cross geographic 1630 boundaries, where the language of recipients cannot be assumed, or 1631 where the session is in a different language from the locally assumed 1632 norm. 1634 6.12. lang (language) 1636 Name: lang 1638 Value: lang-value 1640 Usage Level: session, media 1642 Charset Dependent: no 1644 Syntax: 1646 lang-value = Language-Tag 1647 ; Language-Tag defined in RFC5646 1649 Example: 1651 a=lang:de 1653 Multiple lang attributes can be provided either at session or media 1654 level if the session or media has capabilities to use multiple 1655 languages, in which case the order of the attributes indicates the 1656 order of preference of the various languages in the session or media, 1657 from most preferred to least preferred. 1659 As a session-level attribute, lang specifies a language capability 1660 for the session being described. As a media-level attribute, it 1661 specifies a language capability for that media, overriding any 1662 session-level language(s) specified. 1664 The "lang" attribute value must be a single [RFC5646] language tag in 1665 US-ASCII. A "lang" attribute SHOULD be specified when a session is 1666 of sufficient scope to cross geographic boundaries where the language 1667 of recipients cannot be assumed, or where the session has 1668 capabilities in languages different from the locally assumed norm. 1670 Events during the session can influence which language(s) are used, 1671 and the participants are not strictly bound to only use the declared 1672 languages. 1674 6.13. framerate (frame rate) 1676 Name: framerate 1678 Value: framerate-value 1680 Usage Level: media 1682 Charset Dependent: no 1684 Syntax: 1686 framerate-value = non-zero-int-or-real 1688 Example: 1690 a=framerate:60 1692 This gives the maximum video frame rate in frames/sec. It is 1693 intended as a recommendation for the encoding of video data. Decimal 1694 representations of fractional values are allowed. It is defined only 1695 for video media. 1697 6.14. quality 1699 Name: quality 1701 Value: quality-value 1703 Usage Level: media 1705 Charset Dependent: no 1707 Syntax: 1709 quality-value = zero-based-integer 1711 Example: 1713 a=quality:10 1715 This gives a suggestion for the quality of the encoding as an integer 1716 value. The intention of the quality attribute for video is to 1717 specify a non-default trade-off between frame-rate and still-image 1718 quality. For video, the value is in the range 0 to 10, with the 1719 following suggested meaning: 1721 10 - the best still-image quality the compression scheme 1722 can give. 1723 5 - the default behaviour given no quality suggestion. 1724 0 - the worst still-image quality the codec designer 1725 thinks is still usable. 1727 Editor's note: The usage should be checked with the SIP Forum to see 1728 whether anybody is using this. Otherwise, the recommendation will be 1729 not to use this attribute and the receiver ignores it upon reception. 1731 6.15. fmtp (format parameters) 1733 Name: fmtp 1735 Value: fmtp-value 1737 Usage Level: media 1739 Charset Dependent: no 1741 Syntax: 1743 fmtp-value = fmt SP format-specific-params 1744 format-specific-params = byte-string 1745 ; Notes: 1746 ; - The format parameters are media type parameters and 1747 need to reflect their syntax. 1749 Example: 1751 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1753 This attribute allows parameters that are specific to a particular 1754 format to be conveyed in a way that SDP does not have to understand 1755 them. The format must be one of the formats specified for the media. 1756 Format-specific parameters may be any set of parameters required to 1757 be conveyed by SDP and given unchanged to the media tool that will 1758 use this format. At most one instance of this attribute is allowed 1759 for each format. 1761 7. Security Considerations 1763 SDP is frequently used with the Session Initiation Protocol [RFC3261] 1764 using the offer/answer model [RFC3264] to agree on parameters for 1765 unicast sessions. When used in this manner, the security 1766 considerations of those protocols apply. 1768 SDP is a session description format that describes multimedia 1769 sessions. Entities receiving and acting upon an SDP message SHOULD 1770 be aware that a session description cannot be trusted unless it has 1771 been obtained by an authenticated transport protocol from a known and 1772 trusted source. Many different transport protocols may be used to 1773 distribute session descriptions, and the nature of the authentication 1774 will differ from transport to transport. For some transports, 1775 security features are often not deployed. In case a session 1776 description has not been obtained in a trusted manner, the endpoint 1777 SHOULD exercise care because, among other attacks, the media sessions 1778 received may not be the intended ones, the destination where media is 1779 sent to may not be the expected one, any of the parameters of the 1780 session may be incorrect, or the media security may be compromised. 1781 It is up to the endpoint to make a sensible decision taking into 1782 account the security risks of the application and the user 1783 preferences and may decide to ask the user whether or not to accept 1784 the session. 1786 One transport that can be used to distribute session descriptions is 1787 the SAP. SAP provides both encryption and authentication mechanisms, 1788 but due to the nature of session announcements it is likely that 1789 there are many occasions where the originator of a session 1790 announcement cannot be authenticated because the originator is 1791 previously unknown to the receiver of the announcement and because no 1792 common public key infrastructure is available. 1794 On receiving a session description over an unauthenticated transport 1795 mechanism or from an untrusted party, software parsing the session 1796 should take a few precautions. Session descriptions contain 1797 information required to start software on the receiver's system. 1798 Software that parses a session description MUST NOT be able to start 1799 other software except that which is specifically configured as 1800 appropriate software to participate in multimedia sessions. It is 1801 normally considered inappropriate for software parsing a session 1802 description to start, on a user's system, software that is 1803 appropriate to participate in multimedia sessions, without the user 1804 first being informed that such software will be started and giving 1805 the user's consent. Thus, a session description arriving by session 1806 announcement, email, session invitation, or WWW page MUST NOT deliver 1807 the user into an interactive multimedia session unless the user has 1808 explicitly pre-authorised such action. As it is not always simple to 1809 tell whether or not a session is interactive, applications that are 1810 unsure should assume sessions are interactive. 1812 In this specification, there are no attributes that would allow the 1813 recipient of a session description to be informed to start multimedia 1814 tools in a mode where they default to transmitting. Under some 1815 circumstances it might be appropriate to define such attributes. If 1816 this is done, an application parsing a session description containing 1817 such attributes SHOULD either ignore them or inform the user that 1818 joining this session will result in the automatic transmission of 1819 multimedia data. The default behaviour for an unknown attribute is 1820 to ignore it. 1822 In certain environments, it has become common for intermediary 1823 systems to intercept and analyse session descriptions contained 1824 within other signalling protocols. This is done for a range of 1825 purposes, including but not limited to opening holes in firewalls to 1826 allow media streams to pass, or to mark, prioritize, or block traffic 1827 selectively. In some cases, such intermediary systems may modify the 1828 session description, for example, to have the contents of the session 1829 description match NAT bindings dynamically created. These behaviours 1830 are NOT RECOMMENDED unless the session description is conveyed in 1831 such a manner that allows the intermediary system to conduct proper 1832 checks to establish the authenticity of the session description, and 1833 the authority of its source to establish such communication sessions. 1834 SDP by itself does not include sufficient information to enable these 1835 checks: they depend on the encapsulating protocol (e.g., SIP or 1836 RTSP). 1838 Use of the "k=" line poses a significant security risk, since it 1839 conveys session encryption keys in the clear. SDP MUST NOT be used 1840 to convey key material, unless it can be guaranteed that the channel 1841 over which the SDP is delivered is both private and authenticated. 1842 Moreover, the "k=" line provides no way to indicate or negotiate 1843 cryptographic key algorithms. As it provides for only a single 1844 symmetric key, rather than separate keys for confidentiality and 1845 integrity, its utility is severely limited. The use of the "k=" line 1846 is NOT RECOMMENDED, as discussed in Section 5.12. 1848 8. IANA Considerations 1849 8.1. The "application/sdp" Media Type 1851 One media type registration from [RFC4566] is to be updated, as 1852 defined below. 1854 To: ietf-types@iana.org 1855 Subject: Registration of media type "application/sdp" 1857 Type name: application 1859 Subtype name: sdp 1861 Required parameters: None. 1863 Optional parameters: None. 1865 Encoding considerations: 1866 SDP files are primarily UTF-8 format text. The "a=charset:" 1867 attribute may be used to signal the presence of other character 1868 sets in certain parts of an SDP file (see Section 6 of RFC 1869 XXXX). Arbitrary binary content cannot be directly 1870 represented in SDP. 1872 Security considerations: 1873 See Section 7 of RFC XXXX. 1875 Interoperability considerations: 1876 See RFC XXXX. 1878 Published specification: 1879 See RFC XXXX. 1881 Applications which use this media type: 1882 Voice over IP, video teleconferencing, streaming media, instant 1883 messaging, among others. See also Section 3 of RFC XXXX. 1885 Additional information: 1887 Magic number(s): None. 1888 File extension(s): The extension ".sdp" is commonly used. 1889 Macintosh File Type Code(s): "sdp " 1891 Person & email address to contact for further information: 1892 IETF MMUSIC working group 1894 Intended usage: COMMON 1896 Author/Change controller: 1897 Authors of RFC XXXX 1898 IETF MMUSIC working group delegated from the IESG 1900 8.2. Registration of Parameters 1902 There are seven field names that are registered with IANA. Using the 1903 terminology in the SDP specification Backus-Naur Form (BNF), they are 1904 "media", "proto", "fmt", "att-field", "bwtype", "nettype", and 1905 "addrtype". 1907 The contact address for all parameters registered below is: 1909 IETF MMUSIC working group 1911 8.2.1. Media Types ("media") 1913 The set of media types is intended to be small and SHOULD NOT be 1914 extended except under rare circumstances. The same rules should 1915 apply for media names as for top-level media types, and where 1916 possible the same name should be registered for SDP as for MIME. For 1917 media other than existing top-level media types, a Standards Track 1918 RFC MUST be produced for a new top-level media type to be registered, 1919 and the registration MUST provide good justification why no existing 1920 media name is appropriate (the "Standards Action" policy of 1921 [RFC5226]. 1923 This memo registers the media types "audio", "video", "text", 1924 "application", and "message". 1926 Note: The media types "control" and "data" were listed as valid in an 1927 early version of this specification (RFC 2327); however, their 1928 semantics were never fully specified and they are not widely used. 1929 These media types have been removed in this specification, although 1930 they still remain valid media type capabilities for a SIP user agent 1931 as defined in [RFC3840]. If these media types are considered useful 1932 in the future, a Standards Track RFC MUST be produced to document 1933 their use. Until that is done, applications SHOULD NOT use these 1934 types and SHOULD NOT declare support for them in SIP capabilities 1935 declarations (even though they exist in the registry created by 1936 [RFC3840]). 1938 8.2.2. Transport Protocols ("proto") 1940 The "proto" field describes the transport protocol used. This SHOULD 1941 reference a standards-track protocol RFC. This memo registers three 1942 values: "RTP/AVP" is a reference to [RFC3550] used under the RTP 1943 Profile for Audio and Video Conferences with Minimal Control 1944 [RFC3551] running over UDP/IP, "RTP/SAVP" is a reference to the 1945 Secure Real-time Transport Protocol [RFC3711], and "udp" indicates an 1946 unspecified protocol over UDP. 1948 If other RTP profiles are defined in the future, their "proto" name 1949 SHOULD be specified in the same manner. For example, an RTP profile 1950 whose short name is "XYZ" would be denoted by a "proto" field of 1951 "RTP/XYZ". 1953 New transport protocols SHOULD be registered with IANA. 1954 Registrations MUST reference an RFC describing the protocol. Such an 1955 RFC MAY be Experimental or Informational, although it is preferable 1956 that it be Standards Track. Registrations MUST also define the rules 1957 by which their "fmt" namespace is managed (see below). 1959 8.2.3. Media Formats ("fmt") 1961 Each transport protocol, defined by the "proto" field, has an 1962 associated "fmt" namespace that describes the media formats that may 1963 be conveyed by that protocol. Formats cover all the possible 1964 encodings that could be transported in a multimedia session. 1966 RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST 1967 use the payload type number as their "fmt" value. If the payload 1968 type number is dynamically assigned by this session description, an 1969 additional "rtpmap" attribute MUST be included to specify the format 1970 name and parameters as defined by the media type registration for the 1971 payload format. It is RECOMMENDED that other RTP profiles that are 1972 registered (in combination with RTP) as SDP transport protocols 1973 specify the same rules for the "fmt" namespace. 1975 For the "udp" protocol, new formats SHOULD be registered. Use of an 1976 existing media subtype for the format is encouraged. If no media 1977 subtype exists, it is RECOMMENDED that a suitable one be registered 1978 through the IETF process [RFC6838] by production of, or reference to, 1979 a standards-track RFC that defines the transport protocol for the 1980 format. 1982 For other protocols, formats MAY be registered according to the rules 1983 of the associated "proto" specification. 1985 Registrations of new formats MUST specify which transport protocols 1986 they apply to. 1988 8.2.4. Attribute Names ("att-field") 1990 Attribute field names ("att-field") MUST be registered with IANA and 1991 documented, because of noticeable issues due to conflicting 1992 attributes under the same name. Unknown attributes in SDP are simply 1993 ignored, but conflicting ones that fragment the protocol are a 1994 serious problem. 1996 New attribute registrations are accepted according to the 1997 "Specification Required" policy of [RFC5226], provided that the 1998 specification includes the following information: 2000 o Contact name, email address, and telephone number. 2002 o Attribute name (as it will appear in SDP). This MUST conform to 2003 the definition of . 2005 o Attribute value: The name of an ABNF syntax rule defining the 2006 syntax of the value. Absence of a rule name indicates that the 2007 attribute takes no value. Enclosing the rule name in "[" and "]" 2008 indicates that a value is optional. 2010 o Usage level of the attribute. (One or more of: session, media, 2011 source). 2013 o Whether the attribute value is subject to the charset attribute. 2015 o An ABNF definition of the attribute value rule. The rule MUST NOT 2016 match anything that is not also matched by . The rule 2017 name MUST NOT be defined as an Incremental Alternative to . 2020 o An explanation of the purpose and usage of the attribute. 2022 o A specification of appropriate attribute values for this attribute 2023 (If not included in syntax). 2025 o Offer/Answer procedures as explained in [RFC3264]. 2027 o Indication of which "category" 2028 [I-D.ietf-mmusic-sdp-mux-attributes] an attribute is associated 2029 with. 2031 The above is the minimum that IANA will accept. Attributes that are 2032 expected to see widespread use and interoperability SHOULD be 2033 documented with a standards-track RFC that specifies the attribute 2034 more precisely. 2036 Submitters of registrations should ensure that the specification is 2037 in the spirit of SDP attributes, most notably that the attribute is 2038 platform independent in the sense that it makes no implicit 2039 assumptions about operating systems and does not name specific pieces 2040 of software in a manner that might inhibit interoperability. 2042 Submitters of registrations should also carefully choose the 2043 attribute usage level. They should not choose only "session" when 2044 the attribute can have different values when media is disaggregated, 2045 i.e., when each m= section has its own IP address on a different 2046 endpoint. In that case the attribute type chosen should be "session, 2047 media". The default rule is that for all new SDP attributes that can 2048 occur both in session and media level, the media level overrides the 2049 session level. When this is not the case for a new SDP attribute, it 2050 should be explicitly stated. 2052 IANA has registered the initial set of attribute names ("att-field" 2053 values), with definitions as in Section 6 of this memo (these 2054 definitions replace those in [RFC4566]). 2056 8.2.5. Bandwidth Specifiers ("bwtype") 2058 A proliferation of bandwidth specifiers is strongly discouraged. 2060 New bandwidth specifiers ("bwtype" fields) MUST be registered with 2061 IANA. The submission MUST reference a standards-track RFC specifying 2062 the semantics of the bandwidth specifier precisely, and indicating 2063 when it should be used, and why the existing registered bandwidth 2064 specifiers do not suffice. 2066 IANA has registered the bandwidth specifiers "CT" and "AS" with 2067 definitions as in Section 5.8 of this memo (these definitions update 2068 those in [RFC4566]). 2070 8.2.6. Network Types ("nettype") 2072 New network types (the "nettype" field) MUST be registered with IANA 2073 if SDP needs to be used in the context of non-Internet environments. 2074 The registration is subject to the RFC Required - RFC publication 2075 policy of [RFC5226]. Although these are not normally the preserve of 2076 IANA, there may be circumstances when an Internet application needs 2077 to interoperate with a non-Internet application, such as when 2078 gatewaying an Internet telephone call into the Public Switched 2079 Telephone Network (PSTN). The number of network types should be 2080 small and should be rarely extended. A new network type cannot be 2081 registered without registering at least one address type to be used 2082 with that network type. A new network type registration MUST 2083 reference an RFC that gives details of the network type and address 2084 type(s) and specifies how and when they would be used. 2086 IANA has registered the network type "IN" to represent the Internet, 2087 with definition as in Sections 5.2 and 5.7 of this memo (these 2088 definitions update those in [RFC4566]). 2090 8.2.7. Address Types ("addrtype") 2092 New address types ("addrtype") MUST be registered with IANA. The 2093 registration is subject to the RFC Required - RFC publication policy 2094 of [RFC5226]. An address type is only meaningful in the context of a 2095 network type, and any registration of an address type MUST specify a 2096 registered network type or be submitted along with a network type 2097 registration. A new address type registration MUST reference an RFC 2098 giving details of the syntax of the address type. Address types are 2099 not expected to be registered frequently. 2101 IANA has registered the address types "IP4" and "IP6" with 2102 definitions as in Sections 5.2 and 5.7 of this memo (these 2103 definitions update those in [RFC4566]). 2105 8.2.8. Registration Procedure 2107 In the RFC documentation that registers SDP "media", "proto", "fmt", 2108 "bwtype", "nettype", and "addrtype" fields, the authors MUST include 2109 the following information for IANA to place in the appropriate 2110 registry: 2112 o contact name, email address, and telephone number 2114 o name being registered (as it will appear in SDP) 2116 o long-form name in English 2118 o type of name ("media", "proto", "fmt", "bwtype", "nettype", or 2119 "addrtype") 2121 o a one-paragraph explanation of the purpose of the registered name 2123 o a reference to the specification for the registered name (this 2124 will typically be an RFC number) 2126 In the case of a new addrtype registration, the author has to check 2127 whether the new address type is usable with the existing network 2128 types. If yes, the "nettype" registry MUST be updated accordingly. 2129 In the case of a new nettype registration, the author MUST specify 2130 the usable address type(s). 2132 IANA may refer any registration to the IESG for review, and may 2133 request revisions to be made before a registration will be made. 2135 8.3. Encryption Key Access Methods 2137 The IANA previously maintained a table of SDP encryption key access 2138 method ("enckey") names. This table is obsolete, since the "k=" line 2139 is not extensible. New registrations MUST NOT be accepted. 2141 8.4. Reorganization of the nettype Registry 2143 This document adds a new column in the "nettype" registry with the 2144 title "Usable addrtype Values" and updates the "nettype" registry as 2145 follows: 2147 -------------------------------------------------------------------- 2148 |Type | SDP Name | Usable addrtype Values | Reference | 2149 -------------------------------------------------------------------- 2150 |nettype | IN | IP4, IP6 | [RFC4566] | 2151 |nettype | TN | RFC2543 | [RFC2848] | 2152 |nettype | ATM | NSAP, GWID, E164 | [RFC3108] | 2153 |nettype | PSTN | E164 | [RFC7195] | 2154 -------------------------------------------------------------------- 2156 Note that both [RFC7195] and [RFC3108] registered "E164" as an 2157 address type, although [RFC7195] mentions that the "E164" address 2158 type has a different context for ATM and PSTN networks. 2160 8.5. Reorganization of the att-field Registries 2162 This document combines all the five "att-field" registries into one 2163 registry called "att-field" registry, and update the columns to 2164 reflect the name, usage level(s), charset dependency and reference. 2165 That is, the new registry uses the following columns: 2167 Name | Usage Level | Dependent on charset? | Reference 2169 The "Name" column reflects the attribute name (as it will appear in 2170 the SDP). The "Usage Level" column MUST indicate one or more of the 2171 following: session, media, source. The "Dependent on charset?" 2172 column MUST indicate "Yes" or "No" depending on whether the attribute 2173 value is subject to the charset attribute. Finally, the "Reference" 2174 column indicates the specification(s) where the attribute is defined. 2176 Editor's note: Will IANA reorganize this table based on what is in 2177 the registry now or should we provide the updated table in this 2178 document? 2180 Editor's note: [I-D.ietf-mmusic-sdp-mux-attributes] adds another 2181 column (muxing category) to this table. Should we add it here? 2183 9. SDP Grammar 2185 This section provides an Augmented BNF grammar for SDP. ABNF is 2186 defined in [RFC5234] and [RFC7405]. 2188 ; SDP Syntax 2189 session-description = proto-version 2190 origin-field 2191 session-name-field 2192 information-field 2193 uri-field 2194 email-fields 2195 phone-fields 2196 connection-field 2197 bandwidth-fields 2198 time-fields 2199 key-field 2200 attribute-fields 2201 media-descriptions 2203 proto-version = %s"v" "=" 1*DIGIT CRLF 2204 ;this memo describes version 0 2206 origin-field = %s"o" "=" username SP sess-id SP sess-version SP 2207 nettype SP addrtype SP unicast-address CRLF 2209 session-name-field = %s"s" "=" text CRLF 2211 information-field = [%s"i" "=" text CRLF] 2213 uri-field = [%s"u" "=" uri CRLF] 2215 email-fields = *(%s"e" "=" email-address CRLF) 2217 phone-fields = *(%s"p" "=" phone-number CRLF) 2219 connection-field = [%s"c" "=" nettype SP addrtype SP 2220 connection-address CRLF] 2221 ;a connection field must be present 2222 ;in every media description or at the 2223 ;session-level 2225 bandwidth-fields = *(%s"b" "=" bwtype ":" bandwidth CRLF) 2227 time-fields = 1*( %s"t" "=" start-time SP stop-time 2228 *(CRLF repeat-fields) CRLF) 2229 [zone-adjustments CRLF] 2231 repeat-fields = %s"r" "=" repeat-interval SP typed-time 2232 1*(SP typed-time) 2234 zone-adjustments = %s"z" "=" time SP ["-"] typed-time 2235 *(SP time SP ["-"] typed-time) 2237 key-field = [%s"k" "=" key-type CRLF] 2239 attribute-fields = *(%s"a" "=" attribute CRLF) 2241 media-descriptions = *( media-field 2242 information-field 2243 *connection-field 2244 bandwidth-fields 2245 key-field 2246 attribute-fields ) 2248 media-field = %s"m" "=" media SP port ["/" integer] 2249 SP proto 1*(SP fmt) CRLF 2251 ; sub-rules of 'o=' 2252 username = non-ws-string 2253 ;pretty wide definition, but doesn't 2254 ;include space 2256 sess-id = 1*DIGIT 2257 ;should be unique for this username/host 2259 sess-version = 1*DIGIT 2261 nettype = token 2262 ;typically "IN" 2264 addrtype = token 2265 ;typically "IP4" or "IP6" 2267 ; sub-rules of 'u=' 2268 uri = URI-reference 2269 ; see RFC 3986 2271 ; sub-rules of 'e=', see RFC 5322 for definitions 2272 email-address = address-and-comment / dispname-and-address 2273 / addr-spec 2274 address-and-comment = addr-spec 1*SP "(" 1*email-safe ")" 2275 dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">" 2277 ; sub-rules of 'p=' 2278 phone-number = phone *SP "(" 1*email-safe ")" / 2279 1*email-safe "<" phone ">" / 2280 phone 2282 phone = ["+"] DIGIT 1*(SP / "-" / DIGIT) 2284 ; sub-rules of 'c=' 2285 connection-address = multicast-address / unicast-address 2287 ; sub-rules of 'b=' 2288 bwtype = token 2290 bandwidth = 1*DIGIT 2292 ; sub-rules of 't=' 2293 start-time = time / "0" 2295 stop-time = time / "0" 2297 time = POS-DIGIT 9*DIGIT 2298 ; Decimal representation of NTP time in 2299 ; seconds since 1900. The representation 2300 ; of NTP time is an unbounded length field 2301 ; containing at least 10 digits. Unlike the 2302 ; 64-bit representation used elsewhere, time 2303 ; in SDP does not wrap in the year 2036. 2305 ; sub-rules of 'r=' and 'z=' 2306 repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] 2308 typed-time = 1*DIGIT [fixed-len-time-unit] 2310 fixed-len-time-unit = %s"d" / %s"h" / %s"m" / %s"s" 2311 ; NOTE: These units are case-sensitive. 2313 ; sub-rules of 'k=' 2314 key-type = %s"prompt" 2315 %s"clear:" 2316 %s"base64:" 2317 %s"uri:" 2318 ; NOTE: These names are case-sensitive. 2320 base64 = *base64-unit [base64-pad] 2321 base64-unit = 4base64-char 2322 base64-pad = 2base64-char "==" / 3base64-char "=" 2323 base64-char = ALPHA / DIGIT / "+" / "/" 2325 ; sub-rules of 'a=' 2326 attribute = (att-field ":" att-value) / att-field 2327 att-field = token 2329 att-value = byte-string 2331 ; sub-rules of 'm=' 2332 media = token 2333 ;typically "audio", "video", "text", or 2334 ;"application" 2336 fmt = token 2337 ;typically an RTP payload type for audio 2338 ;and video media 2340 proto = token *("/" token) 2341 ;typically "RTP/AVP" or "udp" 2343 port = 1*DIGIT 2345 ; generic sub-rules: addressing 2346 unicast-address = IP4-address / IP6-address / FQDN / extn-addr 2348 multicast-address = IP4-multicast / IP6-multicast / FQDN 2349 / extn-addr 2351 IP4-multicast = m1 3( "." decimal-uchar ) 2352 "/" ttl [ "/" integer ] 2353 ; IP4 multicast addresses may be in the 2354 ; range 224.0.0.0 to 239.255.255.255 2356 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / 2357 ("23" DIGIT ) 2359 IP6-multicast = IP6-address [ "/" integer ] 2360 ; IP6 address starting with FF 2362 ttl = (POS-DIGIT *2DIGIT) / "0" 2364 FQDN = 4*(alpha-numeric / "-" / ".") 2365 ; fully qualified domain name as specified 2366 ; in RFC 1035 (and updates) 2368 IP4-address = b1 3("." decimal-uchar) 2370 b1 = decimal-uchar 2371 ; less than "224" 2373 IP6-address = 6( h16 ":" ) ls32 2374 / "::" 5( h16 ":" ) ls32 2375 / [ h16 ] "::" 4( h16 ":" ) ls32 2376 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 2377 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 2378 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 2379 / [ *4( h16 ":" ) h16 ] "::" ls32 2380 / [ *5( h16 ":" ) h16 ] "::" h16 2381 / [ *6( h16 ":" ) h16 ] "::" 2383 h16 = 1*4HEXDIG 2385 ls32 = ( h16 ":" h16 ) / IP4-address 2387 ; Generic for other address families 2388 extn-addr = non-ws-string 2390 ; generic sub-rules: datatypes 2391 text = byte-string 2392 ;default is to interpret this as UTF8 text. 2393 ;ISO 8859-1 requires "a=charset:ISO-8859-1" 2394 ;session-level attribute to be used 2396 byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) 2397 ;any byte except NUL, CR, or LF 2399 non-ws-string = 1*(VCHAR/%x80-FF) 2400 ;string of visible characters 2402 token-char = ALPHA / DIGIT 2403 / "!" / "#" / "$" / "%" / "&" 2404 / "'" ; (single quote) 2405 / "*" / "+" / "-" / "." / "^" / "_" 2406 / "`" ; (Grave accent) 2407 / "{" / "|" / "}" / "~" 2409 token = 1*(token-char) 2411 email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF 2412 ;any byte except NUL, CR, LF, or the quoting 2413 ;characters ()<> 2415 integer = POS-DIGIT *DIGIT 2417 zero-based-integer = "0" / integer 2419 non-zero-int-or-real = integer / non-zero-real 2421 non-zero-real = zero-based-integer "." *DIGIT POS-DIGIT 2422 ; generic sub-rules: primitives 2423 alpha-numeric = ALPHA / DIGIT 2425 POS-DIGIT = %x31-39 ; 1 - 9 2427 decimal-uchar = DIGIT 2428 / POS-DIGIT DIGIT 2429 / ("1" 2*(DIGIT)) 2430 / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) 2431 / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) 2433 ; external references: 2434 ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 5234 2435 ; URI-reference: from RFC 3986 2436 ; addr-spec: from RFC 5322 2438 10. Summary of Changes from RFC 4566 2440 The ABNF rule for IP6-address has been corrected. As a result, the 2441 ABNF rule for IP6-multicast has changed, and the (now unused) rules 2442 for hexpart, hexseq, and hex4 have been removed. 2444 IP4 unicast and multicast addresses in the example SDP descriptions 2445 have been revised per RFCs 5735 and 5771. 2447 Text in Section 5.2 has been revised to clarify the use of local 2448 addresses in case of ICE-like SDP extensions. 2450 Normative and informative references have been updated. 2452 The text regarding the session vs. media-level attribute usage has 2453 been clarified. 2455 The case-insensitivity rules from RFC 4855 have been included in this 2456 document. 2458 11. Acknowledgements 2460 Many people in the IETF Multiparty Multimedia Session Control 2461 (MMUSIC) working group have made comments and suggestions 2462 contributing to this document. 2464 12. References 2465 12.1. Normative References 2467 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2468 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 2469 . 2471 [RFC1035] Mockapetris, P., "Domain names - implementation and 2472 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2473 November 1987, . 2475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2476 Requirement Levels", BCP 14, RFC 2119, 2477 DOI 10.17487/RFC2119, March 1997, 2478 . 2480 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2481 Specifications: ABNF", STD 68, RFC 5234, 2482 DOI 10.17487/RFC5234, January 2008, 2483 . 2485 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2486 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2487 2003, . 2489 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2490 Resource Identifier (URI): Generic Syntax", STD 66, 2491 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2492 . 2494 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2495 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2496 DOI 10.17487/RFC5226, May 2008, 2497 . 2499 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 2500 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 2501 September 2009, . 2503 [RFC5890] Klensin, J., "Internationalized Domain Names for 2504 Applications (IDNA): Definitions and Document Framework", 2505 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2506 . 2508 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2509 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 2510 . 2512 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2513 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2514 July 2006, . 2516 [I-D.ietf-avtext-rtp-grouping-taxonomy] 2517 Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 2518 B. Burman, "A Taxonomy of Semantics and Mechanisms for 2519 Real-Time Transport Protocol (RTP) Sources", draft-ietf- 2520 avtext-rtp-grouping-taxonomy-08 (work in progress), July 2521 2015. 2523 [I-D.iana-charset-reg-procedure] 2524 McFadden, M. and A. Melnikov, "IANA Charset Registration 2525 Procedures", draft-iana-charset-reg-procedure-01 (work in 2526 progress), April 2015. 2528 [I-D.ietf-mmusic-sdp-mux-attributes] 2529 Nandakumar, S., "A Framework for SDP Attributes when 2530 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-10 2531 (work in progress), July 2015. 2533 12.2. Informative References 2535 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 2536 Protocol", RFC 2327, DOI 10.17487/RFC2327, April 1998, 2537 . 2539 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 2540 "Network Time Protocol Version 4: Protocol and Algorithms 2541 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 2542 . 2544 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 2545 Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, 2546 October 2000, . 2548 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2549 A., Peterson, J., Sparks, R., Handley, M., and E. 2550 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2551 DOI 10.17487/RFC3261, June 2002, 2552 . 2554 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 2555 Streaming Protocol (RTSP)", RFC 2326, 2556 DOI 10.17487/RFC2326, April 1998, 2557 . 2559 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2560 with Session Description Protocol (SDP)", RFC 3264, 2561 DOI 10.17487/RFC3264, June 2002, 2562 . 2564 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2565 Protocol (SDP) Grouping Framework", RFC 5888, 2566 DOI 10.17487/RFC5888, June 2010, 2567 . 2569 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2570 Jacobson, "RTP: A Transport Protocol for Real-Time 2571 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2572 July 2003, . 2574 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 2575 Video Conferences with Minimal Control", STD 65, RFC 3551, 2576 DOI 10.17487/RFC3551, July 2003, 2577 . 2579 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 2580 Modifiers for RTP Control Protocol (RTCP) Bandwidth", 2581 RFC 3556, DOI 10.17487/RFC3556, July 2003, 2582 . 2584 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2585 in Session Description Protocol (SDP)", RFC 3605, 2586 DOI 10.17487/RFC3605, October 2003, 2587 . 2589 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2590 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2591 RFC 3711, DOI 10.17487/RFC3711, March 2004, 2592 . 2594 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 2595 "Indicating User Agent Capabilities in the Session 2596 Initiation Protocol (SIP)", RFC 3840, 2597 DOI 10.17487/RFC3840, August 2004, 2598 . 2600 [RFC3890] Westerlund, M., "A Transport Independent Bandwidth 2601 Modifier for the Session Description Protocol (SDP)", 2602 RFC 3890, DOI 10.17487/RFC3890, September 2004, 2603 . 2605 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 2606 (ICE): A Protocol for Network Address Translator (NAT) 2607 Traversal for Offer/Answer Protocols", RFC 5245, 2608 DOI 10.17487/RFC5245, April 2010, 2609 . 2611 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 2612 "TCP Candidates with Interactive Connectivity 2613 Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, 2614 March 2012, . 2616 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 2617 RFC 7405, DOI 10.17487/RFC7405, December 2014, 2618 . 2620 [ITU.H332.1998] 2621 International Telecommunication Union, "H.323 extended for 2622 loosely coupled conferences", ITU Recommendation H.332, 2623 September 1998. 2625 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 2626 Carrara, "Key Management Extensions for Session 2627 Description Protocol (SDP) and Real Time Streaming 2628 Protocol (RTSP)", RFC 4567, DOI 10.17487/RFC4567, July 2629 2006, . 2631 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 2632 Description Protocol (SDP) Security Descriptions for Media 2633 Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, 2634 . 2636 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 2637 DOI 10.17487/RFC5322, October 2008, 2638 . 2640 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2641 Specifications and Registration Procedures", BCP 13, 2642 RFC 6838, DOI 10.17487/RFC6838, January 2013, 2643 . 2645 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 2646 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 2647 . 2649 Authors' Addresses 2651 Mark Handley 2652 University College London 2653 Department of Computer Science 2654 London WC1E 6BT 2655 UK 2657 EMail: M.Handley@cs.ucl.ac.uk 2659 Van Jacobson 2660 PARC 2661 3333 Coyote Hill Road 2662 Palo Alto, CA 94304 2663 USA 2665 EMail: van@parc.com 2667 Colin Perkins 2668 University of Glasgow 2669 School of Computing Science 2670 University of Glasgow 2671 Glasgow G12 8QQ 2672 UK 2674 EMail: csp@csperkins.org 2676 Ali Begen 2677 Unaffiliated 2679 EMail: acbegen@gmail.com