idnits 2.17.1 draft-ietf-mmusic-rfc4566bis-12.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 (September 23, 2014) is 3502 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: '0-10' is mentioned on line 1752, but not defined == Unused Reference: 'RFC2365' is defined on line 2632, 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) == Outdated reference: A later version (-08) exists of draft-ietf-avtext-rtp-grouping-taxonomy-02 ** Downref: Normative reference to an Informational draft: draft-ietf-avtext-rtp-grouping-taxonomy (ref. 'I-D.ietf-avtext-rtp-grouping-taxonomy') -- 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 (~~), 5 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: March 27, 2015 C.S. Perkins 7 University of Glasgow 8 A. Begen 9 Cisco 10 September 23, 2014 12 SDP: Session Description Protocol 13 draft-ietf-mmusic-rfc4566bis-12 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 March 27, 2015. 39 Copyright Notice 41 Copyright (c) 2014 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. Private Sessions . . . . . . . . . . . . . . . . . . . . 7 79 4.4. Obtaining Further Information about a Session . . . . . . 8 80 4.5. Categorisation . . . . . . . . . . . . . . . . . . . . . 8 81 4.6. Internationalisation . . . . . . . . . . . . . . . . . . 8 82 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . . 8 83 5.1. Protocol Version ("v=") . . . . . . . . . . . . . . . . . 11 84 5.2. Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 11 85 5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 13 86 5.4. Session Information ("i=") . . . . . . . . . . . . . . . 13 87 5.5. URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . 13 88 5.6. Email Address and Phone Number ("e=" and "p=") . . . . . 14 89 5.7. Connection Data ("c=") . . . . . . . . . . . . . . . . . 15 90 5.8. Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . 17 91 5.9. Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 18 92 5.10. Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . 19 93 5.11. Time Zones ("z=") . . . . . . . . . . . . . . . . . . . . 20 94 5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 20 95 5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 22 96 5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 23 98 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 26 99 6.1. cat (category) . . . . . . . . . . . . . . . . . . . . . 26 100 6.2. keywds (keywords) . . . . . . . . . . . . . . . . . . . . 26 101 6.3. tool . . . . . . . . . . . . . . . . . . . . . . . . . . 27 102 6.4. ptime (packet time) . . . . . . . . . . . . . . . . . . . 28 103 6.5. maxptime (maximum packet time) . . . . . . . . . . . . . 28 104 6.6. rtpmap . . . . . . . . . . . . . . . . . . . . . . . . . 29 105 6.7. Media Direction Attributes . . . . . . . . . . . . . . . 31 106 6.7.1. recvonly (receive-only) . . . . . . . . . . . . . . . 32 107 6.7.2. sendrecv (send-receive) . . . . . . . . . . . . . . . 33 108 6.7.3. sendonly (send-only) . . . . . . . . . . . . . . . . 33 109 6.7.4. inactive . . . . . . . . . . . . . . . . . . . . . . 33 110 6.8. orient (orientation) . . . . . . . . . . . . . . . . . . 34 111 6.9. type (conference type) . . . . . . . . . . . . . . . . . 34 112 6.10. charset (character set) . . . . . . . . . . . . . . . . . 35 113 6.11. sdplang (SDP language) . . . . . . . . . . . . . . . . . 36 114 6.12. lang (language) . . . . . . . . . . . . . . . . . . . . . 37 115 6.13. framerate (frame rate) . . . . . . . . . . . . . . . . . 38 116 6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 39 117 6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 39 118 7. Security Considerations . . . . . . . . . . . . . . . . . . . 40 119 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 120 8.1. The "application/sdp" Media Type . . . . . . . . . . . . 42 121 8.2. Registration of Parameters . . . . . . . . . . . . . . . 43 122 8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 43 123 8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 44 124 8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 44 125 8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 45 126 8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 47 127 8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 47 128 8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 47 129 8.2.8. Registration Procedure . . . . . . . . . . . . . . . 48 130 8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 48 131 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 48 132 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 53 133 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 55 134 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 135 12.1. Normative References . . . . . . . . . . . . . . . . . . 55 136 12.2. Informative References . . . . . . . . . . . . . . . . . 56 137 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 139 1. Introduction 141 When initiating multimedia teleconferences, voice-over-IP calls, 142 streaming video, or other sessions, there is a requirement to convey 143 media details, transport addresses, and other session description 144 metadata to the participants. 146 SDP provides a standard representation for such information, 147 irrespective of how that information is transported. SDP is purely a 148 format for session description -- it does not incorporate a transport 149 protocol, and it is intended to use different transport protocols as 150 appropriate, including the Session Announcement Protocol [RFC2974], 151 Session Initiation Protocol [RFC3261], Real Time Streaming Protocol 152 [RFC2326], electronic mail using the MIME extensions, and the 153 Hypertext Transport Protocol. 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 Session Announcement Protocol (SAP) [RFC2974]. SDP provides the 235 recommended session description format for such session 236 announcements. 238 4. Requirements and Recommendations 240 The purpose of SDP is to convey information about media streams in 241 multimedia sessions to allow the recipients of a session description 242 to participate in the session. SDP is primarily intended for use in 243 an internetwork, although it is sufficiently general that it can 244 describe multimedia conferences in other network environments. Media 245 streams can be many-to-many. Sessions need not be continually 246 active. 248 Thus far, multicast-based sessions on the Internet have differed from 249 many other forms of conferencing in that anyone receiving the traffic 250 can join the session (unless the session traffic is encrypted). In 251 such an environment, SDP serves two primary purposes. It is a means 252 to communicate the existence of a session, and it is a means to 253 convey sufficient information to enable joining and participating in 254 the session. In a unicast environment, only the latter purpose is 255 likely to be relevant. 257 An SDP session description includes the following: 259 o Session name and purpose 261 o Time(s) the session is active 263 o The media comprising the session 265 o Information needed to receive those media (addresses, ports, 266 formats, etc.) 268 As resources necessary to participate in a session may be limited, 269 some additional information may also be desirable: 271 o Information about the bandwidth to be used by the session 273 o Contact information for the person responsible for the session 275 In general, SDP must convey sufficient information to enable 276 applications to join a session (with the possible exception of 277 encryption keys) and to announce the resources to be used to any non- 278 participants that may need to know. (This latter feature is 279 primarily useful when SDP is used with a multicast session 280 announcement protocol.) 282 4.1. Media and Transport Information 284 An SDP session description includes the following media information: 286 o The type of media (video, audio, etc.) 288 o The transport protocol (RTP/UDP/IP, H.320, etc.) 289 o The format of the media (H.261 video, MPEG video, etc.) 291 In addition to media format and transport protocol, SDP conveys 292 address and port details. For an IP multicast session, these 293 comprise: 295 o The multicast group address for media 297 o The transport port for media 299 This address and port are the destination address and destination 300 port of the multicast stream, whether being sent, received, or both. 302 For unicast IP sessions, the following are conveyed: 304 o The remote address for media 306 o The remote transport port for media 308 The semantics of this address and port depend on the media and 309 transport protocol defined. By default, this SHOULD be the remote 310 address and remote port to which data is sent. Some media types may 311 redefine this behaviour, but this is NOT RECOMMENDED since it 312 complicates implementations (including middleboxes that must parse 313 the addresses to open Network Address Translation (NAT) or firewall 314 pinholes). 316 4.2. Timing Information 318 Sessions may be either bounded or unbounded in time. Whether or not 319 they are bounded, they may be only active at specific times. SDP can 320 convey: 322 o An arbitrary list of start and stop times bounding the session 324 o For each bound, repeat times such as "every Wednesday at 10am for 325 one hour" 327 This timing information is globally consistent, irrespective of local 328 time zone or daylight saving time (see Section 5.9). 330 4.3. Private Sessions 332 It is possible to create both public sessions and private sessions. 333 SDP itself does not distinguish between these; private sessions are 334 typically conveyed by encrypting the session description during 335 distribution. The details of how encryption is performed are 336 dependent on the mechanism used to convey SDP; mechanisms are 337 currently defined for SDP transported using SAP [RFC2974] and SIP 338 [RFC3261], and others may be defined in the future. 340 If a session announcement is private, it is possible to use that 341 private announcement to convey encryption keys necessary to decode 342 each of the media in a multimedia conference, including enough 343 information to know which encryption scheme is used for each media. 345 4.4. Obtaining Further Information about a Session 347 A session description should convey enough information to decide 348 whether or not to participate in a session. SDP may include 349 additional pointers in the form of Uniform Resource Identifiers 350 (URIs) for more information about the session. 352 4.5. Categorisation 354 When many session descriptions are being distributed by SAP, or any 355 other advertisement mechanism, it may be desirable to filter session 356 announcements that are of interest from those that are not. SDP 357 supports a categorisation mechanism for sessions that is capable of 358 being automated (the "a=cat:" attribute; see Section 6). 360 4.6. Internationalisation 362 The SDP specification recommends the use of the ISO 10646 character 363 set in the UTF-8 encoding [RFC3629] to allow many different languages 364 to be represented. However, to assist in compact representations, 365 SDP also allows other character sets such as ISO 8859-1 to be used 366 when desired. Internationalisation only applies to free-text fields 367 (session name and background information), and not to SDP as a whole. 369 5. SDP Specification 371 An SDP session description is denoted by the media type "application/ 372 sdp" (See Section 8). 374 An SDP session description is entirely textual. SDP field names and 375 attribute names use only the US-ASCII subset of UTF-8, but textual 376 fields and attribute values MAY use the full ISO 10646 character set 377 in UTF-8 encoding, or some other character set defined by the 378 "a=charset:" attribute. Field and attribute values that use the full 379 UTF-8 character set are never directly compared, hence there is no 380 requirement for UTF-8 normalisation. The textual form, as opposed to 381 a binary encoding such as ASN.1 or XDR, was chosen to enhance 382 portability, to enable a variety of transports to be used, and to 383 allow flexible, text-based toolkits to be used to generate and 384 process session descriptions. However, since SDP may be used in 385 environments where the maximum permissible size of a session 386 description is limited, the encoding is deliberately compact. Also, 387 since announcements may be transported via very unreliable means or 388 damaged by an intermediate caching server, the encoding was designed 389 with strict order and formatting rules so that most errors would 390 result in malformed session announcements that could be detected 391 easily and discarded. This also allows rapid discarding of encrypted 392 session announcements for which a receiver does not have the correct 393 key. 395 An SDP session description consists of a number of lines of text of 396 the form: 398 = 400 where MUST be exactly one case-significant character and 401 is structured text whose format depends on . In 402 general, is either a number of fields delimited by a single 403 space character or a free format string, and is case-significant 404 unless a specific field defines otherwise. Whitespace MUST NOT be 405 used on either side of the "=" sign. 407 An SDP session description consists of a session-level section 408 followed by zero or more media-level sections. The session-level 409 part starts with a "v=" line and continues to the first media-level 410 section (or the end of the whole description, whichever comes first). 411 Each media-level section starts with an "m=" line and continues to 412 the next media-level section or the end of the whole session 413 description - whichever comes first. In general, session-level 414 values are the default for all media unless overridden by an 415 equivalent media-level value. 417 Some lines in each description are REQUIRED and some are OPTIONAL, 418 but all MUST appear in exactly the order given here (the fixed order 419 greatly enhances error detection and allows for a simple parser). 420 OPTIONAL items are marked with a "*". 422 Session description 423 v= (protocol version) 424 o= (originator and session identifier) 425 s= (session name) 426 i=* (session information) 427 u=* (URI of description) 428 e=* (email address) 429 p=* (phone number) 430 c=* (connection information -- not required if included in 431 all media descriptions) 433 b=* (zero or more bandwidth information lines) 434 One or more time descriptions ("t=" and "r=" lines; see below) 435 z=* (time zone adjustments) 436 k=* (encryption key) 437 a=* (zero or more session attribute lines) 438 Zero or more media descriptions 440 Time description 441 t= (time the session is active) 442 r=* (zero or more repeat times) 444 Media description, if present 445 m= (media name and transport address) 446 i=* (media title) 447 c=* (connection information -- optional if included at 448 session level) 449 b=* (zero or more bandwidth information lines) 450 k=* (encryption key) 451 a=* (zero or more media attribute lines) 453 The set of type letters is deliberately small and not intended to be 454 extensible -- an SDP parser MUST completely ignore any session 455 description that contains a type letter that it does not understand. 456 The attribute mechanism ("a=" described below) is the primary means 457 for extending SDP and tailoring it to particular applications or 458 media. Some attributes (the ones listed in Section 6 of this memo) 459 have a defined meaning, but others may be added on an application-, 460 media-, or session-specific basis. An SDP parser MUST ignore any 461 attribute it doesn't understand. 463 An SDP session description may contain URIs that reference external 464 content in the "u=", "k=", and "a=" lines. These URIs may be 465 dereferenced in some cases, making the session description non-self- 466 contained. 468 The connection ("c=") information in the session-level section 469 applies to all the media of that session unless overridden by 470 connection information in the media description. For instance, in 471 the example below, each audio media behaves as if it were given a 472 "c=IN IP4 233.252.0.2". 474 An example SDP description is: 476 v=0 477 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 478 s=SDP Seminar 479 i=A Seminar on the session description protocol 480 u=http://www.example.com/seminars/sdp.pdf 481 e=j.doe@example.com (Jane Doe) 482 c=IN IP4 233.252.0.2 483 t=2873397496 2873404696 484 a=recvonly 485 m=audio 49170 RTP/AVP 0 486 m=audio 49180 RTP/AVP 0 487 m=video 51372 RTP/AVP 99 488 c=IN IP4 233.252.0.1/127 489 a=rtpmap:99 h263-1998/90000 491 Text fields such as the session name and information are octet 492 strings that may contain any octet with the exceptions of 0x00 (Nul), 493 0x0a (ASCII newline), and 0x0d (ASCII carriage return). The sequence 494 CRLF (0x0d0a) is used to end a record, although parsers SHOULD be 495 tolerant and also accept records terminated with a single newline 496 character. If the "a=charset" attribute is not present, these octet 497 strings MUST be interpreted as containing ISO-10646 characters in 498 UTF-8 encoding (the presence of the "a=charset" attribute may force 499 some fields to be interpreted differently). 501 A session description can contain domain names in the "o=", "u=", 502 "e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply 503 with [RFC1034], [RFC1035]. Internationalised domain names (IDNs) 504 MUST be represented using the ASCII Compatible Encoding (ACE) form 505 defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or 506 any other encoding (this requirement is for compatibility with 507 [RFC4566] and other early SDP-related standards, which predate the 508 development of internationalised domain names). 510 5.1. Protocol Version ("v=") 512 v=0 514 The "v=" field gives the version of the Session Description Protocol. 515 This memo defines version 0. There is no minor version number. 517 5.2. Origin ("o=") 519 o= 520 522 The "o=" field gives the originator of the session (her username and 523 the address of the user's host) plus a session identifier and version 524 number: 526 is the user's login on the originating host, or it is "-" 527 if the originating host does not support the concept of user IDs. 528 The MUST NOT contain spaces. 530 is a numeric string such that the tuple of , 531 , , , and forms a 532 globally unique identifier for the session. The method of allocation is up to the creating tool, but it has been 534 suggested that a Network Time Protocol (NTP) format timestamp be 535 used to ensure uniqueness [RFC5905]. 537 is a version number for this session description. 538 Its usage is up to the creating tool, so long as is 539 increased when a modification is made to the session data. Again, 540 it is RECOMMENDED that an NTP format timestamp is used. 542 is a text string giving the type of network. Initially 543 "IN" is defined to have the meaning "Internet", but other values 544 MAY be registered in the future (see Section 8). 546 is a text string giving the type of the address that 547 follows. Initially "IP4" and "IP6" are defined, but other values 548 MAY be registered in the future (see Section 8). 550 is an address of the machine from which the 551 session was created. For an address type of IP4, this is either a 552 fully qualified domain name of the machine or the dotted-decimal 553 representation of an IP version 4 address of the machine. For an 554 address type of IP6, this is either a fully qualified domain name 555 of the machine or the compressed textual representation of an IP 556 version 6 address of the machine. For both IP4 and IP6, the fully 557 qualified domain name is the form that SHOULD be given unless this 558 is unavailable, in which case a globally unique address MAY be 559 substituted. Unless an SDP extension for NAT traversal is used 560 (e.g., ICE [RFC5245], ICE TCP [RFC6544]), a local IP address MUST 561 NOT be used in any context where the SDP description might leave 562 the scope in which the address is meaningful (for example, a local 563 address MUST NOT be included in an application-level referral that 564 might leave the scope). 566 In general, the "o=" field serves as a globally unique identifier for 567 this version of this session description, and the subfields excepting 568 the version taken together identify the session irrespective of any 569 modifications. 571 For privacy reasons, it is sometimes desirable to obfuscate the 572 username and IP address of the session originator. If this is a 573 concern, an arbitrary and private MAY be 574 chosen to populate the "o=" field, provided that these are selected 575 in a manner that does not affect the global uniqueness of the field. 577 5.3. Session Name ("s=") 579 s= 581 The "s=" field is the textual session name. There MUST be one and 582 only one "s=" field per session description. The "s=" field MUST NOT 583 be empty and SHOULD contain ISO 10646 characters (but see also the 584 "a=charset" attribute). If a session has no meaningful name, the 585 value "s= " SHOULD be used (i.e., a single space as the session 586 name). 588 5.4. Session Information ("i=") 590 i= 592 The "i=" field provides textual information about the session. There 593 MUST be at most one session-level "i=" field per session description, 594 and at most one "i=" field per media. If the "a=charset" attribute 595 is present, it specifies the character set used in the "i=" field. 596 If the "a=charset" attribute is not present, the "i=" field MUST 597 contain ISO 10646 characters in UTF-8 encoding. 599 A single "i=" field MAY also be used for each media definition. In 600 media definitions, "i=" fields are primarily intended for labelling 601 media streams. As such, they are most likely to be useful when a 602 single session has more than one distinct media stream of the same 603 media type. An example would be two different whiteboards, one for 604 slides and one for feedback and questions. 606 The "i=" field is intended to provide a free-form human-readable 607 description of the session or the purpose of a media stream. It is 608 not suitable for parsing by automata. 610 5.5. URI ("u=") 612 u= 614 A URI is a Uniform Resource Identifier as used by WWW clients 615 [RFC3986]. The URI should be a pointer to additional information 616 about the session. This field is OPTIONAL, but if it is present it 617 MUST be specified before the first media field. No more than one URI 618 field is allowed per session description. 620 5.6. Email Address and Phone Number ("e=" and "p=") 622 e= 623 p= 625 The "e=" and "p=" lines specify contact information for the person 626 responsible for the session. This is not necessarily the same person 627 that created the session description. 629 Inclusion of an email address or phone number is OPTIONAL. Note that 630 the previous version of SDP specified that either an email field or a 631 phone field MUST be specified, but this was widely ignored. The 632 change brings the specification into line with common usage. 634 If an email address or phone number is present, it MUST be specified 635 before the first media field. More than one email or phone field can 636 be given for a session description. 638 Phone numbers SHOULD be given in the form of an international public 639 telecommunication number (see ITU-T Recommendation E.164) preceded by 640 a "+". Spaces and hyphens may be used to split up a phone field to 641 aid readability if desired. For example: 643 p=+1 617 555-6011 645 Both email addresses and phone numbers can have an OPTIONAL free text 646 string associated with them, normally giving the name of the person 647 who may be contacted. This MUST be enclosed in parentheses if it is 648 present. For example: 650 e=j.doe@example.com (Jane Doe) 652 The alternative [RFC5322] name quoting convention is also allowed for 653 both email addresses and phone numbers. For example: 655 e=Jane Doe 657 The free text string SHOULD be in the ISO-10646 character set with 658 UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if 659 the appropriate session-level "a=charset" attribute is set. 661 5.7. Connection Data ("c=") 663 c= 665 The "c=" field contains connection data. 667 A session description MUST contain either at least one "c=" field in 668 each media description or a single "c=" field at the session level. 669 It MAY contain a single session-level "c=" field and additional "c=" 670 field(s) per media description, in which case the per-media values 671 override the session-level settings for the respective media. 673 The first sub-field ("") is the network type, which is a 674 text string giving the type of network. Initially, "IN" is defined 675 to have the meaning "Internet", but other values MAY be registered in 676 the future (see Section 8). 678 The second sub-field ("") is the address type. This allows 679 SDP to be used for sessions that are not IP based. This memo only 680 defines IP4 and IP6, but other values MAY be registered in the future 681 (see Section 8). 683 The third sub-field ("") is the connection 684 address. OPTIONAL sub-fields MAY be added after the connection 685 address depending on the value of the field. 687 When the is IP4 and IP6, the connection address is defined 688 as follows: 690 o If the session is multicast, the connection address will be an IP 691 multicast group address. If the session is not multicast, then 692 the connection address contains the unicast IP address of the 693 expected data source or data relay or data sink as determined by 694 additional attribute fields. It is not expected that unicast 695 addresses will be given in a session description that is 696 communicated by a multicast announcement, though this is not 697 prohibited. 699 o Sessions using an IP4 multicast connection address MUST also have 700 a time to live (TTL) value present in addition to the multicast 701 address. The TTL and the address together define the scope with 702 which multicast packets sent in this session will be sent. TTL 703 values MUST be in the range 0-255. Although the TTL MUST be 704 specified, its use to scope multicast traffic is deprecated; 705 applications SHOULD use an administratively scoped address 706 instead. 708 The TTL for the session is appended to the address using a slash as a 709 separator. An example is: 711 c=IN IP4 233.252.0.1/127 713 IP6 multicast does not use TTL scoping, and hence the TTL value MUST 714 NOT be present for IP6 multicast. It is expected that IP6 scoped 715 addresses will be used to limit the scope of multimedia conferences. 717 Hierarchical or layered encoding schemes are data streams where the 718 encoding from a single media source is split into a number of layers. 719 The receiver can choose the desired quality (and hence bandwidth) by 720 only subscribing to a subset of these layers. Such layered encodings 721 are normally transmitted in multiple multicast groups to allow 722 multicast pruning. This technique keeps unwanted traffic from sites 723 only requiring certain levels of the hierarchy. For applications 724 requiring multiple multicast groups, we allow the following notation 725 to be used for the connection address: 727 [/]/ 729 If the number of addresses is not given, it is assumed to be one. 730 Multicast addresses so assigned are contiguously allocated above the 731 base address, so that, for example: 733 c=IN IP4 233.252.0.1/127/3 735 would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3 736 are to be used at a TTL of 127. This is semantically identical to 737 including multiple "c=" lines in a media description: 739 c=IN IP4 233.252.0.1/127 740 c=IN IP4 233.252.0.2/127 741 c=IN IP4 233.252.0.3/127 743 Similarly, an IP6 example would be: 745 c=IN IP6 FF15::101/3 747 which is semantically equivalent to: 749 c=IN IP6 FF15::101 750 c=IN IP6 FF15::102 751 c=IN IP6 FF15::103 753 (remembering that the TTL field is not present in IP6 multicast). 755 Multiple addresses or "c=" lines MAY be specified on a per-media 756 basis only if they provide multicast addresses for different layers 757 in a hierarchical or layered encoding scheme. They MUST NOT be 758 specified for a session-level "c=" field. 760 The slash notation for multiple addresses described above MUST NOT be 761 used for IP unicast addresses. 763 5.8. Bandwidth ("b=") 765 b=: 767 This OPTIONAL field denotes the proposed bandwidth to be used by the 768 session or media. The is an alphanumeric modifier giving 769 the meaning of the figure. Two values are defined in 770 this specification, but other values MAY be registered in the future 771 (see Section 8 and [RFC3556], [RFC3890]): 773 CT If the bandwidth of a session or media in a session is different 774 from the bandwidth implicit from the scope, a "b=CT:..." line 775 SHOULD be supplied for the session giving the proposed upper limit 776 to the bandwidth used (the "multimedia conference total" 777 bandwidth). The primary purpose of this is to give an approximate 778 idea as to whether two or more sessions can coexist 779 simultaneously. When using the CT modifier with RTP, if several 780 RTP sessions are part of the multimedia conference, the multimedia 781 conference total refers to total bandwidth of all RTP sessions. 783 AS The bandwidth is interpreted to be application specific (it will 784 be the application's concept of maximum bandwidth). Normally, 785 this will coincide with what is set on the application's "maximum 786 bandwidth" control if applicable. For RTP-based applications, AS 787 gives the RTP "session bandwidth" as defined in Section 6.2 of 788 [RFC3550]. 790 Note that CT gives a total bandwidth figure for all the media at all 791 sites. AS gives a bandwidth figure for a single media at a single 792 site, although there may be many sites sending simultaneously. 794 A prefix "X-" is defined for names. This is intended for 795 experimental purposes only. For example: 797 b=X-YZ:128 799 Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers 800 SHOULD be registered with IANA in the standard namespace. SDP 801 parsers MUST ignore bandwidth fields with unknown modifiers. 802 Modifiers MUST be alphanumeric and, although no length limit is 803 given, it is recommended that they be short. 805 The is interpreted as kilobits per second by default. 806 The definition of a new modifier MAY specify that the 807 bandwidth is to be interpreted in some alternative unit (the "CT" and 808 "AS" modifiers defined in this memo use the default units). 810 5.9. Timing ("t=") 812 t= 814 The "t=" lines specify the start and stop times for a session. 815 Multiple "t=" lines MAY be used if a session is active at multiple 816 irregularly spaced times; each additional "t=" line specifies an 817 additional period of time for which the session will be active. If 818 the session is active at regular times, an "r=" line (see below) 819 should be used in addition to, and following, a "t=" line -- in which 820 case the "t=" line specifies the start and stop times of the repeat 821 sequence. 823 The first and second sub-fields give the start and stop times, 824 respectively, for the session. These values are the decimal 825 representation of Network Time Protocol (NTP) time values in seconds 826 since 1900 [RFC5905]. To convert these values to UNIX time, subtract 827 decimal 2208988800. 829 NTP timestamps are elsewhere represented by 64-bit values, which wrap 830 sometime in the year 2036. Since SDP uses an arbitrary length 831 decimal representation, this should not cause an issue (SDP 832 timestamps MUST continue counting seconds since 1900, NTP will use 833 the value modulo the 64-bit limit). 835 If the is set to zero, then the session is not bounded, 836 though it will not become active until after the . If 837 the is also zero, the session is regarded as permanent. 839 User interfaces SHOULD strongly discourage the creation of unbounded 840 and permanent sessions as they give no information about when the 841 session is actually going to terminate, and so make scheduling 842 difficult. 844 The general assumption may be made, when displaying unbounded 845 sessions that have not timed out to the user, that an unbounded 846 session will only be active until half an hour from the current time 847 or the session start time, whichever is the later. If behaviour 848 other than this is required, an end-time SHOULD be given and modified 849 as appropriate when new information becomes available about when the 850 session should really end. 852 Permanent sessions may be shown to the user as never being active 853 unless there are associated repeat times that state precisely when 854 the session will be active. 856 5.10. Repeat Times ("r=") 858 r= 860 "r=" fields specify repeat times for a session. For example, if a 861 session is active at 10am on Monday and 11am on Tuesday for one hour 862 each week for three months, then the in the 863 corresponding "t=" field would be the NTP representation of 10am on 864 the first Monday, the would be 1 week, the would be 1 hour, and the offsets would be zero and 25 866 hours. The corresponding "t=" field stop time would be the NTP 867 representation of the end of the last session three months later. By 868 default, all fields are in seconds, so the "r=" and "t=" fields might 869 be the following: 871 t=3034423619 3042462419 872 r=604800 3600 0 90000 874 To make the description more compact, times may also be given in 875 units of days, hours, or minutes. The syntax for these is a number 876 immediately followed by a single case-sensitive character. 877 Fractional units are not allowed -- a smaller unit should be used 878 instead. The following unit specification characters are allowed: 880 d - days (86400 seconds) 881 h - hours (3600 seconds) 882 m - minutes (60 seconds) 883 s - seconds (allowed for completeness) 885 Thus, the above session announcement could also have been written: 887 r=7d 1h 0 25h 888 Monthly and yearly repeats cannot be directly specified with a single 889 SDP repeat time; instead, separate "t=" fields should be used to 890 explicitly list the session times. 892 5.11. Time Zones ("z=") 894 z= .... 896 To schedule a repeated session that spans a change from daylight 897 saving time to standard time or vice versa, it is necessary to 898 specify offsets from the base time. This is required because 899 different time zones change time at different times of day, different 900 countries change to or from daylight saving time on different dates, 901 and some countries do not have daylight saving time at all. 903 Thus, in order to schedule a session that is at the same time winter 904 and summer, it must be possible to specify unambiguously by whose 905 time zone a session is scheduled. To simplify this task for 906 receivers, we allow the sender to specify the NTP time that a time 907 zone adjustment happens and the offset from the time when the session 908 was first scheduled. The "z=" field allows the sender to specify a 909 list of these adjustment times and offsets from the base time. 911 An example might be the following: 913 z=2882844526 -1h 2898848070 0 915 This specifies that at time 2882844526, the time base by which the 916 session's repeat times are calculated is shifted back by 1 hour, and 917 that at time 2898848070, the session's original time base is 918 restored. Adjustments are always relative to the specified start 919 time -- they are not cumulative. Adjustments apply to all "t=" and 920 "r=" lines in a session description. 922 If a session is likely to last several years, it is expected that the 923 session description will be modified periodically rather than 924 transmit several years' worth of adjustments in one session 925 description. 927 5.12. Encryption Keys ("k=") 929 k= 930 k=: 931 If transported over a secure and trusted channel, the Session 932 Description Protocol MAY be used to convey encryption keys. A simple 933 mechanism for key exchange is provided by the key field ("k="), 934 although this is primarily supported for compatibility with older 935 implementations and its use is NOT RECOMMENDED. Work is in progress 936 to define new key exchange mechanisms for use with SDP [RFC4567] 937 [RFC4568], and it is expected that new applications will use those 938 mechanisms. 940 A key field is permitted before the first media entry (in which case 941 it applies to all media in the session), or for each media entry as 942 required. The format of keys and their usage are outside the scope 943 of this document, and the key field provides no way to indicate the 944 encryption algorithm to be used, key type, or other information about 945 the key: this is assumed to be provided by the higher-level protocol 946 using SDP. If there is a need to convey this information within SDP, 947 the extensions mentioned previously SHOULD be used. Many security 948 protocols require two keys: one for confidentiality, another for 949 integrity. This specification does not support transfer of two keys. 951 The method indicates the mechanism to be used to obtain a usable key 952 by external means, or from the encoded encryption key given. The 953 following methods are defined: 955 k=clear: 957 The encryption key is included untransformed in this key field. 958 This method MUST NOT be used unless it can be guaranteed that 959 the SDP is conveyed over a secure channel. The encryption key 960 is interpreted as text according to the charset attribute; use 961 the "k=base64:" method to convey characters that are otherwise 962 prohibited in SDP. 964 k=base64: 966 The encryption key is included in this key field but has been 967 base64 encoded [RFC4648] because it includes characters that 968 are prohibited in SDP. This method MUST NOT be used unless it 969 can be guaranteed that the SDP is conveyed over a secure 970 channel. 972 k=uri: 974 A Uniform Resource Identifier is included in the key field. 975 The URI refers to the data containing the key, and may require 976 additional authentication before the key can be returned. When 977 a request is made to the given URI, the reply should specify 978 the encoding for the key. The URI is often an Secure Socket 979 Layer/Transport Layer Security (SSL/TLS)-protected HTTP URI 980 ("https:"), although this is not required. 982 k=prompt 984 No key is included in this SDP description, but the session or 985 media stream referred to by this key field is encrypted. The 986 user should be prompted for the key when attempting to join the 987 session, and this user-supplied key should then be used to 988 decrypt the media streams. The use of user-specified keys is 989 NOT RECOMMENDED, since such keys tend to have weak security 990 properties. 992 The key field MUST NOT be used unless it can be guaranteed that the 993 SDP is conveyed over a secure and trusted channel. An example of 994 such a channel might be SDP embedded inside an S/MIME message or a 995 TLS-protected HTTP session. It is important to ensure that the 996 secure channel is with the party that is authorised to join the 997 session, not an intermediary: if a caching proxy server is used, it 998 is important to ensure that the proxy is either trusted or unable to 999 access the SDP. 1001 5.13. Attributes ("a=") 1003 a= 1004 a=: 1006 Attributes are the primary means for extending SDP. Attributes may 1007 be defined to be used as "session-level" attributes, "media-level" 1008 attributes, or both. 1010 A media description may have any number of attributes ("a=" fields) 1011 that are media specific. These are referred to as "media-level" 1012 attributes and add information about the media stream. Attribute 1013 fields can also be added before the first media field; these 1014 "session-level" attributes convey additional information that applies 1015 to the session as a whole rather than to individual media. 1017 Attribute fields may be of two forms: 1019 o A property attribute is simply of the form "a=". These are 1020 binary attributes, and the presence of the attribute conveys that 1021 the attribute is a property of the session. An example might be 1022 "a=recvonly". 1024 o A value attribute is of the form "a=:". For 1025 example, a whiteboard could have the value attribute 1026 "a=orient:landscape" 1028 Attribute interpretation depends on the media tool being invoked. 1029 Thus receivers of session descriptions should be configurable in 1030 their interpretation of session descriptions in general and of 1031 attributes in particular. 1033 Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. 1035 Attribute values are octet strings, and MAY use any octet value 1036 except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute 1037 values are to be interpreted as in ISO-10646 character set with UTF-8 1038 encoding. Unlike other text fields, attribute values are NOT 1039 normally affected by the "charset" attribute as this would make 1040 comparisons against known values problematic. However, when an 1041 attribute is defined, it can be defined to be charset dependent, in 1042 which case its value should be interpreted in the session charset 1043 rather than in ISO-10646. 1045 Attributes MUST be registered with IANA (see Section 8). If an 1046 attribute is received that is not understood, it MUST be ignored by 1047 the receiver. 1049 5.14. Media Descriptions ("m=") 1051 m= ... 1053 A session description may contain a number of media descriptions. 1054 Each media description starts with an "m=" field and is terminated by 1055 either the next "m=" field or by the end of the session description. 1056 A media field has several sub-fields: 1058 is the media type. Currently defined media are "audio", 1059 "video", "text", "application", and "message", although this list 1060 may be extended in the future (see Section 8). 1062 is the transport port to which the media stream is sent. The 1063 meaning of the transport port depends on the network being used as 1064 specified in the relevant "c=" field, and on the transport 1065 protocol defined in the sub-field of the media field. 1066 Other ports used by the media application (such as the RTP Control 1067 Protocol (RTCP) port [RFC3550]) MAY be derived algorithmically 1068 from the base media port or MAY be specified in a separate 1069 attribute (for example, "a=rtcp:" as defined in [RFC3605]). 1071 If non-contiguous ports are used or if they don't follow the 1072 parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" 1073 attribute MUST be used. Applications that are requested to send 1074 media to a that is odd and where the "a=rtcp:" is present 1075 MUST NOT subtract 1 from the RTP port: that is, they MUST send the 1076 RTP to the port indicated in and send the RTCP to the port 1077 indicated in the "a=rtcp" attribute. 1079 For applications where hierarchically encoded streams are being 1080 sent to a unicast address, it may be necessary to specify multiple 1081 transport ports. This is done using a similar notation to that 1082 used for IP multicast addresses in the "c=" field: 1084 m= / ... 1086 In such a case, the ports used depend on the transport protocol. 1087 For RTP, the default is that only the even-numbered ports are used 1088 for data with the corresponding one-higher odd ports used for the 1089 RTCP belonging to the RTP session, and the 1090 denoting the number of RTP sessions. For example: 1092 m=video 49170/2 RTP/AVP 31 1094 would specify that ports 49170 and 49171 form one RTP/RTCP pair 1095 and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the 1096 transport protocol and 31 is the format (see below). If non- 1097 contiguous ports are required, they must be signalled using a 1098 separate attribute (for example, "a=rtcp:" as defined in 1099 [RFC3605]). 1101 If multiple addresses are specified in the "c=" field and multiple 1102 ports are specified in the "m=" field, a one-to-one mapping from 1103 port to the corresponding address is implied. For example: 1105 c=IN IP4 233.252.0.1/127/2 1106 m=video 49170/2 RTP/AVP 31 1108 would imply that address 233.252.0.1 is used with ports 49170 and 1109 49171, and address 233.252.0.2 is used with ports 49172 and 49173. 1111 The semantics of multiple "m=" lines using the same transport 1112 address are undefined. This implies that, unlike limited past 1113 practice, there is no implicit grouping defined by such means and 1114 an explicit grouping framework (for example, [RFC5888]) should 1115 instead be used to express the intended semantics. 1117 is the transport protocol. The meaning of the transport 1118 protocol is dependent on the address type field in the relevant 1119 "c=" field. Thus a "c=" field of IP4 indicates that the transport 1120 protocol runs over IP4. The following transport protocols are 1121 defined, but may be extended through registration of new protocols 1122 with IANA (see Section 8): 1124 * udp: denotes an unspecified protocol running over UDP. 1126 * RTP/AVP: denotes RTP [RFC3550] used under the RTP Profile for 1127 Audio and Video Conferences with Minimal Control [RFC3551] 1128 running over UDP. 1130 * RTP/SAVP: denotes the Secure Real-time Transport Protocol 1131 [RFC3711] running over UDP. 1133 The main reason to specify the transport protocol in addition to 1134 the media format is that the same standard media formats may be 1135 carried over different transport protocols even when the network 1136 protocol is the same -- a historical example is vat Pulse Code 1137 Modulation (PCM) audio and RTP PCM audio; another might be TCP/RTP 1138 PCM audio. In addition, relays and monitoring tools that are 1139 transport-protocol-specific but format-independent are possible. 1141 is a media format description. The fourth and any subsequent 1142 sub-fields describe the format of the media. The interpretation 1143 of the media format depends on the value of the sub-field. 1145 If the sub-field is "RTP/AVP" or "RTP/SAVP" the sub- 1146 fields contain RTP payload type numbers. When a list of payload 1147 type numbers is given, this implies that all of these payload 1148 formats MAY be used in the session, but the first of these formats 1149 SHOULD be used as the default format for the session. For dynamic 1150 payload type assignments the "a=rtpmap:" attribute (see Section 6) 1151 SHOULD be used to map from an RTP payload type number to a media 1152 encoding name that identifies the payload format. The "a=fmtp:" 1153 attribute MAY be used to specify format parameters (see 1154 Section 6). 1156 If the sub-field is "udp" the sub-fields MUST 1157 reference a media type describing the format under the "audio", 1158 "video", "text", "application", or "message" top-level media 1159 types. The media type registration SHOULD define the packet 1160 format for use with UDP transport. 1162 For media using other transport protocols, the field is 1163 protocol specific. Rules for interpretation of the sub- 1164 field MUST be defined when registering new protocols (see 1165 Section 8.2.2). 1167 Section 3 of [RFC4855] states that the payload format (encoding) 1168 names defined in the RTP Profile are commonly shown in upper case, 1169 while media subtype names are commonly shown in lower case. It 1170 also states that both of these names are case-insensitive in both 1171 places, similar to parameter names which are case-insensitive both 1172 in media type strings and in the default mapping to the SDP a=fmtp 1173 attribute. 1175 6. SDP Attributes 1177 The following attributes are defined. Since application writers may 1178 add new attributes as they are required, this list is not exhaustive. 1179 Registration procedures for new attributes are defined in 1180 Section 8.2.4. 1182 6.1. cat (category) 1184 Name: cat 1186 Value: cat-value 1188 Usage Level: session 1190 Charset Dependent: no 1192 Syntax: 1194 cat-value = category 1195 category = byte-string 1196 ; Note: syntax is vague because usage is not understood 1198 Example: 1200 a=cat:foo.bar 1202 This attribute gives the dot-separated hierarchical category of the 1203 session. This is to enable a receiver to filter unwanted sessions by 1204 category. There is no central registry of categories. 1206 6.2. keywds (keywords) 1207 Name: keywds 1209 Value: keywds-value 1211 Usage Level: session 1213 Charset Dependent: yes 1215 Syntax: 1217 keywds-value = keywords 1218 keywords = byte-string 1219 ; Note: syntax is vague because usage is not understood 1221 Example: 1223 a=keywds:SDP session description protocol 1225 Like the cat attribute, this is to assist identifying wanted sessions 1226 at the receiver. This allows a receiver to select interesting 1227 session based on keywords describing the purpose of the session; 1228 there is no central registry of keywords. session-level attribute. 1229 Its value should be interpreted in the charset specified for the 1230 session description if one is specified, or by default in ISO 10646/ 1231 UTF-8. 1233 6.3. tool 1235 Name: tool 1237 Value: tool-value 1239 Usage Level: session 1241 Charset Dependent: no 1243 Syntax: 1245 tool-value = tool-name-and-version 1246 tool-name-and-version = byte-string 1247 ; Note: syntax is vague because usage is not understood 1249 Example: 1251 a=tool:foobar V3.2 1253 This gives the name and version number of the tool used to create the 1254 session description. 1256 6.4. ptime (packet time) 1258 Name: ptime 1260 Value: ptime-value 1262 Usage Level: media 1264 Charset Dependent: no 1266 Syntax: 1268 ptime-value = packet-time 1269 packet-time = integer 1270 ; do we want to define a limited range for this? 1272 Example: 1274 a=ptime:20 1276 This gives the length of time in milliseconds represented by the 1277 media in a packet. This is probably only meaningful for audio data, 1278 but may be used with other media types if it makes sense. It should 1279 not be necessary to know ptime to decode RTP or vat audio, and it is 1280 intended as a recommendation for the encoding/packetisation of audio. 1282 6.5. maxptime (maximum packet time) 1284 Name: maxptime 1286 Value: maxptime-value 1288 Usage Level: media 1290 Charset Dependent: no 1292 Syntax: 1294 maxptime-value = packet-time 1296 Example: 1298 a=maxptime:20 1300 This gives the maximum amount of media that can be encapsulated in 1301 each packet, expressed as time in milliseconds. The time SHALL be 1302 calculated as the sum of the time the media present in the packet 1303 represents. For frame-based codecs, the time SHOULD be an integer 1304 multiple of the frame size. This attribute is probably only 1305 meaningful for audio data, but may be used with other media types if 1306 it makes sense. Note that this attribute was introduced after 1307 [RFC2327], and non-updated implementations will ignore this 1308 attribute. 1310 6.6. rtpmap 1312 Name: rtpmap 1314 Value: rtpmap-value 1316 Usage Level: media 1318 Charset Dependent: no 1320 Syntax: 1322 rtpmap-value = payload-type SP encoding-name 1323 "/" clock-rate [ "/" encoding-params ] 1324 payload-type = integer 1325 ; do we want to define a limited range for this 1326 ; based on how big a PT can be in RTP? 1327 encoding-name = token 1328 ; To be matched in a case-insensitive way! 1329 ; RFC4855 seems to be the primary definition for this. 1330 ; It refers both to RFC2045 and RFC4288 for the definition. 1331 ; The definition in RFC2045 is messy, 1332 ; but equivalent to SDP . 1333 ; The definition in RFC4288 () is more 1334 ; restrictive and governs what can be registered. 1335 ; Since ultimately only registered names can be referenced, 1336 ; using here seems safe and easy. 1337 clock-rate = integer 1338 ; do we want to define a limited range for this? 1339 encoding-params = channels 1340 ; 4566 is vague about what this can be. RFC4855 seems to be 1341 ; the authoritative source, and only allows the 1342 ; value of the media subtype "channels" parameter - the 1343 ; number of audio channels. 1344 ; Does anyone think this can be used for something else??? 1345 ; (The implication that multiple parameters might be included 1346 ; seems a misdirection - additional parameters are 1347 ; to go into a=fmtp.) 1348 ; Does anyone have an example of other parameters 1349 ; using this field? 1350 channels = integer 1351 ; Is there any reason to make this less restrictive? 1353 This attribute maps from an RTP payload type number (as used in an 1354 "m=" line) to an encoding name denoting the payload format to be 1355 used. It also provides information on the clock rate and encoding 1356 parameters. 1358 Although an RTP profile can make static assignments of payload type 1359 numbers to payload formats, it is more common for that assignment to 1360 be done dynamically using "a=rtpmap:" attributes. As an example of a 1361 static payload type, consider u-law PCM coded single-channel audio 1362 sampled at 8 kHz. This is completely defined in the RTP Audio/Video 1363 profile as payload type 0, so there is no need for an "a=rtpmap:" 1364 attribute, and the media for such a stream sent to UDP port 49232 can 1365 be specified as: 1367 m=audio 49232 RTP/AVP 0 1369 An example of a dynamic payload type is 16-bit linear encoded stereo 1370 audio sampled at 16 kHz. If we wish to use the dynamic RTP/AVP 1371 payload type 98 for this stream, additional information is required 1372 to decode it: 1374 m=audio 49232 RTP/AVP 98 1375 a=rtpmap:98 L16/16000/2 1377 Up to one rtpmap attribute can be defined for each media format 1378 specified. Thus, we might have the following: 1380 m=audio 49230 RTP/AVP 96 97 98 1381 a=rtpmap:96 L8/8000 1382 a=rtpmap:97 L16/8000 1383 a=rtpmap:98 L16/11025/2 1385 RTP profiles that specify the use of dynamic payload types MUST 1386 define the set of valid encoding names and/or a means to register 1387 encoding names if that profile is to be used with SDP. The "RTP/AVP" 1388 and "RTP/SAVP" profiles use media subtypes for encoding names, under 1389 the top-level media type denoted in the "m=" line. In the example 1390 above, the media types are "audio/l8" and "audio/l16". 1392 For audio streams, indicates the number of 1393 audio channels. This parameter is OPTIONAL and may be omitted if the 1394 number of channels is one, provided that no additional parameters are 1395 needed. 1397 For video streams, no encoding parameters are currently specified. 1399 Additional encoding parameters MAY be defined in the future, but 1400 codec-specific parameters SHOULD NOT be added. Parameters added to 1401 an "a=rtpmap:" attribute SHOULD only be those required for a session 1402 directory to make the choice of appropriate media to participate in a 1403 session. Codec-specific parameters should be added in other 1404 attributes (for example, "a=fmtp:"). 1406 Note: RTP audio formats typically do not include information about 1407 the number of samples per packet. If a non-default (as defined in 1408 the RTP Audio/Video Profile) packetisation is required, the "ptime" 1409 attribute is used as given above. 1411 6.7. Media Direction Attributes 1413 At most one of recvonly/sendrecv/sendonly/inactive MAY appear at 1414 session level, and at most one MAY appear in each media section. 1416 If any one of these appears in a media section then it applies for 1417 that media section. If none appear in a media section then the one 1418 from session level, if any, applies to that media section. 1420 If none of the media direction attributes is present at either 1421 session level or media level, "sendrecv" SHOULD be assumed as the 1422 default for sessions that are not of the multimedia conference type 1423 "broadcast" or "H332" (see below). 1425 Within the following SDP example, the "inactive" attribute applies to 1426 audio media and the "recvonly" attribute applies to video media. 1428 v=0 1429 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 1430 s=SDP Seminar 1431 i=A Seminar on the session description protocol 1432 u=http://www.example.com/seminars/sdp.pdf 1433 e=j.doe@example.com (Jane Doe) 1434 c=IN IP4 233.252.0.1/127 1435 t=2873397496 2873404696 1436 a=inactive 1437 m=audio 49170 RTP/AVP 0 1438 m=video 51372 RTP/AVP 99 1439 a=rtpmap:99 h263-1998/90000 1440 a=recvonly 1442 6.7.1. recvonly (receive-only) 1444 Name: recvonly 1446 Value: 1448 Usage Level: session, media 1450 Charset Dependent: no 1452 Example: 1454 a=recvonly 1456 This specifies that the tools should be started in receive-only mode 1457 where applicable. Note that recvonly applies to the media only, not 1458 to any associated control protocol (e.g., an RTP-based system in 1459 recvonly mode SHOULD still send RTCP packets). 1461 6.7.2. sendrecv (send-receive) 1463 Name: sendrecv 1465 Value: 1467 Usage Level: session, media 1469 Charset Dependent: no 1471 Example: 1473 a=sendrecv 1475 This specifies that the tools should be started in send and receive 1476 mode. This is necessary for interactive multimedia conferences with 1477 tools that default to receive-only mode. 1479 6.7.3. sendonly (send-only) 1481 Name: sendonly 1483 Value: 1485 Usage Level: session, media 1487 Charset Dependent: no 1489 Example: 1491 a=sendonly 1493 This specifies that the tools should be started in send-only mode. 1494 An example may be where a different unicast address is to be used for 1495 a traffic destination than for a traffic source. In such a case, two 1496 media descriptions may be used, one sendonly and one recvonly. Note 1497 that sendonly applies only to the media, and any associated control 1498 protocol (e.g., RTCP) SHOULD still be received and processed as 1499 normal. 1501 6.7.4. inactive 1503 Name: inactive 1505 Value: 1507 Usage Level: session, media 1509 Charset Dependent: no 1511 Example: 1513 a=inactive 1515 This specifies that the tools should be started in inactive mode. 1516 This is necessary for interactive multimedia conferences where users 1517 can put other users on hold. No media is sent over an inactive media 1518 stream. Note that an RTP-based system SHOULD still send RTCP, even 1519 if started inactive. 1521 6.8. orient (orientation) 1523 Name: orient 1525 Value: orient-value 1527 Usage Level: media 1529 Charset Dependent: no 1531 Syntax: 1533 orient-value = portrait / landscape / seascape 1534 portrait = %x70.6f.72.74.72.61.69.74 ; "portrait" 1535 landscape = %x6c.61.6e.64.73.63.61.70.65 ; "landscape" 1536 seascape = %x73.65.61.73.63.61.70.65 ; "seascape" 1537 ; Note: this assumes the intent was to be case-sensitive 1538 ; Does anything think this should be matched in a 1539 ; case-insensitive way??? 1541 Example: 1543 a=orient:portrait 1545 Normally this is only used for a whiteboard or presentation tool. It 1546 specifies the orientation of a the workspace on the screen. 1547 Permitted values are "portrait", "landscape", and "seascape" (upside- 1548 down landscape). 1550 6.9. type (conference type) 1551 Name: type 1553 Value: type-value 1555 Usage Level: session 1557 Charset Dependent: no 1559 Syntax: 1561 type-value = conference-type 1562 conference-type = broadcast / meeting / moderated / test / H332 1563 broadcast = %x62.72.6f.61.64.63.61.73.74 ; "broadcast" 1564 meeting = %x6d.65.65.74.69.6e.67 ; "meeting" 1565 moderated = %x6d.6f.64.65.72.61.74.65.64 ; "moderated" 1566 test = %x74.65.73.74 ; "test" 1567 H332 = %x48.33.33.32 ; "H332" 1568 ; NOTE: are these names intended to be case-sensitive? 1569 ; Should there be an extensibility hook? A registry? 1571 Example: 1573 a=type:moderated 1575 This specifies the type of the multimedia conference. Suggested 1576 values are "broadcast", "meeting", "moderated", "test", and "H332". 1577 "recvonly" should be the default for "type:broadcast" sessions, 1578 "type:meeting" should imply "sendrecv", and "type:moderated" should 1579 indicate the use of a floor control tool and that the media tools are 1580 started so as to mute new sites joining the multimedia conference. 1582 Specifying the attribute "type:H332" indicates that this loosely 1583 coupled session is part of an H.332 session as defined in the ITU 1584 H.332 specification [ITU.H332.1998]. Media tools should be started 1585 "recvonly". 1587 Specifying the attribute "type:test" is suggested as a hint that, 1588 unless explicitly requested otherwise, receivers can safely avoid 1589 displaying this session description to users. 1591 6.10. charset (character set) 1593 Name: charset 1595 Value: charset-value 1596 Usage Level: session 1598 Charset Dependent: no 1600 Syntax: 1602 charset-value = iana-charset-preferred-mime-name 1603 iana-charset-preferred-mime-name = 1*40VCHAR 1604 ; Should we be using Preferred MIME Name or Name? 1605 ; Should SP be allowed in the name? 1607 This specifies the character set to be used to display the session 1608 name and information data. By default, the ISO-10646 character set 1609 in UTF-8 encoding is used. If a more compact representation is 1610 required, other character sets may be used. For example, the ISO 1611 8859-1 is specified with the following SDP attribute: 1613 a=charset:ISO-8859-1 1615 The charset specified MUST be one of those registered with IANA, such 1616 as ISO-8859-1. The character set identifier is a US-ASCII string and 1617 MUST be compared against the IANA identifiers using a case- 1618 insensitive comparison. If the identifier is not recognised or not 1619 supported, all strings that are affected by it SHOULD be regarded as 1620 octet strings. 1622 Note that a character set specified MUST still prohibit the use of 1623 bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets requiring 1624 the use of these characters MUST define a quoting mechanism that 1625 prevents these bytes from appearing within text fields. 1627 6.11. sdplang (SDP language) 1629 Name: sdplang 1631 Value: sdplang-value 1633 Usage Level: session, media 1635 Charset Dependent: no 1637 Syntax: 1639 sdplang-value = Language-Tag 1640 Language-Tag = token 1641 ; the actual definition of is in RFC5646. 1642 ; That is a proper subset of . Since the use here is 1643 ; to reference definitions done elsewhere against the 1644 ; more restrictive definition, it seems reasonable to use 1645 ; the simpler syntax here. 1646 ; Should we actually reference the RFC5646 definition? 1648 Example: 1650 a=sdplang:fr 1652 This can be a session-level attribute or a media-level attribute. 1653 Multiple sdplang attributes can be provided either at session or 1654 media level if the session description or media use multiple 1655 languages. 1657 As a session-level attribute, it specifies the language for the 1658 session description. As a media-level attribute, it specifies the 1659 language for any media-level SDP information field associated with 1660 that media, overriding any sdplang attributes specified at session- 1661 level. 1663 In general, sending session descriptions consisting of multiple 1664 languages is discouraged. Instead, multiple descriptions SHOULD be 1665 sent describing the session, one in each language. However, this is 1666 not possible with all transport mechanisms, and so multiple sdplang 1667 attributes are allowed although NOT RECOMMENDED. 1669 The "sdplang" attribute value must be a single [RFC5646] language tag 1670 in US-ASCII. An "sdplang" attribute SHOULD be specified when a 1671 session is distributed with sufficient scope to cross geographic 1672 boundaries, where the language of recipients cannot be assumed, or 1673 where the session is in a different language from the locally assumed 1674 norm. 1676 6.12. lang (language) 1678 Name: lang 1680 Value: lang-value 1682 Usage Level: session, media 1684 Charset Dependent: no 1685 Syntax: 1687 lang-value = Language-Tag 1688 ; defined with sdplang. 1690 Example: 1692 a=lang:de 1694 Multiple lang attributes can be provided either at session or media 1695 level if the session or media use multiple languages, in which case 1696 the order of the attributes indicates the order of importance of the 1697 various languages in the session or media, from most important to 1698 least important. 1700 As a session-level attribute, it specifies the default language for 1701 the session being described. As a media-level attribute, it 1702 specifies the language for that media, overriding any session-level 1703 languages specified. 1705 The "lang" attribute value must be a single [RFC5646] language tag in 1706 US-ASCII. A "lang" attribute SHOULD be specified when a session is 1707 of sufficient scope to cross geographic boundaries where the language 1708 of recipients cannot be assumed, or where the session is in a 1709 different language from the locally assumed norm. 1711 6.13. framerate (frame rate) 1713 Name: framerate 1715 Value: framerate-value 1717 Usage Level: media 1719 Charset Dependent: no 1721 Syntax: 1723 framerate-value = positive-real-number 1724 positive-real-number = (integer / "0") [ "." integer ] 1725 ; Notes: 1726 ; - this permits a zero value. OK? 1727 ; - do we want to restrict the range or precision? 1729 Example: 1731 a=framerate:60 1733 This gives the maximum video frame rate in frames/sec. It is 1734 intended as a recommendation for the encoding of video data. Decimal 1735 representations of fractional values are allowed. It is defined only 1736 for video media. 1738 6.14. quality 1740 Name: quality 1742 Value: quality-value 1744 Usage Level: media 1746 Charset Dependent: no 1748 Syntax: 1750 quality-value = integer 1751 ; Do we want to restrict the range? 1752 ; The definition above limits the range to [0-10] 1753 ; *for video*, but seems to leave usage open for other media. 1755 Example: 1757 a=quality:10 1759 This gives a suggestion for the quality of the encoding as an integer 1760 value. The intention of the quality attribute for video is to 1761 specify a non-default trade-off between frame-rate and still-image 1762 quality. For video, the value is in the range 0 to 10, with the 1763 following suggested meaning: 1765 10 - the best still-image quality the compression scheme 1766 can give. 1767 5 - the default behaviour given no quality suggestion. 1768 0 - the worst still-image quality the codec designer 1769 thinks is still usable. 1771 6.15. fmtp (format parameters) 1772 Name: fmtp 1774 Value: fmtp-value 1776 Usage Level: media 1778 Charset Dependent: no 1780 Syntax: 1782 fmtp-value = fmt SP format-specific-params 1783 format-specific-params = byte-string 1784 ; Notes: 1785 ; - I've assumed a space separator is required. 1786 ; - the rest is vague because it is format-specific. 1788 Example: 1790 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1792 This attribute allows parameters that are specific to a particular 1793 format to be conveyed in a way that SDP does not have to understand 1794 them. The format must be one of the formats specified for the media. 1795 Format-specific parameters may be any set of parameters required to 1796 be conveyed by SDP and given unchanged to the media tool that will 1797 use this format. At most one instance of this attribute is allowed 1798 for each format. 1800 7. Security Considerations 1802 SDP is frequently used with the Session Initiation Protocol [RFC3261] 1803 using the offer/answer model [RFC3264] to agree on parameters for 1804 unicast sessions. When used in this manner, the security 1805 considerations of those protocols apply. 1807 SDP is a session description format that describes multimedia 1808 sessions. Entities receiving and acting upon an SDP message SHOULD 1809 be aware that a session description cannot be trusted unless it has 1810 been obtained by an authenticated transport protocol from a known and 1811 trusted source. Many different transport protocols may be used to 1812 distribute session descriptions, and the nature of the authentication 1813 will differ from transport to transport. For some transports, 1814 security features are often not deployed. In case a session 1815 description has not been obtained in a trusted manner, the endpoint 1816 SHOULD exercise care because, among other attacks, the media sessions 1817 received may not be the intended ones, the destination where media is 1818 sent to may not be the expected one, any of the parameters of the 1819 session may be incorrect, or the media security may be compromised. 1820 It is up to the endpoint to make a sensible decision taking into 1821 account the security risks of the application and the user 1822 preferences and may decide to ask the user whether or not to accept 1823 the session. 1825 One transport that can be used to distribute session descriptions is 1826 the Session Announcement Protocol (SAP). SAP provides both 1827 encryption and authentication mechanisms, but due to the nature of 1828 session announcements it is likely that there are many occasions 1829 where the originator of a session announcement cannot be 1830 authenticated because the originator is previously unknown to the 1831 receiver of the announcement and because no common public key 1832 infrastructure is available. 1834 On receiving a session description over an unauthenticated transport 1835 mechanism or from an untrusted party, software parsing the session 1836 should take a few precautions. Session descriptions contain 1837 information required to start software on the receiver's system. 1838 Software that parses a session description MUST NOT be able to start 1839 other software except that which is specifically configured as 1840 appropriate software to participate in multimedia sessions. It is 1841 normally considered inappropriate for software parsing a session 1842 description to start, on a user's system, software that is 1843 appropriate to participate in multimedia sessions, without the user 1844 first being informed that such software will be started and giving 1845 the user's consent. Thus, a session description arriving by session 1846 announcement, email, session invitation, or WWW page MUST NOT deliver 1847 the user into an interactive multimedia session unless the user has 1848 explicitly pre-authorised such action. As it is not always simple to 1849 tell whether or not a session is interactive, applications that are 1850 unsure should assume sessions are interactive. 1852 In this specification, there are no attributes that would allow the 1853 recipient of a session description to be informed to start multimedia 1854 tools in a mode where they default to transmitting. Under some 1855 circumstances it might be appropriate to define such attributes. If 1856 this is done, an application parsing a session description containing 1857 such attributes SHOULD either ignore them or inform the user that 1858 joining this session will result in the automatic transmission of 1859 multimedia data. The default behaviour for an unknown attribute is 1860 to ignore it. 1862 In certain environments, it has become common for intermediary 1863 systems to intercept and analyse session descriptions contained 1864 within other signalling protocols. This is done for a range of 1865 purposes, including but not limited to opening holes in firewalls to 1866 allow media streams to pass, or to mark, prioritize, or block traffic 1867 selectively. In some cases, such intermediary systems may modify the 1868 session description, for example, to have the contents of the session 1869 description match NAT bindings dynamically created. These behaviours 1870 are NOT RECOMMENDED unless the session description is conveyed in 1871 such a manner that allows the intermediary system to conduct proper 1872 checks to establish the authenticity of the session description, and 1873 the authority of its source to establish such communication sessions. 1874 SDP by itself does not include sufficient information to enable these 1875 checks: they depend on the encapsulating protocol (e.g., SIP or 1876 RTSP). 1878 Use of the "k=" field poses a significant security risk, since it 1879 conveys session encryption keys in the clear. SDP MUST NOT be used 1880 to convey key material, unless it can be guaranteed that the channel 1881 over which the SDP is delivered is both private and authenticated. 1882 Moreover, the "k=" line provides no way to indicate or negotiate 1883 cryptographic key algorithms. As it provides for only a single 1884 symmetric key, rather than separate keys for confidentiality and 1885 integrity, its utility is severely limited. The use of the "k=" line 1886 is NOT RECOMMENDED, as discussed in Section 5.12. 1888 8. IANA Considerations 1890 8.1. The "application/sdp" Media Type 1892 One media type registration from [RFC4566] is to be updated, as 1893 defined below. 1895 To: ietf-types@iana.org 1896 Subject: Registration of media type "application/sdp" 1898 Type name: application 1900 Subtype name: sdp 1902 Required parameters: None. 1904 Optional parameters: None. 1906 Encoding considerations: 1907 SDP files are primarily UTF-8 format text. The "a=charset:" 1908 attribute may be used to signal the presence of other character 1909 sets in certain parts of an SDP file (see Section 6 of RFC 1910 XXXX). Arbitrary binary content cannot be directly 1911 represented in SDP. 1913 Security considerations: 1915 See Section 7 of RFC XXXX. 1917 Interoperability considerations: 1918 See RFC XXXX. 1920 Published specification: 1921 See RFC XXXX. 1923 Applications which use this media type: 1924 Voice over IP, video teleconferencing, streaming media, instant 1925 messaging, among others. See also Section 3 of RFC XXXX. 1927 Additional information: 1929 Magic number(s): None. 1930 File extension(s): The extension ".sdp" is commonly used. 1931 Macintosh File Type Code(s): "sdp " 1933 Person & email address to contact for further information: 1934 IETF MMUSIC working group 1936 Intended usage: COMMON 1938 Author/Change controller: 1939 Authors of RFC XXXX 1940 IETF MMUSIC working group delegated from the IESG 1942 8.2. Registration of Parameters 1944 There are seven field names that may be registered with IANA. Using 1945 the terminology in the SDP specification Backus-Naur Form (BNF), they 1946 are "media", "proto", "fmt", "att-field", "bwtype", "nettype", and 1947 "addrtype". 1949 The contact address for all parameters registered below is: 1951 IETF MMUSIC working group 1953 8.2.1. Media Types ("media") 1955 The set of media types is intended to be small and SHOULD NOT be 1956 extended except under rare circumstances. The same rules should 1957 apply for media names as for top-level media types, and where 1958 possible the same name should be registered for SDP as for MIME. For 1959 media other than existing top-level media types, a Standards Track 1960 RFC MUST be produced for a new top-level media type to be registered, 1961 and the registration MUST provide good justification why no existing 1962 media name is appropriate (the "Standards Action" policy of 1963 [RFC5226]. 1965 This memo registers the media types "audio", "video", "text", 1966 "application", and "message". 1968 Note: The media types "control" and "data" were listed as valid in an 1969 early version of this specification (RFC 2327); however, their 1970 semantics were never fully specified and they are not widely used. 1971 These media types have been removed in this specification, although 1972 they still remain valid media type capabilities for a SIP user agent 1973 as defined in [RFC3840]. If these media types are considered useful 1974 in the future, a Standards Track RFC MUST be produced to document 1975 their use. Until that is done, applications SHOULD NOT use these 1976 types and SHOULD NOT declare support for them in SIP capabilities 1977 declarations (even though they exist in the registry created by 1978 [RFC3840]). 1980 8.2.2. Transport Protocols ("proto") 1982 The "proto" field describes the transport protocol used. This SHOULD 1983 reference a standards-track protocol RFC. This memo registers three 1984 values: "RTP/AVP" is a reference to [RFC3550] used under the RTP 1985 Profile for Audio and Video Conferences with Minimal Control 1986 [RFC3551] running over UDP/IP, "RTP/SAVP" is a reference to the 1987 Secure Real-time Transport Protocol [RFC3711], and "udp" indicates an 1988 unspecified protocol over UDP. 1990 If other RTP profiles are defined in the future, their "proto" name 1991 SHOULD be specified in the same manner. For example, an RTP profile 1992 whose short name is "XYZ" would be denoted by a "proto" field of "RTP 1993 /XYZ". 1995 New transport protocols SHOULD be registered with IANA. 1996 Registrations MUST reference an RFC describing the protocol. Such an 1997 RFC MAY be Experimental or Informational, although it is preferable 1998 that it be Standards Track. Registrations MUST also define the rules 1999 by which their "fmt" namespace is managed (see below). 2001 8.2.3. Media Formats ("fmt") 2003 Each transport protocol, defined by the "proto" field, has an 2004 associated "fmt" namespace that describes the media formats that may 2005 be conveyed by that protocol. Formats cover all the possible 2006 encodings that might want to be transported in a multimedia session. 2008 RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST 2009 use the payload type number as their "fmt" value. If the payload 2010 type number is dynamically assigned by this session description, an 2011 additional "rtpmap" attribute MUST be included to specify the format 2012 name and parameters as defined by the media type registration for the 2013 payload format. It is RECOMMENDED that other RTP profiles that are 2014 registered (in combination with RTP) as SDP transport protocols 2015 specify the same rules for the "fmt" namespace. 2017 For the "udp" protocol, new formats SHOULD be registered. Use of an 2018 existing media subtype for the format is encouraged. If no media 2019 subtype exists, it is RECOMMENDED that a suitable one be registered 2020 through the IETF process [RFC6838] by production of, or reference to, 2021 a standards-track RFC that defines the transport protocol for the 2022 format. 2024 For other protocols, formats MAY be registered according to the rules 2025 of the associated "proto" specification. 2027 Registrations of new formats MUST specify which transport protocols 2028 they apply to. 2030 8.2.4. Attribute Names ("att-field") 2032 Attribute field names ("att-field") MUST be registered with IANA and 2033 documented, because of noticeable issues due to conflicting 2034 attributes under the same name. Unknown attributes in SDP are simply 2035 ignored, but conflicting ones that fragment the protocol are a 2036 serious problem. 2038 New attribute registrations are accepted according to the 2039 "Specification Required" policy of [RFC5226], provided that the 2040 specification includes the following information: 2042 o Contact name, email address, and telephone number. 2044 o Attribute name (as it will appear in SDP). This MUST conform to 2045 the definition of . 2047 o Attribute value: the name of an ABNF syntax rule defining the 2048 syntax of the value. Absence of a rule name indicates that the 2049 attribute takes no value. Enclosing the rule name in "[" and "]" 2050 indicates that a value is optional. 2052 o Long-form attribute name in English. 2054 [ED: I propose that we drop the long form. It hasn't been used 2055 and isn't needed.] 2057 o Usage level of the attribute. (One or more of: session, media). 2059 o Whether the attribute value is subject to the charset attribute. 2061 o An ABNF definition of the attribute value rule. The rule MUST NOT 2062 match anything that is not also matched by . The rule 2063 name SHOULD [MUST?] NOT be defined as an Incremental Alternative 2064 to . 2066 o An explanation of the purpose and usage of the attribute. 2068 o A specification of appropriate attribute values for this attribute 2069 (If not included in syntax). 2071 The above is the minimum that IANA will accept. Attributes that are 2072 expected to see widespread use and interoperability SHOULD be 2073 documented with a standards-track RFC that specifies the attribute 2074 more precisely. 2076 Submitters of registrations should ensure that the specification is 2077 in the spirit of SDP attributes, most notably that the attribute is 2078 platform independent in the sense that it makes no implicit 2079 assumptions about operating systems and does not name specific pieces 2080 of software in a manner that might inhibit interoperability. 2082 Submitters of registrations should also carefully choose the 2083 attribute usage level. They should not choose only session-level 2084 when the attribute can have different values when media is 2085 disaggregated, i.e., when each m= section has its own IP address on a 2086 different endpoint. In that case the attribute type chosen should be 2087 "session, media". 2089 IANA has registered the following initial set of attribute names 2090 ("att-field" values), with definitions as in Section 6 of this memo 2091 (these definitions replace those in [RFC4566]): 2093 [ED: Do we need the following list? I propose that it be dropped 2094 in favor of simply referencing Section 6.] 2096 Name | Usage Level | Dependent on charset? 2097 ----------+-------------------------+---------------------- 2098 cat | Session | No 2099 keywds | Session | Yes 2100 tool | Session | No 2101 ptime | Media | No 2102 maxptime | Media | No 2103 rtpmap | Media | No 2104 recvonly | Session, Media | No 2105 sendrecv | Session, Media | No 2106 sendonly | Session, Media | No 2107 inactive | Session, Media | No 2108 orient | Media | No 2109 type | Session | No 2110 charset | Session | No 2111 sdplang | Session, Media | No 2112 lang | Session, Media | No 2113 framerate | Media | No 2114 quality | Media | No 2115 fmtp | Media | No 2117 8.2.5. Bandwidth Specifiers ("bwtype") 2119 A proliferation of bandwidth specifiers is strongly discouraged. 2121 New bandwidth specifiers ("bwtype" fields) MUST be registered with 2122 IANA. The submission MUST reference a standards-track RFC specifying 2123 the semantics of the bandwidth specifier precisely, and indicating 2124 when it should be used, and why the existing registered bandwidth 2125 specifiers do not suffice. 2127 IANA has registered the bandwidth specifiers "CT" and "AS" with 2128 definitions as in Section 5.8 of this memo (these definitions update 2129 those in [RFC4566]). 2131 8.2.6. Network Types ("nettype") 2133 New network types (the "nettype" field) may be registered with IANA 2134 if SDP needs to be used in the context of non-Internet environments. 2135 Although these are not normally the preserve of IANA, there may be 2136 circumstances when an Internet application needs to interoperate with 2137 a non-Internet application, such as when gatewaying an Internet 2138 telephone call into the Public Switched Telephone Network (PSTN). 2139 The number of network types should be small and should be rarely 2140 extended. A new network type cannot be registered without 2141 registering at least one address type to be used with that network 2142 type. A new network type registration MUST reference an RFC that 2143 gives details of the network type and address type and specifies how 2144 and when they would be used. 2146 IANA has registered the network type "IN" to represent the Internet, 2147 with definition as in Sections 5.2 and 5.7 of this memo (these 2148 definitions update those in [RFC4566]). 2150 8.2.7. Address Types ("addrtype") 2152 New address types ("addrtype") may be registered with IANA. An 2153 address type is only meaningful in the context of a network type, and 2154 any registration of an address type MUST specify a registered network 2155 type or be submitted along with a network type registration. A new 2156 address type registration MUST reference an RFC giving details of the 2157 syntax of the address type. Address types are not expected to be 2158 registered frequently. 2160 IANA has registered the address types "IP4" and "IP6" with 2161 definitions as in Sections 5.2 and 5.7 of this memo (these 2162 definitions update those in [RFC4566]). 2164 8.2.8. Registration Procedure 2166 In the RFC documentation that registers SDP "media", "proto", "fmt", 2167 "bwtype", "nettype", and "addrtype" fields, the authors MUST include 2168 the following information for IANA to place in the appropriate 2169 registry: 2171 o contact name, email address, and telephone number 2173 o name being registered (as it will appear in SDP) 2175 o long-form name in English 2177 o type of name ("media", "proto", "fmt", "bwtype", "nettype", or 2178 "addrtype") 2180 o a one-paragraph explanation of the purpose of the registered name 2182 o a reference to the specification for the registered name (this 2183 will typically be an RFC number) 2185 IANA may refer any registration to the IESG for review, and may 2186 request revisions to be made before a registration will be made. 2188 8.3. Encryption Key Access Methods 2190 The IANA previously maintained a table of SDP encryption key access 2191 method ("enckey") names. This table is obsolete, since the "k=" line 2192 is not extensible. New registrations MUST NOT be accepted. 2194 9. SDP Grammar 2196 This section provides an Augmented BNF grammar for SDP. ABNF is 2197 defined in [RFC5234]. 2199 ; SDP Syntax 2200 session-description = proto-version 2201 origin-field 2202 session-name-field 2203 information-field 2204 uri-field 2205 email-fields 2206 phone-fields 2207 connection-field 2208 bandwidth-fields 2209 time-fields 2210 key-field 2211 attribute-fields 2212 media-descriptions 2214 proto-version = %x76 "=" 1*DIGIT CRLF 2215 ;this memo describes version 0 2217 origin-field = %x6f "=" username SP sess-id SP sess-version SP 2218 nettype SP addrtype SP unicast-address CRLF 2220 session-name-field = %x73 "=" text CRLF 2222 information-field = [%x69 "=" text CRLF] 2224 uri-field = [%x75 "=" uri CRLF] 2226 email-fields = *(%x65 "=" email-address CRLF) 2228 phone-fields = *(%x70 "=" phone-number CRLF) 2230 connection-field = [%x63 "=" nettype SP addrtype SP 2231 connection-address CRLF] 2232 ;a connection field must be present 2233 ;in every media description or at the 2234 ;session-level 2236 bandwidth-fields = *(%x62 "=" bwtype ":" bandwidth CRLF) 2238 time-fields = 1*( %x74 "=" start-time SP stop-time 2239 *(CRLF repeat-fields) CRLF) 2240 [zone-adjustments CRLF] 2242 repeat-fields = %x72 "=" repeat-interval SP typed-time 2243 1*(SP typed-time) 2245 zone-adjustments = %x7a "=" time SP ["-"] typed-time 2246 *(SP time SP ["-"] typed-time) 2248 key-field = [%x6b "=" key-type CRLF] 2249 attribute-fields = *(%x61 "=" attribute CRLF) 2251 media-descriptions = *( media-field 2252 information-field 2253 *connection-field 2254 bandwidth-fields 2255 key-field 2256 attribute-fields ) 2258 media-field = %x6d "=" media SP port ["/" integer] 2259 SP proto 1*(SP fmt) CRLF 2261 ; sub-rules of 'o=' 2262 username = non-ws-string 2263 ;pretty wide definition, but doesn't 2264 ;include space 2266 sess-id = 1*DIGIT 2267 ;should be unique for this username/host 2269 sess-version = 1*DIGIT 2271 nettype = token 2272 ;typically "IN" 2274 addrtype = token 2275 ;typically "IP4" or "IP6" 2277 ; sub-rules of 'u=' 2278 uri = URI-reference 2279 ; see RFC 3986 2281 ; sub-rules of 'e=', see RFC 5322 for definitions 2282 email-address = address-and-comment / dispname-and-address 2283 / addr-spec 2284 address-and-comment = addr-spec 1*SP "(" 1*email-safe ")" 2285 dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">" 2287 ; sub-rules of 'p=' 2288 phone-number = phone *SP "(" 1*email-safe ")" / 2289 1*email-safe "<" phone ">" / 2290 phone 2292 phone = ["+"] DIGIT 1*(SP / "-" / DIGIT) 2294 ; sub-rules of 'c=' 2295 connection-address = multicast-address / unicast-address 2296 ; sub-rules of 'b=' 2297 bwtype = token 2299 bandwidth = 1*DIGIT 2301 ; sub-rules of 't=' 2302 start-time = time / "0" 2304 stop-time = time / "0" 2306 time = POS-DIGIT 9*DIGIT 2307 ; Decimal representation of NTP time in 2308 ; seconds since 1900. The representation 2309 ; of NTP time is an unbounded length field 2310 ; containing at least 10 digits. Unlike the 2311 ; 64-bit representation used elsewhere, time 2312 ; in SDP does not wrap in the year 2036. 2314 ; sub-rules of 'r=' and 'z=' 2315 repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] 2317 typed-time = 1*DIGIT [fixed-len-time-unit] 2319 fixed-len-time-unit = %x64 / %x68 / %x6d / %x73 2321 ; sub-rules of 'k=' 2322 key-type = %x70 %x72 %x6f %x6d %x70 %x74 / ; "prompt" 2323 %x63 %x6c %x65 %x61 %x72 ":" text / ; "clear:" 2324 %x62 %x61 %x73 %x65 "64:" base64 / ; "base64:" 2325 %x75 %x72 %x69 ":" uri ; "uri:" 2327 base64 = *base64-unit [base64-pad] 2328 base64-unit = 4base64-char 2329 base64-pad = 2base64-char "==" / 3base64-char "=" 2330 base64-char = ALPHA / DIGIT / "+" / "/" 2332 ; sub-rules of 'a=' 2333 attribute = (att-field ":" att-value) / att-field 2335 att-field = token 2337 att-value = byte-string 2339 ; sub-rules of 'm=' 2340 media = token 2341 ;typically "audio", "video", "text", or 2342 ;"application" 2344 fmt = token 2345 ;typically an RTP payload type for audio 2346 ;and video media 2348 proto = token *("/" token) 2349 ;typically "RTP/AVP" or "udp" 2351 port = 1*DIGIT 2353 ; generic sub-rules: addressing 2354 unicast-address = IP4-address / IP6-address / FQDN / extn-addr 2356 multicast-address = IP4-multicast / IP6-multicast / FQDN 2357 / extn-addr 2359 IP4-multicast = m1 3( "." decimal-uchar ) 2360 "/" ttl [ "/" integer ] 2361 ; IP4 multicast addresses may be in the 2362 ; range 224.0.0.0 to 239.255.255.255 2364 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / 2365 ("23" DIGIT ) 2367 IP6-multicast = IP6-address [ "/" integer ] 2368 ; IP6 address starting with FF 2370 ttl = (POS-DIGIT *2DIGIT) / "0" 2372 FQDN = 4*(alpha-numeric / "-" / ".") 2373 ; fully qualified domain name as specified 2374 ; in RFC 1035 (and updates) 2376 IP4-address = b1 3("." decimal-uchar) 2378 b1 = decimal-uchar 2379 ; less than "224" 2381 IP6-address = 6( h16 ":" ) ls32 2382 / "::" 5( h16 ":" ) ls32 2383 / [ h16 ] "::" 4( h16 ":" ) ls32 2384 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 2385 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 2386 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 2387 / [ *4( h16 ":" ) h16 ] "::" ls32 2388 / [ *5( h16 ":" ) h16 ] "::" h16 2389 / [ *6( h16 ":" ) h16 ] "::" 2391 h16 = 1*4HEXDIG 2392 ls32 = ( h16 ":" h16 ) / IP4-address 2394 ; Generic for other address families 2395 extn-addr = non-ws-string 2397 ; generic sub-rules: datatypes 2398 text = byte-string 2399 ;default is to interpret this as UTF8 text. 2400 ;ISO 8859-1 requires "a=charset:ISO-8859-1" 2401 ;session-level attribute to be used 2403 byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) 2404 ;any byte except NUL, CR, or LF 2406 non-ws-string = 1*(VCHAR/%x80-FF) 2407 ;string of visible characters 2409 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 2410 / %x41-5A / %x5E-7E 2412 token = 1*(token-char) 2414 email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF 2415 ;any byte except NUL, CR, LF, or the quoting 2416 ;characters ()<> 2418 integer = POS-DIGIT *DIGIT 2420 ; generic sub-rules: primitives 2421 alpha-numeric = ALPHA / DIGIT 2423 POS-DIGIT = %x31-39 ; 1 - 9 2425 decimal-uchar = DIGIT 2426 / POS-DIGIT DIGIT 2427 / ("1" 2*(DIGIT)) 2428 / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) 2429 / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) 2431 ; external references: 2432 ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 5234 2433 ; URI-reference: from RFC 3986 2434 ; addr-spec: from RFC 5322 2436 10. Summary of Changes from RFC 4566 2437 The ABNF rule for IP6-address has been corrected. As a result, the 2438 ABNF rule for IP6-multicast has changed, and the (now unused) rules 2439 for hexpart, hexseq, and hex4 have been removed. 2441 IP4 unicast and multicast addresses in the example SDP descriptions 2442 have been revised per RFCs 5735 and 5771. 2444 Text in Section 5.2 has been revised to clarify the use of local 2445 addresses in case of ICE-like SDP extensions. 2447 Normative and informative references have been updated. 2449 The text regarding the session vs. media-level attribute usage has 2450 been clarified. 2452 The case-insensitivity rules from RFC 4855 have been included in this 2453 document. 2455 The following purely editorial changes have been made: 2457 o Section 4.6: fix typo in first sentence: "sets" -> "set" 2459 o Section 5: clarify second paragraph (SDP field and attribute names 2460 use the US-ASCII subset of UTF-8). 2462 o Section 5: clarify that an SDP session description can contain 2463 only a session-level section, with no media-level section, and 2464 that a media-level section can be terminated by the end of the 2465 session description, and not always by another media-level 2466 section. 2468 o Section 5: clearly differentiate "media" and "media description" 2469 in the description of the "c=" line. 2471 o Section 5.2: when describing the field, clarify 2472 that "an" address of the machine is used, rather than "the" 2473 address of the machine, since IP addresses identify interfaces, 2474 not hosts. 2476 o Section 5.6: use "session" rather than "conference" 2478 o Section 5.10: fix typo: "To make description" -> "To make the 2479 description" 2481 o Section 5.11: use "session description" rather than "session 2482 announcement" in the final paragraph 2484 o Section 7: fix typo: "distribute session description" -> 2485 "distribute session descriptions" 2487 11. Acknowledgements 2489 Many people in the IETF Multiparty Multimedia Session Control 2490 (MMUSIC) working group have made comments and suggestions 2491 contributing to this document. In particular, we would like to thank 2492 Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross 2493 Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna, 2494 Jonathan Lennox, Keith Drage, Sean Olson, Bernie Hoeneisen, Jonathan 2495 Rosenberg, John Elwell, Flemming Andreasen, Jon Peterson, Spencer 2496 Dawkins, Alfred Hoenes, Brett Tate and Paul Kyzivat. 2498 12. References 2500 12.1. Normative References 2502 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2503 STD 13, RFC 1034, November 1987. 2505 [RFC1035] Mockapetris, P., "Domain names - implementation and 2506 specification", STD 13, RFC 1035, November 1987. 2508 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2509 Requirement Levels", BCP 14, RFC 2119, March 1997. 2511 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2512 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2514 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2515 10646", STD 63, RFC 3629, November 2003. 2517 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2518 Resource Identifier (URI): Generic Syntax", STD 66, RFC 2519 3986, January 2005. 2521 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2522 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2523 May 2008. 2525 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 2526 Languages", BCP 47, RFC 5646, September 2009. 2528 [RFC5890] Klensin, J., "Internationalized Domain Names for 2529 Applications (IDNA): Definitions and Document Framework", 2530 RFC 5890, August 2010. 2532 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2533 Encodings", RFC 4648, October 2006. 2535 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2536 Description Protocol", RFC 4566, July 2006. 2538 [I-D.ietf-avtext-rtp-grouping-taxonomy] 2539 Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, 2540 "A Taxonomy of Grouping Semantics and Mechanisms for Real- 2541 Time Transport Protocol (RTP) Sources", draft-ietf-avtext- 2542 rtp-grouping-taxonomy-02 (work in progress), June 2014. 2544 12.2. Informative References 2546 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 2547 Protocol", RFC 2327, April 1998. 2549 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 2550 Time Protocol Version 4: Protocol and Algorithms 2551 Specification", RFC 5905, June 2010. 2553 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 2554 Announcement Protocol", RFC 2974, October 2000. 2556 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2557 A., Peterson, J., Sparks, R., Handley, M., and E. 2558 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2559 June 2002. 2561 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 2562 Streaming Protocol (RTSP)", RFC 2326, April 1998. 2564 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2565 with Session Description Protocol (SDP)", RFC 3264, June 2566 2002. 2568 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2569 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 2571 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2572 Jacobson, "RTP: A Transport Protocol for Real-Time 2573 Applications", STD 64, RFC 3550, July 2003. 2575 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 2576 Video Conferences with Minimal Control", STD 65, RFC 3551, 2577 July 2003. 2579 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 2580 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 2581 3556, July 2003. 2583 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2584 in Session Description Protocol (SDP)", RFC 3605, October 2585 2003. 2587 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2588 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2589 RFC 3711, March 2004. 2591 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 2592 "Indicating User Agent Capabilities in the Session 2593 Initiation Protocol (SIP)", RFC 3840, August 2004. 2595 [RFC3890] Westerlund, M., "A Transport Independent Bandwidth 2596 Modifier for the Session Description Protocol (SDP)", RFC 2597 3890, September 2004. 2599 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 2600 (ICE): A Protocol for Network Address Translator (NAT) 2601 Traversal for Offer/Answer Protocols", RFC 5245, April 2602 2010. 2604 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B.B., and A.B. 2605 Roach, "TCP Candidates with Interactive Connectivity 2606 Establishment (ICE)", RFC 6544, March 2012. 2608 [ITU.H332.1998] 2609 International Telecommunication Union, "H.323 extended for 2610 loosely coupled conferences", ITU Recommendation H.332, 2611 September 1998. 2613 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 2614 Carrara, "Key Management Extensions for Session 2615 Description Protocol (SDP) and Real Time Streaming 2616 Protocol (RTSP)", RFC 4567, July 2006. 2618 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 2619 Description Protocol (SDP) Security Descriptions for Media 2620 Streams", RFC 4568, July 2006. 2622 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 2623 October 2008. 2625 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2626 Specifications and Registration Procedures", BCP 13, RFC 2627 6838, January 2013. 2629 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 2630 Formats", RFC 4855, February 2007. 2632 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 2633 RFC 2365, July 1998. 2635 Authors' Addresses 2637 Mark Handley 2638 University College London 2639 Department of Computer Science 2640 London WC1E 6BT 2641 UK 2643 EMail: M.Handley@cs.ucl.ac.uk 2645 Van Jacobson 2646 PARC 2647 3333 Coyote Hill Road 2648 Palo Alto, CA 94304 2649 USA 2651 EMail: van@parc.com 2653 Colin Perkins 2654 University of Glasgow 2655 School of Computing Science 2656 University of Glasgow 2657 Glasgow G12 8QQ 2658 UK 2660 EMail: csp@csperkins.org 2662 Ali Begen 2663 Cisco 2664 181 Bay Street 2665 Toronto, ON M5J 2T3 2666 Canada 2668 EMail: abegen@cisco.com