idnits 2.17.1 draft-ietf-mmusic-sdp-new-16.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 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2083. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2067. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2073. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 2089), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 3 instances of lines with control characters in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 12 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 -- The draft header indicates that this document obsoletes RFC3266, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC2327, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 540 has weird spacing: '...7 or p=+...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 4, 2004) is 7290 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2234 (ref. '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 3066 (ref. '6') (Obsoleted by RFC 4646, RFC 4647) -- Obsolete informational reference (is this intentional?): RFC 1305 (ref. '7') (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '10') (Obsoleted by RFC 7826) == Outdated reference: A later version (-15) exists of draft-ietf-mmusic-kmgmt-ext-09 == Outdated reference: A later version (-12) exists of draft-ietf-mmusic-sdescriptions-02 Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 10 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: November 2, 2004 C. Perkins 7 University of Glasgow 8 May 4, 2004 10 SDP: Session Description Protocol 11 draft-ietf-mmusic-sdp-new-16.txt 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at http:// 30 www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on November 2, 2004. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 This memo defines the Session Description Protocol (SDP). SDP is 44 intended for describing multimedia sessions for the purposes of 45 session announcement, session invitation, and other forms of 46 multimedia session initiation. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . 3 52 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . 3 53 3.1 Multicast Session Announcement . . . . . . . . . . . . . . 3 54 3.2 Session Initiation . . . . . . . . . . . . . . . . . . . . 4 55 3.3 Streaming media . . . . . . . . . . . . . . . . . . . . . 4 56 3.4 Email and the World Wide Web . . . . . . . . . . . . . . . 4 57 4. Requirements and Recommendations . . . . . . . . . . . . . . 5 58 4.1 Media Information . . . . . . . . . . . . . . . . . . . . 5 59 4.2 Timing Information . . . . . . . . . . . . . . . . . . . . 6 60 4.3 Private Sessions . . . . . . . . . . . . . . . . . . . . . 6 61 4.4 Obtaining Further Information about a Session . . . . . . 6 62 4.5 Categorisation . . . . . . . . . . . . . . . . . . . . . . 6 63 4.6 Internationalization . . . . . . . . . . . . . . . . . . . 7 64 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . 7 65 5.1 Protocol Version ("v=") . . . . . . . . . . . . . . . . . 9 66 5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 10 67 5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . . 11 68 5.4 Session Information ("i=") . . . . . . . . . . . . . . . . 11 69 5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 11 70 5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . 11 71 5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . 12 72 5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 14 73 5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 15 74 5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . 16 75 5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . 17 76 5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 18 77 5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . 19 78 5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . . 21 79 6. Suggested Attributes . . . . . . . . . . . . . . . . . . . . 24 80 7. Communicating Conference Control Policy . . . . . . . . . . 29 81 8. Security Considerations . . . . . . . . . . . . . . . . . . 30 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31 83 9.1 The "application/sdp" media type . . . . . . . . . . . . . 31 84 9.2 Registration of Parameters . . . . . . . . . . . . . . . . 32 85 9.3 Encryption Key Access Methods . . . . . . . . . . . . . . 36 86 A. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 37 87 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 42 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 89 10.1 Normative References . . . . . . . . . . . . . . . . . . . 42 90 10.2 Informative References . . . . . . . . . . . . . . . . . . 42 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 43 92 Intellectual Property and Copyright Statements . . . . . . . 45 94 1. Introduction 96 [Note to RFC Editor: All references to RFC XXXX should be replaced by 97 the RFC number of this document, when published.] 99 When initiating multimedia teleconferences, voice-over-IP calls, 100 streaming video, or other sessions, there is a requirement to convey 101 media details, transport addresses, and other session description 102 metadata to the participants. 104 SDP provides a standard representation for such information, 105 irrespective of how that information is transported. SDP is purely a 106 format for session description - it does not incorporate a transport 107 protocol, and is intended to use different transport protocols as 108 appropriate, including the Session Announcement Protocol [8], Session 109 Initiation Protocol [9], Real-Time Streaming Protocol [10], 110 electronic mail using the MIME extensions, and the Hypertext 111 Transport Protocol. 113 SDP is intended to be general purpose so that it can be used in a 114 wide range of network environments and applications. However, it is 115 not intended to support negotiation of session content or media 116 encodings: this is viewed as outside the scope of session 117 description. 119 2. Glossary of Terms 121 The following terms are used in this document, and have specific 122 meaning within the context of this document. 124 Conference: A multimedia conference is a set of two or more 125 communicating users along with the software they are using to 126 communicate. 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. 130 Session Description: A well defined format for conveying sufficient 131 information to discover and participate in a multimedia session. 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [1]. 137 3. Examples of SDP Usage 139 3.1 Multicast Session Announcement 141 In order to assist the advertisement of multicast multimedia 142 conferences and other multicast sessions, and to communicate the 143 relevant session setup information to prospective participants, a 144 distributed session directory may be used. An instance of such a 145 session directory periodically sends packets containing a description 146 of the session to a well known multicast group. These advertisements 147 are received by other session directories such that potential remote 148 participants can use the session description to start the tools 149 required to participate in the session. 151 One protocol commonly used to implement such a distributed directory 152 is the Session Announcement Protocol, SAP [8]. SDP provides the 153 recommended session description format for such session 154 announcements. 156 3.2 Session Initiation 158 The Session Initiation Protocol, SIP [9] is an application layer 159 control protocol for creating, modifying and terminating sessions 160 such as Internet multimedia conferences, Internet telephone calls and 161 multimedia distribution. The SIP messages used to create sessions 162 carry session descriptions which allow participants to agree on a set 163 of compatible media types. These session descriptions are commonly 164 formatted using SDP. When used with SIP, the offer/answer model [11] 165 provides a limited framework for negotiation using SDP. 167 3.3 Streaming media 169 The Real Time Streaming Protocol, RTSP [10], is an application-level 170 protocol for control over the delivery of data with real-time 171 properties. RTSP provides an extensible framework to enable 172 controlled, on-demand delivery of real-time data, such as audio and 173 video. An RTSP client and server negotiate an appropriate set of 174 parameters for media delivery, partially using SDP syntax to describe 175 those parameters. 177 3.4 Email and the World Wide Web 179 Alternative means of conveying session descriptions include 180 electronic mail and the World Wide Web. For both email and WWW 181 distribution, the MIME content type "application/sdp" is used. This 182 enables the automatic launching of applications for participation in 183 the session from the WWW client or mail reader in a standard manner. 185 Note that announcements of multicast sessions made only via email or 186 the World Wide Web (WWW) do not have the property that the receiver 187 of a session announcement can necessarily receive the session because 188 the multicast sessions may be restricted in scope, and access to the 189 WWW server or reception of email is possible outside this scope. 191 Session announcements made using SAP do not suffer from this 192 mismatch. 194 4. Requirements and Recommendations 196 The purpose of SDP is to convey information about media streams in 197 multimedia sessions to allow the recipients of a session description 198 to participate in the session. SDP is primarily intended for use in 199 an internetwork, although it is sufficiently general that it can 200 describe conferences in other network environments. Media streams can 201 be many-to-many. The times during which the session is active need 202 not be continuous. 204 Thus far, multicast based sessions on the Internet have differed from 205 many other forms of conferencing in that anyone receiving the traffic 206 can join the session (unless the session traffic is encrypted). In 207 such an environment, SDP serves two primary purposes. It is a means 208 to communicate the existence of a session, and is a means to convey 209 sufficient information to enable joining and participating in the 210 session. In a unicast environment, only the latter purpose is likely 211 to be relevant. 213 Thus SDP includes: 214 o Session name and purpose 215 o Time(s) the session is active 216 o The media comprising the session 217 o Information needed to receive those media (addresses, ports, 218 formats and so on) 219 As resources necessary to participate in a session may be limited, 220 some additional information may also be desirable: 221 o Information about the bandwidth to be used by the conference 222 o Contact information for the person responsible for the session 223 In general, SDP must convey sufficient information to enable 224 applications to join a session (with the possible exception of 225 encryption keys) and to announce the resources to be used to non- 226 participants that may need to know. 228 4.1 Media Information 230 SDP includes: 231 o The type of media (video, audio, etc) 232 o The transport protocol (RTP/UDP/IP, H.320, etc) 233 o The format of the media (H.261 video, MPEG video, etc) 235 For an IP multicast session, the following are also conveyed: 236 o Multicast address for media 237 o Transport port for media 238 This address and port are the destination address and destination 239 port of the multicast stream, whether being sent, received, or both. 241 For an IP unicast session, the following are conveyed: 242 o Remote address for media 243 o Transport port for media 244 The semantics of this address and port depend on the media and 245 transport protocol defined. By default, this is the remote address 246 and remote port to which data is sent, however some media types may 247 redefine this behaviour. 249 4.2 Timing Information 251 Sessions may either be bounded or unbounded in time. Whether or not 252 they are bounded, they may be only active at specific times. 254 SDP can convey: 255 o An arbitrary list of start and stop times bounding the session 256 o For each bound, repeat times such as "every Wednesday at 10am for 257 one hour" 258 This timing information is globally consistent, irrespective of local 259 time zone or daylight saving time. 261 4.3 Private Sessions 263 It is possible to create both public sessions and private sessions. 264 SDP itself does not distinguish between these: private sessions are 265 typically conveyed by encrypting the session description during 266 distribution. The details of how encryption is performed are 267 dependent on the mechanism used to convey SDP - e.g. mechanisms are 268 defined for SDP transported using SAP [8] and SIP [9]. 270 If a session announcement is private it is possible to use that 271 private announcement to convey encryption keys necessary to decode 272 each of the media in a conference, including enough information to 273 know which encryption scheme is used for each media. 275 4.4 Obtaining Further Information about a Session 277 A session description should convey enough information to decide 278 whether or not to participate in a session. SDP may include 279 additional pointers in the form of Universal Resources Identifiers 280 (URIs) for more information about the session. 282 4.5 Categorisation 284 When many session descriptions are being distributed by SAP, or any 285 other advertisement mechanism, it may be desirable to filter session 286 announcements that are of interest from those that are not. SDP 287 supports a categorisation mechanism for sessions that is capable of 288 being automated. 290 4.6 Internationalization 292 The SDP specification recommends the use of the ISO 10646 character 293 sets in the UTF-8 encoding [3] to allow many different languages to 294 be represented. However, to assist in compact representations, SDP 295 also allows other character sets such as ISO 8859-1 to be used when 296 desired. Internationalization only applies to free-text fields 297 (session name and background information), and not to SDP as a whole. 299 5. SDP Specification 301 An SDP session description is denoted by the MIME content type 302 "application/sdp" (See Section 9). 304 An SDP session description is entirely textual using the ISO 10646 305 character set in UTF-8 encoding. SDP field names and attribute names 306 use only the US-ASCII subset of UTF-8, but textual fields and 307 attribute values MAY use the full ISO 10646 character set. Field and 308 attribute values which use the full UTF-8 character set are never 309 directly compared, hence there is no requirement for UTF-8 310 normalization. The textual form, as opposed to a binary encoding 311 such as ASN.1 or XDR, was chosen to enhance portability, to enable a 312 variety of transports to be used (e.g, session description in a MIME 313 email message) and to allow flexible, text-based toolkits (e.g., Tcl/ 314 Tk) to be used to generate and to process session descriptions. 315 However, since SDP may be used in environments where the maximum 316 permissable size of a session description is limited (e.g. SAP 317 announcements), the encoding is deliberately compact. Also, since 318 announcements may be transported via very unreliable means or damaged 319 by an intermediate caching server, the encoding was designed with 320 strict order and formatting rules so that most errors would result in 321 malformed session announcements which could be detected easily and 322 discarded. This also allows rapid discarding of encrypted session 323 announcements for which a receiver does not have the correct key. 325 An SDP session description consists of a number of lines of text of 326 the form: 328 = 330 where MUST be exactly one case-significant character and 331 is structured text whose format depends on . In 332 general is either a number of fields delimited by a single 333 space character, or a free format string. Whitespace MUST NOT be used 334 either side of the "=" sign. 336 An SDP session description consists of a session-level section 337 followed by zero or more media-level sections. The session-level 338 part starts with a "v=" line and continues to the first media-level 339 section. The media description starts with an "m=" line and 340 continues to the next media description or end of the whole session 341 description. In general, session-level values are the default for 342 all media unless overridden by an equivalent media-level value. 344 Some lines in each description are REQUIRED and some are OPTIONAL but 345 all MUST appear in exactly the order given here (the fixed order 346 greatly enhances error detection and allows for a simple parser). 347 OPTIONAL items are marked with a "*". 349 Session description 350 v= (protocol version) 351 o= (owner/creator and session identifier). 352 s= (session name) 353 i=* (session information) 354 u=* (URI of description) 355 e=* (email address) 356 p=* (phone number) 357 c=* (connection information - not required if included in 358 all media) 359 b=* (zero or more bandwidth information lines) 360 One or more time descriptions (see below) 361 z=* (time zone adjustments) 362 k=* (encryption key) 363 a=* (zero or more session attribute lines) 364 Zero or more media descriptions (see below) 366 Time description 367 t= (time the session is active) 368 r=* (zero or more repeat times) 370 Media description 371 m= (media name and transport address) 372 i=* (media title) 373 c=* (connection information - optional if included at 374 session-level) 375 b=* (zero or more bandwidth information lines) 376 k=* (encryption key) 377 a=* (zero or more media attribute lines) 379 The set of type letters is deliberately small and not intended to be 380 extensible -- an SDP parser MUST completely ignore any session 381 description that contains a type letter that it does not understand. 382 The attribute mechanism ("a=" described below) is the primary means 383 for extending SDP and tailoring it to particular applications or 384 media. Some attributes (the ones listed in Section 6 of this memo) 385 have a defined meaning, but others may be added on an application-, 386 media- or session-specific basis. An SDP parser MUST ignore any 387 attribute it doesn't understand. 389 An SDP session description may contain URIs which reference external 390 content in the "u=", "k=" and "a=" lines. These URIs may be 391 dereferenced in some cases, making the session description non-self 392 contained. 394 The connection ("c=") and attribute ("a=") information in the 395 session-level section applies to all the media of that session unless 396 overridden by connection information or an attribute of the same name 397 in the media description. For instance, in the example below, each 398 media behaves as if it were given a "recvonly" attribute. 400 An example SDP description is: 402 v=0 403 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 404 s=SDP Seminar 405 i=A Seminar on the session description protocol 406 u=http://www.example.com/seminars/sdp.pdf 407 e=j.doe@example.com (Jane Doe) 408 c=IN IP4 224.2.17.12/127 409 t=2873397496 2873404696 410 a=recvonly 411 m=audio 49170 RTP/AVP 0 412 m=video 51372 RTP/AVP 31 413 m=application 32416 udp wb 414 a=orient:portrait 416 Text fields such as the session name and information are octet 417 strings which may contain any octet with the exceptions of 0x00 418 (Nul), 0x0a (ASCII newline) and 0x0d (ASCII carriage return). The 419 sequence CRLF (0x0d0a) is used to end a record, although parsers 420 SHOULD be tolerant and also accept records terminated with a single 421 newline character. If the "a=charset" attribute is not present, 422 these octet strings MUST be interpreted as containing ISO-10646 423 characters in UTF-8 encoding (the presence of the "a=charset" 424 attribute MAY force some fields to be interpreted differently). 426 5.1 Protocol Version ("v=") 428 v=0 430 The "v=" field gives the version of the Session Description Protocol. 431 This memo defines version 0. There is no minor version number. 433 5.2 Origin ("o=") 435 o= 436 438 The "o=" field gives the originator of the session (her username and 439 the address of the user's host) plus a session identifier and version 440 number: 442 is the user's login on the originating host, or it is "-" 443 if the originating host does not support the concept of user ids. 444 The MUST NOT contain spaces. 445 is a numeric string such that the tuple of , 446 , , and form a 447 globally unique identifier for the session. The method of 448 allocation is up to the creating tool, but it has been 449 suggested that a Network Time Protocol (NTP) format timestamp be 450 used to ensure uniqueness [7]. 451 is a version number for this session description. Its 452 usage is up to the creating tool, so long as is 453 increased when a modification is made to the session data. Again, 454 it is RECOMMENDED that an NTP format timestamp is used. 455 is a text string giving the type of network. Initially "IN" 456 is defined to have the meaning "Internet", but other values MAY be 457 registered in future (see Section 9). 458 is a text string giving the type of the address that 459 follows. Initially "IP4" and "IP6" are defined, but other values 460 MAY be registered in future (see Section 9). 461 is the address of the machine from which the 462 session was created. For an address type of IP4, this is either 463 the fully-qualified domain name of the machine, or the 464 dotted-decimal representation of the IP version 4 address of the 465 machine. For an address type of IP6, this is either the 466 fully-qualified domain name of the machine, or the compressed 467 textual representation of the IP version 6 address of the machine. 468 For both IP4 and IP6, the fully-qualified domain name is the form 469 that SHOULD be given unless this is unavailable, in which case the 470 globally unique address MAY be substituted. A local IP address 471 MUST NOT be used in any context where the SDP description might 472 leave the scope in which the address is meaningful. 474 In general, the "o=" field serves as a globally unique identifier for 475 this version of this session description, and the subfields excepting 476 the version taken together identify the session irrespective of any 477 modifications. 479 5.3 Session Name ("s=") 481 s= 483 The "s=" field is the textual session name. There MUST be one and 484 only one "s=" field per session description. The "s=" field MUST NOT 485 be empty and SHOULD contain ISO 10646 characters (but see also the 486 "a=charset" attribute). If a session has no meaningful name, the 487 value "s= " SHOULD be used (i.e. a single space as the session name). 489 5.4 Session Information ("i=") 491 i= 493 The "i=" field provides textual information about the session. There 494 may be at most one session-level "i=" field per session description, 495 and at most one "i=" field per media. If the "a=charset" attribute is 496 present, it specifies the character set used in the "i=" field. If 497 the "a=charset" attribute is not present, the "i=" field MUST contain 498 ISO 10646 characters in UTF-8 encoding. 500 A single "i=" field MAY also be used for each media definition. In 501 media definitions, "i=" fields are primarily intended for labeling 502 media streams. As such, they are most likely to be useful when a 503 single session has more than one distinct media stream of the same 504 media type. An example would be two different whiteboards, one for 505 slides and one for feedback and questions. 507 5.5 URI ("u=") 509 u= 511 A URI is a Universal Resource Identifier as used by WWW clients [4]. 512 The URI should be a pointer to additional information about the 513 conference. This field is OPTIONAL, but if it is present it MUST be 514 specified before the first media field. No more than one URI field is 515 allowed per session description. 517 5.6 Email Address and Phone Number ("e=" and "p=") 519 e= 520 p= 522 The "e=" and "p=" lines specify contact information for the person 523 responsible for the conference. This is not necessarily the same 524 person that created the conference announcement. 526 Inclusion of an email address or phone number is OPTIONAL. Note that 527 the previous version of SDP specified that either an email field or a 528 phone field MUST be specified, but this was widely ignored. The 529 change brings the specification into line with common usage. 531 If the email addres or phone number are present, they MUST be 532 specified before the first media field. More than one email or phone 533 field can be given for a session description. 535 Phone numbers SHOULD be given in the form of an international public 536 telecommunication number (see ITU-T Recommendation E.164) preceded by 537 a "+". Spaces and hyphens may be used to split up a phone field to 538 aid readability if desired. For example: 540 p=+44-171-380-7777 or p=+1 617 555 6011 542 Both email addresses and phone numbers can have an OPTIONAL free text 543 string associated with them, normally giving the name of the person 544 who may be contacted. This MUST be enclosed in parenthesis if it is 545 present. For example: 547 e=j.doe@example.com (Jane Doe) 549 The alternative RFC 2822 name quoting convention is also allowed for 550 both email addresses and phone numbers. For example: 552 e=Jane Doe 554 The free text string SHOULD be in the ISO-10646 character set with 555 UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if 556 the appropriate session-level "a=charset" attribute is set. 558 5.7 Connection Data ("c=") 560 c= 562 The "c=" field contains connection data. 564 A session description MUST contain either at least one "c=" field in 565 each media description or a single "c=" field at the session level. 566 It MAY contain a single session-level "c=" field and additional "c=" 567 field(s) per media description, in which case the per-media values 568 override the session-level settings for the respective media. 570 The first sub-field ("") is the network type, which is a 571 text string giving the type of network. Initially "IN" is defined to 572 have the meaning "Internet", but other values MAY be registered in 573 the future (see Section 9). 575 The second sub-field ("") is the address type. This allows 576 SDP to be used for sessions that are not IP based. Currently only IP4 577 and IP6 are defined, but other values MAY be registered in the future 578 (see Section 9). 580 The third sub-field ("") is the connection 581 address. OPTIONAL sub-fields MAY be added after the connection 582 address depending on the value of the field. 584 When the is IP4 and IP6, the connection address is defined 585 as follows: 587 o If the session is multicast, the connection address will be an IP 588 multicast group address. If the session is not multicast, then 589 the connection address contains the unicast IP address of the 590 expected data source or data relay or data sink as determined by 591 additional attribute fields. It is not expected that unicast 592 addresses will be given in a session description that is 593 communicated by a multicast announcement, though this is not 594 prohibited. 595 o Conferences using an IPv4 multicast connection address MUST also 596 have a time to live (TTL) value present in addition to the 597 multicast address. The TTL and the address together define the 598 scope with which multicast packets sent in this conference will be 599 sent. TTL values MUST be in the range 0-255. 601 The TTL for the session is appended to the address using a slash as a 602 separator. An example is: 604 c=IN IP4 224.2.36.42/127 606 IPv6 multicast does not use TTL scoping, and hence the TTL value MUST 607 NOT be present for IPv6 multicast. It is expected that IPv6 scoped 608 addresses will be used to limit the scope of conferences. 610 Hierarchical or layered encoding schemes are data streams where the 611 encoding from a single media source is split into a number of layers. 612 The receiver can choose the desired quality (and hence bandwidth) by 613 only subscribing to a subset of these layers. Such layered encodings 614 are normally transmitted in multiple multicast groups to allow 615 multicast pruning. This technique keeps unwanted traffic from sites 616 only requiring certain levels of the hierarchy. For applications 617 requiring multiple multicast groups, we allow the following notation 618 to be used for the connection address: 620 [/]/ 622 If the number of addresses is not given it is assumed to be one. 624 Multicast addresses so assigned are contiguously allocated above the 625 base address, so that, for example: 627 c=IN IP4 224.2.1.1/127/3 629 would state that addresses 224.2.1.1, 224.2.1.2 and 224.2.1.3 are to 630 be used at a TTL of 127. This is semantically identical to including 631 multiple "c=" lines in a media description: 633 c=IN IP4 224.2.1.1/127 634 c=IN IP4 224.2.1.2/127 635 c=IN IP4 224.2.1.3/127 637 Similarly, an IPv6 example would be: 639 c=IN IP6 FF15::101/3 641 which is semantically equivalent to: 643 c=IN IP6 FF15::101 644 c=IN IP6 FF15::102 645 c=IN IP6 FF15::103 647 (remembering that the TTL field is not present in IPv6 multicast). 649 Multiple addresses or "c=" lines MAY be specified on a per-media 650 basis only if they provide multicast addresses for different layers 651 in a hierarchical or layered encoding scheme. They MUST NOT be 652 specified for a session-level "c=" field. 654 The slash notation described above MUST NOT be used for IP unicast 655 addresses. 657 5.8 Bandwidth ("b=") 659 b=: 661 This OPTIONAL field denotes the proposed bandwidth to be used by the 662 session or media. The is an alphanumeric modifier giving 663 the meaning of the figure. Two values are initially 664 defined, but other values MAY be registered in future (see Section 665 9): 667 CT If the bandwidth of a session or media in a session is different 668 from the bandwidth implicit from the scope, a "b=CT:..." line 669 SHOULD be supplied for the session giving the proposed upper limit 670 to the bandwidth used. The primary purpose of this is to give an 671 approximate idea as to whether two or more sessions can co-exist 672 simultaneously. When using the CT modifier with RTP, if several 673 RTP sessions are part of the conference, the conference total 674 refers to total bandwidth of all RTP sessions. 675 AS The bandwidth is interpreted to be application-specific (it will 676 be the application's concept of maximum bandwidth). Normally this 677 will coincide with what is set on the application's "maximum 678 bandwidth" control if applicable. For RTP based applications, AS 679 gives the RTP "session bandwidth" as defined in section 6.2 of 680 [12]. 682 Note that CT gives a total bandwidth figure for all the media at all 683 sites. AS gives a bandwidth figure for a single media at a single 684 site, although there may be many sites sending simultaneously. 686 A prefix "X-" is defined for names. This is intended for 687 experimental purposes only. For example: 689 b=X-YZ:128 691 Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers 692 SHOULD be registered with IANA in the standard namespace. SDP parsers 693 MUST ignore bandwidth fields with unknown modifiers. Modifiers MUST 694 be alpha-numeric and, although no length limit is given, they are 695 recommended to be short. 697 The is in kilobits per second by default. Modifiers MAY 698 specify that alternative units are to be used (the modifiers defined 699 in this memo use the default units). 701 5.9 Timing ("t=") 703 t= 705 The "t=" lines specify the start and stop times for a session. 706 Multiple "t=" lines MAY be used if a session is active at multiple 707 irregularly spaced times; each additional "t=" lines specifies an 708 additional period of time for which the session will be active. If 709 the session is active at regular times, an "r=" line (see below) 710 should be used in addition to, and following, a "t=" line - in which 711 case the "t=" line specifies the start and stop times of the repeat 712 sequence. 714 The first and second sub-fields give the start and stop times for the 715 session respectively. These values are the decimal representation of 716 Network Time Protocol (NTP) time values in seconds [7]. To convert 717 these values to UNIX time, subtract decimal 2208988800. 719 NTP timestamps are 64 bit values which wrap sometime in the year 720 2036. Since SDP uses an arbitrary length decimal representation, 721 this should not cause an issue (SDP timestamps will continue counting 722 seconds since 1900, NTP will use the value modulo the 64 bit limit). 724 If the is set to zero, then the session is not bounded, 725 though it will not become active until after the . If 726 the is also zero, the session is regarded as permanent. 728 User interfaces SHOULD strongly discourage the creation of unbounded 729 and permanent sessions as they give no information about when the 730 session is actually going to terminate, and so make scheduling 731 difficult. 733 The general assumption may be made, when displaying unbounded 734 sessions that have not timed out to the user, that an unbounded 735 session will only be active until half an hour from the current time 736 or the session start time, whichever is the later. If behaviour 737 other than this is required, an end-time should be given and modified 738 as appropriate when new information becomes available about when the 739 session should really end. 741 Permanent sessions may be shown to the user as never being active 742 unless there are associated repeat times which state precisely when 743 the session will be active. In general, permanent sessions SHOULD 744 NOT be created for any session expected to have a duration of less 745 than 2 months, and should be discouraged for sessions expected to 746 have a duration of less than 6 months. 748 5.10 Repeat Times ("r=") 750 r= 752 "r=" fields specify repeat times for a session. For example, if a 753 session is active at 10am on Monday and 11am on Tuesday for one hour 754 each week for three months, then the in the 755 corresponding "t=" field would be the NTP representation of 10am on 756 the first Monday, the would be 1 week, the would be 1 hour, and the offsets would be zero and 25 758 hours. The corresponding "t=" field stop time would be the NTP 759 representation of the end of the last session three months later. By 760 default all fields are in seconds, so the "r=" and "t=" fields might 761 be: 763 t=3034423619 3042462419 764 r=604800 3600 0 90000 766 To make description more compact, times may also be given in units of 767 days, hours or minutes. The syntax for these is a number immediately 768 followed by a single case-sensitive character. Fractional units are 769 not allowed - a smaller unit should be used instead. The following 770 unit specification characters are allowed: 772 d - days (86400 seconds) 773 h - hours (3600 seconds) 774 m - minutes (60 seconds) 775 s - seconds (allowed for completeness but not recommended) 777 Thus, the above session announcement could also have been written: 779 r=7d 1h 0 25h 781 Monthly and yearly repeats cannot be directly specified with a single 782 SDP repeat time - instead separate "t=" fields should be used to 783 explicitly list the session times. 785 5.11 Time Zones ("z=") 787 z= .... 789 To schedule a repeated session which spans a change from daylight- 790 saving time to standard time or vice-versa, it is necessary to 791 specify offsets from the base time. This is required because 792 different time zones change time at different times of day, different 793 countries change to or from daylight time on different dates, and 794 some countries do not have daylight saving time at all. 796 Thus in order to schedule a session that is at the same time winter 797 and summer, it must be possible to specify unambiguously by whose 798 time zone a session is scheduled. To simplify this task for 799 receivers, we allow the sender to specify the NTP time that a time 800 zone adjustment happens and the offset from the time when the session 801 was first scheduled. The "z=" field allows the sender to specify a 802 list of these adjustment times and offsets from the base time. 804 An example might be: 806 z=2882844526 -1h 2898848070 0 808 This specifies that at time 2882844526 the time base by which the 809 session's repeat times are calculated is shifted back by 1 hour, and 810 that at time 2898848070 the session's original time base is restored. 811 Adjustments are always relative to the specified start time - they 812 are not cumulative. Adjustments apply to all "t=" and "r=" lines in 813 a session description. 815 If a session is likely to last several years, it is expected that the 816 session announcement will be modified periodically rather than 817 transmit several years worth of adjustments in one session 818 announcement. 820 5.12 Encryption Keys ("k=") 822 k= 823 k=: 825 If transported over a secure and trusted channel, the session 826 description protocol MAY be used to convey encryption keys. A simple 827 mechanism for key exchange is provided by the key field ("k=") 828 although this is primarily supported for compatibility with older 829 implementations and its use is NOT RECOMMENDED. Work is in progress 830 to define new key exchange mechanisms for use with SDP [17][16] and 831 it is expected that new applications will use those mechanisms. 833 A key field is permitted before the first media entry (in which case 834 it applies to all media in the session), or for each media entry as 835 required. The format of keys and their usage is outside the scope of 836 this document, and the key field provides no way to indicate the 837 encryption algorithm to be used, key type, or other information about 838 the key: this is assumed to be provided by the higher-level protocol 839 using SDP. If there is a need to convey this information within SDP, 840 the extensions mentioned previously SHOULD be used. Many security 841 protocols require two keys, one for confidentiality and another for 842 integrity. This specification does not support the transfer of two 843 keys. 845 The method indicates the mechanism to be used to obtain a usable key 846 by external means, or from the encoded encryption key given. The 847 following methods are defined: 849 k=clear: 851 The encryption key is included untransformed in this key field. 852 This method MUST NOT be used unless it can be guaranteed that 853 the SDP is conveyed over a secure channel. 855 k=base64: 857 The encryption key is included in this key field but has been 858 base64 encoded because it includes characters that are 859 prohibited in SDP. This method MUST NOT be used unless it can 860 be guaranteed that the SDP is conveyed over a secure channel. 862 k=uri: 864 A Universal Resource Identifier is included in the key field. 865 The URI refers to the data containing the key, and may require 866 additional authentication before the key can be returned. When 867 a request is made to the given URI, the reply should specify 868 the encoding for the key. The URI is often a secure HTTP URI, 869 although this is not required. 871 k=prompt 873 No key is included in this SDP description, but the session or 874 media stream referred to by this key field is encrypted. The 875 user should be prompted for the key when attempting to join the 876 session, and this user-supplied key should then be used to 877 decrypt the media streams. The use of user-specified keys is 878 NOT RECOMMENDED, since such keys tend to have weak security 879 properties. 881 The key field MUST NOT be used unless it can be guaranteed that the 882 SDP is conveyed over a secure and trusted channel. An example of such 883 a channel might be SDP embedded inside an S/MIME message or a TLS 884 protected HTTP or SIP session. It is important to ensure that the 885 secure channel is with the party that is authorized to join the 886 session, not an intermediary: if a caching proxy server is used, it 887 is important to ensure that the proxy is either trusted or unable to 888 access the SDP. Definition of appropriate security measures is beyond 889 the scope of this specification, and should be defined by the users 890 of SDP. 892 5.13 Attributes ("a=") 894 a= 895 a=: 897 Attributes are the primary means for extending SDP. Attributes may 898 be defined to be used as "session-level" attributes, "media-level" 899 attributes, or both. 901 A media description may have any number of attributes ("a=" fields) 902 which are media specific. These are referred to as "media-level" 903 attributes and add information about the media stream. Attribute 904 fields can also be added before the first media field; these 905 "session-level" attributes convey additional information that applies 906 to the conference as a whole rather than to individual media; an 907 example might be the conference's floor control policy. 909 Attribute fields may be of two forms: 911 o property attributes: 912 A property attribute is simply of the form "a=". 913 These are binary attributes, and the presence of the 914 attribute conveys that the attribute is a property of 915 the session. An example might be "a=recvonly". 917 o value attributes: 918 A value attribute is of the form "a=:". 919 For example, a whiteboard could have the value attribute 920 "a=orient:landscape" 922 Attribute interpretation depends on the media tool being invoked. 923 Thus receivers of session descriptions should be configurable in 924 their interpretation of session descriptions in general and of 925 attributes in particular. 927 Attribute names MUST be in the US-ASCII subset of ISO-10646/UTF-8. 929 Attribute values are octet strings, and MAY use any octet value 930 except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute 931 values are to be interpreted as in ISO-10646 character set with UTF-8 932 encoding. Unlike other text fields, attribute values are NOT 933 normally affected by the "charset" attribute as this would make 934 comparisons against known values problematic. However, when an 935 attribute is defined, it can be defined to be charset-dependent, in 936 which case it's value should be interpreted in the session charset 937 rather than in ISO-10646. 939 Attributes MUST be registered with IANA (see Section 9). If an 940 attribute is received that is not understood, it MUST be ignored by 941 the receiver. 943 5.14 Media Descriptions ("m=") 945 m= 947 A session description may contain a number of media descriptions. 948 Each media description starts with an "m=" field, and is terminated 949 by either the next "m=" field or by the end of the session 950 description. A media field has several sub-fields. 952 The first sub-field ("") is the media type. Currently defined 953 media are "audio", "video", "text", "application", "data" and 954 "control", though this list may be extended in future. The 955 difference between "application" and "data" is that the former is a 956 media flow such as whiteboard information, and the latter is 957 bulk-data transfer such as multicasting of program executables which 958 will not typically be displayed to the user. "control" is used to 959 specify an additional conference control channel for the session. 961 The second sub-field ("") is the transport port to which the 962 media stream is sent. The meaning of the transport port depends on 963 the network being used as specified in the relevant "c=" field, and 964 on the transport protocol defined in the third sub-field. Other 965 ports used by the media application (such as the RTCP port [12]) MAY 966 be derived algorithmically from the base media port or MAY be 967 specified in a separate attribute (e.g. "a=rtcp:" as defined in 968 [14]). 970 For applications where hierarchically encoded streams are being sent 971 to a unicast address, it may be necessary to specify multiple 972 transport ports. This is done using a similar notation to that used 973 for IP multicast addresses in the "c=" field: 975 m= / 977 In such a case, the ports used depend on the transport protocol. For 978 RTP, the default is that only the even numbered ports are used for 979 data with the corresponding one-higher odd ports used for the RTCP 980 belonging to the RTP session, and the denoting the 981 number of RTP sessions. For example: 983 m=video 49170/2 RTP/AVP 31 985 would specify that ports 49170 and 49171 form one RTP/RTCP pair and 986 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the 987 transport protocol and 31 is the format (see below). If non- 988 contiguous ports are required, they must be signalled using a 989 separate attribute (e.g. "a=rtcp:" as defined in [14]). 991 If multiple addresses are specified in the "c=" field and multiple 992 ports are specified in the "m=" field, a one-to-one mapping from port 993 to the corresponding address is implied. For example: 995 c=IN IP4 224.2.1.1/127/2 996 m=video 49170/2 RTP/AVP 31 998 would imply that address 224.2.1.1 is used with ports 49170 and 999 49171, and address 224.2.1.2 is used with ports 49172 and 49173. 1001 The third sub-field ("") is the transport protocol. The 1002 transport protocol values are dependent on the address type field in 1003 the "c=" fields. Thus a "c=" field of IP4 defines that the transport 1004 protocol runs over IP4. For IP4, it is normally expected that most 1005 media traffic will be carried as RTP over UDP. The following 1006 transport protocols are defined, but may be extended through 1007 registration of new protocols with IANA (see Section 9): 1009 RTP/AVP - the IETF's Realtime Transport Protocol using the 1010 Audio/Video profile carried over UDP. 1011 udp - User Datagram Protocol 1012 TCP - Transmission Control Protocol 1014 If an application uses a single combined proprietary media format and 1015 transport protocol over UDP, then simply specifying the transport 1016 protocol as udp and using the format field to distinguish the 1017 combined protocol is recommended. If a transport protocol is used 1018 over UDP to carry several distinct media types that need to be 1019 distinguished by a session directory, then specifying the transport 1020 protocol and media format separately is necessary. RTP is an example 1021 of a transport-protocol that carries multiple payload formats that 1022 must be distinguished by the session directory for it to know how to 1023 start appropriate tools, relays, mixers or recorders. 1025 The main reason to specify the transport-protocol in addition to the 1026 media format is that the same standard media formats may be carried 1027 over different transport protocols even when the network protocol is 1028 the same - a historical example is vat PCM audio and RTP PCM audio. 1029 In addition, relays and monitoring tools that are 1030 transport-protocol-specific but format-independent are possible. 1032 For RTP media streams operating under the RTP Audio/Video Profile 1033 [13], the protocol field is "RTP/AVP". Should other RTP profiles be 1034 defined in the future, their profiles will be specified in the same 1035 way. For example, the protocol field "RTP/XYZ" would specify RTP 1036 operating under a profile whose short name is "XYZ". 1038 The fourth and subsequent sub-fields ("") are media formats. 1040 For audio, text and video, these SHOULD reference a MIME sub-type 1041 describing the format under the "audio", "text" and "video" top-level 1042 MIME types. 1044 When a list of payload formats is given, this implies that all of 1045 these formats may be used in the session, but the first of these 1046 formats SHOULD be used as the default format for the session. 1048 For media whose transport protocol is not RTP or UDP the format field 1049 is protocol specific. Such formats should be defined in an 1050 additional specification document. 1052 For media whose transport protocol is RTP, SDP can be used to provide 1053 a dynamic binding of media encoding to RTP payload type. The encoding 1054 names in the RTP AV Profile do not specify unique audio encodings (in 1055 terms of clock rate and number of audio channels), and so they are 1056 not used directly in SDP format fields. Instead, the payload type 1057 number should be used to specify the format for static payload types 1058 and the payload type number along with additional encoding 1059 information should be used for dynamically allocated payload types. 1061 An example of a static payload type is u-law PCM coded single channel 1062 audio sampled at 8kHz. This is completely defined in the RTP Audio/ 1063 Video profile as payload type 0, so the media field for such a stream 1064 sent to UDP port 49232 is: 1066 m=audio 49232 RTP/AVP 0 1068 An example of a dynamic payload type is 16 bit linear encoded stereo 1069 audio sampled at 16 kHz. If we wish to use dynamic RTP/AVP payload 1070 type 98 for such a stream, additional information is required to 1071 decode it: 1073 m=audio 49232 RTP/AVP 98 1074 a=rtpmap:98 L16/16000/2 1076 The general form of an rtpmap attribute is: 1078 a=rtpmap: / 1079 [/] 1081 For audio streams, may specify the number of 1082 audio channels. This parameter may be omitted if the number of 1083 channels is one provided no additional parameters are needed. 1085 For video streams, no encoding parameters are currently specified. 1087 Additional parameters may be defined in the future, but codec- 1088 specific parameters SHOULD NOT be added. Parameters added to an 1089 rtpmap attribute SHOULD only be those required for a session 1090 directory to make the choice of appropriate media to participate in a 1091 session. Codec-specific parameters should be added in other 1092 attributes (for example, "a=fmtp:"). 1094 Up to one rtpmap attribute can be defined for each media format 1095 specified. Thus we might have: 1097 m=audio 49230 RTP/AVP 96 97 98 1098 a=rtpmap:96 L8/8000 1099 a=rtpmap:97 L16/8000 1100 a=rtpmap:98 L16/11025/2 1102 RTP profiles that specify the use of dynamic payload types MUST 1103 define the set of valid encoding names and/or a means to register 1104 encoding names if that profile is to be used with SDP. 1106 Note that RTP audio formats typically do not include information 1107 about the number of samples per packet. If a non-default (as defined 1108 in the RTP Audio/Video Profile) packetisation is required, the 1109 "ptime" attribute is used as given below. 1111 For more details on RTP audio and video formats, see [13]. 1113 Predefined application formats for the UDP protocol with non-RTP 1114 media are as below: 1116 wb: LBL Whiteboard (transport: udp) 1117 nt: UCL Network Text Editor (transport: udp) 1119 6. Suggested Attributes 1121 The following attributes are defined. Since application writers may 1122 add new attributes as they are required, this list is not exhaustive. 1124 a=cat: 1126 This attribute gives the dot-separated hierarchical category 1127 of the session. This is to enable a receiver to filter 1128 unwanted sessions by category. It is a session-level 1129 attribute, and is not dependent on charset. 1131 a=keywds: 1133 Like the cat attribute, this is to assist identifying wanted 1134 sessions at the receiver. This allows a receiver to select 1135 interesting session based on keywords describing the purpose 1136 of the session. It is a session-level attribute. It is a 1137 charset dependent attribute, meaning that its value should be 1138 interpreted in the charset specified for the session 1139 description if one is specified, or by default in ISO 1140 10646/UTF-8. 1142 a=tool: 1144 This gives the name and version number of the tool used to 1145 create the session description. It is a session-level 1146 attribute, and is not dependent on charset. 1148 a=ptime: 1150 This gives the length of time in milliseconds represented by 1151 the media in a packet. This is probably only meaningful for 1152 audio data, but may be used with other media types if it makes 1153 sense. It should not be necessary to know ptime to decode RTP 1154 or vat audio, and it is intended as a recommendation for the 1155 encoding/packetisation of audio. It is a media attribute, and 1156 is not dependent on charset. 1158 a=maxptime: 1160 The maximum amount of media which can be encapsulated in each 1161 packet, expressed as time in milliseconds. The time SHALL be 1162 calculated as the sum of the time the media present in the 1163 packet represents. The time SHOULD be a multiple of the frame 1164 size. This attribute is probably only meaningful for audio 1165 data, but may be used with other media types if it makes 1166 sense. It is a media attribute, and is not dependent on 1167 charset. Note that this attribute was introduced after RFC 1168 2327, and non updated implementations will ignore this 1169 attribute. 1171 a=rtpmap: / 1172 [/] 1174 See Section 5.14. This may be a session or media attribute 1175 and is not dependent on charset. 1177 a=recvonly 1179 This specifies that the tools should be started in receive 1180 only mode where applicable. It can be either a session or 1181 media attribute, and is not dependent on charset. Note that 1182 recvonly applies to the media only, not to any associated 1183 control protocol (e.g. an RTP based system in recvonly mode 1184 SHOULD still send RTCP packets). 1186 a=sendrecv 1188 This specifies that the tools should be started in send and 1189 receive mode. This is necessary for interactive conferences 1190 with tools that default to receive only mode. It can be either 1191 a session or media attribute, and is not dependent on charset. 1193 If none of the attributes "sendonly", "recvonly", "inactive", 1194 and "sendrecv" is present, "sendrecv" SHOULD be assumed as the 1195 default for sessions which are not of the conference type 1196 "broadcast" or "H332" (see below). 1198 a=sendonly 1200 This specifies that the tools should be started in send-only 1201 mode. An example may be where a different unicast address is 1202 to be used for a traffic destination than for a traffic 1203 source. In such a case, two media descriptions may be use, 1204 one sendonly and one recvonly. It can be either a session or 1205 media attribute, but would normally only be used as a media 1206 attribute, and is not dependent on charset. Note that sendonly 1207 applies only to the media, and any associated control protocol 1208 (e.g. RTCP) SHOULD still be received and processed as normal. 1210 a=inactive 1212 This specifies that the tools should be started in inactive 1213 mode. This is necessary for interactive conferences where 1214 users can put other users on hold. No media is sent over an 1215 inactive media stream. Note that an RTP based system SHOULD 1216 still send RTCP, even if started inactive. It can be either a 1217 session or media attribute, and is not dependent on charset. 1219 a=orient: 1221 Normally this is only used in a whiteboard media specification. 1222 It specifies the orientation of a the whiteboard on the screen. 1223 It is a media attribute. Permitted values are "portrait", 1224 "landscape" and "seascape" (upside down landscape). It is not 1225 dependent on charset. 1227 a=type: 1229 This specifies the type of the conference. Suggested values 1230 are "broadcast", "meeting", "moderated", "test" and "H332". 1232 "recvonly" should be the default for "type:broadcast" 1233 sessions, "type:meeting" should imply "sendrecv" and 1234 "type:moderated" should indicate the use of a floor control 1235 tool and that the media tools are started so as to mute new 1236 sites joining the conference. 1238 Specifying the attribute "type:H332" indicates that this 1239 loosely coupled session is part of a H.332 session as defined 1240 in the ITU H.332 specification [15]. Media tools should be 1241 started "recvonly". 1243 Specifying the attribute "type:test" is suggested as a hint 1244 that, unless explicitly requested otherwise, receivers can 1245 safely avoid displaying this session description to users. 1247 The type attribute is a session-level attribute, and is not 1248 dependent on charset. 1250 a=charset: 1252 This specifies the character set to be used to display the 1253 session name and information data. By default, the ISO-10646 1254 character set in UTF-8 encoding is used. If a more compact 1255 representation is required, other character sets may be used. 1256 For example, the ISO 8859-1 is specified with the following 1257 SDP attribute: 1259 a=charset:ISO-8859-1 1261 This is a session-level attribute and is not dependent on 1262 charset. The charset specified MUST be one of those registered 1263 with IANA, such as ISO-8859-1. The character set identifier is 1264 a US-ASCII string and MUST be compared against the IANA 1265 identifiers using a case insensitive comparison. If the 1266 identifier is not recognised or not supported, all strings that 1267 are affected by it SHOULD be regarded as octet strings. 1269 Note that a character set specified MUST still prohibit the 1270 use of bytes 0x00 (Nul), 0x0A (LF) and 0x0d (CR). Character 1271 sets requiring the use of these characters MUST define a 1272 quoting mechanism that prevents these bytes appearing within 1273 text fields. 1275 a=sdplang: 1277 This can be a session level attribute or a media level 1278 attribute. As a session level attribute, it specifies the 1279 language for the session description. As a media level 1280 attribute, it specifies the language for any media-level SDP 1281 information field associated with that media. Multiple 1282 sdplang attributes can be provided either at session or media 1283 level if multiple languages in the session description or 1284 media use multiple languages, in which case the order of the 1285 attributes indicates the order of importance of the various 1286 languages in the session or media from most important to least 1287 important. 1289 In general, sending session descriptions consisting of 1290 multiple languages is discouraged. Instead, multiple 1291 descriptions SHOULD be sent describing the session, one in 1292 each language. However this is not possible with all 1293 transport mechanisms, and so multiple sdplang attributes are 1294 allowed although NOT RECOMMENDED. 1296 The "sdplang" attribute value must be a single RFC 3066 1297 language tag in US-ASCII [6]. It is not dependent on 1298 the charset attribute. An "sdplang" attribute SHOULD be 1299 specified when a session is of sufficient scope to cross 1300 geographic boundaries where the language of recipients cannot 1301 be assumed, or where the session is in a different language 1302 from the locally assumed norm. 1304 a=lang: 1306 This can be a session level attribute or a media level 1307 attribute. As a session level attribute, it specifies the 1308 default language for the session being described. As a media 1309 level attribute, it specifies the language for that media, 1310 overriding any session-level language specified. Multiple 1311 lang attributes can be provided either at session or media 1312 level if the session description or media use multiple 1313 languages, in which case the order of the attributes indicates 1314 the order of importance of the various languages in the 1315 session or media from most important to least important. 1317 The "lang" attribute value must be a single RFC 3066 language 1318 tag in US-ASCII [6]. It is not dependent on the charset 1319 attribute. A "lang" attribute SHOULD be specified when a 1320 session is of sufficient scope to cross geographic boundaries 1321 where the language of recipients cannot be assumed, or where 1322 the session is in a different language from the locally 1323 assumed norm. 1325 a=framerate: 1327 This gives the maximum video frame rate in frames/sec. It is 1328 intended as a recommendation for the encoding of video data. 1329 Decimal representations of fractional values using the 1330 notation "." are allowed. It is a 1331 media attribute, defined only for video media, and is not 1332 dependent on charset. 1334 a=quality: 1336 This gives a suggestion for the quality of the encoding as an 1337 integer value. The intention of the quality attribute for 1338 video is to specify a non-default trade-off between frame-rate 1339 and still-image quality. For video, the value in the range 0 1340 to 10, with the following suggested meaning: 1342 10 - the best still-image quality the compression scheme 1343 can give. 1344 5 - the default behaviour given no quality suggestion. 1345 0 - the worst still-image quality the codec designer 1346 thinks is still usable. 1348 It is a media attribute, and is not dependent on charset. 1350 a=fmtp: 1352 This attribute allows parameters that are specific to a 1353 particular format to be conveyed in a way that SDP doesn't 1354 have to understand them. The format must be one of the 1355 formats specified for the media. Format-specific parameters 1356 may be any set of parameters required to be conveyed by SDP 1357 and given unchanged to the media tool that will use this 1358 format. 1360 It is a media attribute, and is not dependent on charset. 1362 7. Communicating Conference Control Policy 1364 There is some debate over the way conference control policy should be 1365 communicated. In general, the authors believe that an implicit 1366 declarative style of specifying conference control is desirable where 1367 possible. 1369 A simple declarative style uses a single conference attribute field 1370 before the first media field, possibly supplemented by properties 1371 such as `recvonly' for some of the media tools. This conference 1372 attribute conveys the conference control policy. An example might 1373 be: 1375 a=type:moderated 1377 In some cases, however, it is possible that this may be insufficient 1378 to communicate the details of an unusual conference control policy. 1379 If this is the case, then a conference attribute specifying external 1380 control might be set, and then one or more "media" fields might be 1381 used to specify the conference control tools and configuration data 1382 for those tools. An example is an ITU H.332 session: 1384 ... 1385 c=IN IP4 224.5.6.7 1386 a=type:H332 1387 m=audio 49230 RTP/AVP 0 1388 m=video 49232 RTP/AVP 31 1389 m=application 12349 udp wb 1390 m=control 49234 H323 mc 1391 c=IN IP4 134.134.157.81 1393 In this example, a general conference attribute (type:H332) is 1394 specified stating that conference control will be provided by an 1395 external H.332 tool, and a contact addresses for the H.323 session 1396 multipoint controller is given. 1398 In this document, only the declarative style of conference control 1399 declaration is specified. Other forms of conference control should 1400 specify an appropriate type attribute, and should define the 1401 implications this has for control media. 1403 8. Security Considerations 1405 SDP is a session description format that describes multimedia 1406 sessions. A session description SHOULD NOT be trusted unless it has 1407 been obtained by an authenticated transport protocol from a trusted 1408 source. Many different transport protocols may be used to distribute 1409 session description, and the nature of the authentication will differ 1410 from transport to transport. 1412 One transport that will frequently be used to distribute session 1413 descriptions is the Session Announcement Protocol (SAP). SAP 1414 provides both encryption and authentication mechanisms but due to the 1415 nature of session announcements it is likely that there are many 1416 occasions where the originator of a session announcement cannot be 1417 authenticated because they are previously unknown to the receiver of 1418 the announcement and because no common public key infrastructure is 1419 available. 1421 On receiving a session description over an unauthenticated transport 1422 mechanism or from an untrusted party, software parsing the session 1423 should take a few precautions. Session descriptions contain 1424 information required to start software on the receivers system. 1425 Software that parses a session description MUST NOT be able to start 1426 other software except that which is specifically configured as 1427 appropriate software to participate in multimedia sessions. It is 1428 normally considered inappropriate for software parsing a session 1429 description to start, on a user's system, software that is 1430 appropriate to participate in multimedia sessions, without the user 1431 first being informed that such software will be started and giving 1432 their consent. Thus a session description arriving by session 1433 announcement, email, session invitation, or WWW page MUST NOT deliver 1434 the user into an interactive multimedia session unless the user has 1435 explicitly pre-authorized such action. As it is not always simple to 1436 tell whether a session is interactive or not, applications that are 1437 unsure should assume sessions are interactive. 1439 In this specification, there are no attributes which would allow the 1440 recipient of a session description to be informed to start multimedia 1441 tools in a mode where they default to transmitting. Under some 1442 circumstances it might be appropriate to define such attributes. If 1443 this is done an application parsing a session description containing 1444 such attributes SHOULD either ignore them, or inform the user that 1445 joining this session will result in the automatic transmission of 1446 multimedia data. The default behaviour for an unknown attribute is 1447 to ignore it. 1449 Session descriptions may be parsed at intermediate systems such as 1450 firewalls for the purposes of opening a hole in the firewall to allow 1451 the participation in multimedia sessions. It is considered 1452 inappropriate for a firewall to open such holes for unicast data 1453 streams unless the session description comes in a request from inside 1454 the firewall. For multicast sessions, it is likely that local 1455 administrators will apply their own policies, but the exclusive use 1456 of "local" or "site-local" administrative scope within the firewall 1457 and the refusal of the firewall to open a hole for such scopes will 1458 provide separation of global multicast sessions from local ones. 1460 Use of the "k=" field poses a significant security risk, since it 1461 conveys session encryption keys in the clear. SDP MUST NOT be used 1462 to convey key material, unless it can be guaranteed that the channel 1463 over which the SDP is delivered is both private and authenticated. 1465 9. IANA Considerations 1467 9.1 The "application/sdp" media type 1469 One new MIME type is to be registered, as defined below. This updates 1470 the previous definition from RFC 2327. 1472 To: ietf-types@iana.org 1473 Subject: Registration of MIME media type application/sdp 1475 MIME media type name: application 1477 MIME subtype name: sdp 1479 Required parameters: None. 1481 Optional parameters: None. 1483 Encoding considerations: 1484 See section 5 of RFC XXXX 1486 Security considerations: 1487 See section 8 of RFC XXXX 1489 Interoperability considerations: 1490 See RFC XXXX 1492 Published specification: 1493 RFC XXXX 1495 Applications which use this media type: 1496 Voice over IP, video teleconferencing, streaming media, instant 1497 messaging, etc. See also section 3 of RFC XXXX. 1499 Additional information: 1501 Magic number(s): None. 1502 File extension(s): The extension ".sdp" is commonly used. 1503 Macintosh File Type Code(s): "sdp " 1505 Person & email address to contact for further information: 1506 Colin Perkins 1507 IETF MMUSIC working group 1509 Intended usage: COMMON 1511 Author/Change controller: 1512 Authors of RFC XXXX 1513 IETF MMUSIC working group 1515 9.2 Registration of Parameters 1517 There are seven field names that may be registered with IANA. Using 1518 the terminology in the SDP specification BNF, they are "media", 1519 "proto", "fmt", "att-field", "bwtype", "nettype" and "addrtype". 1521 9.2.1 Media types ("media") 1523 The set of media types is intended to be small and SHOULD NOT be 1524 extended except under rare circumstances. The same rules should 1525 apply for media names as for top-level MIME content types, and where 1526 possible the same name should be registered for SDP as for MIME. For 1527 media other than existing MIME top-level content types, a 1528 standards-track RFC MUST be produced for a new top-level content type 1529 to be registered, and the registration MUST provide good 1530 justification why no existing media name is appropriate (the 1531 "Standards Action" policy of RFC 2434 [5]. 1533 9.2.2 Transport protocols ("proto") 1535 The "proto" field describes the transport protocol used. This SHOULD 1536 reference a standards-track protocol RFC. This memo registers three 1537 values: "RTP/AVP" is a reference to RTP [12] used under the RTP 1538 Profile for Audio and Video Conferences with Minimal Control [13] 1539 running over UDP/IP; "TCP" denotes an unspecified format over TCP; 1540 and "udp" indicates an unspecified format over UDP. 1542 New transport protocols MAY be registered with IANA. Registrations 1543 MUST reference an RFC describing the protocol. Such an RFC MAY be 1544 Experimental or Informational, although it is preferable if it is 1545 Standards-Track. Registrations MUST also define the rules by which 1546 their "fmt" namespace is managed (see below). 1548 9.2.3 Media formats ("fmt") 1550 Each transport protocol, defined by the "proto" field, has an 1551 associated "fmt" namespace that describes the media formats which may 1552 conveyed by that protocol. Formats cover all the possible encodings 1553 that might want to be transported in a multimedia session. 1555 RTP payload formats under the "RTP/AVP" protocol that have been 1556 assigned static payload types MUST use the static payload type as 1557 their "fmt" value. For payload formats under "RTP/AVP" that have a 1558 dynamic payload type number, the dynamic payload type number is given 1559 as the "fmt" and an additional "rtpmap" attribute specifies the 1560 format name and parameters as defined by the MIME type registration 1561 for the payload format. 1563 For "TCP" and "udp" protocols, new formats SHOULD be registered. Use 1564 of an existing MIME subtype for the format is encouraged. If no MIME 1565 subtype exists, it is RECOMMENDED that a suitable one is registered 1566 through the IETF process (RFC 2048) by production of, or reference 1567 to, a standards-track RFC. If a MIME subtype is for some reason 1568 inappropriate, an RFC publication describing the format MUST be 1569 referenced in the registration, but it may be Informational or 1570 Experimental if the protocol is not deemed to be of widespread 1571 deployment. 1573 For other protocols, formats MAY be registered according to the rules 1574 of the associated "proto" specification. 1576 Registrations of new formats MUST specify which transport protocols 1577 they apply to. 1579 9.2.4 Attribute names ("att-field") 1581 Attribute field names ("att-field") MUST be registered with IANA and 1582 documented, because of noticeable issues due to conflicting 1583 attributes under the same name. Unknown attributes in SDP are simply 1584 ignored, but conflicting ones that fragment the protocol are a 1585 serious problem. 1587 New attribute registerations are accepted according to the 1588 "Specification Required" policy of RFC 2434, provided that the 1589 specification includes the following information: 1590 o contact name, email address and telephone number 1591 o attribute-name (as it will appear in SDP) 1592 o long-form attribute name in English 1593 o type of attribute (session level, media level, or both) 1594 o whether the attribute value is subject to the charset attribute. 1595 o a one paragraph explanation of the purpose of the attribute. 1596 o a specification of appropriate attribute values for this 1597 attribute. 1599 The above is the minimum that IANA will accept. Attributes that are 1600 expected to see widespread use and interoperability, SHOULD be 1601 documented with a standards-track RFC that specifies the attribute 1602 more precisely. 1604 Submitters of registrations should ensure that the specification is 1605 in the spirit of SDP attributes, most notably that the attribute is 1606 platform independent in the sense that it makes no implicit 1607 assumptions about operating systems and does not name specific pieces 1608 of software in a manner that might inhibit interoperability. 1610 IANA is requested to register the following initial set of attribute 1611 names ("att-field" values), with definitions as in Section 6 of this 1612 memo (these definitions update those in RFC 2327): 1614 Name | Session or Media level? | Dependent on charset? 1615 ----------+-------------------------+---------------------- 1616 cat | Session | No 1617 keywds | Session | Yes 1618 tool | Session | No 1619 ptime | Media | No 1620 maxptime | Media | No 1621 rtpmap | Either | No 1622 recvonly | Either | No 1623 sendrecv | Either | No 1624 sendonly | Either | No 1625 inactive | Either | No 1626 orient | Media | No 1627 type | Session | No 1628 charset | Session | No 1629 sdplang | Either | No 1630 lang | Either | No 1631 framerate | Media | No 1632 quality | Media | No 1633 fmtp | Media | No 1635 9.2.5 Bandwidth specifiers ("bwtype") 1637 A proliferation of bandwidth specifiers is strongly discouraged. 1639 New bandwidth specifiers ("bwtype" fields) MUST be registered with 1640 IANA. The submission MUST reference a standards-track RFC specifying 1641 the semantics of the bandwidth specifier precisely, and indicating 1642 when it should be used, and why the existing registered bandwidth 1643 specifiers do not suffice. 1645 IANA is requested to register the bandwith specifiers "CT" and "AS" 1646 with definitions as in Section 5.8 of this memo (these definitions 1647 update those in RFC 2327). 1649 9.2.6 Network types ("nettype") 1651 New network types (the "nettype" field) may be registered with IANA 1652 if SDP needs to be used in the context of non-Internet environments. 1653 Whilst these are not normally the preserve of IANA, there may be 1654 circumstances when an Internet application needs to interoperate with 1655 a non- Internet application, such as when gatewaying an Internet 1656 telephony call into the PSTN. The number of network types should be 1657 small and should be rarely extended. A new network type cannot be 1658 registered without registering at least one address type to be used 1659 with that network type. A new network type registration MUST 1660 reference an RFC which gives details of the network type and address 1661 type and specifies how and when they would be used. Such an RFC MAY 1662 be Informational. 1664 IANA is requested to register the network type "IN" to represent the 1665 Internet, with definition as in Sections 5.2 and 5.7 of this memo 1666 (these definitions update those in RFC 2327). 1668 9.2.7 Address types ("addrtype") 1670 New address types ("addrtype") may be registered with IANA. An 1671 address type is only meaningful in the context of a network type, and 1672 any registration of an address type MUST specify a registered network 1673 type, or be submitted along with a network type registration. A new 1674 address type registration MUST reference an RFC giving details of the 1675 syntax of the address type. Such an RFC MAY be Informational. 1676 Address types are not expected to be registered frequently. 1678 IANA is requested to register the address types "IP4" and "IP6" with 1679 definitions as in Sections 5.2 and 5.7 of this memo (these 1680 definitions update those in RFC 2327). 1682 9.2.8 Registration Procedure 1684 In the RFC documentation that registers SDP "media", "proto", "fmt", 1685 "bwtype", "nettype" and "addrtype" fields, the authors MUST include 1686 the following information for IANA to place in the appropriate 1687 registry: 1688 o contact name, email address and telephone number 1689 o name being registered (as it will appear in SDP) 1690 o long-form name in English 1691 o type of name ("media", "proto", "fmt", "bwtype", "nettype", or 1692 "addrtype") 1693 o a one paragraph explanation of the purpose of the registered name. 1694 o a reference to the specification (e.g. RFC number) of the 1695 registered name. 1697 IANA may refer any registration to the IESG Transport Area Directors 1698 for review, and may request revisions to be made before a 1699 registration will be made. 1701 9.3 Encryption Key Access Methods 1703 The IANA currently maintains a table of SDP encryption key access 1704 method ("enckey") names. This table is obsolete and SHOULD be 1705 removed, since the "k=" line is not extensible. New registrations 1706 MUST NOT be accepted. 1708 Appendix A. SDP Grammar 1710 This appendix provides an Augmented BNF grammar for SDP. ABNF is 1711 defined in [2]. 1713 ; SDP Syntax 1714 session-description = proto-version 1715 origin-field 1716 session-name-field 1717 information-field 1718 uri-field 1719 email-fields 1720 phone-fields 1721 connection-field 1722 bandwidth-fields 1723 time-fields 1724 key-field 1725 attribute-fields 1726 media-descriptions 1728 proto-version = "v=" 1*DIGIT CRLF 1729 ;this memo describes version 0 1731 origin-field = "o=" username SP sess-id SP sess-version SP 1732 nettype SP addrtype SP unicast-address CRLF 1734 session-name-field = "s=" text CRLF 1736 information-field = ["i=" text CRLF] 1738 uri-field = ["u=" uri CRLF] 1740 email-fields = *("e=" email-address CRLF) 1742 phone-fields = *("p=" phone-number CRLF) 1744 connection-field = ["c=" nettype SP addrtype SP 1745 connection-address CRLF] 1746 ;a connection field must be present 1747 ;in every media description or at the 1748 ;session-level 1750 bandwidth-fields = *("b=" bwtype ":" bandwidth CRLF) 1752 time-fields = 1*( "t=" start-time SP stop-time 1753 *(CRLF repeat-fields) CRLF) 1754 [zone-adjustments CRLF] 1756 repeat-fields = "r=" repeat-interval SP typed-time 1757 1*(SP typed-time) 1759 zone-adjustments = "z=" time SP ["-"] typed-time 1760 *(SP time SP ["-"] typed-time) 1762 key-field = ["k=" key-type CRLF] 1764 attribute-fields = *("a=" attribute CRLF) 1766 media-descriptions = *( media-field 1767 information-field 1768 *connection-field 1769 bandwidth-fields 1770 key-field 1771 attribute-fields ) 1773 media-field = "m=" media SP port ["/" integer] 1774 SP proto 1*(SP fmt) CRLF 1776 ; sub-rules of 'o=' 1777 username = non-ws-string 1778 ;pretty wide definition, but doesn't 1779 ;include space 1781 sess-id = 1*DIGIT 1782 ;should be unique for this username/host 1784 sess-version = 1*DIGIT 1785 ;0 is a new session 1787 nettype = token 1788 ;typically "IN" 1790 addrtype = token 1791 ;typically "IP4" or "IP6" 1793 ; sub-rules of 'u=' 1794 uri = URI-reference; see RFC1630 and RFC2732 1796 ; sub-rules of 'e=' 1797 email-address = email *SP "(" 1*email-safe ")" / 1798 1*email-safe "<" email ">" / 1799 email 1801 email = addr-spec ; defined in RFC2822 1802 ; modified to remove CFWS 1804 ; sub-rules of 'p=' 1805 phone-number = phone *SP "(" 1*email-safe ")" / 1806 1*email-safe "<" phone ">" / 1807 phone 1809 phone = "+" POS-DIGIT 1*(SP / "-" / DIGIT) 1811 ; sub-rules of 'c=' 1812 connection-address = multicast-address / unicast-address 1814 ; sub-rules of 'b=' 1815 bwtype = token 1817 bandwidth = 1*DIGIT 1819 ; sub-rules of 't=' 1820 start-time = time / "0" 1822 stop-time = time / "0" 1824 time = POS-DIGIT 9*DIGIT 1825 ; 10-digit NTP time represents times between 1826 ; 1931 and 5068 AD. 9* allows times after 1827 ; that as well. 1829 ; sub-rules of 'r=' and 'z=' 1830 repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] 1832 typed-time = 1*DIGIT [fixed-len-time-unit] 1834 fixed-len-time-unit = "d" / "h" / "m" / "s" 1836 ; sub-rules of 'k=' 1837 key-type = "prompt" / 1838 "clear:" text / 1839 "base64:" base64 / 1840 "uri:" uri / 1841 key-method [ ":" text ] 1843 base64 = *base64-unit [base64-pad] 1844 base64-unit = 4base64-char 1845 base64-pad = 2base64-char "==" / 3base64-char "=" 1846 base64-char = ALPHA / DIGIT / "+" / "/" 1848 key-method = token 1850 ; sub-rules of 'a=' 1851 attribute = (att-field ":" att-value) / att-field 1852 att-field = token 1854 att-value = byte-string 1856 ; sub-rules of 'm=' 1857 media = token 1858 ;typically "audio", "video", "text", 1859 ;"application" or "data" 1861 fmt = token 1862 ;typically an RTP payload type for audio 1863 ;and video media 1865 proto = token "/" token 1866 / token 1867 ;typically "RTP/AVP", "udp" or "tcp" 1869 port = 1*DIGIT 1870 ;should be either "0" or in the range "1024" 1871 ;to "65535" inclusive for UDP based media 1872 ;(a value of "0" is used to signal special 1873 ;conditions in some uses of SDP) 1875 ; generic sub-rules: addressing 1876 unicast-address = IP4-address / IP6-address / FQDN / extn-addr 1878 multicast-address = IP4-multicast / IP6-multicast 1880 IP4-multicast = m1 3( "." decimal-uchar ) 1881 "/" ttl [ "/" integer ] 1882 ; IPv4 multicast addresses may be in the 1883 ; range 224.0.0.0 to 239.255.255.255 1885 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / 1886 ("23" DIGIT ) 1888 IP6-multicast = hexpart [ "/" integer ] 1889 ; IPv6 address starting with FF 1891 ttl = (POS-DIGIT *2DIGIT) / "0" 1893 FQDN = 4*(alpha-numeric / "-" / ".") 1894 ; fully qualified domain name as specified 1895 ; in RFC1035 1897 IP4-address = b1 3("." decimal-uchar) / "0.0.0.0" 1899 b1 = decimal-uchar 1900 ; less than "224"; not "0" or "127" 1902 ; The following is from RFC2373 Appendix B. It is a direct copy. 1903 IP6-address = hexpart [ ":" IP4-address ] 1905 hexpart = hexseq / hexseq "::" [ hexseq ] / 1906 "::" [ hexseq ] 1908 hexseq = hex4 *( ":" hex4) 1910 hex4 = 1*4HEXDIG 1912 ; Generic for other address families 1913 extn-addr = non-ws-string 1915 ; generic sub-rules: datatypes 1916 text = byte-string 1917 ;default is to interpret this as UTF8 text. 1918 ;ISO 8859-1 requires "a=charset:ISO-8859-1" 1919 ;session-level attribute to be used 1921 byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) 1922 ;any byte except NUL, CR or LF 1924 non-ws-string = 1*(VCHAR/%x80-FF) 1925 ;string of visible characters 1927 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 1928 / %x41-5A / %x5E-7E 1930 token = 1*(token-char) 1932 email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF 1933 ;any byte except NUL, CR, LF, or the quoting 1934 ;characters ()<> 1936 integer = POS-DIGIT *DIGIT 1938 ; generic sub-rules: primitives 1939 alpha-numeric = ALPHA / DIGIT 1941 POS-DIGIT = %x31-39 ; 1 - 9 1943 decimal-uchar = DIGIT 1944 / POS-DIGIT DIGIT 1945 / ("1" 2*(DIGIT)) 1946 / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) 1947 / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) 1949 ; external references: 1950 ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 2234 1951 ; URI-reference: from RFC1630 and RFC2732 1952 ; addr-spec: from RFC 2822 1954 Appendix B. Acknowledgments 1956 Many people in the IETF MMUSIC working group have made comments and 1957 suggestions contributing to this document. In particular, we would 1958 like to thank Eve Schooler, Steve Casner, Bill Fenner, Allison 1959 Mankin, Ross Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, 1960 Steve Hanna, Jonathan Lennox and Keith Drage. 1962 10. References 1964 10.1 Normative References 1966 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1967 Levels", BCP 14, RFC 2119, March 1997. 1969 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1970 Specifications: ABNF", RFC 2234, November 1997. 1972 [3] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1973 2279, January 1998. 1975 [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource 1976 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 1978 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1979 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 1981 [6] Alvestrand, H., "Tags for the Identification of Languages", BCP 1982 47, RFC 3066, January 2001. 1984 10.2 Informative References 1986 [7] Mills, D., "Network Time Protocol (Version 3) Specification, 1987 Implementation", RFC 1305, March 1992. 1989 [8] Handley, M., Perkins, C. and E. Whelan, "Session Announcement 1990 Protocol", RFC 2974, October 2000. 1992 [9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1993 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1994 Session Initiation Protocol", RFC 3261, June 2002. 1996 [10] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 1997 Protocol (RTSP)", RFC 2326, April 1998. 1999 [11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2000 Session Description Protocol (SDP)", RFC 3264, June 2002. 2002 [12] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 2003 "RTP: A Transport Protocol for Real-Time Applications", RFC 2004 3550, July 2003. 2006 [13] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 2007 Conferences with Minimal Control", RFC 3551, July 2003. 2009 [14] Huitema, C., "Real Time Control Protocol (RTCP) attribute in 2010 Session Description Protocol (SDP)", RFC 3605, October 2003. 2012 [15] International Telecommunications Union, "H.323 extended for 2013 loosely coupled conferences", ITU Recommendation H.332, 2014 September 1998. 2016 [16] Arkko, J., "Key Management Extensions for Session Description 2017 Protocol (SDP) and Real Time Streaming Protocol (RTSP)", 2018 draft-ietf-mmusic-kmgmt-ext-09 (work in progress), October 2019 2003. 2021 [17] Andreasen, F., Baugher, M. and D. Wing, "SDP Security 2022 Descriptions for Media Streams", 2023 draft-ietf-mmusic-sdescriptions-02 (work in progress), October 2024 2003. 2026 Authors' Addresses 2028 Mark Handley 2029 University College London 2030 Gower Street 2031 London WC1E 6BT 2032 UK 2034 EMail: M.Handley@cs.ucl.ac.uk 2035 Van Jacobson 2036 Packet Design 2037 2465 Latham Street 2038 Mountain View, CA 94040 2039 USA 2041 EMail: van@packetdesign.com 2043 Colin Perkins 2044 University of Glasgow 2045 17 Lilybank Gardens 2046 Glasgow G12 8QQ 2047 UK 2049 EMail: csp@csperkins.org 2051 Intellectual Property Statement 2053 The IETF takes no position regarding the validity or scope of any 2054 Intellectual Property Rights or other rights that might be claimed to 2055 pertain to the implementation or use of the technology described in 2056 this document or the extent to which any license under such rights 2057 might or might not be available; nor does it represent that it has 2058 made any independent effort to identify any such rights. Information 2059 on the IETF's procedures with respect to rights in IETF Documents can 2060 be found in BCP 78 and BCP 79. 2062 Copies of IPR disclosures made to the IETF Secretariat and any 2063 assurances of licenses to be made available, or the result of an 2064 attempt made to obtain a general license or permission for the use of 2065 such proprietary rights by implementers or users of this 2066 specification can be obtained from the IETF on-line IPR repository at 2067 http://www.ietf.org/ipr. 2069 The IETF invites any interested party to bring to its attention any 2070 copyrights, patents or patent applications, or other proprietary 2071 rights that may cover technology that may be required to implement 2072 this standard. Please address the information to the IETF at 2073 ietf-ipr@ietf.org. 2075 Disclaimer of Validity 2077 This document and the information contained herein are provided on an 2078 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2079 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2080 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2081 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2082 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2083 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2085 Copyright Statement 2087 Copyright (C) The Internet Society (2004). This document is subject 2088 to the rights, licenses and restrictions contained in BCP 78, and 2089 except as set forth therein, the authors retain all their rights. 2091 Acknowledgment 2093 Funding for the RFC Editor function is currently provided by the 2094 Internet Society.