idnits 2.17.1 draft-ietf-mmusic-rfc4566bis-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 25, 2012) is 4255 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 2327 (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- 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 PARC 6 Expires: February 26, 2013 C. Perkins 7 University of Glasgow 8 A. Begen 9 Cisco 10 August 25, 2012 12 SDP: Session Description Protocol 13 draft-ietf-mmusic-rfc4566bis-06 15 Abstract 17 This memo defines the Session Description Protocol (SDP). SDP is 18 intended for describing multimedia sessions for the purposes of 19 session announcement, session invitation, and other forms of 20 multimedia session initiation. This document obsoletes RFC 4566. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on February 26, 2013. 39 Copyright Notice 41 Copyright (c) 2012 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. Unless an SDP extension for NAT traversal is used 540 (e.g., ICE [RFC5245], ICE TCP [RFC6544]), a local IP address MUST 541 NOT be used in any context where the SDP description might leave 542 the scope in which the address is meaningful (for example, a local 543 address MUST NOT be included in an application-level referral that 544 might leave the scope). 546 In general, the "o=" field serves as a globally unique identifier for 547 this version of this session description, and the subfields excepting 548 the version taken together identify the session irrespective of any 549 modifications. 551 For privacy reasons, it is sometimes desirable to obfuscate the 552 username and IP address of the session originator. If this is a 553 concern, an arbitrary and private MAY be 554 chosen to populate the "o=" field, provided that these are selected 555 in a manner that does not affect the global uniqueness of the field. 557 5.3. Session Name ("s=") 559 s= 561 The "s=" field is the textual session name. There MUST be one and 562 only one "s=" field per session description. The "s=" field MUST NOT 563 be empty and SHOULD contain ISO 10646 characters (but see also the 564 "a=charset" attribute). If a session has no meaningful name, the 565 value "s= " SHOULD be used (i.e., a single space as the session 566 name). 568 5.4. Session Information ("i=") 570 i= 572 The "i=" field provides textual information about the session. There 573 MUST be at most one session-level "i=" field per session description, 574 and at most one "i=" field per media. If the "a=charset" attribute 575 is present, it specifies the character set used in the "i=" field. 576 If the "a=charset" attribute is not present, the "i=" field MUST 577 contain ISO 10646 characters in UTF-8 encoding. 579 A single "i=" field MAY also be used for each media definition. In 580 media definitions, "i=" fields are primarily intended for labelling 581 media streams. As such, they are most likely to be useful when a 582 single session has more than one distinct media stream of the same 583 media type. An example would be two different whiteboards, one for 584 slides and one for feedback and questions. 586 The "i=" field is intended to provide a free-form human-readable 587 description of the session or the purpose of a media stream. It is 588 not suitable for parsing by automata. 590 5.5. URI ("u=") 592 u= 594 A URI is a Uniform Resource Identifier as used by WWW clients 595 [RFC3986]. The URI should be a pointer to additional information 596 about the session. This field is OPTIONAL, but if it is present it 597 MUST be specified before the first media field. No more than one URI 598 field is allowed per session description. 600 5.6. Email Address and Phone Number ("e=" and "p=") 602 e= 603 p= 605 The "e=" and "p=" lines specify contact information for the person 606 responsible for the session. This is not necessarily the same person 607 that created the session description. 609 Inclusion of an email address or phone number is OPTIONAL. Note that 610 the previous version of SDP specified that either an email field or a 611 phone field MUST be specified, but this was widely ignored. The 612 change brings the specification into line with common usage. 614 If an email address or phone number is present, it MUST be specified 615 before the first media field. More than one email or phone field can 616 be given for a session description. 618 Phone numbers SHOULD be given in the form of an international public 619 telecommunication number (see ITU-T Recommendation E.164) preceded by 620 a "+". Spaces and hyphens may be used to split up a phone field to 621 aid readability if desired. For example: 623 p=+1 617 555-6011 625 Both email addresses and phone numbers can have an OPTIONAL free text 626 string associated with them, normally giving the name of the person 627 who may be contacted. This MUST be enclosed in parentheses if it is 628 present. For example: 630 e=j.doe@example.com (Jane Doe) 632 The alternative [RFC5322] name quoting convention is also allowed for 633 both email addresses and phone numbers. For example: 635 e=Jane Doe 637 The free text string SHOULD be in the ISO-10646 character set with 638 UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if 639 the appropriate session-level "a=charset" attribute is set. 641 5.7. Connection Data ("c=") 643 c= 645 The "c=" field contains connection data. 647 A session description MUST contain either at least one "c=" field in 648 each media description or a single "c=" field at the session level. 649 It MAY contain a single session-level "c=" field and additional "c=" 650 field(s) per media description, in which case the per-media values 651 override the session-level settings for the respective media. 653 The first sub-field ("") is the network type, which is a 654 text string giving the type of network. Initially, "IN" is defined 655 to have the meaning "Internet", but other values MAY be registered in 656 the future (see Section 8). 658 The second sub-field ("") is the address type. This allows 659 SDP to be used for sessions that are not IP based. This memo only 660 defines IP4 and IP6, but other values MAY be registered in the future 661 (see Section 8). 663 The third sub-field ("") is the connection 664 address. OPTIONAL sub-fields MAY be added after the connection 665 address depending on the value of the field. 667 When the is IP4 and IP6, the connection address is defined 668 as follows: 670 o If the session is multicast, the connection address will be an IP 671 multicast group address. If the session is not multicast, then 672 the connection address contains the unicast IP address of the 673 expected data source or data relay or data sink as determined by 674 additional attribute fields. It is not expected that unicast 675 addresses will be given in a session description that is 676 communicated by a multicast announcement, though this is not 677 prohibited. 679 o Sessions using an IPv4 multicast connection address MUST also have 680 a time to live (TTL) value present in addition to the multicast 681 address. The TTL and the address together define the scope with 682 which multicast packets sent in this session will be sent. TTL 683 values MUST be in the range 0-255. Although the TTL MUST be 684 specified, its use to scope multicast traffic is deprecated; 685 applications SHOULD use an administratively scoped address 686 instead. 688 The TTL for the session is appended to the address using a slash as a 689 separator. An example is: 691 c=IN IP4 233.252.0.1/127 693 IPv6 multicast does not use TTL scoping, and hence the TTL value MUST 694 NOT be present for IPv6 multicast. It is expected that IPv6 scoped 695 addresses will be used to limit the scope of conferences. 697 Hierarchical or layered encoding schemes are data streams where the 698 encoding from a single media source is split into a number of layers. 699 The receiver can choose the desired quality (and hence bandwidth) by 700 only subscribing to a subset of these layers. Such layered encodings 701 are normally transmitted in multiple multicast groups to allow 702 multicast pruning. This technique keeps unwanted traffic from sites 703 only requiring certain levels of the hierarchy. For applications 704 requiring multiple multicast groups, we allow the following notation 705 to be used for the connection address: 707 [/]/ 709 If the number of addresses is not given, it is assumed to be one. 710 Multicast addresses so assigned are contiguously allocated above the 711 base address, so that, for example: 713 c=IN IP4 233.252.0.1/127/3 715 would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3 716 are to be used at a TTL of 127. This is semantically identical to 717 including multiple "c=" lines in a media description: 719 c=IN IP4 233.252.0.1/127 720 c=IN IP4 233.252.0.2/127 721 c=IN IP4 233.252.0.3/127 723 Similarly, an IPv6 example would be: 725 c=IN IP6 FF15::101/3 727 which is semantically equivalent to: 729 c=IN IP6 FF15::101 730 c=IN IP6 FF15::102 731 c=IN IP6 FF15::103 733 (remembering that the TTL field is not present in IPv6 multicast). 735 Multiple addresses or "c=" lines MAY be specified on a per-media 736 basis only if they provide multicast addresses for different layers 737 in a hierarchical or layered encoding scheme. They MUST NOT be 738 specified for a session-level "c=" field. 740 The slash notation for multiple addresses described above MUST NOT be 741 used for IP unicast addresses. 743 5.8. Bandwidth ("b=") 745 b=: 747 This OPTIONAL field denotes the proposed bandwidth to be used by the 748 session or media. The is an alphanumeric modifier giving 749 the meaning of the figure. Two values are defined in 750 this specification, but other values MAY be registered in the future 751 (see Section 8 and [RFC3556], [RFC3890]): 753 CT If the bandwidth of a session or media in a session is different 754 from the bandwidth implicit from the scope, a "b=CT:..." line 755 SHOULD be supplied for the session giving the proposed upper limit 756 to the bandwidth used (the "conference total" bandwidth). The 757 primary purpose of this is to give an approximate idea as to 758 whether two or more sessions can coexist simultaneously. When 759 using the CT modifier with RTP, if several RTP sessions are part 760 of the conference, the conference total refers to total bandwidth 761 of all RTP sessions. 763 AS The bandwidth is interpreted to be application specific (it will 764 be the application's concept of maximum bandwidth). Normally, 765 this will coincide with what is set on the application's "maximum 766 bandwidth" control if applicable. For RTP-based applications, AS 767 gives the RTP "session bandwidth" as defined in Section 6.2 of 768 [RFC3550]. 770 Note that CT gives a total bandwidth figure for all the media at all 771 sites. AS gives a bandwidth figure for a single media at a single 772 site, although there may be many sites sending simultaneously. 774 A prefix "X-" is defined for names. This is intended for 775 experimental purposes only. For example: 777 b=X-YZ:128 779 Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers 780 SHOULD be registered with IANA in the standard namespace. SDP 781 parsers MUST ignore bandwidth fields with unknown modifiers. 782 Modifiers MUST be alphanumeric and, although no length limit is 783 given, it is recommended that they be short. 785 The is interpreted as kilobits per second by default. 786 The definition of a new modifier MAY specify that the 787 bandwidth is to be interpreted in some alternative unit (the "CT" and 788 "AS" modifiers defined in this memo use the default units). 790 5.9. Timing ("t=") 792 t= 794 The "t=" lines specify the start and stop times for a session. 795 Multiple "t=" lines MAY be used if a session is active at multiple 796 irregularly spaced times; each additional "t=" line specifies an 797 additional period of time for which the session will be active. If 798 the session is active at regular times, an "r=" line (see below) 799 should be used in addition to, and following, a "t=" line -- in which 800 case the "t=" line specifies the start and stop times of the repeat 801 sequence. 803 The first and second sub-fields give the start and stop times, 804 respectively, for the session. These values are the decimal 805 representation of Network Time Protocol (NTP) time values in seconds 806 since 1900 [RFC5905]. To convert these values to UNIX time, subtract 807 decimal 2208988800. 809 NTP timestamps are elsewhere represented by 64-bit values, which wrap 810 sometime in the year 2036. Since SDP uses an arbitrary length 811 decimal representation, this should not cause an issue (SDP 812 timestamps MUST continue counting seconds since 1900, NTP will use 813 the value modulo the 64-bit limit). 815 If the is set to zero, then the session is not bounded, 816 though it will not become active until after the . If 817 the is also zero, the session is regarded as permanent. 819 User interfaces SHOULD strongly discourage the creation of unbounded 820 and permanent sessions as they give no information about when the 821 session is actually going to terminate, and so make scheduling 822 difficult. 824 The general assumption may be made, when displaying unbounded 825 sessions that have not timed out to the user, that an unbounded 826 session will only be active until half an hour from the current time 827 or the session start time, whichever is the later. If behaviour 828 other than this is required, an end-time SHOULD be given and modified 829 as appropriate when new information becomes available about when the 830 session should really end. 832 Permanent sessions may be shown to the user as never being active 833 unless there are associated repeat times that state precisely when 834 the session will be active. 836 5.10. Repeat Times ("r=") 838 r= 840 "r=" fields specify repeat times for a session. For example, if a 841 session is active at 10am on Monday and 11am on Tuesday for one hour 842 each week for three months, then the in the 843 corresponding "t=" field would be the NTP representation of 10am on 844 the first Monday, the would be 1 week, the would be 1 hour, and the offsets would be zero and 25 846 hours. The corresponding "t=" field stop time would be the NTP 847 representation of the end of the last session three months later. By 848 default, all fields are in seconds, so the "r=" and "t=" fields might 849 be the following: 851 t=3034423619 3042462419 852 r=604800 3600 0 90000 854 To make the description more compact, times may also be given in 855 units of days, hours, or minutes. The syntax for these is a number 856 immediately followed by a single case-sensitive character. 857 Fractional units are not allowed -- a smaller unit should be used 858 instead. The following unit specification characters are allowed: 860 d - days (86400 seconds) 861 h - hours (3600 seconds) 862 m - minutes (60 seconds) 863 s - seconds (allowed for completeness) 865 Thus, the above session announcement could also have been written: 867 r=7d 1h 0 25h 869 Monthly and yearly repeats cannot be directly specified with a single 870 SDP repeat time; instead, separate "t=" fields should be used to 871 explicitly list the session times. 873 5.11. Time Zones ("z=") 875 z= .... 877 To schedule a repeated session that spans a change from daylight 878 saving time to standard time or vice versa, it is necessary to 879 specify offsets from the base time. This is required because 880 different time zones change time at different times of day, different 881 countries change to or from daylight saving time on different dates, 882 and some countries do not have daylight saving time at all. 884 Thus, in order to schedule a session that is at the same time winter 885 and summer, it must be possible to specify unambiguously by whose 886 time zone a session is scheduled. To simplify this task for 887 receivers, we allow the sender to specify the NTP time that a time 888 zone adjustment happens and the offset from the time when the session 889 was first scheduled. The "z=" field allows the sender to specify a 890 list of these adjustment times and offsets from the base time. 892 An example might be the following: 894 z=2882844526 -1h 2898848070 0 896 This specifies that at time 2882844526, the time base by which the 897 session's repeat times are calculated is shifted back by 1 hour, and 898 that at time 2898848070, the session's original time base is 899 restored. Adjustments are always relative to the specified start 900 time -- they are not cumulative. Adjustments apply to all "t=" and 901 "r=" lines in a session description. 903 If a session is likely to last several years, it is expected that the 904 session description will be modified periodically rather than 905 transmit several years' worth of adjustments in one session 906 description. 908 5.12. Encryption Keys ("k=") 910 k= 911 k=: 913 If transported over a secure and trusted channel, the Session 914 Description Protocol MAY be used to convey encryption keys. A simple 915 mechanism for key exchange is provided by the key field ("k="), 916 although this is primarily supported for compatibility with older 917 implementations and its use is NOT RECOMMENDED. Work is in progress 918 to define new key exchange mechanisms for use with SDP [RFC4567] 919 [RFC4568], and it is expected that new applications will use those 920 mechanisms. 922 A key field is permitted before the first media entry (in which case 923 it applies to all media in the session), or for each media entry as 924 required. The format of keys and their usage are outside the scope 925 of this document, and the key field provides no way to indicate the 926 encryption algorithm to be used, key type, or other information about 927 the key: this is assumed to be provided by the higher-level protocol 928 using SDP. If there is a need to convey this information within SDP, 929 the extensions mentioned previously SHOULD be used. Many security 930 protocols require two keys: one for confidentiality, another for 931 integrity. This specification does not support transfer of two keys. 933 The method indicates the mechanism to be used to obtain a usable key 934 by external means, or from the encoded encryption key given. The 935 following methods are defined: 937 k=clear: 939 The encryption key is included untransformed in this key field. 940 This method MUST NOT be used unless it can be guaranteed that 941 the SDP is conveyed over a secure channel. The encryption key 942 is interpreted as text according to the charset attribute; use 943 the "k=base64:" method to convey characters that are otherwise 944 prohibited in SDP. 946 k=base64: 948 The encryption key is included in this key field but has been 949 base64 encoded [RFC4648] because it includes characters that 950 are prohibited in SDP. This method MUST NOT be used unless it 951 can be guaranteed that the SDP is conveyed over a secure 952 channel. 954 k=uri: 956 A Uniform Resource Identifier is included in the key field. 957 The URI refers to the data containing the key, and may require 958 additional authentication before the key can be returned. When 959 a request is made to the given URI, the reply should specify 960 the encoding for the key. The URI is often an Secure Socket 961 Layer/Transport Layer Security (SSL/TLS)-protected HTTP URI 962 ("https:"), although this is not required. 964 k=prompt 966 No key is included in this SDP description, but the session or 967 media stream referred to by this key field is encrypted. The 968 user should be prompted for the key when attempting to join the 969 session, and this user-supplied key should then be used to 970 decrypt the media streams. The use of user-specified keys is 971 NOT RECOMMENDED, since such keys tend to have weak security 972 properties. 974 The key field MUST NOT be used unless it can be guaranteed that the 975 SDP is conveyed over a secure and trusted channel. An example of 976 such a channel might be SDP embedded inside an S/MIME message or a 977 TLS-protected HTTP session. It is important to ensure that the 978 secure channel is with the party that is authorised to join the 979 session, not an intermediary: if a caching proxy server is used, it 980 is important to ensure that the proxy is either trusted or unable to 981 access the SDP. 983 5.13. Attributes ("a=") 985 a= 986 a=: 988 Attributes are the primary means for extending SDP. Attributes may 989 be defined to be used as "session-level" attributes, "media-level" 990 attributes, or both. 992 A media description may have any number of attributes ("a=" fields) 993 that are media specific. These are referred to as "media-level" 994 attributes and add information about the media stream. Attribute 995 fields can also be added before the first media field; these 996 "session-level" attributes convey additional information that applies 997 to the session as a whole rather than to individual media. 999 Attribute fields may be of two forms: 1001 o A property attribute is simply of the form "a=". These are 1002 binary attributes, and the presence of the attribute conveys that 1003 the attribute is a property of the session. An example might be 1004 "a=recvonly". 1006 o A value attribute is of the form "a=:". For 1007 example, a whiteboard could have the value attribute "a=orient: 1008 landscape" 1010 Attribute interpretation depends on the media tool being invoked. 1011 Thus receivers of session descriptions should be configurable in 1012 their interpretation of session descriptions in general and of 1013 attributes in particular. 1015 Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. 1017 Attribute values are octet strings, and MAY use any octet value 1018 except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute 1019 values are to be interpreted as in ISO-10646 character set with UTF-8 1020 encoding. Unlike other text fields, attribute values are NOT 1021 normally affected by the "charset" attribute as this would make 1022 comparisons against known values problematic. However, when an 1023 attribute is defined, it can be defined to be charset dependent, in 1024 which case its value should be interpreted in the session charset 1025 rather than in ISO-10646. 1027 Attributes MUST be registered with IANA (see Section 8). If an 1028 attribute is received that is not understood, it MUST be ignored by 1029 the receiver. 1031 5.14. Media Descriptions ("m=") 1033 m= ... 1035 A session description may contain a number of media descriptions. 1036 Each media description starts with an "m=" field and is terminated by 1037 either the next "m=" field or by the end of the session description. 1038 A media field has several sub-fields: 1040 is the media type. Currently defined media are "audio", 1041 "video", "text", "application", and "message", although this list 1042 may be extended in the future (see Section 8). 1044 is the transport port to which the media stream is sent. The 1045 meaning of the transport port depends on the network being used as 1046 specified in the relevant "c=" field, and on the transport 1047 protocol defined in the sub-field of the media field. 1048 Other ports used by the media application (such as the RTP Control 1049 Protocol (RTCP) port [RFC3550]) MAY be derived algorithmically 1050 from the base media port or MAY be specified in a separate 1051 attribute (for example, "a=rtcp:" as defined in [RFC3605]). 1053 If non-contiguous ports are used or if they don't follow the 1054 parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" 1055 attribute MUST be used. Applications that are requested to send 1056 media to a that is odd and where the "a=rtcp:" is present 1057 MUST NOT subtract 1 from the RTP port: that is, they MUST send the 1058 RTP to the port indicated in and send the RTCP to the port 1059 indicated in the "a=rtcp" attribute. 1061 For applications where hierarchically encoded streams are being 1062 sent to a unicast address, it may be necessary to specify multiple 1063 transport ports. This is done using a similar notation to that 1064 used for IP multicast addresses in the "c=" field: 1066 m= / ... 1068 In such a case, the ports used depend on the transport protocol. 1069 For RTP, the default is that only the even-numbered ports are used 1070 for data with the corresponding one-higher odd ports used for the 1071 RTCP belonging to the RTP session, and the 1072 denoting the number of RTP sessions. For example: 1074 m=video 49170/2 RTP/AVP 31 1076 would specify that ports 49170 and 49171 form one RTP/RTCP pair 1077 and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the 1078 transport protocol and 31 is the format (see below). If non- 1079 contiguous ports are required, they must be signalled using a 1080 separate attribute (for example, "a=rtcp:" as defined in 1081 [RFC3605]). 1083 If multiple addresses are specified in the "c=" field and multiple 1084 ports are specified in the "m=" field, a one-to-one mapping from 1085 port to the corresponding address is implied. For example: 1087 c=IN IP4 233.252.0.1/127/2 1088 m=video 49170/2 RTP/AVP 31 1090 would imply that address 233.252.0.1 is used with ports 49170 and 1091 49171, and address 233.252.0.2 is used with ports 49172 and 49173. 1093 The semantics of multiple "m=" lines using the same transport 1094 address are undefined. This implies that, unlike limited past 1095 practice, there is no implicit grouping defined by such means and 1096 an explicit grouping framework (for example, [RFC5888]) should 1097 instead be used to express the intended semantics. 1099 is the transport protocol. The meaning of the transport 1100 protocol is dependent on the address type field in the relevant 1101 "c=" field. Thus a "c=" field of IP4 indicates that the transport 1102 protocol runs over IP4. The following transport protocols are 1103 defined, but may be extended through registration of new protocols 1104 with IANA (see Section 8): 1106 * udp: denotes an unspecified protocol running over UDP. 1108 * RTP/AVP: denotes RTP [RFC3550] used under the RTP Profile for 1109 Audio and Video Conferences with Minimal Control [RFC3551] 1110 running over UDP. 1112 * RTP/SAVP: denotes the Secure Real-time Transport Protocol 1113 [RFC3711] running over UDP. 1115 The main reason to specify the transport protocol in addition to 1116 the media format is that the same standard media formats may be 1117 carried over different transport protocols even when the network 1118 protocol is the same -- a historical example is vat Pulse Code 1119 Modulation (PCM) audio and RTP PCM audio; another might be TCP/RTP 1120 PCM audio. In addition, relays and monitoring tools that are 1121 transport-protocol-specific but format-independent are possible. 1123 is a media format description. The fourth and any subsequent 1124 sub-fields describe the format of the media. The interpretation 1125 of the media format depends on the value of the sub-field. 1127 If the sub-field is "RTP/AVP" or "RTP/SAVP" the sub- 1128 fields contain RTP payload type numbers. When a list of payload 1129 type numbers is given, this implies that all of these payload 1130 formats MAY be used in the session, but the first of these formats 1131 SHOULD be used as the default format for the session. For dynamic 1132 payload type assignments the "a=rtpmap:" attribute (see Section 6) 1133 SHOULD be used to map from an RTP payload type number to a media 1134 encoding name that identifies the payload format. The "a=fmtp:" 1135 attribute MAY be used to specify format parameters (see 1136 Section 6). 1138 If the sub-field is "udp" the sub-fields MUST 1139 reference a media type describing the format under the "audio", 1140 "video", "text", "application", or "message" top-level media 1141 types. The media type registration SHOULD define the packet 1142 format for use with UDP transport. 1144 For media using other transport protocols, the field is 1145 protocol specific. Rules for interpretation of the sub- 1146 field MUST be defined when registering new protocols (see Section 1147 8.2.2). 1149 6. SDP Attributes 1151 The following attributes are defined. Since application writers may 1152 add new attributes as they are required, this list is not exhaustive. 1153 Registration procedures for new attributes are defined in Section 1154 8.2.4. 1156 a=cat: 1158 This attribute gives the dot-separated hierarchical category of 1159 the session. This is to enable a receiver to filter unwanted 1160 sessions by category. There is no central registry of 1161 categories. It is a session-level attribute, and it is not 1162 dependent on charset. 1164 a=keywds: 1166 Like the cat attribute, this is to assist identifying wanted 1167 sessions at the receiver. This allows a receiver to select 1168 interesting session based on keywords describing the purpose of 1169 the session; there is no central registry of keywords. It is a 1170 session-level attribute. It is a charset-dependent attribute, 1171 meaning that its value should be interpreted in the charset 1172 specified for the session description if one is specified, or 1173 by default in ISO 10646/UTF-8. 1175 a=tool: 1177 This gives the name and version number of the tool used to 1178 create the session description. It is a session-level 1179 attribute, and it is not dependent on charset. 1181 a=ptime: 1183 This gives the length of time in milliseconds represented by 1184 the media in a packet. This is probably only meaningful for 1185 audio data, but may be used with other media types if it makes 1186 sense. It should not be necessary to know ptime to decode RTP 1187 or vat audio, and it is intended as a recommendation for the 1188 encoding/packetisation of audio. It is a media-level 1189 attribute, and it is not dependent on charset. 1191 a=maxptime: 1193 This gives the maximum amount of media that can be encapsulated 1194 in each packet, expressed as time in milliseconds. The time 1195 SHALL be calculated as the sum of the time the media present in 1196 the packet represents. For frame-based codecs, the time SHOULD 1197 be an integer multiple of the frame size. This attribute is 1198 probably only meaningful for audio data, but may be used with 1199 other media types if it makes sense. It is a media-level 1200 attribute, and it is not dependent on charset. Note that this 1201 attribute was introduced after [RFC2327], and non-updated 1202 implementations will ignore this attribute. 1204 a=rtpmap: / [/] 1207 This attribute maps from an RTP payload type number (as used in 1208 an "m=" line) to an encoding name denoting the payload format 1209 to be used. It also provides information on the clock rate and 1210 encoding parameters. It is a media-level attribute that is not 1211 dependent on charset. 1213 Although an RTP profile may make static assignments of payload 1214 type numbers to payload formats, it is more common for that 1215 assignment to be done dynamically using "a=rtpmap:" attributes. 1216 As an example of a static payload type, consider u-law PCM 1217 coded single-channel audio sampled at 8 kHz. This is 1218 completely defined in the RTP Audio/Video profile as payload 1219 type 0, so there is no need for an "a=rtpmap:" attribute, and 1220 the media for such a stream sent to UDP port 49232 can be 1221 specified as: 1223 m=audio 49232 RTP/AVP 0 1225 An example of a dynamic payload type is 16-bit linear encoded 1226 stereo audio sampled at 16 kHz. If we wish to use the dynamic 1227 RTP/AVP payload type 98 for this stream, additional information 1228 is required to decode it: 1230 m=audio 49232 RTP/AVP 98 1231 a=rtpmap:98 L16/16000/2 1233 Up to one rtpmap attribute can be defined for each media format 1234 specified. Thus, we might have the following: 1236 m=audio 49230 RTP/AVP 96 97 98 1237 a=rtpmap:96 L8/8000 1238 a=rtpmap:97 L16/8000 1239 a=rtpmap:98 L16/11025/2 1241 RTP profiles that specify the use of dynamic payload types MUST 1242 define the set of valid encoding names and/or a means to 1243 register encoding names if that profile is to be used with SDP. 1244 The "RTP/AVP" and "RTP/SAVP" profiles use media subtypes for 1245 encoding names, under the top-level media type denoted in the 1246 "m=" line. In the example above, the media types are 1247 "audio/l8" and "audio/l16". 1249 For audio streams, indicates the number 1250 of audio channels. This parameter is OPTIONAL and may be 1251 omitted if the number of channels is one, provided that no 1252 additional parameters are needed. 1254 For video streams, no encoding parameters are currently 1255 specified. 1257 Additional encoding parameters MAY be defined in the future, 1258 but codec-specific parameters SHOULD NOT be added. Parameters 1259 added to an "a=rtpmap:" attribute SHOULD only be those required 1260 for a session directory to make the choice of appropriate media 1261 to participate in a session. Codec-specific parameters should 1262 be added in other attributes (for example, "a=fmtp:"). 1264 Note: RTP audio formats typically do not include information 1265 about the number of samples per packet. If a non-default (as 1266 defined in the RTP Audio/Video Profile) packetisation is 1267 required, the "ptime" attribute is used as given above. 1269 a=recvonly 1271 This specifies that the tools should be started in receive-only 1272 mode where applicable. It can be either a session- or media- 1273 level attribute, and it is not dependent on charset. Note that 1274 recvonly applies to the media only, not to any associated 1275 control protocol (e.g., an RTP-based system in recvonly mode 1276 SHOULD still send RTCP packets). 1278 a=sendrecv 1280 This specifies that the tools should be started in send and 1281 receive mode. This is necessary for interactive conferences 1282 with tools that default to receive-only mode. It can be either 1283 a session or media-level attribute, and it is not dependent on 1284 charset. 1286 If none of the attributes "sendonly", "recvonly", "inactive", 1287 and "sendrecv" is present, "sendrecv" SHOULD be assumed as the 1288 default for sessions that are not of the conference type 1289 "broadcast" or "H332" (see below). 1291 a=sendonly 1293 This specifies that the tools should be started in send-only 1294 mode. An example may be where a different unicast address is 1295 to be used for a traffic destination than for a traffic source. 1296 In such a case, two media descriptions may be used, one 1297 sendonly and one recvonly. It can be either a session- or 1298 media-level attribute, but would normally only be used as a 1299 media attribute. It is not dependent on charset. Note that 1300 sendonly applies only to the media, and any associated control 1301 protocol (e.g., RTCP) SHOULD still be received and processed as 1302 normal. 1304 a=inactive 1306 This specifies that the tools should be started in inactive 1307 mode. This is necessary for interactive conferences where 1308 users can put other users on hold. No media is sent over an 1309 inactive media stream. Note that an RTP-based system SHOULD 1310 still send RTCP, even if started inactive. It can be either a 1311 session or media-level attribute, and it is not dependent on 1312 charset. 1314 a=orient: 1316 Normally this is only used for a whiteboard or presentation 1317 tool. It specifies the orientation of a the workspace on the 1318 screen. It is a media-level attribute. Permitted values are 1319 "portrait", "landscape", and "seascape" (upside-down 1320 landscape). It is not dependent on charset. 1322 a=type: 1324 This specifies the type of the conference. Suggested values 1325 are "broadcast", "meeting", "moderated", "test", and "H332". 1326 "recvonly" should be the default for "type:broadcast" sessions, 1327 "type:meeting" should imply "sendrecv", and "type:moderated" 1328 should indicate the use of a floor control tool and that the 1329 media tools are started so as to mute new sites joining the 1330 conference. 1332 Specifying the attribute "type:H332" indicates that this 1333 loosely coupled session is part of an H.332 session as defined 1334 in the ITU H.332 specification [ITU.H332.1998]. Media tools 1335 should be started "recvonly". 1337 Specifying the attribute "type:test" is suggested as a hint 1338 that, unless explicitly requested otherwise, receivers can 1339 safely avoid displaying this session description to users. 1341 The type attribute is a session-level attribute, and it is not 1342 dependent on charset. 1344 a=charset: 1346 This specifies the character set to be used to display the 1347 session name and information data. By default, the ISO-10646 1348 character set in UTF-8 encoding is used. If a more compact 1349 representation is required, other character sets may be used. 1350 For example, the ISO 8859-1 is specified with the following SDP 1351 attribute: 1353 a=charset:ISO-8859-1 1355 This is a session-level attribute and is not dependent on 1356 charset. The charset specified MUST be one of those registered 1357 with IANA, such as ISO-8859-1. The character set identifier is 1358 a US-ASCII string and MUST be compared against the IANA 1359 identifiers using a case-insensitive comparison. If the 1360 identifier is not recognised or not supported, all strings that 1361 are affected by it SHOULD be regarded as octet strings. 1363 Note that a character set specified MUST still prohibit the use 1364 of bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets 1365 requiring the use of these characters MUST define a quoting 1366 mechanism that prevents these bytes from appearing within text 1367 fields. 1369 a=sdplang: 1371 This can be a session-level attribute or a media-level 1372 attribute. As a session-level attribute, it specifies the 1373 language for the session description. As a media-level 1374 attribute, it specifies the language for any media-level SDP 1375 information field associated with that media. Multiple sdplang 1376 attributes can be provided either at session or media level if 1377 the session description or media use multiple languages. 1379 In general, sending session descriptions consisting of multiple 1380 languages is discouraged. Instead, multiple descriptions 1381 SHOULD be sent describing the session, one in each language. 1382 However, this is not possible with all transport mechanisms, 1383 and so multiple sdplang attributes are allowed although NOT 1384 RECOMMENDED. 1386 The "sdplang" attribute value must be a single [RFC5646] 1387 language tag in US-ASCII. It is not dependent on the charset 1388 attribute. An "sdplang" attribute SHOULD be specified when a 1389 session is distributed with sufficient scope to cross 1390 geographic boundaries, where the language of recipients cannot 1391 be assumed, or where the session is in a different language 1392 from the locally assumed norm. 1394 a=lang: 1396 This can be a session-level attribute or a media-level 1397 attribute. As a session-level attribute, it specifies the 1398 default language for the session being described. As a media- 1399 level attribute, it specifies the language for that media, 1400 overriding any session-level language specified. Multiple lang 1401 attributes can be provided either at session or media level if 1402 the session or media use multiple languages, in which case the 1403 order of the attributes indicates the order of importance of 1404 the various languages in the session or media, from most 1405 important to least important. 1407 The "lang" attribute value must be a single [RFC5646] language 1408 tag in US-ASCII. It is not dependent on the charset attribute. 1409 A "lang" attribute SHOULD be specified when a session is of 1410 sufficient scope to cross geographic boundaries where the 1411 language of recipients cannot be assumed, or where the session 1412 is in a different language from the locally assumed norm. 1414 a=framerate: 1416 This gives the maximum video frame rate in frames/sec. It is 1417 intended as a recommendation for the encoding of video data. 1418 Decimal representations of fractional values using the notation 1419 "." are allowed. It is a media-level 1420 attribute, defined only for video media, and it is not 1421 dependent on charset. 1423 a=quality: 1425 This gives a suggestion for the quality of the encoding as an 1426 integer value. The intention of the quality attribute for 1427 video is to specify a non-default trade-off between frame-rate 1428 and still-image quality. For video, the value is in the range 1429 0 to 10, with the following suggested meaning: 1431 10 - the best still-image quality the compression scheme 1432 can give. 1433 5 - the default behaviour given no quality suggestion. 1434 0 - the worst still-image quality the codec designer 1435 thinks is still usable. 1437 It is a media-level attribute, and it is not dependent on 1438 charset. 1440 a=fmtp: 1442 This attribute allows parameters that are specific to a 1443 particular format to be conveyed in a way that SDP does not 1444 have to understand them. The format must be one of the formats 1445 specified for the media. Format-specific parameters may be any 1446 set of parameters required to be conveyed by SDP and given 1447 unchanged to the media tool that will use this format. At most 1448 one instance of this attribute is allowed for each format. 1450 It is a media-level attribute, and it is not dependent on 1451 charset. 1453 7. Security Considerations 1455 SDP is frequently used with the Session Initiation Protocol [RFC3261] 1456 using the offer/answer model [RFC3264] to agree on parameters for 1457 unicast sessions. When used in this manner, the security 1458 considerations of those protocols apply. 1460 SDP is a session description format that describes multimedia 1461 sessions. Entities receiving and acting upon an SDP message SHOULD 1462 be aware that a session description cannot be trusted unless it has 1463 been obtained by an authenticated transport protocol from a known and 1464 trusted source. Many different transport protocols may be used to 1465 distribute session descriptions, and the nature of the authentication 1466 will differ from transport to transport. For some transports, 1467 security features are often not deployed. In case a session 1468 description has not been obtained in a trusted manner, the endpoint 1469 SHOULD exercise care because, among other attacks, the media sessions 1470 received may not be the intended ones, the destination where media is 1471 sent to may not be the expected one, any of the parameters of the 1472 session may be incorrect, or the media security may be compromised. 1473 It is up to the endpoint to make a sensible decision taking into 1474 account the security risks of the application and the user 1475 preferences and may decide to ask the user whether or not to accept 1476 the session. 1478 One transport that can be used to distribute session descriptions is 1479 the Session Announcement Protocol (SAP). SAP provides both 1480 encryption and authentication mechanisms, but due to the nature of 1481 session announcements it is likely that there are many occasions 1482 where the originator of a session announcement cannot be 1483 authenticated because the originator is previously unknown to the 1484 receiver of the announcement and because no common public key 1485 infrastructure is available. 1487 On receiving a session description over an unauthenticated transport 1488 mechanism or from an untrusted party, software parsing the session 1489 should take a few precautions. Session descriptions contain 1490 information required to start software on the receiver's system. 1491 Software that parses a session description MUST NOT be able to start 1492 other software except that which is specifically configured as 1493 appropriate software to participate in multimedia sessions. It is 1494 normally considered inappropriate for software parsing a session 1495 description to start, on a user's system, software that is 1496 appropriate to participate in multimedia sessions, without the user 1497 first being informed that such software will be started and giving 1498 the user's consent. Thus, a session description arriving by session 1499 announcement, email, session invitation, or WWW page MUST NOT deliver 1500 the user into an interactive multimedia session unless the user has 1501 explicitly pre-authorised such action. As it is not always simple to 1502 tell whether or not a session is interactive, applications that are 1503 unsure should assume sessions are interactive. 1505 In this specification, there are no attributes that would allow the 1506 recipient of a session description to be informed to start multimedia 1507 tools in a mode where they default to transmitting. Under some 1508 circumstances it might be appropriate to define such attributes. If 1509 this is done, an application parsing a session description containing 1510 such attributes SHOULD either ignore them or inform the user that 1511 joining this session will result in the automatic transmission of 1512 multimedia data. The default behaviour for an unknown attribute is 1513 to ignore it. 1515 In certain environments, it has become common for intermediary 1516 systems to intercept and analyse session descriptions contained 1517 within other signalling protocols. This is done for a range of 1518 purposes, including but not limited to opening holes in firewalls to 1519 allow media streams to pass, or to mark, prioritize, or block traffic 1520 selectively. In some cases, such intermediary systems may modify the 1521 session description, for example, to have the contents of the session 1522 description match NAT bindings dynamically created. These behaviours 1523 are NOT RECOMMENDED unless the session description is conveyed in 1524 such a manner that allows the intermediary system to conduct proper 1525 checks to establish the authenticity of the session description, and 1526 the authority of its source to establish such communication sessions. 1527 SDP by itself does not include sufficient information to enable these 1528 checks: they depend on the encapsulating protocol (e.g., SIP or 1529 RTSP). 1531 Use of the "k=" field poses a significant security risk, since it 1532 conveys session encryption keys in the clear. SDP MUST NOT be used 1533 to convey key material, unless it can be guaranteed that the channel 1534 over which the SDP is delivered is both private and authenticated. 1535 Moreover, the "k=" line provides no way to indicate or negotiate 1536 cryptographic key algorithms. As it provides for only a single 1537 symmetric key, rather than separate keys for confidentiality and 1538 integrity, its utility is severely limited. The use of the "k=" line 1539 is NOT RECOMMENDED, as discussed in Section 5.12. 1541 8. IANA Considerations 1543 8.1. The "application/sdp" Media Type 1545 One media type registration from [RFC4566] is to be updated, as 1546 defined below. 1548 To: ietf-types@iana.org 1549 Subject: Registration of media type "application/sdp" 1551 Type name: application 1553 Subtype name: sdp 1555 Required parameters: None. 1557 Optional parameters: None. 1559 Encoding considerations: 1560 SDP files are primarily UTF-8 format text. The "a=charset:" 1561 attribute may be used to signal the presence of other character 1562 sets in certain parts of an SDP file (see Section 6 of RFC 1563 XXXX). Arbitrary binary content cannot be directly 1564 represented in SDP. 1566 Security considerations: 1567 See Section 7 of RFC XXXX. 1569 Interoperability considerations: 1570 See RFC XXXX. 1572 Published specification: 1573 See RFC XXXX. 1575 Applications which use this media type: 1576 Voice over IP, video teleconferencing, streaming media, instant 1577 messaging, among others. See also Section 3 of RFC XXXX. 1579 Additional information: 1581 Magic number(s): None. 1582 File extension(s): The extension ".sdp" is commonly used. 1583 Macintosh File Type Code(s): "sdp " 1585 Person & email address to contact for further information: 1586 Mark Handley 1587 Colin Perkins 1588 IETF MMUSIC working group 1590 Intended usage: COMMON 1592 Author/Change controller: 1593 Authors of RFC XXXX 1594 IETF MMUSIC working group delegated from the IESG 1596 8.2. Registration of Parameters 1598 There are seven field names that may be registered with IANA. Using 1599 the terminology in the SDP specification Backus-Naur Form (BNF), they 1600 are "media", "proto", "fmt", "att-field", "bwtype", "nettype", and 1601 "addrtype". 1603 8.2.1. Media Types ("media") 1605 The set of media types is intended to be small and SHOULD NOT be 1606 extended except under rare circumstances. The same rules should 1607 apply for media names as for top-level media types, and where 1608 possible the same name should be registered for SDP as for MIME. For 1609 media other than existing top-level media types, a Standards Track 1610 RFC MUST be produced for a new top-level media type to be registered, 1611 and the registration MUST provide good justification why no existing 1612 media name is appropriate (the "Standards Action" policy of 1613 [RFC5226]. 1615 This memo registers the media types "audio", "video", "text", 1616 "application", and "message". 1618 Note: The media types "control" and "data" were listed as valid in an 1619 early version of this specification (RFC 2327); however, their 1620 semantics were never fully specified and they are not widely used. 1621 These media types have been removed in this specification, although 1622 they still remain valid media type capabilities for a SIP user agent 1623 as defined in [RFC3840]. If these media types are considered useful 1624 in the future, a Standards Track RFC MUST be produced to document 1625 their use. Until that is done, applications SHOULD NOT use these 1626 types and SHOULD NOT declare support for them in SIP capabilities 1627 declarations (even though they exist in the registry created by 1628 [RFC3840]). 1630 8.2.2. Transport Protocols ("proto") 1632 The "proto" field describes the transport protocol used. This SHOULD 1633 reference a standards-track protocol RFC. This memo registers three 1634 values: "RTP/AVP" is a reference to [RFC3550] used under the RTP 1635 Profile for Audio and Video Conferences with Minimal Control 1636 [RFC3551] running over UDP/IP, "RTP/SAVP" is a reference to the 1637 Secure Real-time Transport Protocol [RFC3711], and "udp" indicates an 1638 unspecified protocol over UDP. 1640 If other RTP profiles are defined in the future, their "proto" name 1641 SHOULD be specified in the same manner. For example, an RTP profile 1642 whose short name is "XYZ" would be denoted by a "proto" field of 1643 "RTP/XYZ". 1645 New transport protocols SHOULD be registered with IANA. 1646 Registrations MUST reference an RFC describing the protocol. Such an 1647 RFC MAY be Experimental or Informational, although it is preferable 1648 that it be Standards Track. Registrations MUST also define the rules 1649 by which their "fmt" namespace is managed (see below). 1651 8.2.3. Media Formats ("fmt") 1653 Each transport protocol, defined by the "proto" field, has an 1654 associated "fmt" namespace that describes the media formats that may 1655 be conveyed by that protocol. Formats cover all the possible 1656 encodings that might want to be transported in a multimedia session. 1658 RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST 1659 use the payload type number as their "fmt" value. If the payload 1660 type number is dynamically assigned by this session description, an 1661 additional "rtpmap" attribute MUST be included to specify the format 1662 name and parameters as defined by the media type registration for the 1663 payload format. It is RECOMMENDED that other RTP profiles that are 1664 registered (in combination with RTP) as SDP transport protocols 1665 specify the same rules for the "fmt" namespace. 1667 For the "udp" protocol, new formats SHOULD be registered. Use of an 1668 existing media subtype for the format is encouraged. If no media 1669 subtype exists, it is RECOMMENDED that a suitable one be registered 1670 through the IETF process [RFC4288] by production of, or reference to, 1671 a standards-track RFC that defines the transport protocol for the 1672 format. 1674 For other protocols, formats MAY be registered according to the rules 1675 of the associated "proto" specification. 1677 Registrations of new formats MUST specify which transport protocols 1678 they apply to. 1680 8.2.4. Attribute Names ("att-field") 1682 Attribute field names ("att-field") MUST be registered with IANA and 1683 documented, because of noticeable issues due to conflicting 1684 attributes under the same name. Unknown attributes in SDP are simply 1685 ignored, but conflicting ones that fragment the protocol are a 1686 serious problem. 1688 New attribute registrations are accepted according to the 1689 "Specification Required" policy of [RFC5226], provided that the 1690 specification includes the following information: 1692 o contact name, email address, and telephone number 1694 o attribute name (as it will appear in SDP) 1696 o long-form attribute name in English 1698 o type of attribute (session level, media level, or both) 1700 o whether the attribute value is subject to the charset attribute 1702 o a one-paragraph explanation of the purpose of the attribute 1704 o a specification of appropriate attribute values for this attribute 1706 The above is the minimum that IANA will accept. Attributes that are 1707 expected to see widespread use and interoperability SHOULD be 1708 documented with a standards-track RFC that specifies the attribute 1709 more precisely. 1711 Submitters of registrations should ensure that the specification is 1712 in the spirit of SDP attributes, most notably that the attribute is 1713 platform independent in the sense that it makes no implicit 1714 assumptions about operating systems and does not name specific pieces 1715 of software in a manner that might inhibit interoperability. 1717 IANA has registered the following initial set of attribute names 1718 ("att-field" values), with definitions as in Section 6 of this memo 1719 (these definitions update those in [RFC4566]): 1721 Name | Session or Media level? | Dependent on charset? 1722 ----------+-------------------------+---------------------- 1723 cat | Session | No 1724 keywds | Session | Yes 1725 tool | Session | No 1726 ptime | Media | No 1727 maxptime | Media | No 1728 rtpmap | Media | No 1729 recvonly | Either | No 1730 sendrecv | Either | No 1731 sendonly | Either | No 1732 inactive | Either | No 1733 orient | Media | No 1734 type | Session | No 1735 charset | Session | No 1736 sdplang | Either | No 1737 lang | Either | No 1738 framerate | Media | No 1739 quality | Media | No 1740 fmtp | Media | No 1742 8.2.5. Bandwidth Specifiers ("bwtype") 1744 A proliferation of bandwidth specifiers is strongly discouraged. 1746 New bandwidth specifiers ("bwtype" fields) MUST be registered with 1747 IANA. The submission MUST reference a standards-track RFC specifying 1748 the semantics of the bandwidth specifier precisely, and indicating 1749 when it should be used, and why the existing registered bandwidth 1750 specifiers do not suffice. 1752 IANA has registered the bandwidth specifiers "CT" and "AS" with 1753 definitions as in Section 5.8 of this memo (these definitions update 1754 those in [RFC4566]). 1756 8.2.6. Network Types ("nettype") 1758 New network types (the "nettype" field) may be registered with IANA 1759 if SDP needs to be used in the context of non-Internet environments. 1760 Although these are not normally the preserve of IANA, there may be 1761 circumstances when an Internet application needs to interoperate with 1762 a non-Internet application, such as when gatewaying an Internet 1763 telephone call into the Public Switched Telephone Network (PSTN). 1764 The number of network types should be small and should be rarely 1765 extended. A new network type cannot be registered without 1766 registering at least one address type to be used with that network 1767 type. A new network type registration MUST reference an RFC that 1768 gives details of the network type and address type and specifies how 1769 and when they would be used. 1771 IANA has registered the network type "IN" to represent the Internet, 1772 with definition as in Sections 5.2 and 5.7 of this memo (these 1773 definitions update those in [RFC4566]). 1775 8.2.7. Address Types ("addrtype") 1777 New address types ("addrtype") may be registered with IANA. An 1778 address type is only meaningful in the context of a network type, and 1779 any registration of an address type MUST specify a registered network 1780 type or be submitted along with a network type registration. A new 1781 address type registration MUST reference an RFC giving details of the 1782 syntax of the address type. Address types are not expected to be 1783 registered frequently. 1785 IANA has registered the address types "IP4" and "IP6" with 1786 definitions as in Sections 5.2 and 5.7 of this memo (these 1787 definitions update those in [RFC4566]). 1789 8.2.8. Registration Procedure 1791 In the RFC documentation that registers SDP "media", "proto", "fmt", 1792 "bwtype", "nettype", and "addrtype" fields, the authors MUST include 1793 the following information for IANA to place in the appropriate 1794 registry: 1796 o contact name, email address, and telephone number 1798 o name being registered (as it will appear in SDP) 1800 o long-form name in English 1802 o type of name ("media", "proto", "fmt", "bwtype", "nettype", or 1803 "addrtype") 1805 o a one-paragraph explanation of the purpose of the registered name 1807 o a reference to the specification for the registered name (this 1808 will typically be an RFC number) 1810 IANA may refer any registration to the IESG for review, and may 1811 request revisions to be made before a registration will be made. 1813 8.3. Encryption Key Access Methods 1815 The IANA previously maintained a table of SDP encryption key access 1816 method ("enckey") names. This table is obsolete, since the "k=" line 1817 is not extensible. New registrations MUST NOT be accepted. 1819 9. SDP Grammar 1821 This section provides an Augmented BNF grammar for SDP. ABNF is 1822 defined in [RFC5234]. 1824 ; SDP Syntax 1825 session-description = proto-version 1826 origin-field 1827 session-name-field 1828 information-field 1829 uri-field 1830 email-fields 1831 phone-fields 1832 connection-field 1833 bandwidth-fields 1834 time-fields 1835 key-field 1836 attribute-fields 1837 media-descriptions 1839 proto-version = %x76 "=" 1*DIGIT CRLF 1840 ;this memo describes version 0 1842 origin-field = %x6f "=" username SP sess-id SP sess-version SP 1843 nettype SP addrtype SP unicast-address CRLF 1845 session-name-field = %x73 "=" text CRLF 1847 information-field = [%x69 "=" text CRLF] 1849 uri-field = [%x75 "=" uri CRLF] 1851 email-fields = *(%x65 "=" email-address CRLF) 1853 phone-fields = *(%x70 "=" phone-number CRLF) 1855 connection-field = [%x63 "=" nettype SP addrtype SP 1856 connection-address CRLF] 1857 ;a connection field must be present 1858 ;in every media description or at the 1859 ;session-level 1861 bandwidth-fields = *(%x62 "=" bwtype ":" bandwidth CRLF) 1863 time-fields = 1*( %x74 "=" start-time SP stop-time 1864 *(CRLF repeat-fields) CRLF) 1865 [zone-adjustments CRLF] 1867 repeat-fields = %x72 "=" repeat-interval SP typed-time 1868 1*(SP typed-time) 1870 zone-adjustments = %x7a "=" time SP ["-"] typed-time 1871 *(SP time SP ["-"] typed-time) 1873 key-field = [%x6b "=" key-type CRLF] 1875 attribute-fields = *(%x61 "=" attribute CRLF) 1877 media-descriptions = *( media-field 1878 information-field 1879 *connection-field 1880 bandwidth-fields 1881 key-field 1882 attribute-fields ) 1884 media-field = %x6d "=" media SP port ["/" integer] 1885 SP proto 1*(SP fmt) CRLF 1887 ; sub-rules of 'o=' 1888 username = non-ws-string 1889 ;pretty wide definition, but doesn't 1890 ;include space 1892 sess-id = 1*DIGIT 1893 ;should be unique for this username/host 1895 sess-version = 1*DIGIT 1897 nettype = token 1898 ;typically "IN" 1900 addrtype = token 1901 ;typically "IP4" or "IP6" 1903 ; sub-rules of 'u=' 1904 uri = URI-reference 1905 ; see RFC 3986 1907 ; sub-rules of 'e=', see RFC 5322 for definitions 1908 email-address = address-and-comment / dispname-and-address 1909 / addr-spec 1910 address-and-comment = addr-spec 1*SP "(" 1*email-safe ")" 1911 dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">" 1913 ; sub-rules of 'p=' 1914 phone-number = phone *SP "(" 1*email-safe ")" / 1915 1*email-safe "<" phone ">" / 1916 phone 1918 phone = ["+"] DIGIT 1*(SP / "-" / DIGIT) 1920 ; sub-rules of 'c=' 1921 connection-address = multicast-address / unicast-address 1923 ; sub-rules of 'b=' 1924 bwtype = token 1926 bandwidth = 1*DIGIT 1928 ; sub-rules of 't=' 1929 start-time = time / "0" 1931 stop-time = time / "0" 1932 time = POS-DIGIT 9*DIGIT 1933 ; Decimal representation of NTP time in 1934 ; seconds since 1900. The representation 1935 ; of NTP time is an unbounded length field 1936 ; containing at least 10 digits. Unlike the 1937 ; 64-bit representation used elsewhere, time 1938 ; in SDP does not wrap in the year 2036. 1940 ; sub-rules of 'r=' and 'z=' 1941 repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] 1943 typed-time = 1*DIGIT [fixed-len-time-unit] 1945 fixed-len-time-unit = %x64 / %x68 / %x6d / %x73 1947 ; sub-rules of 'k=' 1948 key-type = %x70 %x72 %x6f %x6d %x70 %x74 / ; "prompt" 1949 %x63 %x6c %x65 %x61 %x72 ":" text / ; "clear:" 1950 %x62 %x61 %x73 %x65 "64:" base64 / ; "base64:" 1951 %x75 %x72 %x69 ":" uri ; "uri:" 1953 base64 = *base64-unit [base64-pad] 1954 base64-unit = 4base64-char 1955 base64-pad = 2base64-char "==" / 3base64-char "=" 1956 base64-char = ALPHA / DIGIT / "+" / "/" 1958 ; sub-rules of 'a=' 1959 attribute = (att-field ":" att-value) / att-field 1961 att-field = token 1963 att-value = byte-string 1965 ; sub-rules of 'm=' 1966 media = token 1967 ;typically "audio", "video", "text", or 1968 ;"application" 1970 fmt = token 1971 ;typically an RTP payload type for audio 1972 ;and video media 1974 proto = token *("/" token) 1975 ;typically "RTP/AVP" or "udp" 1977 port = 1*DIGIT 1979 ; generic sub-rules: addressing 1980 unicast-address = IP4-address / IP6-address / FQDN / extn-addr 1982 multicast-address = IP4-multicast / IP6-multicast / FQDN 1983 / extn-addr 1985 IP4-multicast = m1 3( "." decimal-uchar ) 1986 "/" ttl [ "/" integer ] 1987 ; IPv4 multicast addresses may be in the 1988 ; range 224.0.0.0 to 239.255.255.255 1990 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / 1991 ("23" DIGIT ) 1993 IP6-multicast = IP6-address [ "/" integer ] 1994 ; IPv6 address starting with FF 1996 ttl = (POS-DIGIT *2DIGIT) / "0" 1998 FQDN = 4*(alpha-numeric / "-" / ".") 1999 ; fully qualified domain name as specified 2000 ; in RFC 1035 (and updates) 2002 IP4-address = b1 3("." decimal-uchar) 2004 b1 = decimal-uchar 2005 ; less than "224" 2007 IP6-address = 6( h16 ":" ) ls32 2008 / "::" 5( h16 ":" ) ls32 2009 / [ h16 ] "::" 4( h16 ":" ) ls32 2010 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 2011 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 2012 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 2013 / [ *4( h16 ":" ) h16 ] "::" ls32 2014 / [ *5( h16 ":" ) h16 ] "::" h16 2015 / [ *6( h16 ":" ) h16 ] "::" 2017 h16 = 1*4HEXDIG 2019 ls32 = ( h16 ":" h16 ) / IP4-address 2021 ; Generic for other address families 2022 extn-addr = non-ws-string 2024 ; generic sub-rules: datatypes 2025 text = byte-string 2026 ;default is to interpret this as UTF8 text. 2027 ;ISO 8859-1 requires "a=charset:ISO-8859-1" 2028 ;session-level attribute to be used 2030 byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) 2031 ;any byte except NUL, CR, or LF 2033 non-ws-string = 1*(VCHAR/%x80-FF) 2034 ;string of visible characters 2036 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 2037 / %x41-5A / %x5E-7E 2039 token = 1*(token-char) 2041 email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF 2042 ;any byte except NUL, CR, LF, or the quoting 2043 ;characters ()<> 2045 integer = POS-DIGIT *DIGIT 2047 ; generic sub-rules: primitives 2048 alpha-numeric = ALPHA / DIGIT 2050 POS-DIGIT = %x31-39 ; 1 - 9 2052 decimal-uchar = DIGIT 2053 / POS-DIGIT DIGIT 2054 / ("1" 2*(DIGIT)) 2055 / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) 2056 / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) 2058 ; external references: 2059 ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 5234 2060 ; URI-reference: from RFC 3986 2061 ; addr-spec: from RFC 5322 2063 10. Summary of Changes from RFC 4566 2065 The ABNF rule for IP6-address has been corrected. As a result, the 2066 ABNF rule for IP6-multicast has changed, and the (now unused) rules 2067 for hexpart, hexseq, and hex4 have been removed. 2069 IPv4 unicast and multicast addresses in the example SDP descriptions 2070 have been revised per RFCs 5735 and 5771. 2072 Text in Section 5.2 has been revised to clarify the use of local 2073 addresses in case of ICE-like SDP extensions. 2075 Normative and informative references have been updated. 2077 The following purely editorial changes have been made: 2079 o Section 4.6: fix typo in first sentence: "sets" -> "set" 2081 o Section 5: clarify second paragraph (SDP field and attribute names 2082 use the US-ASCII subset of UTF-8). 2084 o Section 5: clarify that an SDP session description can contain 2085 only a session-level section, with no media-level section, and 2086 that a media-level section can be terminated by the end of the 2087 session description, and not always by another media-level 2088 section. 2090 o Section 5: clearly differentiate "media" and "media description" 2091 in the description of the "c=" line. 2093 o Section 5.2: when describing the field, clarify 2094 that "an" address of the machine is used, rather than "the" 2095 address of the machine, since IP addresses identify interfaces, 2096 not hosts. 2098 o Section 5.6: use "session" rather than "conference" 2100 o Section 5.10: fix typo: "To make description" -> "To make the 2101 description" 2103 o Section 5.11: use "session description" rather than "session 2104 announcement" in the final paragraph 2106 o Section 7: fix typo: "distribute session description" -> 2107 "distribute session descriptions" 2109 Clarify the use of multiple "a=sdplang:" and "a=lang:" attributes, 2110 and when "a=sdplang:" should be used. 2112 11. Acknowledgements 2114 Many people in the IETF Multiparty Multimedia Session Control 2115 (MMUSIC) working group have made comments and suggestions 2116 contributing to this document. In particular, we would like to thank 2117 Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross 2118 Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna, 2119 Jonathan Lennox, Keith Drage, Sean Olson, Bernie Hoeneisen, Jonathan 2120 Rosenberg, John Elwell, Flemming Andreasen, Jon Peterson, Spencer 2121 Dawkins, and Alfred Hoenes. 2123 12. References 2124 12.1. Normative References 2126 [RFC1034] Mockapetris, P., "Domain names - concepts and 2127 facilities", STD 13, RFC 1034, November 1987. 2129 [RFC1035] Mockapetris, P., "Domain names - implementation and 2130 specification", STD 13, RFC 1035, November 1987. 2132 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2133 Requirement Levels", BCP 14, RFC 2119, March 1997. 2135 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for 2136 Syntax Specifications: ABNF", STD 68, RFC 5234, 2137 January 2008. 2139 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2140 10646", STD 63, RFC 3629, November 2003. 2142 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, 2143 "Uniform Resource Identifier (URI): Generic Syntax", 2144 STD 66, RFC 3986, January 2005. 2146 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for 2147 Writing an IANA Considerations Section in RFCs", 2148 BCP 26, RFC 5226, May 2008. 2150 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 2151 Languages", BCP 47, RFC 5646, September 2009. 2153 [RFC5890] Klensin, J., "Internationalized Domain Names for 2154 Applications (IDNA): Definitions and Document 2155 Framework", RFC 5890, August 2010. 2157 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2158 Encodings", RFC 4648, October 2006. 2160 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: 2161 Session Description Protocol", RFC 4566, July 2006. 2163 12.2. Informative References 2165 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session 2166 Description Protocol", RFC 2327, April 1998. 2168 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, 2169 "Network Time Protocol Version 4: Protocol and 2170 Algorithms Specification", RFC 5905, June 2010. 2172 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 2173 Announcement Protocol", RFC 2974, October 2000. 2175 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., 2176 Johnston, A., Peterson, J., Sparks, R., Handley, M., 2177 and E. Schooler, "SIP: Session Initiation Protocol", 2178 RFC 3261, June 2002. 2180 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real 2181 Time Streaming Protocol (RTSP)", RFC 2326, 2182 April 1998. 2184 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer 2185 Model with Session Description Protocol (SDP)", 2186 RFC 3264, June 2002. 2188 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session 2189 Description Protocol (SDP) Grouping Framework", 2190 RFC 5888, June 2010. 2192 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2193 Jacobson, "RTP: A Transport Protocol for Real-Time 2194 Applications", STD 64, RFC 3550, July 2003. 2196 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for 2197 Audio and Video Conferences with Minimal Control", 2198 STD 65, RFC 3551, July 2003. 2200 [RFC3556] Casner, S., "Session Description Protocol (SDP) 2201 Bandwidth Modifiers for RTP Control Protocol (RTCP) 2202 Bandwidth", RFC 3556, July 2003. 2204 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) 2205 attribute in Session Description Protocol (SDP)", 2206 RFC 3605, October 2003. 2208 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., 2209 and K. Norrman, "The Secure Real-time Transport 2210 Protocol (SRTP)", RFC 3711, March 2004. 2212 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 2213 "Indicating User Agent Capabilities in the Session 2214 Initiation Protocol (SIP)", RFC 3840, August 2004. 2216 [RFC3890] Westerlund, M., "A Transport Independent Bandwidth 2217 Modifier for the Session Description Protocol 2218 (SDP)", RFC 3890, September 2004. 2220 [RFC5245] Rosenberg, J., "Interactive Connectivity 2221 Establishment (ICE): A Protocol for Network Address 2222 Translator (NAT) Traversal for Offer/Answer 2223 Protocols", RFC 5245, April 2010. 2225 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. 2226 Roach, "TCP Candidates with Interactive Connectivity 2227 Establishment (ICE)", RFC 6544, March 2012. 2229 [ITU.H332.1998] International Telecommunication Union, "H.323 2230 extended for loosely coupled conferences", 2231 ITU Recommendation H.332, September 1998. 2233 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., 2234 and E. Carrara, "Key Management Extensions for 2235 Session Description Protocol (SDP) and Real Time 2236 Streaming Protocol (RTSP)", RFC 4567, July 2006. 2238 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 2239 Description Protocol (SDP) Security Descriptions for 2240 Media Streams", RFC 4568, July 2006. 2242 [RFC5322] Resnick, P., Ed., "Internet Message Format", 2243 RFC 5322, October 2008. 2245 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications 2246 and Registration Procedures", BCP 13, RFC 4288, 2247 December 2005. 2249 Authors' Addresses 2251 Mark Handley 2252 University College London 2253 Department of Computer Science 2254 London WC1E 6BT 2255 UK 2257 EMail: M.Handley@cs.ucl.ac.uk 2259 Van Jacobson 2260 PARC 2261 3333 Coyote Hill Road 2262 Palo Alto, CA 94304 2263 USA 2265 EMail: van@parc.com 2266 Colin Perkins 2267 University of Glasgow 2268 School of Computing Science 2269 University of Glasgow 2270 Glasgow G12 8QQ 2271 UK 2273 EMail: csp@csperkins.org 2275 Ali Begen 2276 Cisco 2277 181 Bay Street 2278 Toronto, ON M5J 2T3 2279 Canada 2281 EMail: abegen@cisco.com