idnits 2.17.1 draft-ietf-mmusic-rfc4566bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2207. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2218. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2225. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2231. 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 non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 11 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 -- The draft header indicates that this document obsoletes RFC4566, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 8, 2008) is 5791 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 4234 (ref. '4') (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 2327 (ref. '6') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2434 (ref. '8') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3066 (ref. '9') (Obsoleted by RFC 4646, RFC 4647) ** Obsolete normative reference: RFC 3490 (ref. '10') (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 3548 (ref. '11') (Obsoleted by RFC 4648) ** Obsolete normative reference: RFC 4566 (ref. '12') (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 1305 (ref. '13') (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '16') (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 3388 (ref. '18') (Obsoleted by RFC 5888) -- Obsolete informational reference (is this intentional?): RFC 2822 (ref. '29') (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 4288 (ref. '30') (Obsoleted by RFC 6838) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Handley 3 Internet-Draft UCL 4 Obsoletes: 4566 (if approved) V. Jacobson 5 Intended status: Standards Track Packet Design 6 Expires: December 10, 2008 C. Perkins 7 University of Glasgow 8 June 8, 2008 10 SDP: Session Description Protocol 11 draft-ietf-mmusic-rfc4566bis-01.txt 13 Status of This Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 10, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This memo defines the Session Description Protocol (SDP). SDP is 45 intended for describing multimedia sessions for the purposes of 46 session announcement, session invitation, and other forms of 47 multimedia session initiation. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . . 5 54 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 5 55 3.2. Streaming Media . . . . . . . . . . . . . . . . . . . . . 5 56 3.3. Email and the World Wide Web . . . . . . . . . . . . . . . 5 57 3.4. Multicast Session Announcement . . . . . . . . . . . . . . 5 58 4. Requirements and Recommendations . . . . . . . . . . . . . . . 6 59 4.1. Media and Transport Information . . . . . . . . . . . . . 7 60 4.2. Timing Information . . . . . . . . . . . . . . . . . . . . 7 61 4.3. Private Sessions . . . . . . . . . . . . . . . . . . . . . 8 62 4.4. Obtaining Further Information about a Session . . . . . . 8 63 4.5. Categorisation . . . . . . . . . . . . . . . . . . . . . . 8 64 4.6. Internationalisation . . . . . . . . . . . . . . . . . . . 8 65 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . . 8 66 5.1. Protocol Version ("v=") . . . . . . . . . . . . . . . . . 11 67 5.2. Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 11 68 5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 13 69 5.4. Session Information ("i=") . . . . . . . . . . . . . . . . 13 70 5.5. URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 13 71 5.6. Email Address and Phone Number ("e=" and "p=") . . . . . . 14 72 5.7. Connection Data ("c=") . . . . . . . . . . . . . . . . . . 14 73 5.8. Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 17 74 5.9. Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 18 75 5.10. Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . 19 76 5.11. Time Zones ("z=") . . . . . . . . . . . . . . . . . . . . 19 77 5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . . 20 78 5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 22 79 5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 23 80 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . . 25 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 83 8.1. The "application/sdp" Media Type . . . . . . . . . . . . . 33 84 8.2. Registration of Parameters . . . . . . . . . . . . . . . . 35 85 8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 35 86 8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 35 87 8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 36 88 8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 36 89 8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 38 90 8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 38 91 8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . . 38 92 8.2.8. Registration Procedure . . . . . . . . . . . . . . . . 39 93 8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 39 94 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 39 95 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . . 44 96 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 97 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 98 12.1. Normative References . . . . . . . . . . . . . . . . . . . 45 99 12.2. Informative References . . . . . . . . . . . . . . . . . . 46 101 1. Introduction 103 When initiating multimedia teleconferences, voice-over-IP calls, 104 streaming video, or other sessions, there is a requirement to convey 105 media details, transport addresses, and other session description 106 metadata to the participants. 108 SDP provides a standard representation for such information, 109 irrespective of how that information is transported. SDP is purely a 110 format for session description -- it does not incorporate a transport 111 protocol, and it is intended to use different transport protocols as 112 appropriate, including the Session Announcement Protocol [14], 113 Session Initiation Protocol [15], Real Time Streaming Protocol [16], 114 electronic mail using the MIME extensions, and the Hypertext 115 Transport Protocol. 117 SDP is intended to be general purpose so that it can be used in a 118 wide range of network environments and applications. However, it is 119 not intended to support negotiation of session content or media 120 encodings: this is viewed as outside the scope of session 121 description. 123 This memo obsoletes RFC 4566 [12]. The changes relative to RFC 4566 124 are limited to essential corrections, and are outlined in Section 10 125 of this memo. 127 2. Glossary of Terms 129 The following terms are used in this document and have specific 130 meaning within the context of this document. 132 Conference: A multimedia conference is a set of two or more 133 communicating users along with the software they are using to 134 communicate. 136 Session: A multimedia session is a set of multimedia senders and 137 receivers and the data streams flowing from senders to receivers. 138 A multimedia conference is an example of a multimedia session. 140 Session Description: A well-defined format for conveying sufficient 141 information to discover and participate in a multimedia session. 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC 2119 [3]. 147 3. Examples of SDP Usage 149 3.1. Session Initiation 151 The Session Initiation Protocol (SIP) [15] is an application-layer 152 control protocol for creating, modifying, and terminating sessions 153 such as Internet multimedia conferences, Internet telephone calls, 154 and multimedia distribution. The SIP messages used to create 155 sessions carry session descriptions that allow participants to agree 156 on a set of compatible media types. These session descriptions are 157 commonly formatted using SDP. When used with SIP, the offer/answer 158 model [17] provides a limited framework for negotiation using SDP. 160 3.2. Streaming Media 162 The Real Time Streaming Protocol (RTSP) [16], is an application-level 163 protocol for control over the delivery of data with real-time 164 properties. RTSP provides an extensible framework to enable 165 controlled, on-demand delivery of real-time data, such as audio and 166 video. An RTSP client and server negotiate an appropriate set of 167 parameters for media delivery, partially using SDP syntax to describe 168 those parameters. 170 3.3. Email and the World Wide Web 172 Alternative means of conveying session descriptions include 173 electronic mail and the World Wide Web (WWW). For both email and WWW 174 distribution, the media type "application/sdp" is used. This enables 175 the automatic launching of applications for participation in the 176 session from the WWW client or mail reader in a standard manner. 178 Note that announcements of multicast sessions made only via email or 179 the WWW do not have the property that the receiver of a session 180 announcement can necessarily receive the session because the 181 multicast sessions may be restricted in scope, and access to the WWW 182 server or reception of email is possible outside this scope. 184 3.4. Multicast Session Announcement 186 In order to assist the advertisement of multicast multimedia 187 conferences and other multicast sessions, and to communicate the 188 relevant session setup information to prospective participants, a 189 distributed session directory may be used. An instance of such a 190 session directory periodically sends packets containing a description 191 of the session to a well-known multicast group. These advertisements 192 are received by other session directories such that potential remote 193 participants can use the session description to start the tools 194 required to participate in the session. 196 One protocol used to implement such a distributed directory is the 197 Session Announcement Protocol (SAP) [14]. SDP provides the 198 recommended session description format for such session 199 announcements. 201 4. Requirements and Recommendations 203 The purpose of SDP is to convey information about media streams in 204 multimedia sessions to allow the recipients of a session description 205 to participate in the session. SDP is primarily intended for use in 206 an internetwork, although it is sufficiently general that it can 207 describe conferences in other network environments. Media streams 208 can be many-to-many. Sessions need not be continually active. 210 Thus far, multicast-based sessions on the Internet have differed from 211 many other forms of conferencing in that anyone receiving the traffic 212 can join the session (unless the session traffic is encrypted). In 213 such an environment, SDP serves two primary purposes. It is a means 214 to communicate the existence of a session, and it is a means to 215 convey sufficient information to enable joining and participating in 216 the session. In a unicast environment, only the latter purpose is 217 likely to be relevant. 219 An SDP session description includes the following: 221 o Session name and purpose 223 o Time(s) the session is active 225 o The media comprising the session 227 o Information needed to receive those media (addresses, ports, 228 formats, etc.) 230 As resources necessary to participate in a session may be limited, 231 some additional information may also be desirable: 233 o Information about the bandwidth to be used by the session 235 o Contact information for the person responsible for the session 237 In general, SDP must convey sufficient information to enable 238 applications to join a session (with the possible exception of 239 encryption keys) and to announce the resources to be used to any non- 240 participants that may need to know. (This latter feature is 241 primarily useful when SDP is used with a multicast session 242 announcement protocol.) 244 4.1. Media and Transport Information 246 An SDP session description includes the following media information: 248 o The type of media (video, audio, etc.) 250 o The transport protocol (RTP/UDP/IP, H.320, etc.) 252 o The format of the media (H.261 video, MPEG video, etc.) 254 In addition to media format and transport protocol, SDP conveys 255 address and port details. For an IP multicast session, these 256 comprise: 258 o The multicast group address for media 260 o The transport port for media 262 This address and port are the destination address and destination 263 port of the multicast stream, whether being sent, received, or both. 265 For unicast IP sessions, the following are conveyed: 267 o The remote address for media 269 o The remote transport port for media 271 The semantics of this address and port depend on the media and 272 transport protocol defined. By default, this SHOULD be the remote 273 address and remote port to which data is sent. Some media types may 274 redefine this behaviour, but this is NOT RECOMMENDED since it 275 complicates implementations (including middleboxes that must parse 276 the addresses to open Network Address Translation (NAT) or firewall 277 pinholes). 279 4.2. Timing Information 281 Sessions may be either bounded or unbounded in time. Whether or not 282 they are bounded, they may be only active at specific times. SDP can 283 convey: 285 o An arbitrary list of start and stop times bounding the session 287 o For each bound, repeat times such as "every Wednesday at 10am for 288 one hour" 290 This timing information is globally consistent, irrespective of local 291 time zone or daylight saving time (see Section 5.9). 293 4.3. Private Sessions 295 It is possible to create both public sessions and private sessions. 296 SDP itself does not distinguish between these; private sessions are 297 typically conveyed by encrypting the session description during 298 distribution. The details of how encryption is performed are 299 dependent on the mechanism used to convey SDP; mechanisms are 300 currently defined for SDP transported using SAP [14] and SIP [15], 301 and others may be defined in the future. 303 If a session announcement is private, it is possible to use that 304 private announcement to convey encryption keys necessary to decode 305 each of the media in a conference, including enough information to 306 know which encryption scheme is used for each media. 308 4.4. Obtaining Further Information about a Session 310 A session description should convey enough information to decide 311 whether or not to participate in a session. SDP may include 312 additional pointers in the form of Uniform Resource Identifiers 313 (URIs) for more information about the session. 315 4.5. Categorisation 317 When many session descriptions are being distributed by SAP, or any 318 other advertisement mechanism, it may be desirable to filter session 319 announcements that are of interest from those that are not. SDP 320 supports a categorisation mechanism for sessions that is capable of 321 being automated (the "a=cat:" attribute; see Section 6). 323 4.6. Internationalisation 325 The SDP specification recommends the use of the ISO 10646 character 326 sets in the UTF-8 encoding [5] to allow many different languages to 327 be represented. However, to assist in compact representations, SDP 328 also allows other character sets such as ISO 8859-1 to be used when 329 desired. Internationalisation only applies to free-text fields 330 (session name and background information), and not to SDP as a whole. 332 5. SDP Specification 334 An SDP session description is denoted by the media type "application/ 335 sdp" (See Section 8). 337 An SDP session description is entirely textual using the ISO 10646 338 character set in UTF-8 encoding. SDP field names and attribute names 339 use only the US-ASCII subset of UTF-8, but textual fields and 340 attribute values MAY use the full ISO 10646 character set. Field and 341 attribute values that use the full UTF-8 character set are never 342 directly compared, hence there is no requirement for UTF-8 343 normalisation. The textual form, as opposed to a binary encoding 344 such as ASN.1 or XDR, was chosen to enhance portability, to enable a 345 variety of transports to be used, and to allow flexible, text-based 346 toolkits to be used to generate and process session descriptions. 347 However, since SDP may be used in environments where the maximum 348 permissible size of a session description is limited, the encoding is 349 deliberately compact. Also, since announcements may be transported 350 via very unreliable means or damaged by an intermediate caching 351 server, the encoding was designed with strict order and formatting 352 rules so that most errors would result in malformed session 353 announcements that could be detected easily and discarded. This also 354 allows rapid discarding of encrypted session announcements for which 355 a receiver does not have the correct key. 357 An SDP session description consists of a number of lines of text of 358 the form: 360 = 362 where MUST be exactly one case-significant character and 363 is structured text whose format depends on . In 364 general, is either a number of fields delimited by a single 365 space character or a free format string, and is case-significant 366 unless a specific field defines otherwise. Whitespace MUST NOT be 367 used on either side of the "=" sign. 369 An SDP session description consists of a session-level section 370 followed by zero or more media-level sections. The session-level 371 part starts with a "v=" line and continues to the first media-level 372 section. Each media-level section starts with an "m=" line and 373 continues to the next media-level section or end of the whole session 374 description. In general, session-level values are the default for 375 all media unless overridden by an equivalent media-level value. 377 Some lines in each description are REQUIRED and some are OPTIONAL, 378 but all MUST appear in exactly the order given here (the fixed order 379 greatly enhances error detection and allows for a simple parser). 380 OPTIONAL items are marked with a "*". 382 Session description 383 v= (protocol version) 384 o= (originator and session identifier) 385 s= (session name) 386 i=* (session information) 387 u=* (URI of description) 388 e=* (email address) 389 p=* (phone number) 390 c=* (connection information -- not required if included in 391 all media) 392 b=* (zero or more bandwidth information lines) 393 One or more time descriptions ("t=" and "r=" lines; see below) 394 z=* (time zone adjustments) 395 k=* (encryption key) 396 a=* (zero or more session attribute lines) 397 Zero or more media descriptions 399 Time description 400 t= (time the session is active) 401 r=* (zero or more repeat times) 403 Media description, if present 404 m= (media name and transport address) 405 i=* (media title) 406 c=* (connection information -- optional if included at 407 session level) 408 b=* (zero or more bandwidth information lines) 409 k=* (encryption key) 410 a=* (zero or more media attribute lines) 412 The set of type letters is deliberately small and not intended to be 413 extensible -- an SDP parser MUST completely ignore any session 414 description that contains a type letter that it does not understand. 415 The attribute mechanism ("a=" described below) is the primary means 416 for extending SDP and tailoring it to particular applications or 417 media. Some attributes (the ones listed in Section 6 of this memo) 418 have a defined meaning, but others may be added on an application-, 419 media-, or session-specific basis. An SDP parser MUST ignore any 420 attribute it doesn't understand. 422 An SDP session description may contain URIs that reference external 423 content in the "u=", "k=", and "a=" lines. These URIs may be 424 dereferenced in some cases, making the session description non-self- 425 contained. 427 The connection ("c=") and attribute ("a=") information in the 428 session-level section applies to all the media of that session unless 429 overridden by connection information or an attribute of the same name 430 in the media description. For instance, in the example below, each 431 media behaves as if it were given a "recvonly" attribute. 433 An example SDP description is: 435 v=0 436 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 437 s=SDP Seminar 438 i=A Seminar on the session description protocol 439 u=http://www.example.com/seminars/sdp.pdf 440 e=j.doe@example.com (Jane Doe) 441 c=IN IP4 224.2.17.12/127 442 t=2873397496 2873404696 443 a=recvonly 444 m=audio 49170 RTP/AVP 0 445 m=video 51372 RTP/AVP 99 446 a=rtpmap:99 h263-1998/90000 448 Text fields such as the session name and information are octet 449 strings that may contain any octet with the exceptions of 0x00 (Nul), 450 0x0a (ASCII newline), and 0x0d (ASCII carriage return). The sequence 451 CRLF (0x0d0a) is used to end a record, although parsers SHOULD be 452 tolerant and also accept records terminated with a single newline 453 character. If the "a=charset" attribute is not present, these octet 454 strings MUST be interpreted as containing ISO-10646 characters in 455 UTF-8 encoding (the presence of the "a=charset" attribute may force 456 some fields to be interpreted differently). 458 A session description can contain domain names in the "o=", "u=", 459 "e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply 460 with [1], [2]. Internationalised domain names (IDNs) MUST be 461 represented using the ASCII Compatible Encoding (ACE) form defined in 462 [10] and MUST NOT be directly represented in UTF-8 or any other 463 encoding (this requirement is for compatibility with RFC 2327 [6] and 464 other early SDP-related standards, which predate the development of 465 internationalised domain names). 467 5.1. Protocol Version ("v=") 469 v=0 471 The "v=" field gives the version of the Session Description Protocol. 472 This memo defines version 0. There is no minor version number. 474 5.2. Origin ("o=") 476 o= 477 479 The "o=" field gives the originator of the session (her username and 480 the address of the user's host) plus a session identifier and version 481 number: 483 is the user's login on the originating host, or it is "-" 484 if the originating host does not support the concept of user IDs. 485 The MUST NOT contain spaces. 487 is a numeric string such that the tuple of , 488 , , , and forms a 489 globally unique identifier for the session. The method of 490 allocation is up to the creating tool, but it has been 491 suggested that a Network Time Protocol (NTP) format timestamp be 492 used to ensure uniqueness [13]. 494 is a version number for this session description. 495 Its usage is up to the creating tool, so long as is 496 increased when a modification is made to the session data. Again, 497 it is RECOMMENDED that an NTP format timestamp is used. 499 is a text string giving the type of network. Initially 500 "IN" is defined to have the meaning "Internet", but other values 501 MAY be registered in the future (see Section 8). 503 is a text string giving the type of the address that 504 follows. Initially "IP4" and "IP6" are defined, but other values 505 MAY be registered in the future (see Section 8). 507 is the address of the machine from which the 508 session was created. For an address type of IP4, this is either 509 the fully qualified domain name of the machine or the dotted- 510 decimal representation of the IP version 4 address of the machine. 511 For an address type of IP6, this is either the fully qualified 512 domain name of the machine or the compressed textual 513 representation of the IP version 6 address of the machine. For 514 both IP4 and IP6, the fully qualified domain name is the form that 515 SHOULD be given unless this is unavailable, in which case the 516 globally unique address MAY be substituted. A local IP address 517 MUST NOT be used in any context where the SDP description might 518 leave the scope in which the address is meaningful (for example, a 519 local address MUST NOT be included in an application-level 520 referral that might leave the scope). 522 In general, the "o=" field serves as a globally unique identifier for 523 this version of this session description, and the subfields excepting 524 the version taken together identify the session irrespective of any 525 modifications. 527 For privacy reasons, it is sometimes desirable to obfuscate the 528 username and IP address of the session originator. If this is a 529 concern, an arbitrary and private MAY be 530 chosen to populate the "o=" field, provided that these are selected 531 in a manner that does not affect the global uniqueness of the field. 533 5.3. Session Name ("s=") 535 s= 537 The "s=" field is the textual session name. There MUST be one and 538 only one "s=" field per session description. The "s=" field MUST NOT 539 be empty and SHOULD contain ISO 10646 characters (but see also the 540 "a=charset" attribute). If a session has no meaningful name, the 541 value "s= " SHOULD be used (i.e., a single space as the session 542 name). 544 5.4. Session Information ("i=") 546 i= 548 The "i=" field provides textual information about the session. There 549 MUST be at most one session-level "i=" field per session description, 550 and at most one "i=" field per media. If the "a=charset" attribute 551 is present, it specifies the character set used in the "i=" field. 552 If the "a=charset" attribute is not present, the "i=" field MUST 553 contain ISO 10646 characters in UTF-8 encoding. 555 A single "i=" field MAY also be used for each media definition. In 556 media definitions, "i=" fields are primarily intended for labelling 557 media streams. As such, they are most likely to be useful when a 558 single session has more than one distinct media stream of the same 559 media type. An example would be two different whiteboards, one for 560 slides and one for feedback and questions. 562 The "i=" field is intended to provide a free-form human-readable 563 description of the session or the purpose of a media stream. It is 564 not suitable for parsing by automata. 566 5.5. URI ("u=") 568 u= 570 A URI is a Uniform Resource Identifier as used by WWW clients [7]. 571 The URI should be a pointer to additional information about the 572 session. This field is OPTIONAL, but if it is present it MUST be 573 specified before the first media field. No more than one URI field 574 is allowed per session description. 576 5.6. Email Address and Phone Number ("e=" and "p=") 578 e= 579 p= 581 The "e=" and "p=" lines specify contact information for the person 582 responsible for the conference. This is not necessarily the same 583 person that created the conference announcement. 585 Inclusion of an email address or phone number is OPTIONAL. Note that 586 the previous version of SDP specified that either an email field or a 587 phone field MUST be specified, but this was widely ignored. The 588 change brings the specification into line with common usage. 590 If an email address or phone number is present, it MUST be specified 591 before the first media field. More than one email or phone field can 592 be given for a session description. 594 Phone numbers SHOULD be given in the form of an international public 595 telecommunication number (see ITU-T Recommendation E.164) preceded by 596 a "+". Spaces and hyphens may be used to split up a phone field to 597 aid readability if desired. For example: 599 p=+1 617 555-6011 601 Both email addresses and phone numbers can have an OPTIONAL free text 602 string associated with them, normally giving the name of the person 603 who may be contacted. This MUST be enclosed in parentheses if it is 604 present. For example: 606 e=j.doe@example.com (Jane Doe) 608 The alternative RFC 2822 [29] name quoting convention is also allowed 609 for both email addresses and phone numbers. For example: 611 e=Jane Doe 613 The free text string SHOULD be in the ISO-10646 character set with 614 UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if 615 the appropriate session-level "a=charset" attribute is set. 617 5.7. Connection Data ("c=") 619 c= 621 The "c=" field contains connection data. 623 A session description MUST contain either at least one "c=" field in 624 each media description or a single "c=" field at the session level. 625 It MAY contain a single session-level "c=" field and additional "c=" 626 field(s) per media description, in which case the per-media values 627 override the session-level settings for the respective media. 629 The first sub-field ("") is the network type, which is a 630 text string giving the type of network. Initially, "IN" is defined 631 to have the meaning "Internet", but other values MAY be registered in 632 the future (see Section 8). 634 The second sub-field ("") is the address type. This allows 635 SDP to be used for sessions that are not IP based. This memo only 636 defines IP4 and IP6, but other values MAY be registered in the future 637 (see Section 8). 639 The third sub-field ("") is the connection 640 address. OPTIONAL sub-fields MAY be added after the connection 641 address depending on the value of the field. 643 When the is IP4 and IP6, the connection address is defined 644 as follows: 646 o If the session is multicast, the connection address will be an IP 647 multicast group address. If the session is not multicast, then 648 the connection address contains the unicast IP address of the 649 expected data source or data relay or data sink as determined by 650 additional attribute fields. It is not expected that unicast 651 addresses will be given in a session description that is 652 communicated by a multicast announcement, though this is not 653 prohibited. 655 o Sessions using an IPv4 multicast connection address MUST also have 656 a time to live (TTL) value present in addition to the multicast 657 address. The TTL and the address together define the scope with 658 which multicast packets sent in this conference will be sent. TTL 659 values MUST be in the range 0-255. Although the TTL MUST be 660 specified, its use to scope multicast traffic is deprecated; 661 applications SHOULD use an administratively scoped address 662 instead. 664 The TTL for the session is appended to the address using a slash as a 665 separator. An example is: 667 c=IN IP4 224.2.36.42/127 669 IPv6 multicast does not use TTL scoping, and hence the TTL value MUST 670 NOT be present for IPv6 multicast. It is expected that IPv6 scoped 671 addresses will be used to limit the scope of conferences. 673 Hierarchical or layered encoding schemes are data streams where the 674 encoding from a single media source is split into a number of layers. 675 The receiver can choose the desired quality (and hence bandwidth) by 676 only subscribing to a subset of these layers. Such layered encodings 677 are normally transmitted in multiple multicast groups to allow 678 multicast pruning. This technique keeps unwanted traffic from sites 679 only requiring certain levels of the hierarchy. For applications 680 requiring multiple multicast groups, we allow the following notation 681 to be used for the connection address: 683 [/]/ 685 If the number of addresses is not given, it is assumed to be one. 686 Multicast addresses so assigned are contiguously allocated above the 687 base address, so that, for example: 689 c=IN IP4 224.2.1.1/127/3 691 would state that addresses 224.2.1.1, 224.2.1.2, and 224.2.1.3 are to 692 be used at a TTL of 127. This is semantically identical to including 693 multiple "c=" lines in a media description: 695 c=IN IP4 224.2.1.1/127 696 c=IN IP4 224.2.1.2/127 697 c=IN IP4 224.2.1.3/127 699 Similarly, an IPv6 example would be: 701 c=IN IP6 FF15::101/3 703 which is semantically equivalent to: 705 c=IN IP6 FF15::101 706 c=IN IP6 FF15::102 707 c=IN IP6 FF15::103 709 (remembering that the TTL field is not present in IPv6 multicast). 711 Multiple addresses or "c=" lines MAY be specified on a per-media 712 basis only if they provide multicast addresses for different layers 713 in a hierarchical or layered encoding scheme. They MUST NOT be 714 specified for a session-level "c=" field. 716 The slash notation for multiple addresses described above MUST NOT be 717 used for IP unicast addresses. 719 5.8. Bandwidth ("b=") 721 b=: 723 This OPTIONAL field denotes the proposed bandwidth to be used by the 724 session or media. The is an alphanumeric modifier giving 725 the meaning of the figure. Two values are defined in 726 this specification, but other values MAY be registered in the future 727 (see Section 8 and [21], [25]): 729 CT If the bandwidth of a session or media in a session is different 730 from the bandwidth implicit from the scope, a "b=CT:..." line 731 SHOULD be supplied for the session giving the proposed upper limit 732 to the bandwidth used (the "conference total" bandwidth). The 733 primary purpose of this is to give an approximate idea as to 734 whether two or more sessions can coexist simultaneously. When 735 using the CT modifier with RTP, if several RTP sessions are part 736 of the conference, the conference total refers to total bandwidth 737 of all RTP sessions. 739 AS The bandwidth is interpreted to be application specific (it will 740 be the application's concept of maximum bandwidth). Normally, 741 this will coincide with what is set on the application's "maximum 742 bandwidth" control if applicable. For RTP-based applications, AS 743 gives the RTP "session bandwidth" as defined in Section 6.2 of 744 [19]. 746 Note that CT gives a total bandwidth figure for all the media at all 747 sites. AS gives a bandwidth figure for a single media at a single 748 site, although there may be many sites sending simultaneously. 750 A prefix "X-" is defined for names. This is intended for 751 experimental purposes only. For example: 753 b=X-YZ:128 755 Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers 756 SHOULD be registered with IANA in the standard namespace. SDP 757 parsers MUST ignore bandwidth fields with unknown modifiers. 758 Modifiers MUST be alphanumeric and, although no length limit is 759 given, it is recommended that they be short. 761 The is interpreted as kilobits per second by default. 762 The definition of a new modifier MAY specify that the 763 bandwidth is to be interpreted in some alternative unit (the "CT" and 764 "AS" modifiers defined in this memo use the default units). 766 5.9. Timing ("t=") 768 t= 770 The "t=" lines specify the start and stop times for a session. 771 Multiple "t=" lines MAY be used if a session is active at multiple 772 irregularly spaced times; each additional "t=" line specifies an 773 additional period of time for which the session will be active. If 774 the session is active at regular times, an "r=" line (see below) 775 should be used in addition to, and following, a "t=" line -- in which 776 case the "t=" line specifies the start and stop times of the repeat 777 sequence. 779 The first and second sub-fields give the start and stop times, 780 respectively, for the session. These values are the decimal 781 representation of Network Time Protocol (NTP) time values in seconds 782 since 1900 [13]. To convert these values to UNIX time, subtract 783 decimal 2208988800. 785 NTP timestamps are elsewhere represented by 64-bit values, which wrap 786 sometime in the year 2036. Since SDP uses an arbitrary length 787 decimal representation, this should not cause an issue (SDP 788 timestamps MUST continue counting seconds since 1900, NTP will use 789 the value modulo the 64-bit limit). 791 If the is set to zero, then the session is not bounded, 792 though it will not become active until after the . If 793 the is also zero, the session is regarded as permanent. 795 User interfaces SHOULD strongly discourage the creation of unbounded 796 and permanent sessions as they give no information about when the 797 session is actually going to terminate, and so make scheduling 798 difficult. 800 The general assumption may be made, when displaying unbounded 801 sessions that have not timed out to the user, that an unbounded 802 session will only be active until half an hour from the current time 803 or the session start time, whichever is the later. If behaviour 804 other than this is required, an end-time SHOULD be given and modified 805 as appropriate when new information becomes available about when the 806 session should really end. 808 Permanent sessions may be shown to the user as never being active 809 unless there are associated repeat times that state precisely when 810 the session will be active. 812 5.10. Repeat Times ("r=") 814 r= 816 "r=" fields specify repeat times for a session. For example, if a 817 session is active at 10am on Monday and 11am on Tuesday for one hour 818 each week for three months, then the in the 819 corresponding "t=" field would be the NTP representation of 10am on 820 the first Monday, the would be 1 week, the would be 1 hour, and the offsets would be zero and 25 822 hours. The corresponding "t=" field stop time would be the NTP 823 representation of the end of the last session three months later. By 824 default, all fields are in seconds, so the "r=" and "t=" fields might 825 be the following: 827 t=3034423619 3042462419 828 r=604800 3600 0 90000 830 To make description more compact, times may also be given in units of 831 days, hours, or minutes. The syntax for these is a number 832 immediately followed by a single case-sensitive character. 833 Fractional units are not allowed -- a smaller unit should be used 834 instead. The following unit specification characters are allowed: 836 d - days (86400 seconds) 837 h - hours (3600 seconds) 838 m - minutes (60 seconds) 839 s - seconds (allowed for completeness) 841 Thus, the above session announcement could also have been written: 843 r=7d 1h 0 25h 845 Monthly and yearly repeats cannot be directly specified with a single 846 SDP repeat time; instead, separate "t=" fields should be used to 847 explicitly list the session times. 849 5.11. Time Zones ("z=") 851 z= .... 853 To schedule a repeated session that spans a change from daylight 854 saving time to standard time or vice versa, it is necessary to 855 specify offsets from the base time. This is required because 856 different time zones change time at different times of day, different 857 countries change to or from daylight saving time on different dates, 858 and some countries do not have daylight saving time at all. 860 Thus, in order to schedule a session that is at the same time winter 861 and summer, it must be possible to specify unambiguously by whose 862 time zone a session is scheduled. To simplify this task for 863 receivers, we allow the sender to specify the NTP time that a time 864 zone adjustment happens and the offset from the time when the session 865 was first scheduled. The "z=" field allows the sender to specify a 866 list of these adjustment times and offsets from the base time. 868 An example might be the following: 870 z=2882844526 -1h 2898848070 0 872 This specifies that at time 2882844526, the time base by which the 873 session's repeat times are calculated is shifted back by 1 hour, and 874 that at time 2898848070, the session's original time base is 875 restored. Adjustments are always relative to the specified start 876 time -- they are not cumulative. Adjustments apply to all "t=" and 877 "r=" lines in a session description. 879 If a session is likely to last several years, it is expected that the 880 session announcement will be modified periodically rather than 881 transmit several years' worth of adjustments in one session 882 announcement. 884 5.12. Encryption Keys ("k=") 886 k= 887 k=: 889 If transported over a secure and trusted channel, the Session 890 Description Protocol MAY be used to convey encryption keys. A simple 891 mechanism for key exchange is provided by the key field ("k="), 892 although this is primarily supported for compatibility with older 893 implementations and its use is NOT RECOMMENDED. Work is in progress 894 to define new key exchange mechanisms for use with SDP [27] [28], and 895 it is expected that new applications will use those mechanisms. 897 A key field is permitted before the first media entry (in which case 898 it applies to all media in the session), or for each media entry as 899 required. The format of keys and their usage are outside the scope 900 of this document, and the key field provides no way to indicate the 901 encryption algorithm to be used, key type, or other information about 902 the key: this is assumed to be provided by the higher-level protocol 903 using SDP. If there is a need to convey this information within SDP, 904 the extensions mentioned previously SHOULD be used. Many security 905 protocols require two keys: one for confidentiality, another for 906 integrity. This specification does not support transfer of two keys. 908 The method indicates the mechanism to be used to obtain a usable key 909 by external means, or from the encoded encryption key given. The 910 following methods are defined: 912 k=clear: 914 The encryption key is included untransformed in this key field. 915 This method MUST NOT be used unless it can be guaranteed that 916 the SDP is conveyed over a secure channel. The encryption key 917 is interpreted as text according to the charset attribute; use 918 the "k=base64:" method to convey characters that are otherwise 919 prohibited in SDP. 921 k=base64: 923 The encryption key is included in this key field but has been 924 base64 encoded [11] because it includes characters that are 925 prohibited in SDP. This method MUST NOT be used unless it can 926 be guaranteed that the SDP is conveyed over a secure channel. 928 k=uri: 930 A Uniform Resource Identifier is included in the key field. 931 The URI refers to the data containing the key, and may require 932 additional authentication before the key can be returned. When 933 a request is made to the given URI, the reply should specify 934 the encoding for the key. The URI is often an Secure Socket 935 Layer/Transport Layer Security (SSL/TLS)-protected HTTP URI 936 ("https:"), although this is not required. 938 k=prompt 940 No key is included in this SDP description, but the session or 941 media stream referred to by this key field is encrypted. The 942 user should be prompted for the key when attempting to join the 943 session, and this user-supplied key should then be used to 944 decrypt the media streams. The use of user-specified keys is 945 NOT RECOMMENDED, since such keys tend to have weak security 946 properties. 948 The key field MUST NOT be used unless it can be guaranteed that the 949 SDP is conveyed over a secure and trusted channel. An example of 950 such a channel might be SDP embedded inside an S/MIME message or a 951 TLS-protected HTTP session. It is important to ensure that the 952 secure channel is with the party that is authorised to join the 953 session, not an intermediary: if a caching proxy server is used, it 954 is important to ensure that the proxy is either trusted or unable to 955 access the SDP. 957 5.13. Attributes ("a=") 959 a= 960 a=: 962 Attributes are the primary means for extending SDP. Attributes may 963 be defined to be used as "session-level" attributes, "media-level" 964 attributes, or both. 966 A media description may have any number of attributes ("a=" fields) 967 that are media specific. These are referred to as "media-level" 968 attributes and add information about the media stream. Attribute 969 fields can also be added before the first media field; these 970 "session-level" attributes convey additional information that applies 971 to the conference as a whole rather than to individual media. 973 Attribute fields may be of two forms: 975 o A property attribute is simply of the form "a=". These are 976 binary attributes, and the presence of the attribute conveys that 977 the attribute is a property of the session. An example might be 978 "a=recvonly". 980 o A value attribute is of the form "a=:". For 981 example, a whiteboard could have the value attribute "a=orient: 982 landscape" 984 Attribute interpretation depends on the media tool being invoked. 985 Thus receivers of session descriptions should be configurable in 986 their interpretation of session descriptions in general and of 987 attributes in particular. 989 Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. 991 Attribute values are octet strings, and MAY use any octet value 992 except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute 993 values are to be interpreted as in ISO-10646 character set with UTF-8 994 encoding. Unlike other text fields, attribute values are NOT 995 normally affected by the "charset" attribute as this would make 996 comparisons against known values problematic. However, when an 997 attribute is defined, it can be defined to be charset dependent, in 998 which case its value should be interpreted in the session charset 999 rather than in ISO-10646. 1001 Attributes MUST be registered with IANA (see Section 8). If an 1002 attribute is received that is not understood, it MUST be ignored by 1003 the receiver. 1005 5.14. Media Descriptions ("m=") 1007 m= ... 1009 A session description may contain a number of media descriptions. 1010 Each media description starts with an "m=" field and is terminated by 1011 either the next "m=" field or by the end of the session description. 1012 A media field has several sub-fields: 1014 is the media type. Currently defined media are "audio", 1015 "video", "text", "application", and "message", although this list 1016 may be extended in the future (see Section 8). 1018 is the transport port to which the media stream is sent. The 1019 meaning of the transport port depends on the network being used as 1020 specified in the relevant "c=" field, and on the transport 1021 protocol defined in the sub-field of the media field. 1022 Other ports used by the media application (such as the RTP Control 1023 Protocol (RTCP) port [19]) MAY be derived algorithmically from the 1024 base media port or MAY be specified in a separate attribute (for 1025 example, "a=rtcp:" as defined in [22]). 1027 If non-contiguous ports are used or if they don't follow the 1028 parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" 1029 attribute MUST be used. Applications that are requested to send 1030 media to a that is odd and where the "a=rtcp:" is present 1031 MUST NOT subtract 1 from the RTP port: that is, they MUST send the 1032 RTP to the port indicated in and send the RTCP to the port 1033 indicated in the "a=rtcp" attribute. 1035 For applications where hierarchically encoded streams are being 1036 sent to a unicast address, it may be necessary to specify multiple 1037 transport ports. This is done using a similar notation to that 1038 used for IP multicast addresses in the "c=" field: 1040 m= / ... 1042 In such a case, the ports used depend on the transport protocol. 1043 For RTP, the default is that only the even-numbered ports are used 1044 for data with the corresponding one-higher odd ports used for the 1045 RTCP belonging to the RTP session, and the 1046 denoting the number of RTP sessions. For example: 1048 m=video 49170/2 RTP/AVP 31 1050 would specify that ports 49170 and 49171 form one RTP/RTCP pair 1051 and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the 1052 transport protocol and 31 is the format (see below). If non- 1053 contiguous ports are required, they must be signalled using a 1054 separate attribute (for example, "a=rtcp:" as defined in [22]). 1056 If multiple addresses are specified in the "c=" field and multiple 1057 ports are specified in the "m=" field, a one-to-one mapping from 1058 port to the corresponding address is implied. For example: 1060 c=IN IP4 224.2.1.1/127/2 1061 m=video 49170/2 RTP/AVP 31 1063 would imply that address 224.2.1.1 is used with ports 49170 and 1064 49171, and address 224.2.1.2 is used with ports 49172 and 49173. 1066 The semantics of multiple "m=" lines using the same transport 1067 address are undefined. This implies that, unlike limited past 1068 practice, there is no implicit grouping defined by such means and 1069 an explicit grouping framework (for example, [18]) should instead 1070 be used to express the intended semantics. 1072 is the transport protocol. The meaning of the transport 1073 protocol is dependent on the address type field in the relevant 1074 "c=" field. Thus a "c=" field of IP4 indicates that the transport 1075 protocol runs over IP4. The following transport protocols are 1076 defined, but may be extended through registration of new protocols 1077 with IANA (see Section 8): 1079 * udp: denotes an unspecified protocol running over UDP. 1081 * RTP/AVP: denotes RTP [19] used under the RTP Profile for Audio 1082 and Video Conferences with Minimal Control [20] running over 1083 UDP. 1085 * RTP/SAVP: denotes the Secure Real-time Transport Protocol [23] 1086 running over UDP. 1088 The main reason to specify the transport protocol in addition to 1089 the media format is that the same standard media formats may be 1090 carried over different transport protocols even when the network 1091 protocol is the same -- a historical example is vat Pulse Code 1092 Modulation (PCM) audio and RTP PCM audio; another might be TCP/RTP 1093 PCM audio. In addition, relays and monitoring tools that are 1094 transport-protocol-specific but format-independent are possible. 1096 is a media format description. The fourth and any subsequent 1097 sub-fields describe the format of the media. The interpretation 1098 of the media format depends on the value of the sub-field. 1100 If the sub-field is "RTP/AVP" or "RTP/SAVP" the sub- 1101 fields contain RTP payload type numbers. When a list of payload 1102 type numbers is given, this implies that all of these payload 1103 formats MAY be used in the session, but the first of these formats 1104 SHOULD be used as the default format for the session. For dynamic 1105 payload type assignments the "a=rtpmap:" attribute (see Section 6) 1106 SHOULD be used to map from an RTP payload type number to a media 1107 encoding name that identifies the payload format. The "a=fmtp:" 1108 attribute MAY be used to specify format parameters (see 1109 Section 6). 1111 If the sub-field is "udp" the sub-fields MUST 1112 reference a media type describing the format under the "audio", 1113 "video", "text", "application", or "message" top-level media 1114 types. The media type registration SHOULD define the packet 1115 format for use with UDP transport. 1117 For media using other transport protocols, the field is 1118 protocol specific. Rules for interpretation of the sub- 1119 field MUST be defined when registering new protocols (see Section 1120 8.2.2). 1122 6. SDP Attributes 1124 The following attributes are defined. Since application writers may 1125 add new attributes as they are required, this list is not exhaustive. 1126 Registration procedures for new attributes are defined in Section 1127 8.2.4. 1129 a=cat: 1131 This attribute gives the dot-separated hierarchical category of 1132 the session. This is to enable a receiver to filter unwanted 1133 sessions by category. There is no central registry of 1134 categories. It is a session-level attribute, and it is not 1135 dependent on charset. 1137 a=keywds: 1139 Like the cat attribute, this is to assist identifying wanted 1140 sessions at the receiver. This allows a receiver to select 1141 interesting session based on keywords describing the purpose of 1142 the session; there is no central registry of keywords. It is a 1143 session-level attribute. It is a charset-dependent attribute, 1144 meaning that its value should be interpreted in the charset 1145 specified for the session description if one is specified, or 1146 by default in ISO 10646/UTF-8. 1148 a=tool: 1150 This gives the name and version number of the tool used to 1151 create the session description. It is a session-level 1152 attribute, and it is not dependent on charset. 1154 a=ptime: 1156 This gives the length of time in milliseconds represented by 1157 the media in a packet. This is probably only meaningful for 1158 audio data, but may be used with other media types if it makes 1159 sense. It should not be necessary to know ptime to decode RTP 1160 or vat audio, and it is intended as a recommendation for the 1161 encoding/packetisation of audio. It is a media-level 1162 attribute, and it is not dependent on charset. 1164 a=maxptime: 1166 This gives the maximum amount of media that can be encapsulated 1167 in each packet, expressed as time in milliseconds. The time 1168 SHALL be calculated as the sum of the time the media present in 1169 the packet represents. For frame-based codecs, the time SHOULD 1170 be an integer multiple of the frame size. This attribute is 1171 probably only meaningful for audio data, but may be used with 1172 other media types if it makes sense. It is a media-level 1173 attribute, and it is not dependent on charset. Note that this 1174 attribute was introduced after RFC 2327 [6], and non-updated 1175 implementations will ignore this attribute. 1177 a=rtpmap: / [/] 1180 This attribute maps from an RTP payload type number (as used in 1181 an "m=" line) to an encoding name denoting the payload format 1182 to be used. It also provides information on the clock rate and 1183 encoding parameters. It is a media-level attribute that is not 1184 dependent on charset. 1186 Although an RTP profile may make static assignments of payload 1187 type numbers to payload formats, it is more common for that 1188 assignment to be done dynamically using "a=rtpmap:" attributes. 1189 As an example of a static payload type, consider u-law PCM 1190 coded single-channel audio sampled at 8 kHz. This is 1191 completely defined in the RTP Audio/Video profile as payload 1192 type 0, so there is no need for an "a=rtpmap:" attribute, and 1193 the media for such a stream sent to UDP port 49232 can be 1194 specified as: 1196 m=audio 49232 RTP/AVP 0 1198 An example of a dynamic payload type is 16-bit linear encoded 1199 stereo audio sampled at 16 kHz. If we wish to use the dynamic 1200 RTP/AVP payload type 98 for this stream, additional information 1201 is required to decode it: 1203 m=audio 49232 RTP/AVP 98 1204 a=rtpmap:98 L16/16000/2 1206 Up to one rtpmap attribute can be defined for each media format 1207 specified. Thus, we might have the following: 1209 m=audio 49230 RTP/AVP 96 97 98 1210 a=rtpmap:96 L8/8000 1211 a=rtpmap:97 L16/8000 1212 a=rtpmap:98 L16/11025/2 1214 RTP profiles that specify the use of dynamic payload types MUST 1215 define the set of valid encoding names and/or a means to 1216 register encoding names if that profile is to be used with SDP. 1217 The "RTP/AVP" and "RTP/SAVP" profiles use media subtypes for 1218 encoding names, under the top-level media type denoted in the 1219 "m=" line. In the example above, the media types are 1220 "audio/l8" and "audio/l16". 1222 For audio streams, indicates the number 1223 of audio channels. This parameter is OPTIONAL and may be 1224 omitted if the number of channels is one, provided that no 1225 additional parameters are needed. 1227 For video streams, no encoding parameters are currently 1228 specified. 1230 Additional encoding parameters MAY be defined in the future, 1231 but codec-specific parameters SHOULD NOT be added. Parameters 1232 added to an "a=rtpmap:" attribute SHOULD only be those required 1233 for a session directory to make the choice of appropriate media 1234 to participate in a session. Codec-specific parameters should 1235 be added in other attributes (for example, "a=fmtp:"). 1237 Note: RTP audio formats typically do not include information 1238 about the number of samples per packet. If a non-default (as 1239 defined in the RTP Audio/Video Profile) packetisation is 1240 required, the "ptime" attribute is used as given above. 1242 a=recvonly 1244 This specifies that the tools should be started in receive-only 1245 mode where applicable. It can be either a session- or media- 1246 level attribute, and it is not dependent on charset. Note that 1247 recvonly applies to the media only, not to any associated 1248 control protocol (e.g., an RTP-based system in recvonly mode 1249 SHOULD still send RTCP packets). 1251 a=sendrecv 1253 This specifies that the tools should be started in send and 1254 receive mode. This is necessary for interactive conferences 1255 with tools that default to receive-only mode. It can be either 1256 a session or media-level attribute, and it is not dependent on 1257 charset. 1259 If none of the attributes "sendonly", "recvonly", "inactive", 1260 and "sendrecv" is present, "sendrecv" SHOULD be assumed as the 1261 default for sessions that are not of the conference type 1262 "broadcast" or "H332" (see below). 1264 a=sendonly 1266 This specifies that the tools should be started in send-only 1267 mode. An example may be where a different unicast address is 1268 to be used for a traffic destination than for a traffic source. 1269 In such a case, two media descriptions may be used, one 1270 sendonly and one recvonly. It can be either a session- or 1271 media-level attribute, but would normally only be used as a 1272 media attribute. It is not dependent on charset. Note that 1273 sendonly applies only to the media, and any associated control 1274 protocol (e.g., RTCP) SHOULD still be received and processed as 1275 normal. 1277 a=inactive 1279 This specifies that the tools should be started in inactive 1280 mode. This is necessary for interactive conferences where 1281 users can put other users on hold. No media is sent over an 1282 inactive media stream. Note that an RTP-based system SHOULD 1283 still send RTCP, even if started inactive. It can be either a 1284 session or media-level attribute, and it is not dependent on 1285 charset. 1287 a=orient: 1289 Normally this is only used for a whiteboard or presentation 1290 tool. It specifies the orientation of a the workspace on the 1291 screen. It is a media-level attribute. Permitted values are 1292 "portrait", "landscape", and "seascape" (upside-down 1293 landscape). It is not dependent on charset. 1295 a=type: 1297 This specifies the type of the conference. Suggested values 1298 are "broadcast", "meeting", "moderated", "test", and "H332". 1299 "recvonly" should be the default for "type:broadcast" sessions, 1300 "type:meeting" should imply "sendrecv", and "type:moderated" 1301 should indicate the use of a floor control tool and that the 1302 media tools are started so as to mute new sites joining the 1303 conference. 1305 Specifying the attribute "type:H332" indicates that this 1306 loosely coupled session is part of an H.332 session as defined 1307 in the ITU H.332 specification [26]. Media tools should be 1308 started "recvonly". 1310 Specifying the attribute "type:test" is suggested as a hint 1311 that, unless explicitly requested otherwise, receivers can 1312 safely avoid displaying this session description to users. 1314 The type attribute is a session-level attribute, and it is not 1315 dependent on charset. 1317 a=charset: 1319 This specifies the character set to be used to display the 1320 session name and information data. By default, the ISO-10646 1321 character set in UTF-8 encoding is used. If a more compact 1322 representation is required, other character sets may be used. 1323 For example, the ISO 8859-1 is specified with the following SDP 1324 attribute: 1326 a=charset:ISO-8859-1 1328 This is a session-level attribute and is not dependent on 1329 charset. The charset specified MUST be one of those registered 1330 with IANA, such as ISO-8859-1. The character set identifier is 1331 a US-ASCII string and MUST be compared against the IANA 1332 identifiers using a case-insensitive comparison. If the 1333 identifier is not recognised or not supported, all strings that 1334 are affected by it SHOULD be regarded as octet strings. 1336 Note that a character set specified MUST still prohibit the use 1337 of bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets 1338 requiring the use of these characters MUST define a quoting 1339 mechanism that prevents these bytes from appearing within text 1340 fields. 1342 a=sdplang: 1344 This can be a session-level attribute or a media-level 1345 attribute. As a session-level attribute, it specifies the 1346 language for the session description. As a media-level 1347 attribute, it specifies the language for any media-level SDP 1348 information field associated with that media. Multiple sdplang 1349 attributes can be provided either at session or media level if 1350 multiple languages in the session description or media use 1351 multiple languages, in which case the order of the attributes 1352 indicates the order of importance of the various languages in 1353 the session or media from most important to least important. 1355 In general, sending session descriptions consisting of multiple 1356 languages is discouraged. Instead, multiple descriptions 1357 SHOULD be sent describing the session, one in each language. 1358 However, this is not possible with all transport mechanisms, 1359 and so multiple sdplang attributes are allowed although NOT 1360 RECOMMENDED. 1362 The "sdplang" attribute value must be a single RFC 3066 1363 language tag in US-ASCII [9]. It is not dependent on the 1364 charset attribute. An "sdplang" attribute SHOULD be specified 1365 when a session is of sufficient scope to cross geographic 1366 boundaries where the language of recipients cannot be assumed, 1367 or where the session is in a different language from the 1368 locally assumed norm. 1370 a=lang: 1372 This can be a session-level attribute or a media-level 1373 attribute. As a session-level attribute, it specifies the 1374 default language for the session being described. As a media- 1375 level attribute, it specifies the language for that media, 1376 overriding any session-level language specified. Multiple lang 1377 attributes can be provided either at session or media level if 1378 the session description or media use multiple languages, in 1379 which case the order of the attributes indicates the order of 1380 importance of the various languages in the session or media 1381 from most important to least important. 1383 The "lang" attribute value must be a single RFC 3066 language 1384 tag in US-ASCII [9]. It is not dependent on the charset 1385 attribute. A "lang" attribute SHOULD be specified when a 1386 session is of sufficient scope to cross geographic boundaries 1387 where the language of recipients cannot be assumed, or where 1388 the session is in a different language from the locally assumed 1389 norm. 1391 a=framerate: 1393 This gives the maximum video frame rate in frames/sec. It is 1394 intended as a recommendation for the encoding of video data. 1395 Decimal representations of fractional values using the notation 1396 "." are allowed. It is a media-level 1397 attribute, defined only for video media, and it is not 1398 dependent on charset. 1400 a=quality: 1402 This gives a suggestion for the quality of the encoding as an 1403 integer value. The intention of the quality attribute for 1404 video is to specify a non-default trade-off between frame-rate 1405 and still-image quality. For video, the value is in the range 1406 0 to 10, with the following suggested meaning: 1408 10 - the best still-image quality the compression scheme 1409 can give. 1410 5 - the default behaviour given no quality suggestion. 1411 0 - the worst still-image quality the codec designer 1412 thinks is still usable. 1414 It is a media-level attribute, and it is not dependent on 1415 charset. 1417 a=fmtp: 1419 This attribute allows parameters that are specific to a 1420 particular format to be conveyed in a way that SDP does not 1421 have to understand them. The format must be one of the formats 1422 specified for the media. Format-specific parameters may be any 1423 set of parameters required to be conveyed by SDP and given 1424 unchanged to the media tool that will use this format. At most 1425 one instance of this attribute is allowed for each format. 1427 It is a media-level attribute, and it is not dependent on 1428 charset. 1430 7. Security Considerations 1432 SDP is frequently used with the Session Initiation Protocol [15] 1433 using the offer/answer model [17] to agree on parameters for unicast 1434 sessions. When used in this manner, the security considerations of 1435 those protocols apply. 1437 SDP is a session description format that describes multimedia 1438 sessions. Entities receiving and acting upon an SDP message SHOULD 1439 be aware that a session description cannot be trusted unless it has 1440 been obtained by an authenticated transport protocol from a known and 1441 trusted source. Many different transport protocols may be used to 1442 distribute session description, and the nature of the authentication 1443 will differ from transport to transport. For some transports, 1444 security features are often not deployed. In case a session 1445 description has not been obtained in a trusted manner, the endpoint 1446 SHOULD exercise care because, among other attacks, the media sessions 1447 received may not be the intended ones, the destination where media is 1448 sent to may not be the expected one, any of the parameters of the 1449 session may be incorrect, or the media security may be compromised. 1450 It is up to the endpoint to make a sensible decision taking into 1451 account the security risks of the application and the user 1452 preferences and may decide to ask the user whether or not to accept 1453 the session. 1455 One transport that can be used to distribute session descriptions is 1456 the Session Announcement Protocol (SAP). SAP provides both 1457 encryption and authentication mechanisms, but due to the nature of 1458 session announcements it is likely that there are many occasions 1459 where the originator of a session announcement cannot be 1460 authenticated because the originator is previously unknown to the 1461 receiver of the announcement and because no common public key 1462 infrastructure is available. 1464 On receiving a session description over an unauthenticated transport 1465 mechanism or from an untrusted party, software parsing the session 1466 should take a few precautions. Session descriptions contain 1467 information required to start software on the receiver's system. 1468 Software that parses a session description MUST NOT be able to start 1469 other software except that which is specifically configured as 1470 appropriate software to participate in multimedia sessions. It is 1471 normally considered inappropriate for software parsing a session 1472 description to start, on a user's system, software that is 1473 appropriate to participate in multimedia sessions, without the user 1474 first being informed that such software will be started and giving 1475 the user's consent. Thus, a session description arriving by session 1476 announcement, email, session invitation, or WWW page MUST NOT deliver 1477 the user into an interactive multimedia session unless the user has 1478 explicitly pre-authorised such action. As it is not always simple to 1479 tell whether or not a session is interactive, applications that are 1480 unsure should assume sessions are interactive. 1482 In this specification, there are no attributes that would allow the 1483 recipient of a session description to be informed to start multimedia 1484 tools in a mode where they default to transmitting. Under some 1485 circumstances it might be appropriate to define such attributes. If 1486 this is done, an application parsing a session description containing 1487 such attributes SHOULD either ignore them or inform the user that 1488 joining this session will result in the automatic transmission of 1489 multimedia data. The default behaviour for an unknown attribute is 1490 to ignore it. 1492 In certain environments, it has become common for intermediary 1493 systems to intercept and analyse session descriptions contained 1494 within other signalling protocols. This is done for a range of 1495 purposes, including but not limited to opening holes in firewalls to 1496 allow media streams to pass, or to mark, prioritize, or block traffic 1497 selectively. In some cases, such intermediary systems may modify the 1498 session description, for example, to have the contents of the session 1499 description match NAT bindings dynamically created. These behaviours 1500 are NOT RECOMMENDED unless the session description is conveyed in 1501 such a manner that allows the intermediary system to conduct proper 1502 checks to establish the authenticity of the session description, and 1503 the authority of its source to establish such communication sessions. 1504 SDP by itself does not include sufficient information to enable these 1505 checks: they depend on the encapsulating protocol (e.g., SIP or 1506 RTSP). 1508 Use of the "k=" field poses a significant security risk, since it 1509 conveys session encryption keys in the clear. SDP MUST NOT be used 1510 to convey key material, unless it can be guaranteed that the channel 1511 over which the SDP is delivered is both private and authenticated. 1512 Moreover, the "k=" line provides no way to indicate or negotiate 1513 cryptographic key algorithms. As it provides for only a single 1514 symmetric key, rather than separate keys for confidentiality and 1515 integrity, its utility is severely limited. The use of the "k=" line 1516 is NOT RECOMMENDED, as discussed in Section 5.12. 1518 8. IANA Considerations 1520 8.1. The "application/sdp" Media Type 1522 One media type registration from RFC 4566 is to be updated, as 1523 defined below. 1525 To: ietf-types@iana.org 1526 Subject: Registration of media type "application/sdp" 1528 Type name: application 1530 Subtype name: sdp 1532 Required parameters: None. 1534 Optional parameters: None. 1536 Encoding considerations: 1537 SDP files are primarily UTF-8 format text. The "a=charset:" 1538 attribute may be used to signal the presence of other character 1539 sets in certain parts of an SDP file (see Section 6 of RFC 1540 XXXX). Arbitrary binary content cannot be directly 1541 represented in SDP. 1543 Security considerations: 1544 See Section 7 of RFC XXXX 1546 Interoperability considerations: 1547 See RFC XXXX 1549 Published specification: 1550 See RFC XXXX 1552 Applications which use this media type: 1553 Voice over IP, video teleconferencing, streaming media, instant 1554 messaging, among others. See also Section 3 of RFC XXXX. 1556 Additional information: 1558 Magic number(s): None. 1559 File extension(s): The extension ".sdp" is commonly used. 1560 Macintosh File Type Code(s): "sdp " 1562 Person & email address to contact for further information: 1563 Mark Handley 1564 Colin Perkins 1565 IETF MMUSIC working group 1567 Intended usage: COMMON 1569 Author/Change controller: 1570 Authors of RFC XXXX 1571 IETF MMUSIC working group delegated from the IESG 1573 8.2. Registration of Parameters 1575 There are seven field names that may be registered with IANA. Using 1576 the terminology in the SDP specification Backus-Naur Form (BNF), they 1577 are "media", "proto", "fmt", "att-field", "bwtype", "nettype", and 1578 "addrtype". 1580 8.2.1. Media Types ("media") 1582 The set of media types is intended to be small and SHOULD NOT be 1583 extended except under rare circumstances. The same rules should 1584 apply for media names as for top-level media content types, and where 1585 possible the same name should be registered for SDP as for MIME. For 1586 media other than existing top-level media content types, a Standards 1587 Track RFC MUST be produced for a new top-level content type to be 1588 registered, and the registration MUST provide good justification why 1589 no existing media name is appropriate (the "Standards Action" policy 1590 of RFC 2434 [8]. 1592 This memo registers the media types "audio", "video", "text", 1593 "application", and "message". 1595 Note: The media types "control" and "data" were listed as valid in an 1596 early version of this specification [6]; however, their semantics 1597 were never fully specified and they are not widely used. These media 1598 types have been removed in this specification, although they still 1599 remain valid media type capabilities for a SIP user agent as defined 1600 in RFC 3840 [24]. If these media types are considered useful in the 1601 future, a Standards Track RFC MUST be produced to document their use. 1602 Until that is done, applications SHOULD NOT use these types and 1603 SHOULD NOT declare support for them in SIP capabilities declarations 1604 (even though they exist in the registry created by RFC 3840). 1606 8.2.2. Transport Protocols ("proto") 1608 The "proto" field describes the transport protocol used. This SHOULD 1609 reference a standards-track protocol RFC. This memo registers three 1610 values: "RTP/AVP" is a reference to RTP [19] used under the RTP 1611 Profile for Audio and Video Conferences with Minimal Control [20] 1612 running over UDP/IP, "RTP/SAVP" is a reference to the Secure Real- 1613 time Transport Protocol [23], and "udp" indicates an unspecified 1614 protocol over UDP. 1616 If other RTP profiles are defined in the future, their "proto" name 1617 SHOULD be specified in the same manner. For example, an RTP profile 1618 whose short name is "XYZ" would be denoted by a "proto" field of 1619 "RTP/XYZ". 1621 New transport protocols SHOULD be registered with IANA. 1622 Registrations MUST reference an RFC describing the protocol. Such an 1623 RFC MAY be Experimental or Informational, although it is preferable 1624 that it be Standards Track. Registrations MUST also define the rules 1625 by which their "fmt" namespace is managed (see below). 1627 8.2.3. Media Formats ("fmt") 1629 Each transport protocol, defined by the "proto" field, has an 1630 associated "fmt" namespace that describes the media formats that may 1631 be conveyed by that protocol. Formats cover all the possible 1632 encodings that might want to be transported in a multimedia session. 1634 RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST 1635 use the payload type number as their "fmt" value. If the payload 1636 type number is dynamically assigned by this session description, an 1637 additional "rtpmap" attribute MUST be included to specify the format 1638 name and parameters as defined by the media type registration for the 1639 payload format. It is RECOMMENDED that other RTP profiles that are 1640 registered (in combination with RTP) as SDP transport protocols 1641 specify the same rules for the "fmt" namespace. 1643 For the "udp" protocol, new formats SHOULD be registered. Use of an 1644 existing media subtype for the format is encouraged. If no media 1645 subtype exists, it is RECOMMENDED that a suitable one be registered 1646 through the IETF process [30] by production of, or reference to, a 1647 standards-track RFC that defines the transport protocol for the 1648 format. 1650 For other protocols, formats MAY be registered according to the rules 1651 of the associated "proto" specification. 1653 Registrations of new formats MUST specify which transport protocols 1654 they apply to. 1656 8.2.4. Attribute Names ("att-field") 1658 Attribute field names ("att-field") MUST be registered with IANA and 1659 documented, because of noticeable issues due to conflicting 1660 attributes under the same name. Unknown attributes in SDP are simply 1661 ignored, but conflicting ones that fragment the protocol are a 1662 serious problem. 1664 New attribute registrations are accepted according to the 1665 "Specification Required" policy of RFC 2434, provided that the 1666 specification includes the following information: 1668 o contact name, email address, and telephone number 1670 o attribute name (as it will appear in SDP) 1672 o long-form attribute name in English 1674 o type of attribute (session level, media level, or both) 1676 o whether the attribute value is subject to the charset attribute 1678 o a one-paragraph explanation of the purpose of the attribute 1680 o a specification of appropriate attribute values for this attribute 1682 The above is the minimum that IANA will accept. Attributes that are 1683 expected to see widespread use and interoperability SHOULD be 1684 documented with a standards-track RFC that specifies the attribute 1685 more precisely. 1687 Submitters of registrations should ensure that the specification is 1688 in the spirit of SDP attributes, most notably that the attribute is 1689 platform independent in the sense that it makes no implicit 1690 assumptions about operating systems and does not name specific pieces 1691 of software in a manner that might inhibit interoperability. 1693 IANA has registered the following initial set of attribute names 1694 ("att-field" values), with definitions as in Section 6 of this memo 1695 (these definitions update those in RFC 4566): 1697 Name | Session or Media level? | Dependent on charset? 1698 ----------+-------------------------+---------------------- 1699 cat | Session | No 1700 keywds | Session | Yes 1701 tool | Session | No 1702 ptime | Media | No 1703 maxptime | Media | No 1704 rtpmap | Media | No 1705 recvonly | Either | No 1706 sendrecv | Either | No 1707 sendonly | Either | No 1708 inactive | Either | No 1709 orient | Media | No 1710 type | Session | No 1711 charset | Session | No 1712 sdplang | Either | No 1713 lang | Either | No 1714 framerate | Media | No 1715 quality | Media | No 1716 fmtp | Media | No 1718 8.2.5. Bandwidth Specifiers ("bwtype") 1720 A proliferation of bandwidth specifiers is strongly discouraged. 1722 New bandwidth specifiers ("bwtype" fields) MUST be registered with 1723 IANA. The submission MUST reference a standards-track RFC specifying 1724 the semantics of the bandwidth specifier precisely, and indicating 1725 when it should be used, and why the existing registered bandwidth 1726 specifiers do not suffice. 1728 IANA has registered the bandwidth specifiers "CT" and "AS" with 1729 definitions as in Section 5.8 of this memo (these definitions update 1730 those in RFC 4566). 1732 8.2.6. Network Types ("nettype") 1734 New network types (the "nettype" field) may be registered with IANA 1735 if SDP needs to be used in the context of non-Internet environments. 1736 Although these are not normally the preserve of IANA, there may be 1737 circumstances when an Internet application needs to interoperate with 1738 a non-Internet application, such as when gatewaying an Internet 1739 telephone call into the Public Switched Telephone Network (PSTN). 1740 The number of network types should be small and should be rarely 1741 extended. A new network type cannot be registered without 1742 registering at least one address type to be used with that network 1743 type. A new network type registration MUST reference an RFC that 1744 gives details of the network type and address type and specifies how 1745 and when they would be used. 1747 IANA has registered the network type "IN" to represent the Internet, 1748 with definition as in Sections 5.2 and 5.7 of this memo (these 1749 definitions update those in RFC 4566). 1751 8.2.7. Address Types ("addrtype") 1753 New address types ("addrtype") may be registered with IANA. An 1754 address type is only meaningful in the context of a network type, and 1755 any registration of an address type MUST specify a registered network 1756 type or be submitted along with a network type registration. A new 1757 address type registration MUST reference an RFC giving details of the 1758 syntax of the address type. Address types are not expected to be 1759 registered frequently. 1761 IANA has registered the address types "IP4" and "IP6" with 1762 definitions as in Sections 5.2 and 5.7 of this memo (these 1763 definitions update those in RFC 4566). 1765 8.2.8. Registration Procedure 1767 In the RFC documentation that registers SDP "media", "proto", "fmt", 1768 "bwtype", "nettype", and "addrtype" fields, the authors MUST include 1769 the following information for IANA to place in the appropriate 1770 registry: 1772 o contact name, email address, and telephone number 1774 o name being registered (as it will appear in SDP) 1776 o long-form name in English 1778 o type of name ("media", "proto", "fmt", "bwtype", "nettype", or 1779 "addrtype") 1781 o a one-paragraph explanation of the purpose of the registered name 1783 o a reference to the specification for the registered name (this 1784 will typically be an RFC number) 1786 IANA may refer any registration to the IESG for review, and may 1787 request revisions to be made before a registration will be made. 1789 8.3. Encryption Key Access Methods 1791 The IANA previously maintained a table of SDP encryption key access 1792 method ("enckey") names. This table is obsolete, since the "k=" line 1793 is not extensible. New registrations MUST NOT be accepted. 1795 9. SDP Grammar 1797 This section provides an Augmented BNF grammar for SDP. ABNF is 1798 defined in [4]. 1800 ; SDP Syntax 1801 session-description = proto-version 1802 origin-field 1803 session-name-field 1804 information-field 1805 uri-field 1806 email-fields 1807 phone-fields 1808 connection-field 1809 bandwidth-fields 1810 time-fields 1811 key-field 1812 attribute-fields 1813 media-descriptions 1815 proto-version = %x76 "=" 1*DIGIT CRLF 1816 ;this memo describes version 0 1818 origin-field = %x6f "=" username SP sess-id SP sess-version SP 1819 nettype SP addrtype SP unicast-address CRLF 1821 session-name-field = %x73 "=" text CRLF 1823 information-field = [%x69 "=" text CRLF] 1825 uri-field = [%x75 "=" uri CRLF] 1827 email-fields = *(%x65 "=" email-address CRLF) 1829 phone-fields = *(%x70 "=" phone-number CRLF) 1831 connection-field = [%x63 "=" nettype SP addrtype SP 1832 connection-address CRLF] 1833 ;a connection field must be present 1834 ;in every media description or at the 1835 ;session-level 1837 bandwidth-fields = *(%x62 "=" bwtype ":" bandwidth CRLF) 1839 time-fields = 1*( %x74 "=" start-time SP stop-time 1840 *(CRLF repeat-fields) CRLF) 1841 [zone-adjustments CRLF] 1843 repeat-fields = %x72 "=" repeat-interval SP typed-time 1844 1*(SP typed-time) 1846 zone-adjustments = %x7a "=" time SP ["-"] typed-time 1847 *(SP time SP ["-"] typed-time) 1849 key-field = [%x6b "=" key-type CRLF] 1851 attribute-fields = *(%x61 "=" attribute CRLF) 1853 media-descriptions = *( media-field 1854 information-field 1855 *connection-field 1856 bandwidth-fields 1857 key-field 1858 attribute-fields ) 1860 media-field = %x6d "=" media SP port ["/" integer] 1861 SP proto 1*(SP fmt) CRLF 1863 ; sub-rules of 'o=' 1864 username = non-ws-string 1865 ;pretty wide definition, but doesn't 1866 ;include space 1868 sess-id = 1*DIGIT 1869 ;should be unique for this username/host 1871 sess-version = 1*DIGIT 1873 nettype = token 1874 ;typically "IN" 1876 addrtype = token 1877 ;typically "IP4" or "IP6" 1879 ; sub-rules of 'u=' 1880 uri = URI-reference 1881 ; see RFC 3986 1883 ; sub-rules of 'e=', see RFC 2822 for definitions 1884 email-address = address-and-comment / dispname-and-address 1885 / addr-spec 1886 address-and-comment = addr-spec 1*SP "(" 1*email-safe ")" 1887 dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">" 1889 ; sub-rules of 'p=' 1890 phone-number = phone *SP "(" 1*email-safe ")" / 1891 1*email-safe "<" phone ">" / 1892 phone 1894 phone = ["+"] DIGIT 1*(SP / "-" / DIGIT) 1896 ; sub-rules of 'c=' 1897 connection-address = multicast-address / unicast-address 1899 ; sub-rules of 'b=' 1900 bwtype = token 1902 bandwidth = 1*DIGIT 1904 ; sub-rules of 't=' 1905 start-time = time / "0" 1907 stop-time = time / "0" 1908 time = POS-DIGIT 9*DIGIT 1909 ; Decimal representation of NTP time in 1910 ; seconds since 1900. The representation 1911 ; of NTP time is an unbounded length field 1912 ; containing at least 10 digits. Unlike the 1913 ; 64-bit representation used elsewhere, time 1914 ; in SDP does not wrap in the year 2036. 1916 ; sub-rules of 'r=' and 'z=' 1917 repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] 1919 typed-time = 1*DIGIT [fixed-len-time-unit] 1921 fixed-len-time-unit = %x64 / %x68 / %x6d / %x73 1923 ; sub-rules of 'k=' 1924 key-type = %x70 %x72 %x6f %x6d %x70 %x74 / ; "prompt" 1925 %x63 %x6c %x65 %x61 %x72 ":" text / ; "clear:" 1926 %x62 %x61 %x73 %x65 "64:" base64 / ; "base64:" 1927 %x75 %x72 %x69 ":" uri ; "uri:" 1929 base64 = *base64-unit [base64-pad] 1930 base64-unit = 4base64-char 1931 base64-pad = 2base64-char "==" / 3base64-char "=" 1932 base64-char = ALPHA / DIGIT / "+" / "/" 1934 ; sub-rules of 'a=' 1935 attribute = (att-field ":" att-value) / att-field 1937 att-field = token 1939 att-value = byte-string 1941 ; sub-rules of 'm=' 1942 media = token 1943 ;typically "audio", "video", "text", or 1944 ;"application" 1946 fmt = token 1947 ;typically an RTP payload type for audio 1948 ;and video media 1950 proto = token *("/" token) 1951 ;typically "RTP/AVP" or "udp" 1953 port = 1*DIGIT 1955 ; generic sub-rules: addressing 1956 unicast-address = IP4-address / IP6-address / FQDN / extn-addr 1958 multicast-address = IP4-multicast / IP6-multicast / FQDN 1959 / extn-addr 1961 IP4-multicast = m1 3( "." decimal-uchar ) 1962 "/" ttl [ "/" integer ] 1963 ; IPv4 multicast addresses may be in the 1964 ; range 224.0.0.0 to 239.255.255.255 1966 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / 1967 ("23" DIGIT ) 1969 IP6-multicast = IP6-address [ "/" integer ] 1970 ; IPv6 address starting with FF 1972 ttl = (POS-DIGIT *2DIGIT) / "0" 1974 FQDN = 4*(alpha-numeric / "-" / ".") 1975 ; fully qualified domain name as specified 1976 ; in RFC 1035 (and updates) 1978 IP4-address = b1 3("." decimal-uchar) 1980 b1 = decimal-uchar 1981 ; less than "224" 1983 IP6-address = 6( h16 ":" ) ls32 1984 / "::" 5( h16 ":" ) ls32 1985 / [ h16 ] "::" 4( h16 ":" ) ls32 1986 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 1987 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 1988 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 1989 / [ *4( h16 ":" ) h16 ] "::" ls32 1990 / [ *5( h16 ":" ) h16 ] "::" h16 1991 / [ *6( h16 ":" ) h16 ] "::" 1993 h16 = 1*4HEXDIG 1995 ls32 = ( h16 ":" h16 ) / IP4-address 1997 ; Generic for other address families 1998 extn-addr = non-ws-string 2000 ; generic sub-rules: datatypes 2001 text = byte-string 2002 ;default is to interpret this as UTF8 text. 2003 ;ISO 8859-1 requires "a=charset:ISO-8859-1" 2004 ;session-level attribute to be used 2006 byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) 2007 ;any byte except NUL, CR, or LF 2009 non-ws-string = 1*(VCHAR/%x80-FF) 2010 ;string of visible characters 2012 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 2013 / %x41-5A / %x5E-7E 2015 token = 1*(token-char) 2017 email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF 2018 ;any byte except NUL, CR, LF, or the quoting 2019 ;characters ()<> 2021 integer = POS-DIGIT *DIGIT 2023 ; generic sub-rules: primitives 2024 alpha-numeric = ALPHA / DIGIT 2026 POS-DIGIT = %x31-39 ; 1 - 9 2028 decimal-uchar = DIGIT 2029 / POS-DIGIT DIGIT 2030 / ("1" 2*(DIGIT)) 2031 / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) 2032 / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) 2034 ; external references: 2035 ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 4234 2036 ; URI-reference: from RFC 3986 2037 ; addr-spec: from RFC 2822 2039 10. Summary of Changes from RFC 4566 2041 The ABNF rule for IP6-address has been corrected. As a result, the 2042 ABNF rule for IP6-multicast has changed, and the (now unused) rules 2043 for hexpart, hexseq, and hex4 have been removed. 2045 11. Acknowledgements 2047 Many people in the IETF Multiparty Multimedia Session Control 2048 (MMUSIC) working group have made comments and suggestions 2049 contributing to this document. In particular, we would like to thank 2050 Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross 2051 Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna, 2052 Jonathan Lennox, Keith Drage, Sean Olson, Bernie Hoeneisen, Jonathan 2053 Rosenberg, John Elwell, Flemming Andreasen, Jon Peterson, and Spencer 2054 Dawkins. 2056 12. References 2058 12.1. Normative References 2060 [1] Mockapetris, P., "Domain names - concepts and facilities", 2061 STD 13, RFC 1034, November 1987. 2063 [2] Mockapetris, P., "Domain names - implementation and 2064 specification", STD 13, RFC 1035, November 1987. 2066 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2067 Levels", BCP 14, RFC 2119, March 1997. 2069 [4] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2070 Specifications: ABNF", RFC 4234, October 2005. 2072 [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 2073 STD 63, RFC 3629, November 2003. 2075 [6] Handley, M. and V. Jacobson, "SDP: Session Description 2076 Protocol", RFC 2327, April 1998. 2078 [7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2079 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 2080 January 2005. 2082 [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2083 Considerations Section in RFCs", BCP 26, RFC 2434, 2084 October 1998. 2086 [9] Alvestrand, H., "Tags for the Identification of Languages", 2087 BCP 47, RFC 3066, January 2001. 2089 [10] Faltstrom, P., Hoffman, P., and A. Costello, 2090 "Internationalizing Domain Names in Applications (IDNA)", 2091 RFC 3490, March 2003. 2093 [11] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 2094 RFC 3548, July 2003. 2096 [12] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2097 Description Protocol", RFC 4566, July 2006. 2099 12.2. Informative References 2101 [13] Mills, D., "Network Time Protocol (Version 3) Specification, 2102 Implementation", RFC 1305, March 1992. 2104 [14] Handley, M., Perkins, C., and E. Whelan, "Session Announcement 2105 Protocol", RFC 2974, October 2000. 2107 [15] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2108 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 2109 Session Initiation Protocol", RFC 3261, June 2002. 2111 [16] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming 2112 Protocol (RTSP)", RFC 2326, April 1998. 2114 [17] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2115 Session Description Protocol (SDP)", RFC 3264, June 2002. 2117 [18] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, 2118 "Grouping of Media Lines in the Session Description Protocol 2119 (SDP)", RFC 3388, December 2002. 2121 [19] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 2122 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 2123 RFC 3550, July 2003. 2125 [20] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 2126 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 2128 [21] Casner, S., "Session Description Protocol (SDP) Bandwidth 2129 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, 2130 July 2003. 2132 [22] Huitema, C., "Real Time Control Protocol (RTCP) attribute in 2133 Session Description Protocol (SDP)", RFC 3605, October 2003. 2135 [23] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2136 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2137 RFC 3711, March 2004. 2139 [24] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating 2140 User Agent Capabilities in the Session Initiation Protocol 2141 (SIP)", RFC 3840, August 2004. 2143 [25] Westerlund, M., "A Transport Independent Bandwidth Modifier for 2144 the Session Description Protocol (SDP)", RFC 3890, 2145 September 2004. 2147 [26] International Telecommunication Union, "H.323 extended for 2148 loosely coupled conferences", ITU Recommendation H.332, 2149 September 1998. 2151 [27] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 2152 Norrman, "Key Management Extensions for Session Description 2153 Protocol (SDP) and Real Time Streaming Protocol (RTSP)", 2154 RFC 4567, July 2006. 2156 [28] Andreasen, F., Baugher, M., and D. Wing, "Session Description 2157 Protocol (SDP) Security Descriptions for Media Streams", 2158 RFC 4568, July 2006. 2160 [29] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 2162 [30] Freed, N. and J. Klensin, "Media Type Specifications and 2163 Registration Procedures", BCP 13, RFC 4288, December 2005. 2165 Authors' Addresses 2167 Mark Handley 2168 University College London 2169 Department of Computer Science 2170 Gower Street 2171 London WC1E 6BT 2172 UK 2174 EMail: M.Handley@cs.ucl.ac.uk 2176 Van Jacobson 2177 Packet Design 2178 2465 Latham Street 2179 Mountain View, CA 94040 2180 USA 2182 EMail: van@packetdesign.com 2184 Colin Perkins 2185 University of Glasgow 2186 Department of Computing Science 2187 17 Lilybank Gardens 2188 Glasgow G12 8QQ 2189 UK 2191 EMail: csp@csperkins.org 2193 Full Copyright Statement 2195 Copyright (C) The IETF Trust (2008). 2197 This document is subject to the rights, licenses and restrictions 2198 contained in BCP 78, and except as set forth therein, the authors 2199 retain all their rights. 2201 This document and the information contained herein are provided on an 2202 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2203 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2204 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2205 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2206 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2207 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2209 Intellectual Property 2211 The IETF takes no position regarding the validity or scope of any 2212 Intellectual Property Rights or other rights that might be claimed to 2213 pertain to the implementation or use of the technology described in 2214 this document or the extent to which any license under such rights 2215 might or might not be available; nor does it represent that it has 2216 made any independent effort to identify any such rights. Information 2217 on the procedures with respect to rights in RFC documents can be 2218 found in BCP 78 and BCP 79. 2220 Copies of IPR disclosures made to the IETF Secretariat and any 2221 assurances of licenses to be made available, or the result of an 2222 attempt made to obtain a general license or permission for the use of 2223 such proprietary rights by implementers or users of this 2224 specification can be obtained from the IETF on-line IPR repository at 2225 http://www.ietf.org/ipr. 2227 The IETF invites any interested party to bring to its attention any 2228 copyrights, patents or patent applications, or other proprietary 2229 rights that may cover technology that may be required to implement 2230 this standard. Please address the information to the IETF at 2231 ietf-ipr@ietf.org. 2233 Acknowledgement 2235 Funding for the RFC Editor function is provided by the IETF 2236 Administrative Support Activity (IASA).