idnits 2.17.1 draft-ietf-mmusic-rfc4566bis-04.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 -- The draft header indicates that this document obsoletes RFC4566, but the abstract doesn't seem to mention this, which it should. 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 (October 24, 2011) is 4540 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 4288 (Obsoleted by RFC 6838) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 6 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 Packet Design 6 Expires: April 26, 2012 C. Perkins 7 University of Glasgow 8 A. Begen 9 Cisco 10 October 24, 2011 12 SDP: Session Description Protocol 13 draft-ietf-mmusic-rfc4566bis-04 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. 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 April 26, 2012. 39 Copyright Notice 41 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . . 5 71 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 5 72 3.2. Streaming Media . . . . . . . . . . . . . . . . . . . . . 5 73 3.3. Email and the World Wide Web . . . . . . . . . . . . . . . 5 74 3.4. Multicast Session Announcement . . . . . . . . . . . . . . 5 75 4. Requirements and Recommendations . . . . . . . . . . . . . . . 6 76 4.1. Media and Transport Information . . . . . . . . . . . . . 7 77 4.2. Timing Information . . . . . . . . . . . . . . . . . . . . 7 78 4.3. Private Sessions . . . . . . . . . . . . . . . . . . . . . 8 79 4.4. Obtaining Further Information about a Session . . . . . . 8 80 4.5. Categorisation . . . . . . . . . . . . . . . . . . . . . . 8 81 4.6. Internationalisation . . . . . . . . . . . . . . . . . . . 8 82 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . . 8 83 5.1. Protocol Version ("v=") . . . . . . . . . . . . . . . . . 11 84 5.2. Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 11 85 5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 13 86 5.4. Session Information ("i=") . . . . . . . . . . . . . . . . 13 87 5.5. URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 13 88 5.6. Email Address and Phone Number ("e=" and "p=") . . . . . . 14 89 5.7. Connection Data ("c=") . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 31 100 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 101 8.1. The "application/sdp" Media Type . . . . . . . . . . . . . 33 102 8.2. Registration of Parameters . . . . . . . . . . . . . . . . 35 103 8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 35 104 8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 35 105 8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 36 106 8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 36 107 8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 38 108 8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 38 109 8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . . 38 110 8.2.8. Registration Procedure . . . . . . . . . . . . . . . . 39 111 8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 39 112 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 39 113 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . . 44 114 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45 115 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 116 12.1. Normative References . . . . . . . . . . . . . . . . . . . 46 117 12.2. Informative References . . . . . . . . . . . . . . . . . . 46 119 1. Introduction 121 When initiating multimedia teleconferences, voice-over-IP calls, 122 streaming video, or other sessions, there is a requirement to convey 123 media details, transport addresses, and other session description 124 metadata to the participants. 126 SDP provides a standard representation for such information, 127 irrespective of how that information is transported. SDP is purely a 128 format for session description -- it does not incorporate a transport 129 protocol, and it is intended to use different transport protocols as 130 appropriate, including the Session Announcement Protocol [RFC2974], 131 Session Initiation Protocol [RFC3261], Real Time Streaming Protocol 132 [RFC2326], electronic mail using the MIME extensions, and the 133 Hypertext Transport Protocol. 135 SDP is intended to be general purpose so that it can be used in a 136 wide range of network environments and applications. However, it is 137 not intended to support negotiation of session content or media 138 encodings: this is viewed as outside the scope of session 139 description. 141 This memo obsoletes [RFC4566]. The changes relative to [RFC4566] are 142 limited to essential corrections, and are outlined in Section 10 of 143 this memo. 145 2. Glossary of Terms 147 The following terms are used in this document and have specific 148 meaning within the context of this document. 150 Conference: A multimedia conference is a set of two or more 151 communicating users along with the software they are using to 152 communicate. 154 Session: A multimedia session is a set of multimedia senders and 155 receivers and the data streams flowing from senders to receivers. 156 A multimedia conference is an example of a multimedia session. 158 Session Description: A well-defined format for conveying sufficient 159 information to discover and participate in a multimedia session. 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 163 "OPTIONAL" in this document are to be interpreted as described in 164 [RFC2119]. 166 3. Examples of SDP Usage 168 3.1. Session Initiation 170 The Session Initiation Protocol (SIP) [RFC3261] is an application- 171 layer control protocol for creating, modifying, and terminating 172 sessions such as Internet multimedia conferences, Internet telephone 173 calls, and multimedia distribution. The SIP messages used to create 174 sessions carry session descriptions that allow participants to agree 175 on a set of compatible media types. These session descriptions are 176 commonly formatted using SDP. When used with SIP, the offer/answer 177 model [RFC3264] provides a limited framework for negotiation using 178 SDP. 180 3.2. Streaming Media 182 The Real Time Streaming Protocol (RTSP) [RFC2326], is an application- 183 level protocol for control over the delivery of data with real-time 184 properties. RTSP provides an extensible framework to enable 185 controlled, on-demand delivery of real-time data, such as audio and 186 video. An RTSP client and server negotiate an appropriate set of 187 parameters for media delivery, partially using SDP syntax to describe 188 those parameters. 190 3.3. Email and the World Wide Web 192 Alternative means of conveying session descriptions include 193 electronic mail and the World Wide Web (WWW). For both email and WWW 194 distribution, the media type "application/sdp" is used. This enables 195 the automatic launching of applications for participation in the 196 session from the WWW client or mail reader in a standard manner. 198 Note that announcements of multicast sessions made only via email or 199 the WWW do not have the property that the receiver of a session 200 announcement can necessarily receive the session because the 201 multicast sessions may be restricted in scope, and access to the WWW 202 server or reception of email is possible outside this scope. 204 3.4. Multicast Session Announcement 206 In order to assist the advertisement of multicast multimedia 207 conferences and other multicast sessions, and to communicate the 208 relevant session setup information to prospective participants, a 209 distributed session directory may be used. An instance of such a 210 session directory periodically sends packets containing a description 211 of the session to a well-known multicast group. These advertisements 212 are received by other session directories such that potential remote 213 participants can use the session description to start the tools 214 required to participate in the session. 216 One protocol used to implement such a distributed directory is the 217 Session Announcement Protocol (SAP) [RFC2974]. SDP provides the 218 recommended session description format for such session 219 announcements. 221 4. Requirements and Recommendations 223 The purpose of SDP is to convey information about media streams in 224 multimedia sessions to allow the recipients of a session description 225 to participate in the session. SDP is primarily intended for use in 226 an internetwork, although it is sufficiently general that it can 227 describe conferences in other network environments. Media streams 228 can be many-to-many. Sessions need not be continually active. 230 Thus far, multicast-based sessions on the Internet have differed from 231 many other forms of conferencing in that anyone receiving the traffic 232 can join the session (unless the session traffic is encrypted). In 233 such an environment, SDP serves two primary purposes. It is a means 234 to communicate the existence of a session, and it is a means to 235 convey sufficient information to enable joining and participating in 236 the session. In a unicast environment, only the latter purpose is 237 likely to be relevant. 239 An SDP session description includes the following: 241 o Session name and purpose 243 o Time(s) the session is active 245 o The media comprising the session 247 o Information needed to receive those media (addresses, ports, 248 formats, etc.) 250 As resources necessary to participate in a session may be limited, 251 some additional information may also be desirable: 253 o Information about the bandwidth to be used by the session 255 o Contact information for the person responsible for the session 257 In general, SDP must convey sufficient information to enable 258 applications to join a session (with the possible exception of 259 encryption keys) and to announce the resources to be used to any non- 260 participants that may need to know. (This latter feature is 261 primarily useful when SDP is used with a multicast session 262 announcement protocol.) 264 4.1. Media and Transport Information 266 An SDP session description includes the following media information: 268 o The type of media (video, audio, etc.) 270 o The transport protocol (RTP/UDP/IP, H.320, etc.) 272 o The format of the media (H.261 video, MPEG video, etc.) 274 In addition to media format and transport protocol, SDP conveys 275 address and port details. For an IP multicast session, these 276 comprise: 278 o The multicast group address for media 280 o The transport port for media 282 This address and port are the destination address and destination 283 port of the multicast stream, whether being sent, received, or both. 285 For unicast IP sessions, the following are conveyed: 287 o The remote address for media 289 o The remote transport port for media 291 The semantics of this address and port depend on the media and 292 transport protocol defined. By default, this SHOULD be the remote 293 address and remote port to which data is sent. Some media types may 294 redefine this behaviour, but this is NOT RECOMMENDED since it 295 complicates implementations (including middleboxes that must parse 296 the addresses to open Network Address Translation (NAT) or firewall 297 pinholes). 299 4.2. Timing Information 301 Sessions may be either bounded or unbounded in time. Whether or not 302 they are bounded, they may be only active at specific times. SDP can 303 convey: 305 o An arbitrary list of start and stop times bounding the session 307 o For each bound, repeat times such as "every Wednesday at 10am for 308 one hour" 310 This timing information is globally consistent, irrespective of local 311 time zone or daylight saving time (see Section 5.9). 313 4.3. Private Sessions 315 It is possible to create both public sessions and private sessions. 316 SDP itself does not distinguish between these; private sessions are 317 typically conveyed by encrypting the session description during 318 distribution. The details of how encryption is performed are 319 dependent on the mechanism used to convey SDP; mechanisms are 320 currently defined for SDP transported using SAP [RFC2974] and SIP 321 [RFC3261], and others may be defined in the future. 323 If a session announcement is private, it is possible to use that 324 private announcement to convey encryption keys necessary to decode 325 each of the media in a conference, including enough information to 326 know which encryption scheme is used for each media. 328 4.4. Obtaining Further Information about a Session 330 A session description should convey enough information to decide 331 whether or not to participate in a session. SDP may include 332 additional pointers in the form of Uniform Resource Identifiers 333 (URIs) for more information about the session. 335 4.5. Categorisation 337 When many session descriptions are being distributed by SAP, or any 338 other advertisement mechanism, it may be desirable to filter session 339 announcements that are of interest from those that are not. SDP 340 supports a categorisation mechanism for sessions that is capable of 341 being automated (the "a=cat:" attribute; see Section 6). 343 4.6. Internationalisation 345 The SDP specification recommends the use of the ISO 10646 character 346 set in the UTF-8 encoding [RFC3629] to allow many different languages 347 to be represented. However, to assist in compact representations, 348 SDP also allows other character sets such as ISO 8859-1 to be used 349 when desired. Internationalisation only applies to free-text fields 350 (session name and background information), and not to SDP as a whole. 352 5. SDP Specification 354 An SDP session description is denoted by the media type "application/ 355 sdp" (See Section 8). 357 An SDP session description is entirely textual. SDP field names and 358 attribute names use only the US-ASCII subset of UTF-8, but textual 359 fields and attribute values MAY use the full ISO 10646 character set 360 in UTF-8 encoding, or some other character set defined by the 361 "a=charset:" attribute. Field and attribute values that use the full 362 UTF-8 character set are never directly compared, hence there is no 363 requirement for UTF-8 normalisation. The textual form, as opposed to 364 a binary encoding such as ASN.1 or XDR, was chosen to enhance 365 portability, to enable a variety of transports to be used, and to 366 allow flexible, text-based toolkits to be used to generate and 367 process session descriptions. However, since SDP may be used in 368 environments where the maximum permissible size of a session 369 description is limited, the encoding is deliberately compact. Also, 370 since announcements may be transported via very unreliable means or 371 damaged by an intermediate caching server, the encoding was designed 372 with strict order and formatting rules so that most errors would 373 result in malformed session announcements that could be detected 374 easily and discarded. This also allows rapid discarding of encrypted 375 session announcements for which a receiver does not have the correct 376 key. 378 An SDP session description consists of a number of lines of text of 379 the form: 381 = 383 where MUST be exactly one case-significant character and 384 is structured text whose format depends on . In 385 general, is either a number of fields delimited by a single 386 space character or a free format string, and is case-significant 387 unless a specific field defines otherwise. Whitespace MUST NOT be 388 used on either side of the "=" sign. 390 An SDP session description consists of a session-level section 391 followed by zero or more media-level sections. The session-level 392 part starts with a "v=" line and continues to the first media-level 393 section (or the end of the whole description, whichever comes first). 394 Each media-level section starts with an "m=" line and continues to 395 the next media-level section or the end of the whole session 396 description - whichever comes first. In general, session-level 397 values are the default for all media unless overridden by an 398 equivalent media-level value. 400 Some lines in each description are REQUIRED and some are OPTIONAL, 401 but all MUST appear in exactly the order given here (the fixed order 402 greatly enhances error detection and allows for a simple parser). 403 OPTIONAL items are marked with a "*". 405 Session description 406 v= (protocol version) 407 o= (originator and session identifier) 408 s= (session name) 409 i=* (session information) 410 u=* (URI of description) 411 e=* (email address) 412 p=* (phone number) 413 c=* (connection information -- not required if included in 414 all media descriptions) 415 b=* (zero or more bandwidth information lines) 416 One or more time descriptions ("t=" and "r=" lines; see below) 417 z=* (time zone adjustments) 418 k=* (encryption key) 419 a=* (zero or more session attribute lines) 420 Zero or more media descriptions 422 Time description 423 t= (time the session is active) 424 r=* (zero or more repeat times) 426 Media description, if present 427 m= (media name and transport address) 428 i=* (media title) 429 c=* (connection information -- optional if included at 430 session level) 431 b=* (zero or more bandwidth information lines) 432 k=* (encryption key) 433 a=* (zero or more media attribute lines) 435 The set of type letters is deliberately small and not intended to be 436 extensible -- an SDP parser MUST completely ignore any session 437 description that contains a type letter that it does not understand. 438 The attribute mechanism ("a=" described below) is the primary means 439 for extending SDP and tailoring it to particular applications or 440 media. Some attributes (the ones listed in Section 6 of this memo) 441 have a defined meaning, but others may be added on an application-, 442 media-, or session-specific basis. An SDP parser MUST ignore any 443 attribute it doesn't understand. 445 An SDP session description may contain URIs that reference external 446 content in the "u=", "k=", and "a=" lines. These URIs may be 447 dereferenced in some cases, making the session description non-self- 448 contained. 450 The connection ("c=") and attribute ("a=") information in the 451 session-level section applies to all the media of that session unless 452 overridden by connection information or an attribute of the same name 453 in the media description. For instance, in the example below, each 454 media behaves as if it were given a "recvonly" attribute. 456 An example SDP description is: 458 v=0 459 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 460 s=SDP Seminar 461 i=A Seminar on the session description protocol 462 u=http://www.example.com/seminars/sdp.pdf 463 e=j.doe@example.com (Jane Doe) 464 c=IN IP4 233.252.0.1/127 465 t=2873397496 2873404696 466 a=recvonly 467 m=audio 49170 RTP/AVP 0 468 m=video 51372 RTP/AVP 99 469 a=rtpmap:99 h263-1998/90000 471 Text fields such as the session name and information are octet 472 strings that may contain any octet with the exceptions of 0x00 (Nul), 473 0x0a (ASCII newline), and 0x0d (ASCII carriage return). The sequence 474 CRLF (0x0d0a) is used to end a record, although parsers SHOULD be 475 tolerant and also accept records terminated with a single newline 476 character. If the "a=charset" attribute is not present, these octet 477 strings MUST be interpreted as containing ISO-10646 characters in 478 UTF-8 encoding (the presence of the "a=charset" attribute may force 479 some fields to be interpreted differently). 481 A session description can contain domain names in the "o=", "u=", 482 "e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply 483 with [RFC1034], [RFC1035]. Internationalised domain names (IDNs) 484 MUST be represented using the ASCII Compatible Encoding (ACE) form 485 defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or 486 any other encoding (this requirement is for compatibility with 487 [RFC4566] and other early SDP-related standards, which predate the 488 development of internationalised domain names). 490 5.1. Protocol Version ("v=") 492 v=0 494 The "v=" field gives the version of the Session Description Protocol. 495 This memo defines version 0. There is no minor version number. 497 5.2. Origin ("o=") 499 o= 500 502 The "o=" field gives the originator of the session (her username and 503 the address of the user's host) plus a session identifier and version 504 number: 506 is the user's login on the originating host, or it is "-" 507 if the originating host does not support the concept of user IDs. 508 The MUST NOT contain spaces. 510 is a numeric string such that the tuple of , 511 , , , and forms a 512 globally unique identifier for the session. The method of 513 allocation is up to the creating tool, but it has been 514 suggested that a Network Time Protocol (NTP) format timestamp be 515 used to ensure uniqueness [RFC5905]. 517 is a version number for this session description. 518 Its usage is up to the creating tool, so long as is 519 increased when a modification is made to the session data. Again, 520 it is RECOMMENDED that an NTP format timestamp is used. 522 is a text string giving the type of network. Initially 523 "IN" is defined to have the meaning "Internet", but other values 524 MAY be registered in the future (see Section 8). 526 is a text string giving the type of the address that 527 follows. Initially "IP4" and "IP6" are defined, but other values 528 MAY be registered in the future (see Section 8). 530 is an address of the machine from which the 531 session was created. For an address type of IP4, this is either a 532 fully qualified domain name of the machine or the dotted-decimal 533 representation of an IP version 4 address of the machine. For an 534 address type of IP6, this is either a fully qualified domain name 535 of the machine or the compressed textual representation of an IP 536 version 6 address of the machine. For both IP4 and IP6, the fully 537 qualified domain name is the form that SHOULD be given unless this 538 is unavailable, in which case a globally unique address MAY be 539 substituted. A local IP address MUST NOT be used in any context 540 where the SDP description might leave the scope in which the 541 address is meaningful (for example, a local address MUST NOT be 542 included in an application-level referral that might leave the 543 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 IPv4 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 IPv6 multicast does not use TTL scoping, and hence the TTL value MUST 693 NOT be present for IPv6 multicast. It is expected that IPv6 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 IPv6 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 IPv6 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 "a=orient: 1007 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 Section 1146 8.2.2). 1148 6. SDP Attributes 1150 The following attributes are defined. Since application writers may 1151 add new attributes as they are required, this list is not exhaustive. 1152 Registration procedures for new attributes are defined in Section 1153 8.2.4. 1155 a=cat: 1157 This attribute gives the dot-separated hierarchical category of 1158 the session. This is to enable a receiver to filter unwanted 1159 sessions by category. There is no central registry of 1160 categories. It is a session-level attribute, and it is not 1161 dependent on charset. 1163 a=keywds: 1165 Like the cat attribute, this is to assist identifying wanted 1166 sessions at the receiver. This allows a receiver to select 1167 interesting session based on keywords describing the purpose of 1168 the session; there is no central registry of keywords. It is a 1169 session-level attribute. It is a charset-dependent attribute, 1170 meaning that its value should be interpreted in the charset 1171 specified for the session description if one is specified, or 1172 by default in ISO 10646/UTF-8. 1174 a=tool: 1176 This gives the name and version number of the tool used to 1177 create the session description. It is a session-level 1178 attribute, and it is not dependent on charset. 1180 a=ptime: 1182 This gives the length of time in milliseconds represented by 1183 the media in a packet. This is probably only meaningful for 1184 audio data, but may be used with other media types if it makes 1185 sense. It should not be necessary to know ptime to decode RTP 1186 or vat audio, and it is intended as a recommendation for the 1187 encoding/packetisation of audio. It is a media-level 1188 attribute, and it is not dependent on charset. 1190 a=maxptime: 1192 This gives the maximum amount of media that can be encapsulated 1193 in each packet, expressed as time in milliseconds. The time 1194 SHALL be calculated as the sum of the time the media present in 1195 the packet represents. For frame-based codecs, the time SHOULD 1196 be an integer multiple of the frame size. This attribute is 1197 probably only meaningful for audio data, but may be used with 1198 other media types if it makes sense. It is a media-level 1199 attribute, and it is not dependent on charset. Note that this 1200 attribute was introduced after [RFC2327], and non-updated 1201 implementations will ignore this attribute. 1203 a=rtpmap: / [/] 1206 This attribute maps from an RTP payload type number (as used in 1207 an "m=" line) to an encoding name denoting the payload format 1208 to be used. It also provides information on the clock rate and 1209 encoding parameters. It is a media-level attribute that is not 1210 dependent on charset. 1212 Although an RTP profile may make static assignments of payload 1213 type numbers to payload formats, it is more common for that 1214 assignment to be done dynamically using "a=rtpmap:" attributes. 1215 As an example of a static payload type, consider u-law PCM 1216 coded single-channel audio sampled at 8 kHz. This is 1217 completely defined in the RTP Audio/Video profile as payload 1218 type 0, so there is no need for an "a=rtpmap:" attribute, and 1219 the media for such a stream sent to UDP port 49232 can be 1220 specified as: 1222 m=audio 49232 RTP/AVP 0 1224 An example of a dynamic payload type is 16-bit linear encoded 1225 stereo audio sampled at 16 kHz. If we wish to use the dynamic 1226 RTP/AVP payload type 98 for this stream, additional information 1227 is required to decode it: 1229 m=audio 49232 RTP/AVP 98 1230 a=rtpmap:98 L16/16000/2 1232 Up to one rtpmap attribute can be defined for each media format 1233 specified. Thus, we might have the following: 1235 m=audio 49230 RTP/AVP 96 97 98 1236 a=rtpmap:96 L8/8000 1237 a=rtpmap:97 L16/8000 1238 a=rtpmap:98 L16/11025/2 1240 RTP profiles that specify the use of dynamic payload types MUST 1241 define the set of valid encoding names and/or a means to 1242 register encoding names if that profile is to be used with SDP. 1243 The "RTP/AVP" and "RTP/SAVP" profiles use media subtypes for 1244 encoding names, under the top-level media type denoted in the 1245 "m=" line. In the example above, the media types are 1246 "audio/l8" and "audio/l16". 1248 For audio streams, indicates the number 1249 of audio channels. This parameter is OPTIONAL and may be 1250 omitted if the number of channels is one, provided that no 1251 additional parameters are needed. 1253 For video streams, no encoding parameters are currently 1254 specified. 1256 Additional encoding parameters MAY be defined in the future, 1257 but codec-specific parameters SHOULD NOT be added. Parameters 1258 added to an "a=rtpmap:" attribute SHOULD only be those required 1259 for a session directory to make the choice of appropriate media 1260 to participate in a session. Codec-specific parameters should 1261 be added in other attributes (for example, "a=fmtp:"). 1263 Note: RTP audio formats typically do not include information 1264 about the number of samples per packet. If a non-default (as 1265 defined in the RTP Audio/Video Profile) packetisation is 1266 required, the "ptime" attribute is used as given above. 1268 a=recvonly 1270 This specifies that the tools should be started in receive-only 1271 mode where applicable. It can be either a session- or media- 1272 level attribute, and it is not dependent on charset. Note that 1273 recvonly applies to the media only, not to any associated 1274 control protocol (e.g., an RTP-based system in recvonly mode 1275 SHOULD still send RTCP packets). 1277 a=sendrecv 1279 This specifies that the tools should be started in send and 1280 receive mode. This is necessary for interactive conferences 1281 with tools that default to receive-only mode. It can be either 1282 a session or media-level attribute, and it is not dependent on 1283 charset. 1285 If none of the attributes "sendonly", "recvonly", "inactive", 1286 and "sendrecv" is present, "sendrecv" SHOULD be assumed as the 1287 default for sessions that are not of the conference type 1288 "broadcast" or "H332" (see below). 1290 a=sendonly 1292 This specifies that the tools should be started in send-only 1293 mode. An example may be where a different unicast address is 1294 to be used for a traffic destination than for a traffic source. 1295 In such a case, two media descriptions may be used, one 1296 sendonly and one recvonly. It can be either a session- or 1297 media-level attribute, but would normally only be used as a 1298 media attribute. It is not dependent on charset. Note that 1299 sendonly applies only to the media, and any associated control 1300 protocol (e.g., RTCP) SHOULD still be received and processed as 1301 normal. 1303 a=inactive 1305 This specifies that the tools should be started in inactive 1306 mode. This is necessary for interactive conferences where 1307 users can put other users on hold. No media is sent over an 1308 inactive media stream. Note that an RTP-based system SHOULD 1309 still send RTCP, even if started inactive. It can be either a 1310 session or media-level attribute, and it is not dependent on 1311 charset. 1313 a=orient: 1315 Normally this is only used for a whiteboard or presentation 1316 tool. It specifies the orientation of a the workspace on the 1317 screen. It is a media-level attribute. Permitted values are 1318 "portrait", "landscape", and "seascape" (upside-down 1319 landscape). It is not dependent on charset. 1321 a=type: 1323 This specifies the type of the conference. Suggested values 1324 are "broadcast", "meeting", "moderated", "test", and "H332". 1325 "recvonly" should be the default for "type:broadcast" sessions, 1326 "type:meeting" should imply "sendrecv", and "type:moderated" 1327 should indicate the use of a floor control tool and that the 1328 media tools are started so as to mute new sites joining the 1329 conference. 1331 Specifying the attribute "type:H332" indicates that this 1332 loosely coupled session is part of an H.332 session as defined 1333 in the ITU H.332 specification [ITU.H332.1998]. Media tools 1334 should be started "recvonly". 1336 Specifying the attribute "type:test" is suggested as a hint 1337 that, unless explicitly requested otherwise, receivers can 1338 safely avoid displaying this session description to users. 1340 The type attribute is a session-level attribute, and it is not 1341 dependent on charset. 1343 a=charset: 1345 This specifies the character set to be used to display the 1346 session name and information data. By default, the ISO-10646 1347 character set in UTF-8 encoding is used. If a more compact 1348 representation is required, other character sets may be used. 1349 For example, the ISO 8859-1 is specified with the following SDP 1350 attribute: 1352 a=charset:ISO-8859-1 1354 This is a session-level attribute and is not dependent on 1355 charset. The charset specified MUST be one of those registered 1356 with IANA, such as ISO-8859-1. The character set identifier is 1357 a US-ASCII string and MUST be compared against the IANA 1358 identifiers using a case-insensitive comparison. If the 1359 identifier is not recognised or not supported, all strings that 1360 are affected by it SHOULD be regarded as octet strings. 1362 Note that a character set specified MUST still prohibit the use 1363 of bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets 1364 requiring the use of these characters MUST define a quoting 1365 mechanism that prevents these bytes from appearing within text 1366 fields. 1368 a=sdplang: 1370 This can be a session-level attribute or a media-level 1371 attribute. As a session-level attribute, it specifies the 1372 language for the session description. As a media-level 1373 attribute, it specifies the language for any media-level SDP 1374 information field associated with that media. Multiple sdplang 1375 attributes can be provided either at session or media level if 1376 the session description or media use multiple languages. 1378 In general, sending session descriptions consisting of multiple 1379 languages is discouraged. Instead, multiple descriptions 1380 SHOULD be sent describing the session, one in each language. 1381 However, this is not possible with all transport mechanisms, 1382 and so multiple sdplang attributes are allowed although NOT 1383 RECOMMENDED. 1385 The "sdplang" attribute value must be a single [RFC5646] 1386 language tag in US-ASCII. It is not dependent on the charset 1387 attribute. An "sdplang" attribute SHOULD be specified when a 1388 session is distributed with sufficient scope to cross 1389 geographic boundaries, where the language of recipients cannot 1390 be assumed, or where the session is in a different language 1391 from the locally assumed norm. 1393 a=lang: 1395 This can be a session-level attribute or a media-level 1396 attribute. As a session-level attribute, it specifies the 1397 default language for the session being described. As a media- 1398 level attribute, it specifies the language for that media, 1399 overriding any session-level language specified. Multiple lang 1400 attributes can be provided either at session or media level if 1401 the session or media use multiple languages, in which case the 1402 order of the attributes indicates the order of importance of 1403 the various languages in the session or media, from most 1404 important to least important. 1406 The "lang" attribute value must be a single [RFC5646] language 1407 tag in US-ASCII. It is not dependent on the charset attribute. 1408 A "lang" attribute SHOULD be specified when a session is of 1409 sufficient scope to cross geographic boundaries where the 1410 language of recipients cannot be assumed, or where the session 1411 is in a different language from the locally assumed norm. 1413 a=framerate: 1415 This gives the maximum video frame rate in frames/sec. It is 1416 intended as a recommendation for the encoding of video data. 1417 Decimal representations of fractional values using the notation 1418 "." are allowed. It is a media-level 1419 attribute, defined only for video media, and it is not 1420 dependent on charset. 1422 a=quality: 1424 This gives a suggestion for the quality of the encoding as an 1425 integer value. The intention of the quality attribute for 1426 video is to specify a non-default trade-off between frame-rate 1427 and still-image quality. For video, the value is in the range 1428 0 to 10, with the following suggested meaning: 1430 10 - the best still-image quality the compression scheme 1431 can give. 1432 5 - the default behaviour given no quality suggestion. 1433 0 - the worst still-image quality the codec designer 1434 thinks is still usable. 1436 It is a media-level attribute, and it is not dependent on 1437 charset. 1439 a=fmtp: 1441 This attribute allows parameters that are specific to a 1442 particular format to be conveyed in a way that SDP does not 1443 have to understand them. The format must be one of the formats 1444 specified for the media. Format-specific parameters may be any 1445 set of parameters required to be conveyed by SDP and given 1446 unchanged to the media tool that will use this format. At most 1447 one instance of this attribute is allowed for each format. 1449 It is a media-level attribute, and it is not dependent on 1450 charset. 1452 7. Security Considerations 1454 SDP is frequently used with the Session Initiation Protocol [RFC3261] 1455 using the offer/answer model [RFC3264] to agree on parameters for 1456 unicast sessions. When used in this manner, the security 1457 considerations of those protocols apply. 1459 SDP is a session description format that describes multimedia 1460 sessions. Entities receiving and acting upon an SDP message SHOULD 1461 be aware that a session description cannot be trusted unless it has 1462 been obtained by an authenticated transport protocol from a known and 1463 trusted source. Many different transport protocols may be used to 1464 distribute session descriptions, and the nature of the authentication 1465 will differ from transport to transport. For some transports, 1466 security features are often not deployed. In case a session 1467 description has not been obtained in a trusted manner, the endpoint 1468 SHOULD exercise care because, among other attacks, the media sessions 1469 received may not be the intended ones, the destination where media is 1470 sent to may not be the expected one, any of the parameters of the 1471 session may be incorrect, or the media security may be compromised. 1472 It is up to the endpoint to make a sensible decision taking into 1473 account the security risks of the application and the user 1474 preferences and may decide to ask the user whether or not to accept 1475 the session. 1477 One transport that can be used to distribute session descriptions is 1478 the Session Announcement Protocol (SAP). SAP provides both 1479 encryption and authentication mechanisms, but due to the nature of 1480 session announcements it is likely that there are many occasions 1481 where the originator of a session announcement cannot be 1482 authenticated because the originator is previously unknown to the 1483 receiver of the announcement and because no common public key 1484 infrastructure is available. 1486 On receiving a session description over an unauthenticated transport 1487 mechanism or from an untrusted party, software parsing the session 1488 should take a few precautions. Session descriptions contain 1489 information required to start software on the receiver's system. 1490 Software that parses a session description MUST NOT be able to start 1491 other software except that which is specifically configured as 1492 appropriate software to participate in multimedia sessions. It is 1493 normally considered inappropriate for software parsing a session 1494 description to start, on a user's system, software that is 1495 appropriate to participate in multimedia sessions, without the user 1496 first being informed that such software will be started and giving 1497 the user's consent. Thus, a session description arriving by session 1498 announcement, email, session invitation, or WWW page MUST NOT deliver 1499 the user into an interactive multimedia session unless the user has 1500 explicitly pre-authorised such action. As it is not always simple to 1501 tell whether or not a session is interactive, applications that are 1502 unsure should assume sessions are interactive. 1504 In this specification, there are no attributes that would allow the 1505 recipient of a session description to be informed to start multimedia 1506 tools in a mode where they default to transmitting. Under some 1507 circumstances it might be appropriate to define such attributes. If 1508 this is done, an application parsing a session description containing 1509 such attributes SHOULD either ignore them or inform the user that 1510 joining this session will result in the automatic transmission of 1511 multimedia data. The default behaviour for an unknown attribute is 1512 to ignore it. 1514 In certain environments, it has become common for intermediary 1515 systems to intercept and analyse session descriptions contained 1516 within other signalling protocols. This is done for a range of 1517 purposes, including but not limited to opening holes in firewalls to 1518 allow media streams to pass, or to mark, prioritize, or block traffic 1519 selectively. In some cases, such intermediary systems may modify the 1520 session description, for example, to have the contents of the session 1521 description match NAT bindings dynamically created. These behaviours 1522 are NOT RECOMMENDED unless the session description is conveyed in 1523 such a manner that allows the intermediary system to conduct proper 1524 checks to establish the authenticity of the session description, and 1525 the authority of its source to establish such communication sessions. 1526 SDP by itself does not include sufficient information to enable these 1527 checks: they depend on the encapsulating protocol (e.g., SIP or 1528 RTSP). 1530 Use of the "k=" field poses a significant security risk, since it 1531 conveys session encryption keys in the clear. SDP MUST NOT be used 1532 to convey key material, unless it can be guaranteed that the channel 1533 over which the SDP is delivered is both private and authenticated. 1534 Moreover, the "k=" line provides no way to indicate or negotiate 1535 cryptographic key algorithms. As it provides for only a single 1536 symmetric key, rather than separate keys for confidentiality and 1537 integrity, its utility is severely limited. The use of the "k=" line 1538 is NOT RECOMMENDED, as discussed in Section 5.12. 1540 8. IANA Considerations 1542 8.1. The "application/sdp" Media Type 1544 One media type registration from [RFC4566] is to be updated, as 1545 defined below. 1547 To: ietf-types@iana.org 1548 Subject: Registration of media type "application/sdp" 1550 Type name: application 1552 Subtype name: sdp 1554 Required parameters: None. 1556 Optional parameters: None. 1558 Encoding considerations: 1559 SDP files are primarily UTF-8 format text. The "a=charset:" 1560 attribute may be used to signal the presence of other character 1561 sets in certain parts of an SDP file (see Section 6 of RFC 1562 XXXX). Arbitrary binary content cannot be directly 1563 represented in SDP. 1565 Security considerations: 1566 See Section 7 of RFC XXXX. 1568 Interoperability considerations: 1569 See RFC XXXX. 1571 Published specification: 1572 See RFC XXXX. 1574 Applications which use this media type: 1575 Voice over IP, video teleconferencing, streaming media, instant 1576 messaging, among others. See also Section 3 of RFC XXXX. 1578 Additional information: 1580 Magic number(s): None. 1581 File extension(s): The extension ".sdp" is commonly used. 1582 Macintosh File Type Code(s): "sdp " 1584 Person & email address to contact for further information: 1585 Mark Handley 1586 Colin Perkins 1587 IETF MMUSIC working group 1589 Intended usage: COMMON 1591 Author/Change controller: 1592 Authors of RFC XXXX 1593 IETF MMUSIC working group delegated from the IESG 1595 8.2. Registration of Parameters 1597 There are seven field names that may be registered with IANA. Using 1598 the terminology in the SDP specification Backus-Naur Form (BNF), they 1599 are "media", "proto", "fmt", "att-field", "bwtype", "nettype", and 1600 "addrtype". 1602 8.2.1. Media Types ("media") 1604 The set of media types is intended to be small and SHOULD NOT be 1605 extended except under rare circumstances. The same rules should 1606 apply for media names as for top-level media content types, and where 1607 possible the same name should be registered for SDP as for MIME. For 1608 media other than existing top-level media content types, a Standards 1609 Track RFC MUST be produced for a new top-level content type to be 1610 registered, and the registration MUST provide good justification why 1611 no existing media name is appropriate (the "Standards Action" policy 1612 of [RFC5226]. 1614 This memo registers the media types "audio", "video", "text", 1615 "application", and "message". 1617 Note: The media types "control" and "data" were listed as valid in an 1618 early version of this specification (RFC 2327); however, their 1619 semantics were never fully specified and they are not widely used. 1620 These media types have been removed in this specification, although 1621 they still remain valid media type capabilities for a SIP user agent 1622 as defined in [RFC3840]. If these media types are considered useful 1623 in the future, a Standards Track RFC MUST be produced to document 1624 their use. Until that is done, applications SHOULD NOT use these 1625 types and SHOULD NOT declare support for them in SIP capabilities 1626 declarations (even though they exist in the registry created by 1627 [RFC3840]). 1629 8.2.2. Transport Protocols ("proto") 1631 The "proto" field describes the transport protocol used. This SHOULD 1632 reference a standards-track protocol RFC. This memo registers three 1633 values: "RTP/AVP" is a reference to [RFC3550] used under the RTP 1634 Profile for Audio and Video Conferences with Minimal Control 1635 [RFC3551] running over UDP/IP, "RTP/SAVP" is a reference to the 1636 Secure Real-time Transport Protocol [RFC3711], and "udp" indicates an 1637 unspecified protocol over UDP. 1639 If other RTP profiles are defined in the future, their "proto" name 1640 SHOULD be specified in the same manner. For example, an RTP profile 1641 whose short name is "XYZ" would be denoted by a "proto" field of 1642 "RTP/XYZ". 1644 New transport protocols SHOULD be registered with IANA. 1645 Registrations MUST reference an RFC describing the protocol. Such an 1646 RFC MAY be Experimental or Informational, although it is preferable 1647 that it be Standards Track. Registrations MUST also define the rules 1648 by which their "fmt" namespace is managed (see below). 1650 8.2.3. Media Formats ("fmt") 1652 Each transport protocol, defined by the "proto" field, has an 1653 associated "fmt" namespace that describes the media formats that may 1654 be conveyed by that protocol. Formats cover all the possible 1655 encodings that might want to be transported in a multimedia session. 1657 RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST 1658 use the payload type number as their "fmt" value. If the payload 1659 type number is dynamically assigned by this session description, an 1660 additional "rtpmap" attribute MUST be included to specify the format 1661 name and parameters as defined by the media type registration for the 1662 payload format. It is RECOMMENDED that other RTP profiles that are 1663 registered (in combination with RTP) as SDP transport protocols 1664 specify the same rules for the "fmt" namespace. 1666 For the "udp" protocol, new formats SHOULD be registered. Use of an 1667 existing media subtype for the format is encouraged. If no media 1668 subtype exists, it is RECOMMENDED that a suitable one be registered 1669 through the IETF process [RFC4288] by production of, or reference to, 1670 a standards-track RFC that defines the transport protocol for the 1671 format. 1673 For other protocols, formats MAY be registered according to the rules 1674 of the associated "proto" specification. 1676 Registrations of new formats MUST specify which transport protocols 1677 they apply to. 1679 8.2.4. Attribute Names ("att-field") 1681 Attribute field names ("att-field") MUST be registered with IANA and 1682 documented, because of noticeable issues due to conflicting 1683 attributes under the same name. Unknown attributes in SDP are simply 1684 ignored, but conflicting ones that fragment the protocol are a 1685 serious problem. 1687 New attribute registrations are accepted according to the 1688 "Specification Required" policy of [RFC5226], provided that the 1689 specification includes the following information: 1691 o contact name, email address, and telephone number 1693 o attribute name (as it will appear in SDP) 1695 o long-form attribute name in English 1697 o type of attribute (session level, media level, or both) 1699 o whether the attribute value is subject to the charset attribute 1701 o a one-paragraph explanation of the purpose of the attribute 1703 o a specification of appropriate attribute values for this attribute 1705 The above is the minimum that IANA will accept. Attributes that are 1706 expected to see widespread use and interoperability SHOULD be 1707 documented with a standards-track RFC that specifies the attribute 1708 more precisely. 1710 Submitters of registrations should ensure that the specification is 1711 in the spirit of SDP attributes, most notably that the attribute is 1712 platform independent in the sense that it makes no implicit 1713 assumptions about operating systems and does not name specific pieces 1714 of software in a manner that might inhibit interoperability. 1716 IANA has registered the following initial set of attribute names 1717 ("att-field" values), with definitions as in Section 6 of this memo 1718 (these definitions update those in [RFC4566]): 1720 Name | Session or Media level? | Dependent on charset? 1721 ----------+-------------------------+---------------------- 1722 cat | Session | No 1723 keywds | Session | Yes 1724 tool | Session | No 1725 ptime | Media | No 1726 maxptime | Media | No 1727 rtpmap | Media | No 1728 recvonly | Either | No 1729 sendrecv | Either | No 1730 sendonly | Either | No 1731 inactive | Either | No 1732 orient | Media | No 1733 type | Session | No 1734 charset | Session | No 1735 sdplang | Either | No 1736 lang | Either | No 1737 framerate | Media | No 1738 quality | Media | No 1739 fmtp | Media | No 1741 8.2.5. Bandwidth Specifiers ("bwtype") 1743 A proliferation of bandwidth specifiers is strongly discouraged. 1745 New bandwidth specifiers ("bwtype" fields) MUST be registered with 1746 IANA. The submission MUST reference a standards-track RFC specifying 1747 the semantics of the bandwidth specifier precisely, and indicating 1748 when it should be used, and why the existing registered bandwidth 1749 specifiers do not suffice. 1751 IANA has registered the bandwidth specifiers "CT" and "AS" with 1752 definitions as in Section 5.8 of this memo (these definitions update 1753 those in [RFC4566]). 1755 8.2.6. Network Types ("nettype") 1757 New network types (the "nettype" field) may be registered with IANA 1758 if SDP needs to be used in the context of non-Internet environments. 1759 Although these are not normally the preserve of IANA, there may be 1760 circumstances when an Internet application needs to interoperate with 1761 a non-Internet application, such as when gatewaying an Internet 1762 telephone call into the Public Switched Telephone Network (PSTN). 1763 The number of network types should be small and should be rarely 1764 extended. A new network type cannot be registered without 1765 registering at least one address type to be used with that network 1766 type. A new network type registration MUST reference an RFC that 1767 gives details of the network type and address type and specifies how 1768 and when they would be used. 1770 IANA has registered the network type "IN" to represent the Internet, 1771 with definition as in Sections 5.2 and 5.7 of this memo (these 1772 definitions update those in [RFC4566]). 1774 8.2.7. Address Types ("addrtype") 1776 New address types ("addrtype") may be registered with IANA. An 1777 address type is only meaningful in the context of a network type, and 1778 any registration of an address type MUST specify a registered network 1779 type or be submitted along with a network type registration. A new 1780 address type registration MUST reference an RFC giving details of the 1781 syntax of the address type. Address types are not expected to be 1782 registered frequently. 1784 IANA has registered the address types "IP4" and "IP6" with 1785 definitions as in Sections 5.2 and 5.7 of this memo (these 1786 definitions update those in [RFC4566]). 1788 8.2.8. Registration Procedure 1790 In the RFC documentation that registers SDP "media", "proto", "fmt", 1791 "bwtype", "nettype", and "addrtype" fields, the authors MUST include 1792 the following information for IANA to place in the appropriate 1793 registry: 1795 o contact name, email address, and telephone number 1797 o name being registered (as it will appear in SDP) 1799 o long-form name in English 1801 o type of name ("media", "proto", "fmt", "bwtype", "nettype", or 1802 "addrtype") 1804 o a one-paragraph explanation of the purpose of the registered name 1806 o a reference to the specification for the registered name (this 1807 will typically be an RFC number) 1809 IANA may refer any registration to the IESG for review, and may 1810 request revisions to be made before a registration will be made. 1812 8.3. Encryption Key Access Methods 1814 The IANA previously maintained a table of SDP encryption key access 1815 method ("enckey") names. This table is obsolete, since the "k=" line 1816 is not extensible. New registrations MUST NOT be accepted. 1818 9. SDP Grammar 1820 This section provides an Augmented BNF grammar for SDP. ABNF is 1821 defined in [RFC5234]. 1823 ; SDP Syntax 1824 session-description = proto-version 1825 origin-field 1826 session-name-field 1827 information-field 1828 uri-field 1829 email-fields 1830 phone-fields 1831 connection-field 1832 bandwidth-fields 1833 time-fields 1834 key-field 1835 attribute-fields 1836 media-descriptions 1838 proto-version = %x76 "=" 1*DIGIT CRLF 1839 ;this memo describes version 0 1841 origin-field = %x6f "=" username SP sess-id SP sess-version SP 1842 nettype SP addrtype SP unicast-address CRLF 1844 session-name-field = %x73 "=" text CRLF 1846 information-field = [%x69 "=" text CRLF] 1848 uri-field = [%x75 "=" uri CRLF] 1850 email-fields = *(%x65 "=" email-address CRLF) 1852 phone-fields = *(%x70 "=" phone-number CRLF) 1854 connection-field = [%x63 "=" nettype SP addrtype SP 1855 connection-address CRLF] 1856 ;a connection field must be present 1857 ;in every media description or at the 1858 ;session-level 1860 bandwidth-fields = *(%x62 "=" bwtype ":" bandwidth CRLF) 1862 time-fields = 1*( %x74 "=" start-time SP stop-time 1863 *(CRLF repeat-fields) CRLF) 1864 [zone-adjustments CRLF] 1866 repeat-fields = %x72 "=" repeat-interval SP typed-time 1867 1*(SP typed-time) 1869 zone-adjustments = %x7a "=" time SP ["-"] typed-time 1870 *(SP time SP ["-"] typed-time) 1872 key-field = [%x6b "=" key-type CRLF] 1874 attribute-fields = *(%x61 "=" attribute CRLF) 1876 media-descriptions = *( media-field 1877 information-field 1878 *connection-field 1879 bandwidth-fields 1880 key-field 1881 attribute-fields ) 1883 media-field = %x6d "=" media SP port ["/" integer] 1884 SP proto 1*(SP fmt) CRLF 1886 ; sub-rules of 'o=' 1887 username = non-ws-string 1888 ;pretty wide definition, but doesn't 1889 ;include space 1891 sess-id = 1*DIGIT 1892 ;should be unique for this username/host 1894 sess-version = 1*DIGIT 1896 nettype = token 1897 ;typically "IN" 1899 addrtype = token 1900 ;typically "IP4" or "IP6" 1902 ; sub-rules of 'u=' 1903 uri = URI-reference 1904 ; see RFC 3986 1906 ; sub-rules of 'e=', see RFC 5322 for definitions 1907 email-address = address-and-comment / dispname-and-address 1908 / addr-spec 1909 address-and-comment = addr-spec 1*SP "(" 1*email-safe ")" 1910 dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">" 1912 ; sub-rules of 'p=' 1913 phone-number = phone *SP "(" 1*email-safe ")" / 1914 1*email-safe "<" phone ">" / 1915 phone 1917 phone = ["+"] DIGIT 1*(SP / "-" / DIGIT) 1919 ; sub-rules of 'c=' 1920 connection-address = multicast-address / unicast-address 1922 ; sub-rules of 'b=' 1923 bwtype = token 1925 bandwidth = 1*DIGIT 1927 ; sub-rules of 't=' 1928 start-time = time / "0" 1930 stop-time = time / "0" 1931 time = POS-DIGIT 9*DIGIT 1932 ; Decimal representation of NTP time in 1933 ; seconds since 1900. The representation 1934 ; of NTP time is an unbounded length field 1935 ; containing at least 10 digits. Unlike the 1936 ; 64-bit representation used elsewhere, time 1937 ; in SDP does not wrap in the year 2036. 1939 ; sub-rules of 'r=' and 'z=' 1940 repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] 1942 typed-time = 1*DIGIT [fixed-len-time-unit] 1944 fixed-len-time-unit = %x64 / %x68 / %x6d / %x73 1946 ; sub-rules of 'k=' 1947 key-type = %x70 %x72 %x6f %x6d %x70 %x74 / ; "prompt" 1948 %x63 %x6c %x65 %x61 %x72 ":" text / ; "clear:" 1949 %x62 %x61 %x73 %x65 "64:" base64 / ; "base64:" 1950 %x75 %x72 %x69 ":" uri ; "uri:" 1952 base64 = *base64-unit [base64-pad] 1953 base64-unit = 4base64-char 1954 base64-pad = 2base64-char "==" / 3base64-char "=" 1955 base64-char = ALPHA / DIGIT / "+" / "/" 1957 ; sub-rules of 'a=' 1958 attribute = (att-field ":" att-value) / att-field 1960 att-field = token 1962 att-value = byte-string 1964 ; sub-rules of 'm=' 1965 media = token 1966 ;typically "audio", "video", "text", or 1967 ;"application" 1969 fmt = token 1970 ;typically an RTP payload type for audio 1971 ;and video media 1973 proto = token *("/" token) 1974 ;typically "RTP/AVP" or "udp" 1976 port = 1*DIGIT 1978 ; generic sub-rules: addressing 1979 unicast-address = IP4-address / IP6-address / FQDN / extn-addr 1981 multicast-address = IP4-multicast / IP6-multicast / FQDN 1982 / extn-addr 1984 IP4-multicast = m1 3( "." decimal-uchar ) 1985 "/" ttl [ "/" integer ] 1986 ; IPv4 multicast addresses may be in the 1987 ; range 224.0.0.0 to 239.255.255.255 1989 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / 1990 ("23" DIGIT ) 1992 IP6-multicast = IP6-address [ "/" integer ] 1993 ; IPv6 address starting with FF 1995 ttl = (POS-DIGIT *2DIGIT) / "0" 1997 FQDN = 4*(alpha-numeric / "-" / ".") 1998 ; fully qualified domain name as specified 1999 ; in RFC 1035 (and updates) 2001 IP4-address = b1 3("." decimal-uchar) 2003 b1 = decimal-uchar 2004 ; less than "224" 2006 IP6-address = 6( h16 ":" ) ls32 2007 / "::" 5( h16 ":" ) ls32 2008 / [ h16 ] "::" 4( h16 ":" ) ls32 2009 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 2010 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 2011 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 2012 / [ *4( h16 ":" ) h16 ] "::" ls32 2013 / [ *5( h16 ":" ) h16 ] "::" h16 2014 / [ *6( h16 ":" ) h16 ] "::" 2016 h16 = 1*4HEXDIG 2018 ls32 = ( h16 ":" h16 ) / IP4-address 2020 ; Generic for other address families 2021 extn-addr = non-ws-string 2023 ; generic sub-rules: datatypes 2024 text = byte-string 2025 ;default is to interpret this as UTF8 text. 2026 ;ISO 8859-1 requires "a=charset:ISO-8859-1" 2027 ;session-level attribute to be used 2029 byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) 2030 ;any byte except NUL, CR, or LF 2032 non-ws-string = 1*(VCHAR/%x80-FF) 2033 ;string of visible characters 2035 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 2036 / %x41-5A / %x5E-7E 2038 token = 1*(token-char) 2040 email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF 2041 ;any byte except NUL, CR, LF, or the quoting 2042 ;characters ()<> 2044 integer = POS-DIGIT *DIGIT 2046 ; generic sub-rules: primitives 2047 alpha-numeric = ALPHA / DIGIT 2049 POS-DIGIT = %x31-39 ; 1 - 9 2051 decimal-uchar = DIGIT 2052 / POS-DIGIT DIGIT 2053 / ("1" 2*(DIGIT)) 2054 / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) 2055 / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) 2057 ; external references: 2058 ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 5234 2059 ; URI-reference: from RFC 3986 2060 ; addr-spec: from RFC 5322 2062 10. Summary of Changes from RFC 4566 2064 The ABNF rule for IP6-address has been corrected. As a result, the 2065 ABNF rule for IP6-multicast has changed, and the (now unused) rules 2066 for hexpart, hexseq, and hex4 have been removed. 2068 IPv4 unicast and multicast addresses in the example SDP descriptions 2069 have been revised per RFCs 5735 and 5771. 2071 Normative and informative references have been updated. 2073 The following purely editorial changes have been made: 2075 o Section 4.6: fix typo in first sentence: "sets" -> "set" 2077 o Section 5: clarify second paragraph (SDP field and attribute names 2078 use the US-ASCII subset of UTF-8). 2080 o Section 5: clarify that an SDP session description can contain 2081 only a session-level section, with no media-level section, and 2082 that a media-level section can be terminated by the end of the 2083 session description, and not always by another media-level 2084 section. 2086 o Section 5: clearly differentiate "media" and "media description" 2087 in the description of the "c=" line. 2089 o Section 5.2: when describing the field, clarify 2090 that "an" address of the machine is used, rather than "the" 2091 address of the machine, since IP addresses identify interfaces, 2092 not hosts. 2094 o Section 5.6: use "session" rather than "conference" 2096 o Section 5.10: fix typo: "To make description" -> "To make the 2097 description" 2099 o Section 5.11: use "session description" rather than "session 2100 announcement" in the final paragraph 2102 o Section 7: fix typo: "distribute session description" -> 2103 "distribute session descriptions" 2105 Clarify the use of multiple "a=sdplang:" and "a=lang:" attributes, 2106 and when "a=sdplang:" should be used. 2108 11. Acknowledgements 2110 Many people in the IETF Multiparty Multimedia Session Control 2111 (MMUSIC) working group have made comments and suggestions 2112 contributing to this document. In particular, we would like to thank 2113 Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross 2114 Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna, 2115 Jonathan Lennox, Keith Drage, Sean Olson, Bernie Hoeneisen, Jonathan 2116 Rosenberg, John Elwell, Flemming Andreasen, Jon Peterson, Spencer 2117 Dawkins, and Alfred Hoenes. 2119 12. References 2120 12.1. Normative References 2122 [RFC1034] Mockapetris, P., "Domain names - concepts and 2123 facilities", STD 13, RFC 1034, November 1987. 2125 [RFC1035] Mockapetris, P., "Domain names - implementation and 2126 specification", STD 13, RFC 1035, November 1987. 2128 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2129 Requirement Levels", BCP 14, RFC 2119, March 1997. 2131 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for 2132 Syntax Specifications: ABNF", STD 68, RFC 5234, 2133 January 2008. 2135 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2136 10646", STD 63, RFC 3629, November 2003. 2138 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, 2139 "Uniform Resource Identifier (URI): Generic Syntax", 2140 STD 66, RFC 3986, January 2005. 2142 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for 2143 Writing an IANA Considerations Section in RFCs", 2144 BCP 26, RFC 5226, May 2008. 2146 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 2147 Languages", BCP 47, RFC 5646, September 2009. 2149 [RFC5890] Klensin, J., "Internationalized Domain Names for 2150 Applications (IDNA): Definitions and Document 2151 Framework", RFC 5890, August 2010. 2153 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2154 Encodings", RFC 4648, October 2006. 2156 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: 2157 Session Description Protocol", RFC 4566, July 2006. 2159 12.2. Informative References 2161 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session 2162 Description Protocol", RFC 2327, April 1998. 2164 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, 2165 "Network Time Protocol Version 4: Protocol and 2166 Algorithms Specification", RFC 5905, June 2010. 2168 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 2169 Announcement Protocol", RFC 2974, October 2000. 2171 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., 2172 Johnston, A., Peterson, J., Sparks, R., Handley, M., 2173 and E. Schooler, "SIP: Session Initiation Protocol", 2174 RFC 3261, June 2002. 2176 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real 2177 Time Streaming Protocol (RTSP)", RFC 2326, 2178 April 1998. 2180 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer 2181 Model with Session Description Protocol (SDP)", 2182 RFC 3264, June 2002. 2184 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session 2185 Description Protocol (SDP) Grouping Framework", 2186 RFC 5888, June 2010. 2188 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2189 Jacobson, "RTP: A Transport Protocol for Real-Time 2190 Applications", STD 64, RFC 3550, July 2003. 2192 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for 2193 Audio and Video Conferences with Minimal Control", 2194 STD 65, RFC 3551, July 2003. 2196 [RFC3556] Casner, S., "Session Description Protocol (SDP) 2197 Bandwidth Modifiers for RTP Control Protocol (RTCP) 2198 Bandwidth", RFC 3556, July 2003. 2200 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) 2201 attribute in Session Description Protocol (SDP)", 2202 RFC 3605, October 2003. 2204 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., 2205 and K. Norrman, "The Secure Real-time Transport 2206 Protocol (SRTP)", RFC 3711, March 2004. 2208 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 2209 "Indicating User Agent Capabilities in the Session 2210 Initiation Protocol (SIP)", RFC 3840, August 2004. 2212 [RFC3890] Westerlund, M., "A Transport Independent Bandwidth 2213 Modifier for the Session Description Protocol 2214 (SDP)", RFC 3890, September 2004. 2216 [ITU.H332.1998] International Telecommunication Union, "H.323 2217 extended for loosely coupled conferences", 2218 ITU Recommendation H.332, September 1998. 2220 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., 2221 and E. Carrara, "Key Management Extensions for 2222 Session Description Protocol (SDP) and Real Time 2223 Streaming Protocol (RTSP)", RFC 4567, July 2006. 2225 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 2226 Description Protocol (SDP) Security Descriptions for 2227 Media Streams", RFC 4568, July 2006. 2229 [RFC5322] Resnick, P., Ed., "Internet Message Format", 2230 RFC 5322, October 2008. 2232 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications 2233 and Registration Procedures", BCP 13, RFC 4288, 2234 December 2005. 2236 Authors' Addresses 2238 Mark Handley 2239 University College London 2240 Department of Computer Science 2241 Gower Street 2242 London WC1E 6BT 2243 UK 2245 EMail: M.Handley@cs.ucl.ac.uk 2247 Van Jacobson 2248 Packet Design 2249 2465 Latham Street 2250 Mountain View, CA 94040 2251 USA 2253 EMail: van@parc.com 2254 Colin Perkins 2255 University of Glasgow 2256 School of Computing Science 2257 University of Glasgow 2258 Glasgow G12 8QQ 2259 UK 2261 EMail: csp@csperkins.org 2263 Ali Begen 2264 Cisco 2265 181 Bay Street 2266 Toronto, ON M5J 2T3 2267 Canada 2269 EMail: abegen@cisco.com