idnits 2.17.1 draft-ietf-mmusic-sdp-new-21.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.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2134. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2111. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2118. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2124. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 (October 25, 2004) is 7121 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) == Unused Reference: '7' is defined on line 2013, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 2056, 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 2396 (ref. '4') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2434 (ref. '5') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2732 (ref. '6') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 3066 (ref. '7') (Obsoleted by RFC 4646, RFC 4647) -- Obsolete informational reference (is this intentional?): RFC 1305 (ref. '8') (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '11') (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 3548 (ref. '13') (Obsoleted by RFC 4648) == Outdated reference: A later version (-15) exists of draft-ietf-mmusic-kmgmt-ext-11 == Outdated reference: A later version (-12) exists of draft-ietf-mmusic-sdescriptions-07 Summary: 11 errors (**), 0 flaws (~~), 9 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: April 25, 2005 C. Perkins 7 University of Glasgow 8 October 25, 2004 10 SDP: Session Description Protocol 11 draft-ietf-mmusic-sdp-new-21.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on April 25, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). 44 Abstract 46 This memo defines the Session Description Protocol (SDP). SDP is 47 intended for describing multimedia sessions for the purposes of 48 session announcement, session invitation, and other forms of 49 multimedia session initiation. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . 3 55 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . 3 56 3.1 Multicast Session Announcement . . . . . . . . . . . . . . 3 57 3.2 Session Initiation . . . . . . . . . . . . . . . . . . . . 4 58 3.3 Streaming media . . . . . . . . . . . . . . . . . . . . . 4 59 3.4 Email and the World Wide Web . . . . . . . . . . . . . . . 4 60 4. Requirements and Recommendations . . . . . . . . . . . . . . 5 61 4.1 Media and Transport Information . . . . . . . . . . . . . 5 62 4.2 Timing Information . . . . . . . . . . . . . . . . . . . . 6 63 4.3 Private Sessions . . . . . . . . . . . . . . . . . . . . . 6 64 4.4 Obtaining Further Information about a Session . . . . . . 7 65 4.5 Categorisation . . . . . . . . . . . . . . . . . . . . . . 7 66 4.6 Internationalization . . . . . . . . . . . . . . . . . . . 7 67 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . 7 68 5.1 Protocol Version ("v=") . . . . . . . . . . . . . . . . . 10 69 5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 10 70 5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . . 11 71 5.4 Session Information ("i=") . . . . . . . . . . . . . . . . 12 72 5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 12 73 5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . 12 74 5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . 13 75 5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 15 76 5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 16 77 5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . 17 78 5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . 18 79 5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 19 80 5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . 20 81 5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . . 21 82 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 24 83 7. Security Considerations . . . . . . . . . . . . . . . . . . 30 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32 85 8.1 The "application/sdp" media type . . . . . . . . . . . . . 32 86 8.2 Registration of Parameters . . . . . . . . . . . . . . . . 33 87 8.3 Encryption Key Access Methods . . . . . . . . . . . . . . 37 88 A. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 37 89 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 42 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 91 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 42 92 9.2 Informative References . . . . . . . . . . . . . . . . . . . 43 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 44 94 Intellectual Property and Copyright Statements . . . . . . . 46 96 1. Introduction 98 When initiating multimedia teleconferences, voice-over-IP calls, 99 streaming video, or other sessions, there is a requirement to convey 100 media details, transport addresses, and other session description 101 metadata to the participants. 103 SDP provides a standard representation for such information, 104 irrespective of how that information is transported. SDP is purely a 105 format for session description - it does not incorporate a transport 106 protocol, and is intended to use different transport protocols as 107 appropriate, including the Session Announcement Protocol [9], Session 108 Initiation Protocol [10], Real-Time Streaming Protocol [11], 109 electronic mail using the MIME extensions, and the Hypertext 110 Transport Protocol. 112 SDP is intended to be general purpose so that it can be used in a 113 wide range of network environments and applications. However, it is 114 not intended to support negotiation of session content or media 115 encodings: this is viewed as outside the scope of session 116 description. 118 2. Glossary of Terms 120 The following terms are used in this document, and have specific 121 meaning within the context of this document. 123 Conference: A multimedia conference is a set of two or more 124 communicating users along with the software they are using to 125 communicate. 127 Session: A multimedia session is a set of multimedia senders and 128 receivers and the data streams flowing from senders to receivers. 129 A multimedia conference is an example of a multimedia session. 131 Session Description: A well defined format for conveying sufficient 132 information to discover and participate in a multimedia session. 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC 2119 [1]. 138 3. Examples of SDP Usage 140 3.1 Multicast Session Announcement 142 In order to assist the advertisement of multicast multimedia 143 conferences and other multicast sessions, and to communicate the 144 relevant session setup information to prospective participants, a 145 distributed session directory may be used. An instance of such a 146 session directory periodically sends packets containing a description 147 of the session to a well known multicast group. These advertisements 148 are received by other session directories such that potential remote 149 participants can use the session description to start the tools 150 required to participate in the session. 152 One protocol commonly used to implement such a distributed directory 153 is the Session Announcement Protocol, SAP [9]. SDP provides the 154 recommended session description format for such session 155 announcements. 157 3.2 Session Initiation 159 The Session Initiation Protocol, SIP [10] is an application layer 160 control protocol for creating, modifying and terminating sessions 161 such as Internet multimedia conferences, Internet telephone calls and 162 multimedia distribution. The SIP messages used to create sessions 163 carry session descriptions which allow participants to agree on a set 164 of compatible media types. These session descriptions are commonly 165 formatted using SDP. When used with SIP, the offer/answer model [12] 166 provides a limited framework for negotiation using SDP. 168 3.3 Streaming media 170 The Real Time Streaming Protocol, RTSP [11], is an application-level 171 protocol for control over the delivery of data with real-time 172 properties. RTSP provides an extensible framework to enable 173 controlled, on-demand delivery of real-time data, such as audio and 174 video. An RTSP client and server negotiate an appropriate set of 175 parameters for media delivery, partially using SDP syntax to describe 176 those parameters. 178 3.4 Email and the World Wide Web 180 Alternative means of conveying session descriptions include 181 electronic mail and the World Wide Web. For both email and WWW 182 distribution, the MIME content type "application/sdp" is used. This 183 enables the automatic launching of applications for participation in 184 the session from the WWW client or mail reader in a standard manner. 186 Note that announcements of multicast sessions made only via email or 187 the World Wide Web (WWW) do not have the property that the receiver 188 of a session announcement can necessarily receive the session because 189 the multicast sessions may be restricted in scope, and access to the 190 WWW server or reception of email is possible outside this scope. 191 Session announcements made using SAP do not suffer this mismatch. 193 4. Requirements and Recommendations 195 The purpose of SDP is to convey information about media streams in 196 multimedia sessions to allow the recipients of a session description 197 to participate in the session. SDP is primarily intended for use in 198 an internetwork, although it is sufficiently general that it can 199 describe conferences in other network environments. Media streams 200 can be many-to-many. The times during which the session is active 201 need not be continuous. 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. 269 4.2 Timing Information 271 Sessions may either be bounded or unbounded in time. Whether or not 272 they are bounded, they may be only active at specific times. SDP can 273 convey: 275 o An arbitrary list of start and stop times bounding the session 277 o For each bound, repeat times such as "every Wednesday at 10am for 278 one hour" 280 This timing information is globally consistent, irrespective of local 281 time zone or daylight saving time. 283 4.3 Private Sessions 285 It is possible to create both public sessions and private sessions. 286 SDP itself does not distinguish between these: private sessions are 287 typically conveyed by encrypting the session description during 288 distribution. The details of how encryption is performed are 289 dependent on the mechanism used to convey SDP: mechanisms are 290 currently defined for SDP transported using SAP [9] and SIP [10], 291 others may be defined in future. 293 If a session announcement is private it is possible to use that 294 private announcement to convey encryption keys necessary to decode 295 each of the media in a conference, including enough information to 296 know which encryption scheme is used for each media. 298 4.4 Obtaining Further Information about a Session 300 A session description should convey enough information to decide 301 whether or not to participate in a session. SDP may include 302 additional pointers in the form of Universal Resources Identifiers 303 (URIs) for more information about the session. 305 4.5 Categorisation 307 When many session descriptions are being distributed by SAP, or any 308 other advertisement mechanism, it may be desirable to filter session 309 announcements that are of interest from those that are not. SDP 310 supports a categorisation mechanism for sessions that is capable of 311 being automated. 313 4.6 Internationalization 315 The SDP specification recommends the use of the ISO 10646 character 316 sets in the UTF-8 encoding [3] to allow many different languages to 317 be represented. However, to assist in compact representations, SDP 318 also allows other character sets such as ISO 8859-1 to be used when 319 desired. Internationalization only applies to free-text fields 320 (session name and background information), and not to SDP as a whole. 322 5. SDP Specification 324 An SDP session description is denoted by the MIME content type 325 "application/sdp" (See Section 8). 327 An SDP session description is entirely textual using the ISO 10646 328 character set in UTF-8 encoding. SDP field names and attribute names 329 use only the US-ASCII subset of UTF-8, but textual fields and 330 attribute values MAY use the full ISO 10646 character set. Field and 331 attribute values which use the full UTF-8 character set are never 332 directly compared, hence there is no requirement for UTF-8 333 normalization. The textual form, as opposed to a binary encoding 334 such as ASN.1 or XDR, was chosen to enhance portability, to enable a 335 variety of transports to be used, and to allow flexible, text-based 336 toolkits to be used to generate and process session descriptions. 338 However, since SDP may be used in environments where the maximum 339 permissable size of a session description is limited, the encoding is 340 deliberately compact. Also, since announcements may be transported 341 via very unreliable means or damaged by an intermediate caching 342 server, the encoding was designed with strict order and formatting 343 rules so that most errors would result in malformed session 344 announcements which could be detected easily and discarded. This 345 also allows rapid discarding of encrypted session announcements for 346 which a receiver does not have the correct key. 348 An SDP session description consists of a number of lines of text of 349 the form: 351 = 353 where MUST be exactly one case-significant character and 354 is structured text whose format depends on . In 355 general is either a number of fields delimited by a single 356 space character, or a free format string. Whitespace MUST NOT be 357 used either side of the "=" sign. 359 An SDP session description consists of a session-level section 360 followed by zero or more media-level sections. The session-level 361 part starts with a "v=" line and continues to the first media-level 362 section. The media description starts with an "m=" line and 363 continues to the next media description or end of the whole session 364 description. In general, session-level values are the default for 365 all media unless overridden by an equivalent media-level value. 367 Some lines in each description are REQUIRED and some are OPTIONAL but 368 all MUST appear in exactly the order given here (the fixed order 369 greatly enhances error detection and allows for a simple parser). 370 OPTIONAL items are marked with a "*". 372 Session description 373 v= (protocol version) 374 o= (owner/creator and session identifier) 375 s= (session name) 376 i=* (session information) 377 u=* (URI of description) 378 e=* (email address) 379 p=* (phone number) 380 c=* (connection information - not required if included in 381 all media) 382 b=* (zero or more bandwidth information lines) 383 One or more time descriptions ("t=" and "r=" lines, see below) 384 z=* (time zone adjustments) 385 k=* (encryption key) 386 a=* (zero or more session attribute lines) 387 Zero or more media descriptions 389 Time description 390 t= (time the session is active) 391 r=* (zero or more repeat times) 393 Media description, if present 394 m= (media name and transport address) 395 i=* (media title) 396 c=* (connection information - optional if included at 397 session-level) 398 b=* (zero or more bandwidth information lines) 399 k=* (encryption key) 400 a=* (zero or more media attribute lines) 402 The set of type letters is deliberately small and not intended to be 403 extensible -- an SDP parser MUST completely ignore any session 404 description that contains a type letter that it does not understand. 405 The attribute mechanism ("a=" described below) is the primary means 406 for extending SDP and tailoring it to particular applications or 407 media. Some attributes (the ones listed in Section 6 of this memo) 408 have a defined meaning, but others may be added on an application-, 409 media- or session-specific basis. An SDP parser MUST ignore any 410 attribute it doesn't understand. 412 An SDP session description may contain URIs which reference external 413 content in the "u=", "k=" and "a=" lines. These URIs may be 414 dereferenced in some cases, making the session description non-self 415 contained. 417 The connection ("c=") and attribute ("a=") information in the 418 session-level section applies to all the media of that session unless 419 overridden by connection information or an attribute of the same name 420 in the media description. For instance, in the example below, each 421 media behaves as if it were given a "recvonly" attribute. 423 An example SDP description is: 425 v=0 426 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 427 s=SDP Seminar 428 i=A Seminar on the session description protocol 429 u=http://www.example.com/seminars/sdp.pdf 430 e=j.doe@example.com (Jane Doe) 431 c=IN IP4 224.2.17.12/127 432 t=2873397496 2873404696 433 a=recvonly 434 m=audio 49170 RTP/AVP 0 435 m=video 51372 RTP/AVP 99 436 a=rtpmap:99 h263-1998/90000 438 Text fields 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. If the "a=charset" attribute is not present, 444 these octet strings MUST be interpreted as containing ISO-10646 445 characters in UTF-8 encoding (the presence of the "a=charset" 446 attribute MAY force some fields to be interpreted differently). 448 5.1 Protocol Version ("v=") 450 v=0 452 The "v=" field gives the version of the Session Description Protocol. 453 This memo defines version 0. There is no minor version number. 455 5.2 Origin ("o=") 457 o= 458 460 The "o=" field gives the originator of the session (her username and 461 the address of the user's host) plus a session identifier and version 462 number: 464 is the user's login on the originating host, or it is "-" 465 if the originating host does not support the concept of user ids. 466 The MUST NOT contain spaces. 468 is a numeric string such that the tuple of , 469 , , and form a 470 globally unique identifier for the session. The method of 471 allocation is up to the creating tool, but it has been 472 suggested that a Network Time Protocol (NTP) format timestamp be 473 used to ensure uniqueness [8]. 475 is a version number for this session description. Its 476 usage is up to the creating tool, so long as is 477 increased when a modification is made to the session data. Again, 478 it is RECOMMENDED that an NTP format timestamp is used. 480 is a text string giving the type of network. Initially 481 "IN" is defined to have the meaning "Internet", but other values 482 MAY be registered in future (see Section 8). 484 is a text string giving the type of the address that 485 follows. Initially "IP4" and "IP6" are defined, but other values 486 MAY be registered in future (see Section 8). 488 is the address of the machine from which the 489 session was created. For an address type of IP4, this is either 490 the fully-qualified domain name of the machine, or the 491 dotted-decimal representation of the IP version 4 address of the 492 machine. For an address type of IP6, this is either the 493 fully-qualified domain name of the machine, or the compressed 494 textual representation of the IP version 6 address of the machine. 495 For both IP4 and IP6, the fully-qualified domain name is the form 496 that SHOULD be given unless this is unavailable, in which case the 497 globally unique address MAY be substituted. A local IP address 498 MUST NOT be used in any context where the SDP description might 499 leave the scope in which the address is meaningful. 501 In general, the "o=" field serves as a globally unique identifier for 502 this version of this session description, and the subfields excepting 503 the version taken together identify the session irrespective of any 504 modifications. 506 5.3 Session Name ("s=") 508 s= 510 The "s=" field is the textual session name. There MUST be one and 511 only one "s=" field per session description. The "s=" field MUST NOT 512 be empty and SHOULD contain ISO 10646 characters (but see also the 513 "a=charset" attribute). If a session has no meaningful name, the 514 value "s= " SHOULD be used (i.e. a single space as the session 515 name). 517 5.4 Session Information ("i=") 519 i= 521 The "i=" field provides textual information about the session. There 522 MUST be at most one session-level "i=" field per session description, 523 and at most one "i=" field per media. If the "a=charset" attribute 524 is present, it specifies the character set used in the "i=" field. 525 If the "a=charset" attribute is not present, the "i=" field MUST 526 contain ISO 10646 characters in UTF-8 encoding. 528 A single "i=" field MAY also be used for each media definition. In 529 media definitions, "i=" fields are primarily intended for labeling 530 media streams. As such, they are most likely to be useful when a 531 single session has more than one distinct media stream of the same 532 media type. An example would be two different whiteboards, one for 533 slides and one for feedback and questions. 535 The "i=" field is intended to provide a free-form human readable 536 description of the session or the purpose of a media stream. It is 537 not suitable for parsing by automata. 539 5.5 URI ("u=") 541 u= 543 A URI is a Universal Resource Identifier as used by WWW clients [4], 544 [6]. The URI should be a pointer to additional information about the 545 session. This field is OPTIONAL, but if it is present it MUST be 546 specified before the first media field. No more than one URI field 547 is allowed per session description. 549 5.6 Email Address and Phone Number ("e=" and "p=") 551 e= 552 p= 554 The "e=" and "p=" lines specify contact information for the person 555 responsible for the conference. This is not necessarily the same 556 person that created the conference announcement. 558 Inclusion of an email address or phone number is OPTIONAL. Note that 559 the previous version of SDP specified that either an email field or a 560 phone field MUST be specified, but this was widely ignored. The 561 change brings the specification into line with common usage. 563 If the email addres or phone number are present, they MUST be 564 specified before the first media field. More than one email or phone 565 field can be given for a session description. 567 Phone numbers SHOULD be given in the form of an international public 568 telecommunication number (see ITU-T Recommendation E.164) preceded by 569 a "+". Spaces and hyphens may be used to split up a phone field to 570 aid readability if desired. For example: 572 p=+1 617 555-6011 574 Both email addresses and phone numbers can have an OPTIONAL free text 575 string associated with them, normally giving the name of the person 576 who may be contacted. This MUST be enclosed in parenthesis if it is 577 present. For example: 579 e=j.doe@example.com (Jane Doe) 581 The alternative RFC 2822 name quoting convention is also allowed for 582 both email addresses and phone numbers. For example: 584 e=Jane Doe 586 The free text string SHOULD be in the ISO-10646 character set with 587 UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if 588 the appropriate session-level "a=charset" attribute is set. 590 5.7 Connection Data ("c=") 592 c= 594 The "c=" field contains connection data. 596 A session description MUST contain either at least one "c=" field in 597 each media description or a single "c=" field at the session level. 598 It MAY contain a single session-level "c=" field and additional "c=" 599 field(s) per media description, in which case the per-media values 600 override the session-level settings for the respective media. 602 The first sub-field ("") is the network type, which is a 603 text string giving the type of network. Initially "IN" is defined to 604 have the meaning "Internet", but other values MAY be registered in 605 the future (see Section 8). 607 The second sub-field ("") is the address type. This allows 608 SDP to be used for sessions that are not IP based. This memo only 609 defines IP4 and IP6, but other values MAY be registered in the future 610 (see Section 8). 612 The third sub-field ("") is the connection 613 address. OPTIONAL sub-fields MAY be added after the connection 614 address depending on the value of the field. 616 When the is IP4 and IP6, the connection address is defined 617 as follows: 619 o If the session is multicast, the connection address will be an IP 620 multicast group address. If the session is not multicast, then 621 the connection address contains the unicast IP address of the 622 expected data source or data relay or data sink as determined by 623 additional attribute fields. It is not expected that unicast 624 addresses will be given in a session description that is 625 communicated by a multicast announcement, though this is not 626 prohibited. 628 o Sessions using an IPv4 multicast connection address MUST also have 629 a time to live (TTL) value present in addition to the multicast 630 address. The TTL and the address together define the scope with 631 which multicast packets sent in this conference will be sent. TTL 632 values MUST be in the range 0-255. While the TTL MUST be 633 specified, its use to scope multicast traffic is deprecated; 634 applications SHOULD use an adminstratively scoped address instead. 636 The TTL for the session is appended to the address using a slash as a 637 separator. An example is: 639 c=IN IP4 224.2.36.42/127 641 IPv6 multicast does not use TTL scoping, and hence the TTL value MUST 642 NOT be present for IPv6 multicast. It is expected that IPv6 scoped 643 addresses will be used to limit the scope of conferences. 645 Hierarchical or layered encoding schemes are data streams where the 646 encoding from a single media source is split into a number of layers. 647 The receiver can choose the desired quality (and hence bandwidth) by 648 only subscribing to a subset of these layers. Such layered encodings 649 are normally transmitted in multiple multicast groups to allow 650 multicast pruning. This technique keeps unwanted traffic from sites 651 only requiring certain levels of the hierarchy. For applications 652 requiring multiple multicast groups, we allow the following notation 653 to be used for the connection address: 655 [/]/ 657 If the number of addresses is not given it is assumed to be one. 658 Multicast addresses so assigned are contiguously allocated above the 659 base address, so that, for example: 661 c=IN IP4 224.2.1.1/127/3 663 would state that addresses 224.2.1.1, 224.2.1.2 and 224.2.1.3 are to 664 be used at a TTL of 127. This is semantically identical to including 665 multiple "c=" lines in a media description: 667 c=IN IP4 224.2.1.1/127 668 c=IN IP4 224.2.1.2/127 669 c=IN IP4 224.2.1.3/127 671 Similarly, an IPv6 example would be: 673 c=IN IP6 FF15::101/3 675 which is semantically equivalent to: 677 c=IN IP6 FF15::101 678 c=IN IP6 FF15::102 679 c=IN IP6 FF15::103 681 (remembering that the TTL field is not present in IPv6 multicast). 683 Multiple addresses or "c=" lines MAY be specified on a per-media 684 basis only if they provide multicast addresses for different layers 685 in a hierarchical or layered encoding scheme. They MUST NOT be 686 specified for a session-level "c=" field. 688 The slash notation for multiple addresses described above MUST NOT be 689 used for IP unicast addresses. 691 5.8 Bandwidth ("b=") 693 b=: 695 This OPTIONAL field denotes the proposed bandwidth to be used by the 696 session or media. The is an alphanumeric modifier giving 697 the meaning of the figure. Two values are defined in 698 this specification, but other values MAY be registered in future (see 699 Section 8 and [22], [16]): 701 CT If the bandwidth of a session or media in a session is different 702 from the bandwidth implicit from the scope, a "b=CT:..." line 703 SHOULD be supplied for the session giving the proposed upper limit 704 to the bandwidth used (the "conference total" bandwidth). The 705 primary purpose of this is to give an approximate idea as to 706 whether two or more sessions can co-exist simultaneously. When 707 using the CT modifier with RTP, if several RTP sessions are part 708 of the conference, the conference total refers to total bandwidth 709 of all RTP sessions. 711 AS The bandwidth is interpreted to be application-specific (it will 712 be the application's concept of maximum bandwidth). Normally this 713 will coincide with what is set on the application's "maximum 714 bandwidth" control if applicable. For RTP based applications, AS 715 gives the RTP "session bandwidth" as defined in section 6.2 of 716 [14]. 718 Note that CT gives a total bandwidth figure for all the media at all 719 sites. AS gives a bandwidth figure for a single media at a single 720 site, although there may be many sites sending simultaneously. 722 A prefix "X-" is defined for names. This is intended for 723 experimental purposes only. For example: 725 b=X-YZ:128 727 Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers 728 SHOULD be registered with IANA in the standard namespace. SDP 729 parsers MUST ignore bandwidth fields with unknown modifiers. 730 Modifiers MUST be alpha-numeric and, although no length limit is 731 given, they are recommended to be short. 733 The is interpreted as kilobits per second by default. 734 The definition of a new modifier MAY specify that the 735 bandwidth is to be interpreted in some alternative unit (the "CT" and 736 "AS" modifiers defined in this memo use the default units). 738 5.9 Timing ("t=") 740 t= 742 The "t=" lines specify the start and stop times for a session. 743 Multiple "t=" lines MAY be used if a session is active at multiple 744 irregularly spaced times; each additional "t=" lines specifies an 745 additional period of time for which the session will be active. If 746 the session is active at regular times, an "r=" line (see below) 747 should be used in addition to, and following, a "t=" line - in which 748 case the "t=" line specifies the start and stop times of the repeat 749 sequence. 751 The first and second sub-fields give the start and stop times for the 752 session respectively. These values are the decimal representation of 753 Network Time Protocol (NTP) time values in seconds since 1900 [8]. 754 To convert these values to UNIX time, subtract decimal 2208988800. 756 NTP timestamps are elsewhere represented by 64 bit values which wrap 757 sometime in the year 2036. Since SDP uses an arbitrary length 758 decimal representation, this should not cause an issue (SDP 759 timestamps MUST continue counting seconds since 1900, NTP will use 760 the value modulo the 64 bit limit). 762 If the is set to zero, then the session is not bounded, 763 though it will not become active until after the . If 764 the is also zero, the session is regarded as permanent. 766 User interfaces SHOULD strongly discourage the creation of unbounded 767 and permanent sessions as they give no information about when the 768 session is actually going to terminate, and so make scheduling 769 difficult. 771 The general assumption may be made, when displaying unbounded 772 sessions that have not timed out to the user, that an unbounded 773 session will only be active until half an hour from the current time 774 or the session start time, whichever is the later. If behaviour 775 other than this is required, an end-time SHOULD be given and modified 776 as appropriate when new information becomes available about when the 777 session should really end. 779 Permanent sessions may be shown to the user as never being active 780 unless there are associated repeat times which state precisely when 781 the session will be active. In general, permanent sessions SHOULD 782 NOT be created for any session expected to have a duration of less 783 than 2 months, and should be discouraged for sessions expected to 784 have a duration of less than 6 months. 786 5.10 Repeat Times ("r=") 788 r= 790 "r=" fields specify repeat times for a session. For example, if a 791 session is active at 10am on Monday and 11am on Tuesday for one hour 792 each week for three months, then the in the 793 corresponding "t=" field would be the NTP representation of 10am on 794 the first Monday, the would be 1 week, the would be 1 hour, and the offsets would be zero and 25 796 hours. The corresponding "t=" field stop time would be the NTP 797 representation of the end of the last session three months later. By 798 default all fields are in seconds, so the "r=" and "t=" fields might 799 be: 801 t=3034423619 3042462419 802 r=604800 3600 0 90000 804 To make description more compact, times may also be given in units of 805 days, hours or minutes. The syntax for these is a number immediately 806 followed by a single case-sensitive character. Fractional units are 807 not allowed - a smaller unit should be used instead. The following 808 unit specification characters are allowed: 810 d - days (86400 seconds) 811 h - hours (3600 seconds) 812 m - minutes (60 seconds) 813 s - seconds (allowed for completeness but NOT RECOMMENDED) 815 Thus, the above session announcement could also have been written: 817 r=7d 1h 0 25h 819 Monthly and yearly repeats cannot be directly specified with a single 820 SDP repeat time - instead separate "t=" fields should be used to 821 explicitly list the session times. 823 5.11 Time Zones ("z=") 825 z= .... 827 To schedule a repeated session which spans a change from daylight 828 saving time to standard time or vice-versa, it is necessary to 829 specify offsets from the base time. This is required because 830 different time zones change time at different times of day, different 831 countries change to or from daylight time on different dates, and 832 some countries do not have daylight saving time at all. 834 Thus in order to schedule a session that is at the same time winter 835 and summer, it must be possible to specify unambiguously by whose 836 time zone a session is scheduled. To simplify this task for 837 receivers, we allow the sender to specify the NTP time that a time 838 zone adjustment happens and the offset from the time when the session 839 was first scheduled. The "z=" field allows the sender to specify a 840 list of these adjustment times and offsets from the base time. 842 An example might be: 844 z=2882844526 -1h 2898848070 0 846 This specifies that at time 2882844526 the time base by which the 847 session's repeat times are calculated is shifted back by 1 hour, and 848 that at time 2898848070 the session's original time base is restored. 849 Adjustments are always relative to the specified start time - they 850 are not cumulative. Adjustments apply to all "t=" and "r=" lines in 851 a session description. 853 If a session is likely to last several years, it is expected that the 854 session announcement will be modified periodically rather than 855 transmit several years worth of adjustments in one session 856 announcement. 858 5.12 Encryption Keys ("k=") 860 k= 861 k=: 863 If transported over a secure and trusted channel, the session 864 description protocol MAY be used to convey encryption keys. A simple 865 mechanism for key exchange is provided by the key field ("k=") 866 although this is primarily supported for compatibility with older 867 implementations and its use is NOT RECOMMENDED. Work is in progress 868 to define new key exchange mechanisms for use with SDP [20][21] and 869 it is expected that new applications will use those mechanisms. 871 A key field is permitted before the first media entry (in which case 872 it applies to all media in the session), or for each media entry as 873 required. The format of keys and their usage is outside the scope of 874 this document, and the key field provides no way to indicate the 875 encryption algorithm to be used, key type, or other information about 876 the key: this is assumed to be provided by the higher-level protocol 877 using SDP. If there is a need to convey this information within SDP, 878 the extensions mentioned previously SHOULD be used. Many security 879 protocols require two keys: one for confidentiality, another for 880 integrity. This specification does not support transfer of two keys. 882 The method indicates the mechanism to be used to obtain a usable key 883 by external means, or from the encoded encryption key given. The 884 following methods are defined: 886 k=clear: 888 The encryption key is included untransformed in this key field. 889 This method MUST NOT be used unless it can be guaranteed that 890 the SDP is conveyed over a secure channel. The encryption key 891 is interpreted as text according to the charset attribute, use 892 the "k=base64:" method to convey characters that are otherwise 893 prohibited in SDP. 895 k=base64: 897 The encryption key is included in this key field but has been 898 base64 encoded [13] because it includes characters that are 899 prohibited in SDP. This method MUST NOT be used unless it can 900 be guaranteed that the SDP is conveyed over a secure channel. 902 k=uri: 904 A Universal Resource Identifier is included in the key field. 905 The URI refers to the data containing the key, and may require 906 additional authentication before the key can be returned. When 907 a request is made to the given URI, the reply should specify 908 the encoding for the key. The URI is often a secure HTTP URI, 909 although this is not required. 911 k=prompt 913 No key is included in this SDP description, but the session or 914 media stream referred to by this key field is encrypted. The 915 user should be prompted for the key when attempting to join the 916 session, and this user-supplied key should then be used to 917 decrypt the media streams. The use of user-specified keys is 918 NOT RECOMMENDED, since such keys tend to have weak security 919 properties. 921 The key field MUST NOT be used unless it can be guaranteed that the 922 SDP is conveyed over a secure and trusted channel. An example of 923 such a channel might be SDP embedded inside an S/MIME message or a 924 TLS-protected HTTP session. It is important to ensure that the 925 secure channel is with the party that is authorized to join the 926 session, not an intermediary: if a caching proxy server is used, it 927 is important to ensure that the proxy is either trusted or unable to 928 access the SDP. Definition of appropriate security measures is 929 beyond the scope of this specification, and should be defined by the 930 users of SDP. 932 5.13 Attributes ("a=") 934 a= 935 a=: 937 Attributes are the primary means for extending SDP. Attributes may 938 be defined to be used as "session-level" attributes, "media-level" 939 attributes, or both. 941 A media description may have any number of attributes ("a=" fields) 942 which are media specific. These are referred to as "media-level" 943 attributes and add information about the media stream. Attribute 944 fields can also be added before the first media field; these 945 "session-level" attributes convey additional information that applies 946 to the conference as a whole rather than to individual media. 948 Attribute fields may be of two forms: 950 o A property attribute is simply of the form "a=". These are 951 binary attributes, and the presence of the attribute conveys that 952 the attribute is a property of the session. An example might be 953 "a=recvonly". 955 o A value attribute is of the form "a=:". For 956 example, a whiteboard could have the value attribute 957 "a=orient:landscape" 959 Attribute interpretation depends on the media tool being invoked. 960 Thus receivers of session descriptions should be configurable in 961 their interpretation of session descriptions in general and of 962 attributes in particular. 964 Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. 966 Attribute values are octet strings, and MAY use any octet value 967 except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute 968 values are to be interpreted as in ISO-10646 character set with UTF-8 969 encoding. Unlike other text fields, attribute values are NOT 970 normally affected by the "charset" attribute as this would make 971 comparisons against known values problematic. However, when an 972 attribute is defined, it can be defined to be charset-dependent, in 973 which case its value should be interpreted in the session charset 974 rather than in ISO-10646. 976 Attributes MUST be registered with IANA (see Section 8). If an 977 attribute is received that is not understood, it MUST be ignored by 978 the receiver. 980 5.14 Media Descriptions ("m=") 982 m= ... 984 A session description may contain a number of media descriptions. 985 Each media description starts with an "m=" field, and is terminated 986 by either the next "m=" field or by the end of the session 987 description. A media field has several sub-fields: 989 is the media type. Currently defined media are "audio", 990 "video", "text" and "application", although this list may be 991 extended in future (see Section 8). 993 is the transport port to which the media stream is sent. The 994 meaning of the transport port depends on the network being used as 995 specified in the relevant "c=" field, and on the transport 996 protocol defined in the sub-field of the media field. 997 Other ports used by the media application (such as the RTCP port 999 [14]) MAY be derived algorithmically from the base media port or 1000 MAY be specified in a separate attribute (for example "a=rtcp:" as 1001 defined in [17]). 1003 For applications where hierarchically encoded streams are being 1004 sent to a unicast address, it may be necessary to specify multiple 1005 transport ports. This is done using a similar notation to that 1006 used for IP multicast addresses in the "c=" field: 1008 m= / 1010 In such a case, the ports used depend on the transport protocol. 1011 For RTP, the default is that only the even numbered ports are used 1012 for data with the corresponding one-higher odd ports used for the 1013 RTCP belonging to the RTP session, and the 1014 denoting the number of RTP sessions. For example: 1016 m=video 49170/2 RTP/AVP 31 1018 would specify that ports 49170 and 49171 form one RTP/RTCP pair 1019 and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the 1020 transport protocol and 31 is the format (see below). If 1021 non-contiguous ports are required, they must be signalled using a 1022 separate attribute (for example "a=rtcp:" as defined in [17]). 1024 If multiple addresses are specified in the "c=" field and multiple 1025 ports are specified in the "m=" field, a one-to-one mapping from 1026 port to the corresponding address is implied. For example: 1028 c=IN IP4 224.2.1.1/127/2 1029 m=video 49170/2 RTP/AVP 31 1031 would imply that address 224.2.1.1 is used with ports 49170 and 1032 49171, and address 224.2.1.2 is used with ports 49172 and 49173. 1034 The combination of ports specified in "m=" lines and IP addresses 1035 specified in "c=" lines MUST comply with the following rules for 1036 RTP-based media streams (other protocols SHOULD define similar 1037 rules): 1039 1. If two media sessions have the same transport address (i.e. 1040 identical IP address and port numbers), the associated payload 1041 types (e.g. given in the "a=rtpmap:" attribute) MUST NOT be 1042 in conflict, i.e. the same payload type MUST NOT be mapped to 1043 different media types. 1045 2. If two media sessions have the same transport address, they 1046 MUST use compatible media (e.g. both audio or both video). 1048 3. If two media sessions have the same transport address, they 1049 SHOULD operate under the same RTP profile. The sessions MAY 1050 use two different RTP profiles only if those profiles are 1051 specifically designed to be compatible. 1053 4. If two media sessions have the same RTP transport address, 1054 they MUST also use the same RTCP address and vice versa. 1056 Two media sessions with the same transport address indicate 1057 alternatives for the same media stream, i.e. all profiles, media 1058 types, and payload types provided in any of the "m=" lines are 1059 valid. 1061 is the transport protocol. The meaning of the transport 1062 protocol is dependent on the address type field in the relevant 1063 "c=" field. Thus a "c=" field of IP4 indicates that the transport 1064 protocol runs over IP4. The following transport protocols are 1065 defined, but may be extended through registration of new protocols 1066 with IANA (see Section 8): 1068 * udp: denotes an unspecified protocol running over UDP. 1070 * RTP/AVP: denotes RTP [14] used under the RTP Profile for Audio 1071 and Video Conferences with Minimal Control [15] running over 1072 UDP. 1074 * RTP/SAVP: denotes the Secure Real-time Transport Protocol [18] 1075 running over UDP. 1077 The main reason to specify the transport-protocol in addition to 1078 the media format is that the same standard media formats may be 1079 carried over different transport protocols even when the network 1080 protocol is the same - a historical example is vat PCM audio and 1081 RTP PCM audio, another might be TCP/RTP PCM audio. In addition, 1082 relays and monitoring tools that are transport-protocol-specific 1083 but format-independent are possible. 1085 is a media format description. The fourth and any subsequent 1086 sub-fields describe the format of the media. The interpretation 1087 of the media format depends on the value of the sub-field. 1089 If the sub-field is "RTP/AVP" or "RTP/SAVP" the 1090 sub-fields contain RTP payload type numbers. When a list of 1091 payload type numbers is given, this implies that all of these 1092 payload formats MAY be used in the session, but the first of these 1093 formats SHOULD be used as the default format for the session. For 1094 dynamic payload type assignments the "a=rtpmap:" attribute (see 1095 Section 6) SHOULD be used to map from an RTP payload type number 1096 to a media encoding name that identifies the payload format. The 1097 "a=fmtp:" attribute MAY be used to specify format parameters (see 1098 Section 6). 1100 If the sub-field is "udp" the sub-fields MUST 1101 reference a media type describing the format under the "audio", 1102 "video", "text" and "application" top-level MIME types. The media 1103 type registration SHOULD define the packetization format for use 1104 with UDP transport. 1106 For media using other transport protocols, the field is 1107 protocol specific. Rules for interpretation of the 1108 sub-field MUST be defined when registering new protocols (see 1109 section 8.2.2). 1111 6. SDP Attributes 1113 The following attributes are defined. Since application writers may 1114 add new attributes as they are required, this list is not exhaustive. 1115 Registration procedures for new attributes are defined in Section 1116 8.2.4. 1118 a=cat: 1120 This attribute gives the dot-separated hierarchical category 1121 of the session. This is to enable a receiver to filter 1122 unwanted sessions by category. It is a session-level 1123 attribute, and is not 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 1130 of the session. It is a session-level attribute. It is a 1131 charset dependent attribute, meaning that its value should be 1132 interpreted in the charset specified for the session 1133 description if one is specified, or by default in ISO 1134 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 1158 be 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: / 1166 [/] 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 "audio/l8" 1207 and "audio/l16". 1209 For audio streams, indicates the 1210 number of audio channels. This parameter is OPTIONAL and 1211 may be omitted if the number of channels is one, provided 1212 no 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 1232 only mode where applicable. It can be either a session or 1233 media attribute, and is not dependent on charset. Note that 1234 recvonly applies to the media only, not to any associated 1235 control protocol (e.g. an RTP based system in recvonly mode 1236 SHOULD 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 1255 source. In such a case, two media descriptions may be used, 1256 one sendonly and one recvonly. It can be either a session or 1257 media 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 1275 the 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" 1284 sessions, "type:meeting" should imply "sendrecv" and 1285 "type:moderated" should indicate the use of a floor control 1286 tool and that the media tools are started so as to mute new 1287 sites joining the 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 [15]. 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 1308 SDP 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 1321 use of bytes 0x00 (Nul), 0x0A (LF) and 0x0d (CR). Character 1322 sets requiring the use of these characters MUST define a 1323 quoting mechanism that prevents these bytes appearing within 1324 text 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 1333 sdplang attributes can be provided either at session or media 1334 level if multiple languages in the session description or 1335 media use multiple languages, in which case the order of the 1336 attributes indicates the order of importance of the various 1337 languages in the session or media from most important to least 1338 important. 1340 In general, sending session descriptions consisting of 1341 multiple languages is discouraged. Instead, multiple 1342 descriptions SHOULD be sent describing the session, one in 1343 each language. However this is not possible with all 1344 transport mechanisms, and so multiple sdplang attributes are 1345 allowed although NOT RECOMMENDED. 1347 The "sdplang" attribute value must be a single RFC 3066 1348 language tag in US-ASCII [6]. It is not dependent on 1349 the charset attribute. An "sdplang" attribute SHOULD be 1350 specified when a session is of sufficient scope to cross 1351 geographic boundaries where the language of recipients cannot 1352 be assumed, or where the session is in a different language 1353 from the locally assumed norm. 1355 a=lang: 1357 This can be a session level attribute or a media level 1358 attribute. As a session level attribute, it specifies the 1359 default language for the session being described. As a media 1360 level attribute, it specifies the language for that media, 1361 overriding any session-level language specified. Multiple 1362 lang attributes can be provided either at session or media 1363 level if the session description or media use multiple 1364 languages, in which case the order of the attributes indicates 1365 the order of importance of the various languages in the 1366 session or media from most important to least important. 1368 The "lang" attribute value must be a single RFC 3066 language 1369 tag in US-ASCII [6]. It is not dependent on the charset 1370 attribute. A "lang" attribute SHOULD be specified when a 1371 session is of sufficient scope to cross geographic boundaries 1372 where the language of recipients cannot be assumed, or where 1373 the session is in a different language from the locally 1374 assumed norm. 1376 a=framerate: 1378 This gives the maximum video frame rate in frames/sec. It is 1379 intended as a recommendation for the encoding of video data. 1381 Decimal representations of fractional values using the 1382 notation "." are allowed. It is a 1383 media attribute, defined only for video media, and is not 1384 dependent on charset. 1386 a=quality: 1388 This gives a suggestion for the quality of the encoding as an 1389 integer value. The intention of the quality attribute for 1390 video is to specify a non-default trade-off between frame-rate 1391 and still-image quality. For video, the value in the range 0 1392 to 10, with the following suggested meaning: 1394 10 - the best still-image quality the compression scheme 1395 can give. 1396 5 - the default behaviour given no quality suggestion. 1397 0 - the worst still-image quality the codec designer 1398 thinks is still usable. 1400 It is a media attribute, and is not dependent on charset. 1402 a=fmtp: 1404 This attribute allows parameters that are specific to a 1405 particular format to be conveyed in a way that SDP doesn't 1406 have to understand them. The format must be one of the 1407 formats specified for the media. Format-specific parameters 1408 may be any set of parameters required to be conveyed by SDP 1409 and given unchanged to the media tool that will use this 1410 format. At most one instance of this attribute is allowed 1411 for each format. 1413 It is a media attribute, and is not dependent on charset. 1415 7. Security Considerations 1417 SDP is frequently used with the Session Initiation Protocol [10] 1418 using the offer/answer model [12] to agree parameters for unicast 1419 sessions. When used in this manner, the security considerations of 1420 those protocols apply. 1422 SDP is a session description format that describes multimedia 1423 sessions. A session description SHOULD NOT be trusted unless it has 1424 been obtained by an authenticated transport protocol from a trusted 1425 source. Many different transport protocols may be used to distribute 1426 session description, and the nature of the authentication will differ 1427 from transport to transport. 1429 One transport that will frequently be used to distribute session 1430 descriptions is the Session Announcement Protocol (SAP). SAP 1431 provides both encryption and authentication mechanisms but due to the 1432 nature of session announcements it is likely that there are many 1433 occasions where the originator of a session announcement cannot be 1434 authenticated because they are previously unknown to the receiver of 1435 the announcement and because no common public key infrastructure is 1436 available. 1438 On receiving a session description over an unauthenticated transport 1439 mechanism or from an untrusted party, software parsing the session 1440 should take a few precautions. Session descriptions contain 1441 information required to start software on the receivers system. 1442 Software that parses a session description MUST NOT be able to start 1443 other software except that which is specifically configured as 1444 appropriate software to participate in multimedia sessions. It is 1445 normally considered inappropriate for software parsing a session 1446 description to start, on a user's system, software that is 1447 appropriate to participate in multimedia sessions, without the user 1448 first being informed that such software will be started and giving 1449 their consent. Thus a session description arriving by session 1450 announcement, email, session invitation, or WWW page MUST NOT deliver 1451 the user into an interactive multimedia session unless the user has 1452 explicitly pre-authorized such action. As it is not always simple to 1453 tell whether a session is interactive or not, applications that are 1454 unsure should assume sessions are interactive. 1456 In this specification, there are no attributes which would allow the 1457 recipient of a session description to be informed to start multimedia 1458 tools in a mode where they default to transmitting. Under some 1459 circumstances it might be appropriate to define such attributes. If 1460 this is done an application parsing a session description containing 1461 such attributes SHOULD either ignore them, or inform the user that 1462 joining this session will result in the automatic transmission of 1463 multimedia data. The default behaviour for an unknown attribute is 1464 to ignore it. 1466 Session descriptions may be parsed at intermediate systems such as 1467 firewalls for the purposes of opening a hole in the firewall to allow 1468 participation in multimedia sessions. This SHOULD NOT be done unless 1469 the SDP is conveyed in a manner that allows proper authentication and 1470 authorization checks to ensure that firewall holes are only opened in 1471 accordance with applicable security policy. SDP by itself does not 1472 include sufficient information to enable these checks: they depend on 1473 the encapsulating protocol (e.g. SIP or RTSP). 1475 Use of the "k=" field poses a significant security risk, since it 1476 conveys session encryption keys in the clear. SDP MUST NOT be used 1477 to convey key material, unless it can be guaranteed that the channel 1478 over which the SDP is delivered is both private and authenticated. 1480 8. IANA Considerations 1482 8.1 The "application/sdp" media type 1484 One MIME type is to be registered, as defined below. This updates 1485 the previous definition from RFC 2327. 1487 To: ietf-types@iana.org 1488 Subject: Registration of media type "application/sdp" 1490 MIME media type name: application 1492 MIME subtype name: sdp 1494 Required parameters: None. 1496 Optional parameters: None. 1498 Encoding considerations: 1499 See section 5 of RFC XXXX 1501 Security considerations: 1502 See section 8 of RFC XXXX 1504 Interoperability considerations: 1505 See RFC XXXX 1507 Published specification: 1508 See RFC XXXX 1510 Applications which use this media type: 1511 Voice over IP, video teleconferencing, streaming media, instant 1512 messaging, etc. See also section 3 of RFC XXXX. 1514 Additional information: 1516 Magic number(s): None. 1517 File extension(s): The extension ".sdp" is commonly used. 1518 Macintosh File Type Code(s): "sdp " 1520 Person & email address to contact for further information: 1521 Colin Perkins 1522 IETF MMUSIC working group 1524 Intended usage: COMMON 1525 Author/Change controller: 1526 Authors of RFC XXXX 1527 IETF MMUSIC working group delegated from the IESG 1529 8.2 Registration of Parameters 1531 There are seven field names that may be registered with IANA. Using 1532 the terminology in the SDP specification BNF, they are "media", 1533 "proto", "fmt", "att-field", "bwtype", "nettype" and "addrtype". 1535 8.2.1 Media types ("media") 1537 The set of media types is intended to be small and SHOULD NOT be 1538 extended except under rare circumstances. The same rules should 1539 apply for media names as for top-level MIME content types, and where 1540 possible the same name should be registered for SDP as for MIME. For 1541 media other than existing MIME top-level content types, a 1542 standards-track RFC MUST be produced for a new top-level content type 1543 to be registered, and the registration MUST provide good 1544 justification why no existing media name is appropriate (the 1545 "Standards Action" policy of RFC 2434 [5]. 1547 This memo registers the media types "audio", "video", "text" and 1548 "application". 1550 8.2.2 Transport protocols ("proto") 1552 The "proto" field describes the transport protocol used. This SHOULD 1553 reference a standards-track protocol RFC. This memo registers three 1554 values: "RTP/AVP" is a reference to RTP [14] used under the RTP 1555 Profile for Audio and Video Conferences with Minimal Control [15] 1556 running over UDP/IP, "RTP/SAVP" is a reference to the Secure 1557 Real-time Transport Protocol [18], and "udp" indicates an unspecified 1558 protocol over UDP. 1560 If other RTP profiles are defined in the future, their "proto" name 1561 SHOULD be specified in the same manner. For example, an RTP profile 1562 whose short name is "XYZ" would be denoted by a "proto" field of 1563 "RTP/XYZ". 1565 New transport protocols SHOULD be registered with IANA. 1566 Registrations MUST reference an RFC describing the protocol. Such an 1567 RFC MAY be Experimental or Informational, although it is preferable 1568 if it is Standards-Track. Registrations MUST also define the rules 1569 by which their "fmt" namespace is managed (see below). 1571 8.2.3 Media formats ("fmt") 1573 Each transport protocol, defined by the "proto" field, has an 1574 associated "fmt" namespace that describes the media formats which may 1575 conveyed by that protocol. Formats cover all the possible encodings 1576 that might want to be transported in a multimedia session. 1578 RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST 1579 use the payload type number as their "fmt" value. If the payload 1580 type number is dynamically assigned by this session description, an 1581 additional "rtpmap" attribute MUST be included to specify the format 1582 name and parameters as defined by the MIME type registration for the 1583 payload format. It is RECOMMENDED that other RTP profiles which are 1584 registered (in combination with RTP) as SDP transport protocols 1585 specify the same rules for the "fmt" namespace. 1587 For the "udp" protocol, new formats SHOULD be registered. Use of an 1588 existing MIME subtype for the format is encouraged. If no MIME 1589 subtype exists, it is RECOMMENDED that a suitable one is registered 1590 through the IETF process (RFC 2048) by production of, or reference 1591 to, a standards-track RFC that defines the transport protocol for the 1592 format. 1594 For other protocols, formats MAY be registered according to the rules 1595 of the associated "proto" specification. 1597 Registrations of new formats MUST specify which transport protocols 1598 they apply to. 1600 8.2.4 Attribute names ("att-field") 1602 Attribute field names ("att-field") MUST be registered with IANA and 1603 documented, because of noticeable issues due to conflicting 1604 attributes under the same name. Unknown attributes in SDP are simply 1605 ignored, but conflicting ones that fragment the protocol are a 1606 serious problem. 1608 New attribute registerations are accepted according to the 1609 "Specification Required" policy of RFC 2434, provided that the 1610 specification includes the following information: 1612 o contact name, email address and telephone number 1614 o attribute-name (as it will appear in SDP) 1616 o long-form attribute name in English 1618 o type of attribute (session level, media level, or both) 1619 o whether the attribute value is subject to the charset attribute. 1621 o a one paragraph explanation of the purpose of the attribute. 1623 o a specification of appropriate attribute values for this 1624 attribute. 1626 The above is the minimum that IANA will accept. Attributes that are 1627 expected to see widespread use and interoperability, SHOULD be 1628 documented with a standards-track RFC that specifies the attribute 1629 more precisely. 1631 Submitters of registrations should ensure that the specification is 1632 in the spirit of SDP attributes, most notably that the attribute is 1633 platform independent in the sense that it makes no implicit 1634 assumptions about operating systems and does not name specific pieces 1635 of software in a manner that might inhibit interoperability. 1637 IANA is requested to register the following initial set of attribute 1638 names ("att-field" values), with definitions as in Section 6 of this 1639 memo (these definitions update those in RFC 2327): 1641 Name | Session or Media level? | Dependent on charset? 1642 ----------+-------------------------+---------------------- 1643 cat | Session | No 1644 keywds | Session | Yes 1645 tool | Session | No 1646 ptime | Media | No 1647 maxptime | Media | No 1648 rtpmap | Media | No 1649 recvonly | Either | No 1650 sendrecv | Either | No 1651 sendonly | Either | No 1652 inactive | Either | No 1653 orient | Media | No 1654 type | Session | No 1655 charset | Session | No 1656 sdplang | Either | No 1657 lang | Either | No 1658 framerate | Media | No 1659 quality | Media | No 1660 fmtp | Media | No 1662 8.2.5 Bandwidth specifiers ("bwtype") 1664 A proliferation of bandwidth specifiers is strongly discouraged. 1666 New bandwidth specifiers ("bwtype" fields) MUST be registered with 1667 IANA. The submission MUST reference a standards-track RFC specifying 1668 the semantics of the bandwidth specifier precisely, and indicating 1669 when it should be used, and why the existing registered bandwidth 1670 specifiers do not suffice. 1672 IANA is requested to register the bandwith specifiers "CT" and "AS" 1673 with definitions as in Section 5.8 of this memo (these definitions 1674 update those in RFC 2327). 1676 8.2.6 Network types ("nettype") 1678 New network types (the "nettype" field) may be registered with IANA 1679 if SDP needs to be used in the context of non-Internet environments. 1680 Whilst these are not normally the preserve of IANA, there may be 1681 circumstances when an Internet application needs to interoperate with 1682 a non- Internet application, such as when gatewaying an Internet 1683 telephony call into the PSTN. The number of network types should be 1684 small and should be rarely extended. A new network type cannot be 1685 registered without registering at least one address type to be used 1686 with that network type. A new network type registration MUST 1687 reference an RFC which gives details of the network type and address 1688 type and specifies how and when they would be used. 1690 IANA is requested to register the network type "IN" to represent the 1691 Internet, with definition as in Sections 5.2 and 5.7 of this memo 1692 (these definitions update those in RFC 2327). 1694 8.2.7 Address types ("addrtype") 1696 New address types ("addrtype") may be registered with IANA. An 1697 address type is only meaningful in the context of a network type, and 1698 any registration of an address type MUST specify a registered network 1699 type, or be submitted along with a network type registration. A new 1700 address type registration MUST reference an RFC giving details of the 1701 syntax of the address type. Address types are not expected to be 1702 registered frequently. 1704 IANA is requested to register the address types "IP4" and "IP6" with 1705 definitions as in Sections 5.2 and 5.7 of this memo (these 1706 definitions update those in RFC 2327). 1708 8.2.8 Registration Procedure 1710 In the RFC documentation that registers SDP "media", "proto", "fmt", 1711 "bwtype", "nettype" and "addrtype" fields, the authors MUST include 1712 the following information for IANA to place in the appropriate 1713 registry: 1715 o contact name, email address and telephone number 1717 o name being registered (as it will appear in SDP) 1719 o long-form name in English 1721 o type of name ("media", "proto", "fmt", "bwtype", "nettype", or 1722 "addrtype") 1724 o a one paragraph explanation of the purpose of the registered name. 1726 o a reference to the specification for the registered name (this 1727 will typically be an RFC number). 1729 IANA may refer any registration to the IESG Transport Area Directors 1730 for review, and may request revisions to be made before a 1731 registration will be made. 1733 8.3 Encryption Key Access Methods 1735 The IANA currently maintains a table of SDP encryption key access 1736 method ("enckey") names. This table is obsolete and SHOULD be 1737 removed, since the "k=" line is not extensible. New registrations 1738 MUST NOT be accepted. 1740 Appendix A. SDP Grammar 1742 This appendix provides an Augmented BNF grammar for SDP. ABNF is 1743 defined in [2]. 1745 ; SDP Syntax 1746 session-description = proto-version 1747 origin-field 1748 session-name-field 1749 information-field 1750 uri-field 1751 email-fields 1752 phone-fields 1753 connection-field 1754 bandwidth-fields 1755 time-fields 1756 key-field 1757 attribute-fields 1758 media-descriptions 1760 proto-version = "v=" 1*DIGIT CRLF 1761 ;this memo describes version 0 1763 origin-field = "o=" username SP sess-id SP sess-version SP 1764 nettype SP addrtype SP unicast-address CRLF 1766 session-name-field = "s=" text CRLF 1768 information-field = ["i=" text CRLF] 1770 uri-field = ["u=" uri CRLF] 1772 email-fields = *("e=" email-address CRLF) 1774 phone-fields = *("p=" phone-number CRLF) 1776 connection-field = ["c=" nettype SP addrtype SP 1777 connection-address CRLF] 1778 ;a connection field must be present 1779 ;in every media description or at the 1780 ;session-level 1782 bandwidth-fields = *("b=" bwtype ":" bandwidth CRLF) 1784 time-fields = 1*( "t=" start-time SP stop-time 1785 *(CRLF repeat-fields) CRLF) 1786 [zone-adjustments CRLF] 1788 repeat-fields = "r=" repeat-interval SP typed-time 1789 1*(SP typed-time) 1791 zone-adjustments = "z=" time SP ["-"] typed-time 1792 *(SP time SP ["-"] typed-time) 1794 key-field = ["k=" key-type CRLF] 1796 attribute-fields = *("a=" attribute CRLF) 1798 media-descriptions = *( media-field 1799 information-field 1800 *connection-field 1801 bandwidth-fields 1802 key-field 1803 attribute-fields ) 1805 media-field = "m=" media SP port ["/" integer] 1806 SP proto 1*(SP fmt) CRLF 1808 ; sub-rules of 'o=' 1809 username = non-ws-string 1810 ;pretty wide definition, but doesn't 1811 ;include space 1813 sess-id = 1*DIGIT 1814 ;should be unique for this username/host 1816 sess-version = 1*DIGIT 1818 nettype = token 1819 ;typically "IN" 1821 addrtype = token 1822 ;typically "IP4" or "IP6" 1824 ; sub-rules of 'u=' 1825 uri = URI-reference 1826 ; see RFC2396 and RFC2732 1828 ; sub-rules of 'e=' 1829 email-address = email *SP "(" 1*email-safe ")" / 1830 1*email-safe "<" email ">" / 1831 email 1833 email = addr-spec ; defined in RFC2822 1834 ; modified to remove CFWS 1836 ; sub-rules of 'p=' 1837 phone-number = phone *SP "(" 1*email-safe ")" / 1838 1*email-safe "<" phone ">" / 1839 phone 1841 phone = ["+"] DIGIT 1*(SP / "-" / DIGIT) 1843 ; sub-rules of 'c=' 1844 connection-address = multicast-address / unicast-address 1846 ; sub-rules of 'b=' 1847 bwtype = token 1849 bandwidth = 1*DIGIT 1851 ; sub-rules of 't=' 1852 start-time = time / "0" 1854 stop-time = time / "0" 1856 time = POS-DIGIT 9*DIGIT 1857 ; Decimal representation of NTP time in 1858 ; seconds since 1900. The representation 1859 ; of NTP time is an unbounded length field 1860 ; containing at least 10 digits. Unlike the 1861 ; 64-bit representation used elsewhere, time 1862 ; in SDP does not wrap in the year 2036. 1864 ; sub-rules of 'r=' and 'z=' 1865 repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] 1867 typed-time = 1*DIGIT [fixed-len-time-unit] 1869 fixed-len-time-unit = "d" / "h" / "m" / "s" 1871 ; sub-rules of 'k=' 1872 key-type = "prompt" / 1873 "clear:" text / 1874 "base64:" base64 / 1875 "uri:" uri 1877 base64 = *base64-unit [base64-pad] 1878 base64-unit = 4base64-char 1879 base64-pad = 2base64-char "==" / 3base64-char "=" 1880 base64-char = ALPHA / DIGIT / "+" / "/" 1882 ; sub-rules of 'a=' 1883 attribute = (att-field ":" att-value) / att-field 1885 att-field = token 1887 att-value = byte-string 1889 ; sub-rules of 'm=' 1890 media = token 1891 ;typically "audio", "video", "text" or 1892 ;"application" 1894 fmt = token 1895 ;typically an RTP payload type for audio 1896 ;and video media 1898 proto = token *("/" token) 1899 ;typically "RTP/AVP" or "udp" 1901 port = 1*DIGIT 1903 ; generic sub-rules: addressing 1904 unicast-address = IP4-address / IP6-address / FQDN / extn-addr 1906 multicast-address = IP4-multicast / IP6-multicast / FQDN 1907 / extn-addr 1909 IP4-multicast = m1 3( "." decimal-uchar ) 1910 "/" ttl [ "/" integer ] 1911 ; IPv4 multicast addresses may be in the 1912 ; range 224.0.0.0 to 239.255.255.255 1914 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / 1915 ("23" DIGIT ) 1917 IP6-multicast = hexpart [ "/" integer ] 1918 ; IPv6 address starting with FF 1920 ttl = (POS-DIGIT *2DIGIT) / "0" 1922 FQDN = 4*(alpha-numeric / "-" / ".") 1923 ; fully qualified domain name as specified 1924 ; in RFC1035 (and updates) 1926 IP4-address = b1 3("." decimal-uchar) 1928 b1 = decimal-uchar 1929 ; less than "224" 1931 ; The following is from RFC2373 Appendix B. It is a direct copy. 1932 IP6-address = hexpart [ ":" IP4-address ] 1934 hexpart = hexseq / hexseq "::" [ hexseq ] / 1935 "::" [ hexseq ] 1937 hexseq = hex4 *( ":" hex4) 1939 hex4 = 1*4HEXDIG 1941 ; Generic for other address families 1942 extn-addr = non-ws-string 1944 ; generic sub-rules: datatypes 1945 text = byte-string 1946 ;default is to interpret this as UTF8 text. 1947 ;ISO 8859-1 requires "a=charset:ISO-8859-1" 1948 ;session-level attribute to be used 1950 byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) 1951 ;any byte except NUL, CR or LF 1953 non-ws-string = 1*(VCHAR/%x80-FF) 1954 ;string of visible characters 1956 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 1957 / %x41-5A / %x5E-7E 1959 token = 1*(token-char) 1961 email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF 1962 ;any byte except NUL, CR, LF, or the quoting 1963 ;characters ()<> 1965 integer = POS-DIGIT *DIGIT 1967 ; generic sub-rules: primitives 1968 alpha-numeric = ALPHA / DIGIT 1970 POS-DIGIT = %x31-39 ; 1 - 9 1972 decimal-uchar = DIGIT 1973 / POS-DIGIT DIGIT 1974 / ("1" 2*(DIGIT)) 1975 / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) 1976 / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) 1978 ; external references: 1979 ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 2234 1980 ; URI-reference: from RFC2396 and RFC2732 1981 ; addr-spec: from RFC 2822 1983 Appendix B. Acknowledgments 1985 Many people in the IETF MMUSIC working group have made comments and 1986 suggestions contributing to this document. In particular, we would 1987 like to thank Eve Schooler, Steve Casner, Bill Fenner, Allison 1988 Mankin, Ross Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, 1989 Steve Hanna, Jonathan Lennox and Keith Drage. 1991 9. References 1993 9.1 Normative References 1995 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1996 Levels", BCP 14, RFC 2119, March 1997. 1998 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1999 Specifications: ABNF", RFC 2234, November 1997. 2001 [3] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2002 2279, January 1998. 2004 [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource 2005 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 2007 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2008 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 2010 [6] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal 2011 IPv6 Addresses in URL's", RFC 2732, December 1999. 2013 [7] Alvestrand, H., "Tags for the Identification of Languages", BCP 2014 47, RFC 3066, January 2001. 2016 9.2 Informative References 2018 [8] Mills, D., "Network Time Protocol (Version 3) Specification, 2019 Implementation", RFC 1305, March 1992. 2021 [9] Handley, M., Perkins, C. and E. Whelan, "Session Announcement 2022 Protocol", RFC 2974, October 2000. 2024 [10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2025 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 2026 Session Initiation Protocol", RFC 3261, June 2002. 2028 [11] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 2029 Protocol (RTSP)", RFC 2326, April 1998. 2031 [12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2032 Session Description Protocol (SDP)", RFC 3264, June 2002. 2034 [13] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 2035 RFC 3548, July 2003. 2037 [14] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 2038 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 2039 RFC 3550, July 2003. 2041 [15] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 2042 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 2044 [16] Casner, S., "Session Description Protocol (SDP) Bandwidth 2045 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, 2046 July 2003. 2048 [17] Huitema, C., "Real Time Control Protocol (RTCP) attribute in 2049 Session Description Protocol (SDP)", RFC 3605, October 2003. 2051 [18] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K. 2053 Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 2054 3711, March 2004. 2056 [19] International Telecommunications Union, "H.323 extended for 2057 loosely coupled conferences", ITU Recommendation H.332, 2058 September 1998. 2060 [20] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K. 2061 Norrman, "Key Management Extensions for Session Description 2062 Protocol (SDP) and Real Time Streaming Protocol (RTSP)", 2063 draft-ietf-mmusic-kmgmt-ext-11 (work in progress), April 2004. 2065 [21] Andreasen, F., Baugher, M. and D. Wing, "Session Description 2066 Protocol Security Descriptions for Media Streams", 2067 draft-ietf-mmusic-sdescriptions-07 (work in progress), July 2068 2004. 2070 [22] Westerlund, M., "A Transport Independent Bandwidth Modifier for 2071 the Session Description Protocol (SDP)", 2072 draft-ietf-mmusic-sdp-bwparam-06 (work in progress), April 2073 2004. 2075 Authors' Addresses 2077 Mark Handley 2078 University College London 2079 Department of Computer Science 2080 Gower Street 2081 London WC1E 6BT 2082 UK 2084 EMail: M.Handley@cs.ucl.ac.uk 2086 Van Jacobson 2087 Packet Design 2088 2465 Latham Street 2089 Mountain View, CA 94040 2090 USA 2092 EMail: van@packetdesign.com 2093 Colin Perkins 2094 University of Glasgow 2095 Department of Computing Science 2096 17 Lilybank Gardens 2097 Glasgow G12 8QQ 2098 UK 2100 EMail: csp@csperkins.org 2102 Intellectual Property Statement 2104 The IETF takes no position regarding the validity or scope of any 2105 Intellectual Property Rights or other rights that might be claimed to 2106 pertain to the implementation or use of the technology described in 2107 this document or the extent to which any license under such rights 2108 might or might not be available; nor does it represent that it has 2109 made any independent effort to identify any such rights. Information 2110 on the procedures with respect to rights in RFC documents can be 2111 found in BCP 78 and BCP 79. 2113 Copies of IPR disclosures made to the IETF Secretariat and any 2114 assurances of licenses to be made available, or the result of an 2115 attempt made to obtain a general license or permission for the use of 2116 such proprietary rights by implementers or users of this 2117 specification can be obtained from the IETF on-line IPR repository at 2118 http://www.ietf.org/ipr. 2120 The IETF invites any interested party to bring to its attention any 2121 copyrights, patents or patent applications, or other proprietary 2122 rights that may cover technology that may be required to implement 2123 this standard. Please address the information to the IETF at 2124 ietf-ipr@ietf.org. 2126 Disclaimer of Validity 2128 This document and the information contained herein are provided on an 2129 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2130 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2131 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2132 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2133 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2134 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2136 Copyright Statement 2138 Copyright (C) The Internet Society (2004). This document is subject 2139 to the rights, licenses and restrictions contained in BCP 78, and 2140 except as set forth therein, the authors retain all their rights. 2142 Acknowledgment 2144 Funding for the RFC Editor function is currently provided by the 2145 Internet Society.