idnits 2.17.1 draft-ietf-mmusic-rfc4566bis-10.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 (March 17, 2014) is 3692 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 2327 (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 2 errors (**), 0 flaws (~~), 2 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: September 18, 2014 C. Perkins 7 University of Glasgow 8 A. Begen 9 Cisco 10 March 17, 2014 12 SDP: Session Description Protocol 13 draft-ietf-mmusic-rfc4566bis-10 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 September 18, 2014. 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 . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . 7 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=") . . . . . . . . . . . . . . . . . . . . . . 12 85 5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 13 86 5.4. Session Information ("i=") . . . . . . . . . . . . . . . 13 87 5.5. URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . . . 25 99 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 100 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 101 8.1. The "application/sdp" Media Type . . . . . . . . . . . . 35 102 8.2. Registration of Parameters . . . . . . . . . . . . . . . 37 103 8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 37 104 8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 37 105 8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 38 106 8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 38 107 8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 40 108 8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 40 109 8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 40 110 8.2.8. Registration Procedure . . . . . . . . . . . . . . . 41 111 8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 41 112 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 41 113 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 46 114 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 115 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 116 12.1. Normative References . . . . . . . . . . . . . . . . . . 48 117 12.2. Informative References . . . . . . . . . . . . . . . . . 48 119 1. Introduction 121 When initiating multimedia teleconferences, voice-over-IP calls, 122 streaming video, or other sessions, there is a requirement to convey 123 media details, transport addresses, and other session description 124 metadata to the participants. 126 SDP provides a standard representation for such information, 127 irrespective of how that information is transported. SDP is purely a 128 format for session description -- it does not incorporate a transport 129 protocol, and it is intended to use different transport protocols as 130 appropriate, including the Session Announcement Protocol [RFC2974], 131 Session Initiation Protocol [RFC3261], Real Time Streaming Protocol 132 [RFC2326], electronic mail using the MIME extensions, and the 133 Hypertext Transport Protocol. 135 SDP is intended to be general purpose so that it can be used in a 136 wide range of network environments and applications. However, it is 137 not intended to support negotiation of session content or media 138 encodings: this is viewed as outside the scope of session 139 description. 141 This memo obsoletes [RFC4566]. The changes relative to [RFC4566] are 142 limited to essential corrections, and are outlined in Section 10 of 143 this memo. 145 2. Glossary of Terms 147 The following terms are used in this document and have specific 148 meaning within the context of this document. 150 Conference: A multimedia conference is a set of two or more 151 communicating users along with the software they are using to 152 communicate. 154 Session: A multimedia session is a set of multimedia senders and 155 receivers and the data streams flowing from senders to receivers. 156 A multimedia conference is an example of a multimedia session. 158 Session Description: A well-defined format for conveying sufficient 159 information to discover and participate in a multimedia session. 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 163 "OPTIONAL" in this document are to be interpreted as described in 164 [RFC2119]. 166 3. Examples of SDP Usage 168 3.1. Session Initiation 170 The Session Initiation Protocol (SIP) [RFC3261] is an application- 171 layer control protocol for creating, modifying, and terminating 172 sessions such as Internet multimedia conferences, Internet telephone 173 calls, and multimedia distribution. The SIP messages used to create 174 sessions carry session descriptions that allow participants to agree 175 on a set of compatible media types. These session descriptions are 176 commonly formatted using SDP. When used with SIP, the offer/answer 177 model [RFC3264] provides a limited framework for negotiation using 178 SDP. 180 3.2. Streaming Media 182 The Real Time Streaming Protocol (RTSP) [RFC2326], is an application- 183 level protocol for control over the delivery of data with real-time 184 properties. RTSP provides an extensible framework to enable 185 controlled, on-demand delivery of real-time data, such as audio and 186 video. An RTSP client and server negotiate an appropriate set of 187 parameters for media delivery, partially using SDP syntax to describe 188 those parameters. 190 3.3. Email and the World Wide Web 192 Alternative means of conveying session descriptions include 193 electronic mail and the World Wide Web (WWW). For both email and WWW 194 distribution, the media type "application/sdp" is used. This enables 195 the automatic launching of applications for participation in the 196 session from the WWW client or mail reader in a standard manner. 198 Note that announcements of multicast sessions made only via email or 199 the WWW do not have the property that the receiver of a session 200 announcement can necessarily receive the session because the 201 multicast sessions may be restricted in scope, and access to the WWW 202 server or reception of email is possible outside this scope. 204 3.4. Multicast Session Announcement 206 In order to assist the advertisement of multicast multimedia 207 conferences and other multicast sessions, and to communicate the 208 relevant session setup information to prospective participants, a 209 distributed session directory may be used. An instance of such a 210 session directory periodically sends packets containing a description 211 of the session to a well-known multicast group. These advertisements 212 are received by other session directories such that potential remote 213 participants can use the session description to start the tools 214 required to participate in the session. 216 One protocol used to implement such a distributed directory is the 217 Session Announcement Protocol (SAP) [RFC2974]. SDP provides the 218 recommended session description format for such session 219 announcements. 221 4. Requirements and Recommendations 223 The purpose of SDP is to convey information about media streams in 224 multimedia sessions to allow the recipients of a session description 225 to participate in the session. SDP is primarily intended for use in 226 an internetwork, although it is sufficiently general that it can 227 describe conferences in other network environments. Media streams 228 can be many-to-many. Sessions need not be continually active. 230 Thus far, multicast-based sessions on the Internet have differed from 231 many other forms of conferencing in that anyone receiving the traffic 232 can join the session (unless the session traffic is encrypted). In 233 such an environment, SDP serves two primary purposes. It is a means 234 to communicate the existence of a session, and it is a means to 235 convey sufficient information to enable joining and participating in 236 the session. In a unicast environment, only the latter purpose is 237 likely to be relevant. 239 An SDP session description includes the following: 241 o Session name and purpose 243 o Time(s) the session is active 245 o The media comprising the session 247 o Information needed to receive those media (addresses, ports, 248 formats, etc.) 250 As resources necessary to participate in a session may be limited, 251 some additional information may also be desirable: 253 o Information about the bandwidth to be used by the session 255 o Contact information for the person responsible for the session 257 In general, SDP must convey sufficient information to enable 258 applications to join a session (with the possible exception of 259 encryption keys) and to announce the resources to be used to any non- 260 participants that may need to know. (This latter feature is 261 primarily useful when SDP is used with a multicast session 262 announcement protocol.) 264 4.1. Media and Transport Information 266 An SDP session description includes the following media information: 268 o The type of media (video, audio, etc.) 270 o The transport protocol (RTP/UDP/IP, H.320, etc.) 272 o The format of the media (H.261 video, MPEG video, etc.) 274 In addition to media format and transport protocol, SDP conveys 275 address and port details. For an IP multicast session, these 276 comprise: 278 o The multicast group address for media 280 o The transport port for media 282 This address and port are the destination address and destination 283 port of the multicast stream, whether being sent, received, or both. 285 For unicast IP sessions, the following are conveyed: 287 o The remote address for media 289 o The remote transport port for media 291 The semantics of this address and port depend on the media and 292 transport protocol defined. By default, this SHOULD be the remote 293 address and remote port to which data is sent. Some media types may 294 redefine this behaviour, but this is NOT RECOMMENDED since it 295 complicates implementations (including middleboxes that must parse 296 the addresses to open Network Address Translation (NAT) or firewall 297 pinholes). 299 4.2. Timing Information 301 Sessions may be either bounded or unbounded in time. Whether or not 302 they are bounded, they may be only active at specific times. SDP can 303 convey: 305 o An arbitrary list of start and stop times bounding the session 307 o For each bound, repeat times such as "every Wednesday at 10am for 308 one hour" 310 This timing information is globally consistent, irrespective of local 311 time zone or daylight saving time (see Section 5.9). 313 4.3. Private Sessions 315 It is possible to create both public sessions and private sessions. 316 SDP itself does not distinguish between these; private sessions are 317 typically conveyed by encrypting the session description during 318 distribution. The details of how encryption is performed are 319 dependent on the mechanism used to convey SDP; mechanisms are 320 currently defined for SDP transported using SAP [RFC2974] and SIP 321 [RFC3261], and others may be defined in the future. 323 If a session announcement is private, it is possible to use that 324 private announcement to convey encryption keys necessary to decode 325 each of the media in a conference, including enough information to 326 know which encryption scheme is used for each media. 328 4.4. Obtaining Further Information about a Session 330 A session description should convey enough information to decide 331 whether or not to participate in a session. SDP may include 332 additional pointers in the form of Uniform Resource Identifiers 333 (URIs) for more information about the session. 335 4.5. Categorisation 337 When many session descriptions are being distributed by SAP, or any 338 other advertisement mechanism, it may be desirable to filter session 339 announcements that are of interest from those that are not. SDP 340 supports a categorisation mechanism for sessions that is capable of 341 being automated (the "a=cat:" attribute; see Section 6). 343 4.6. Internationalisation 345 The SDP specification recommends the use of the ISO 10646 character 346 set in the UTF-8 encoding [RFC3629] to allow many different languages 347 to be represented. However, to assist in compact representations, 348 SDP also allows other character sets such as ISO 8859-1 to be used 349 when desired. Internationalisation only applies to free-text fields 350 (session name and background information), and not to SDP as a whole. 352 5. SDP Specification 354 An SDP session description is denoted by the media type "application/ 355 sdp" (See Section 8). 357 An SDP session description is entirely textual. SDP field names and 358 attribute names use only the US-ASCII subset of UTF-8, but textual 359 fields and attribute values MAY use the full ISO 10646 character set 360 in UTF-8 encoding, or some other character set defined by the 361 "a=charset:" attribute. Field and attribute values that use the full 362 UTF-8 character set are never directly compared, hence there is no 363 requirement for UTF-8 normalisation. The textual form, as opposed to 364 a binary encoding such as ASN.1 or XDR, was chosen to enhance 365 portability, to enable a variety of transports to be used, and to 366 allow flexible, text-based toolkits to be used to generate and 367 process session descriptions. However, since SDP may be used in 368 environments where the maximum permissible size of a session 369 description is limited, the encoding is deliberately compact. Also, 370 since announcements may be transported via very unreliable means or 371 damaged by an intermediate caching server, the encoding was designed 372 with strict order and formatting rules so that most errors would 373 result in malformed session announcements that could be detected 374 easily and discarded. This also allows rapid discarding of encrypted 375 session announcements for which a receiver does not have the correct 376 key. 378 An SDP session description consists of a number of lines of text of 379 the form: 381 = 383 where MUST be exactly one case-significant character and 384 is structured text whose format depends on . In 385 general, is either a number of fields delimited by a single 386 space character or a free format string, and is case-significant 387 unless a specific field defines otherwise. Whitespace MUST NOT be 388 used on either side of the "=" sign. 390 An SDP session description consists of a session-level section 391 followed by zero or more media-level sections. The session-level 392 part starts with a "v=" line and continues to the first media-level 393 section (or the end of the whole description, whichever comes first). 394 Each media-level section starts with an "m=" line and continues to 395 the next media-level section or the end of the whole session 396 description - whichever comes first. In general, session-level 397 values are the default for all media unless overridden by an 398 equivalent media-level value. 400 Some lines in each description are REQUIRED and some are OPTIONAL, 401 but all MUST appear in exactly the order given here (the fixed order 402 greatly enhances error detection and allows for a simple parser). 403 OPTIONAL items are marked with a "*". 405 Session description 406 v= (protocol version) 407 o= (originator and session identifier) 408 s= (session name) 409 i=* (session information) 410 u=* (URI of description) 411 e=* (email address) 412 p=* (phone number) 413 c=* (connection information -- not required if included in 414 all media descriptions) 415 b=* (zero or more bandwidth information lines) 416 One or more time descriptions ("t=" and "r=" lines; see below) 417 z=* (time zone adjustments) 418 k=* (encryption key) 419 a=* (zero or more session attribute lines) 420 Zero or more media descriptions 422 Time description 423 t= (time the session is active) 424 r=* (zero or more repeat times) 426 Media description, if present 427 m= (media name and transport address) 428 i=* (media title) 429 c=* (connection information -- optional if included at 430 session level) 431 b=* (zero or more bandwidth information lines) 432 k=* (encryption key) 433 a=* (zero or more media attribute lines) 435 The set of type letters is deliberately small and not intended to be 436 extensible -- an SDP parser MUST completely ignore any session 437 description that contains a type letter that it does not understand. 438 The attribute mechanism ("a=" described below) is the primary means 439 for extending SDP and tailoring it to particular applications or 440 media. Some attributes (the ones listed in Section 6 of this memo) 441 have a defined meaning, but others may be added on an application-, 442 media-, or session-specific basis. An SDP parser MUST ignore any 443 attribute it doesn't understand. 445 An SDP session description may contain URIs that reference external 446 content in the "u=", "k=", and "a=" lines. These URIs may be 447 dereferenced in some cases, making the session description non-self- 448 contained. 450 The connection ("c=") information in the session-level section 451 applies to all the media of that session unless overridden by 452 connection information in the media description. For instance, in 453 the example below, each audio media behaves as if it were given a 454 "c=IN IP4 233.252.0.2". 456 An example SDP description is: 458 v=0 459 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 460 s=SDP Seminar 461 i=A Seminar on the session description protocol 462 u=http://www.example.com/seminars/sdp.pdf 463 e=j.doe@example.com (Jane Doe) 464 c=IN IP4 233.252.0.2 465 t=2873397496 2873404696 466 a=recvonly 467 m=audio 49170 RTP/AVP 0 468 m=audio 49180 RTP/AVP 0 469 m=video 51372 RTP/AVP 99 470 c=IN IP4 233.252.0.1/127 471 a=rtpmap:99 h263-1998/90000 473 Text fields such as the session name and information are octet 474 strings that may contain any octet with the exceptions of 0x00 (Nul), 475 0x0a (ASCII newline), and 0x0d (ASCII carriage return). The sequence 476 CRLF (0x0d0a) is used to end a record, although parsers SHOULD be 477 tolerant and also accept records terminated with a single newline 478 character. If the "a=charset" attribute is not present, these octet 479 strings MUST be interpreted as containing ISO-10646 characters in 480 UTF-8 encoding (the presence of the "a=charset" attribute may force 481 some fields to be interpreted differently). 483 A session description can contain domain names in the "o=", "u=", 484 "e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply 485 with [RFC1034], [RFC1035]. Internationalised domain names (IDNs) 486 MUST be represented using the ASCII Compatible Encoding (ACE) form 487 defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or 488 any other encoding (this requirement is for compatibility with 489 [RFC4566] and other early SDP-related standards, which predate the 490 development of internationalised domain names). 492 5.1. Protocol Version ("v=") 494 v=0 496 The "v=" field gives the version of the Session Description Protocol. 497 This memo defines version 0. There is no minor version number. 499 5.2. Origin ("o=") 501 o= 502 504 The "o=" field gives the originator of the session (her username and 505 the address of the user's host) plus a session identifier and version 506 number: 508 is the user's login on the originating host, or it is "-" 509 if the originating host does not support the concept of user IDs. 510 The MUST NOT contain spaces. 512 is a numeric string such that the tuple of , 513 , , , and forms a 514 globally unique identifier for the session. The method of allocation is up to the creating tool, but it has been 516 suggested that a Network Time Protocol (NTP) format timestamp be 517 used to ensure uniqueness [RFC5905]. 519 is a version number for this session description. 520 Its usage is up to the creating tool, so long as is 521 increased when a modification is made to the session data. Again, 522 it is RECOMMENDED that an NTP format timestamp is used. 524 is a text string giving the type of network. Initially 525 "IN" is defined to have the meaning "Internet", but other values 526 MAY be registered in the future (see Section 8). 528 is a text string giving the type of the address that 529 follows. Initially "IP4" and "IP6" are defined, but other values 530 MAY be registered in the future (see Section 8). 532 is an address of the machine from which the 533 session was created. For an address type of IP4, this is either a 534 fully qualified domain name of the machine or the dotted-decimal 535 representation of an IP version 4 address of the machine. For an 536 address type of IP6, this is either a fully qualified domain name 537 of the machine or the compressed textual representation of an IP 538 version 6 address of the machine. For both IP4 and IP6, the fully 539 qualified domain name is the form that SHOULD be given unless this 540 is unavailable, in which case a globally unique address MAY be 541 substituted. Unless an SDP extension for NAT traversal is used 542 (e.g., ICE [RFC5245], ICE TCP [RFC6544]), a local IP address MUST 543 NOT be used in any context where the SDP description might leave 544 the scope in which the address is meaningful (for example, a local 545 address MUST NOT be included in an application-level referral that 546 might leave the scope). 548 In general, the "o=" field serves as a globally unique identifier for 549 this version of this session description, and the subfields excepting 550 the version taken together identify the session irrespective of any 551 modifications. 553 For privacy reasons, it is sometimes desirable to obfuscate the 554 username and IP address of the session originator. If this is a 555 concern, an arbitrary and private MAY be 556 chosen to populate the "o=" field, provided that these are selected 557 in a manner that does not affect the global uniqueness of the field. 559 5.3. Session Name ("s=") 561 s= 563 The "s=" field is the textual session name. There MUST be one and 564 only one "s=" field per session description. The "s=" field MUST NOT 565 be empty and SHOULD contain ISO 10646 characters (but see also the 566 "a=charset" attribute). If a session has no meaningful name, the 567 value "s= " SHOULD be used (i.e., a single space as the session 568 name). 570 5.4. Session Information ("i=") 572 i= 574 The "i=" field provides textual information about the session. There 575 MUST be at most one session-level "i=" field per session description, 576 and at most one "i=" field per media. If the "a=charset" attribute 577 is present, it specifies the character set used in the "i=" field. 578 If the "a=charset" attribute is not present, the "i=" field MUST 579 contain ISO 10646 characters in UTF-8 encoding. 581 A single "i=" field MAY also be used for each media definition. In 582 media definitions, "i=" fields are primarily intended for labelling 583 media streams. As such, they are most likely to be useful when a 584 single session has more than one distinct media stream of the same 585 media type. An example would be two different whiteboards, one for 586 slides and one for feedback and questions. 588 The "i=" field is intended to provide a free-form human-readable 589 description of the session or the purpose of a media stream. It is 590 not suitable for parsing by automata. 592 5.5. URI ("u=") 594 u= 596 A URI is a Uniform Resource Identifier as used by WWW clients 597 [RFC3986]. The URI should be a pointer to additional information 598 about the session. This field is OPTIONAL, but if it is present it 599 MUST be specified before the first media field. No more than one URI 600 field is allowed per session description. 602 5.6. Email Address and Phone Number ("e=" and "p=") 604 e= 605 p= 607 The "e=" and "p=" lines specify contact information for the person 608 responsible for the session. This is not necessarily the same person 609 that created the session description. 611 Inclusion of an email address or phone number is OPTIONAL. Note that 612 the previous version of SDP specified that either an email field or a 613 phone field MUST be specified, but this was widely ignored. The 614 change brings the specification into line with common usage. 616 If an email address or phone number is present, it MUST be specified 617 before the first media field. More than one email or phone field can 618 be given for a session description. 620 Phone numbers SHOULD be given in the form of an international public 621 telecommunication number (see ITU-T Recommendation E.164) preceded by 622 a "+". Spaces and hyphens may be used to split up a phone field to 623 aid readability if desired. For example: 625 p=+1 617 555-6011 627 Both email addresses and phone numbers can have an OPTIONAL free text 628 string associated with them, normally giving the name of the person 629 who may be contacted. This MUST be enclosed in parentheses if it is 630 present. For example: 632 e=j.doe@example.com (Jane Doe) 634 The alternative [RFC5322] name quoting convention is also allowed for 635 both email addresses and phone numbers. For example: 637 e=Jane Doe 639 The free text string SHOULD be in the ISO-10646 character set with 640 UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if 641 the appropriate session-level "a=charset" attribute is set. 643 5.7. Connection Data ("c=") 645 c= 647 The "c=" field contains connection data. 649 A session description MUST contain either at least one "c=" field in 650 each media description or a single "c=" field at the session level. 651 It MAY contain a single session-level "c=" field and additional "c=" 652 field(s) per media description, in which case the per-media values 653 override the session-level settings for the respective media. 655 The first sub-field ("") is the network type, which is a 656 text string giving the type of network. Initially, "IN" is defined 657 to have the meaning "Internet", but other values MAY be registered in 658 the future (see Section 8). 660 The second sub-field ("") is the address type. This allows 661 SDP to be used for sessions that are not IP based. This memo only 662 defines IP4 and IP6, but other values MAY be registered in the future 663 (see Section 8). 665 The third sub-field ("") is the connection 666 address. OPTIONAL sub-fields MAY be added after the connection 667 address depending on the value of the field. 669 When the is IP4 and IP6, the connection address is defined 670 as follows: 672 o If the session is multicast, the connection address will be an IP 673 multicast group address. If the session is not multicast, then 674 the connection address contains the unicast IP address of the 675 expected data source or data relay or data sink as determined by 676 additional attribute fields. It is not expected that unicast 677 addresses will be given in a session description that is 678 communicated by a multicast announcement, though this is not 679 prohibited. 681 o Sessions using an IP4 multicast connection address MUST also have 682 a time to live (TTL) value present in addition to the multicast 683 address. The TTL and the address together define the scope with 684 which multicast packets sent in this session will be sent. TTL 685 values MUST be in the range 0-255. Although the TTL MUST be 686 specified, its use to scope multicast traffic is deprecated; 687 applications SHOULD use an administratively scoped address 688 instead. 690 The TTL for the session is appended to the address using a slash as a 691 separator. An example is: 693 c=IN IP4 233.252.0.1/127 695 IP6 multicast does not use TTL scoping, and hence the TTL value MUST 696 NOT be present for IP6 multicast. It is expected that IP6 scoped 697 addresses will be used to limit the scope of conferences. 699 Hierarchical or layered encoding schemes are data streams where the 700 encoding from a single media source is split into a number of layers. 701 The receiver can choose the desired quality (and hence bandwidth) by 702 only subscribing to a subset of these layers. Such layered encodings 703 are normally transmitted in multiple multicast groups to allow 704 multicast pruning. This technique keeps unwanted traffic from sites 705 only requiring certain levels of the hierarchy. For applications 706 requiring multiple multicast groups, we allow the following notation 707 to be used for the connection address: 709 [/]/ 711 If the number of addresses is not given, it is assumed to be one. 712 Multicast addresses so assigned are contiguously allocated above the 713 base address, so that, for example: 715 c=IN IP4 233.252.0.1/127/3 717 would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3 718 are to be used at a TTL of 127. This is semantically identical to 719 including multiple "c=" lines in a media description: 721 c=IN IP4 233.252.0.1/127 722 c=IN IP4 233.252.0.2/127 723 c=IN IP4 233.252.0.3/127 725 Similarly, an IP6 example would be: 727 c=IN IP6 FF15::101/3 729 which is semantically equivalent to: 731 c=IN IP6 FF15::101 732 c=IN IP6 FF15::102 733 c=IN IP6 FF15::103 735 (remembering that the TTL field is not present in IP6 multicast). 737 Multiple addresses or "c=" lines MAY be specified on a per-media 738 basis only if they provide multicast addresses for different layers 739 in a hierarchical or layered encoding scheme. They MUST NOT be 740 specified for a session-level "c=" field. 742 The slash notation for multiple addresses described above MUST NOT be 743 used for IP unicast addresses. 745 5.8. Bandwidth ("b=") 747 b=: 749 This OPTIONAL field denotes the proposed bandwidth to be used by the 750 session or media. The is an alphanumeric modifier giving 751 the meaning of the figure. Two values are defined in 752 this specification, but other values MAY be registered in the future 753 (see Section 8 and [RFC3556], [RFC3890]): 755 CT If the bandwidth of a session or media in a session is different 756 from the bandwidth implicit from the scope, a "b=CT:..." line 757 SHOULD be supplied for the session giving the proposed upper limit 758 to the bandwidth used (the "conference total" bandwidth). The 759 primary purpose of this is to give an approximate idea as to 760 whether two or more sessions can coexist simultaneously. When 761 using the CT modifier with RTP, if several RTP sessions are part 762 of the conference, the conference total refers to total bandwidth 763 of all RTP sessions. 765 AS The bandwidth is interpreted to be application specific (it will 766 be the application's concept of maximum bandwidth). Normally, 767 this will coincide with what is set on the application's "maximum 768 bandwidth" control if applicable. For RTP-based applications, AS 769 gives the RTP "session bandwidth" as defined in Section 6.2 of 770 [RFC3550]. 772 Note that CT gives a total bandwidth figure for all the media at all 773 sites. AS gives a bandwidth figure for a single media at a single 774 site, although there may be many sites sending simultaneously. 776 A prefix "X-" is defined for names. This is intended for 777 experimental purposes only. For example: 779 b=X-YZ:128 781 Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers 782 SHOULD be registered with IANA in the standard namespace. SDP 783 parsers MUST ignore bandwidth fields with unknown modifiers. 784 Modifiers MUST be alphanumeric and, although no length limit is 785 given, it is recommended that they be short. 787 The is interpreted as kilobits per second by default. 788 The definition of a new modifier MAY specify that the 789 bandwidth is to be interpreted in some alternative unit (the "CT" and 790 "AS" modifiers defined in this memo use the default units). 792 5.9. Timing ("t=") 794 t= 796 The "t=" lines specify the start and stop times for a session. 797 Multiple "t=" lines MAY be used if a session is active at multiple 798 irregularly spaced times; each additional "t=" line specifies an 799 additional period of time for which the session will be active. If 800 the session is active at regular times, an "r=" line (see below) 801 should be used in addition to, and following, a "t=" line -- in which 802 case the "t=" line specifies the start and stop times of the repeat 803 sequence. 805 The first and second sub-fields give the start and stop times, 806 respectively, for the session. These values are the decimal 807 representation of Network Time Protocol (NTP) time values in seconds 808 since 1900 [RFC5905]. To convert these values to UNIX time, subtract 809 decimal 2208988800. 811 NTP timestamps are elsewhere represented by 64-bit values, which wrap 812 sometime in the year 2036. Since SDP uses an arbitrary length 813 decimal representation, this should not cause an issue (SDP 814 timestamps MUST continue counting seconds since 1900, NTP will use 815 the value modulo the 64-bit limit). 817 If the is set to zero, then the session is not bounded, 818 though it will not become active until after the . If 819 the is also zero, the session is regarded as permanent. 821 User interfaces SHOULD strongly discourage the creation of unbounded 822 and permanent sessions as they give no information about when the 823 session is actually going to terminate, and so make scheduling 824 difficult. 826 The general assumption may be made, when displaying unbounded 827 sessions that have not timed out to the user, that an unbounded 828 session will only be active until half an hour from the current time 829 or the session start time, whichever is the later. If behaviour 830 other than this is required, an end-time SHOULD be given and modified 831 as appropriate when new information becomes available about when the 832 session should really end. 834 Permanent sessions may be shown to the user as never being active 835 unless there are associated repeat times that state precisely when 836 the session will be active. 838 5.10. Repeat Times ("r=") 840 r= 842 "r=" fields specify repeat times for a session. For example, if a 843 session is active at 10am on Monday and 11am on Tuesday for one hour 844 each week for three months, then the in the 845 corresponding "t=" field would be the NTP representation of 10am on 846 the first Monday, the would be 1 week, the would be 1 hour, and the offsets would be zero and 25 848 hours. The corresponding "t=" field stop time would be the NTP 849 representation of the end of the last session three months later. By 850 default, all fields are in seconds, so the "r=" and "t=" fields might 851 be the following: 853 t=3034423619 3042462419 854 r=604800 3600 0 90000 856 To make the description more compact, times may also be given in 857 units of days, hours, or minutes. The syntax for these is a number 858 immediately followed by a single case-sensitive character. 859 Fractional units are not allowed -- a smaller unit should be used 860 instead. The following unit specification characters are allowed: 862 d - days (86400 seconds) 863 h - hours (3600 seconds) 864 m - minutes (60 seconds) 865 s - seconds (allowed for completeness) 867 Thus, the above session announcement could also have been written: 869 r=7d 1h 0 25h 871 Monthly and yearly repeats cannot be directly specified with a single 872 SDP repeat time; instead, separate "t=" fields should be used to 873 explicitly list the session times. 875 5.11. Time Zones ("z=") 877 z= .... 879 To schedule a repeated session that spans a change from daylight 880 saving time to standard time or vice versa, it is necessary to 881 specify offsets from the base time. This is required because 882 different time zones change time at different times of day, different 883 countries change to or from daylight saving time on different dates, 884 and some countries do not have daylight saving time at all. 886 Thus, in order to schedule a session that is at the same time winter 887 and summer, it must be possible to specify unambiguously by whose 888 time zone a session is scheduled. To simplify this task for 889 receivers, we allow the sender to specify the NTP time that a time 890 zone adjustment happens and the offset from the time when the session 891 was first scheduled. The "z=" field allows the sender to specify a 892 list of these adjustment times and offsets from the base time. 894 An example might be the following: 896 z=2882844526 -1h 2898848070 0 898 This specifies that at time 2882844526, the time base by which the 899 session's repeat times are calculated is shifted back by 1 hour, and 900 that at time 2898848070, the session's original time base is 901 restored. Adjustments are always relative to the specified start 902 time -- they are not cumulative. Adjustments apply to all "t=" and 903 "r=" lines in a session description. 905 If a session is likely to last several years, it is expected that the 906 session description will be modified periodically rather than 907 transmit several years' worth of adjustments in one session 908 description. 910 5.12. Encryption Keys ("k=") 912 k= 913 k=: 915 If transported over a secure and trusted channel, the Session 916 Description Protocol MAY be used to convey encryption keys. A simple 917 mechanism for key exchange is provided by the key field ("k="), 918 although this is primarily supported for compatibility with older 919 implementations and its use is NOT RECOMMENDED. Work is in progress 920 to define new key exchange mechanisms for use with SDP [RFC4567] 921 [RFC4568], and it is expected that new applications will use those 922 mechanisms. 924 A key field is permitted before the first media entry (in which case 925 it applies to all media in the session), or for each media entry as 926 required. The format of keys and their usage are outside the scope 927 of this document, and the key field provides no way to indicate the 928 encryption algorithm to be used, key type, or other information about 929 the key: this is assumed to be provided by the higher-level protocol 930 using SDP. If there is a need to convey this information within SDP, 931 the extensions mentioned previously SHOULD be used. Many security 932 protocols require two keys: one for confidentiality, another for 933 integrity. This specification does not support transfer of two keys. 935 The method indicates the mechanism to be used to obtain a usable key 936 by external means, or from the encoded encryption key given. The 937 following methods are defined: 939 k=clear: 941 The encryption key is included untransformed in this key field. 942 This method MUST NOT be used unless it can be guaranteed that 943 the SDP is conveyed over a secure channel. The encryption key 944 is interpreted as text according to the charset attribute; use 945 the "k=base64:" method to convey characters that are otherwise 946 prohibited in SDP. 948 k=base64: 950 The encryption key is included in this key field but has been 951 base64 encoded [RFC4648] because it includes characters that 952 are prohibited in SDP. This method MUST NOT be used unless it 953 can be guaranteed that the SDP is conveyed over a secure 954 channel. 956 k=uri: 958 A Uniform Resource Identifier is included in the key field. 959 The URI refers to the data containing the key, and may require 960 additional authentication before the key can be returned. When 961 a request is made to the given URI, the reply should specify 962 the encoding for the key. The URI is often an Secure Socket 963 Layer/Transport Layer Security (SSL/TLS)-protected HTTP URI 964 ("https:"), although this is not required. 966 k=prompt 968 No key is included in this SDP description, but the session or 969 media stream referred to by this key field is encrypted. The 970 user should be prompted for the key when attempting to join the 971 session, and this user-supplied key should then be used to 972 decrypt the media streams. The use of user-specified keys is 973 NOT RECOMMENDED, since such keys tend to have weak security 974 properties. 976 The key field MUST NOT be used unless it can be guaranteed that the 977 SDP is conveyed over a secure and trusted channel. An example of 978 such a channel might be SDP embedded inside an S/MIME message or a 979 TLS-protected HTTP session. It is important to ensure that the 980 secure channel is with the party that is authorised to join the 981 session, not an intermediary: if a caching proxy server is used, it 982 is important to ensure that the proxy is either trusted or unable to 983 access the SDP. 985 5.13. Attributes ("a=") 987 a= 988 a=: 990 Attributes are the primary means for extending SDP. Attributes may 991 be defined to be used as "session-level" attributes, "media-level" 992 attributes, or both. 994 A media description may have any number of attributes ("a=" fields) 995 that are media specific. These are referred to as "media-level" 996 attributes and add information about the media stream. Attribute 997 fields can also be added before the first media field; these 998 "session-level" attributes convey additional information that applies 999 to the session as a whole rather than to individual media. 1001 Attribute fields may be of two forms: 1003 o A property attribute is simply of the form "a=". These are 1004 binary attributes, and the presence of the attribute conveys that 1005 the attribute is a property of the session. An example might be 1006 "a=recvonly". 1008 o A value attribute is of the form "a=:". For 1009 example, a whiteboard could have the value attribute 1010 "a=orient:landscape" 1012 Attribute interpretation depends on the media tool being invoked. 1013 Thus receivers of session descriptions should be configurable in 1014 their interpretation of session descriptions in general and of 1015 attributes in particular. 1017 Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. 1019 Attribute values are octet strings, and MAY use any octet value 1020 except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute 1021 values are to be interpreted as in ISO-10646 character set with UTF-8 1022 encoding. Unlike other text fields, attribute values are NOT 1023 normally affected by the "charset" attribute as this would make 1024 comparisons against known values problematic. However, when an 1025 attribute is defined, it can be defined to be charset dependent, in 1026 which case its value should be interpreted in the session charset 1027 rather than in ISO-10646. 1029 Attributes MUST be registered with IANA (see Section 8). If an 1030 attribute is received that is not understood, it MUST be ignored by 1031 the receiver. 1033 5.14. Media Descriptions ("m=") 1035 m= ... 1037 A session description may contain a number of media descriptions. 1038 Each media description starts with an "m=" field and is terminated by 1039 either the next "m=" field or by the end of the session description. 1040 A media field has several sub-fields: 1042 is the media type. Currently defined media are "audio", 1043 "video", "text", "application", and "message", although this list 1044 may be extended in the future (see Section 8). 1046 is the transport port to which the media stream is sent. The 1047 meaning of the transport port depends on the network being used as 1048 specified in the relevant "c=" field, and on the transport 1049 protocol defined in the sub-field of the media field. 1050 Other ports used by the media application (such as the RTP Control 1051 Protocol (RTCP) port [RFC3550]) MAY be derived algorithmically 1052 from the base media port or MAY be specified in a separate 1053 attribute (for example, "a=rtcp:" as defined in [RFC3605]). 1055 If non-contiguous ports are used or if they don't follow the 1056 parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" 1057 attribute MUST be used. Applications that are requested to send 1058 media to a that is odd and where the "a=rtcp:" is present 1059 MUST NOT subtract 1 from the RTP port: that is, they MUST send the 1060 RTP to the port indicated in and send the RTCP to the port 1061 indicated in the "a=rtcp" attribute. 1063 For applications where hierarchically encoded streams are being 1064 sent to a unicast address, it may be necessary to specify multiple 1065 transport ports. This is done using a similar notation to that 1066 used for IP multicast addresses in the "c=" field: 1068 m= / ... 1070 In such a case, the ports used depend on the transport protocol. 1071 For RTP, the default is that only the even-numbered ports are used 1072 for data with the corresponding one-higher odd ports used for the 1073 RTCP belonging to the RTP session, and the 1074 denoting the number of RTP sessions. For example: 1076 m=video 49170/2 RTP/AVP 31 1078 would specify that ports 49170 and 49171 form one RTP/RTCP pair 1079 and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the 1080 transport protocol and 31 is the format (see below). If non- 1081 contiguous ports are required, they must be signalled using a 1082 separate attribute (for example, "a=rtcp:" as defined in 1083 [RFC3605]). 1085 If multiple addresses are specified in the "c=" field and multiple 1086 ports are specified in the "m=" field, a one-to-one mapping from 1087 port to the corresponding address is implied. For example: 1089 c=IN IP4 233.252.0.1/127/2 1090 m=video 49170/2 RTP/AVP 31 1092 would imply that address 233.252.0.1 is used with ports 49170 and 1093 49171, and address 233.252.0.2 is used with ports 49172 and 49173. 1095 The semantics of multiple "m=" lines using the same transport 1096 address are undefined. This implies that, unlike limited past 1097 practice, there is no implicit grouping defined by such means and 1098 an explicit grouping framework (for example, [RFC5888]) should 1099 instead be used to express the intended semantics. 1101 is the transport protocol. The meaning of the transport 1102 protocol is dependent on the address type field in the relevant 1103 "c=" field. Thus a "c=" field of IP4 indicates that the transport 1104 protocol runs over IP4. The following transport protocols are 1105 defined, but may be extended through registration of new protocols 1106 with IANA (see Section 8): 1108 * udp: denotes an unspecified protocol running over UDP. 1110 * RTP/AVP: denotes RTP [RFC3550] used under the RTP Profile for 1111 Audio and Video Conferences with Minimal Control [RFC3551] 1112 running over UDP. 1114 * RTP/SAVP: denotes the Secure Real-time Transport Protocol 1115 [RFC3711] running over UDP. 1117 The main reason to specify the transport protocol in addition to 1118 the media format is that the same standard media formats may be 1119 carried over different transport protocols even when the network 1120 protocol is the same -- a historical example is vat Pulse Code 1121 Modulation (PCM) audio and RTP PCM audio; another might be TCP/RTP 1122 PCM audio. In addition, relays and monitoring tools that are 1123 transport-protocol-specific but format-independent are possible. 1125 is a media format description. The fourth and any subsequent 1126 sub-fields describe the format of the media. The interpretation 1127 of the media format depends on the value of the sub-field. 1129 If the sub-field is "RTP/AVP" or "RTP/SAVP" the sub- 1130 fields contain RTP payload type numbers. When a list of payload 1131 type numbers is given, this implies that all of these payload 1132 formats MAY be used in the session, but the first of these formats 1133 SHOULD be used as the default format for the session. For dynamic 1134 payload type assignments the "a=rtpmap:" attribute (see Section 6) 1135 SHOULD be used to map from an RTP payload type number to a media 1136 encoding name that identifies the payload format. The "a=fmtp:" 1137 attribute MAY be used to specify format parameters (see 1138 Section 6). 1140 If the sub-field is "udp" the sub-fields MUST 1141 reference a media type describing the format under the "audio", 1142 "video", "text", "application", or "message" top-level media 1143 types. The media type registration SHOULD define the packet 1144 format for use with UDP transport. 1146 For media using other transport protocols, the field is 1147 protocol specific. Rules for interpretation of the sub- 1148 field MUST be defined when registering new protocols (see 1149 Section 8.2.2). 1151 Section 3 of [RFC4855] states that the payload format (encoding) 1152 names defined in the RTP Profile are commonly shown in upper case, 1153 while media subtype names are commonly shown in lower case. It 1154 also states that both of these names are case-insensitive in both 1155 places, similar to parameter names which are case-insensitive both 1156 in media type strings and in the default mapping to the SDP a=fmtp 1157 attribute. 1159 6. SDP Attributes 1161 The following attributes are defined. Since application writers may 1162 add new attributes as they are required, this list is not exhaustive. 1163 Registration procedures for new attributes are defined in 1164 Section 8.2.4. 1166 a=cat: 1168 This attribute gives the dot-separated hierarchical category of 1169 the session. This is to enable a receiver to filter unwanted 1170 sessions by category. There is no central registry of 1171 categories. It is a session-level attribute, and it is not 1172 dependent on charset. 1174 a=keywds: 1176 Like the cat attribute, this is to assist identifying wanted 1177 sessions at the receiver. This allows a receiver to select 1178 interesting session based on keywords describing the purpose of 1179 the session; there is no central registry of keywords. It is a 1180 session-level attribute. It is a charset-dependent attribute, 1181 meaning that its value should be interpreted in the charset 1182 specified for the session description if one is specified, or 1183 by default in ISO 10646/UTF-8. 1185 a=tool: 1187 This gives the name and version number of the tool used to 1188 create the session description. It is a session-level 1189 attribute, and it is not dependent on charset. 1191 a=ptime: 1193 This gives the length of time in milliseconds represented by 1194 the media in a packet. This is probably only meaningful for 1195 audio data, but may be used with other media types if it makes 1196 sense. It should not be necessary to know ptime to decode RTP 1197 or vat audio, and it is intended as a recommendation for the 1198 encoding/packetisation of audio. It is a media-level 1199 attribute, and it is not dependent on charset. 1201 a=maxptime: 1203 This gives the maximum amount of media that can be encapsulated 1204 in each packet, expressed as time in milliseconds. The time 1205 SHALL be calculated as the sum of the time the media present in 1206 the packet represents. For frame-based codecs, the time SHOULD 1207 be an integer multiple of the frame size. This attribute is 1208 probably only meaningful for audio data, but may be used with 1209 other media types if it makes sense. It is a media-level 1210 attribute, and it is not dependent on charset. Note that this 1211 attribute was introduced after [RFC2327], and non-updated 1212 implementations will ignore this attribute. 1214 a=rtpmap: / [/] 1217 This attribute maps from an RTP payload type number (as used in 1218 an "m=" line) to an encoding name denoting the payload format 1219 to be used. It also provides information on the clock rate and 1220 encoding parameters. It is a media-level attribute that is not 1221 dependent on charset. 1223 Although an RTP profile may make static assignments of payload 1224 type numbers to payload formats, it is more common for that 1225 assignment to be done dynamically using "a=rtpmap:" attributes. 1226 As an example of a static payload type, consider u-law PCM 1227 coded single-channel audio sampled at 8 kHz. This is 1228 completely defined in the RTP Audio/Video profile as payload 1229 type 0, so there is no need for an "a=rtpmap:" attribute, and 1230 the media for such a stream sent to UDP port 49232 can be 1231 specified as: 1233 m=audio 49232 RTP/AVP 0 1235 An example of a dynamic payload type is 16-bit linear encoded 1236 stereo audio sampled at 16 kHz. If we wish to use the dynamic 1237 RTP/AVP payload type 98 for this stream, additional information 1238 is required to decode it: 1240 m=audio 49232 RTP/AVP 98 1241 a=rtpmap:98 L16/16000/2 1243 Up to one rtpmap attribute can be defined for each media format 1244 specified. Thus, we might have the following: 1246 m=audio 49230 RTP/AVP 96 97 98 1247 a=rtpmap:96 L8/8000 1248 a=rtpmap:97 L16/8000 1249 a=rtpmap:98 L16/11025/2 1251 RTP profiles that specify the use of dynamic payload types MUST 1252 define the set of valid encoding names and/or a means to 1253 register encoding names if that profile is to be used with SDP. 1254 The "RTP/AVP" and "RTP/SAVP" profiles use media subtypes for 1255 encoding names, under the top-level media type denoted in the 1256 "m=" line. In the example above, the media types are "audio/ 1257 l8" and "audio/l16". 1259 For audio streams, indicates the number 1260 of audio channels. This parameter is OPTIONAL and may be 1261 omitted if the number of channels is one, provided that no 1262 additional parameters are needed. 1264 For video streams, no encoding parameters are currently 1265 specified. 1267 Additional encoding parameters MAY be defined in the future, 1268 but codec-specific parameters SHOULD NOT be added. Parameters 1269 added to an "a=rtpmap:" attribute SHOULD only be those required 1270 for a session directory to make the choice of appropriate media 1271 to participate in a session. Codec-specific parameters should 1272 be added in other attributes (for example, "a=fmtp:"). 1274 Note: RTP audio formats typically do not include information 1275 about the number of samples per packet. If a non-default (as 1276 defined in the RTP Audio/Video Profile) packetisation is 1277 required, the "ptime" attribute is used as given above. 1279 a=recvonly, a=sendrecv, a=sendonly, a=inactive 1281 At most one of recvonly/sendrecv/sendonly/inactive MAY appear 1282 at session level, and at most one MAY appear in each media 1283 section. 1285 If any one of these appears in a media section then it applies 1286 for that media section. If none appear in a media section then 1287 the one from session level, if any, applies to that media 1288 section. 1290 If none of the attributes "sendonly", "recvonly", "inactive", 1291 and "sendrecv" is present at either session level or media 1292 level, "sendrecv" SHOULD be assumed as the default for sessions 1293 that are not of the conference type "broadcast" or "H332" (see 1294 below). 1296 Within the following SDP example, the "inactive" attribute 1297 applies to audio media and the "recvonly" attribute applies to 1298 video media. 1300 v=0 1301 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 1302 s=SDP Seminar 1303 i=A Seminar on the session description protocol 1304 u=http://www.example.com/seminars/sdp.pdf 1305 e=j.doe@example.com (Jane Doe) 1306 c=IN IP4 233.252.0.1/127 1307 t=2873397496 2873404696 1308 a=inactive 1309 m=audio 49170 RTP/AVP 0 1310 m=video 51372 RTP/AVP 99 1311 a=rtpmap:99 h263-1998/90000 1312 a=recvonly 1314 a=recvonly 1316 This specifies that the tools should be started in receive-only 1317 mode where applicable. It can be either a session- or media- 1318 level attribute, and it is not dependent on charset. Note that 1319 recvonly applies to the media only, not to any associated 1320 control protocol (e.g., an RTP-based system in recvonly mode 1321 SHOULD still send RTCP packets). 1323 a=sendrecv 1325 This specifies that the tools should be started in send and 1326 receive mode. This is necessary for interactive conferences 1327 with tools that default to receive-only mode. It can be either 1328 a session or media-level attribute, and it is not dependent on 1329 charset. 1331 a=sendonly 1333 This specifies that the tools should be started in send-only 1334 mode. An example may be where a different unicast address is 1335 to be used for a traffic destination than for a traffic source. 1336 In such a case, two media descriptions may be used, one 1337 sendonly and one recvonly. It can be either a session- or 1338 media-level attribute, but would normally only be used as a 1339 media attribute. It is not dependent on charset. Note that 1340 sendonly applies only to the media, and any associated control 1341 protocol (e.g., RTCP) SHOULD still be received and processed as 1342 normal. 1344 a=inactive 1346 This specifies that the tools should be started in inactive 1347 mode. This is necessary for interactive conferences where 1348 users can put other users on hold. No media is sent over an 1349 inactive media stream. Note that an RTP-based system SHOULD 1350 still send RTCP, even if started inactive. It can be either a 1351 session or media-level attribute, and it is not dependent on 1352 charset. 1354 a=orient: 1356 Normally this is only used for a whiteboard or presentation 1357 tool. It specifies the orientation of a the workspace on the 1358 screen. It is a media-level attribute. Permitted values are 1359 "portrait", "landscape", and "seascape" (upside-down 1360 landscape). It is not dependent on charset. 1362 a=type: 1364 This specifies the type of the conference. Suggested values 1365 are "broadcast", "meeting", "moderated", "test", and "H332". 1366 "recvonly" should be the default for "type:broadcast" sessions, 1367 "type:meeting" should imply "sendrecv", and "type:moderated" 1368 should indicate the use of a floor control tool and that the 1369 media tools are started so as to mute new sites joining the 1370 conference. 1372 Specifying the attribute "type:H332" indicates that this 1373 loosely coupled session is part of an H.332 session as defined 1374 in the ITU H.332 specification [ITU.H332.1998]. Media tools 1375 should be started "recvonly". 1377 Specifying the attribute "type:test" is suggested as a hint 1378 that, unless explicitly requested otherwise, receivers can 1379 safely avoid displaying this session description to users. 1381 The type attribute is a session-level attribute, and it is not 1382 dependent on charset. 1384 a=charset: 1386 This specifies the character set to be used to display the 1387 session name and information data. By default, the ISO-10646 1388 character set in UTF-8 encoding is used. If a more compact 1389 representation is required, other character sets may be used. 1390 For example, the ISO 8859-1 is specified with the following SDP 1391 attribute: 1393 a=charset:ISO-8859-1 1395 This is a session-level attribute and is not dependent on 1396 charset. The charset specified MUST be one of those registered 1397 with IANA, such as ISO-8859-1. The character set identifier is 1398 a US-ASCII string and MUST be compared against the IANA 1399 identifiers using a case-insensitive comparison. If the 1400 identifier is not recognised or not supported, all strings that 1401 are affected by it SHOULD be regarded as octet strings. 1403 Note that a character set specified MUST still prohibit the use 1404 of bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets 1405 requiring the use of these characters MUST define a quoting 1406 mechanism that prevents these bytes from appearing within text 1407 fields. 1409 a=sdplang: 1411 This can be a session-level attribute or a media-level 1412 attribute. Multiple sdplang attributes can be provided either 1413 at session or media level if the session description or media 1414 use multiple languages. 1416 As a session-level attribute, it specifies the language for the 1417 session description. As a media-level attribute, it specifies 1418 the language for any media-level SDP information field 1419 associated with that media, overriding any sdplang attributes 1420 specified at session-level. 1422 In general, sending session descriptions consisting of multiple 1423 languages is discouraged. Instead, multiple descriptions 1424 SHOULD be sent describing the session, one in each language. 1425 However, this is not possible with all transport mechanisms, 1426 and so multiple sdplang attributes are allowed although NOT 1427 RECOMMENDED. 1429 The "sdplang" attribute value must be a single [RFC5646] 1430 language tag in US-ASCII. It is not dependent on the charset 1431 attribute. An "sdplang" attribute SHOULD be specified when a 1432 session is distributed with sufficient scope to cross 1433 geographic boundaries, where the language of recipients cannot 1434 be assumed, or where the session is in a different language 1435 from the locally assumed norm. 1437 a=lang: 1439 This can be a session-level attribute or a media-level 1440 attribute. Multiple lang attributes can be provided either at 1441 session or media level if the session or media use multiple 1442 languages, in which case the order of the attributes indicates 1443 the order of importance of the various languages in the session 1444 or media, from most important to least important. 1446 As a session-level attribute, it specifies the default language 1447 for the session being described. As a media-level attribute, 1448 it specifies the language for that media, overriding any 1449 session-level languages specified. 1451 The "lang" attribute value must be a single [RFC5646] language 1452 tag in US-ASCII. It is not dependent on the charset attribute. 1453 A "lang" attribute SHOULD be specified when a session is of 1454 sufficient scope to cross geographic boundaries where the 1455 language of recipients cannot be assumed, or where the session 1456 is in a different language from the locally assumed norm. 1458 a=framerate: 1460 This gives the maximum video frame rate in frames/sec. It is 1461 intended as a recommendation for the encoding of video data. 1462 Decimal representations of fractional values using the notation 1463 "." are allowed. It is a media-level 1464 attribute, defined only for video media, and it is not 1465 dependent on charset. 1467 a=quality: 1469 This gives a suggestion for the quality of the encoding as an 1470 integer value. The intention of the quality attribute for 1471 video is to specify a non-default trade-off between frame-rate 1472 and still-image quality. For video, the value is in the range 1473 0 to 10, with the following suggested meaning: 1475 10 - the best still-image quality the compression scheme 1476 can give. 1477 5 - the default behaviour given no quality suggestion. 1478 0 - the worst still-image quality the codec designer 1479 thinks is still usable. 1481 It is a media-level attribute, and it is not dependent on 1482 charset. 1484 a=fmtp: 1486 This attribute allows parameters that are specific to a 1487 particular format to be conveyed in a way that SDP does not 1488 have to understand them. The format must be one of the formats 1489 specified for the media. Format-specific parameters may be any 1490 set of parameters required to be conveyed by SDP and given 1491 unchanged to the media tool that will use this format. At most 1492 one instance of this attribute is allowed for each format. 1494 It is a media-level attribute, and it is not dependent on 1495 charset. 1497 7. Security Considerations 1499 SDP is frequently used with the Session Initiation Protocol [RFC3261] 1500 using the offer/answer model [RFC3264] to agree on parameters for 1501 unicast sessions. When used in this manner, the security 1502 considerations of those protocols apply. 1504 SDP is a session description format that describes multimedia 1505 sessions. Entities receiving and acting upon an SDP message SHOULD 1506 be aware that a session description cannot be trusted unless it has 1507 been obtained by an authenticated transport protocol from a known and 1508 trusted source. Many different transport protocols may be used to 1509 distribute session descriptions, and the nature of the authentication 1510 will differ from transport to transport. For some transports, 1511 security features are often not deployed. In case a session 1512 description has not been obtained in a trusted manner, the endpoint 1513 SHOULD exercise care because, among other attacks, the media sessions 1514 received may not be the intended ones, the destination where media is 1515 sent to may not be the expected one, any of the parameters of the 1516 session may be incorrect, or the media security may be compromised. 1517 It is up to the endpoint to make a sensible decision taking into 1518 account the security risks of the application and the user 1519 preferences and may decide to ask the user whether or not to accept 1520 the session. 1522 One transport that can be used to distribute session descriptions is 1523 the Session Announcement Protocol (SAP). SAP provides both 1524 encryption and authentication mechanisms, but due to the nature of 1525 session announcements it is likely that there are many occasions 1526 where the originator of a session announcement cannot be 1527 authenticated because the originator is previously unknown to the 1528 receiver of the announcement and because no common public key 1529 infrastructure is available. 1531 On receiving a session description over an unauthenticated transport 1532 mechanism or from an untrusted party, software parsing the session 1533 should take a few precautions. Session descriptions contain 1534 information required to start software on the receiver's system. 1535 Software that parses a session description MUST NOT be able to start 1536 other software except that which is specifically configured as 1537 appropriate software to participate in multimedia sessions. It is 1538 normally considered inappropriate for software parsing a session 1539 description to start, on a user's system, software that is 1540 appropriate to participate in multimedia sessions, without the user 1541 first being informed that such software will be started and giving 1542 the user's consent. Thus, a session description arriving by session 1543 announcement, email, session invitation, or WWW page MUST NOT deliver 1544 the user into an interactive multimedia session unless the user has 1545 explicitly pre-authorised such action. As it is not always simple to 1546 tell whether or not a session is interactive, applications that are 1547 unsure should assume sessions are interactive. 1549 In this specification, there are no attributes that would allow the 1550 recipient of a session description to be informed to start multimedia 1551 tools in a mode where they default to transmitting. Under some 1552 circumstances it might be appropriate to define such attributes. If 1553 this is done, an application parsing a session description containing 1554 such attributes SHOULD either ignore them or inform the user that 1555 joining this session will result in the automatic transmission of 1556 multimedia data. The default behaviour for an unknown attribute is 1557 to ignore it. 1559 In certain environments, it has become common for intermediary 1560 systems to intercept and analyse session descriptions contained 1561 within other signalling protocols. This is done for a range of 1562 purposes, including but not limited to opening holes in firewalls to 1563 allow media streams to pass, or to mark, prioritize, or block traffic 1564 selectively. In some cases, such intermediary systems may modify the 1565 session description, for example, to have the contents of the session 1566 description match NAT bindings dynamically created. These behaviours 1567 are NOT RECOMMENDED unless the session description is conveyed in 1568 such a manner that allows the intermediary system to conduct proper 1569 checks to establish the authenticity of the session description, and 1570 the authority of its source to establish such communication sessions. 1571 SDP by itself does not include sufficient information to enable these 1572 checks: they depend on the encapsulating protocol (e.g., SIP or 1573 RTSP). 1575 Use of the "k=" field poses a significant security risk, since it 1576 conveys session encryption keys in the clear. SDP MUST NOT be used 1577 to convey key material, unless it can be guaranteed that the channel 1578 over which the SDP is delivered is both private and authenticated. 1579 Moreover, the "k=" line provides no way to indicate or negotiate 1580 cryptographic key algorithms. As it provides for only a single 1581 symmetric key, rather than separate keys for confidentiality and 1582 integrity, its utility is severely limited. The use of the "k=" line 1583 is NOT RECOMMENDED, as discussed in Section 5.12. 1585 8. IANA Considerations 1587 8.1. The "application/sdp" Media Type 1589 One media type registration from [RFC4566] is to be updated, as 1590 defined below. 1592 To: ietf-types@iana.org 1593 Subject: Registration of media type "application/sdp" 1595 Type name: application 1597 Subtype name: sdp 1599 Required parameters: None. 1601 Optional parameters: None. 1603 Encoding considerations: 1604 SDP files are primarily UTF-8 format text. The "a=charset:" 1605 attribute may be used to signal the presence of other character 1606 sets in certain parts of an SDP file (see Section 6 of RFC 1607 XXXX). Arbitrary binary content cannot be directly 1608 represented in SDP. 1610 Security considerations: 1611 See Section 7 of RFC XXXX. 1613 Interoperability considerations: 1614 See RFC XXXX. 1616 Published specification: 1617 See RFC XXXX. 1619 Applications which use this media type: 1620 Voice over IP, video teleconferencing, streaming media, instant 1621 messaging, among others. See also Section 3 of RFC XXXX. 1623 Additional information: 1625 Magic number(s): None. 1626 File extension(s): The extension ".sdp" is commonly used. 1627 Macintosh File Type Code(s): "sdp " 1629 Person & email address to contact for further information: 1630 Mark Handley 1631 Colin Perkins 1632 IETF MMUSIC working group 1634 Intended usage: COMMON 1636 Author/Change controller: 1637 Authors of RFC XXXX 1638 IETF MMUSIC working group delegated from the IESG 1640 8.2. Registration of Parameters 1642 There are seven field names that may be registered with IANA. Using 1643 the terminology in the SDP specification Backus-Naur Form (BNF), they 1644 are "media", "proto", "fmt", "att-field", "bwtype", "nettype", and 1645 "addrtype". 1647 8.2.1. Media Types ("media") 1649 The set of media types is intended to be small and SHOULD NOT be 1650 extended except under rare circumstances. The same rules should 1651 apply for media names as for top-level media types, and where 1652 possible the same name should be registered for SDP as for MIME. For 1653 media other than existing top-level media types, a Standards Track 1654 RFC MUST be produced for a new top-level media type to be registered, 1655 and the registration MUST provide good justification why no existing 1656 media name is appropriate (the "Standards Action" policy of 1657 [RFC5226]. 1659 This memo registers the media types "audio", "video", "text", 1660 "application", and "message". 1662 Note: The media types "control" and "data" were listed as valid in an 1663 early version of this specification (RFC 2327); however, their 1664 semantics were never fully specified and they are not widely used. 1665 These media types have been removed in this specification, although 1666 they still remain valid media type capabilities for a SIP user agent 1667 as defined in [RFC3840]. If these media types are considered useful 1668 in the future, a Standards Track RFC MUST be produced to document 1669 their use. Until that is done, applications SHOULD NOT use these 1670 types and SHOULD NOT declare support for them in SIP capabilities 1671 declarations (even though they exist in the registry created by 1672 [RFC3840]). 1674 8.2.2. Transport Protocols ("proto") 1676 The "proto" field describes the transport protocol used. This SHOULD 1677 reference a standards-track protocol RFC. This memo registers three 1678 values: "RTP/AVP" is a reference to [RFC3550] used under the RTP 1679 Profile for Audio and Video Conferences with Minimal Control 1680 [RFC3551] running over UDP/IP, "RTP/SAVP" is a reference to the 1681 Secure Real-time Transport Protocol [RFC3711], and "udp" indicates an 1682 unspecified protocol over UDP. 1684 If other RTP profiles are defined in the future, their "proto" name 1685 SHOULD be specified in the same manner. For example, an RTP profile 1686 whose short name is "XYZ" would be denoted by a "proto" field of "RTP 1687 /XYZ". 1689 New transport protocols SHOULD be registered with IANA. 1690 Registrations MUST reference an RFC describing the protocol. Such an 1691 RFC MAY be Experimental or Informational, although it is preferable 1692 that it be Standards Track. Registrations MUST also define the rules 1693 by which their "fmt" namespace is managed (see below). 1695 8.2.3. Media Formats ("fmt") 1697 Each transport protocol, defined by the "proto" field, has an 1698 associated "fmt" namespace that describes the media formats that may 1699 be conveyed by that protocol. Formats cover all the possible 1700 encodings that might want to be transported in a multimedia session. 1702 RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST 1703 use the payload type number as their "fmt" value. If the payload 1704 type number is dynamically assigned by this session description, an 1705 additional "rtpmap" attribute MUST be included to specify the format 1706 name and parameters as defined by the media type registration for the 1707 payload format. It is RECOMMENDED that other RTP profiles that are 1708 registered (in combination with RTP) as SDP transport protocols 1709 specify the same rules for the "fmt" namespace. 1711 For the "udp" protocol, new formats SHOULD be registered. Use of an 1712 existing media subtype for the format is encouraged. If no media 1713 subtype exists, it is RECOMMENDED that a suitable one be registered 1714 through the IETF process [RFC6838] by production of, or reference to, 1715 a standards-track RFC that defines the transport protocol for the 1716 format. 1718 For other protocols, formats MAY be registered according to the rules 1719 of the associated "proto" specification. 1721 Registrations of new formats MUST specify which transport protocols 1722 they apply to. 1724 8.2.4. Attribute Names ("att-field") 1726 Attribute field names ("att-field") MUST be registered with IANA and 1727 documented, because of noticeable issues due to conflicting 1728 attributes under the same name. Unknown attributes in SDP are simply 1729 ignored, but conflicting ones that fragment the protocol are a 1730 serious problem. 1732 New attribute registrations are accepted according to the 1733 "Specification Required" policy of [RFC5226], provided that the 1734 specification includes the following information: 1736 o contact name, email address, and telephone number 1737 o attribute name (as it will appear in SDP) 1739 o long-form attribute name in English 1741 o type of attribute (session level, media level, or both) 1743 o whether the attribute value is subject to the charset attribute 1745 o a one-paragraph explanation of the purpose of the attribute 1747 o a specification of appropriate attribute values for this attribute 1749 The above is the minimum that IANA will accept. Attributes that are 1750 expected to see widespread use and interoperability SHOULD be 1751 documented with a standards-track RFC that specifies the attribute 1752 more precisely. 1754 Submitters of registrations should ensure that the specification is 1755 in the spirit of SDP attributes, most notably that the attribute is 1756 platform independent in the sense that it makes no implicit 1757 assumptions about operating systems and does not name specific pieces 1758 of software in a manner that might inhibit interoperability. 1760 IANA has registered the following initial set of attribute names 1761 ("att-field" values), with definitions as in Section 6 of this memo 1762 (these definitions update those in [RFC4566]): 1764 Name | Session or Media level? | Dependent on charset? 1765 ----------+-------------------------+---------------------- 1766 cat | Session | No 1767 keywds | Session | Yes 1768 tool | Session | No 1769 ptime | Media | No 1770 maxptime | Media | No 1771 rtpmap | Media | No 1772 recvonly | Either | No 1773 sendrecv | Either | No 1774 sendonly | Either | No 1775 inactive | Either | No 1776 orient | Media | No 1777 type | Session | No 1778 charset | Session | No 1779 sdplang | Either | No 1780 lang | Either | No 1781 framerate | Media | No 1782 quality | Media | No 1783 fmtp | Media | No 1785 8.2.5. Bandwidth Specifiers ("bwtype") 1787 A proliferation of bandwidth specifiers is strongly discouraged. 1789 New bandwidth specifiers ("bwtype" fields) MUST be registered with 1790 IANA. The submission MUST reference a standards-track RFC specifying 1791 the semantics of the bandwidth specifier precisely, and indicating 1792 when it should be used, and why the existing registered bandwidth 1793 specifiers do not suffice. 1795 IANA has registered the bandwidth specifiers "CT" and "AS" with 1796 definitions as in Section 5.8 of this memo (these definitions update 1797 those in [RFC4566]). 1799 8.2.6. Network Types ("nettype") 1801 New network types (the "nettype" field) may be registered with IANA 1802 if SDP needs to be used in the context of non-Internet environments. 1803 Although these are not normally the preserve of IANA, there may be 1804 circumstances when an Internet application needs to interoperate with 1805 a non-Internet application, such as when gatewaying an Internet 1806 telephone call into the Public Switched Telephone Network (PSTN). 1807 The number of network types should be small and should be rarely 1808 extended. A new network type cannot be registered without 1809 registering at least one address type to be used with that network 1810 type. A new network type registration MUST reference an RFC that 1811 gives details of the network type and address type and specifies how 1812 and when they would be used. 1814 IANA has registered the network type "IN" to represent the Internet, 1815 with definition as in Sections 5.2 and 5.7 of this memo (these 1816 definitions update those in [RFC4566]). 1818 8.2.7. Address Types ("addrtype") 1820 New address types ("addrtype") may be registered with IANA. An 1821 address type is only meaningful in the context of a network type, and 1822 any registration of an address type MUST specify a registered network 1823 type or be submitted along with a network type registration. A new 1824 address type registration MUST reference an RFC giving details of the 1825 syntax of the address type. Address types are not expected to be 1826 registered frequently. 1828 IANA has registered the address types "IP4" and "IP6" with 1829 definitions as in Sections 5.2 and 5.7 of this memo (these 1830 definitions update those in [RFC4566]). 1832 8.2.8. Registration Procedure 1834 In the RFC documentation that registers SDP "media", "proto", "fmt", 1835 "bwtype", "nettype", and "addrtype" fields, the authors MUST include 1836 the following information for IANA to place in the appropriate 1837 registry: 1839 o contact name, email address, and telephone number 1841 o name being registered (as it will appear in SDP) 1843 o long-form name in English 1845 o type of name ("media", "proto", "fmt", "bwtype", "nettype", or 1846 "addrtype") 1848 o a one-paragraph explanation of the purpose of the registered name 1850 o a reference to the specification for the registered name (this 1851 will typically be an RFC number) 1853 IANA may refer any registration to the IESG for review, and may 1854 request revisions to be made before a registration will be made. 1856 8.3. Encryption Key Access Methods 1858 The IANA previously maintained a table of SDP encryption key access 1859 method ("enckey") names. This table is obsolete, since the "k=" line 1860 is not extensible. New registrations MUST NOT be accepted. 1862 9. SDP Grammar 1864 This section provides an Augmented BNF grammar for SDP. ABNF is 1865 defined in [RFC5234]. 1867 ; SDP Syntax 1868 session-description = proto-version 1869 origin-field 1870 session-name-field 1871 information-field 1872 uri-field 1873 email-fields 1874 phone-fields 1875 connection-field 1876 bandwidth-fields 1877 time-fields 1878 key-field 1879 attribute-fields 1880 media-descriptions 1882 proto-version = %x76 "=" 1*DIGIT CRLF 1883 ;this memo describes version 0 1885 origin-field = %x6f "=" username SP sess-id SP sess-version SP 1886 nettype SP addrtype SP unicast-address CRLF 1888 session-name-field = %x73 "=" text CRLF 1890 information-field = [%x69 "=" text CRLF] 1892 uri-field = [%x75 "=" uri CRLF] 1894 email-fields = *(%x65 "=" email-address CRLF) 1896 phone-fields = *(%x70 "=" phone-number CRLF) 1898 connection-field = [%x63 "=" nettype SP addrtype SP 1899 connection-address CRLF] 1900 ;a connection field must be present 1901 ;in every media description or at the 1902 ;session-level 1904 bandwidth-fields = *(%x62 "=" bwtype ":" bandwidth CRLF) 1906 time-fields = 1*( %x74 "=" start-time SP stop-time 1907 *(CRLF repeat-fields) CRLF) 1908 [zone-adjustments CRLF] 1910 repeat-fields = %x72 "=" repeat-interval SP typed-time 1911 1*(SP typed-time) 1913 zone-adjustments = %x7a "=" time SP ["-"] typed-time 1914 *(SP time SP ["-"] typed-time) 1916 key-field = [%x6b "=" key-type CRLF] 1918 attribute-fields = *(%x61 "=" attribute CRLF) 1920 media-descriptions = *( media-field 1921 information-field 1922 *connection-field 1923 bandwidth-fields 1924 key-field 1925 attribute-fields ) 1927 media-field = %x6d "=" media SP port ["/" integer] 1928 SP proto 1*(SP fmt) CRLF 1930 ; sub-rules of 'o=' 1931 username = non-ws-string 1932 ;pretty wide definition, but doesn't 1933 ;include space 1935 sess-id = 1*DIGIT 1936 ;should be unique for this username/host 1938 sess-version = 1*DIGIT 1940 nettype = token 1941 ;typically "IN" 1943 addrtype = token 1944 ;typically "IP4" or "IP6" 1946 ; sub-rules of 'u=' 1947 uri = URI-reference 1948 ; see RFC 3986 1950 ; sub-rules of 'e=', see RFC 5322 for definitions 1951 email-address = address-and-comment / dispname-and-address 1952 / addr-spec 1953 address-and-comment = addr-spec 1*SP "(" 1*email-safe ")" 1954 dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">" 1956 ; sub-rules of 'p=' 1957 phone-number = phone *SP "(" 1*email-safe ")" / 1958 1*email-safe "<" phone ">" / 1959 phone 1961 phone = ["+"] DIGIT 1*(SP / "-" / DIGIT) 1963 ; sub-rules of 'c=' 1964 connection-address = multicast-address / unicast-address 1966 ; sub-rules of 'b=' 1967 bwtype = token 1969 bandwidth = 1*DIGIT 1971 ; sub-rules of 't=' 1972 start-time = time / "0" 1974 stop-time = time / "0" 1975 time = POS-DIGIT 9*DIGIT 1976 ; Decimal representation of NTP time in 1977 ; seconds since 1900. The representation 1978 ; of NTP time is an unbounded length field 1979 ; containing at least 10 digits. Unlike the 1980 ; 64-bit representation used elsewhere, time 1981 ; in SDP does not wrap in the year 2036. 1983 ; sub-rules of 'r=' and 'z=' 1984 repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] 1986 typed-time = 1*DIGIT [fixed-len-time-unit] 1988 fixed-len-time-unit = %x64 / %x68 / %x6d / %x73 1990 ; sub-rules of 'k=' 1991 key-type = %x70 %x72 %x6f %x6d %x70 %x74 / ; "prompt" 1992 %x63 %x6c %x65 %x61 %x72 ":" text / ; "clear:" 1993 %x62 %x61 %x73 %x65 "64:" base64 / ; "base64:" 1994 %x75 %x72 %x69 ":" uri ; "uri:" 1996 base64 = *base64-unit [base64-pad] 1997 base64-unit = 4base64-char 1998 base64-pad = 2base64-char "==" / 3base64-char "=" 1999 base64-char = ALPHA / DIGIT / "+" / "/" 2001 ; sub-rules of 'a=' 2002 attribute = (att-field ":" att-value) / att-field 2004 att-field = token 2006 att-value = byte-string 2008 ; sub-rules of 'm=' 2009 media = token 2010 ;typically "audio", "video", "text", or 2011 ;"application" 2013 fmt = token 2014 ;typically an RTP payload type for audio 2015 ;and video media 2017 proto = token *("/" token) 2018 ;typically "RTP/AVP" or "udp" 2020 port = 1*DIGIT 2022 ; generic sub-rules: addressing 2023 unicast-address = IP4-address / IP6-address / FQDN / extn-addr 2025 multicast-address = IP4-multicast / IP6-multicast / FQDN 2026 / extn-addr 2028 IP4-multicast = m1 3( "." decimal-uchar ) 2029 "/" ttl [ "/" integer ] 2030 ; IP4 multicast addresses may be in the 2031 ; range 224.0.0.0 to 239.255.255.255 2033 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / 2034 ("23" DIGIT ) 2036 IP6-multicast = IP6-address [ "/" integer ] 2037 ; IP6 address starting with FF 2039 ttl = (POS-DIGIT *2DIGIT) / "0" 2041 FQDN = 4*(alpha-numeric / "-" / ".") 2042 ; fully qualified domain name as specified 2043 ; in RFC 1035 (and updates) 2045 IP4-address = b1 3("." decimal-uchar) 2047 b1 = decimal-uchar 2048 ; less than "224" 2050 IP6-address = 6( h16 ":" ) ls32 2051 / "::" 5( h16 ":" ) ls32 2052 / [ h16 ] "::" 4( h16 ":" ) ls32 2053 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 2054 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 2055 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 2056 / [ *4( h16 ":" ) h16 ] "::" ls32 2057 / [ *5( h16 ":" ) h16 ] "::" h16 2058 / [ *6( h16 ":" ) h16 ] "::" 2060 h16 = 1*4HEXDIG 2062 ls32 = ( h16 ":" h16 ) / IP4-address 2064 ; Generic for other address families 2065 extn-addr = non-ws-string 2067 ; generic sub-rules: datatypes 2068 text = byte-string 2069 ;default is to interpret this as UTF8 text. 2070 ;ISO 8859-1 requires "a=charset:ISO-8859-1" 2071 ;session-level attribute to be used 2073 byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) 2074 ;any byte except NUL, CR, or LF 2076 non-ws-string = 1*(VCHAR/%x80-FF) 2077 ;string of visible characters 2079 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 2080 / %x41-5A / %x5E-7E 2082 token = 1*(token-char) 2084 email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF 2085 ;any byte except NUL, CR, LF, or the quoting 2086 ;characters ()<> 2088 integer = POS-DIGIT *DIGIT 2090 ; generic sub-rules: primitives 2091 alpha-numeric = ALPHA / DIGIT 2093 POS-DIGIT = %x31-39 ; 1 - 9 2095 decimal-uchar = DIGIT 2096 / POS-DIGIT DIGIT 2097 / ("1" 2*(DIGIT)) 2098 / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) 2099 / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) 2101 ; external references: 2102 ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 5234 2103 ; URI-reference: from RFC 3986 2104 ; addr-spec: from RFC 5322 2106 10. Summary of Changes from RFC 4566 2108 The ABNF rule for IP6-address has been corrected. As a result, the 2109 ABNF rule for IP6-multicast has changed, and the (now unused) rules 2110 for hexpart, hexseq, and hex4 have been removed. 2112 IP4 unicast and multicast addresses in the example SDP descriptions 2113 have been revised per RFCs 5735 and 5771. 2115 Text in Section 5.2 has been revised to clarify the use of local 2116 addresses in case of ICE-like SDP extensions. 2118 Normative and informative references have been updated. 2120 The text regarding the session vs. media-level attribute usage has 2121 been clarified. 2123 The case-insensitivity rules from RFC 4855 have been included in this 2124 document. 2126 The following purely editorial changes have been made: 2128 o Section 4.6: fix typo in first sentence: "sets" -> "set" 2130 o Section 5: clarify second paragraph (SDP field and attribute names 2131 use the US-ASCII subset of UTF-8). 2133 o Section 5: clarify that an SDP session description can contain 2134 only a session-level section, with no media-level section, and 2135 that a media-level section can be terminated by the end of the 2136 session description, and not always by another media-level 2137 section. 2139 o Section 5: clearly differentiate "media" and "media description" 2140 in the description of the "c=" line. 2142 o Section 5.2: when describing the field, clarify 2143 that "an" address of the machine is used, rather than "the" 2144 address of the machine, since IP addresses identify interfaces, 2145 not hosts. 2147 o Section 5.6: use "session" rather than "conference" 2149 o Section 5.10: fix typo: "To make description" -> "To make the 2150 description" 2152 o Section 5.11: use "session description" rather than "session 2153 announcement" in the final paragraph 2155 o Section 7: fix typo: "distribute session description" -> 2156 "distribute session descriptions" 2158 11. Acknowledgements 2160 Many people in the IETF Multiparty Multimedia Session Control 2161 (MMUSIC) working group have made comments and suggestions 2162 contributing to this document. In particular, we would like to thank 2163 Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross 2164 Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna, 2165 Jonathan Lennox, Keith Drage, Sean Olson, Bernie Hoeneisen, Jonathan 2166 Rosenberg, John Elwell, Flemming Andreasen, Jon Peterson, Spencer 2167 Dawkins, Alfred Hoenes, Brett Tate and Paul Kyzivat. 2169 12. References 2171 12.1. Normative References 2173 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2174 STD 13, RFC 1034, November 1987. 2176 [RFC1035] Mockapetris, P., "Domain names - implementation and 2177 specification", STD 13, RFC 1035, November 1987. 2179 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2180 Requirement Levels", BCP 14, RFC 2119, March 1997. 2182 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2183 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2185 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2186 10646", STD 63, RFC 3629, November 2003. 2188 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2189 Resource Identifier (URI): Generic Syntax", STD 66, RFC 2190 3986, January 2005. 2192 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2193 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2194 May 2008. 2196 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 2197 Languages", BCP 47, RFC 5646, September 2009. 2199 [RFC5890] Klensin, J., "Internationalized Domain Names for 2200 Applications (IDNA): Definitions and Document Framework", 2201 RFC 5890, August 2010. 2203 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2204 Encodings", RFC 4648, October 2006. 2206 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2207 Description Protocol", RFC 4566, July 2006. 2209 12.2. Informative References 2211 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 2212 Protocol", RFC 2327, April 1998. 2214 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 2215 Time Protocol Version 4: Protocol and Algorithms 2216 Specification", RFC 5905, June 2010. 2218 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 2219 Announcement Protocol", RFC 2974, October 2000. 2221 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2222 A., Peterson, J., Sparks, R., Handley, M., and E. 2223 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2224 June 2002. 2226 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 2227 Streaming Protocol (RTSP)", RFC 2326, April 1998. 2229 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2230 with Session Description Protocol (SDP)", RFC 3264, June 2231 2002. 2233 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2234 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 2236 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2237 Jacobson, "RTP: A Transport Protocol for Real-Time 2238 Applications", STD 64, RFC 3550, July 2003. 2240 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 2241 Video Conferences with Minimal Control", STD 65, RFC 3551, 2242 July 2003. 2244 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 2245 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 2246 3556, July 2003. 2248 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2249 in Session Description Protocol (SDP)", RFC 3605, October 2250 2003. 2252 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2253 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2254 RFC 3711, March 2004. 2256 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 2257 "Indicating User Agent Capabilities in the Session 2258 Initiation Protocol (SIP)", RFC 3840, August 2004. 2260 [RFC3890] Westerlund, M., "A Transport Independent Bandwidth 2261 Modifier for the Session Description Protocol (SDP)", RFC 2262 3890, September 2004. 2264 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 2265 (ICE): A Protocol for Network Address Translator (NAT) 2266 Traversal for Offer/Answer Protocols", RFC 5245, April 2267 2010. 2269 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 2270 "TCP Candidates with Interactive Connectivity 2271 Establishment (ICE)", RFC 6544, March 2012. 2273 [ITU.H332.1998] 2274 International Telecommunication Union, "H.323 extended for 2275 loosely coupled conferences", ITU Recommendation H.332, 2276 September 1998. 2278 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 2279 Carrara, "Key Management Extensions for Session 2280 Description Protocol (SDP) and Real Time Streaming 2281 Protocol (RTSP)", RFC 4567, July 2006. 2283 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 2284 Description Protocol (SDP) Security Descriptions for Media 2285 Streams", RFC 4568, July 2006. 2287 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 2288 October 2008. 2290 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2291 Specifications and Registration Procedures", BCP 13, RFC 2292 6838, January 2013. 2294 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 2295 Formats", RFC 4855, February 2007. 2297 Authors' Addresses 2299 Mark Handley 2300 University College London 2301 Department of Computer Science 2302 London WC1E 6BT 2303 UK 2305 EMail: M.Handley@cs.ucl.ac.uk 2306 Van Jacobson 2307 PARC 2308 3333 Coyote Hill Road 2309 Palo Alto, CA 94304 2310 USA 2312 EMail: van@parc.com 2314 Colin Perkins 2315 University of Glasgow 2316 School of Computing Science 2317 University of Glasgow 2318 Glasgow G12 8QQ 2319 UK 2321 EMail: csp@csperkins.org 2323 Ali Begen 2324 Cisco 2325 181 Bay Street 2326 Toronto, ON M5J 2T3 2327 Canada 2329 EMail: abegen@cisco.com