idnits 2.17.1 draft-ietf-mmusic-sdp-new-26.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 on line 2233. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2210. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2217. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2223. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 RFC3266, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC2327, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (January 24, 2006) is 6657 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 2234 (ref. '4') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2279 (ref. '5') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2327 (ref. '6') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2396 (ref. '7') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2434 (ref. '8') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2732 (ref. '9') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 3066 (ref. '10') (Obsoleted by RFC 4646, RFC 4647) ** Obsolete normative reference: RFC 3266 (ref. '11') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 3490 (ref. '12') (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 3548 (ref. '13') (Obsoleted by RFC 4648) -- Obsolete informational reference (is this intentional?): RFC 1305 (ref. '14') (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '17') (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 3388 (ref. '19') (Obsoleted by RFC 5888) == Outdated reference: A later version (-15) exists of draft-ietf-mmusic-kmgmt-ext-12 == Outdated reference: A later version (-12) exists of draft-ietf-mmusic-sdescriptions-07 Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 12 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: 2327, 3266 (if V. Jacobson 5 approved) Packet Design 6 Expires: July 28, 2006 C. Perkins 7 University of Glasgow 8 January 24, 2006 10 SDP: Session Description Protocol 11 draft-ietf-mmusic-sdp-new-26.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 July 28, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . . 4 54 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 4 55 3.2. Streaming media . . . . . . . . . . . . . . . . . . . . . 4 56 3.3. Email and the World Wide Web . . . . . . . . . . . . . . . 4 57 3.4. Multicast Session Announcement . . . . . . . . . . . . . . 4 58 4. Requirements and Recommendations . . . . . . . . . . . . . . . 5 59 4.1. Media and Transport Information . . . . . . . . . . . . . 6 60 4.2. Timing Information . . . . . . . . . . . . . . . . . . . . 6 61 4.3. Private Sessions . . . . . . . . . . . . . . . . . . . . . 7 62 4.4. Obtaining Further Information about a Session . . . . . . 7 63 4.5. Categorisation . . . . . . . . . . . . . . . . . . . . . . 7 64 4.6. Internationalisation . . . . . . . . . . . . . . . . . . . 7 65 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . . 7 66 5.1. Protocol Version ("v=") . . . . . . . . . . . . . . . . . 10 67 5.2. Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 10 68 5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 12 69 5.4. Session Information ("i=") . . . . . . . . . . . . . . . . 12 70 5.5. URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 12 71 5.6. Email Address and Phone Number ("e=" and "p=") . . . . . . 13 72 5.7. Connection Data ("c=") . . . . . . . . . . . . . . . . . . 13 73 5.8. Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 15 74 5.9. Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 16 75 5.10. Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . 17 76 5.11. Time Zones ("z=") . . . . . . . . . . . . . . . . . . . . 18 77 5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . . 19 78 5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 20 79 5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 21 80 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . . 24 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 83 8.1. The "application/sdp" media type . . . . . . . . . . . . . 32 84 8.2. Registration of Parameters . . . . . . . . . . . . . . . . 34 85 8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 38 86 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 39 87 10. Summary of Changes from RFC 2327 . . . . . . . . . . . . . . . 44 88 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 90 12.1. Normative References . . . . . . . . . . . . . . . . . . . 45 91 12.2. Informative References . . . . . . . . . . . . . . . . . . 46 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 93 Intellectual Property and Copyright Statements . . . . . . . . . . 49 95 1. Introduction 97 When initiating multimedia teleconferences, voice-over-IP calls, 98 streaming video, or other sessions, there is a requirement to convey 99 media details, transport addresses, and other session description 100 metadata to the participants. 102 SDP provides a standard representation for such information, 103 irrespective of how that information is transported. SDP is purely a 104 format for session description - it does not incorporate a transport 105 protocol, and is intended to use different transport protocols as 106 appropriate, including the Session Announcement Protocol [15], 107 Session Initiation Protocol [16], Real-Time Streaming Protocol [17], 108 electronic mail using the MIME extensions, and the Hypertext 109 Transport Protocol. 111 SDP is intended to be general purpose so that it can be used in a 112 wide range of network environments and applications. However, it is 113 not intended to support negotiation of session content or media 114 encodings: this is viewed as outside the scope of session 115 description. 117 This memo obsoletes RFC 2327 [6] and RFC 3266 [11]. Section 10 118 outlines the changes introduced in this memo. 120 2. Glossary of Terms 122 The following terms are used in this document, and have specific 123 meaning within the context of this document. 125 Conference: A multimedia conference is a set of two or more 126 communicating users along with the software they are using to 127 communicate. 129 Session: A multimedia session is a set of multimedia senders and 130 receivers and the data streams flowing from senders to receivers. 131 A multimedia conference is an example of a multimedia session. 133 Session Description: A well defined format for conveying sufficient 134 information to discover and participate in a multimedia session. 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [3]. 140 3. Examples of SDP Usage 142 3.1. Session Initiation 144 The Session Initiation Protocol, SIP [16] is an application layer 145 control protocol for creating, modifying and terminating sessions 146 such as Internet multimedia conferences, Internet telephone calls and 147 multimedia distribution. The SIP messages used to create sessions 148 carry session descriptions which allow participants to agree on a set 149 of compatible media types. These session descriptions are commonly 150 formatted using SDP. When used with SIP, the offer/answer model [18] 151 provides a limited framework for negotiation using SDP. 153 3.2. Streaming media 155 The Real Time Streaming Protocol, RTSP [17], is an application-level 156 protocol for control over the delivery of data with real-time 157 properties. RTSP provides an extensible framework to enable 158 controlled, on-demand delivery of real-time data, such as audio and 159 video. An RTSP client and server negotiate an appropriate set of 160 parameters for media delivery, partially using SDP syntax to describe 161 those parameters. 163 3.3. Email and the World Wide Web 165 Alternative means of conveying session descriptions include 166 electronic mail and the World Wide Web. For both email and WWW 167 distribution, the MIME content type "application/sdp" is used. This 168 enables the automatic launching of applications for participation in 169 the session from the WWW client or mail reader in a standard manner. 171 Note that announcements of multicast sessions made only via email or 172 the World Wide Web (WWW) do not have the property that the receiver 173 of a session announcement can necessarily receive the session because 174 the multicast sessions may be restricted in scope, and access to the 175 WWW server or reception of email is possible outside this scope. 177 3.4. Multicast Session Announcement 179 In order to assist the advertisement of multicast multimedia 180 conferences and other multicast sessions, and to communicate the 181 relevant session setup information to prospective participants, a 182 distributed session directory may be used. An instance of such a 183 session directory periodically sends packets containing a description 184 of the session to a well known multicast group. These advertisements 185 are received by other session directories such that potential remote 186 participants can use the session description to start the tools 187 required to participate in the session. 189 One protocol used to implement such a distributed directory is the 190 Session Announcement Protocol, SAP [15]. SDP provides the 191 recommended session description format for such session 192 announcements. 194 4. Requirements and Recommendations 196 The purpose of SDP is to convey information about media streams in 197 multimedia sessions to allow the recipients of a session description 198 to participate in the session. SDP is primarily intended for use in 199 an internetwork, although it is sufficiently general that it can 200 describe conferences in other network environments. Media streams 201 can be many-to-many. Sessions need not be continually active. 203 Thus far, multicast based sessions on the Internet have differed from 204 many other forms of conferencing in that anyone receiving the traffic 205 can join the session (unless the session traffic is encrypted). In 206 such an environment, SDP serves two primary purposes. It is a means 207 to communicate the existence of a session, and is a means to convey 208 sufficient information to enable joining and participating in the 209 session. In a unicast environment, only the latter purpose is likely 210 to be relevant. 212 An SDP session description includes: 214 o Session name and purpose 216 o Time(s) the session is active 218 o The media comprising the session 220 o Information needed to receive those media (addresses, ports, 221 formats and so on) 223 As resources necessary to participate in a session may be limited, 224 some additional information may also be desirable: 226 o Information about the bandwidth to be used by the session 228 o Contact information for the person responsible for the session 230 In general, SDP must convey sufficient information to enable 231 applications to join a session (with the possible exception of 232 encryption keys), and to announce the resources to be used to any 233 non-participants that may need to know (this latter feature is 234 primarily useful when SDP is used with a multicast session 235 announcement protocol). 237 4.1. Media and Transport Information 239 An SDP session description includes the following media information: 241 o The type of media (video, audio, etc.) 243 o The transport protocol (RTP/UDP/IP, H.320, etc.) 245 o The format of the media (H.261 video, MPEG video, etc.) 247 In addition to media format and transport protocol, SDP conveys 248 address and port details. For an IP multicast session, these 249 comprise: 251 o The multicast group address for media 253 o The transport port for media 255 This address and port are the destination address and destination 256 port of the multicast stream, whether being sent, received, or both. 258 For unicast IP sessions, the following are conveyed: 260 o The remote address for media 262 o The remote transport port for media 264 The semantics of this address and port depend on the media and 265 transport protocol defined. By default, this SHOULD be the remote 266 address and remote port to which data is sent. Some media types may 267 redefine this behaviour, but this is NOT RECOMMENDED since it 268 complicates implementations (including middleboxes that must parse 269 the addresses to open NAT or firewall pinholes). 271 4.2. Timing Information 273 Sessions may either be bounded or unbounded in time. Whether or not 274 they are bounded, they may be only active at specific times. SDP can 275 convey: 277 o An arbitrary list of start and stop times bounding the session 279 o For each bound, repeat times such as "every Wednesday at 10am for 280 one hour" 282 This timing information is globally consistent, irrespective of local 283 time zone or daylight saving time (see Section 5.9). 285 4.3. Private Sessions 287 It is possible to create both public sessions and private sessions. 288 SDP itself does not distinguish between these; private sessions are 289 typically conveyed by encrypting the session description during 290 distribution. The details of how encryption is performed are 291 dependent on the mechanism used to convey SDP; mechanisms are 292 currently defined for SDP transported using SAP [15] and SIP [16], 293 others may be defined in future. 295 If a session announcement is private it is possible to use that 296 private announcement to convey encryption keys necessary to decode 297 each of the media in a conference, including enough information to 298 know which encryption scheme is used for each media. 300 4.4. Obtaining Further Information about a Session 302 A session description should convey enough information to decide 303 whether or not to participate in a session. SDP may include 304 additional pointers in the form of Universal Resources Identifiers 305 (URIs) for more information about the session. 307 4.5. Categorisation 309 When many session descriptions are being distributed by SAP, or any 310 other advertisement mechanism, it may be desirable to filter session 311 announcements that are of interest from those that are not. SDP 312 supports a categorisation mechanism for sessions that is capable of 313 being automated (the "a=cat:" attribute; see Section 6). 315 4.6. Internationalisation 317 The SDP specification recommends the use of the ISO 10646 character 318 sets in the UTF-8 encoding [5] to allow many different languages to 319 be represented. However, to assist in compact representations, SDP 320 also allows other character sets such as ISO 8859-1 to be used when 321 desired. Internationalisation only applies to free-text fields 322 (session name and background information), and not to SDP as a whole. 324 5. SDP Specification 326 An SDP session description is denoted by the MIME content type 327 "application/sdp" (See Section 8). 329 An SDP session description is entirely textual using the ISO 10646 330 character set in UTF-8 encoding. SDP field names and attribute names 331 use only the US-ASCII subset of UTF-8, but textual fields and 332 attribute values MAY use the full ISO 10646 character set. Field and 333 attribute values which use the full UTF-8 character set are never 334 directly compared, hence there is no requirement for UTF-8 335 normalisation. The textual form, as opposed to a binary encoding 336 such as ASN.1 or XDR, was chosen to enhance portability, to enable a 337 variety of transports to be used, and to allow flexible, text-based 338 toolkits to be used to generate and process session descriptions. 339 However, since SDP may be used in environments where the maximum 340 permissible size of a session description is limited, the encoding is 341 deliberately compact. Also, since announcements may be transported 342 via very unreliable means or damaged by an intermediate caching 343 server, the encoding was designed with strict order and formatting 344 rules so that most errors would result in malformed session 345 announcements which could be detected easily and discarded. This 346 also allows rapid discarding of encrypted session announcements for 347 which a receiver does not have the correct key. 349 An SDP session description consists of a number of lines of text of 350 the form: 352 = 354 where MUST be exactly one case-significant character and 355 is structured text whose format depends on . In 356 general is either a number of fields delimited by a single 357 space character, or a free format string. Whitespace MUST NOT be 358 used either side of the "=" sign. 360 An SDP session description consists of a session-level section 361 followed by zero or more media-level sections. The session-level 362 part starts with a "v=" line and continues to the first media-level 363 section. The media description starts with an "m=" line and 364 continues to the next media description or end of the whole session 365 description. In general, session-level values are the default for 366 all media unless overridden by an equivalent media-level value. 368 Some lines in each description are REQUIRED and some are OPTIONAL but 369 all MUST appear in exactly the order given here (the fixed order 370 greatly enhances error detection and allows for a simple parser). 371 OPTIONAL items are marked with a "*". 373 Session description 374 v= (protocol version) 375 o= (owner/creator and session identifier) 376 s= (session name) 377 i=* (session information) 378 u=* (URI of description) 379 e=* (email address) 380 p=* (phone number) 381 c=* (connection information - not required if included in 382 all media) 383 b=* (zero or more bandwidth information lines) 384 One or more time descriptions ("t=" and "r=" lines, see below) 385 z=* (time zone adjustments) 386 k=* (encryption key) 387 a=* (zero or more session attribute lines) 388 Zero or more media descriptions 390 Time description 391 t= (time the session is active) 392 r=* (zero or more repeat times) 394 Media description, if present 395 m= (media name and transport address) 396 i=* (media title) 397 c=* (connection information - optional if included at 398 session-level) 399 b=* (zero or more bandwidth information lines) 400 k=* (encryption key) 401 a=* (zero or more media attribute lines) 403 The set of type letters is deliberately small and not intended to be 404 extensible -- an SDP parser MUST completely ignore any session 405 description that contains a type letter that it does not understand. 406 The attribute mechanism ("a=" described below) is the primary means 407 for extending SDP and tailoring it to particular applications or 408 media. Some attributes (the ones listed in Section 6 of this memo) 409 have a defined meaning, but others may be added on an application-, 410 media- or session-specific basis. An SDP parser MUST ignore any 411 attribute it doesn't understand. 413 An SDP session description may contain URIs which reference external 414 content in the "u=", "k=" and "a=" lines. These URIs may be 415 dereferenced in some cases, making the session description non-self 416 contained. 418 The connection ("c=") and attribute ("a=") information in the 419 session-level section applies to all the media of that session unless 420 overridden by connection information or an attribute of the same name 421 in the media description. For instance, in the example below, each 422 media behaves as if it were given a "recvonly" attribute. 424 An example SDP description is: 426 v=0 427 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 428 s=SDP Seminar 429 i=A Seminar on the session description protocol 430 u=http://www.example.com/seminars/sdp.pdf 431 e=j.doe@example.com (Jane Doe) 432 c=IN IP4 224.2.17.12/127 433 t=2873397496 2873404696 434 a=recvonly 435 m=audio 49170 RTP/AVP 0 436 m=video 51372 RTP/AVP 99 437 a=rtpmap:99 h263-1998/90000 439 Text fields such as the session name and information are octet 440 strings which may contain any octet with the exceptions of 0x00 441 (Nul), 0x0a (ASCII newline) and 0x0d (ASCII carriage return). The 442 sequence CRLF (0x0d0a) is used to end a record, although parsers 443 SHOULD be tolerant and also accept records terminated with a single 444 newline character. If the "a=charset" attribute is not present, 445 these octet strings MUST be interpreted as containing ISO-10646 446 characters in UTF-8 encoding (the presence of the "a=charset" 447 attribute may force some fields to be interpreted differently). 449 A session description can contain domain names in the "o=", "u=", 450 "e=", "c=" and "a=" lines. Any domain name used in SDP MUST comply 451 with [1], [2]. Internationalised domain names (IDNs) MUST be 452 represented using the ASCII Compatible Encoding (ACE) form defined in 453 [12] and MUST NOT be directly represented in UTF-8 or any other 454 encoding (this requirement is for compatibility with RFC 2327 and 455 other SDP-related standards, which predate the development of 456 internationalized domain names). 458 5.1. Protocol Version ("v=") 460 v=0 462 The "v=" field gives the version of the Session Description Protocol. 463 This memo defines version 0. There is no minor version number. 465 5.2. Origin ("o=") 467 o= 468 470 The "o=" field gives the originator of the session (her username and 471 the address of the user's host) plus a session identifier and version 472 number: 474 is the user's login on the originating host, or it is "-" 475 if the originating host does not support the concept of user ids. 476 The MUST NOT contain spaces. 478 is a numeric string such that the tuple of , 479 , , and form a 480 globally unique identifier for the session. The method of 481 allocation is up to the creating tool, but it has been 482 suggested that a Network Time Protocol (NTP) format timestamp be 483 used to ensure uniqueness [14]. 485 is a version number for this session description. Its 486 usage is up to the creating tool, so long as is 487 increased when a modification is made to the session data. Again, 488 it is RECOMMENDED that an NTP format timestamp is used. 490 is a text string giving the type of network. Initially 491 "IN" is defined to have the meaning "Internet", but other values 492 MAY be registered in future (see Section 8). 494 is a text string giving the type of the address that 495 follows. Initially "IP4" and "IP6" are defined, but other values 496 MAY be registered in future (see Section 8). 498 is the address of the machine from which the 499 session was created. For an address type of IP4, this is either 500 the fully-qualified domain name of the machine, or the dotted- 501 decimal representation of the IP version 4 address of the machine. 502 For an address type of IP6, this is either the fully-qualified 503 domain name of the machine, or the compressed textual 504 representation of the IP version 6 address of the machine. For 505 both IP4 and IP6, the fully-qualified domain name is the form that 506 SHOULD be given unless this is unavailable, in which case the 507 globally unique address MAY be substituted. A local IP address 508 MUST NOT be used in any context where the SDP description might 509 leave the scope in which the address is meaningful (for example, a 510 local address MUST NOT be included in an application-level 511 referral that might leave the scope). 513 In general, the "o=" field serves as a globally unique identifier for 514 this version of this session description, and the subfields excepting 515 the version taken together identify the session irrespective of any 516 modifications. 518 For privacy reasons, it is sometimes desirable to obfuscate the 519 username and IP address of the session originator. If this is a 520 concern, an arbitrary and private MAY be 521 chosen to populate the "o=" field, provided these are selected in a 522 manner that does not affect the global uniqueness of the field. 524 5.3. Session Name ("s=") 526 s= 528 The "s=" field is the textual session name. There MUST be one and 529 only one "s=" field per session description. The "s=" field MUST NOT 530 be empty and SHOULD contain ISO 10646 characters (but see also the 531 "a=charset" attribute). If a session has no meaningful name, the 532 value "s= " SHOULD be used (i.e. a single space as the session name). 534 5.4. Session Information ("i=") 536 i= 538 The "i=" field provides textual information about the session. There 539 MUST be at most one session-level "i=" field per session description, 540 and at most one "i=" field per media. If the "a=charset" attribute 541 is present, it specifies the character set used in the "i=" field. 542 If the "a=charset" attribute is not present, the "i=" field MUST 543 contain ISO 10646 characters in UTF-8 encoding. 545 A single "i=" field MAY also be used for each media definition. In 546 media definitions, "i=" fields are primarily intended for labelling 547 media streams. As such, they are most likely to be useful when a 548 single session has more than one distinct media stream of the same 549 media type. An example would be two different whiteboards, one for 550 slides and one for feedback and questions. 552 The "i=" field is intended to provide a free-form human readable 553 description of the session or the purpose of a media stream. It is 554 not suitable for parsing by automata. 556 5.5. URI ("u=") 558 u= 560 A URI is a Universal Resource Identifier as used by WWW clients [7], 561 [9]. The URI should be a pointer to additional information about the 562 session. This field is OPTIONAL, but if it is present it MUST be 563 specified before the first media field. No more than one URI field 564 is allowed per session description. 566 5.6. Email Address and Phone Number ("e=" and "p=") 568 e= 569 p= 571 The "e=" and "p=" lines specify contact information for the person 572 responsible for the conference. This is not necessarily the same 573 person that created the conference announcement. 575 Inclusion of an email address or phone number is OPTIONAL. Note that 576 the previous version of SDP specified that either an email field or a 577 phone field MUST be specified, but this was widely ignored. The 578 change brings the specification into line with common usage. 580 If the email address or phone number are present, they MUST be 581 specified before the first media field. More than one email or phone 582 field can be given for a session description. 584 Phone numbers SHOULD be given in the form of an international public 585 telecommunication number (see ITU-T Recommendation E.164) preceded by 586 a "+". Spaces and hyphens may be used to split up a phone field to 587 aid readability if desired. For example: 589 p=+1 617 555-6011 591 Both email addresses and phone numbers can have an OPTIONAL free text 592 string associated with them, normally giving the name of the person 593 who may be contacted. This MUST be enclosed in parenthesis if it is 594 present. For example: 596 e=j.doe@example.com (Jane Doe) 598 The alternative RFC 2822 name quoting convention is also allowed for 599 both email addresses and phone numbers. For example: 601 e=Jane Doe 603 The free text string SHOULD be in the ISO-10646 character set with 604 UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if 605 the appropriate session-level "a=charset" attribute is set. 607 5.7. Connection Data ("c=") 609 c= 611 The "c=" field contains connection data. 613 A session description MUST contain either at least one "c=" field in 614 each media description or a single "c=" field at the session level. 615 It MAY contain a single session-level "c=" field and additional "c=" 616 field(s) per media description, in which case the per-media values 617 override the session-level settings for the respective media. 619 The first sub-field ("") is the network type, which is a 620 text string giving the type of network. Initially "IN" is defined to 621 have the meaning "Internet", but other values MAY be registered in 622 the future (see Section 8). 624 The second sub-field ("") is the address type. This allows 625 SDP to be used for sessions that are not IP based. This memo only 626 defines IP4 and IP6, but other values MAY be registered in the future 627 (see Section 8). 629 The third sub-field ("") is the connection 630 address. OPTIONAL sub-fields MAY be added after the connection 631 address depending on the value of the field. 633 When the is IP4 and IP6, the connection address is defined 634 as follows: 636 o If the session is multicast, the connection address will be an IP 637 multicast group address. If the session is not multicast, then 638 the connection address contains the unicast IP address of the 639 expected data source or data relay or data sink as determined by 640 additional attribute fields. It is not expected that unicast 641 addresses will be given in a session description that is 642 communicated by a multicast announcement, though this is not 643 prohibited. 645 o Sessions using an IPv4 multicast connection address MUST also have 646 a time to live (TTL) value present in addition to the multicast 647 address. The TTL and the address together define the scope with 648 which multicast packets sent in this conference will be sent. TTL 649 values MUST be in the range 0-255. While the TTL MUST be 650 specified, its use to scope multicast traffic is deprecated; 651 applications SHOULD use an administratively scoped address 652 instead. 654 The TTL for the session is appended to the address using a slash as a 655 separator. An example is: 657 c=IN IP4 224.2.36.42/127 659 IPv6 multicast does not use TTL scoping, and hence the TTL value MUST 660 NOT be present for IPv6 multicast. It is expected that IPv6 scoped 661 addresses will be used to limit the scope of conferences. 663 Hierarchical or layered encoding schemes are data streams where the 664 encoding from a single media source is split into a number of layers. 665 The receiver can choose the desired quality (and hence bandwidth) by 666 only subscribing to a subset of these layers. Such layered encodings 667 are normally transmitted in multiple multicast groups to allow 668 multicast pruning. This technique keeps unwanted traffic from sites 669 only requiring certain levels of the hierarchy. For applications 670 requiring multiple multicast groups, we allow the following notation 671 to be used for the connection address: 673 [/]/ 675 If the number of addresses is not given it is assumed to be one. 676 Multicast addresses so assigned are contiguously allocated above the 677 base address, so that, for example: 679 c=IN IP4 224.2.1.1/127/3 681 would state that addresses 224.2.1.1, 224.2.1.2 and 224.2.1.3 are to 682 be used at a TTL of 127. This is semantically identical to including 683 multiple "c=" lines in a media description: 685 c=IN IP4 224.2.1.1/127 686 c=IN IP4 224.2.1.2/127 687 c=IN IP4 224.2.1.3/127 689 Similarly, an IPv6 example would be: 691 c=IN IP6 FF15::101/3 693 which is semantically equivalent to: 695 c=IN IP6 FF15::101 696 c=IN IP6 FF15::102 697 c=IN IP6 FF15::103 699 (remembering that the TTL field is not present in IPv6 multicast). 701 Multiple addresses or "c=" lines MAY be specified on a per-media 702 basis only if they provide multicast addresses for different layers 703 in a hierarchical or layered encoding scheme. They MUST NOT be 704 specified for a session-level "c=" field. 706 The slash notation for multiple addresses described above MUST NOT be 707 used for IP unicast addresses. 709 5.8. Bandwidth ("b=") 710 b=: 712 This OPTIONAL field denotes the proposed bandwidth to be used by the 713 session or media. The is an alphanumeric modifier giving 714 the meaning of the figure. Two values are defined in 715 this specification, but other values MAY be registered in future (see 716 Section 8 and [22], [26]): 718 CT If the bandwidth of a session or media in a session is different 719 from the bandwidth implicit from the scope, a "b=CT:..." line 720 SHOULD be supplied for the session giving the proposed upper limit 721 to the bandwidth used (the "conference total" bandwidth). The 722 primary purpose of this is to give an approximate idea as to 723 whether two or more sessions can co-exist simultaneously. When 724 using the CT modifier with RTP, if several RTP sessions are part 725 of the conference, the conference total refers to total bandwidth 726 of all RTP sessions. 728 AS The bandwidth is interpreted to be application-specific (it will 729 be the application's concept of maximum bandwidth). Normally this 730 will coincide with what is set on the application's "maximum 731 bandwidth" control if applicable. For RTP based applications, AS 732 gives the RTP "session bandwidth" as defined in Section 6.2 of 733 [20]. 735 Note that CT gives a total bandwidth figure for all the media at all 736 sites. AS gives a bandwidth figure for a single media at a single 737 site, although there may be many sites sending simultaneously. 739 A prefix "X-" is defined for names. This is intended for 740 experimental purposes only. For example: 742 b=X-YZ:128 744 Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers 745 SHOULD be registered with IANA in the standard namespace. SDP 746 parsers MUST ignore bandwidth fields with unknown modifiers. 747 Modifiers MUST be alpha-numeric and, although no length limit is 748 given, they are recommended to be short. 750 The is interpreted as kilobits per second by default. 751 The definition of a new modifier MAY specify that the 752 bandwidth is to be interpreted in some alternative unit (the "CT" and 753 "AS" modifiers defined in this memo use the default units). 755 5.9. Timing ("t=") 757 t= 759 The "t=" lines specify the start and stop times for a session. 760 Multiple "t=" lines MAY be used if a session is active at multiple 761 irregularly spaced times; each additional "t=" lines specifies an 762 additional period of time for which the session will be active. If 763 the session is active at regular times, an "r=" line (see below) 764 should be used in addition to, and following, a "t=" line - in which 765 case the "t=" line specifies the start and stop times of the repeat 766 sequence. 768 The first and second sub-fields give the start and stop times for the 769 session respectively. These values are the decimal representation of 770 Network Time Protocol (NTP) time values in seconds since 1900 [14]. 771 To convert these values to UNIX time, subtract decimal 2208988800. 773 NTP timestamps are elsewhere represented by 64 bit values which wrap 774 sometime in the year 2036. Since SDP uses an arbitrary length 775 decimal representation, this should not cause an issue (SDP 776 timestamps MUST continue counting seconds since 1900, NTP will use 777 the value modulo the 64 bit limit). 779 If the is set to zero, then the session is not bounded, 780 though it will not become active until after the . If 781 the is also zero, the session is regarded as permanent. 783 User interfaces SHOULD strongly discourage the creation of unbounded 784 and permanent sessions as they give no information about when the 785 session is actually going to terminate, and so make scheduling 786 difficult. 788 The general assumption may be made, when displaying unbounded 789 sessions that have not timed out to the user, that an unbounded 790 session will only be active until half an hour from the current time 791 or the session start time, whichever is the later. If behaviour 792 other than this is required, an end-time SHOULD be given and modified 793 as appropriate when new information becomes available about when the 794 session should really end. 796 Permanent sessions may be shown to the user as never being active 797 unless there are associated repeat times which state precisely when 798 the session will be active. 800 5.10. Repeat Times ("r=") 802 r= 804 "r=" fields specify repeat times for a session. For example, if a 805 session is active at 10am on Monday and 11am on Tuesday for one hour 806 each week for three months, then the in the 807 corresponding "t=" field would be the NTP representation of 10am on 808 the first Monday, the would be 1 week, the would be 1 hour, and the offsets would be zero and 25 810 hours. The corresponding "t=" field stop time would be the NTP 811 representation of the end of the last session three months later. By 812 default all fields are in seconds, so the "r=" and "t=" fields might 813 be: 815 t=3034423619 3042462419 816 r=604800 3600 0 90000 818 To make description more compact, times may also be given in units of 819 days, hours or minutes. The syntax for these is a number immediately 820 followed by a single case-sensitive character. Fractional units are 821 not allowed - a smaller unit should be used instead. The following 822 unit specification characters are allowed: 824 d - days (86400 seconds) 825 h - hours (3600 seconds) 826 m - minutes (60 seconds) 827 s - seconds (allowed for completeness) 829 Thus, the above session announcement could also have been written: 831 r=7d 1h 0 25h 833 Monthly and yearly repeats cannot be directly specified with a single 834 SDP repeat time - instead separate "t=" fields should be used to 835 explicitly list the session times. 837 5.11. Time Zones ("z=") 839 z= .... 841 To schedule a repeated session which spans a change from daylight 842 saving time to standard time or vice-versa, it is necessary to 843 specify offsets from the base time. This is required because 844 different time zones change time at different times of day, different 845 countries change to or from daylight time on different dates, and 846 some countries do not have daylight saving time at all. 848 Thus in order to schedule a session that is at the same time winter 849 and summer, it must be possible to specify unambiguously by whose 850 time zone a session is scheduled. To simplify this task for 851 receivers, we allow the sender to specify the NTP time that a time 852 zone adjustment happens and the offset from the time when the session 853 was first scheduled. The "z=" field allows the sender to specify a 854 list of these adjustment times and offsets from the base time. 856 An example might be: 858 z=2882844526 -1h 2898848070 0 860 This specifies that at time 2882844526 the time base by which the 861 session's repeat times are calculated is shifted back by 1 hour, and 862 that at time 2898848070 the session's original time base is restored. 863 Adjustments are always relative to the specified start time - they 864 are not cumulative. Adjustments apply to all "t=" and "r=" lines in 865 a session description. 867 If a session is likely to last several years, it is expected that the 868 session announcement will be modified periodically rather than 869 transmit several years worth of adjustments in one session 870 announcement. 872 5.12. Encryption Keys ("k=") 874 k= 875 k=: 877 If transported over a secure and trusted channel, the session 878 description protocol MAY be used to convey encryption keys. A simple 879 mechanism for key exchange is provided by the key field ("k=") 880 although this is primarily supported for compatibility with older 881 implementations and its use is NOT RECOMMENDED. Work is in progress 882 to define new key exchange mechanisms for use with SDP [28] [29] and 883 it is expected that new applications will use those mechanisms. 885 A key field is permitted before the first media entry (in which case 886 it applies to all media in the session), or for each media entry as 887 required. The format of keys and their usage is outside the scope of 888 this document, and the key field provides no way to indicate the 889 encryption algorithm to be used, key type, or other information about 890 the key: this is assumed to be provided by the higher-level protocol 891 using SDP. If there is a need to convey this information within SDP, 892 the extensions mentioned previously SHOULD be used. Many security 893 protocols require two keys: one for confidentiality, another for 894 integrity. This specification does not support transfer of two keys. 896 The method indicates the mechanism to be used to obtain a usable key 897 by external means, or from the encoded encryption key given. The 898 following methods are defined: 900 k=clear: 902 The encryption key is included untransformed in this key field. 903 This method MUST NOT be used unless it can be guaranteed that 904 the SDP is conveyed over a secure channel. The encryption key 905 is interpreted as text according to the charset attribute, use 906 the "k=base64:" method to convey characters that are otherwise 907 prohibited in SDP. 909 k=base64: 911 The encryption key is included in this key field but has been 912 base64 encoded [13] because it includes characters that are 913 prohibited in SDP. This method MUST NOT be used unless it can 914 be guaranteed that the SDP is conveyed over a secure channel. 916 k=uri: 918 A Universal Resource Identifier is included in the key field. 919 The URI refers to the data containing the key, and may require 920 additional authentication before the key can be returned. When 921 a request is made to the given URI, the reply should specify 922 the encoding for the key. The URI is often a a SSL/ 923 TLS-protected HTTP URI ("https:"), although this is not 924 required. 926 k=prompt 928 No key is included in this SDP description, but the session or 929 media stream referred to by this key field is encrypted. The 930 user should be prompted for the key when attempting to join the 931 session, and this user-supplied key should then be used to 932 decrypt the media streams. The use of user-specified keys is 933 NOT RECOMMENDED, since such keys tend to have weak security 934 properties. 936 The key field MUST NOT be used unless it can be guaranteed that the 937 SDP is conveyed over a secure and trusted channel. An example of 938 such a channel might be SDP embedded inside an S/MIME message or a 939 TLS-protected HTTP session. It is important to ensure that the 940 secure channel is with the party that is authorised to join the 941 session, not an intermediary: if a caching proxy server is used, it 942 is important to ensure that the proxy is either trusted or unable to 943 access the SDP. 945 5.13. Attributes ("a=") 947 a= 948 a=: 950 Attributes are the primary means for extending SDP. Attributes may 951 be defined to be used as "session-level" attributes, "media-level" 952 attributes, or both. 954 A media description may have any number of attributes ("a=" fields) 955 which are media specific. These are referred to as "media-level" 956 attributes and add information about the media stream. Attribute 957 fields can also be added before the first media field; these 958 "session-level" attributes convey additional information that applies 959 to the conference as a whole rather than to individual media. 961 Attribute fields may be of two forms: 963 o A property attribute is simply of the form "a=". These are 964 binary attributes, and the presence of the attribute conveys that 965 the attribute is a property of the session. An example might be 966 "a=recvonly". 968 o A value attribute is of the form "a=:". For 969 example, a whiteboard could have the value attribute "a=orient: 970 landscape" 972 Attribute interpretation depends on the media tool being invoked. 973 Thus receivers of session descriptions should be configurable in 974 their interpretation of session descriptions in general and of 975 attributes in particular. 977 Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. 979 Attribute values are octet strings, and MAY use any octet value 980 except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute 981 values are to be interpreted as in ISO-10646 character set with UTF-8 982 encoding. Unlike other text fields, attribute values are NOT 983 normally affected by the "charset" attribute as this would make 984 comparisons against known values problematic. However, when an 985 attribute is defined, it can be defined to be charset-dependent, in 986 which case its value should be interpreted in the session charset 987 rather than in ISO-10646. 989 Attributes MUST be registered with IANA (see Section 8). If an 990 attribute is received that is not understood, it MUST be ignored by 991 the receiver. 993 5.14. Media Descriptions ("m=") 995 m= ... 997 A session description may contain a number of media descriptions. 998 Each media description starts with an "m=" field, and is terminated 999 by either the next "m=" field or by the end of the session 1000 description. A media field has several sub-fields: 1002 is the media type. Currently defined media are "audio", 1003 "video", "text", "application" and "message", although this list 1004 may be extended in future (see Section 8). 1006 is the transport port to which the media stream is sent. The 1007 meaning of the transport port depends on the network being used as 1008 specified in the relevant "c=" field, and on the transport 1009 protocol defined in the sub-field of the media field. 1010 Other ports used by the media application (such as the RTCP port 1011 [20]) MAY be derived algorithmically from the base media port or 1012 MAY be specified in a separate attribute (for example "a=rtcp:" as 1013 defined in [23]). 1015 If non-contiguous ports are used or if they don't follow the 1016 parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" 1017 attribute MUST be used. Applications that are requested to send 1018 media to a that is odd and where the "a=rtcp:" is present 1019 MUST NOT substract 1 to the RTP port: i.e, they MUST send the RTP 1020 to the port indicated in and send the RTCP to the port 1021 indicated in the "a=rtcp" attribute. 1023 For applications where hierarchically encoded streams are being 1024 sent to a unicast address, it may be necessary to specify multiple 1025 transport ports. This is done using a similar notation to that 1026 used for IP multicast addresses in the "c=" field: 1028 m= / ... 1030 In such a case, the ports used depend on the transport protocol. 1031 For RTP, the default is that only the even numbered ports are used 1032 for data with the corresponding one-higher odd ports used for the 1033 RTCP belonging to the RTP session, and the 1034 denoting the number of RTP sessions. For example: 1036 m=video 49170/2 RTP/AVP 31 1038 would specify that ports 49170 and 49171 form one RTP/RTCP pair 1039 and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the 1040 transport protocol and 31 is the format (see below). If non- 1041 contiguous ports are required, they must be signalled using a 1042 separate attribute (for example "a=rtcp:" as defined in [23]). 1044 If multiple addresses are specified in the "c=" field and multiple 1045 ports are specified in the "m=" field, a one-to-one mapping from 1046 port to the corresponding address is implied. For example: 1048 c=IN IP4 224.2.1.1/127/2 1049 m=video 49170/2 RTP/AVP 31 1051 would imply that address 224.2.1.1 is used with ports 49170 and 1052 49171, and address 224.2.1.2 is used with ports 49172 and 49173. 1054 The semantics of multiple "m=" lines using the same transport 1055 address are undefined. This implies that, unlike limited past 1056 practice, there is no implicit grouping defined by such means and 1057 an explicit grouping framework (for example [19]) should instead 1058 be used to express the intended semantics. 1060 is the transport protocol. The meaning of the transport 1061 protocol is dependent on the address type field in the relevant 1062 "c=" field. Thus a "c=" field of IP4 indicates that the transport 1063 protocol runs over IP4. The following transport protocols are 1064 defined, but may be extended through registration of new protocols 1065 with IANA (see Section 8): 1067 * udp: denotes an unspecified protocol running over UDP. 1069 * RTP/AVP: denotes RTP [20] used under the RTP Profile for Audio 1070 and Video Conferences with Minimal Control [21] running over 1071 UDP. 1073 * RTP/SAVP: denotes the Secure Real-time Transport Protocol [24] 1074 running over UDP. 1076 The main reason to specify the transport-protocol in addition to 1077 the media format is that the same standard media formats may be 1078 carried over different transport protocols even when the network 1079 protocol is the same - a historical example is vat PCM audio and 1080 RTP PCM audio, another might be TCP/RTP PCM audio. In addition, 1081 relays and monitoring tools that are transport-protocol-specific 1082 but format-independent are possible. 1084 is a media format description. The fourth and any subsequent 1085 sub-fields describe the format of the media. The interpretation 1086 of the media format depends on the value of the sub-field. 1088 If the sub-field is "RTP/AVP" or "RTP/SAVP" the sub- 1089 fields contain RTP payload type numbers. When a list of payload 1090 type numbers is given, this implies that all of these payload 1091 formats MAY be used in the session, but the first of these formats 1092 SHOULD be used as the default format for the session. For dynamic 1093 payload type assignments the "a=rtpmap:" attribute (see Section 6) 1094 SHOULD be used to map from an RTP payload type number to a media 1095 encoding name that identifies the payload format. The "a=fmtp:" 1096 attribute MAY be used to specify format parameters (see 1097 Section 6). 1099 If the sub-field is "udp" the sub-fields MUST 1100 reference a media type describing the format under the "audio", 1101 "video", "text", "application" or "message" top-level MIME types. 1102 The media type registration SHOULD define the packet format for 1103 use with UDP transport. 1105 For media using other transport protocols, the field is 1106 protocol specific. Rules for interpretation of the sub- 1107 field MUST be defined when registering new protocols (see section 1108 8.2.2). 1110 6. SDP Attributes 1112 The following attributes are defined. Since application writers may 1113 add new attributes as they are required, this list is not exhaustive. 1114 Registration procedures for new attributes are defined in Section 1115 8.2.4. 1117 a=cat: 1119 This attribute gives the dot-separated hierarchical category of 1120 the session. This is to enable a receiver to filter unwanted 1121 sessions by category. There is no central registry of 1122 categories. It is a session-level attribute, and is not 1123 dependent on charset. 1125 a=keywds: 1127 Like the cat attribute, this is to assist identifying wanted 1128 sessions at the receiver. This allows a receiver to select 1129 interesting session based on keywords describing the purpose of 1130 the session; there is no central registry of keywords. It is a 1131 session-level attribute. It is a charset dependent attribute, 1132 meaning that its value should be interpreted in the charset 1133 specified for the session description if one is specified, or 1134 by default in ISO 10646/UTF-8. 1136 a=tool: 1138 This gives the name and version number of the tool used to 1139 create the session description. It is a session-level 1140 attribute, and is not dependent on charset. 1142 a=ptime: 1144 This gives the length of time in milliseconds represented by 1145 the media in a packet. This is probably only meaningful for 1146 audio data, but may be used with other media types if it makes 1147 sense. It should not be necessary to know ptime to decode RTP 1148 or vat audio, and it is intended as a recommendation for the 1149 encoding/packetisation of audio. It is a media attribute, and 1150 is not dependent on charset. 1152 a=maxptime: 1154 The maximum amount of media which can be encapsulated in each 1155 packet, expressed as time in milliseconds. The time SHALL be 1156 calculated as the sum of the time the media present in the 1157 packet represents. For frame based codecs, the time SHOULD be 1158 an integer multiple of the frame size. This attribute is 1159 probably only meaningful for audio data, but may be used with 1160 other media types if it makes sense. It is a media attribute, 1161 and is not dependent on charset. Note that this attribute was 1162 introduced after RFC 2327, and non updated implementations will 1163 ignore this attribute. 1165 a=rtpmap: / [/] 1168 This attribute maps from an RTP payload type number (as used in 1169 an "m=" line) to an encoding name denoting the payload format 1170 to be used. It also provides information on the clock rate and 1171 encoding parameters. It is a media level attribute that is not 1172 dependent on charset. 1174 While an RTP profile may make static assignments of payload 1175 type numbers to payload formats, it is more common for that 1176 assignment to be done dynamically using "a=rtpmap:" attributes. 1177 As an example of a static payload type, consider u-law PCM 1178 coded single channel audio sampled at 8kHz. This is completely 1179 defined in the RTP Audio/Video profile as payload type 0, so 1180 there is no need for an "a=rtpmap: attribute, and the media for 1181 such a stream sent to UDP port 49232 can be specified as: 1183 m=audio 49232 RTP/AVP 0 1185 An example of a dynamic payload type is 16 bit linear encoded 1186 stereo audio sampled at 16 kHz. If we wish to use the dynamic 1187 RTP/AVP payload type 98 for this stream, additional information 1188 is required to decode it: 1190 m=audio 49232 RTP/AVP 98 1191 a=rtpmap:98 L16/16000/2 1193 Up to one rtpmap attribute can be defined for each media format 1194 specified. Thus we might have: 1196 m=audio 49230 RTP/AVP 96 97 98 1197 a=rtpmap:96 L8/8000 1198 a=rtpmap:97 L16/8000 1199 a=rtpmap:98 L16/11025/2 1201 RTP profiles that specify the use of dynamic payload types MUST 1202 define the set of valid encoding names and/or a means to 1203 register encoding names if that profile is to be used with SDP. 1204 The "RTP/AVP" and "RTP/SAVP" profiles use MIME sub-types for 1205 encoding names, under the top-level media type denoted in the 1206 "m=" line. In the example above, the media types are 1207 "audio/l8" and "audio/l16". 1209 For audio streams, indicates the number 1210 of audio channels. This parameter is OPTIONAL and may be 1211 omitted if the number of channels is one, provided no 1212 additional parameters are needed. 1214 For video streams, no encoding parameters are currently 1215 specified. 1217 Additional encoding parameters MAY be defined in the future, 1218 but codec specific parameters SHOULD NOT be added. Parameters 1219 added to an "a=rtpmap:" attribute SHOULD only be those required 1220 for a session directory to make the choice of appropriate media 1221 to participate in a session. Codec-specific parameters should 1222 be added in other attributes (for example, "a=fmtp:"). 1224 Note: RTP audio formats typically do not include information 1225 about the number of samples per packet. If a non-default (as 1226 defined in the RTP Audio/Video Profile) packetisation is 1227 required, the "ptime" attribute is used as given below. 1229 a=recvonly 1231 This specifies that the tools should be started in receive only 1232 mode where applicable. It can be either a session or media 1233 attribute, and is not dependent on charset. Note that recvonly 1234 applies to the media only, not to any associated control 1235 protocol (e.g. an RTP based system in recvonly mode SHOULD 1236 still send RTCP packets). 1238 a=sendrecv 1240 This specifies that the tools should be started in send and 1241 receive mode. This is necessary for interactive conferences 1242 with tools that default to receive only mode. It can be either 1243 a session or media attribute, and is not dependent on charset. 1245 If none of the attributes "sendonly", "recvonly", "inactive", 1246 and "sendrecv" is present, "sendrecv" SHOULD be assumed as the 1247 default for sessions which are not of the conference type 1248 "broadcast" or "H332" (see below). 1250 a=sendonly 1252 This specifies that the tools should be started in send-only 1253 mode. An example may be where a different unicast address is 1254 to be used for a traffic destination than for a traffic source. 1255 In such a case, two media descriptions may be used, one 1256 sendonly and one recvonly. It can be either a session or media 1257 attribute, but would normally only be used as a media 1258 attribute. It is not dependent on charset. Note that sendonly 1259 applies only to the media, and any associated control protocol 1260 (e.g. RTCP) SHOULD still be received and processed as normal. 1262 a=inactive 1264 This specifies that the tools should be started in inactive 1265 mode. This is necessary for interactive conferences where 1266 users can put other users on hold. No media is sent over an 1267 inactive media stream. Note that an RTP based system SHOULD 1268 still send RTCP, even if started inactive. It can be either a 1269 session or media attribute, and is not dependent on charset. 1271 a=orient: 1273 Normally this is only used for a whiteboard or presentation 1274 tool. It specifies the orientation of a the workspace on the 1275 screen. It is a media attribute. Permitted values are 1276 "portrait", "landscape" and "seascape" (upside down landscape). 1277 It is not dependent on charset. 1279 a=type: 1281 This specifies the type of the conference. Suggested values 1282 are "broadcast", "meeting", "moderated", "test" and "H332". 1283 "recvonly" should be the default for "type:broadcast" sessions, 1284 "type:meeting" should imply "sendrecv" and "type:moderated" 1285 should indicate the use of a floor control tool and that the 1286 media tools are started so as to mute new sites joining the 1287 conference. 1289 Specifying the attribute "type:H332" indicates that this 1290 loosely coupled session is part of a H.332 session as defined 1291 in the ITU H.332 specification [27]. Media tools should be 1292 started "recvonly". 1294 Specifying the attribute "type:test" is suggested as a hint 1295 that, unless explicitly requested otherwise, receivers can 1296 safely avoid displaying this session description to users. 1298 The type attribute is a session-level attribute, and is not 1299 dependent on charset. 1301 a=charset: 1303 This specifies the character set to be used to display the 1304 session name and information data. By default, the ISO-10646 1305 character set in UTF-8 encoding is used. If a more compact 1306 representation is required, other character sets may be used. 1307 For example, the ISO 8859-1 is specified with the following SDP 1308 attribute: 1310 a=charset:ISO-8859-1 1312 This is a session-level attribute and is not dependent on 1313 charset. The charset specified MUST be one of those registered 1314 with IANA, such as ISO-8859-1. The character set identifier is 1315 a US-ASCII string and MUST be compared against the IANA 1316 identifiers using a case insensitive comparison. If the 1317 identifier is not recognised or not supported, all strings that 1318 are affected by it SHOULD be regarded as octet strings. 1320 Note that a character set specified MUST still prohibit the use 1321 of bytes 0x00 (Nul), 0x0A (LF) and 0x0d (CR). Character sets 1322 requiring the use of these characters MUST define a quoting 1323 mechanism that prevents these bytes appearing within text 1324 fields. 1326 a=sdplang: 1328 This can be a session level attribute or a media level 1329 attribute. As a session level attribute, it specifies the 1330 language for the session description. As a media level 1331 attribute, it specifies the language for any media-level SDP 1332 information field associated with that media. Multiple sdplang 1333 attributes can be provided either at session or media level if 1334 multiple languages in the session description or media use 1335 multiple languages, in which case the order of the attributes 1336 indicates the order of importance of the various languages in 1337 the session or media from most important to least important. 1339 In general, sending session descriptions consisting of multiple 1340 languages is discouraged. Instead, multiple descriptions 1341 SHOULD be sent describing the session, one in each language. 1342 However this is not possible with all transport mechanisms, and 1343 so multiple sdplang attributes are allowed although NOT 1344 RECOMMENDED. 1346 The "sdplang" attribute value must be a single RFC 3066 1347 language tag in US-ASCII [10]. It is not dependent on the 1348 charset attribute. An "sdplang" attribute SHOULD be specified 1349 when a session is of sufficient scope to cross geographic 1350 boundaries where the language of recipients cannot be assumed, 1351 or where the session is in a different language from the 1352 locally assumed norm. 1354 a=lang: 1356 This can be a session level attribute or a media level 1357 attribute. As a session level attribute, it specifies the 1358 default language for the session being described. As a media 1359 level attribute, it specifies the language for that media, 1360 overriding any session-level language specified. Multiple lang 1361 attributes can be provided either at session or media level if 1362 the session description or media use multiple languages, in 1363 which case the order of the attributes indicates the order of 1364 importance of the various languages in the session or media 1365 from most important to least important. 1367 The "lang" attribute value must be a single RFC 3066 language 1368 tag in US-ASCII [10]. It is not dependent on the charset 1369 attribute. A "lang" attribute SHOULD be specified when a 1370 session is of sufficient scope to cross geographic boundaries 1371 where the language of recipients cannot be assumed, or where 1372 the session is in a different language from the locally assumed 1373 norm. 1375 a=framerate: 1377 This gives the maximum video frame rate in frames/sec. It is 1378 intended as a recommendation for the encoding of video data. 1379 Decimal representations of fractional values using the notation 1380 "." are allowed. It is a media attribute, 1381 defined only for video media, and is not dependent on charset. 1383 a=quality: 1385 This gives a suggestion for the quality of the encoding as an 1386 integer value. The intention of the quality attribute for 1387 video is to specify a non-default trade-off between frame-rate 1388 and still-image quality. For video, the value in the range 0 1389 to 10, with the following suggested meaning: 1391 10 - the best still-image quality the compression scheme 1392 can give. 1393 5 - the default behaviour given no quality suggestion. 1394 0 - the worst still-image quality the codec designer 1395 thinks is still usable. 1397 It is a media attribute, and is not dependent on charset. 1399 a=fmtp: 1401 This attribute allows parameters that are specific to a 1402 particular format to be conveyed in a way that SDP doesn't have 1403 to understand them. The format must be one of the formats 1404 specified for the media. Format-specific parameters may be any 1405 set of parameters required to be conveyed by SDP and given 1406 unchanged to the media tool that will use this format. At most 1407 one instance of this attribute is allowed for each format. 1409 It is a media attribute, and is not dependent on charset. 1411 7. Security Considerations 1413 SDP is frequently used with the Session Initiation Protocol [16] 1414 using the offer/answer model [18] to agree on parameters for unicast 1415 sessions. When used in this manner, the security considerations of 1416 those protocols apply. 1418 SDP is a session description format that describes multimedia 1419 sessions. Entities receiving and acting upon an SDP message SHOULD 1420 be aware that a session description cannot be trusted unless it has 1421 been obtained by an authenticated transport protocol from a known and 1422 trusted source. Many different transport protocols may be used to 1423 distribute session description, and the nature of the authentication 1424 will differ from transport to transport. For some transports, 1425 security features are often not deployed. In case a session 1426 description has not been obtained in a trusted manner, the endpoint 1427 SHOULD exercise care because, among other attacks, the media sessions 1428 received may not be the intended ones, the destination where media is 1429 sent to may not be the expected one, any the parameters of the 1430 session may be incorrect, or the media security may be compromised. 1431 It is up to the endpoint to take a sensible decision taking into 1432 account the security risks of the application and the user 1433 preferences and may decide to inquire the user whether or not to 1434 accept the session. 1436 One transport that can be used to distribute session descriptions is 1437 the Session Announcement Protocol (SAP). SAP provides both 1438 encryption and authentication mechanisms but due to the nature of 1439 session announcements it is likely that there are many occasions 1440 where the originator of a session announcement cannot be 1441 authenticated because they are previously unknown to the receiver of 1442 the announcement and because no common public key infrastructure is 1443 available. 1445 On receiving a session description over an unauthenticated transport 1446 mechanism or from an untrusted party, software parsing the session 1447 should take a few precautions. Session descriptions contain 1448 information required to start software on the receivers system. 1449 Software that parses a session description MUST NOT be able to start 1450 other software except that which is specifically configured as 1451 appropriate software to participate in multimedia sessions. It is 1452 normally considered inappropriate for software parsing a session 1453 description to start, on a user's system, software that is 1454 appropriate to participate in multimedia sessions, without the user 1455 first being informed that such software will be started and giving 1456 their consent. Thus a session description arriving by session 1457 announcement, email, session invitation, or WWW page MUST NOT deliver 1458 the user into an interactive multimedia session unless the user has 1459 explicitly pre-authorized such action. As it is not always simple to 1460 tell whether a session is interactive or not, applications that are 1461 unsure should assume sessions are interactive. 1463 In this specification, there are no attributes which would allow the 1464 recipient of a session description to be informed to start multimedia 1465 tools in a mode where they default to transmitting. Under some 1466 circumstances it might be appropriate to define such attributes. If 1467 this is done an application parsing a session description containing 1468 such attributes SHOULD either ignore them, or inform the user that 1469 joining this session will result in the automatic transmission of 1470 multimedia data. The default behaviour for an unknown attribute is 1471 to ignore it. 1473 In certain environments is has become common for intermediary systems 1474 to intercept and analyse session descriptions contained within other 1475 signalling protocols. This is done for a range of purposes, 1476 including but not limited to: opening holes in firewalls to allow 1477 media streams to pass, or to mark, prioritize, or block traffic 1478 selectively. In some cases, such intermediary systems may modify the 1479 session description, for example to have the contents of the session 1480 description match NAT bindings dynamically created. These behaviors 1481 are NOT RECOMMENDED unless the session description is conveyed in 1482 such a manner that allows the intermediary system to conduct proper 1483 checks to establish the authenticity of the session description, and 1484 the authority of its source to establish such communication sessions. 1485 SDP by itself does not include sufficient information to enable these 1486 checks: they depend on the encapsulating protocol (e.g. SIP or 1487 RTSP). 1489 Use of the "k=" field poses a significant security risk, since it 1490 conveys session encryption keys in the clear. SDP MUST NOT be used 1491 to convey key material, unless it can be guaranteed that the channel 1492 over which the SDP is delivered is both private and authenticated. 1494 8. IANA Considerations 1496 8.1. The "application/sdp" media type 1498 One MIME media type registration from RFC 2327 is to be updated, as 1499 defined below. 1501 To: ietf-types@iana.org 1502 Subject: Registration of media type "application/sdp" 1504 MIME media type name: application 1506 MIME subtype name: sdp 1508 Required parameters: None. 1510 Optional parameters: None. 1512 Encoding considerations: 1513 SDP files are primarily 7-bit ASCII text. The "a=charset:" 1514 attribute may be used to signal the presence of other, 1515 possibly 8-bit, text in certain parts of an SDP file (see 1516 section 6 of RFC XXXX). Arbitrary binary content cannot 1517 be directly represented in SDP. 1519 Security considerations: 1520 See section 7 of RFC XXXX 1522 Interoperability considerations: 1523 See RFC XXXX 1525 Published specification: 1526 See RFC XXXX 1528 Applications which use this media type: 1529 Voice over IP, video teleconferencing, streaming media, instant 1530 messaging, etc. See also section 3 of RFC XXXX. 1532 Additional information: 1534 Magic number(s): None. 1535 File extension(s): The extension ".sdp" is commonly used. 1536 Macintosh File Type Code(s): "sdp " 1538 Person & email address to contact for further information: 1539 Mark Handley 1540 Colin Perkins 1541 IETF MMUSIC working group 1543 Intended usage: COMMON 1545 Author/Change controller: 1546 Authors of RFC XXXX 1547 IETF MMUSIC working group delegated from the IESG 1549 8.2. Registration of Parameters 1551 There are seven field names that may be registered with IANA. Using 1552 the terminology in the SDP specification BNF, they are "media", 1553 "proto", "fmt", "att-field", "bwtype", "nettype" and "addrtype". 1555 8.2.1. Media types ("media") 1557 The set of media types is intended to be small and SHOULD NOT be 1558 extended except under rare circumstances. The same rules should 1559 apply for media names as for top-level MIME content types, and where 1560 possible the same name should be registered for SDP as for MIME. For 1561 media other than existing MIME top-level content types, a standards- 1562 track RFC MUST be produced for a new top-level content type to be 1563 registered, and the registration MUST provide good justification why 1564 no existing media name is appropriate (the "Standards Action" policy 1565 of RFC 2434 [8]. 1567 This memo registers the media types "audio", "video", "text", 1568 "application" and "message". 1570 Note: The media types "control" and "data" were listed as valid in 1571 the previous version of this specification [6], however their 1572 semantics were never fully specified and they are not widely used. 1573 These media types have been removed in this specification, although 1574 they still remain valid media type capabilities for a SIP user agent 1575 as defined in RFC 3840 [25]. If these media types are considered 1576 useful in future, a Standards Track RFC MUST be produced to document 1577 their use. Until that is done, applications SHOULD NOT use these 1578 types and SHOULD NOT declare support for them in SIP capabilities 1579 declarations (even though they exist in the registry created by RFC 1580 3840). 1582 8.2.2. Transport protocols ("proto") 1584 The "proto" field describes the transport protocol used. This SHOULD 1585 reference a standards-track protocol RFC. This memo registers three 1586 values: "RTP/AVP" is a reference to RTP [20] used under the RTP 1587 Profile for Audio and Video Conferences with Minimal Control [21] 1588 running over UDP/IP, "RTP/SAVP" is a reference to the Secure Real- 1589 time Transport Protocol [24], and "udp" indicates an unspecified 1590 protocol over UDP. 1592 If other RTP profiles are defined in the future, their "proto" name 1593 SHOULD be specified in the same manner. For example, an RTP profile 1594 whose short name is "XYZ" would be denoted by a "proto" field of 1595 "RTP/XYZ". 1597 New transport protocols SHOULD be registered with IANA. 1598 Registrations MUST reference an RFC describing the protocol. Such an 1599 RFC MAY be Experimental or Informational, although it is preferable 1600 if it is Standards-Track. Registrations MUST also define the rules 1601 by which their "fmt" namespace is managed (see below). 1603 8.2.3. Media formats ("fmt") 1605 Each transport protocol, defined by the "proto" field, has an 1606 associated "fmt" namespace that describes the media formats which may 1607 conveyed by that protocol. Formats cover all the possible encodings 1608 that might want to be transported in a multimedia session. 1610 RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST 1611 use the payload type number as their "fmt" value. If the payload 1612 type number is dynamically assigned by this session description, an 1613 additional "rtpmap" attribute MUST be included to specify the format 1614 name and parameters as defined by the MIME type registration for the 1615 payload format. It is RECOMMENDED that other RTP profiles which are 1616 registered (in combination with RTP) as SDP transport protocols 1617 specify the same rules for the "fmt" namespace. 1619 For the "udp" protocol, new formats SHOULD be registered. Use of an 1620 existing MIME subtype for the format is encouraged. If no MIME 1621 subtype exists, it is RECOMMENDED that a suitable one is registered 1622 through the IETF process (RFC 2048) by production of, or reference 1623 to, a standards-track RFC that defines the transport protocol for the 1624 format. 1626 For other protocols, formats MAY be registered according to the rules 1627 of the associated "proto" specification. 1629 Registrations of new formats MUST specify which transport protocols 1630 they apply to. 1632 8.2.4. Attribute names ("att-field") 1634 Attribute field names ("att-field") MUST be registered with IANA and 1635 documented, because of noticeable issues due to conflicting 1636 attributes under the same name. Unknown attributes in SDP are simply 1637 ignored, but conflicting ones that fragment the protocol are a 1638 serious problem. 1640 New attribute registrations are accepted according to the 1641 "Specification Required" policy of RFC 2434, provided that the 1642 specification includes the following information: 1644 o contact name, email address and telephone number 1646 o attribute-name (as it will appear in SDP) 1648 o long-form attribute name in English 1650 o type of attribute (session level, media level, or both) 1652 o whether the attribute value is subject to the charset attribute. 1654 o a one paragraph explanation of the purpose of the attribute. 1656 o a specification of appropriate attribute values for this 1657 attribute. 1659 The above is the minimum that IANA will accept. Attributes that are 1660 expected to see widespread use and interoperability, SHOULD be 1661 documented with a standards-track RFC that specifies the attribute 1662 more precisely. 1664 Submitters of registrations should ensure that the specification is 1665 in the spirit of SDP attributes, most notably that the attribute is 1666 platform independent in the sense that it makes no implicit 1667 assumptions about operating systems and does not name specific pieces 1668 of software in a manner that might inhibit interoperability. 1670 IANA is requested to register the following initial set of attribute 1671 names ("att-field" values), with definitions as in Section 6 of this 1672 memo (these definitions update those in RFC 2327): 1674 Name | Session or Media level? | Dependent on charset? 1675 ----------+-------------------------+---------------------- 1676 cat | Session | No 1677 keywds | Session | Yes 1678 tool | Session | No 1679 ptime | Media | No 1680 maxptime | Media | No 1681 rtpmap | Media | No 1682 recvonly | Either | No 1683 sendrecv | Either | No 1684 sendonly | Either | No 1685 inactive | Either | No 1686 orient | Media | No 1687 type | Session | No 1688 charset | Session | No 1689 sdplang | Either | No 1690 lang | Either | No 1691 framerate | Media | No 1692 quality | Media | No 1693 fmtp | Media | No 1695 8.2.5. Bandwidth specifiers ("bwtype") 1697 A proliferation of bandwidth specifiers is strongly discouraged. 1699 New bandwidth specifiers ("bwtype" fields) MUST be registered with 1700 IANA. The submission MUST reference a standards-track RFC specifying 1701 the semantics of the bandwidth specifier precisely, and indicating 1702 when it should be used, and why the existing registered bandwidth 1703 specifiers do not suffice. 1705 IANA is requested to register the bandwith specifiers "CT" and "AS" 1706 with definitions as in Section 5.8 of this memo (these definitions 1707 update those in RFC 2327). 1709 8.2.6. Network types ("nettype") 1711 New network types (the "nettype" field) may be registered with IANA 1712 if SDP needs to be used in the context of non-Internet environments. 1713 Whilst these are not normally the preserve of IANA, there may be 1714 circumstances when an Internet application needs to interoperate with 1715 a non- Internet application, such as when gatewaying an Internet 1716 telephony call into the PSTN. The number of network types should be 1717 small and should be rarely extended. A new network type cannot be 1718 registered without registering at least one address type to be used 1719 with that network type. A new network type registration MUST 1720 reference an RFC which gives details of the network type and address 1721 type and specifies how and when they would be used. 1723 IANA is requested to register the network type "IN" to represent the 1724 Internet, with definition as in Sections 5.2 and 5.7 of this memo 1725 (these definitions update those in RFC 2327). 1727 8.2.7. Address types ("addrtype") 1729 New address types ("addrtype") may be registered with IANA. An 1730 address type is only meaningful in the context of a network type, and 1731 any registration of an address type MUST specify a registered network 1732 type, or be submitted along with a network type registration. A new 1733 address type registration MUST reference an RFC giving details of the 1734 syntax of the address type. Address types are not expected to be 1735 registered frequently. 1737 IANA is requested to register the address types "IP4" and "IP6" with 1738 definitions as in Sections 5.2 and 5.7 of this memo (these 1739 definitions update those in RFC 2327). 1741 8.2.8. Registration Procedure 1743 In the RFC documentation that registers SDP "media", "proto", "fmt", 1744 "bwtype", "nettype" and "addrtype" fields, the authors MUST include 1745 the following information for IANA to place in the appropriate 1746 registry: 1748 o contact name, email address and telephone number 1750 o name being registered (as it will appear in SDP) 1752 o long-form name in English 1754 o type of name ("media", "proto", "fmt", "bwtype", "nettype", or 1755 "addrtype") 1757 o a one paragraph explanation of the purpose of the registered name. 1759 o a reference to the specification for the registered name (this 1760 will typically be an RFC number). 1762 IANA may refer any registration to the IESG Transport Area Directors 1763 for review, and may request revisions to be made before a 1764 registration will be made. 1766 8.3. Encryption Key Access Methods 1768 The IANA currently maintains a table of SDP encryption key access 1769 method ("enckey") names. This table is obsolete and SHOULD be 1770 removed, since the "k=" line is not extensible. New registrations 1771 MUST NOT be accepted. 1773 9. SDP Grammar 1775 This section provides an Augmented BNF grammar for SDP. ABNF is 1776 defined in [4]. 1778 ; SDP Syntax 1779 session-description = proto-version 1780 origin-field 1781 session-name-field 1782 information-field 1783 uri-field 1784 email-fields 1785 phone-fields 1786 connection-field 1787 bandwidth-fields 1788 time-fields 1789 key-field 1790 attribute-fields 1791 media-descriptions 1793 proto-version = "v=" 1*DIGIT CRLF 1794 ;this memo describes version 0 1796 origin-field = "o=" username SP sess-id SP sess-version SP 1797 nettype SP addrtype SP unicast-address CRLF 1799 session-name-field = "s=" text CRLF 1801 information-field = ["i=" text CRLF] 1803 uri-field = ["u=" uri CRLF] 1805 email-fields = *("e=" email-address CRLF) 1807 phone-fields = *("p=" phone-number CRLF) 1809 connection-field = ["c=" nettype SP addrtype SP 1810 connection-address CRLF] 1811 ;a connection field must be present 1812 ;in every media description or at the 1813 ;session-level 1815 bandwidth-fields = *("b=" bwtype ":" bandwidth CRLF) 1817 time-fields = 1*( "t=" start-time SP stop-time 1818 *(CRLF repeat-fields) CRLF) 1819 [zone-adjustments CRLF] 1821 repeat-fields = "r=" repeat-interval SP typed-time 1822 1*(SP typed-time) 1824 zone-adjustments = "z=" time SP ["-"] typed-time 1825 *(SP time SP ["-"] typed-time) 1827 key-field = ["k=" key-type CRLF] 1829 attribute-fields = *("a=" attribute CRLF) 1831 media-descriptions = *( media-field 1832 information-field 1833 *connection-field 1834 bandwidth-fields 1835 key-field 1836 attribute-fields ) 1838 media-field = "m=" media SP port ["/" integer] 1839 SP proto 1*(SP fmt) CRLF 1841 ; sub-rules of 'o=' 1842 username = non-ws-string 1843 ;pretty wide definition, but doesn't 1844 ;include space 1846 sess-id = 1*DIGIT 1847 ;should be unique for this username/host 1849 sess-version = 1*DIGIT 1851 nettype = token 1852 ;typically "IN" 1854 addrtype = token 1855 ;typically "IP4" or "IP6" 1857 ; sub-rules of 'u=' 1858 uri = URI-reference 1859 ; see RFC2396 and RFC2732 1861 ; sub-rules of 'e=', see rfc 2822 for definitions 1862 email-address = address-and-comment / dispname-and-address 1863 / addrspec 1864 address-and-comment = addrspec 1*SP "(" 1*email-safe ")" 1865 dispname-and-address = 1*email-safe 1*SP "<" addrspec ">" 1866 addrspec = dot-atom "@" domain 1868 ; sub-rules of 'p=' 1869 phone-number = phone *SP "(" 1*email-safe ")" / 1870 1*email-safe "<" phone ">" / 1871 phone 1873 phone = ["+"] DIGIT 1*(SP / "-" / DIGIT) 1875 ; sub-rules of 'c=' 1876 connection-address = multicast-address / unicast-address 1878 ; sub-rules of 'b=' 1879 bwtype = token 1881 bandwidth = 1*DIGIT 1883 ; sub-rules of 't=' 1884 start-time = time / "0" 1886 stop-time = time / "0" 1888 time = POS-DIGIT 9*DIGIT 1889 ; Decimal representation of NTP time in 1890 ; seconds since 1900. The representation 1891 ; of NTP time is an unbounded length field 1892 ; containing at least 10 digits. Unlike the 1893 ; 64-bit representation used elsewhere, time 1894 ; in SDP does not wrap in the year 2036. 1896 ; sub-rules of 'r=' and 'z=' 1897 repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] 1899 typed-time = 1*DIGIT [fixed-len-time-unit] 1901 fixed-len-time-unit = "d" / "h" / "m" / "s" 1903 ; sub-rules of 'k=' 1904 key-type = "prompt" / 1905 "clear:" text / 1906 "base64:" base64 / 1907 "uri:" uri 1909 base64 = *base64-unit [base64-pad] 1910 base64-unit = 4base64-char 1911 base64-pad = 2base64-char "==" / 3base64-char "=" 1912 base64-char = ALPHA / DIGIT / "+" / "/" 1913 ; sub-rules of 'a=' 1914 attribute = (att-field ":" att-value) / att-field 1916 att-field = token 1918 att-value = byte-string 1920 ; sub-rules of 'm=' 1921 media = token 1922 ;typically "audio", "video", "text" or 1923 ;"application" 1925 fmt = token 1926 ;typically an RTP payload type for audio 1927 ;and video media 1929 proto = token *("/" token) 1930 ;typically "RTP/AVP" or "udp" 1932 port = 1*DIGIT 1934 ; generic sub-rules: addressing 1935 unicast-address = IP4-address / IP6-address / FQDN / extn-addr 1937 multicast-address = IP4-multicast / IP6-multicast / FQDN 1938 / extn-addr 1940 IP4-multicast = m1 3( "." decimal-uchar ) 1941 "/" ttl [ "/" integer ] 1942 ; IPv4 multicast addresses may be in the 1943 ; range 224.0.0.0 to 239.255.255.255 1945 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / 1946 ("23" DIGIT ) 1948 IP6-multicast = hexpart [ "/" integer ] 1949 ; IPv6 address starting with FF 1951 ttl = (POS-DIGIT *2DIGIT) / "0" 1953 FQDN = 4*(alpha-numeric / "-" / ".") 1954 ; fully qualified domain name as specified 1955 ; in RFC1035 (and updates) 1957 IP4-address = b1 3("." decimal-uchar) 1959 b1 = decimal-uchar 1960 ; less than "224" 1962 ; The following is from RFC2373 Appendix B. It is a direct copy. 1963 IP6-address = hexpart [ ":" IP4-address ] 1965 hexpart = hexseq / hexseq "::" [ hexseq ] / 1966 "::" [ hexseq ] 1968 hexseq = hex4 *( ":" hex4) 1970 hex4 = 1*4HEXDIG 1972 ; Generic for other address families 1973 extn-addr = non-ws-string 1975 ; generic sub-rules: datatypes 1976 text = byte-string 1977 ;default is to interpret this as UTF8 text. 1978 ;ISO 8859-1 requires "a=charset:ISO-8859-1" 1979 ;session-level attribute to be used 1981 byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) 1982 ;any byte except NUL, CR or LF 1984 non-ws-string = 1*(VCHAR/%x80-FF) 1985 ;string of visible characters 1987 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 1988 / %x41-5A / %x5E-7E 1990 token = 1*(token-char) 1992 email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF 1993 ;any byte except NUL, CR, LF, or the quoting 1994 ;characters ()<> 1996 integer = POS-DIGIT *DIGIT 1998 ; generic sub-rules: primitives 1999 alpha-numeric = ALPHA / DIGIT 2001 POS-DIGIT = %x31-39 ; 1 - 9 2003 decimal-uchar = DIGIT 2004 / POS-DIGIT DIGIT 2005 / ("1" 2*(DIGIT)) 2006 / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) 2007 / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) 2009 ; external references: 2011 ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 2234 2012 ; URI-reference: from RFC2396 and RFC2732 2013 ; addr-spec: from RFC 2822 2015 10. Summary of Changes from RFC 2327 2017 The memo has been significantly restructured, incorporating a large 2018 number of clarifications to the specification in light of use. With 2019 the exception of those items noted below, the changes to the memo are 2020 intended to be backwards compatible clarifications. However, due to 2021 inconsistencies and unclear definitions in RFC 2327 it is likely that 2022 some implementations interpreted that memo in ways that differ from 2023 this version of SDP. 2025 The ABNF grammar in Section 9 has been extensively revised and 2026 updated, correcting a number of mistakes and incorporating the RFC 2027 3266 IPv6 extensions. Known inconsistencies between the grammar and 2028 the specification text have been resolved. 2030 A media type registration for SDP is included. Requirements for the 2031 registration of attributes and other parameters with IANA have been 2032 clarified and tightened (Section 8). It is noted that "text" and 2033 "message" are valid media types for use with SDP, but that "control" 2034 and "data" are under-specified and deprecated. 2036 RFC 2119 terms are now used throughout to specify requirements 2037 levels. Certain of those requirements, in particular in relation to 2038 parameter registration, are stricter than those in RFC 2327. 2040 The "RTP/SAVP" RTP profile and its "fmt" namespace are registered. 2042 The attributes "a=inactive" and "a=maxptime" have been added. 2044 RFC 2327 mandated that either "e=" or "p=" was required. Both are 2045 now optional, to reflect actual usage. 2047 The significant limitations of the "k=" field are noted, and its use 2048 is deprecated. 2050 Most uses of the "x-" prefix notation for experimental parameters are 2051 disallowed and the other uses are deprecated. 2053 11. Acknowledgements 2055 Many people in the IETF Multiparty Multimedia Session Control 2056 (MMUSIC) working group have made comments and suggestions 2057 contributing to this document. In particular, we would like to thank 2058 Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross 2059 Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna, 2060 Jonathan Lennox, Keith Drage, Sean Olson, Bernie Hoeneisen, Jonathan 2061 Rosenberg, John Elwell, Flemming Andreasen, Jon Peterson and Spencer 2062 Dawkins. 2064 12. References 2066 12.1. Normative References 2068 [1] Mockapetris, P., "Domain names - concepts and facilities", 2069 STD 13, RFC 1034, November 1987. 2071 [2] Mockapetris, P., "Domain names - implementation and 2072 specification", STD 13, RFC 1035, November 1987. 2074 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2075 Levels", BCP 14, RFC 2119, March 1997. 2077 [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2078 Specifications: ABNF", RFC 2234, November 1997. 2080 [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 2081 RFC 2279, January 1998. 2083 [6] Handley, M. and V. Jacobson, "SDP: Session Description 2084 Protocol", RFC 2327, April 1998. 2086 [7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2087 Resource Identifiers (URI): Generic Syntax", RFC 2396, 2088 August 1998. 2090 [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2091 Considerations Section in RFCs", BCP 26, RFC 2434, 2092 October 1998. 2094 [9] Hinden, R., Carpenter, B., and L. Masinter, "Format for Literal 2095 IPv6 Addresses in URL's", RFC 2732, December 1999. 2097 [10] Alvestrand, H., "Tags for the Identification of Languages", 2098 BCP 47, RFC 3066, January 2001. 2100 [11] Olson, S., Camarillo, G., and A. Roach, "Support for IPv6 in 2101 Session Description Protocol (SDP)", RFC 3266, June 2002. 2103 [12] Faltstrom, P., Hoffman, P., and A. Costello, 2104 "Internationalizing Domain Names in Applications (IDNA)", 2105 RFC 3490, March 2003. 2107 [13] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 2108 RFC 3548, July 2003. 2110 12.2. Informative References 2112 [14] Mills, D., "Network Time Protocol (Version 3) Specification, 2113 Implementation", RFC 1305, March 1992. 2115 [15] Handley, M., Perkins, C., and E. Whelan, "Session Announcement 2116 Protocol", RFC 2974, October 2000. 2118 [16] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2119 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 2120 Session Initiation Protocol", RFC 3261, June 2002. 2122 [17] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming 2123 Protocol (RTSP)", RFC 2326, April 1998. 2125 [18] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2126 Session Description Protocol (SDP)", RFC 3264, June 2002. 2128 [19] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, 2129 "Grouping of Media Lines in the Session Description Protocol 2130 (SDP)", RFC 3388, December 2002. 2132 [20] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 2133 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 2134 RFC 3550, July 2003. 2136 [21] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 2137 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 2139 [22] Casner, S., "Session Description Protocol (SDP) Bandwidth 2140 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, 2141 July 2003. 2143 [23] Huitema, C., "Real Time Control Protocol (RTCP) attribute in 2144 Session Description Protocol (SDP)", RFC 3605, October 2003. 2146 [24] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2147 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2148 RFC 3711, March 2004. 2150 [25] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating 2151 User Agent Capabilities in the Session Initiation Protocol 2152 (SIP)", RFC 3840, August 2004. 2154 [26] Westerlund, M., "A Transport Independent Bandwidth Modifier for 2155 the Session Description Protocol (SDP)", RFC 3890, 2156 September 2004. 2158 [27] International Telecommunications Union, "H.323 extended for 2159 loosely coupled conferences", ITU Recommendation H.332, 2160 September 1998. 2162 [28] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 2163 Norrman, "Key Management Extensions for Session Description 2164 Protocol (SDP) and Real Time Streaming Protocol (RTSP)", 2165 draft-ietf-mmusic-kmgmt-ext-12 (work in progress), 2166 November 2004. 2168 [29] Andreasen, F., Baugher, M., and D. Wing, "Session Description 2169 Protocol Security Descriptions for Media Streams", 2170 draft-ietf-mmusic-sdescriptions-07 (work in progress), 2171 July 2004. 2173 Authors' Addresses 2175 Mark Handley 2176 University College London 2177 Department of Computer Science 2178 Gower Street 2179 London WC1E 6BT 2180 UK 2182 Email: M.Handley@cs.ucl.ac.uk 2184 Van Jacobson 2185 Packet Design 2186 2465 Latham Street 2187 Mountain View, CA 94040 2188 USA 2190 Email: van@packetdesign.com 2192 Colin Perkins 2193 University of Glasgow 2194 Department of Computing Science 2195 17 Lilybank Gardens 2196 Glasgow G12 8QQ 2197 UK 2199 Email: csp@csperkins.org 2201 Intellectual Property Statement 2203 The IETF takes no position regarding the validity or scope of any 2204 Intellectual Property Rights or other rights that might be claimed to 2205 pertain to the implementation or use of the technology described in 2206 this document or the extent to which any license under such rights 2207 might or might not be available; nor does it represent that it has 2208 made any independent effort to identify any such rights. Information 2209 on the procedures with respect to rights in RFC documents can be 2210 found in BCP 78 and BCP 79. 2212 Copies of IPR disclosures made to the IETF Secretariat and any 2213 assurances of licenses to be made available, or the result of an 2214 attempt made to obtain a general license or permission for the use of 2215 such proprietary rights by implementers or users of this 2216 specification can be obtained from the IETF on-line IPR repository at 2217 http://www.ietf.org/ipr. 2219 The IETF invites any interested party to bring to its attention any 2220 copyrights, patents or patent applications, or other proprietary 2221 rights that may cover technology that may be required to implement 2222 this standard. Please address the information to the IETF at 2223 ietf-ipr@ietf.org. 2225 Disclaimer of Validity 2227 This document and the information contained herein are provided on an 2228 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2229 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2230 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2231 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2232 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2233 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2235 Copyright Statement 2237 Copyright (C) The Internet Society (2006). This document is subject 2238 to the rights, licenses and restrictions contained in BCP 78, and 2239 except as set forth therein, the authors retain all their rights. 2241 Acknowledgment 2243 Funding for the RFC Editor function is currently provided by the 2244 Internet Society.