idnits 2.17.1 draft-ietf-mmusic-sdp-new-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 2 instances of lines with control characters in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 12 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 == Line 568 has weird spacing: '...7 or p=+...' == 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 (September 4, 2003) is 7540 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) -- Looks like a reference, but probably isn't: 'RFC2974' on line 299 -- Looks like a reference, but probably isn't: 'RFC3261' on line 299 -- Looks like a reference, but probably isn't: 'RFC2326' on line 178 -- Looks like a reference, but probably isn't: 'RFC2119' on line 145 -- Looks like a reference, but probably isn't: 'RFC3264' on line 173 -- Looks like a reference, but probably isn't: 'RFC2279' on line 324 -- Looks like a reference, but probably isn't: 'RFC1305' on line 742 -- Looks like a reference, but probably isn't: 'RFC1889' on line 1491 -- Looks like a reference, but probably isn't: 'RFC1890' on line 1493 -- Looks like a reference, but probably isn't: 'RTCPSDP' on line 993 -- Looks like a reference, but probably isn't: 'RFC3066' on line 1322 -- Looks like a reference, but probably isn't: 'RFC2434' on line 1485 -- Looks like a reference, but probably isn't: 'RFC2234' on line 1634 == Unused Reference: '1' is defined on line 1955, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1958, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1961, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1964, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1967, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1972, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1975, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1979, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1982, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1985, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1989, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1992, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1995, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2279 (ref. '3') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2434 (ref. '4') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3066 (ref. '5') (Obsoleted by RFC 4646, RFC 4647) -- Obsolete informational reference (is this intentional?): RFC 1305 (ref. '6') (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 1889 (ref. '7') (Obsoleted by RFC 3550) -- Obsolete informational reference (is this intentional?): RFC 1890 (ref. '8') (Obsoleted by RFC 3551) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '11') (Obsoleted by RFC 7826) Summary: 6 errors (**), 0 flaws (~~), 19 warnings (==), 21 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: March 4, 2004 C. Perkins 7 University of Glasgow 8 September 4, 2003 10 SDP: Session Description Protocol 11 draft-ietf-mmusic-sdp-new-14.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on March 4, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 This memo defines the Session Description Protocol (SDP). SDP is 42 intended for describing multimedia sessions for the purposes of 43 session announcement, session invitation, and other forms of 44 multimedia session initiation. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 49 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . 4 50 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . 5 51 3.1 Multicast Announcement . . . . . . . . . . . . . . . . . . . 5 52 3.2 Session Initiation . . . . . . . . . . . . . . . . . . . . . 5 53 3.3 Streaming media . . . . . . . . . . . . . . . . . . . . . . 5 54 3.4 Email and the World Wide Web . . . . . . . . . . . . . . . . 5 55 4. Requirements and Recommendations . . . . . . . . . . . . . . 6 56 4.1 Media Information . . . . . . . . . . . . . . . . . . . . . 7 57 4.2 Timing Information . . . . . . . . . . . . . . . . . . . . . 7 58 4.3 Private Sessions . . . . . . . . . . . . . . . . . . . . . . 8 59 4.4 Obtaining Further Information about a Session . . . . . . . 8 60 4.5 Categorisation . . . . . . . . . . . . . . . . . . . . . . . 8 61 4.6 Internationalization . . . . . . . . . . . . . . . . . . . . 8 62 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . 8 63 5.1 Protocol Version ("v=") . . . . . . . . . . . . . . . . . . 11 64 5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . . 11 65 5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . . . 12 66 5.4 Session and Media Information ("i=") . . . . . . . . . . . . 12 67 5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . . 13 69 5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . . 14 70 5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . . 16 71 5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . . 17 72 5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . . 18 73 5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . . . 18 74 5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . . . 19 75 5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . . . 20 76 5.14 Media Announcements ("m=") . . . . . . . . . . . . . . . . . 21 77 6. Suggested Attributes . . . . . . . . . . . . . . . . . . . . 25 78 7. Communicating Conference Control Policy . . . . . . . . . . 30 79 8. Security Considerations . . . . . . . . . . . . . . . . . . 31 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32 81 9.1 Media types ("media") . . . . . . . . . . . . . . . . . . . 32 82 9.2 Transport protocols ("proto") . . . . . . . . . . . . . . . 32 83 9.3 Media formats ("fmt") . . . . . . . . . . . . . . . . . . . 33 84 9.4 Attribute names ("att-field") . . . . . . . . . . . . . . . 33 85 9.5 Bandwidth specifiers ("bwtype") . . . . . . . . . . . . . . 34 86 9.6 Network types ("nettype") . . . . . . . . . . . . . . . . . 34 87 9.7 Address types ("addrtype") . . . . . . . . . . . . . . . . . 35 88 9.8 Registration Procedure . . . . . . . . . . . . . . . . . . . 35 89 A. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 35 90 B. Changes from RFC 2327 . . . . . . . . . . . . . . . . . . . 41 91 C. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 42 92 Normative References . . . . . . . . . . . . . . . . . . . . 42 93 Informative References . . . . . . . . . . . . . . . . . . . 42 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 43 95 Intellectual Property and Copyright Statements . . . . . . . 45 97 1. Introduction 99 When initiating multimedia teleconferences, voice-over-IP calls, 100 streaming video, or other real-time sessions, there is a requirement 101 to convey media details, transport addresses, and other session 102 description metadata to the participants. 104 SDP provides a standard representation for such information, 105 irrespective of how that information is transported. SDP is purely a 106 format for session description - it does not incorporate a transport 107 protocol, and is intended to use different transport protocols as 108 appropriate, including the Session Announcement Protocol [RFC2974], 109 Session Initiation Protocol [RFC3261], Real-Time Streaming Protocol 110 [RFC2326], electronic mail using the MIME extensions, and the 111 Hypertext Transport Protocol. 113 SDP is intended to be general purpose so that it can be used in a 114 wide range of network environments and applications. However, it is 115 not intended to support negotiation of session content or media 116 encodings: this is viewed as outside the scope of session 117 description. 119 2. Glossary of Terms 121 The following terms are used in this document, and have specific 122 meaning within the context of this document. 124 Conference: A multimedia conference is a set of two or more 125 communicating users along with the software they are using to 126 communicate. 128 Session: A multimedia session is a set of multimedia senders and 129 receivers and the data streams flowing from senders to receivers. 130 A multimedia conference is an example of a multimedia session. 132 Session Advertisement: See session announcement. 134 Session Announcement: A session announcement is a mechanism by which 135 a session description is conveyed to users in a pro-active 136 fashion, i.e., the session description was not explicitly 137 requested by the user. 139 Session Description: A well defined format for conveying sufficient 140 information to discover and participate in a multimedia session. 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [RFC2119]. 146 3. Examples of SDP Usage 148 3.1 Multicast Announcement 150 In order to assist the advertisement of multicast multimedia 151 conferences and other multicast sessions, and to communicate the 152 relevant session setup information to prospective participants, a 153 distributed session directory may be used. An instance of such a 154 session directory periodically sends packets containing a description 155 of the session to a well known multicast group. These advertisements 156 are received by other session directories such that potential remote 157 participants can use the session description to start the tools 158 required to participate in the session. 160 One protocol commonly used to implement such a distributed directory 161 is the Session Announcement Protocol, SAP [RFC2974]. SDP provides the 162 recommended session description format for such announcements. 164 3.2 Session Initiation 166 The Session Initiation Protocol, SIP [RFC3261] is an application 167 layer control protocol for creating, modifying and terminating 168 sessions such as Internet multimedia conferences, Internet telephone 169 calls and multimedia distribution. The SIP messages used to create 170 sessions carry session descriptions which allow participants to agree 171 on a set of compatible media types. These session descriptions are 172 commonly formatted using SDP. When used with SIP, the offer/answer 173 model [RFC3264] provides a limited framework for negotiation using 174 SDP. 176 3.3 Streaming media 178 The Real Time Streaming Protocol, RTSP [RFC2326], is an application- 179 level protocol for control over the delivery of data with real-time 180 properties. RTSP provides an extensible framework to enable 181 controlled, on-demand delivery of real-time data, such as audio and 182 video. An RTSP client and server negotiate an appropriate set of 183 parameters for media delivery, partially using SDP syntax to describe 184 those parameters. 186 3.4 Email and the World Wide Web 188 Alternative means of conveying session descriptions include 189 electronic mail and the World Wide Web. For both email and WWW 190 distribution, the use of the MIME content type "application/sdp" MUST 191 be used. This enables the automatic launching of applications for 192 participation in the session from the WWW client or mail reader in a 193 standard manner. 195 Note that announcements of multicast sessions made only via email or 196 the World Wide Web (WWW) do not have the property that the receiver 197 of a session announcement can necessarily receive the session because 198 the multicast sessions may be restricted in scope, and access to the 199 WWW server or reception of email is possible outside this scope. SAP 200 announcements do not suffer from this mismatch. 202 4. Requirements and Recommendations 204 The purpose of SDP is to convey information about media streams in 205 multimedia sessions to allow the recipients of a session description 206 to participate in the session. SDP is primarily intended for use in 207 an internetwork, although it is sufficiently general that it can 208 describe conferences in other network environments. 210 A multimedia session, for these purposes, is defined as a set of 211 media streams that exist for some duration of time. Media streams 212 can be many-to-many. The times during which the session is active 213 need not be continuous. 215 Thus far, multicast based sessions on the Internet have differed from 216 many other forms of conferencing in that anyone receiving the traffic 217 can join the session (unless the session traffic is encrypted). In 218 such an environment, SDP serves two primary purposes. It is a means 219 to communicate the existence of a session, and is a means to convey 220 sufficient information to enable joining and participating in the 221 session. In a unicast environment, only the latter purpose is likely 222 to be relevant. 224 Thus SDP includes: 226 o Session name and purpose 228 o Time(s) the session is active 230 o The media comprising the session 232 o Information needed to receive those media (addresses, ports, 233 formats and so on) 235 As resources necessary to participate in a session may be limited, 236 some additional information may also be desirable: 238 o Information about the bandwidth to be used by the conference 240 o Contact information for the person responsible for the session 242 In general, SDP must convey sufficient information to enable 243 applications to join a session (with the possible exception of 244 encryption keys) and to announce the resources to be used to non- 245 participants that may need to know. 247 4.1 Media Information 249 SDP includes: 251 o The type of media (video, audio, etc) 253 o The transport protocol (RTP/UDP/IP, H.320, etc) 255 o The format of the media (H.261 video, MPEG video, etc) 257 For an IP multicast session, the following are also conveyed: 259 o Multicast address for media 261 o Transport port for media 263 This address and port are the destination address and destination 264 port of the multicast stream, whether being sent, received, or both. 266 For an IP unicast session, the following are conveyed: 268 o Remote address for media 270 o Transport port for media 272 The semantics of this address and port depend on the media and 273 transport protocol defined. By default, this is the remote address 274 and remote port to which data is sent, however some media types may 275 redefine this behaviour. 277 4.2 Timing Information 279 Sessions may either be bounded or unbounded in time. Whether or not 280 they are bounded, they may be only active at specific times. 282 SDP can convey: 284 o An arbitrary list of start and stop times bounding the session 286 o For each bound, repeat times such as "every Wednesday at 10am for 287 one hour" 289 This timing information is globally consistent, irrespective of local 290 time zone or daylight saving time. 292 4.3 Private Sessions 294 It is possible to create both public sessions and private sessions. 295 SDP itself does not distinguish between these: private sessions are 296 typically conveyed by encrypting the session description during 297 distribution. The details of how encryption is performed are 298 dependent on the mechanism used to convey SDP - e.g. mechanisms are 299 defined for SDP transported using SAP [RFC2974] and SIP [RFC3261]. 301 If a session announcement is private it is possible to use that 302 private announcement to convey encryption keys necessary to decode 303 each of the media in a conference, including enough information to 304 know which encryption scheme is used for each media. 306 4.4 Obtaining Further Information about a Session 308 A session description should convey enough information to decide 309 whether or not to participate in a session. SDP may include 310 additional pointers in the form of Universal Resources Identifiers 311 (URIs) for more information about the session. 313 4.5 Categorisation 315 When many session descriptions are being distributed by SAP, or any 316 other advertisement mechanism, it may be desirable to filter 317 announcements that are of interest from those that are not. SDP 318 supports a categorisation mechanism for sessions that is capable of 319 being automated. 321 4.6 Internationalization 323 The SDP specification recommends the use of the ISO 10646 character 324 sets in the UTF-8 encoding [RFC2279] to allow many different 325 languages to be represented. However, to assist in compact 326 representations, SDP also allows other character sets such as ISO 327 8859-1 to be used when desired. Internationalization only applies to 328 free-text fields (session name and background information), and not 329 to SDP as a whole. 331 5. SDP Specification 333 SDP session descriptions are entirely textual using the ISO 10646 334 character set in UTF-8 encoding. SDP field names and attribute names 335 use only the US-ASCII subset of UTF-8, but textual fields and 336 attribute values MAY use the full ISO 10646 character set. The 337 textual form, as opposed to a binary encoding such as ASN.1 or XDR, 338 was chosen to enhance portability, to enable a variety of transports 339 to be used (e.g, session description in a MIME email message) and to 340 allow flexible, text-based toolkits (e.g., Tcl/Tk) to be used to 341 generate and to process session descriptions. However, since SDP may 342 be used in environments where the maximum permissable size of a 343 session description is limited (e.g. SAP announcements; SIP 344 transported in UDP), the encoding is deliberately compact. Also, 345 since announcements may be transported via very unreliable means or 346 damaged by an intermediate caching server, the encoding was designed 347 with strict order and formatting rules so that most errors would 348 result in malformed announcements which could be detected easily and 349 discarded. This also allows rapid discarding of encrypted 350 announcements for which a receiver does not have the correct key. 352 An SDP session description consists of a number of lines of text of 353 the form: 355 = 357 where MUST be exactly one case-significant character and 358 is structured text whose format depends on . In 359 general is either a number of fields delimited by a single 360 space character, or a free format string. Whitespace MUST NOT be used 361 either side of the "=" sign. 363 A session description consists of a session-level section followed by 364 zero or more media-level sections. The session-level part starts 365 with a "v=" line and continues to the first media-level section. The 366 media description starts with an "m=" line and continues to the next 367 media description or end of the whole session description. In 368 general, session-level values are the default for all media unless 369 overridden by an equivalent media-level value. 371 Some lines in each description are REQUIRED and some are OPTIONAL but 372 all MUST appear in exactly the order given here (the fixed order 373 greatly enhances error detection and allows for a simple parser). 374 OPTIONAL items are marked with a "*". 376 Session description 377 v= (protocol version) 378 o= (owner/creator and session identifier). 379 s= (session name) 380 i=* (session information) 381 u=* (URI of description) 382 e=* (email address) 383 p=* (phone number) 384 c=* (connection information - not required if included in 385 all media) 386 b=* (bandwidth information) 387 One or more time descriptions (see below) 388 z=* (time zone adjustments) 389 k=* (encryption key) 390 a=* (zero or more session attribute lines) 391 Zero or more media descriptions (see below) 393 Time description 394 t= (time the session is active) 395 r=* (zero or more repeat times) 397 Media description 398 m= (media name and transport address) 399 i=* (media title) 400 c=* (connection information - optional if included at 401 session-level) 402 b=* (bandwidth information) 403 k=* (encryption key) 404 a=* (zero or more media attribute lines) 406 The set of type letters is deliberately small and not intended to be 407 extensible -- an SDP parser MUST completely ignore any announcement 408 that contains a type letter that it does not understand. The 409 attribute mechanism ("a=" described below) is the primary means for 410 extending SDP and tailoring it to particular applications or media. 411 Some attributes (the ones listed in this document) have a defined 412 meaning but others may be added on an application-, media- or 413 session-specific basis. An SDP parser MUST ignore any attribute it 414 doesn't understand. 416 The connection ("c=") and attribute ("a=") information in the 417 session-level section applies to all the media of that session unless 418 overridden by connection information or an attribute of the same name 419 in the media description. For instance, in the example below, each 420 media behaves as if it were given a "recvonly" attribute. 422 An example SDP description is: 424 v=0 425 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 426 s=SDP Seminar 427 i=A Seminar on the session description protocol 428 u=http://www.example.com/seminars/sdp.pdf 429 e=j.doe@example.com (Jane Doe) 430 c=IN IP4 224.2.17.12/127 431 t=2873397496 2873404696 432 a=recvonly 433 m=audio 49170 RTP/AVP 0 434 m=video 51372 RTP/AVP 31 435 m=application 32416 udp wb 436 a=orient:portrait 438 Text records such as the session name and information are octet 439 strings which may contain any octet with the exceptions of 0x00 440 (Nul), 0x0a (ASCII newline) and 0x0d (ASCII carriage return). The 441 sequence CRLF (0x0d0a) is used to end a record, although parsers 442 SHOULD be tolerant and also accept records terminated with a single 443 newline character. By default these byte strings contain ISO-10646 444 characters in UTF-8 encoding, but this default MAY be changed using 445 the "charset" attribute. 447 5.1 Protocol Version ("v=") 449 v=0 451 The "v=" field gives the version of the Session Description Protocol. 452 There is no minor version number. 454 5.2 Origin ("o=") 456 o=
457
459 The "o=" field gives the originator of the session (her username and 460 the address of the user's host) plus a session id and session version 461 number. 463 is the user's login on the originating host, or it is "-" 464 if the originating host does not support the concept of user ids. 465 MUST NOT contain spaces. 467 is a numeric string such that the tuple of , 468 , ,
and
form a 469 globally unique identifier for the session. The method of session 470 id allocation is up to the creating tool, but it has been 471 suggested that a Network Time Protocol (NTP) format timestamp be 472 used to ensure uniqueness [RFC1305]. 474 is a version number for this announcement. It is needed for 475 proxy announcements to detect which of several announcements for 476 the same session is the most recent. Again its usage is up to the 477 creating tool, so long as is increased when a 478 modification is made to the session data. Again, it is RECOMMENDED 479 (but not mandatory) that an NTP format timestamp is used. 481 is a text string giving the type of network. 482 Initially "IN" is defined to have the meaning "Internet". 484
is a text string giving the type of the address that 485 follows. Initially "IP4" and "IP6" are defined. 487
is the globally unique address of the machine from which 488 the session was created. For an address type of IP4, this is 489 either the fully-qualified domain name of the machine, or the 490 dotted-decimal representation of the IP version 4 address of the 491 machine. For an address type of IP6, this is either the 492 fully-qualified domain name of the machine, or the compressed 493 textual representation of the IP version 6 address of the machine. 494 For both IP4 and IP6, the fully-qualified domain name is the form 495 that SHOULD be given unless this is unavailable, in which case the 496 globally unique address may be substituted. A local IP address 497 MUST NOT be used in any context where the SDP description might 498 leave the scope in which the address is meaningful. 500 In general, the "o=" field serves as a globally unique identifier for 501 this version of this session description, and the subfields excepting 502 the version taken together identify the session irrespective of any 503 modifications. 505 5.3 Session Name ("s=") 507 s= 509 The "s=" field is the session name. There MUST be one and only one 510 "s=" field per session description. The "s=" field MUST NOT be empty 511 and SHOULD contain ISO 10646 characters (but see also the "a=charset" 512 attribute). If a session has no meaningful name, the value "s= " 513 SHOULD be used (i.e. a single space as the session name). 515 5.4 Session and Media Information ("i=") 517 i= 519 The "i=" field is information about the session. There may be at 520 most one session-level "i=" field per session description, and at 521 most one "i=" field per media. Although it may be omitted, this is 522 NOT RECOMMENDED for session announcements, and user interfaces for 523 composing sessions should require text to be entered. If it is 524 present it must contain ISO 10646 characters (but see also the 525 "a=charset" attribute below). 527 A single "i=" field can also be used for each media definition. In 528 media definitions, "i=" fields are primarily intended for labeling 529 media streams. As such, they are most likely to be useful when a 530 single session has more than one distinct media stream of the same 531 media type. An example would be two different whiteboards, one for 532 slides and one for feedback and questions. 534 5.5 URI ("u=") 536 u= 538 A URI is a Universal Resource Identifier as used by WWW clients. The 539 URI should be a pointer to additional information about the 540 conference. This field is OPTIONAL, but if it is present it MUST be 541 specified before the first media field. No more than one URI field is 542 allowed per session description. 544 5.6 Email Address and Phone Number ("e=" and "p=") 546 e= 547 p= 549 These specify contact information for the person responsible for the 550 conference. This is not necessarily the same person that created the 551 conference announcement. 553 Inclusion of an email address or phone number is OPTIONAL. Note that 554 the previous version of SDP specified that either an email field or a 555 phone field MUST be specified, but this was widely ignored. The 556 change brings the specification into line with common usage. 558 If the email addres or phone number are present, they MUST be 559 specified before the first media field. More than one email or phone 560 field can be given for a session description. 562 Phone numbers SHOULD be given in the conventional international 563 format: preceded by a "+" and the international country code. There 564 must be a space or a hyphen ("-") between the country code and the 565 rest of the phone number. Spaces and hyphens may be used to split up 566 a phone field to aid readability if desired. For example: 568 p=+44-171-380-7777 or p=+1 617 555 6011 570 Both email addresses and phone numbers can have an optional free text 571 string associated with them, normally giving the name of the person 572 who may be contacted. This should be enclosed in parenthesis if it 573 is present. For example: 575 e=j.doe@example.com (Jane Doe) 577 The alternative RFC822 name quoting convention is also allowed for 578 both email addresses and phone numbers. For example: 580 e=Jane Doe 582 The free text string SHOULD be in the ISO-10646 character set with 583 UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if 584 the appropriate charset session-level attribute is set. 586 5.7 Connection Data ("c=") 588 c=
590 The "c=" field contains connection data. 592 A session announcement MUST contain either at least one "c=" field in 593 each media description (see below) or a single "c=" field at the 594 session-level. It MAY contain a single session-level "c=" field and 595 additional "c=" field(s) per media description, in which case the 596 per-media values override the session-level settings for the 597 respective media. 599 The first sub-field is the network type, which is a text string 600 giving the type of network. Initially "IN" is defined to have the 601 meaning "Internet". 603 The second sub-field is the address type. This allows SDP to be used 604 for sessions that are not IP based. Currently only IP4 and IP6 are 605 defined. 607 The third sub-field is the connection address. Optional extra 608 sub-fields MAY be added after the connection address depending on the 609 value of the
field. 611 For IP4 and IP6 addresses, the connection address is defined as 612 follows: 614 o If the session is multicast, the connection address will be an IP 615 multicast group address. If the session is not multicast, then 616 the connection address contains the unicast IP address of the 617 expected data source or data relay or data sink as determined by 618 additional attribute fields. It is not expected that unicast 619 addresses will be given in a session description that is 620 communicated by a multicast announcement, though this is not 621 prohibited. 623 o Conferences using an IPv4 multicast connection address MUST also 624 have a time to live (TTL) value present in addition to the 625 multicast address. The TTL and the address together define the 626 scope with which multicast packets sent in this conference will be 627 sent. TTL values MUST be in the range 0-255. 629 The TTL for the session is appended to the address using a slash as a 630 separator. An example is: 632 c=IN IP4 224.2.36.42/127 634 IPv6 multicast does not use TTL scoping, and hence the TTL value MUST 635 NOT be present for IPv6 multicast. It is expected that IPv6 scoped 636 addresses will be used to limit the scope of conferences. 638 Hierarchical or layered encoding schemes are data streams where the 639 encoding from a single media source is split into a number of layers. 640 The receiver can choose the desired quality (and hence bandwidth) by 641 only subscribing to a subset of these layers. Such layered encodings 642 are normally transmitted in multiple multicast groups to allow 643 multicast pruning. This technique keeps unwanted traffic from sites 644 only requiring certain levels of the hierarchy. For applications 645 requiring multiple multicast groups, we allow the following notation 646 to be used for the connection address: 648 [/]/ 650 If the number of addresses is not given it is assumed to be one. 651 Multicast addresses so assigned are contiguously allocated above the 652 base address, so that, for example: 654 c=IN IP4 224.2.1.1/127/3 656 would state that addresses 224.2.1.1, 224.2.1.2 and 224.2.1.3 are to 657 be used at a ttl of 127. This is semantically identical to including 658 multiple "c=" lines in a media description: 660 c=IN IP4 224.2.1.1/127 661 c=IN IP4 224.2.1.2/127 662 c=IN IP4 224.2.1.3/127 664 Similarly, an IPv6 example would be: 666 c=IN IP6 FF15::101/3 668 which is semantically equivalent to: 670 c=IN IP6 FF15::101 671 c=IN IP6 FF15::102 672 c=IN IP6 FF15::103 674 (remembering that the TTL field is not present in IPv6 multicast). 676 Multiple addresses or "c=" lines MAY be specified on a per-media 677 basis. They MUST NOT be specified for a session-level "c=" field. 679 The slash notation described above MUST NOT be used for IP unicast 680 addresses. 682 5.8 Bandwidth ("b=") 684 b=: 686 This specifies the proposed bandwidth to be used by the session or 687 media, and is OPTIONAL. 689 The is in kilobits per second by default. Modifiers 690 MAY specify that alternative units are to be used (the modifiers 691 defined in this memo use the default units). 693 The is a single alphanumeric word giving the meaning of 694 the bandwidth figure. Two modifiers are initially defined: 696 CT Conference Total 697 If the bandwidth of a session or media in a session is 698 different from the bandwidth implicit from the scope, a 699 "b=CT:..." line should be supplied for the session giving 700 the proposed upper limit to the bandwidth used. The primary 701 purpose of this is to give an approximate idea as to whether 702 two or more sessions can co-exist simultaneously. 704 AS Application-Specific Maximum 705 The bandwidth is interpreted to be application-specific (it 706 will be the application's concept of maximum bandwidth). 707 Normally this will coincide with what is set on the 708 application's "maximum bandwidth" control if applicable. 709 For RTP based applications, AS gives the RTP "session 710 bandwidth" as defined in section 6.2 of [RFC1889]. 712 Note that CT gives a total bandwidth figure for all the media at all 713 sites. AS gives a bandwidth figure for a single media at a single 714 site, although there may be many sites sending simultaneously. 716 Tool writers MAY define experimental bandwidth modifiers by prefixing 717 their modifier with "X-". For example: 719 b=X-YZ:128 721 Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers 722 SHOULD be registered with IANA in the standard namespace. SDP parsers 723 MUST ignore bandwidth fields with unknown modifiers. Modifiers MUST 724 be alpha-numeric and, although no length limit is given, they are 725 recommended to be short. 727 5.9 Timing ("t=") 729 t= 731 "t=" fields specify the start and stop times for a session. Multiple 732 "t=" fields MAY be used if a session is active at multiple 733 irregularly spaced times; each additional "t=" field specifies an 734 additional period of time for which the session will be active. If 735 the session is active at regular times, an "r=" field (see below) 736 should be used in addition to and following a "t=" field - in which 737 case the "t=" field specifies the start and stop times of the repeat 738 sequence. 740 The first and second sub-fields give the start and stop times for the 741 session respectively. These values are the decimal representation of 742 Network Time Protocol (NTP) time values in seconds [RFC1305]. To 743 convert these values to UNIX time, subtract decimal 2208988800. 745 NTP timestamps are 64 bit values which wrap sometime in the year 746 2036. Since SDP uses an arbitrary length decimal representation, 747 this should not cause an issue (SDP timestamps will continue counting 748 seconds since 1900, NTP will use the value modulo the 64 bit limit). 750 If the stop-time is set to zero, then the session is not bounded, 751 though it will not become active until after the start-time. If the 752 start-time is also zero, the session is regarded as permanent. 754 User interfaces SHOULD strongly discourage the creation of unbounded 755 and permanent sessions as they give no information about when the 756 session is actually going to terminate, and so make scheduling 757 difficult. 759 The general assumption may be made, when displaying unbounded 760 sessions that have not timed out to the user, that an unbounded 761 session will only be active until half an hour from the current time 762 or the session start time, whichever is the later. If behaviour 763 other than this is required, an end-time should be given and modified 764 as appropriate when new information becomes available about when the 765 session should really end. 767 Permanent sessions may be shown to the user as never being active 768 unless there are associated repeat times which state precisely when 769 the session will be active. In general, permanent sessions SHOULD 770 NOT be created for any session expected to have a duration of less 771 than 2 months, and should be discouraged for sessions expected to 772 have a duration of less than 6 months. 774 5.10 Repeat Times ("r=") 776 r= 778 "r=" fields specify repeat times for a session. For example, if a 779 session is active at 10am on Monday and 11am on Tuesday for one hour 780 each week for three months, then the in the 781 corresponding "t=" field would be the NTP representation of 10am on 782 the first Monday, the would be 1 week, the would be 1 hour, and the offsets would be zero and 25 784 hours. The corresponding "t=" field stop time would be the NTP 785 representation of the end of the last session three months later. By 786 default all fields are in seconds, so the "r=" and "t=" fields might 787 be: 789 t=3034423619 3042462419 790 r=604800 3600 0 90000 792 To make description more compact, times may also be given in units of 793 days, hours or minutes. The syntax for these is a number immediately 794 followed by a single case-sensitive character. Fractional units are 795 not allowed - a smaller unit should be used instead. The following 796 unit specification characters are allowed: 798 d - days (86400 seconds) 799 h - hours (3600 seconds) 800 m - minutes (60 seconds) 801 s - seconds (allowed for completeness but not recommended) 803 Thus, the above announcement could also have been written: 805 r=7d 1h 0 25h 807 Monthly and yearly repeats cannot be directly specified with a single 808 SDP repeat time - instead separate "t=" fields should be used to 809 explicitly list the session times. 811 5.11 Time Zones ("z=") 813 z= .... 815 To schedule a repeated session which spans a change from daylight- 816 saving time to standard time or vice-versa, it is necessary to 817 specify offsets from the base time. This is required because 818 different time zones change time at different times of day, different 819 countries change to or from daylight time on different dates, and 820 some countries do not have daylight saving time at all. 822 Thus in order to schedule a session that is at the same time winter 823 and summer, it must be possible to specify unambiguously by whose 824 time zone a session is scheduled. To simplify this task for 825 receivers, we allow the sender to specify the NTP time that a time 826 zone adjustment happens and the offset from the time when the session 827 was first scheduled. The "z=" field allows the sender to specify a 828 list of these adjustment times and offsets from the base time. 830 An example might be: 832 z=2882844526 -1h 2898848070 0 834 This specifies that at time 2882844526 the time base by which the 835 session's repeat times are calculated is shifted back by 1 hour, and 836 that at time 2898848070 the session's original time base is restored. 837 Adjustments are always relative to the specified start time - they 838 are not cumulative. Adjustments apply to all "t=" and "r=" lines in 839 a session description. 841 If a session is likely to last several years, it is expected that the 842 session announcement will be modified periodically rather than 843 transmit several years worth of adjustments in one announcement. 845 5.12 Encryption Keys ("k=") 847 k= 848 k=: 850 If transported over a secure and trusted channel, the session 851 description protocol MAY be used to convey encryption keys. A key 852 field is permitted before the first media entry (in which case it 853 applies to all media in the session), or for each media entry as 854 required. 856 The format of keys and their usage is outside the scope of this 857 document, but see [RFC1890] for an example. 859 The method indicates the mechanism to be used to obtain a usable key 860 by external means, or from the encoded encryption key given. The 861 following methods are defined: 863 k=clear: 865 The encryption key is included untransformed in this key field. 866 This method MUST NOT be used unless it can be guaranteed that 867 the SDP is conveyed over a secure channel. 869 k=base64: 870 The encryption key is included in this key field but has been 871 base64 encoded because it includes characters that are 872 prohibited in SDP. This method MUST NOT be used unless it can 873 be guaranteed that the SDP is conveyed over a secure channel. 875 k=uri: 877 A Universal Resource Identifier is included in the key field. 878 The URI refers to the data containing the key, and may require 879 additional authentication before the key can be returned. When 880 a request is made to the given URI, the MIME content-type of 881 the reply specifies the encoding for the key in the reply. 883 k=prompt 885 No key is included in this SDP description, but the session or 886 media stream referred to by this key field is encrypted. The 887 user should be prompted for the key when attempting to join the 888 session, and this user-supplied key should then be used to 889 decrypt the media streams. The use of user-specified keys is 890 NOT RECOMMENDED, since such keys tend to have weak security 891 properties. 893 The key field MUST NOT be used unless it can be guaranteed that the 894 SDP is conveyed over a secure and trusted channel. An example of such 895 a channel might be SDP embedded inside an S/MIME message. 897 5.13 Attributes ("a=") 899 a= 900 a=: 902 Attributes are the primary means for extending SDP. Attributes may 903 be defined to be used as "session-level" attributes, "media-level" 904 attributes, or both. 906 A media description may have any number of attributes ("a=" fields) 907 which are media specific. These are referred to as "media-level" 908 attributes and add information about the media stream. Attribute 909 fields can also be added before the first media field; these 910 "session-level" attributes convey additional information that applies 911 to the conference as a whole rather than to individual media; an 912 example might be the conference's floor control policy. 914 Attribute fields may be of two forms: 916 o property attributes: 917 A property attribute is simply of the form "a=". 919 These are binary attributes, and the presence of the 920 attribute conveys that the attribute is a property of 921 the session. An example might be "a=recvonly". 923 o value attributes: 924 A value attribute is of the form "a=:". 925 For example, a whiteboard could have the value attribute 926 "a=orient:landscape" 928 Attribute interpretation depends on the media tool being invoked. 929 Thus receivers of session descriptions should be configurable in 930 their interpretation of announcements in general and of attributes in 931 particular. 933 Attribute names MUST be in the US-ASCII subset of ISO-10646/UTF-8. 935 Attribute values are octet strings, and MAY use any octet value 936 except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute 937 values are to be interpreted as in ISO-10646 character set with UTF-8 938 encoding. Unlike other text fields, attribute values are NOT 939 normally affected by the "charset" attribute as this would make 940 comparisons against known values problematic. However, when an 941 attribute is defined, it can be defined to be charset-dependent, in 942 which case it's value should be interpreted in the session charset 943 rather than in ISO-10646. 945 Attributes MUST be registered with IANA (see Section 9). If an 946 attribute is received that is not understood, it MUST be ignored by 947 the receiver. 949 5.14 Media Announcements ("m=") 951 m= 953 A session description may contain a number of media descriptions. 954 Each media description starts with an "m=" field, and is terminated 955 by either the next "m=" field or by the end of the session 956 description. A media field has several sub-fields. 958 The first sub-field is the media type. Currently defined media are 959 "audio", "video", "application", "data" and "control", though this 960 list may be extended in future. The difference between "application" 961 and "data" is that the former is a media flow such as whiteboard 962 information, and the latter is bulk-data transfer such as 963 multicasting of program executables which will not typically be 964 displayed to the user. "control" is used to specify an additional 965 conference control channel for the session. 967 The second sub-field is the transport port to which the media stream 968 is sent. The meaning of the transport port depends on the network 969 being used as specified in the relevant "c=" field, and on the 970 transport protocol defined in the third sub-field. Other ports used 971 by the media application (such as the RTCP port [RFC1889]) MAY be 972 derived algorithmically from the base media port or MAY be specified 973 in a separate attribute (e.g. "a=rtcp:" as defined in [RTCPSDP]). 975 For applications where hierarchically encoded streams are being sent 976 to a unicast address, it may be necessary to specify multiple 977 transport ports. This is done using a similar notation to that used 978 for IP multicast addresses in the "c=" field: 980 m= / 982 In such a case, the ports used depend on the transport protocol. For 983 RTP, the default is that only the even numbered ports are used for 984 data and the corresponding one-higher odd port is used for RTCP. For 985 example: 987 m=video 49170/2 RTP/AVP 31 989 would specify that ports 49170 and 49171 form one RTP/RTCP pair and 990 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the 991 transport protocol and 31 is the format (see below). If non- 992 contiguous ports are required, they must be signalled using a 993 separate attribute (e.g. "a=rtcp:" as defined in [RTCPSDP]). 995 If multiple addresses are specified in the "c=" field and multiple 996 ports are specified in the "m=" field, a one-to-one mapping from port 997 to the corresponding address is implied. For example: 999 c=IN IP4 224.2.1.1/127/2 1000 m=video 49170/2 RTP/AVP 31 1002 would imply that address 224.2.1.1 is used with ports 49170 and 1003 49171, and address 224.2.1.2 is used with ports 49172 and 49173. 1005 The third sub-field is the transport protocol. The transport 1006 protocol values are dependent on the address-type field in the "c=" 1007 fields. Thus a "c=" field of IP4 defines that the transport protocol 1008 runs over IP4. For IP4, it is normally expected that most media 1009 traffic will be carried as RTP over UDP. The following transport 1010 protocols are defined, but may be extended through registration of 1011 new protocols with IANA (see Section 9): 1013 RTP/AVP - the IETF's Realtime Transport Protocol using the 1014 Audio/Video profile carried over UDP. 1016 udp - User Datagram Protocol 1017 TCP - Transmission Control Protocol 1019 If an application uses a single combined proprietary media format and 1020 transport protocol over UDP, then simply specifying the transport 1021 protocol as udp and using the format field to distinguish the 1022 combined protocol is recommended. If a transport protocol is used 1023 over UDP to carry several distinct media types that need to be 1024 distinguished by a session directory, then specifying the transport 1025 protocol and media format separately is necessary. RTP is an example 1026 of a transport-protocol that carries multiple payload formats that 1027 must be distinguished by the session directory for it to know how to 1028 start appropriate tools, relays, mixers or recorders. 1030 The main reason to specify the transport-protocol in addition to the 1031 media format is that the same standard media formats may be carried 1032 over different transport protocols even when the network protocol is 1033 the same - a historical example is vat PCM audio and RTP PCM audio. 1034 In addition, relays and monitoring tools that are 1035 transport-protocol-specific but format-independent are possible. 1037 For RTP media streams operating under the RTP Audio/Video Profile 1038 [RFC1890], the protocol field is "RTP/AVP". Should other RTP 1039 profiles be defined in the future, their profiles will be specified 1040 in the same way. For example, the protocol field "RTP/XYZ" would 1041 specify RTP operating under a profile whose short name is "XYZ". 1043 The fourth and subsequent sub-fields are media formats. For audio 1044 and video, these SHOULD reference a MIME sub-type describing the 1045 format under the "audio" and "video" top-level MIME types. 1047 When a list of payload formats is given, this implies that all of 1048 these formats may be used in the session, but the first of these 1049 formats SHOULD be used as the default format for the session. 1051 For media whose transport protocol is not RTP or UDP the format field 1052 is protocol specific. Such formats should be defined in an 1053 additional specification document. 1055 For media whose transport protocol is RTP, SDP can be used to provide 1056 a dynamic binding of media encoding to RTP payload type. The encoding 1057 names in the RTP AV Profile do not specify unique audio encodings (in 1058 terms of clock rate and number of audio channels), and so they are 1059 not used directly in SDP format fields. Instead, the payload type 1060 number should be used to specify the format for static payload types 1061 and the payload type number along with additional encoding 1062 information should be used for dynamically allocated payload types. 1064 An example of a static payload type is u-law PCM coded single channel 1065 audio sampled at 8kHz. This is completely defined in the RTP Audio/ 1066 Video profile as payload type 0, so the media field for such a stream 1067 sent to UDP port 49232 is: 1069 m=audio 49232 RTP/AVP 0 1071 An example of a dynamic payload type is 16 bit linear encoded stereo 1072 audio sampled at 16 kHz. If we wish to use dynamic RTP/AVP payload 1073 type 98 for such a stream, additional information is required to 1074 decode it: 1076 m=audio 49232 RTP/AVP 98 1077 a=rtpmap:98 L16/16000/2 1079 The general form of an rtpmap attribute is: 1081 a=rtpmap: / 1082 [/] 1084 For audio streams, may specify the number of 1085 audio channels. This parameter may be omitted if the number of 1086 channels is one provided no additional parameters are needed. 1088 For video streams, no encoding parameters are currently specified. 1090 Additional parameters may be defined in the future, but codec- 1091 specific parameters SHOULD NOT be added. Parameters added to an 1092 rtpmap attribute SHOULD only be those required for a session 1093 directory to make the choice of appropriate media to participate in a 1094 session. Codec-specific parameters should be added in other 1095 attributes (for example, "a=fmtp:"). 1097 Up to one rtpmap attribute can be defined for each media format 1098 specified. Thus we might have: 1100 m=audio 49230 RTP/AVP 96 97 98 1101 a=rtpmap:96 L8/8000 1102 a=rtpmap:97 L16/8000 1103 a=rtpmap:98 L16/11025/2 1105 RTP profiles that specify the use of dynamic payload types MUST 1106 define the set of valid encoding names and/or a means to register 1107 encoding names if that profile is to be used with SDP. 1109 Note that RTP audio formats typically do not include information 1110 about the number of samples per packet. If a non-default (as defined 1111 in the RTP Audio/Video Profile) packetisation is required, the 1112 "ptime" attribute is used as given below. 1114 For more details on RTP audio and video formats, see [RFC1890]. 1116 Predefined application formats for the UDP protocol with non-RTP 1117 media are as below: 1119 wb: LBL Whiteboard (transport: udp) 1120 nt: UCL Network Text Editor (transport: udp) 1122 6. Suggested Attributes 1124 The following attributes are suggested. Since application writers 1125 may add new attributes as they are required, this list is not 1126 exhaustive. 1128 a=cat: 1130 This attribute gives the dot-separated hierarchical category 1131 of the session. This is to enable a receiver to filter 1132 unwanted sessions by category. It is a session-level 1133 attribute, and is not dependent on charset. 1135 a=keywds: 1137 Like the cat attribute, this is to assist identifying wanted 1138 sessions at the receiver. This allows a receiver to select 1139 interesting session based on keywords describing the purpose 1140 of the session. It is a session-level attribute. It is a 1141 charset dependent attribute, meaning that its value should be 1142 interpreted in the charset specified for the session 1143 description if one is specified, or by default in ISO 1144 10646/UTF-8. 1146 a=tool: 1148 This gives the name and version number of the tool used to 1149 create the session description. It is a session-level 1150 attribute, and is not dependent on charset. 1152 a=ptime: 1154 This gives the length of time in milliseconds represented by 1155 the media in a packet. This is probably only meaningful for 1156 audio data, but may be used with other media types if it makes 1157 sense. It should not be necessary to know ptime to decode RTP 1158 or vat audio, and it is intended as a recommendation for the 1159 encoding/packetisation of audio. It is a media attribute, and 1160 is not dependent on charset. 1162 a=maxptime: 1164 The maximum amount of media which can be encapsulated in each 1165 packet, expressed as time in milliseconds. The time SHALL be 1166 calculated as the sum of the time the media present in the 1167 packet represents. The time SHOULD be a multiple of the frame 1168 size. This attribute is probably only meaningful for audio 1169 data, but may be used with other media types if it makes 1170 sense. It is a media attribute, and is not dependent on 1171 charset. Note that this attribute was introduced after RFC 1172 2327, and non updated implementations will ignore this 1173 attribute. 1175 a=rtpmap: / 1176 [/] 1178 See Section 5.14. This may be a session or media attribute. 1180 a=recvonly 1182 This specifies that the tools should be started in receive 1183 only mode where applicable. It can be either a session or 1184 media attribute, and is not dependent on charset. Note that 1185 recvonly applies to the media only, not to any associated 1186 control protocol (e.g. an RTP based system in recvonly mode 1187 SHOULD still send RTCP packets). 1189 a=sendrecv 1191 This specifies that the tools should be started in send and 1192 receive mode. This is necessary for interactive conferences 1193 with tools that default to receive only mode. It can be either 1194 a session or media attribute, and is not dependent on charset. 1196 If none of the attributes "sendonly", "recvonly", "inactive", 1197 and "sendrecv" is present, "sendrecv" SHOULD be assumed as the 1198 default for sessions which are not of the conference type 1199 "broadcast" or "H332" (see below). 1201 a=sendonly 1203 This specifies that the tools should be started in send-only 1204 mode. An example may be where a different unicast address is 1205 to be used for a traffic destination than for a traffic 1206 source. In such a case, two media descriptions may be use, 1207 one sendonly and one recvonly. It can be either a session or 1208 media attribute, but would normally only be used as a media 1209 attribute, and is not dependent on charset. Note that sendonly 1210 applies only to the media, and any associated control protocol 1211 (e.g. RTCP) SHOULD still be received and processed as normal. 1213 a=inactive 1215 This specifies that the tools should be started in inactive 1216 mode. This is necessary for interactive conferences where 1217 users can put other users on hold. No media is sent over an 1218 inactive media stream. Note that an RTP based system SHOULD 1219 still send RTCP, even if started inactive. It can be either a 1220 session or media attribute, and is not dependent on charset. 1222 a=orient: 1224 Normally this is only used in a whiteboard media specification. 1225 It specifies the orientation of a the whiteboard on the screen. 1226 It is a media attribute. Permitted values are "portrait", 1227 "landscape" and "seascape" (upside down landscape). It is not 1228 dependent on charset. 1230 a=type: 1232 This specifies the type of the conference. Suggested values 1233 are "broadcast", "meeting", "moderated", "test" and "H332". 1234 "recvonly" should be the default for "type:broadcast" 1235 sessions, "type:meeting" should imply "sendrecv" and 1236 "type:moderated" should indicate the use of a floor control 1237 tool and that the media tools are started so as to mute new 1238 sites joining the conference. 1240 Specifying the attribute "type:H332" indicates that this 1241 loosely coupled session is part of a H.332 session as defined 1242 in the ITU H.332 specification [H.332]. Media tools should be 1243 started "recvonly". 1245 Specifying the attribute "type:test" is suggested as a hint 1246 that, unless explicitly requested otherwise, receivers can 1247 safely avoid displaying this session description to users. 1249 The type attribute is a session-level attribute, and is not 1250 dependent on charset. 1252 a=charset: 1254 This specifies the character set to be used to display the 1255 session name and information data. By default, the ISO-10646 1256 character set in UTF-8 encoding is used. If a more compact 1257 representation is required, other character sets may be used 1258 such as ISO-8859-1 for Northern European languages. In 1259 particular, the ISO 8859-1 is specified with the following 1260 SDP attribute: 1262 a=charset:ISO-8859-1 1264 This is a session-level attribute; if this attribute is 1265 present, it MUST be before the first media field. The charset 1266 specified MUST be one of those registered with IANA, such as 1267 ISO-8859-1. The character set identifier is a US-ASCII string 1268 and MUST be compared against the IANA identifiers using a 1269 case- insensitive comparison. If the identifier is not 1270 recognised or not supported, all strings that are affected by 1271 it SHOULD be regarded as octet strings. 1273 Note that a character set specified MUST still prohibit the 1274 use of bytes 0x00 (Nul), 0x0A (LF) and 0x0d (CR). Character 1275 sets requiring the use of these characters MUST define a 1276 quoting mechanism that prevents these bytes appearing within 1277 text fields. 1279 a=sdplang: 1281 This can be a session level attribute or a media level 1282 attribute. As a session level attribute, it specifies the 1283 language for the session description. As a media level 1284 attribute, it specifies the language for any media-level SDP 1285 information field associated with that media. Multiple 1286 sdplang attributes can be provided either at session or media 1287 level if multiple languages in the session description or 1288 media use multiple languages, in which case the order of the 1289 attributes indicates the order of importance of the various 1290 languages in the session or media from most important to least 1291 important. 1293 In general, sending session descriptions consisting of 1294 multiple languages is discouraged. Instead, multiple 1295 descriptions SHOULD be sent describing the session, one in 1296 each language. However this is not possible with all 1297 transport mechanisms, and so multiple sdplang attributes are 1298 allowed although NOT RECOMMENDED. 1300 The "sdplang" attribute value must be a single RFC 3066 1301 language tag in US-ASCII [RFC3066]. It is not dependent on 1302 the charset attribute. An "sdplang" attribute SHOULD be 1303 specified when a session is of sufficient scope to cross 1304 geographic boundaries where the language of recipients cannot 1305 be assumed, or where the session is in a different language 1306 from the locally assumed norm. 1308 a=lang: 1310 This can be a session level attribute or a media level 1311 attribute. As a session level attribute, it specifies the 1312 default language for the session being described. As a media 1313 level attribute, it specifies the language for that media, 1314 overriding any session-level language specified. Multiple 1315 lang attributes can be provided either at session or media 1316 level if the session description or media use multiple 1317 languages, in which case the order of the attributes indicates 1318 the order of importance of the various languages in the 1319 session or media from most important to least important. 1321 The "lang" attribute value must be a single RFC 3066 language 1322 tag in US-ASCII [RFC3066]. It is not dependent on the charset 1323 attribute. A "lang" attribute SHOULD be specified when a 1324 session is of sufficient scope to cross geographic boundaries 1325 where the language of recipients cannot be assumed, or where 1326 the session is in a different language from the locally 1327 assumed norm. 1329 a=framerate: 1331 This gives the maximum video frame rate in frames/sec. It is 1332 intended as a recommendation for the encoding of video data. 1333 Decimal representations of fractional values using the 1334 notation "." are allowed. It is a 1335 media attribute, defined only for video media, and is not 1336 dependent on charset. 1338 a=quality: 1340 This gives a suggestion for the quality of the encoding as an 1341 integer value. The intention of the quality attribute for 1342 video is to specify a non-default trade-off between frame-rate 1343 and still-image quality. For video, the value in the range 0 1344 to 10, with the following suggested meaning: 1346 10 - the best still-image quality the compression scheme 1347 can give. 1348 5 - the default behaviour given no quality suggestion. 1349 0 - the worst still-image quality the codec designer 1350 thinks is still usable. 1352 It is a media attribute, and is not dependent on charset. 1354 a=fmtp: 1356 This attribute allows parameters that are specific to a 1357 particular format to be conveyed in a way that SDP doesn't 1358 have to understand them. The format must be one of the 1359 formats specified for the media. Format-specific parameters 1360 may be any set of parameters required to be conveyed by SDP 1361 and given unchanged to the media tool that will use this 1362 format. 1364 It is a media attribute, and is not dependent on charset. 1366 7. Communicating Conference Control Policy 1368 There is some debate over the way conference control policy should be 1369 communicated. In general, the authors believe that an implicit 1370 declarative style of specifying conference control is desirable where 1371 possible. 1373 A simple declarative style uses a single conference attribute field 1374 before the first media field, possibly supplemented by properties 1375 such as `recvonly' for some of the media tools. This conference 1376 attribute conveys the conference control policy. An example might 1377 be: 1379 a=type:moderated 1381 In some cases, however, it is possible that this may be insufficient 1382 to communicate the details of an unusual conference control policy. 1383 If this is the case, then a conference attribute specifying external 1384 control might be set, and then one or more "media" fields might be 1385 used to specify the conference control tools and configuration data 1386 for those tools. An example is an ITU H.332 session: 1388 ... 1389 c=IN IP4 224.5.6.7 1390 a=type:H332 1391 m=audio 49230 RTP/AVP 0 1392 m=video 49232 RTP/AVP 31 1393 m=application 12349 udp wb 1394 m=control 49234 H323 mc 1395 c=IN IP4 134.134.157.81 1397 In this example, a general conference attribute (type:H332) is 1398 specified stating that conference control will be provided by an 1399 external H.332 tool, and a contact addresses for the H.323 session 1400 multipoint controller is given. 1402 In this document, only the declarative style of conference control 1403 declaration is specified. Other forms of conference control should 1404 specify an appropriate type attribute, and should define the 1405 implications this has for control media. 1407 8. Security Considerations 1409 SDP is a session description format that describes multimedia 1410 sessions. A session description SHOULD NOT be trusted unless it has 1411 been obtained by an authenticated transport protocol from a trusted 1412 source. Many different transport protocols may be used to distribute 1413 session description, and the nature of the authentication will differ 1414 from transport to transport. 1416 One transport that will frequently be used to distribute session 1417 descriptions is the Session Announcement Protocol (SAP). SAP 1418 provides both encryption and authentication mechanisms but due to the 1419 nature of session announcements it is likely that there are many 1420 occasions where the originator of a session announcement cannot be 1421 authenticated because they are previously unknown to the receiver of 1422 the announcement and because no common public key infrastructure is 1423 available. 1425 On receiving a session description over an unauthenticated transport 1426 mechanism or from an untrusted party, software parsing the session 1427 should take a few precautions. Session descriptions contain 1428 information required to start software on the receivers system. 1429 Software that parses a session description MUST NOT be able to start 1430 other software except that which is specifically configured as 1431 appropriate software to participate in multimedia sessions. It is 1432 normally considered inappropriate for software parsing a session 1433 description to start, on a user's system, software that is 1434 appropriate to participate in multimedia sessions, without the user 1435 first being informed that such software will be started and giving 1436 their consent. Thus a session description arriving by session 1437 announcement, email, session invitation, or WWW page SHOULD NOT 1438 deliver the user into an interactive multimedia session without the 1439 user being aware that this will happen. As it is not always simple 1440 to tell whether a session is interactive or not, applications that 1441 are unsure should assume sessions are interactive. 1443 In this specification, there are no attributes which would allow the 1444 recipient of a session description to be informed to start multimedia 1445 tools in a mode where they default to transmitting. Under some 1446 circumstances it might be appropriate to define such attributes. If 1447 this is done an application parsing a session description containing 1448 such attributes SHOULD either ignore them, or inform the user that 1449 joining this session will result in the automatic transmission of 1450 multimedia data. The default behaviour for an unknown attribute is 1451 to ignore it. 1453 Session descriptions may be parsed at intermediate systems such as 1454 firewalls for the purposes of opening a hole in the firewall to allow 1455 the participation in multimedia sessions. It is considered 1456 inappropriate for a firewall to open such holes for unicast data 1457 streams unless the session description comes in a request from inside 1458 the firewall. For multicast sessions, it is likely that local 1459 administrators will apply their own policies, but the exclusive use 1460 of "local" or "site-local" administrative scope within the firewall 1461 and the refusal of the firewall to open a hole for such scopes will 1462 provide separation of global multicast sessions from local ones. 1464 Use of the "k=" field poses a significant security risk, since it 1465 conveys session encryption keys in the clear. SDP MUST NOT be used 1466 to convey key material, unless it can be guaranteed that the channel 1467 over which the SDP is delivered is both private and authenticated. 1469 9. IANA Considerations 1471 There are seven field names that may be registered with IANA. Using 1472 the terminology in the SDP specification BNF, they are "media", 1473 "proto", "fmt", "att-field", "bwtype", "nettype" and "addrtype". 1475 9.1 Media types ("media") 1477 The set of media types is intended to be small and SHOULD NOT be 1478 extended except under rare circumstances. The same rules should 1479 apply for media names as for top-level MIME content types, and where 1480 possible the same name should be registered for SDP as for MIME. For 1481 media other than existing MIME top-level content types, a 1482 standards-track RFC MUST be produced for a new top-level content type 1483 to be registered, and the registration MUST provide good 1484 justification why no existing media name is appropriate (the 1485 "Standards Action" policy of RFC 2434 [RFC2434]). 1487 9.2 Transport protocols ("proto") 1489 The "proto" field describes the transport protocol used. This SHOULD 1490 reference a standards-track protocol RFC. This memo registers three 1491 values: "RTP/AVP" is a reference to RTP [RFC1889] used under the RTP 1492 Profile for Audio and Video Conferences with Minimal Control 1493 [RFC1890]) running over UDP/IP; "TCP" denotes an unspecified format 1494 over TCP; and "udp" indicates an unspecified format over UDP. 1496 New transport protocols MAY be registered with IANA. Registrations 1497 MUST reference an RFC describing the protocol. Such an RFC MAY be 1498 Experimental or Informational, although it is preferable if it is 1499 Standards-Track. Registrations MUST also define the rules by which 1500 their "fmt" namespace is managed (see below). 1502 9.3 Media formats ("fmt") 1504 Each transport protocol, defined by the "proto" field, has an 1505 associated "fmt" namespace that describes the media formats which may 1506 conveyed by that protocol. Formats cover all the possible encodings 1507 that might want to be transported in a multimedia session. 1509 RTP payload formats under the "RTP/AVP" protocol that have been 1510 assigned static payload types MUST use the static payload type as 1511 their "fmt" value. For payload formats under "RTP/AVP" that have a 1512 dynamic payload type number, the dynamic payload type number is given 1513 as the "fmt" and an additional "rtpmap" attribute specifies the 1514 format name and parameters as defined by the MIME type registration 1515 for the payload format. 1517 For "TCP" and "udp" protocols, new formats SHOULD be registered. Use 1518 of an existing MIME subtype for the format is encouraged. If no MIME 1519 subtype exists, it is RECOMMENDED that a suitable one is registered 1520 through the IETF process (RFC 2048) by production of, or reference 1521 to, a standards-track RFC. If a MIME subtype is for some reason 1522 inappropriate, an RFC publication describing the format MUST be 1523 referenced in the registration, but it may be Informational or 1524 Experimental if the protocol is not deemed to be of widespread 1525 deployment. 1527 For other protocols, formats MAY be registered according to the rules 1528 of the associated "proto" specification. 1530 Registrations of new formats MUST specify which transport protocols 1531 they apply to. 1533 9.4 Attribute names ("att-field") 1535 Attribute field names ("att-field") MUST be registered with IANA and 1536 documented, because of noticeable issues due to conflicting 1537 attributes under the same name. Unknown attributes in SDP are simply 1538 ignored, but conflicting ones that fragment the protocol are a 1539 serious problem. 1541 New attribute registerations are accepted according to the 1542 "Specification Required" policy of RFC 2434, provided that the 1543 specification includes the following information: 1545 o contact name, email address and telephone number 1547 o attribute-name (as it will appear in SDP) 1549 o long-form attribute name in English 1551 o type of attribute (session level, media level, or both) 1553 o whether the attribute value is subject to the charset attribute. 1555 o a one paragraph explanation of the purpose of the attribute. 1557 o a specification of appropriate attribute values for this 1558 attribute. 1560 The above is the minimum that IANA will accept. Attributes that are 1561 expected to see widespread use and interoperability, SHOULD be 1562 documented with a standards-track RFC that specifies the attribute 1563 more precisely. 1565 Submitters of registrations should ensure that the specification is 1566 in the spirit of SDP attributes, most notably that the attribute is 1567 platform independent in the sense that it makes no implicit 1568 assumptions about operating systems and does not name specific pieces 1569 of software in a manner that might inhibit interoperability. 1571 9.5 Bandwidth specifiers ("bwtype") 1573 A proliferation of bandwidth specifiers is strongly discouraged. 1575 New bandwidth specifiers ("bwtype" fields) MUST be registered with 1576 IANA. The submission MUST reference a standards-track RFC specifying 1577 the semantics of the bandwidth specifier precisely, and indicating 1578 when it should be used, and why the existing registered bandwidth 1579 specifiers do not suffice. 1581 9.6 Network types ("nettype") 1583 New network types (the "nettype" field) may be registered with IANA 1584 if SDP needs to be used in the context of non-Internet environments. 1585 Whilst these are not normally the preserve of IANA, there may be 1586 circumstances when an Internet application needs to interoperate with 1587 a non- Internet application, such as when gatewaying an Internet 1588 telephony call into the PSTN. The number of network types should be 1589 small and should be rarely extended. A new network type cannot be 1590 registered without registering at least one address type to be used 1591 with that network type. A new network type registration MUST 1592 reference an RFC which gives details of the network type and address 1593 type and specifies how and when they would be used. Such an RFC MAY 1594 be Informational. 1596 9.7 Address types ("addrtype") 1598 New address types ("addrtype") may be registered with IANA. An 1599 address type is only meaningful in the context of a network type, and 1600 any registration of an address type MUST specify a registered network 1601 type, or be submitted along with a network type registration. A new 1602 address type registration MUST reference an RFC giving details of the 1603 syntax of the address type. Such an RFC MAY be Informational. 1604 Address types are not expected to be registered frequently. 1606 9.8 Registration Procedure 1608 In the RFC documentation that registers SDP "media", "proto", "fmt", 1609 "bwtype", "nettype" and "addrtype" fields, the authors MUST include 1610 the following information for IANA to place in the appropriate 1611 registry: 1613 o contact name, email address and telephone number 1615 o name being registered (as it will appear in SDP) 1617 o long-form name in English 1619 o type of name ("media", "proto", "fmt", "bwtype", "nettype", or 1620 "addrtype") 1622 o a one paragraph explanation of the purpose of the registered name. 1624 o a reference to the specification (e.g. RFC number) of the 1625 registered name. 1627 IANA may refer any registration to the IESG Transport Area Directors 1628 for review, and may request revisions to be made before a 1629 registration will be made. 1631 Appendix A. SDP Grammar 1633 This appendix provides an Augmented BNF grammar for SDP. ABNF is 1634 defined in [RFC2234]. 1636 ; SDP Syntax 1637 announcement = proto-version 1638 origin-field 1639 session-name-field 1640 information-field 1641 uri-field 1642 email-fields 1643 phone-fields 1644 connection-field 1645 bandwidth-fields 1646 time-fields 1647 key-field 1648 attribute-fields 1649 media-descriptions 1651 proto-version = "v=" 1*DIGIT CRLF 1652 ;this memo describes version 0 1654 origin-field = "o=" username SP sess-id SP sess-version SP 1655 nettype SP addrtype SP unicast-address CRLF 1657 session-name-field = "s=" text CRLF 1659 information-field = ["i=" text CRLF] 1661 uri-field = ["u=" uri CRLF] 1663 email-fields = *("e=" email-address CRLF) 1665 phone-fields = *("p=" phone-number CRLF) 1667 connection-field = ["c=" nettype SP addrtype SP 1668 connection-address CRLF] 1669 ;a connection field must be present 1670 ;in every media description or at the 1671 ;session-level 1673 bandwidth-fields = *("b=" bwtype ":" bandwidth CRLF) 1675 time-fields = 1*( "t=" start-time SP stop-time 1676 *(CRLF repeat-fields) CRLF) 1677 [zone-adjustments CRLF] 1679 repeat-fields = "r=" repeat-interval SP typed-time 1680 1*(SP typed-time) 1682 zone-adjustments = "z=" time SP ["-"] typed-time 1683 *(SP time SP ["-"] typed-time) 1685 key-field = ["k=" key-type CRLF] 1686 attribute-fields = *("a=" attribute CRLF) 1688 media-descriptions = *( media-field 1689 information-field 1690 *connection-field 1691 bandwidth-fields 1692 key-field 1693 attribute-fields ) 1695 media-field = "m=" media SP port ["/" integer] 1696 SP proto 1*(SP fmt) CRLF 1698 ; sub-rules of 'o=' 1699 username = non-ws-string 1700 ;pretty wide definition, but doesn't 1701 ;include space 1703 sess-id = 1*DIGIT 1704 ;should be unique for this username/host 1706 sess-version = 1*DIGIT 1707 ;0 is a new session 1709 nettype = token 1710 ;typically "IN" 1712 addrtype = token 1713 ;typically "IP4" or "IP6" 1715 ; sub-rules of 'u=' 1716 uri = URI-reference; see RFC1630 and RFC2732 1718 ; sub-rules of 'e=' 1719 email-address = email *SP "(" 1*email-safe ")" / 1720 1*email-safe "<" email ">" / 1721 email 1723 email = addr-spec ; defined in RFC2822 1724 ; modified to remove CFWS 1726 ; sub-rules of 'p=' 1727 phone-number = phone *SP "(" 1*email-safe ")" / 1728 1*email-safe "<" phone ">" / 1729 phone 1731 phone = "+" POS-DIGIT 1*(SP / "-" / DIGIT) 1732 ;there must be a space or hyphen between 1733 ;the international code and the rest of 1734 ;the number. 1736 ; sub-rules of 'c=' 1737 connection-address = multicast-address / unicast-address 1739 ; sub-rules of 'b=' 1740 bwtype = token 1742 bandwidth = 1*DIGIT 1744 ; sub-rules of 't=' 1745 start-time = time / "0" 1747 stop-time = time / "0" 1749 time = POS-DIGIT 9*DIGIT 1750 ; 10-digit NTP time represents times between 1751 ; 1931 and 5068 AD. 9* allows times after 1752 ; that as well. 1754 ; sub-rules of 'r=' and 'z=' 1755 repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] 1757 typed-time = 1*DIGIT [fixed-len-time-unit] 1759 fixed-len-time-unit = "d" / "h" / "m" / "s" 1761 ; sub-rules of 'k=' 1762 key-type = "prompt" / 1763 "clear:" text / 1764 "base64:" base64 / 1765 "uri:" uri / 1766 key-method [ ":" text ] 1768 base64 = *base64-unit [base64-pad] 1769 base64-unit = 4base64-char 1770 base64-pad = 2base64-char "==" / 3base64-char "=" 1771 base64-char = ALPHA / DIGIT / "+" / "/" 1773 key-method = token 1775 ; sub-rules of 'a=' 1776 attribute = (att-field ":" att-value) / att-field 1778 att-field = token 1780 att-value = byte-string 1781 ; sub-rules of 'm=' 1782 media = token 1783 ;typically "audio", "video", "application" 1784 ;or "data" 1786 fmt = token 1787 ;typically an RTP payload type for audio 1788 ;and video media 1790 proto = token "/" token 1791 / token 1792 ;typically "RTP/AVP" or "udp" for IP4 1794 port = 1*DIGIT 1795 ;should be either "0" or in the range "1024" 1796 ;to "65535" inclusive for UDP based media 1797 ;(a value of "0" is used to signal special 1798 ;conditions in some uses of SDP) 1800 ; generic sub-rules: addressing 1801 unicast-address = IP4-address / IP6-address / FQDN / extn-addr 1803 multicast-address = IP4-multicast / IP6-multicast 1805 IP4-multicast = m1 3( "." decimal-uchar ) 1806 "/" ttl [ "/" integer ] 1807 ; IPv4 multicast addresses may be in the 1808 ; range 224.0.0.0 to 239.255.255.255 1810 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / 1811 ("23" DIGIT )) 1813 IP6-multicast = hexpart [ "/" integer ] 1814 ; IPv6 address starting with FF 1816 ttl = (POS-DIGIT *2DIGIT) / "0" 1818 FQDN = 4*(alpha-numeric / "-" / ".") 1819 ; fully qualified domain name as specified 1820 ; in RFC1035 1822 IP4-address = b1 3("." decimal-uchar) / "0.0.0.0" 1824 b1 = decimal-uchar 1825 ; less than "224"; not "0" or "127" 1827 ; The following is from RFC2373 Appendix B. It is a direct copy. 1828 IP6-address = hexpart [ ":" IP4-address ] 1829 hexpart = hexseq / hexseq "::" [ hexseq ] / 1830 "::" [ hexseq ] 1832 hexseq = hex4 *( ":" hex4) 1834 hex4 = 1*4HEXDIG 1836 ; Generic for other address families 1837 extn-addr = non-ws-string 1839 ; generic sub-rules: datatypes 1840 text = byte-string 1841 ;default is to interpret this as UTF8 text. 1842 ;ISO 8859-1 requires "a=charset:ISO-8859-1" 1843 ;session-level attribute to be used 1845 byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) 1846 ;any byte except NUL, CR or LF 1848 non-ws-string = 1*(VCHAR/%x80-FF) 1849 ;string of visible characters 1851 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 1852 / %x41-5A / %x5E-7E 1853 ; definition from RFC 2045 - 1854 ; "any (US-ASCII) CHAR except SPACE, CTLs, 1855 ; or tspecials". 1856 ; the tspecials are ()<>@,;: 1858 token = 1*(token-char) 1860 email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF 1861 ;any byte except NUL, CR, LF, or the quoting 1862 ;characters ()<> 1864 integer = POS-DIGIT *DIGIT 1866 ; generic sub-rules: primitives 1867 alpha-numeric = ALPHA / DIGIT 1869 POS-DIGIT = %x31-39 ; 1 - 9 1871 decimal-uchar = DIGIT 1872 / POS-DIGIT DIGIT 1873 / ("1" 2*(DIGIT)) 1874 / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) 1875 / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) 1877 ; external references: 1878 ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 2234 1879 ; URI-reference: from RFC1630 and RFC2732 1880 ; addr-spec: from RFC 2822 1882 Appendix B. Changes from RFC 2327 1884 o Deprecate X- notation for experimental parameters 1886 o Clarify that a=recvonly does NOT mean that you don't send RTCP, 1887 and similarly for sendonly and inactive. These only effect the RTP 1888 stream. 1890 o Rewrite and correct the ABNF syntax (thanks to Jonathan Lennox) 1892 o Update BNF to support IPv6. 1894 o Add a=inactive attribute. 1896 o Add a=maxptime attribute. 1898 o RFC 2327 mandated that either e= or p= was required. Both are now 1899 optional, to reflect actual usage. 1901 o Removed references to "conference" from the description of the t= 1902 line, to make it less SAP oriented. 1904 o Note about wrap-around of NTP timestamps in t= 1906 o References have been updated and split into normative and 1907 informative sections. 1909 o Section 3.1 was replaced with a reference to RFC 2119, and the 1910 memo has been updated to use the RFC 2119 terminology (MUST, 1911 SHOULD, etc). 1913 o Use of "application/sdp" as MIME a type for SDP files is now 1914 "MUST" rather than "SHOULD". 1916 o Many sections have been updated to be less SAP specific, and to 1917 reference other current uses of SDP such as RTSP and SIP. 1919 o The introduction and background has been rewritten, to remove 1920 references to the Mbone, reflecting current use of SDP. 1922 o The section on concatenation of session descriptions (which was 1923 not allowed in SAP, but allowed in other cases) has been removed. 1925 It is assumed that transports of SDP specify will specify this. 1927 o The description of the c= line has been updated to reflect common 1928 usage of SDP, rather than Mbone conferencing with SAP. 1930 o The b= line no longer makes a normative reference to the Mbone FAQ 1931 for bandwidth limits at various TTLs. The AS modifier to b= is 1932 noted as being the RTP session bandwidth. 1934 o Define relation between the m= line and MIME types 1936 o Note use of s= in sessions with no meaningful name 1938 o Allow a=rtpmap to be a session level attribute, in addition to a 1939 media level attribute 1941 o Clarify the limitations of the k= field 1943 o Clarify IANA considerations 1945 Appendix C. Acknowledgments 1947 Many people in the IETF MMUSIC working group have made comments and 1948 suggestions contributing to this document. In particular, we would 1949 like to thank Eve Schooler, Steve Casner, Bill Fenner, Allison 1950 Mankin, Ross Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, 1951 Steve Hanna and Jonathan Lennox. 1953 Normative References 1955 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1956 Levels", BCP 14, RFC 2119, March 1997. 1958 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1959 Specifications: ABNF", RFC 2234, November 1997. 1961 [3] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1962 2279, January 1998. 1964 [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1965 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 1967 [5] Alvestrand, H., "Tags for the Identification of Languages", BCP 1968 47, RFC 3066, January 2001. 1970 Informative References 1972 [6] Mills, D., "Network Time Protocol (Version 3) Specification, 1973 Implementation", RFC 1305, March 1992. 1975 [7] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 1976 "RTP: A Transport Protocol for Real-Time Applications", RFC 1977 1889, January 1996. 1979 [8] Schulzrinne, H., "RTP Profile for Audio and Video Conferences 1980 with Minimal Control", RFC 1890, January 1996. 1982 [9] Handley, M., Perkins, C. and E. Whelan, "Session Announcement 1983 Protocol", RFC 2974, October 2000. 1985 [10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1986 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1987 Session Initiation Protocol", RFC 3261, June 2002. 1989 [11] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 1990 Protocol (RTSP)", RFC 2326, April 1998. 1992 [12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1993 Session Description Protocol (SDP)", RFC 3264, June 2002. 1995 [13] Huitema, C., "RTCP attribute in SDP", 1996 draft-ietf-mmusic-sdp4nat-05 (work in progress), June 2003. 1998 Authors' Addresses 2000 Mark Handley 2001 University College London 2002 Gower Street 2003 London WC1E 6BT 2004 UK 2006 EMail: M.Handley@cs.ucl.ac.uk 2008 Van Jacobson 2009 Packet Design 2010 2465 Latham Street 2011 Mountain View, CA 94040 2012 USA 2014 EMail: van@packetdesign.com 2015 Colin Perkins 2016 University of Glasgow 2017 17 Lilybank Gardens 2018 Glasgow G12 8QQ 2019 UK 2021 EMail: csp@csperkins.org 2023 Intellectual Property Statement 2025 The IETF takes no position regarding the validity or scope of any 2026 intellectual property or other rights that might be claimed to 2027 pertain to the implementation or use of the technology described in 2028 this document or the extent to which any license under such rights 2029 might or might not be available; neither does it represent that it 2030 has made any effort to identify any such rights. Information on the 2031 IETF's procedures with respect to rights in standards-track and 2032 standards-related documentation can be found in BCP-11. Copies of 2033 claims of rights made available for publication and any assurances of 2034 licenses to be made available, or the result of an attempt made to 2035 obtain a general license or permission for the use of such 2036 proprietary rights by implementors or users of this specification can 2037 be obtained from the IETF Secretariat. 2039 The IETF invites any interested party to bring to its attention any 2040 copyrights, patents or patent applications, or other proprietary 2041 rights which may cover technology that may be required to practice 2042 this standard. Please address the information to the IETF Executive 2043 Director. 2045 Full Copyright Statement 2047 Copyright (C) The Internet Society (2003). All Rights Reserved. 2049 This document and translations of it may be copied and furnished to 2050 others, and derivative works that comment on or otherwise explain it 2051 or assist in its implementation may be prepared, copied, published 2052 and distributed, in whole or in part, without restriction of any 2053 kind, provided that the above copyright notice and this paragraph are 2054 included on all such copies and derivative works. However, this 2055 document itself may not be modified in any way, such as by removing 2056 the copyright notice or references to the Internet Society or other 2057 Internet organizations, except as needed for the purpose of 2058 developing Internet standards in which case the procedures for 2059 copyrights defined in the Internet Standards process must be 2060 followed, or as required to translate it into languages other than 2061 English. 2063 The limited permissions granted above are perpetual and will not be 2064 revoked by the Internet Society or its successors or assignees. 2066 This document and the information contained herein is provided on an 2067 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2068 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2069 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2070 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2071 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2073 Acknowledgment 2075 Funding for the RFC Editor function is currently provided by the 2076 Internet Society.