idnits 2.17.1 draft-ietf-mmusic-rfc4566bis-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 16, 2013) is 3874 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: March 20, 2014 C. Perkins 7 University of Glasgow 8 A. Begen 9 Cisco 10 September 16, 2013 12 SDP: Session Description Protocol 13 draft-ietf-mmusic-rfc4566bis-09 15 Abstract 17 This memo defines the Session Description Protocol (SDP). SDP is 18 intended for describing multimedia sessions for the purposes of 19 session announcement, session invitation, and other forms of 20 multimedia session initiation. This document obsoletes RFC 4566. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 20, 2014. 39 Copyright Notice 41 Copyright (c) 2013 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 . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . 7 81 4.6. Internationalisation . . . . . . . . . . . . . . . . . . 8 82 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . . 8 83 5.1. Protocol Version ("v=") . . . . . . . . . . . . . . . . . 11 84 5.2. Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 11 85 5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 12 86 5.4. Session Information ("i=") . . . . . . . . . . . . . . . 13 87 5.5. URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . 13 88 5.6. Email Address and Phone Number ("e=" and "p=") . . . . . 13 89 5.7. Connection Data ("c=") . . . . . . . . . . . . . . . . . 14 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=") . . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . 36 103 8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 36 104 8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 36 105 8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 37 106 8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 38 107 8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 39 108 8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 39 109 8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 40 110 8.2.8. Registration Procedure . . . . . . . . . . . . . . . 40 111 8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 40 112 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 40 113 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 46 114 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 115 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 116 12.1. Normative References . . . . . . . . . . . . . . . . . . 47 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 191 Alternative means of conveying session descriptions include 192 electronic mail and the World Wide Web (WWW). For both email and WWW 193 distribution, the media type "application/sdp" is used. This enables 194 the automatic launching of applications for participation in the 195 session from the WWW client or mail reader in a standard manner. 197 Note that announcements of multicast sessions made only via email or 198 the WWW do not have the property that the receiver of a session 199 announcement can necessarily receive the session because the 200 multicast sessions may be restricted in scope, and access to the WWW 201 server or reception of email is possible outside this scope. 203 3.4. Multicast Session Announcement 205 In order to assist the advertisement of multicast multimedia 206 conferences and other multicast sessions, and to communicate the 207 relevant session setup information to prospective participants, a 208 distributed session directory may be used. An instance of such a 209 session directory periodically sends packets containing a description 210 of the session to a well-known multicast group. These advertisements 211 are received by other session directories such that potential remote 212 participants can use the session description to start the tools 213 required to participate in the session. 215 One protocol used to implement such a distributed directory is the 216 Session Announcement Protocol (SAP) [RFC2974]. SDP provides the 217 recommended session description format for such session 218 announcements. 220 4. Requirements and Recommendations 222 The purpose of SDP is to convey information about media streams in 223 multimedia sessions to allow the recipients of a session description 224 to participate in the session. SDP is primarily intended for use in 225 an internetwork, although it is sufficiently general that it can 226 describe conferences in other network environments. Media streams 227 can be many-to-many. Sessions need not be continually active. 229 Thus far, multicast-based sessions on the Internet have differed from 230 many other forms of conferencing in that anyone receiving the traffic 231 can join the session (unless the session traffic is encrypted). In 232 such an environment, SDP serves two primary purposes. It is a means 233 to communicate the existence of a session, and it is a means to 234 convey sufficient information to enable joining and participating in 235 the session. In a unicast environment, only the latter purpose is 236 likely to be relevant. 238 An SDP session description includes the following: 240 o Session name and purpose 242 o Time(s) the session is active 244 o The media comprising the session 246 o Information needed to receive those media (addresses, ports, 247 formats, etc.) 249 As resources necessary to participate in a session may be limited, 250 some additional information may also be desirable: 252 o Information about the bandwidth to be used by the session 254 o Contact information for the person responsible for the session 256 In general, SDP must convey sufficient information to enable 257 applications to join a session (with the possible exception of 258 encryption keys) and to announce the resources to be used to any non- 259 participants that may need to know. (This latter feature is 260 primarily useful when SDP is used with a multicast session 261 announcement protocol.) 263 4.1. Media and Transport Information 265 An SDP session description includes the following media information: 267 o The type of media (video, audio, etc.) 269 o The transport protocol (RTP/UDP/IP, H.320, etc.) 271 o The format of the media (H.261 video, MPEG video, etc.) 273 In addition to media format and transport protocol, SDP conveys 274 address and port details. For an IP multicast session, these 275 comprise: 277 o The multicast group address for media 279 o The transport port for media 281 This address and port are the destination address and destination 282 port of the multicast stream, whether being sent, received, or both. 284 For unicast IP sessions, the following are conveyed: 286 o The remote address for media 287 o The remote transport port for media 289 The semantics of this address and port depend on the media and 290 transport protocol defined. By default, this SHOULD be the remote 291 address and remote port to which data is sent. Some media types may 292 redefine this behaviour, but this is NOT RECOMMENDED since it 293 complicates implementations (including middleboxes that must parse 294 the addresses to open Network Address Translation (NAT) or firewall 295 pinholes). 297 4.2. Timing Information 299 Sessions may be either bounded or unbounded in time. Whether or not 300 they are bounded, they may be only active at specific times. SDP can 301 convey: 303 o An arbitrary list of start and stop times bounding the session 305 o For each bound, repeat times such as "every Wednesday at 10am for 306 one hour" 308 This timing information is globally consistent, irrespective of local 309 time zone or daylight saving time (see Section 5.9). 311 4.3. Private Sessions 313 It is possible to create both public sessions and private sessions. 314 SDP itself does not distinguish between these; private sessions are 315 typically conveyed by encrypting the session description during 316 distribution. The details of how encryption is performed are 317 dependent on the mechanism used to convey SDP; mechanisms are 318 currently defined for SDP transported using SAP [RFC2974] and SIP 319 [RFC3261], and others may be defined in the future. 321 If a session announcement is private, it is possible to use that 322 private announcement to convey encryption keys necessary to decode 323 each of the media in a conference, including enough information to 324 know which encryption scheme is used for each media. 326 4.4. Obtaining Further Information about a Session 328 A session description should convey enough information to decide 329 whether or not to participate in a session. SDP may include 330 additional pointers in the form of Uniform Resource Identifiers 331 (URIs) for more information about the session. 333 4.5. Categorisation 334 When many session descriptions are being distributed by SAP, or any 335 other advertisement mechanism, it may be desirable to filter session 336 announcements that are of interest from those that are not. SDP 337 supports a categorisation mechanism for sessions that is capable of 338 being automated (the "a=cat:" attribute; see Section 6). 340 4.6. Internationalisation 342 The SDP specification recommends the use of the ISO 10646 character 343 set in the UTF-8 encoding [RFC3629] to allow many different languages 344 to be represented. However, to assist in compact representations, 345 SDP also allows other character sets such as ISO 8859-1 to be used 346 when desired. Internationalisation only applies to free-text fields 347 (session name and background information), and not to SDP as a whole. 349 5. SDP Specification 351 An SDP session description is denoted by the media type "application/ 352 sdp" (See Section 8). 354 An SDP session description is entirely textual. SDP field names and 355 attribute names use only the US-ASCII subset of UTF-8, but textual 356 fields and attribute values MAY use the full ISO 10646 character set 357 in UTF-8 encoding, or some other character set defined by the 358 "a=charset:" attribute. Field and attribute values that use the full 359 UTF-8 character set are never directly compared, hence there is no 360 requirement for UTF-8 normalisation. The textual form, as opposed to 361 a binary encoding such as ASN.1 or XDR, was chosen to enhance 362 portability, to enable a variety of transports to be used, and to 363 allow flexible, text-based toolkits to be used to generate and 364 process session descriptions. However, since SDP may be used in 365 environments where the maximum permissible size of a session 366 description is limited, the encoding is deliberately compact. Also, 367 since announcements may be transported via very unreliable means or 368 damaged by an intermediate caching server, the encoding was designed 369 with strict order and formatting rules so that most errors would 370 result in malformed session announcements that could be detected 371 easily and discarded. This also allows rapid discarding of encrypted 372 session announcements for which a receiver does not have the correct 373 key. 375 An SDP session description consists of a number of lines of text of 376 the form: 378 = 379 where MUST be exactly one case-significant character and 380 is structured text whose format depends on . In 381 general, is either a number of fields delimited by a single 382 space character or a free format string, and is case-significant 383 unless a specific field defines otherwise. Whitespace MUST NOT be 384 used on either side of the "=" sign. 386 An SDP session description consists of a session-level section 387 followed by zero or more media-level sections. The session-level 388 part starts with a "v=" line and continues to the first media-level 389 section (or the end of the whole description, whichever comes first). 390 Each media-level section starts with an "m=" line and continues to 391 the next media-level section or the end of the whole session 392 description - whichever comes first. In general, session-level 393 values are the default for all media unless overridden by an 394 equivalent media-level value. 396 Some lines in each description are REQUIRED and some are OPTIONAL, 397 but all MUST appear in exactly the order given here (the fixed order 398 greatly enhances error detection and allows for a simple parser). 399 OPTIONAL items are marked with a "*". 401 Session description 402 v= (protocol version) 403 o= (originator and session identifier) 404 s= (session name) 405 i=* (session information) 406 u=* (URI of description) 407 e=* (email address) 408 p=* (phone number) 409 c=* (connection information -- not required if included in 410 all media descriptions) 411 b=* (zero or more bandwidth information lines) 412 One or more time descriptions ("t=" and "r=" lines; see below) 413 z=* (time zone adjustments) 414 k=* (encryption key) 415 a=* (zero or more session attribute lines) 416 Zero or more media descriptions 418 Time description 419 t= (time the session is active) 420 r=* (zero or more repeat times) 422 Media description, if present 423 m= (media name and transport address) 424 i=* (media title) 425 c=* (connection information -- optional if included at 426 session level) 428 b=* (zero or more bandwidth information lines) 429 k=* (encryption key) 430 a=* (zero or more media attribute lines) 432 The set of type letters is deliberately small and not intended to be 433 extensible -- an SDP parser MUST completely ignore any session 434 description that contains a type letter that it does not understand. 435 The attribute mechanism ("a=" described below) is the primary means 436 for extending SDP and tailoring it to particular applications or 437 media. Some attributes (the ones listed in Section 6 of this memo) 438 have a defined meaning, but others may be added on an application-, 439 media-, or session-specific basis. An SDP parser MUST ignore any 440 attribute it doesn't understand. 442 An SDP session description may contain URIs that reference external 443 content in the "u=", "k=", and "a=" lines. These URIs may be 444 dereferenced in some cases, making the session description non-self- 445 contained. 447 The connection ("c=") information in the session-level section 448 applies to all the media of that session unless overridden by 449 connection information in the media description. For instance, in 450 the example below, each audio media behaves as if it were given a 451 "c=IN IP4 233.252.0.2". 453 An example SDP description is: 455 v=0 456 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 457 s=SDP Seminar 458 i=A Seminar on the session description protocol 459 u=http://www.example.com/seminars/sdp.pdf 460 e=j.doe@example.com (Jane Doe) 461 c=IN IP4 233.252.0.2 462 t=2873397496 2873404696 463 a=recvonly 464 m=audio 49170 RTP/AVP 0 465 m=audio 49180 RTP/AVP 0 466 m=video 51372 RTP/AVP 99 467 c=IN IP4 233.252.0.1/127 468 a=rtpmap:99 h263-1998/90000 470 Text fields such as the session name and information are octet 471 strings that may contain any octet with the exceptions of 0x00 (Nul), 472 0x0a (ASCII newline), and 0x0d (ASCII carriage return). The sequence 473 CRLF (0x0d0a) is used to end a record, although parsers SHOULD be 474 tolerant and also accept records terminated with a single newline 475 character. If the "a=charset" attribute is not present, these octet 476 strings MUST be interpreted as containing ISO-10646 characters in 477 UTF-8 encoding (the presence of the "a=charset" attribute may force 478 some fields to be interpreted differently). 480 A session description can contain domain names in the "o=", "u=", 481 "e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply 482 with [RFC1034], [RFC1035]. Internationalised domain names (IDNs) 483 MUST be represented using the ASCII Compatible Encoding (ACE) form 484 defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or 485 any other encoding (this requirement is for compatibility with 486 [RFC4566] and other early SDP-related standards, which predate the 487 development of internationalised domain names). 489 5.1. Protocol Version ("v=") 491 v=0 493 The "v=" field gives the version of the Session Description Protocol. 494 This memo defines version 0. There is no minor version number. 496 5.2. Origin ("o=") 498 o= 499 501 The "o=" field gives the originator of the session (her username and 502 the address of the user's host) plus a session identifier and version 503 number: 505 is the user's login on the originating host, or it is "-" 506 if the originating host does not support the concept of user IDs. 507 The MUST NOT contain spaces. 509 is a numeric string such that the tuple of , 510 , , , and forms a 511 globally unique identifier for the session. The method of allocation is up to the creating tool, but it has been 513 suggested that a Network Time Protocol (NTP) format timestamp be 514 used to ensure uniqueness [RFC5905]. 516 is a version number for this session description. 517 Its usage is up to the creating tool, so long as is 518 increased when a modification is made to the session data. Again, 519 it is RECOMMENDED that an NTP format timestamp is used. 521 is a text string giving the type of network. Initially 522 "IN" is defined to have the meaning "Internet", but other values 523 MAY be registered in the future (see Section 8). 525 is a text string giving the type of the address that 526 follows. Initially "IP4" and "IP6" are defined, but other values 527 MAY be registered in the future (see Section 8). 529 is an address of the machine from which the 530 session was created. For an address type of IP4, this is either a 531 fully qualified domain name of the machine or the dotted-decimal 532 representation of an IP version 4 address of the machine. For an 533 address type of IP6, this is either a fully qualified domain name 534 of the machine or the compressed textual representation of an IP 535 version 6 address of the machine. For both IP4 and IP6, the fully 536 qualified domain name is the form that SHOULD be given unless this 537 is unavailable, in which case a globally unique address MAY be 538 substituted. Unless an SDP extension for NAT traversal is used 539 (e.g., ICE [RFC5245], ICE TCP [RFC6544]), a local IP address MUST 540 NOT be used in any context where the SDP description might leave 541 the scope in which the address is meaningful (for example, a local 542 address MUST NOT be included in an application-level referral that 543 might leave the scope). 545 In general, the "o=" field serves as a globally unique identifier for 546 this version of this session description, and the subfields excepting 547 the version taken together identify the session irrespective of any 548 modifications. 550 For privacy reasons, it is sometimes desirable to obfuscate the 551 username and IP address of the session originator. If this is a 552 concern, an arbitrary and private MAY be 553 chosen to populate the "o=" field, provided that these are selected 554 in a manner that does not affect the global uniqueness of the field. 556 5.3. Session Name ("s=") 558 s= 560 The "s=" field is the textual session name. There MUST be one and 561 only one "s=" field per session description. The "s=" field MUST NOT 562 be empty and SHOULD contain ISO 10646 characters (but see also the 563 "a=charset" attribute). If a session has no meaningful name, the 564 value "s= " SHOULD be used (i.e., a single space as the session 565 name). 567 5.4. Session Information ("i=") 569 i= 571 The "i=" field provides textual information about the session. There 572 MUST be at most one session-level "i=" field per session description, 573 and at most one "i=" field per media. If the "a=charset" attribute 574 is present, it specifies the character set used in the "i=" field. 575 If the "a=charset" attribute is not present, the "i=" field MUST 576 contain ISO 10646 characters in UTF-8 encoding. 578 A single "i=" field MAY also be used for each media definition. In 579 media definitions, "i=" fields are primarily intended for labelling 580 media streams. As such, they are most likely to be useful when a 581 single session has more than one distinct media stream of the same 582 media type. An example would be two different whiteboards, one for 583 slides and one for feedback and questions. 585 The "i=" field is intended to provide a free-form human-readable 586 description of the session or the purpose of a media stream. It is 587 not suitable for parsing by automata. 589 5.5. URI ("u=") 591 u= 593 A URI is a Uniform Resource Identifier as used by WWW clients 594 [RFC3986]. The URI should be a pointer to additional information 595 about the session. This field is OPTIONAL, but if it is present it 596 MUST be specified before the first media field. No more than one URI 597 field is allowed per session description. 599 5.6. Email Address and Phone Number ("e=" and "p=") 601 e= 602 p= 604 The "e=" and "p=" lines specify contact information for the person 605 responsible for the session. This is not necessarily the same person 606 that created the session description. 608 Inclusion of an email address or phone number is OPTIONAL. Note that 609 the previous version of SDP specified that either an email field or a 610 phone field MUST be specified, but this was widely ignored. The 611 change brings the specification into line with common usage. 613 If an email address or phone number is present, it MUST be specified 614 before the first media field. More than one email or phone field can 615 be given for a session description. 617 Phone numbers SHOULD be given in the form of an international public 618 telecommunication number (see ITU-T Recommendation E.164) preceded by 619 a "+". Spaces and hyphens may be used to split up a phone field to 620 aid readability if desired. For example: 622 p=+1 617 555-6011 624 Both email addresses and phone numbers can have an OPTIONAL free text 625 string associated with them, normally giving the name of the person 626 who may be contacted. This MUST be enclosed in parentheses if it is 627 present. For example: 629 e=j.doe@example.com (Jane Doe) 631 The alternative [RFC5322] name quoting convention is also allowed for 632 both email addresses and phone numbers. For example: 634 e=Jane Doe 636 The free text string SHOULD be in the ISO-10646 character set with 637 UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if 638 the appropriate session-level "a=charset" attribute is set. 640 5.7. Connection Data ("c=") 642 c= 644 The "c=" field contains connection data. 646 A session description MUST contain either at least one "c=" field in 647 each media description or a single "c=" field at the session level. 648 It MAY contain a single session-level "c=" field and additional "c=" 649 field(s) per media description, in which case the per-media values 650 override the session-level settings for the respective media. 652 The first sub-field ("") is the network type, which is a 653 text string giving the type of network. Initially, "IN" is defined 654 to have the meaning "Internet", but other values MAY be registered in 655 the future (see Section 8). 657 The second sub-field ("") is the address type. This allows 658 SDP to be used for sessions that are not IP based. This memo only 659 defines IP4 and IP6, but other values MAY be registered in the future 660 (see Section 8). 662 The third sub-field ("") is the connection 663 address. OPTIONAL sub-fields MAY be added after the connection 664 address depending on the value of the field. 666 When the is IP4 and IP6, the connection address is defined 667 as follows: 669 o If the session is multicast, the connection address will be an IP 670 multicast group address. If the session is not multicast, then 671 the connection address contains the unicast IP address of the 672 expected data source or data relay or data sink as determined by 673 additional attribute fields. It is not expected that unicast 674 addresses will be given in a session description that is 675 communicated by a multicast announcement, though this is not 676 prohibited. 678 o Sessions using an IP4 multicast connection address MUST also have 679 a time to live (TTL) value present in addition to the multicast 680 address. The TTL and the address together define the scope with 681 which multicast packets sent in this session will be sent. TTL 682 values MUST be in the range 0-255. Although the TTL MUST be 683 specified, its use to scope multicast traffic is deprecated; 684 applications SHOULD use an administratively scoped address 685 instead. 687 The TTL for the session is appended to the address using a slash as a 688 separator. An example is: 690 c=IN IP4 233.252.0.1/127 692 IP6 multicast does not use TTL scoping, and hence the TTL value MUST 693 NOT be present for IP6 multicast. It is expected that IP6 scoped 694 addresses will be used to limit the scope of conferences. 696 Hierarchical or layered encoding schemes are data streams where the 697 encoding from a single media source is split into a number of layers. 698 The receiver can choose the desired quality (and hence bandwidth) by 699 only subscribing to a subset of these layers. Such layered encodings 700 are normally transmitted in multiple multicast groups to allow 701 multicast pruning. This technique keeps unwanted traffic from sites 702 only requiring certain levels of the hierarchy. For applications 703 requiring multiple multicast groups, we allow the following notation 704 to be used for the connection address: 706 [/]/ 708 If the number of addresses is not given, it is assumed to be one. 709 Multicast addresses so assigned are contiguously allocated above the 710 base address, so that, for example: 712 c=IN IP4 233.252.0.1/127/3 714 would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3 715 are to be used at a TTL of 127. This is semantically identical to 716 including multiple "c=" lines in a media description: 718 c=IN IP4 233.252.0.1/127 719 c=IN IP4 233.252.0.2/127 720 c=IN IP4 233.252.0.3/127 722 Similarly, an IP6 example would be: 724 c=IN IP6 FF15::101/3 726 which is semantically equivalent to: 728 c=IN IP6 FF15::101 729 c=IN IP6 FF15::102 730 c=IN IP6 FF15::103 732 (remembering that the TTL field is not present in IP6 multicast). 734 Multiple addresses or "c=" lines MAY be specified on a per-media 735 basis only if they provide multicast addresses for different layers 736 in a hierarchical or layered encoding scheme. They MUST NOT be 737 specified for a session-level "c=" field. 739 The slash notation for multiple addresses described above MUST NOT be 740 used for IP unicast addresses. 742 5.8. Bandwidth ("b=") 744 b=: 746 This OPTIONAL field denotes the proposed bandwidth to be used by the 747 session or media. The is an alphanumeric modifier giving 748 the meaning of the figure. Two values are defined in 749 this specification, but other values MAY be registered in the future 750 (see Section 8 and [RFC3556], [RFC3890]): 752 CT If the bandwidth of a session or media in a session is different 753 from the bandwidth implicit from the scope, a "b=CT:..." line 754 SHOULD be supplied for the session giving the proposed upper limit 755 to the bandwidth used (the "conference total" bandwidth). The 756 primary purpose of this is to give an approximate idea as to 757 whether two or more sessions can coexist simultaneously. When 758 using the CT modifier with RTP, if several RTP sessions are part 759 of the conference, the conference total refers to total bandwidth 760 of all RTP sessions. 762 AS The bandwidth is interpreted to be application specific (it will 763 be the application's concept of maximum bandwidth). Normally, 764 this will coincide with what is set on the application's "maximum 765 bandwidth" control if applicable. For RTP-based applications, AS 766 gives the RTP "session bandwidth" as defined in Section 6.2 of 767 [RFC3550]. 769 Note that CT gives a total bandwidth figure for all the media at all 770 sites. AS gives a bandwidth figure for a single media at a single 771 site, although there may be many sites sending simultaneously. 773 A prefix "X-" is defined for names. This is intended for 774 experimental purposes only. For example: 776 b=X-YZ:128 778 Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers 779 SHOULD be registered with IANA in the standard namespace. SDP 780 parsers MUST ignore bandwidth fields with unknown modifiers. 781 Modifiers MUST be alphanumeric and, although no length limit is 782 given, it is recommended that they be short. 784 The is interpreted as kilobits per second by default. 785 The definition of a new modifier MAY specify that the 786 bandwidth is to be interpreted in some alternative unit (the "CT" and 787 "AS" modifiers defined in this memo use the default units). 789 5.9. Timing ("t=") 791 t= 793 The "t=" lines specify the start and stop times for a session. 794 Multiple "t=" lines MAY be used if a session is active at multiple 795 irregularly spaced times; each additional "t=" line specifies an 796 additional period of time for which the session will be active. If 797 the session is active at regular times, an "r=" line (see below) 798 should be used in addition to, and following, a "t=" line -- in which 799 case the "t=" line specifies the start and stop times of the repeat 800 sequence. 802 The first and second sub-fields give the start and stop times, 803 respectively, for the session. These values are the decimal 804 representation of Network Time Protocol (NTP) time values in seconds 805 since 1900 [RFC5905]. To convert these values to UNIX time, subtract 806 decimal 2208988800. 808 NTP timestamps are elsewhere represented by 64-bit values, which wrap 809 sometime in the year 2036. Since SDP uses an arbitrary length 810 decimal representation, this should not cause an issue (SDP 811 timestamps MUST continue counting seconds since 1900, NTP will use 812 the value modulo the 64-bit limit). 814 If the is set to zero, then the session is not bounded, 815 though it will not become active until after the . If 816 the is also zero, the session is regarded as permanent. 818 User interfaces SHOULD strongly discourage the creation of unbounded 819 and permanent sessions as they give no information about when the 820 session is actually going to terminate, and so make scheduling 821 difficult. 823 The general assumption may be made, when displaying unbounded 824 sessions that have not timed out to the user, that an unbounded 825 session will only be active until half an hour from the current time 826 or the session start time, whichever is the later. If behaviour 827 other than this is required, an end-time SHOULD be given and modified 828 as appropriate when new information becomes available about when the 829 session should really end. 831 Permanent sessions may be shown to the user as never being active 832 unless there are associated repeat times that state precisely when 833 the session will be active. 835 5.10. Repeat Times ("r=") 837 r= 839 "r=" fields specify repeat times for a session. For example, if a 840 session is active at 10am on Monday and 11am on Tuesday for one hour 841 each week for three months, then the in the 842 corresponding "t=" field would be the NTP representation of 10am on 843 the first Monday, the would be 1 week, the would be 1 hour, and the offsets would be zero and 25 845 hours. The corresponding "t=" field stop time would be the NTP 846 representation of the end of the last session three months later. By 847 default, all fields are in seconds, so the "r=" and "t=" fields might 848 be the following: 850 t=3034423619 3042462419 851 r=604800 3600 0 90000 853 To make the description more compact, times may also be given in 854 units of days, hours, or minutes. The syntax for these is a number 855 immediately followed by a single case-sensitive character. 856 Fractional units are not allowed -- a smaller unit should be used 857 instead. The following unit specification characters are allowed: 859 d - days (86400 seconds) 860 h - hours (3600 seconds) 861 m - minutes (60 seconds) 862 s - seconds (allowed for completeness) 864 Thus, the above session announcement could also have been written: 866 r=7d 1h 0 25h 868 Monthly and yearly repeats cannot be directly specified with a single 869 SDP repeat time; instead, separate "t=" fields should be used to 870 explicitly list the session times. 872 5.11. Time Zones ("z=") 874 z= .... 876 To schedule a repeated session that spans a change from daylight 877 saving time to standard time or vice versa, it is necessary to 878 specify offsets from the base time. This is required because 879 different time zones change time at different times of day, different 880 countries change to or from daylight saving time on different dates, 881 and some countries do not have daylight saving time at all. 883 Thus, in order to schedule a session that is at the same time winter 884 and summer, it must be possible to specify unambiguously by whose 885 time zone a session is scheduled. To simplify this task for 886 receivers, we allow the sender to specify the NTP time that a time 887 zone adjustment happens and the offset from the time when the session 888 was first scheduled. The "z=" field allows the sender to specify a 889 list of these adjustment times and offsets from the base time. 891 An example might be the following: 893 z=2882844526 -1h 2898848070 0 895 This specifies that at time 2882844526, the time base by which the 896 session's repeat times are calculated is shifted back by 1 hour, and 897 that at time 2898848070, the session's original time base is 898 restored. Adjustments are always relative to the specified start 899 time -- they are not cumulative. Adjustments apply to all "t=" and 900 "r=" lines in a session description. 902 If a session is likely to last several years, it is expected that the 903 session description will be modified periodically rather than 904 transmit several years' worth of adjustments in one session 905 description. 907 5.12. Encryption Keys ("k=") 909 k= 910 k=: 912 If transported over a secure and trusted channel, the Session 913 Description Protocol MAY be used to convey encryption keys. A simple 914 mechanism for key exchange is provided by the key field ("k="), 915 although this is primarily supported for compatibility with older 916 implementations and its use is NOT RECOMMENDED. Work is in progress 917 to define new key exchange mechanisms for use with SDP [RFC4567] 918 [RFC4568], and it is expected that new applications will use those 919 mechanisms. 921 A key field is permitted before the first media entry (in which case 922 it applies to all media in the session), or for each media entry as 923 required. The format of keys and their usage are outside the scope 924 of this document, and the key field provides no way to indicate the 925 encryption algorithm to be used, key type, or other information about 926 the key: this is assumed to be provided by the higher-level protocol 927 using SDP. If there is a need to convey this information within SDP, 928 the extensions mentioned previously SHOULD be used. Many security 929 protocols require two keys: one for confidentiality, another for 930 integrity. This specification does not support transfer of two keys. 932 The method indicates the mechanism to be used to obtain a usable key 933 by external means, or from the encoded encryption key given. The 934 following methods are defined: 936 k=clear: 938 The encryption key is included untransformed in this key field. 939 This method MUST NOT be used unless it can be guaranteed that 940 the SDP is conveyed over a secure channel. The encryption key 941 is interpreted as text according to the charset attribute; use 942 the "k=base64:" method to convey characters that are otherwise 943 prohibited in SDP. 945 k=base64: 947 The encryption key is included in this key field but has been 948 base64 encoded [RFC4648] because it includes characters that 949 are prohibited in SDP. This method MUST NOT be used unless it 950 can be guaranteed that the SDP is conveyed over a secure 951 channel. 953 k=uri: 955 A Uniform Resource Identifier is included in the key field. 956 The URI refers to the data containing the key, and may require 957 additional authentication before the key can be returned. When 958 a request is made to the given URI, the reply should specify 959 the encoding for the key. The URI is often an Secure Socket 960 Layer/Transport Layer Security (SSL/TLS)-protected HTTP URI 961 ("https:"), although this is not required. 963 k=prompt 965 No key is included in this SDP description, but the session or 966 media stream referred to by this key field is encrypted. The 967 user should be prompted for the key when attempting to join the 968 session, and this user-supplied key should then be used to 969 decrypt the media streams. The use of user-specified keys is 970 NOT RECOMMENDED, since such keys tend to have weak security 971 properties. 973 The key field MUST NOT be used unless it can be guaranteed that the 974 SDP is conveyed over a secure and trusted channel. An example of 975 such a channel might be SDP embedded inside an S/MIME message or a 976 TLS-protected HTTP session. It is important to ensure that the 977 secure channel is with the party that is authorised to join the 978 session, not an intermediary: if a caching proxy server is used, it 979 is important to ensure that the proxy is either trusted or unable to 980 access the SDP. 982 5.13. Attributes ("a=") 984 a= 985 a=: 987 Attributes are the primary means for extending SDP. Attributes may 988 be defined to be used as "session-level" attributes, "media-level" 989 attributes, or both. 991 A media description may have any number of attributes ("a=" fields) 992 that are media specific. These are referred to as "media-level" 993 attributes and add information about the media stream. Attribute 994 fields can also be added before the first media field; these 995 "session-level" attributes convey additional information that applies 996 to the session as a whole rather than to individual media. 998 Attribute fields may be of two forms: 1000 o A property attribute is simply of the form "a=". These are 1001 binary attributes, and the presence of the attribute conveys that 1002 the attribute is a property of the session. An example might be 1003 "a=recvonly". 1005 o A value attribute is of the form "a=:". For 1006 example, a whiteboard could have the value attribute 1007 "a=orient:landscape" 1009 Attribute interpretation depends on the media tool being invoked. 1010 Thus receivers of session descriptions should be configurable in 1011 their interpretation of session descriptions in general and of 1012 attributes in particular. 1014 Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. 1016 Attribute values are octet strings, and MAY use any octet value 1017 except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute 1018 values are to be interpreted as in ISO-10646 character set with UTF-8 1019 encoding. Unlike other text fields, attribute values are NOT 1020 normally affected by the "charset" attribute as this would make 1021 comparisons against known values problematic. However, when an 1022 attribute is defined, it can be defined to be charset dependent, in 1023 which case its value should be interpreted in the session charset 1024 rather than in ISO-10646. 1026 Attributes MUST be registered with IANA (see Section 8). If an 1027 attribute is received that is not understood, it MUST be ignored by 1028 the receiver. 1030 5.14. Media Descriptions ("m=") 1032 m= ... 1034 A session description may contain a number of media descriptions. 1035 Each media description starts with an "m=" field and is terminated by 1036 either the next "m=" field or by the end of the session description. 1037 A media field has several sub-fields: 1039 is the media type. Currently defined media are "audio", 1040 "video", "text", "application", and "message", although this list 1041 may be extended in the future (see Section 8). 1043 is the transport port to which the media stream is sent. The 1044 meaning of the transport port depends on the network being used as 1045 specified in the relevant "c=" field, and on the transport 1046 protocol defined in the sub-field of the media field. 1047 Other ports used by the media application (such as the RTP Control 1048 Protocol (RTCP) port [RFC3550]) MAY be derived algorithmically 1049 from the base media port or MAY be specified in a separate 1050 attribute (for example, "a=rtcp:" as defined in [RFC3605]). 1052 If non-contiguous ports are used or if they don't follow the 1053 parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" 1054 attribute MUST be used. Applications that are requested to send 1055 media to a that is odd and where the "a=rtcp:" is present 1056 MUST NOT subtract 1 from the RTP port: that is, they MUST send the 1057 RTP to the port indicated in and send the RTCP to the port 1058 indicated in the "a=rtcp" attribute. 1060 For applications where hierarchically encoded streams are being 1061 sent to a unicast address, it may be necessary to specify multiple 1062 transport ports. This is done using a similar notation to that 1063 used for IP multicast addresses in the "c=" field: 1065 m= / ... 1067 In such a case, the ports used depend on the transport protocol. 1068 For RTP, the default is that only the even-numbered ports are used 1069 for data with the corresponding one-higher odd ports used for the 1070 RTCP belonging to the RTP session, and the 1071 denoting the number of RTP sessions. For example: 1073 m=video 49170/2 RTP/AVP 31 1075 would specify that ports 49170 and 49171 form one RTP/RTCP pair 1076 and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the 1077 transport protocol and 31 is the format (see below). If non- 1078 contiguous ports are required, they must be signalled using a 1079 separate attribute (for example, "a=rtcp:" as defined in 1080 [RFC3605]). 1082 If multiple addresses are specified in the "c=" field and multiple 1083 ports are specified in the "m=" field, a one-to-one mapping from 1084 port to the corresponding address is implied. For example: 1086 c=IN IP4 233.252.0.1/127/2 1087 m=video 49170/2 RTP/AVP 31 1089 would imply that address 233.252.0.1 is used with ports 49170 and 1090 49171, and address 233.252.0.2 is used with ports 49172 and 49173. 1092 The semantics of multiple "m=" lines using the same transport 1093 address are undefined. This implies that, unlike limited past 1094 practice, there is no implicit grouping defined by such means and 1095 an explicit grouping framework (for example, [RFC5888]) should 1096 instead be used to express the intended semantics. 1098 is the transport protocol. The meaning of the transport 1099 protocol is dependent on the address type field in the relevant 1100 "c=" field. Thus a "c=" field of IP4 indicates that the transport 1101 protocol runs over IP4. The following transport protocols are 1102 defined, but may be extended through registration of new protocols 1103 with IANA (see Section 8): 1105 * udp: denotes an unspecified protocol running over UDP. 1107 * RTP/AVP: denotes RTP [RFC3550] used under the RTP Profile for 1108 Audio and Video Conferences with Minimal Control [RFC3551] 1109 running over UDP. 1111 * RTP/SAVP: denotes the Secure Real-time Transport Protocol 1112 [RFC3711] running over UDP. 1114 The main reason to specify the transport protocol in addition to 1115 the media format is that the same standard media formats may be 1116 carried over different transport protocols even when the network 1117 protocol is the same -- a historical example is vat Pulse Code 1118 Modulation (PCM) audio and RTP PCM audio; another might be TCP/RTP 1119 PCM audio. In addition, relays and monitoring tools that are 1120 transport-protocol-specific but format-independent are possible. 1122 is a media format description. The fourth and any subsequent 1123 sub-fields describe the format of the media. The interpretation 1124 of the media format depends on the value of the sub-field. 1126 If the sub-field is "RTP/AVP" or "RTP/SAVP" the sub- 1127 fields contain RTP payload type numbers. When a list of payload 1128 type numbers is given, this implies that all of these payload 1129 formats MAY be used in the session, but the first of these formats 1130 SHOULD be used as the default format for the session. For dynamic 1131 payload type assignments the "a=rtpmap:" attribute (see Section 6) 1132 SHOULD be used to map from an RTP payload type number to a media 1133 encoding name that identifies the payload format. The "a=fmtp:" 1134 attribute MAY be used to specify format parameters (see 1135 Section 6). 1137 If the sub-field is "udp" the sub-fields MUST 1138 reference a media type describing the format under the "audio", 1139 "video", "text", "application", or "message" top-level media 1140 types. The media type registration SHOULD define the packet 1141 format for use with UDP transport. 1143 For media using other transport protocols, the field is 1144 protocol specific. Rules for interpretation of the sub- 1145 field MUST be defined when registering new protocols (see 1146 Section 8.2.2). 1148 Section 3 of [RFC4855] states that the payload format (encoding) 1149 names defined in the RTP Profile are commonly shown in upper case, 1150 while media subtype names are commonly shown in lower case. It 1151 also states that both of these names are case-insensitive in both 1152 places, similar to parameter names which are case-insensitive both 1153 in media type strings and in the default mapping to the SDP a=fmtp 1154 attribute. 1156 6. SDP Attributes 1158 The following attributes are defined. Since application writers may 1159 add new attributes as they are required, this list is not exhaustive. 1160 Registration procedures for new attributes are defined in 1161 Section 8.2.4. 1163 a=cat: 1165 This attribute gives the dot-separated hierarchical category of 1166 the session. This is to enable a receiver to filter unwanted 1167 sessions by category. There is no central registry of 1168 categories. It is a session-level attribute, and it is not 1169 dependent on charset. 1171 a=keywds: 1173 Like the cat attribute, this is to assist identifying wanted 1174 sessions at the receiver. This allows a receiver to select 1175 interesting session based on keywords describing the purpose of 1176 the session; there is no central registry of keywords. It is a 1177 session-level attribute. It is a charset-dependent attribute, 1178 meaning that its value should be interpreted in the charset 1179 specified for the session description if one is specified, or 1180 by default in ISO 10646/UTF-8. 1182 a=tool: 1184 This gives the name and version number of the tool used to 1185 create the session description. It is a session-level 1186 attribute, and it is not dependent on charset. 1188 a=ptime: 1190 This gives the length of time in milliseconds represented by 1191 the media in a packet. This is probably only meaningful for 1192 audio data, but may be used with other media types if it makes 1193 sense. It should not be necessary to know ptime to decode RTP 1194 or vat audio, and it is intended as a recommendation for the 1195 encoding/packetisation of audio. It is a media-level 1196 attribute, and it is not dependent on charset. 1198 a=maxptime: 1200 This gives the maximum amount of media that can be encapsulated 1201 in each packet, expressed as time in milliseconds. The time 1202 SHALL be calculated as the sum of the time the media present in 1203 the packet represents. For frame-based codecs, the time SHOULD 1204 be an integer multiple of the frame size. This attribute is 1205 probably only meaningful for audio data, but may be used with 1206 other media types if it makes sense. It is a media-level 1207 attribute, and it is not dependent on charset. Note that this 1208 attribute was introduced after [RFC2327], and non-updated 1209 implementations will ignore this attribute. 1211 a=rtpmap: / [/] 1214 This attribute maps from an RTP payload type number (as used in 1215 an "m=" line) to an encoding name denoting the payload format 1216 to be used. It also provides information on the clock rate and 1217 encoding parameters. It is a media-level attribute that is not 1218 dependent on charset. 1220 Although an RTP profile may make static assignments of payload 1221 type numbers to payload formats, it is more common for that 1222 assignment to be done dynamically using "a=rtpmap:" attributes. 1223 As an example of a static payload type, consider u-law PCM 1224 coded single-channel audio sampled at 8 kHz. This is 1225 completely defined in the RTP Audio/Video profile as payload 1226 type 0, so there is no need for an "a=rtpmap:" attribute, and 1227 the media for such a stream sent to UDP port 49232 can be 1228 specified as: 1230 m=audio 49232 RTP/AVP 0 1232 An example of a dynamic payload type is 16-bit linear encoded 1233 stereo audio sampled at 16 kHz. If we wish to use the dynamic 1234 RTP/AVP payload type 98 for this stream, additional information 1235 is required to decode it: 1237 m=audio 49232 RTP/AVP 98 1238 a=rtpmap:98 L16/16000/2 1240 Up to one rtpmap attribute can be defined for each media format 1241 specified. Thus, we might have the following: 1243 m=audio 49230 RTP/AVP 96 97 98 1244 a=rtpmap:96 L8/8000 1245 a=rtpmap:97 L16/8000 1246 a=rtpmap:98 L16/11025/2 1248 RTP profiles that specify the use of dynamic payload types MUST 1249 define the set of valid encoding names and/or a means to 1250 register encoding names if that profile is to be used with SDP. 1251 The "RTP/AVP" and "RTP/SAVP" profiles use media subtypes for 1252 encoding names, under the top-level media type denoted in the 1253 "m=" line. In the example above, the media types are "audio/ 1254 l8" and "audio/l16". 1256 For audio streams, indicates the number 1257 of audio channels. This parameter is OPTIONAL and may be 1258 omitted if the number of channels is one, provided that no 1259 additional parameters are needed. 1261 For video streams, no encoding parameters are currently 1262 specified. 1264 Additional encoding parameters MAY be defined in the future, 1265 but codec-specific parameters SHOULD NOT be added. Parameters 1266 added to an "a=rtpmap:" attribute SHOULD only be those required 1267 for a session directory to make the choice of appropriate media 1268 to participate in a session. Codec-specific parameters should 1269 be added in other attributes (for example, "a=fmtp:"). 1271 Note: RTP audio formats typically do not include information 1272 about the number of samples per packet. If a non-default (as 1273 defined in the RTP Audio/Video Profile) packetisation is 1274 required, the "ptime" attribute is used as given above. 1276 a=recvonly, a=sendrecv, a=sendonly, a=inactive 1278 At most one of recvonly/sendrecv/sendonly/inactive MAY appear 1279 at session level, and at most one MAY appear in each media 1280 section. 1282 If any one of these appears in a media section then it applies 1283 for that media section. If none appear in a media section then 1284 the one from session level, if any, applies to that media 1285 section. 1287 If none of the attributes "sendonly", "recvonly", "inactive", 1288 and "sendrecv" is present at either session level or media 1289 level, "sendrecv" SHOULD be assumed as the default for sessions 1290 that are not of the conference type "broadcast" or "H332" (see 1291 below). 1293 Within the following SDP example, the "inactive" attribute 1294 applies to audio media and the "recvonly" attribute applies to 1295 video media. 1297 v=0 1298 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 1299 s=SDP Seminar 1300 i=A Seminar on the session description protocol 1301 u=http://www.example.com/seminars/sdp.pdf 1302 e=j.doe@example.com (Jane Doe) 1303 c=IN IP4 233.252.0.1/127 1304 t=2873397496 2873404696 1305 a=inactive 1306 m=audio 49170 RTP/AVP 0 1307 m=video 51372 RTP/AVP 99 1308 a=rtpmap:99 h263-1998/90000 1309 a=recvonly 1311 a=recvonly 1313 This specifies that the tools should be started in receive-only 1314 mode where applicable. It can be either a session- or media- 1315 level attribute, and it is not dependent on charset. Note that 1316 recvonly applies to the media only, not to any associated 1317 control protocol (e.g., an RTP-based system in recvonly mode 1318 SHOULD still send RTCP packets). 1320 a=sendrecv 1322 This specifies that the tools should be started in send and 1323 receive mode. This is necessary for interactive conferences 1324 with tools that default to receive-only mode. It can be either 1325 a session or media-level attribute, and it is not dependent on 1326 charset. 1328 a=sendonly 1330 This specifies that the tools should be started in send-only 1331 mode. An example may be where a different unicast address is 1332 to be used for a traffic destination than for a traffic source. 1333 In such a case, two media descriptions may be used, one 1334 sendonly and one recvonly. It can be either a session- or 1335 media-level attribute, but would normally only be used as a 1336 media attribute. It is not dependent on charset. Note that 1337 sendonly applies only to the media, and any associated control 1338 protocol (e.g., RTCP) SHOULD still be received and processed as 1339 normal. 1341 a=inactive 1342 This specifies that the tools should be started in inactive 1343 mode. This is necessary for interactive conferences where 1344 users can put other users on hold. No media is sent over an 1345 inactive media stream. Note that an RTP-based system SHOULD 1346 still send RTCP, even if started inactive. It can be either a 1347 session or media-level attribute, and it is not dependent on 1348 charset. 1350 a=orient: 1352 Normally this is only used for a whiteboard or presentation 1353 tool. It specifies the orientation of a the workspace on the 1354 screen. It is a media-level attribute. Permitted values are 1355 "portrait", "landscape", and "seascape" (upside-down 1356 landscape). It is not dependent on charset. 1358 a=type: 1360 This specifies the type of the conference. Suggested values 1361 are "broadcast", "meeting", "moderated", "test", and "H332". 1362 "recvonly" should be the default for "type:broadcast" sessions, 1363 "type:meeting" should imply "sendrecv", and "type:moderated" 1364 should indicate the use of a floor control tool and that the 1365 media tools are started so as to mute new sites joining the 1366 conference. 1368 Specifying the attribute "type:H332" indicates that this 1369 loosely coupled session is part of an H.332 session as defined 1370 in the ITU H.332 specification [ITU.H332.1998]. Media tools 1371 should be started "recvonly". 1373 Specifying the attribute "type:test" is suggested as a hint 1374 that, unless explicitly requested otherwise, receivers can 1375 safely avoid displaying this session description to users. 1377 The type attribute is a session-level attribute, and it is not 1378 dependent on charset. 1380 a=charset: 1382 This specifies the character set to be used to display the 1383 session name and information data. By default, the ISO-10646 1384 character set in UTF-8 encoding is used. If a more compact 1385 representation is required, other character sets may be used. 1386 For example, the ISO 8859-1 is specified with the following SDP 1387 attribute: 1389 a=charset:ISO-8859-1 1391 This is a session-level attribute and is not dependent on 1392 charset. The charset specified MUST be one of those registered 1393 with IANA, such as ISO-8859-1. The character set identifier is 1394 a US-ASCII string and MUST be compared against the IANA 1395 identifiers using a case-insensitive comparison. If the 1396 identifier is not recognised or not supported, all strings that 1397 are affected by it SHOULD be regarded as octet strings. 1399 Note that a character set specified MUST still prohibit the use 1400 of bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets 1401 requiring the use of these characters MUST define a quoting 1402 mechanism that prevents these bytes from appearing within text 1403 fields. 1405 a=sdplang: 1407 This can be a session-level attribute or a media-level 1408 attribute. Multiple sdplang attributes can be provided either 1409 at session or media level if the session description or media 1410 use multiple languages. 1412 As a session-level attribute, it specifies the language for the 1413 session description. As a media-level attribute, it specifies 1414 the language for any media-level SDP information field 1415 associated with that media, overriding any sdplang attributes 1416 specified at session-level. 1418 In general, sending session descriptions consisting of multiple 1419 languages is discouraged. Instead, multiple descriptions 1420 SHOULD be sent describing the session, one in each language. 1421 However, this is not possible with all transport mechanisms, 1422 and so multiple sdplang attributes are allowed although NOT 1423 RECOMMENDED. 1425 The "sdplang" attribute value must be a single [RFC5646] 1426 language tag in US-ASCII. It is not dependent on the charset 1427 attribute. An "sdplang" attribute SHOULD be specified when a 1428 session is distributed with sufficient scope to cross 1429 geographic boundaries, where the language of recipients cannot 1430 be assumed, or where the session is in a different language 1431 from the locally assumed norm. 1433 a=lang: 1434 This can be a session-level attribute or a media-level 1435 attribute. Multiple lang attributes can be provided either at 1436 session or media level if the session or media use multiple 1437 languages, in which case the order of the attributes indicates 1438 the order of importance of the various languages in the session 1439 or media, from most important to least important. 1441 As a session-level attribute, it specifies the default language 1442 for the session being described. As a media-level attribute, 1443 it specifies the language for that media, overriding any 1444 session-level languages specified. 1446 The "lang" attribute value must be a single [RFC5646] language 1447 tag in US-ASCII. It is not dependent on the charset attribute. 1448 A "lang" attribute SHOULD be specified when a session is of 1449 sufficient scope to cross geographic boundaries where the 1450 language of recipients cannot be assumed, or where the session 1451 is in a different language from the locally assumed norm. 1453 a=framerate: 1455 This gives the maximum video frame rate in frames/sec. It is 1456 intended as a recommendation for the encoding of video data. 1457 Decimal representations of fractional values using the notation 1458 "." are allowed. It is a media-level 1459 attribute, defined only for video media, and it is not 1460 dependent on charset. 1462 a=quality: 1464 This gives a suggestion for the quality of the encoding as an 1465 integer value. The intention of the quality attribute for 1466 video is to specify a non-default trade-off between frame-rate 1467 and still-image quality. For video, the value is in the range 1468 0 to 10, with the following suggested meaning: 1470 10 - the best still-image quality the compression scheme 1471 can give. 1472 5 - the default behaviour given no quality suggestion. 1473 0 - the worst still-image quality the codec designer 1474 thinks is still usable. 1476 It is a media-level attribute, and it is not dependent on 1477 charset. 1479 a=fmtp: 1480 This attribute allows parameters that are specific to a 1481 particular format to be conveyed in a way that SDP does not 1482 have to understand them. The format must be one of the formats 1483 specified for the media. Format-specific parameters may be any 1484 set of parameters required to be conveyed by SDP and given 1485 unchanged to the media tool that will use this format. At most 1486 one instance of this attribute is allowed for each format. 1488 It is a media-level attribute, and it is not dependent on 1489 charset. 1491 7. Security Considerations 1493 SDP is frequently used with the Session Initiation Protocol [RFC3261] 1494 using the offer/answer model [RFC3264] to agree on parameters for 1495 unicast sessions. When used in this manner, the security 1496 considerations of those protocols apply. 1498 SDP is a session description format that describes multimedia 1499 sessions. Entities receiving and acting upon an SDP message SHOULD 1500 be aware that a session description cannot be trusted unless it has 1501 been obtained by an authenticated transport protocol from a known and 1502 trusted source. Many different transport protocols may be used to 1503 distribute session descriptions, and the nature of the authentication 1504 will differ from transport to transport. For some transports, 1505 security features are often not deployed. In case a session 1506 description has not been obtained in a trusted manner, the endpoint 1507 SHOULD exercise care because, among other attacks, the media sessions 1508 received may not be the intended ones, the destination where media is 1509 sent to may not be the expected one, any of the parameters of the 1510 session may be incorrect, or the media security may be compromised. 1511 It is up to the endpoint to make a sensible decision taking into 1512 account the security risks of the application and the user 1513 preferences and may decide to ask the user whether or not to accept 1514 the session. 1516 One transport that can be used to distribute session descriptions is 1517 the Session Announcement Protocol (SAP). SAP provides both 1518 encryption and authentication mechanisms, but due to the nature of 1519 session announcements it is likely that there are many occasions 1520 where the originator of a session announcement cannot be 1521 authenticated because the originator is previously unknown to the 1522 receiver of the announcement and because no common public key 1523 infrastructure is available. 1525 On receiving a session description over an unauthenticated transport 1526 mechanism or from an untrusted party, software parsing the session 1527 should take a few precautions. Session descriptions contain 1528 information required to start software on the receiver's system. 1529 Software that parses a session description MUST NOT be able to start 1530 other software except that which is specifically configured as 1531 appropriate software to participate in multimedia sessions. It is 1532 normally considered inappropriate for software parsing a session 1533 description to start, on a user's system, software that is 1534 appropriate to participate in multimedia sessions, without the user 1535 first being informed that such software will be started and giving 1536 the user's consent. Thus, a session description arriving by session 1537 announcement, email, session invitation, or WWW page MUST NOT deliver 1538 the user into an interactive multimedia session unless the user has 1539 explicitly pre-authorised such action. As it is not always simple to 1540 tell whether or not a session is interactive, applications that are 1541 unsure should assume sessions are interactive. 1543 In this specification, there are no attributes that would allow the 1544 recipient of a session description to be informed to start multimedia 1545 tools in a mode where they default to transmitting. Under some 1546 circumstances it might be appropriate to define such attributes. If 1547 this is done, an application parsing a session description containing 1548 such attributes SHOULD either ignore them or inform the user that 1549 joining this session will result in the automatic transmission of 1550 multimedia data. The default behaviour for an unknown attribute is 1551 to ignore it. 1553 In certain environments, it has become common for intermediary 1554 systems to intercept and analyse session descriptions contained 1555 within other signalling protocols. This is done for a range of 1556 purposes, including but not limited to opening holes in firewalls to 1557 allow media streams to pass, or to mark, prioritize, or block traffic 1558 selectively. In some cases, such intermediary systems may modify the 1559 session description, for example, to have the contents of the session 1560 description match NAT bindings dynamically created. These behaviours 1561 are NOT RECOMMENDED unless the session description is conveyed in 1562 such a manner that allows the intermediary system to conduct proper 1563 checks to establish the authenticity of the session description, and 1564 the authority of its source to establish such communication sessions. 1565 SDP by itself does not include sufficient information to enable these 1566 checks: they depend on the encapsulating protocol (e.g., SIP or 1567 RTSP). 1569 Use of the "k=" field poses a significant security risk, since it 1570 conveys session encryption keys in the clear. SDP MUST NOT be used 1571 to convey key material, unless it can be guaranteed that the channel 1572 over which the SDP is delivered is both private and authenticated. 1573 Moreover, the "k=" line provides no way to indicate or negotiate 1574 cryptographic key algorithms. As it provides for only a single 1575 symmetric key, rather than separate keys for confidentiality and 1576 integrity, its utility is severely limited. The use of the "k=" line 1577 is NOT RECOMMENDED, as discussed in Section 5.12. 1579 8. IANA Considerations 1581 8.1. The "application/sdp" Media Type 1583 One media type registration from [RFC4566] is to be updated, as 1584 defined below. 1586 To: ietf-types@iana.org 1587 Subject: Registration of media type "application/sdp" 1589 Type name: application 1591 Subtype name: sdp 1593 Required parameters: None. 1595 Optional parameters: None. 1597 Encoding considerations: 1598 SDP files are primarily UTF-8 format text. The "a=charset:" 1599 attribute may be used to signal the presence of other character 1600 sets in certain parts of an SDP file (see Section 6 of RFC 1601 XXXX). Arbitrary binary content cannot be directly 1602 represented in SDP. 1604 Security considerations: 1605 See Section 7 of RFC XXXX. 1607 Interoperability considerations: 1608 See RFC XXXX. 1610 Published specification: 1611 See RFC XXXX. 1613 Applications which use this media type: 1614 Voice over IP, video teleconferencing, streaming media, instant 1615 messaging, among others. See also Section 3 of RFC XXXX. 1617 Additional information: 1619 Magic number(s): None. 1620 File extension(s): The extension ".sdp" is commonly used. 1621 Macintosh File Type Code(s): "sdp " 1623 Person & email address to contact for further information: 1625 Mark Handley 1626 Colin Perkins 1627 IETF MMUSIC working group 1629 Intended usage: COMMON 1631 Author/Change controller: 1632 Authors of RFC XXXX 1633 IETF MMUSIC working group delegated from the IESG 1635 8.2. Registration of Parameters 1637 There are seven field names that may be registered with IANA. Using 1638 the terminology in the SDP specification Backus-Naur Form (BNF), they 1639 are "media", "proto", "fmt", "att-field", "bwtype", "nettype", and 1640 "addrtype". 1642 8.2.1. Media Types ("media") 1644 The set of media types is intended to be small and SHOULD NOT be 1645 extended except under rare circumstances. The same rules should 1646 apply for media names as for top-level media types, and where 1647 possible the same name should be registered for SDP as for MIME. For 1648 media other than existing top-level media types, a Standards Track 1649 RFC MUST be produced for a new top-level media type to be registered, 1650 and the registration MUST provide good justification why no existing 1651 media name is appropriate (the "Standards Action" policy of 1652 [RFC5226]. 1654 This memo registers the media types "audio", "video", "text", 1655 "application", and "message". 1657 Note: The media types "control" and "data" were listed as valid in an 1658 early version of this specification (RFC 2327); however, their 1659 semantics were never fully specified and they are not widely used. 1660 These media types have been removed in this specification, although 1661 they still remain valid media type capabilities for a SIP user agent 1662 as defined in [RFC3840]. If these media types are considered useful 1663 in the future, a Standards Track RFC MUST be produced to document 1664 their use. Until that is done, applications SHOULD NOT use these 1665 types and SHOULD NOT declare support for them in SIP capabilities 1666 declarations (even though they exist in the registry created by 1667 [RFC3840]). 1669 8.2.2. Transport Protocols ("proto") 1670 The "proto" field describes the transport protocol used. This SHOULD 1671 reference a standards-track protocol RFC. This memo registers three 1672 values: "RTP/AVP" is a reference to [RFC3550] used under the RTP 1673 Profile for Audio and Video Conferences with Minimal Control 1674 [RFC3551] running over UDP/IP, "RTP/SAVP" is a reference to the 1675 Secure Real-time Transport Protocol [RFC3711], and "udp" indicates an 1676 unspecified protocol over UDP. 1678 If other RTP profiles are defined in the future, their "proto" name 1679 SHOULD be specified in the same manner. For example, an RTP profile 1680 whose short name is "XYZ" would be denoted by a "proto" field of "RTP 1681 /XYZ". 1683 New transport protocols SHOULD be registered with IANA. 1684 Registrations MUST reference an RFC describing the protocol. Such an 1685 RFC MAY be Experimental or Informational, although it is preferable 1686 that it be Standards Track. Registrations MUST also define the rules 1687 by which their "fmt" namespace is managed (see below). 1689 8.2.3. Media Formats ("fmt") 1691 Each transport protocol, defined by the "proto" field, has an 1692 associated "fmt" namespace that describes the media formats that may 1693 be conveyed by that protocol. Formats cover all the possible 1694 encodings that might want to be transported in a multimedia session. 1696 RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST 1697 use the payload type number as their "fmt" value. If the payload 1698 type number is dynamically assigned by this session description, an 1699 additional "rtpmap" attribute MUST be included to specify the format 1700 name and parameters as defined by the media type registration for the 1701 payload format. It is RECOMMENDED that other RTP profiles that are 1702 registered (in combination with RTP) as SDP transport protocols 1703 specify the same rules for the "fmt" namespace. 1705 For the "udp" protocol, new formats SHOULD be registered. Use of an 1706 existing media subtype for the format is encouraged. If no media 1707 subtype exists, it is RECOMMENDED that a suitable one be registered 1708 through the IETF process [RFC6838] by production of, or reference to, 1709 a standards-track RFC that defines the transport protocol for the 1710 format. 1712 For other protocols, formats MAY be registered according to the rules 1713 of the associated "proto" specification. 1715 Registrations of new formats MUST specify which transport protocols 1716 they apply to. 1718 8.2.4. Attribute Names ("att-field") 1720 Attribute field names ("att-field") MUST be registered with IANA and 1721 documented, because of noticeable issues due to conflicting 1722 attributes under the same name. Unknown attributes in SDP are simply 1723 ignored, but conflicting ones that fragment the protocol are a 1724 serious problem. 1726 New attribute registrations are accepted according to the 1727 "Specification Required" policy of [RFC5226], provided that the 1728 specification includes the following information: 1730 o contact name, email address, and telephone number 1732 o attribute name (as it will appear in SDP) 1734 o long-form attribute name in English 1736 o type of attribute (session level, media level, or both) 1738 o whether the attribute value is subject to the charset attribute 1740 o a one-paragraph explanation of the purpose of the attribute 1742 o a specification of appropriate attribute values for this attribute 1744 The above is the minimum that IANA will accept. Attributes that are 1745 expected to see widespread use and interoperability SHOULD be 1746 documented with a standards-track RFC that specifies the attribute 1747 more precisely. 1749 Submitters of registrations should ensure that the specification is 1750 in the spirit of SDP attributes, most notably that the attribute is 1751 platform independent in the sense that it makes no implicit 1752 assumptions about operating systems and does not name specific pieces 1753 of software in a manner that might inhibit interoperability. 1755 IANA has registered the following initial set of attribute names 1756 ("att-field" values), with definitions as in Section 6 of this memo 1757 (these definitions update those in [RFC4566]): 1759 Name | Session or Media level? | Dependent on charset? 1760 ----------+-------------------------+---------------------- 1761 cat | Session | No 1762 keywds | Session | Yes 1763 tool | Session | No 1764 ptime | Media | No 1765 maxptime | Media | No 1766 rtpmap | Media | No 1767 recvonly | Either | No 1768 sendrecv | Either | No 1769 sendonly | Either | No 1770 inactive | Either | No 1771 orient | Media | No 1772 type | Session | No 1773 charset | Session | No 1774 sdplang | Either | No 1775 lang | Either | No 1776 framerate | Media | No 1777 quality | Media | No 1778 fmtp | Media | No 1780 8.2.5. Bandwidth Specifiers ("bwtype") 1782 A proliferation of bandwidth specifiers is strongly discouraged. 1784 New bandwidth specifiers ("bwtype" fields) MUST be registered with 1785 IANA. The submission MUST reference a standards-track RFC specifying 1786 the semantics of the bandwidth specifier precisely, and indicating 1787 when it should be used, and why the existing registered bandwidth 1788 specifiers do not suffice. 1790 IANA has registered the bandwidth specifiers "CT" and "AS" with 1791 definitions as in Section 5.8 of this memo (these definitions update 1792 those in [RFC4566]). 1794 8.2.6. Network Types ("nettype") 1796 New network types (the "nettype" field) may be registered with IANA 1797 if SDP needs to be used in the context of non-Internet environments. 1798 Although these are not normally the preserve of IANA, there may be 1799 circumstances when an Internet application needs to interoperate with 1800 a non-Internet application, such as when gatewaying an Internet 1801 telephone call into the Public Switched Telephone Network (PSTN). 1802 The number of network types should be small and should be rarely 1803 extended. A new network type cannot be registered without 1804 registering at least one address type to be used with that network 1805 type. A new network type registration MUST reference an RFC that 1806 gives details of the network type and address type and specifies how 1807 and when they would be used. 1809 IANA has registered the network type "IN" to represent the Internet, 1810 with definition as in Sections 5.2 and 5.7 of this memo (these 1811 definitions update those in [RFC4566]). 1813 8.2.7. Address Types ("addrtype") 1815 New address types ("addrtype") may be registered with IANA. An 1816 address type is only meaningful in the context of a network type, and 1817 any registration of an address type MUST specify a registered network 1818 type or be submitted along with a network type registration. A new 1819 address type registration MUST reference an RFC giving details of the 1820 syntax of the address type. Address types are not expected to be 1821 registered frequently. 1823 IANA has registered the address types "IP4" and "IP6" with 1824 definitions as in Sections 5.2 and 5.7 of this memo (these 1825 definitions update those in [RFC4566]). 1827 8.2.8. Registration Procedure 1829 In the RFC documentation that registers SDP "media", "proto", "fmt", 1830 "bwtype", "nettype", and "addrtype" fields, the authors MUST include 1831 the following information for IANA to place in the appropriate 1832 registry: 1834 o contact name, email address, and telephone number 1836 o name being registered (as it will appear in SDP) 1838 o long-form name in English 1840 o type of name ("media", "proto", "fmt", "bwtype", "nettype", or 1841 "addrtype") 1843 o a one-paragraph explanation of the purpose of the registered name 1845 o a reference to the specification for the registered name (this 1846 will typically be an RFC number) 1848 IANA may refer any registration to the IESG for review, and may 1849 request revisions to be made before a registration will be made. 1851 8.3. Encryption Key Access Methods 1853 The IANA previously maintained a table of SDP encryption key access 1854 method ("enckey") names. This table is obsolete, since the "k=" line 1855 is not extensible. New registrations MUST NOT be accepted. 1857 9. SDP Grammar 1859 This section provides an Augmented BNF grammar for SDP. ABNF is 1860 defined in [RFC5234]. 1862 ; SDP Syntax 1863 session-description = proto-version 1864 origin-field 1865 session-name-field 1866 information-field 1867 uri-field 1868 email-fields 1869 phone-fields 1870 connection-field 1871 bandwidth-fields 1872 time-fields 1873 key-field 1874 attribute-fields 1875 media-descriptions 1877 proto-version = %x76 "=" 1*DIGIT CRLF 1878 ;this memo describes version 0 1880 origin-field = %x6f "=" username SP sess-id SP sess-version SP 1881 nettype SP addrtype SP unicast-address CRLF 1883 session-name-field = %x73 "=" text CRLF 1885 information-field = [%x69 "=" text CRLF] 1887 uri-field = [%x75 "=" uri CRLF] 1889 email-fields = *(%x65 "=" email-address CRLF) 1891 phone-fields = *(%x70 "=" phone-number CRLF) 1893 connection-field = [%x63 "=" nettype SP addrtype SP 1894 connection-address CRLF] 1895 ;a connection field must be present 1896 ;in every media description or at the 1897 ;session-level 1899 bandwidth-fields = *(%x62 "=" bwtype ":" bandwidth CRLF) 1901 time-fields = 1*( %x74 "=" start-time SP stop-time 1902 *(CRLF repeat-fields) CRLF) 1903 [zone-adjustments CRLF] 1905 repeat-fields = %x72 "=" repeat-interval SP typed-time 1906 1*(SP typed-time) 1908 zone-adjustments = %x7a "=" time SP ["-"] typed-time 1909 *(SP time SP ["-"] typed-time) 1911 key-field = [%x6b "=" key-type CRLF] 1913 attribute-fields = *(%x61 "=" attribute CRLF) 1915 media-descriptions = *( media-field 1916 information-field 1917 *connection-field 1918 bandwidth-fields 1919 key-field 1920 attribute-fields ) 1922 media-field = %x6d "=" media SP port ["/" integer] 1923 SP proto 1*(SP fmt) CRLF 1925 ; sub-rules of 'o=' 1926 username = non-ws-string 1927 ;pretty wide definition, but doesn't 1928 ;include space 1930 sess-id = 1*DIGIT 1931 ;should be unique for this username/host 1933 sess-version = 1*DIGIT 1935 nettype = token 1936 ;typically "IN" 1938 addrtype = token 1939 ;typically "IP4" or "IP6" 1941 ; sub-rules of 'u=' 1942 uri = URI-reference 1943 ; see RFC 3986 1945 ; sub-rules of 'e=', see RFC 5322 for definitions 1946 email-address = address-and-comment / dispname-and-address 1947 / addr-spec 1948 address-and-comment = addr-spec 1*SP "(" 1*email-safe ")" 1949 dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">" 1951 ; sub-rules of 'p=' 1952 phone-number = phone *SP "(" 1*email-safe ")" / 1953 1*email-safe "<" phone ">" / 1954 phone 1956 phone = ["+"] DIGIT 1*(SP / "-" / DIGIT) 1958 ; sub-rules of 'c=' 1959 connection-address = multicast-address / unicast-address 1961 ; sub-rules of 'b=' 1962 bwtype = token 1964 bandwidth = 1*DIGIT 1966 ; sub-rules of 't=' 1967 start-time = time / "0" 1969 stop-time = time / "0" 1971 time = POS-DIGIT 9*DIGIT 1972 ; Decimal representation of NTP time in 1973 ; seconds since 1900. The representation 1974 ; of NTP time is an unbounded length field 1975 ; containing at least 10 digits. Unlike the 1976 ; 64-bit representation used elsewhere, time 1977 ; in SDP does not wrap in the year 2036. 1979 ; sub-rules of 'r=' and 'z=' 1980 repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] 1982 typed-time = 1*DIGIT [fixed-len-time-unit] 1984 fixed-len-time-unit = %x64 / %x68 / %x6d / %x73 1986 ; sub-rules of 'k=' 1987 key-type = %x70 %x72 %x6f %x6d %x70 %x74 / ; "prompt" 1988 %x63 %x6c %x65 %x61 %x72 ":" text / ; "clear:" 1989 %x62 %x61 %x73 %x65 "64:" base64 / ; "base64:" 1990 %x75 %x72 %x69 ":" uri ; "uri:" 1992 base64 = *base64-unit [base64-pad] 1993 base64-unit = 4base64-char 1994 base64-pad = 2base64-char "==" / 3base64-char "=" 1995 base64-char = ALPHA / DIGIT / "+" / "/" 1997 ; sub-rules of 'a=' 1998 attribute = (att-field ":" att-value) / att-field 2000 att-field = token 2002 att-value = byte-string 2004 ; sub-rules of 'm=' 2005 media = token 2006 ;typically "audio", "video", "text", or 2007 ;"application" 2009 fmt = token 2010 ;typically an RTP payload type for audio 2011 ;and video media 2013 proto = token *("/" token) 2014 ;typically "RTP/AVP" or "udp" 2016 port = 1*DIGIT 2018 ; generic sub-rules: addressing 2019 unicast-address = IP4-address / IP6-address / FQDN / extn-addr 2021 multicast-address = IP4-multicast / IP6-multicast / FQDN 2022 / extn-addr 2024 IP4-multicast = m1 3( "." decimal-uchar ) 2025 "/" ttl [ "/" integer ] 2026 ; IP4 multicast addresses may be in the 2027 ; range 224.0.0.0 to 239.255.255.255 2029 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / 2030 ("23" DIGIT ) 2032 IP6-multicast = IP6-address [ "/" integer ] 2033 ; IP6 address starting with FF 2035 ttl = (POS-DIGIT *2DIGIT) / "0" 2037 FQDN = 4*(alpha-numeric / "-" / ".") 2038 ; fully qualified domain name as specified 2039 ; in RFC 1035 (and updates) 2041 IP4-address = b1 3("." decimal-uchar) 2043 b1 = decimal-uchar 2044 ; less than "224" 2046 IP6-address = 6( h16 ":" ) ls32 2047 / "::" 5( h16 ":" ) ls32 2048 / [ h16 ] "::" 4( h16 ":" ) ls32 2049 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 2050 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 2051 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 2052 / [ *4( h16 ":" ) h16 ] "::" ls32 2053 / [ *5( h16 ":" ) h16 ] "::" h16 2054 / [ *6( h16 ":" ) h16 ] "::" 2056 h16 = 1*4HEXDIG 2058 ls32 = ( h16 ":" h16 ) / IP4-address 2060 ; Generic for other address families 2061 extn-addr = non-ws-string 2063 ; generic sub-rules: datatypes 2064 text = byte-string 2065 ;default is to interpret this as UTF8 text. 2066 ;ISO 8859-1 requires "a=charset:ISO-8859-1" 2067 ;session-level attribute to be used 2069 byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) 2070 ;any byte except NUL, CR, or LF 2072 non-ws-string = 1*(VCHAR/%x80-FF) 2073 ;string of visible characters 2075 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 2076 / %x41-5A / %x5E-7E 2078 token = 1*(token-char) 2080 email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF 2081 ;any byte except NUL, CR, LF, or the quoting 2082 ;characters ()<> 2084 integer = POS-DIGIT *DIGIT 2086 ; generic sub-rules: primitives 2087 alpha-numeric = ALPHA / DIGIT 2089 POS-DIGIT = %x31-39 ; 1 - 9 2091 decimal-uchar = DIGIT 2092 / POS-DIGIT DIGIT 2093 / ("1" 2*(DIGIT)) 2094 / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) 2095 / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) 2097 ; external references: 2098 ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 5234 2099 ; URI-reference: from RFC 3986 2100 ; addr-spec: from RFC 5322 2102 10. Summary of Changes from RFC 4566 2104 The ABNF rule for IP6-address has been corrected. As a result, the 2105 ABNF rule for IP6-multicast has changed, and the (now unused) rules 2106 for hexpart, hexseq, and hex4 have been removed. 2108 IP4 unicast and multicast addresses in the example SDP descriptions 2109 have been revised per RFCs 5735 and 5771. 2111 Text in Section 5.2 has been revised to clarify the use of local 2112 addresses in case of ICE-like SDP extensions. 2114 Normative and informative references have been updated. 2116 The text regarding the session vs. media-level attribute usage has 2117 been clarified. 2119 The case-insensitivity rules from RFC 4855 have been included in this 2120 document. 2122 The following purely editorial changes have been made: 2124 o Section 4.6: fix typo in first sentence: "sets" -> "set" 2126 o Section 5: clarify second paragraph (SDP field and attribute names 2127 use the US-ASCII subset of UTF-8). 2129 o Section 5: clarify that an SDP session description can contain 2130 only a session-level section, with no media-level section, and 2131 that a media-level section can be terminated by the end of the 2132 session description, and not always by another media-level 2133 section. 2135 o Section 5: clearly differentiate "media" and "media description" 2136 in the description of the "c=" line. 2138 o Section 5.2: when describing the field, clarify 2139 that "an" address of the machine is used, rather than "the" 2140 address of the machine, since IP addresses identify interfaces, 2141 not hosts. 2143 o Section 5.6: use "session" rather than "conference" 2145 o Section 5.10: fix typo: "To make description" -> "To make the 2146 description" 2148 o Section 5.11: use "session description" rather than "session 2149 announcement" in the final paragraph 2151 o Section 7: fix typo: "distribute session description" -> 2152 "distribute session descriptions" 2154 11. Acknowledgements 2156 Many people in the IETF Multiparty Multimedia Session Control 2157 (MMUSIC) working group have made comments and suggestions 2158 contributing to this document. In particular, we would like to thank 2159 Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross 2160 Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna, 2161 Jonathan Lennox, Keith Drage, Sean Olson, Bernie Hoeneisen, Jonathan 2162 Rosenberg, John Elwell, Flemming Andreasen, Jon Peterson, Spencer 2163 Dawkins, Alfred Hoenes, Brett Tate and Paul Kyzivat. 2165 12. References 2167 12.1. Normative References 2169 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2170 STD 13, RFC 1034, November 1987. 2172 [RFC1035] Mockapetris, P., "Domain names - implementation and 2173 specification", STD 13, RFC 1035, November 1987. 2175 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2176 Requirement Levels", BCP 14, RFC 2119, March 1997. 2178 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2179 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2181 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2182 10646", STD 63, RFC 3629, November 2003. 2184 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2185 Resource Identifier (URI): Generic Syntax", STD 66, RFC 2186 3986, January 2005. 2188 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2189 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2190 May 2008. 2192 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 2193 Languages", BCP 47, RFC 5646, September 2009. 2195 [RFC5890] Klensin, J., "Internationalized Domain Names for 2196 Applications (IDNA): Definitions and Document Framework", 2197 RFC 5890, August 2010. 2199 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2200 Encodings", RFC 4648, October 2006. 2202 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2203 Description Protocol", RFC 4566, July 2006. 2205 12.2. Informative References 2207 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 2208 Protocol", RFC 2327, April 1998. 2210 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 2211 Time Protocol Version 4: Protocol and Algorithms 2212 Specification", RFC 5905, June 2010. 2214 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 2215 Announcement Protocol", RFC 2974, October 2000. 2217 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2218 A., Peterson, J., Sparks, R., Handley, M., and E. 2219 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2220 June 2002. 2222 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 2223 Streaming Protocol (RTSP)", RFC 2326, April 1998. 2225 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2226 with Session Description Protocol (SDP)", RFC 3264, June 2227 2002. 2229 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2230 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 2232 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2233 Jacobson, "RTP: A Transport Protocol for Real-Time 2234 Applications", STD 64, RFC 3550, July 2003. 2236 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 2237 Video Conferences with Minimal Control", STD 65, RFC 3551, 2238 July 2003. 2240 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 2241 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 2242 3556, July 2003. 2244 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2245 in Session Description Protocol (SDP)", RFC 3605, October 2246 2003. 2248 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2249 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2250 RFC 3711, March 2004. 2252 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 2253 "Indicating User Agent Capabilities in the Session 2254 Initiation Protocol (SIP)", RFC 3840, August 2004. 2256 [RFC3890] Westerlund, M., "A Transport Independent Bandwidth 2257 Modifier for the Session Description Protocol (SDP)", RFC 2258 3890, September 2004. 2260 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 2261 (ICE): A Protocol for Network Address Translator (NAT) 2262 Traversal for Offer/Answer Protocols", RFC 5245, April 2263 2010. 2265 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 2266 "TCP Candidates with Interactive Connectivity 2267 Establishment (ICE)", RFC 6544, March 2012. 2269 [ITU.H332.1998] 2270 International Telecommunication Union, "H.323 extended for 2271 loosely coupled conferences", ITU Recommendation H.332, 2272 September 1998. 2274 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 2275 Carrara, "Key Management Extensions for Session 2276 Description Protocol (SDP) and Real Time Streaming 2277 Protocol (RTSP)", RFC 4567, July 2006. 2279 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 2280 Description Protocol (SDP) Security Descriptions for Media 2281 Streams", RFC 4568, July 2006. 2283 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 2284 October 2008. 2286 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2287 Specifications and Registration Procedures", BCP 13, RFC 2288 6838, January 2013. 2290 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 2291 Formats", RFC 4855, February 2007. 2293 Authors' Addresses 2294 Mark Handley 2295 University College London 2296 Department of Computer Science 2297 London WC1E 6BT 2298 UK 2300 EMail: M.Handley@cs.ucl.ac.uk 2302 Van Jacobson 2303 PARC 2304 3333 Coyote Hill Road 2305 Palo Alto, CA 94304 2306 USA 2308 EMail: van@parc.com 2310 Colin Perkins 2311 University of Glasgow 2312 School of Computing Science 2313 University of Glasgow 2314 Glasgow G12 8QQ 2315 UK 2317 EMail: csp@csperkins.org 2319 Ali Begen 2320 Cisco 2321 181 Bay Street 2322 Toronto, ON M5J 2T3 2323 Canada 2325 EMail: abegen@cisco.com