idnits 2.17.1 draft-ietf-mmusic-sdp-new-18.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2089. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2073. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2079. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 2095), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** 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 == The page length should not exceed 58 lines per page, but there was 44 longer pages, the longest (page 32) being 73 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 45 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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 539 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 (June 11, 2004) is 7230 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '16' is defined on line 2018, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2279 (ref. '3') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2396 (ref. '4') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2434 (ref. '5') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 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: 12 errors (**), 0 flaws (~~), 11 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Handley 2 Internet-Draft UCL 3 Obsoletes: 2327, 3266 (if V. Jacobson 4 approved) Packet Design 5 Expires: December 10, 2004 C. Perkins 6 University of Glasgow 7 June 11, 2004 9 SDP: Session Description Protocol 10 draft-ietf-mmusic-sdp-new-18.txt 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 10, 2004. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 This memo defines the Session Description Protocol (SDP). SDP is 43 intended for describing multimedia sessions for the purposes of 44 session announcement, session invitation, and other forms of 45 multimedia session initiation. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . 3 51 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . 3 52 3.1 Multicast Session Announcement . . . . . . . . . . . . . . 3 53 3.2 Session Initiation . . . . . . . . . . . . . . . . . . . . 4 54 3.3 Streaming media . . . . . . . . . . . . . . . . . . . . . 4 55 3.4 Email and the World Wide Web . . . . . . . . . . . . . . . 4 56 4. Requirements and Recommendations . . . . . . . . . . . . . . 5 57 4.1 Media Information . . . . . . . . . . . . . . . . . . . . 5 58 4.2 Timing Information . . . . . . . . . . . . . . . . . . . . 6 59 4.3 Private Sessions . . . . . . . . . . . . . . . . . . . . . 6 60 4.4 Obtaining Further Information about a Session . . . . . . 6 61 4.5 Categorisation . . . . . . . . . . . . . . . . . . . . . . 6 62 4.6 Internationalization . . . . . . . . . . . . . . . . . . . 7 63 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . 7 64 5.1 Protocol Version ("v=") . . . . . . . . . . . . . . . . . 9 65 5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 10 66 5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . . 11 67 5.4 Session Information ("i=") . . . . . . . . . . . . . . . . 11 68 5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 11 69 5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . 11 70 5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . 12 71 5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 14 72 5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 15 73 5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . 16 74 5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . 17 75 5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 18 76 5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . 19 77 5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . . 21 78 6. Suggested Attributes . . . . . . . . . . . . . . . . . . . . 24 79 7. Communicating Conference Control Policy . . . . . . . . . . 29 80 8. Security Considerations . . . . . . . . . . . . . . . . . . 30 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31 82 9.1 The "application/sdp" media type . . . . . . . . . . . . . 31 83 9.2 Registration of Parameters . . . . . . . . . . . . . . . . 32 84 9.3 Encryption Key Access Methods . . . . . . . . . . . . . . 36 85 A. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 37 86 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 42 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 88 10.1 Normative References . . . . . . . . . . . . . . . . . . . 42 89 10.2 Informative References . . . . . . . . . . . . . . . . . . 42 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 43 91 Intellectual Property and Copyright Statements . . . . . . . 45 93 1. Introduction 95 [Note to RFC Editor: All references to RFC XXXX should be replaced by 96 the RFC number of this document, when published.] 98 When initiating multimedia teleconferences, voice-over-IP calls, 99 streaming video, or other sessions, there is a requirement to convey 100 media details, transport addresses, and other session description 101 metadata to the participants. 103 SDP provides a standard representation for such information, 104 irrespective of how that information is transported. SDP is purely a 105 format for session description - it does not incorporate a transport 106 protocol, and is intended to use different transport protocols as 107 appropriate, including the Session Announcement Protocol [8], Session 108 Initiation Protocol [9], Real-Time Streaming Protocol [10], 109 electronic mail using the MIME extensions, and the Hypertext 110 Transport Protocol. 112 SDP is intended to be general purpose so that it can be used in a 113 wide range of network environments and applications. However, it is 114 not intended to support negotiation of session content or media 115 encodings: this is viewed as outside the scope of session 116 description. 118 2. Glossary of Terms 120 The following terms are used in this document, and have specific 121 meaning within the context of this document. 123 Conference: A multimedia conference is a set of two or more 124 communicating users along with the software they are using to 125 communicate. 126 Session: A multimedia session is a set of multimedia senders and 127 receivers and the data streams flowing from senders to receivers. 128 A multimedia conference is an example of a multimedia session. 129 Session Description: A well defined format for conveying sufficient 130 information to discover and participate in a multimedia session. 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [1]. 136 3. Examples of SDP Usage 138 3.1 Multicast Session Announcement 140 In order to assist the advertisement of multicast multimedia 141 conferences and other multicast sessions, and to communicate the 142 relevant session setup information to prospective participants, a 143 distributed session directory may be used. An instance of such a 144 session directory periodically sends packets containing a description 145 of the session to a well known multicast group. These advertisements 146 are received by other session directories such that potential remote 147 participants can use the session description to start the tools 148 required to participate in the session. 150 One protocol commonly used to implement such a distributed directory 151 is the Session Announcement Protocol, SAP [8]. SDP provides the 152 recommended session description format for such session 153 announcements. 155 3.2 Session Initiation 157 The Session Initiation Protocol, SIP [9] is an application layer 158 control protocol for creating, modifying and terminating sessions 159 such as Internet multimedia conferences, Internet telephone calls and 160 multimedia distribution. The SIP messages used to create sessions 161 carry session descriptions which allow participants to agree on a set 162 of compatible media types. These session descriptions are commonly 163 formatted using SDP. When used with SIP, the offer/answer model [11] 164 provides a limited framework for negotiation using SDP. 166 3.3 Streaming media 168 The Real Time Streaming Protocol, RTSP [10], is an application-level 169 protocol for control over the delivery of data with real-time 170 properties. RTSP provides an extensible framework to enable 171 controlled, on-demand delivery of real-time data, such as audio and 172 video. An RTSP client and server negotiate an appropriate set of 173 parameters for media delivery, partially using SDP syntax to describe 174 those parameters. 176 3.4 Email and the World Wide Web 178 Alternative means of conveying session descriptions include 179 electronic mail and the World Wide Web. For both email and WWW 180 distribution, the MIME content type "application/sdp" is used. This 181 enables the automatic launching of applications for participation in 182 the session from the WWW client or mail reader in a standard manner. 184 Note that announcements of multicast sessions made only via email or 185 the World Wide Web (WWW) do not have the property that the receiver 186 of a session announcement can necessarily receive the session because 187 the multicast sessions may be restricted in scope, and access to the 188 WWW server or reception of email is possible outside this scope. 190 Session announcements made using SAP do not suffer from this 191 mismatch. 193 4. Requirements and Recommendations 195 The purpose of SDP is to convey information about media streams in 196 multimedia sessions to allow the recipients of a session description 197 to participate in the session. SDP is primarily intended for use in 198 an internetwork, although it is sufficiently general that it can 199 describe conferences in other network environments. Media streams can 200 be many-to-many. The times during which the session is active need 201 not be continuous. 203 Thus far, multicast based sessions on the Internet have differed from 204 many other forms of conferencing in that anyone receiving the traffic 205 can join the session (unless the session traffic is encrypted). In 206 such an environment, SDP serves two primary purposes. It is a means 207 to communicate the existence of a session, and is a means to convey 208 sufficient information to enable joining and participating in the 209 session. In a unicast environment, only the latter purpose is likely 210 to be relevant. 212 Thus SDP includes: 213 o Session name and purpose 214 o Time(s) the session is active 215 o The media comprising the session 216 o Information needed to receive those media (addresses, ports, 217 formats and so on) 218 As resources necessary to participate in a session may be limited, 219 some additional information may also be desirable: 220 o Information about the bandwidth to be used by the conference 221 o Contact information for the person responsible for the session 222 In general, SDP must convey sufficient information to enable 223 applications to join a session (with the possible exception of 224 encryption keys) and to announce the resources to be used to non- 225 participants that may need to know. 227 4.1 Media Information 229 SDP includes: 230 o The type of media (video, audio, etc) 231 o The transport protocol (RTP/UDP/IP, H.320, etc) 232 o The format of the media (H.261 video, MPEG video, etc) 234 For an IP multicast session, the following are also conveyed: 235 o Multicast address for media 236 o Transport port for media 237 This address and port are the destination address and destination 238 port of the multicast stream, whether being sent, received, or both. 240 For an IP unicast session, the following are conveyed: 241 o Remote address for media 242 o Transport port for media 243 The semantics of this address and port depend on the media and 244 transport protocol defined. By default, this is the remote address 245 and remote port to which data is sent, however some media types may 246 redefine this behaviour. 248 4.2 Timing Information 250 Sessions may either be bounded or unbounded in time. Whether or not 251 they are bounded, they may be only active at specific times. 253 SDP can convey: 254 o An arbitrary list of start and stop times bounding the session 255 o For each bound, repeat times such as "every Wednesday at 10am for 256 one hour" 257 This timing information is globally consistent, irrespective of local 258 time zone or daylight saving time. 260 4.3 Private Sessions 262 It is possible to create both public sessions and private sessions. 263 SDP itself does not distinguish between these: private sessions are 264 typically conveyed by encrypting the session description during 265 distribution. The details of how encryption is performed are 266 dependent on the mechanism used to convey SDP - e.g. mechanisms are 267 defined for SDP transported using SAP [8] and SIP [9]. 269 If a session announcement is private it is possible to use that 270 private announcement to convey encryption keys necessary to decode 271 each of the media in a conference, including enough information to 272 know which encryption scheme is used for each media. 274 4.4 Obtaining Further Information about a Session 276 A session description should convey enough information to decide 277 whether or not to participate in a session. SDP may include 278 additional pointers in the form of Universal Resources Identifiers 279 (URIs) for more information about the session. 281 4.5 Categorisation 283 When many session descriptions are being distributed by SAP, or any 284 other advertisement mechanism, it may be desirable to filter session 285 announcements that are of interest from those that are not. SDP 286 supports a categorisation mechanism for sessions that is capable of 287 being automated. 289 4.6 Internationalization 291 The SDP specification recommends the use of the ISO 10646 character 292 sets in the UTF-8 encoding [3] to allow many different languages to 293 be represented. However, to assist in compact representations, SDP 294 also allows other character sets such as ISO 8859-1 to be used when 295 desired. Internationalization only applies to free-text fields 296 (session name and background information), and not to SDP as a whole. 298 5. SDP Specification 300 An SDP session description is denoted by the MIME content type 301 "application/sdp" (See Section 9). 303 An SDP session description is entirely textual using the ISO 10646 304 character set in UTF-8 encoding. SDP field names and attribute names 305 use only the US-ASCII subset of UTF-8, but textual fields and 306 attribute values MAY use the full ISO 10646 character set. Field and 307 attribute values which use the full UTF-8 character set are never 308 directly compared, hence there is no requirement for UTF-8 309 normalization. The textual form, as opposed to a binary encoding 310 such as ASN.1 or XDR, was chosen to enhance portability, to enable a 311 variety of transports to be used (e.g, session description in a MIME 312 email message) and to allow flexible, text-based toolkits (e.g., Tcl/ 313 Tk) to be used to generate and to process session descriptions. 314 However, since SDP may be used in environments where the maximum 315 permissable size of a session description is limited (e.g. SAP 316 announcements), the encoding is deliberately compact. Also, since 317 announcements may be transported via very unreliable means or damaged 318 by an intermediate caching server, the encoding was designed with 319 strict order and formatting rules so that most errors would result in 320 malformed session announcements which could be detected easily and 321 discarded. This also allows rapid discarding of encrypted session 322 announcements for which a receiver does not have the correct key. 324 An SDP session description consists of a number of lines of text of 325 the form: 327 = 329 where MUST be exactly one case-significant character and 330 is structured text whose format depends on . In 331 general is either a number of fields delimited by a single 332 space character, or a free format string. Whitespace MUST NOT be used 333 either side of the "=" sign. 335 An SDP session description consists of a session-level section 336 followed by zero or more media-level sections. The session-level 337 part starts with a "v=" line and continues to the first media-level 338 section. The media description starts with an "m=" line and 339 continues to the next media description or end of the whole session 340 description. In general, session-level values are the default for 341 all media unless overridden by an equivalent media-level value. 343 Some lines in each description are REQUIRED and some are OPTIONAL but 344 all MUST appear in exactly the order given here (the fixed order 345 greatly enhances error detection and allows for a simple parser). 346 OPTIONAL items are marked with a "*". 348 Session description 349 v= (protocol version) 350 o= (owner/creator and session identifier). 351 s= (session name) 352 i=* (session information) 353 u=* (URI of description) 354 e=* (email address) 355 p=* (phone number) 356 c=* (connection information - not required if included in 357 all media) 358 b=* (zero or more bandwidth information lines) 359 One or more time descriptions (see below) 360 z=* (time zone adjustments) 361 k=* (encryption key) 362 a=* (zero or more session attribute lines) 363 Zero or more media descriptions (see below) 365 Time description 366 t= (time the session is active) 367 r=* (zero or more repeat times) 369 Media description 370 m= (media name and transport address) 371 i=* (media title) 372 c=* (connection information - optional if included at 373 session-level) 374 b=* (zero or more bandwidth information lines) 375 k=* (encryption key) 376 a=* (zero or more media attribute lines) 378 The set of type letters is deliberately small and not intended to be 379 extensible -- an SDP parser MUST completely ignore any session 380 description that contains a type letter that it does not understand. 381 The attribute mechanism ("a=" described below) is the primary means 382 for extending SDP and tailoring it to particular applications or 383 media. Some attributes (the ones listed in Section 6 of this memo) 384 have a defined meaning, but others may be added on an application-, 385 media- or session-specific basis. An SDP parser MUST ignore any 386 attribute it doesn't understand. 388 An SDP session description may contain URIs which reference external 389 content in the "u=", "k=" and "a=" lines. These URIs may be 390 dereferenced in some cases, making the session description non-self 391 contained. 393 The connection ("c=") and attribute ("a=") information in the 394 session-level section applies to all the media of that session unless 395 overridden by connection information or an attribute of the same name 396 in the media description. For instance, in the example below, each 397 media behaves as if it were given a "recvonly" attribute. 399 An example SDP description is: 401 v=0 402 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 403 s=SDP Seminar 404 i=A Seminar on the session description protocol 405 u=http://www.example.com/seminars/sdp.pdf 406 e=j.doe@example.com (Jane Doe) 407 c=IN IP4 224.2.17.12/127 408 t=2873397496 2873404696 409 a=recvonly 410 m=audio 49170 RTP/AVP 0 411 m=video 51372 RTP/AVP 31 412 m=application 32416 udp wb 413 a=orient:portrait 415 Text fields such as the session name and information are octet 416 strings which may contain any octet with the exceptions of 0x00 417 (Nul), 0x0a (ASCII newline) and 0x0d (ASCII carriage return). The 418 sequence CRLF (0x0d0a) is used to end a record, although parsers 419 SHOULD be tolerant and also accept records terminated with a single 420 newline character. If the "a=charset" attribute is not present, 421 these octet strings MUST be interpreted as containing ISO-10646 422 characters in UTF-8 encoding (the presence of the "a=charset" 423 attribute MAY force some fields to be interpreted differently). 425 5.1 Protocol Version ("v=") 427 v=0 429 The "v=" field gives the version of the Session Description Protocol. 430 This memo defines version 0. There is no minor version number. 432 5.2 Origin ("o=") 434 o= 435 437 The "o=" field gives the originator of the session (her username and 438 the address of the user's host) plus a session identifier and version 439 number: 441 is the user's login on the originating host, or it is "-" 442 if the originating host does not support the concept of user ids. 443 The MUST NOT contain spaces. 444 is a numeric string such that the tuple of , 445 , , and form a 446 globally unique identifier for the session. The method of 447 allocation is up to the creating tool, but it has been 448 suggested that a Network Time Protocol (NTP) format timestamp be 449 used to ensure uniqueness [7]. 450 is a version number for this session description. Its 451 usage is up to the creating tool, so long as is 452 increased when a modification is made to the session data. Again, 453 it is RECOMMENDED that an NTP format timestamp is used. 454 is a text string giving the type of network. Initially "IN" 455 is defined to have the meaning "Internet", but other values MAY be 456 registered in future (see Section 9). 457 is a text string giving the type of the address that 458 follows. Initially "IP4" and "IP6" are defined, but other values 459 MAY be registered in future (see Section 9). 460 is the address of the machine from which the 461 session was created. For an address type of IP4, this is either 462 the fully-qualified domain name of the machine, or the 463 dotted-decimal representation of the IP version 4 address of the 464 machine. For an address type of IP6, this is either the 465 fully-qualified domain name of the machine, or the compressed 466 textual representation of the IP version 6 address of the machine. 467 For both IP4 and IP6, the fully-qualified domain name is the form 468 that SHOULD be given unless this is unavailable, in which case the 469 globally unique address MAY be substituted. A local IP address 470 MUST NOT be used in any context where the SDP description might 471 leave the scope in which the address is meaningful. 473 In general, the "o=" field serves as a globally unique identifier for 474 this version of this session description, and the subfields excepting 475 the version taken together identify the session irrespective of any 476 modifications. 478 5.3 Session Name ("s=") 480 s= 482 The "s=" field is the textual session name. There MUST be one and 483 only one "s=" field per session description. The "s=" field MUST NOT 484 be empty and SHOULD contain ISO 10646 characters (but see also the 485 "a=charset" attribute). If a session has no meaningful name, the 486 value "s= " SHOULD be used (i.e. a single space as the session name). 488 5.4 Session Information ("i=") 490 i= 492 The "i=" field provides textual information about the session. There 493 may be at most one session-level "i=" field per session description, 494 and at most one "i=" field per media. If the "a=charset" attribute is 495 present, it specifies the character set used in the "i=" field. If 496 the "a=charset" attribute is not present, the "i=" field MUST contain 497 ISO 10646 characters in UTF-8 encoding. 499 A single "i=" field MAY also be used for each media definition. In 500 media definitions, "i=" fields are primarily intended for labeling 501 media streams. As such, they are most likely to be useful when a 502 single session has more than one distinct media stream of the same 503 media type. An example would be two different whiteboards, one for 504 slides and one for feedback and questions. 506 5.5 URI ("u=") 508 u= 510 A URI is a Universal Resource Identifier as used by WWW clients [4]. 511 The URI should be a pointer to additional information about the 512 conference. This field is OPTIONAL, but if it is present it MUST be 513 specified before the first media field. No more than one URI field is 514 allowed per session description. 516 5.6 Email Address and Phone Number ("e=" and "p=") 518 e= 519 p= 521 The "e=" and "p=" lines specify contact information for the person 522 responsible for the conference. This is not necessarily the same 523 person that created the conference announcement. 525 Inclusion of an email address or phone number is OPTIONAL. Note that 526 the previous version of SDP specified that either an email field or a 527 phone field MUST be specified, but this was widely ignored. The 528 change brings the specification into line with common usage. 530 If the email addres or phone number are present, they MUST be 531 specified before the first media field. More than one email or phone 532 field can be given for a session description. 534 Phone numbers SHOULD be given in the form of an international public 535 telecommunication number (see ITU-T Recommendation E.164) preceded by 536 a "+". Spaces and hyphens may be used to split up a phone field to 537 aid readability if desired. For example: 539 p=+44-171-380-7777 or p=+1 617 555 6011 541 Both email addresses and phone numbers can have an OPTIONAL free text 542 string associated with them, normally giving the name of the person 543 who may be contacted. This MUST be enclosed in parenthesis if it is 544 present. For example: 546 e=j.doe@example.com (Jane Doe) 548 The alternative RFC 2822 name quoting convention is also allowed for 549 both email addresses and phone numbers. For example: 551 e=Jane Doe 553 The free text string SHOULD be in the ISO-10646 character set with 554 UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if 555 the appropriate session-level "a=charset" attribute is set. 557 5.7 Connection Data ("c=") 559 c= 561 The "c=" field contains connection data. 563 A session description MUST contain either at least one "c=" field in 564 each media description or a single "c=" field at the session level. 565 It MAY contain a single session-level "c=" field and additional "c=" 566 field(s) per media description, in which case the per-media values 567 override the session-level settings for the respective media. 569 The first sub-field ("") is the network type, which is a 570 text string giving the type of network. Initially "IN" is defined to 571 have the meaning "Internet", but other values MAY be registered in 572 the future (see Section 9). 574 The second sub-field ("") is the address type. This allows 575 SDP to be used for sessions that are not IP based. Currently only IP4 576 and IP6 are defined, but other values MAY be registered in the future 577 (see Section 9). 579 The third sub-field ("") is the connection 580 address. OPTIONAL sub-fields MAY be added after the connection 581 address depending on the value of the field. 583 When the is IP4 and IP6, the connection address is defined 584 as follows: 586 o If the session is multicast, the connection address will be an IP 587 multicast group address. If the session is not multicast, then 588 the connection address contains the unicast IP address of the 589 expected data source or data relay or data sink as determined by 590 additional attribute fields. It is not expected that unicast 591 addresses will be given in a session description that is 592 communicated by a multicast announcement, though this is not 593 prohibited. 594 o Conferences using an IPv4 multicast connection address MUST also 595 have a time to live (TTL) value present in addition to the 596 multicast address. The TTL and the address together define the 597 scope with which multicast packets sent in this conference will be 598 sent. TTL values MUST be in the range 0-255. 600 The TTL for the session is appended to the address using a slash as a 601 separator. An example is: 603 c=IN IP4 224.2.36.42/127 605 IPv6 multicast does not use TTL scoping, and hence the TTL value MUST 606 NOT be present for IPv6 multicast. It is expected that IPv6 scoped 607 addresses will be used to limit the scope of conferences. 609 Hierarchical or layered encoding schemes are data streams where the 610 encoding from a single media source is split into a number of layers. 611 The receiver can choose the desired quality (and hence bandwidth) by 612 only subscribing to a subset of these layers. Such layered encodings 613 are normally transmitted in multiple multicast groups to allow 614 multicast pruning. This technique keeps unwanted traffic from sites 615 only requiring certain levels of the hierarchy. For applications 616 requiring multiple multicast groups, we allow the following notation 617 to be used for the connection address: 619 [/]/ 621 If the number of addresses is not given it is assumed to be one. 623 Multicast addresses so assigned are contiguously allocated above the 624 base address, so that, for example: 626 c=IN IP4 224.2.1.1/127/3 628 would state that addresses 224.2.1.1, 224.2.1.2 and 224.2.1.3 are to 629 be used at a TTL of 127. This is semantically identical to including 630 multiple "c=" lines in a media description: 632 c=IN IP4 224.2.1.1/127 633 c=IN IP4 224.2.1.2/127 634 c=IN IP4 224.2.1.3/127 636 Similarly, an IPv6 example would be: 638 c=IN IP6 FF15::101/3 640 which is semantically equivalent to: 642 c=IN IP6 FF15::101 643 c=IN IP6 FF15::102 644 c=IN IP6 FF15::103 646 (remembering that the TTL field is not present in IPv6 multicast). 648 Multiple addresses or "c=" lines MAY be specified on a per-media 649 basis only if they provide multicast addresses for different layers 650 in a hierarchical or layered encoding scheme. They MUST NOT be 651 specified for a session-level "c=" field. 653 The slash notation described above MUST NOT be used for IP unicast 654 addresses. 656 5.8 Bandwidth ("b=") 658 b=: 660 This OPTIONAL field denotes the proposed bandwidth to be used by the 661 session or media. The is an alphanumeric modifier giving 662 the meaning of the figure. Two values are initially 663 defined, but other values MAY be registered in future (see Section 664 9): 666 CT If the bandwidth of a session or media in a session is different 667 from the bandwidth implicit from the scope, a "b=CT:..." line 668 SHOULD be supplied for the session giving the proposed upper limit 669 to the bandwidth used. The primary purpose of this is to give an 670 approximate idea as to whether two or more sessions can co-exist 671 simultaneously. When using the CT modifier with RTP, if several 672 RTP sessions are part of the conference, the conference total 673 refers to total bandwidth of all RTP sessions. 674 AS The bandwidth is interpreted to be application-specific (it will 675 be the application's concept of maximum bandwidth). Normally this 676 will coincide with what is set on the application's "maximum 677 bandwidth" control if applicable. For RTP based applications, AS 678 gives the RTP "session bandwidth" as defined in section 6.2 of 679 [12]. 681 Note that CT gives a total bandwidth figure for all the media at all 682 sites. AS gives a bandwidth figure for a single media at a single 683 site, although there may be many sites sending simultaneously. 685 A prefix "X-" is defined for names. This is intended for 686 experimental purposes only. For example: 688 b=X-YZ:128 690 Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers 691 SHOULD be registered with IANA in the standard namespace. SDP parsers 692 MUST ignore bandwidth fields with unknown modifiers. Modifiers MUST 693 be alpha-numeric and, although no length limit is given, they are 694 recommended to be short. 696 The is in kilobits per second by default. Modifiers MAY 697 specify that alternative units are to be used (the modifiers defined 698 in this memo use the default units). 700 5.9 Timing ("t=") 702 t= 704 The "t=" lines specify the start and stop times for a session. 705 Multiple "t=" lines MAY be used if a session is active at multiple 706 irregularly spaced times; each additional "t=" lines specifies an 707 additional period of time for which the session will be active. If 708 the session is active at regular times, an "r=" line (see below) 709 should be used in addition to, and following, a "t=" line - in which 710 case the "t=" line specifies the start and stop times of the repeat 711 sequence. 713 The first and second sub-fields give the start and stop times for the 714 session respectively. These values are the decimal representation of 715 Network Time Protocol (NTP) time values in seconds [7]. To convert 716 these values to UNIX time, subtract decimal 2208988800. 718 NTP timestamps are 64 bit values which wrap sometime in the year 719 2036. Since SDP uses an arbitrary length decimal representation, 720 this should not cause an issue (SDP timestamps will continue counting 721 seconds since 1900, NTP will use the value modulo the 64 bit limit). 723 If the is set to zero, then the session is not bounded, 724 though it will not become active until after the . If 725 the is also zero, the session is regarded as permanent. 727 User interfaces SHOULD strongly discourage the creation of unbounded 728 and permanent sessions as they give no information about when the 729 session is actually going to terminate, and so make scheduling 730 difficult. 732 The general assumption may be made, when displaying unbounded 733 sessions that have not timed out to the user, that an unbounded 734 session will only be active until half an hour from the current time 735 or the session start time, whichever is the later. If behaviour 736 other than this is required, an end-time should be given and modified 737 as appropriate when new information becomes available about when the 738 session should really end. 740 Permanent sessions may be shown to the user as never being active 741 unless there are associated repeat times which state precisely when 742 the session will be active. In general, permanent sessions SHOULD 743 NOT be created for any session expected to have a duration of less 744 than 2 months, and should be discouraged for sessions expected to 745 have a duration of less than 6 months. 747 5.10 Repeat Times ("r=") 749 r= 751 "r=" fields specify repeat times for a session. For example, if a 752 session is active at 10am on Monday and 11am on Tuesday for one hour 753 each week for three months, then the in the 754 corresponding "t=" field would be the NTP representation of 10am on 755 the first Monday, the would be 1 week, the would be 1 hour, and the offsets would be zero and 25 757 hours. The corresponding "t=" field stop time would be the NTP 758 representation of the end of the last session three months later. By 759 default all fields are in seconds, so the "r=" and "t=" fields might 760 be: 762 t=3034423619 3042462419 763 r=604800 3600 0 90000 765 To make description more compact, times may also be given in units of 766 days, hours or minutes. The syntax for these is a number immediately 767 followed by a single case-sensitive character. Fractional units are 768 not allowed - a smaller unit should be used instead. The following 769 unit specification characters are allowed: 771 d - days (86400 seconds) 772 h - hours (3600 seconds) 773 m - minutes (60 seconds) 774 s - seconds (allowed for completeness but not recommended) 776 Thus, the above session announcement could also have been written: 778 r=7d 1h 0 25h 780 Monthly and yearly repeats cannot be directly specified with a single 781 SDP repeat time - instead separate "t=" fields should be used to 782 explicitly list the session times. 784 5.11 Time Zones ("z=") 786 z= .... 788 To schedule a repeated session which spans a change from daylight- 789 saving time to standard time or vice-versa, it is necessary to 790 specify offsets from the base time. This is required because 791 different time zones change time at different times of day, different 792 countries change to or from daylight time on different dates, and 793 some countries do not have daylight saving time at all. 795 Thus in order to schedule a session that is at the same time winter 796 and summer, it must be possible to specify unambiguously by whose 797 time zone a session is scheduled. To simplify this task for 798 receivers, we allow the sender to specify the NTP time that a time 799 zone adjustment happens and the offset from the time when the session 800 was first scheduled. The "z=" field allows the sender to specify a 801 list of these adjustment times and offsets from the base time. 803 An example might be: 805 z=2882844526 -1h 2898848070 0 807 This specifies that at time 2882844526 the time base by which the 808 session's repeat times are calculated is shifted back by 1 hour, and 809 that at time 2898848070 the session's original time base is restored. 810 Adjustments are always relative to the specified start time - they 811 are not cumulative. Adjustments apply to all "t=" and "r=" lines in 812 a session description. 814 If a session is likely to last several years, it is expected that the 815 session announcement will be modified periodically rather than 816 transmit several years worth of adjustments in one session 817 announcement. 819 5.12 Encryption Keys ("k=") 821 k= 822 k=: 824 If transported over a secure and trusted channel, the session 825 description protocol MAY be used to convey encryption keys. A simple 826 mechanism for key exchange is provided by the key field ("k=") 827 although this is primarily supported for compatibility with older 828 implementations and its use is NOT RECOMMENDED. Work is in progress 829 to define new key exchange mechanisms for use with SDP [18][17] and 830 it is expected that new applications will use those mechanisms. 832 A key field is permitted before the first media entry (in which case 833 it applies to all media in the session), or for each media entry as 834 required. The format of keys and their usage is outside the scope of 835 this document, and the key field provides no way to indicate the 836 encryption algorithm to be used, key type, or other information about 837 the key: this is assumed to be provided by the higher-level protocol 838 using SDP. If there is a need to convey this information within SDP, 839 the extensions mentioned previously SHOULD be used. Many security 840 protocols require two keys, one for confidentiality and another for 841 integrity. This specification does not support the transfer of two 842 keys. 844 The method indicates the mechanism to be used to obtain a usable key 845 by external means, or from the encoded encryption key given. The 846 following methods are defined: 848 k=clear: 850 The encryption key is included untransformed in this key field. 851 This method MUST NOT be used unless it can be guaranteed that 852 the SDP is conveyed over a secure channel. 854 k=base64: 856 The encryption key is included in this key field but has been 857 base64 encoded because it includes characters that are 858 prohibited in SDP. This method MUST NOT be used unless it can 859 be guaranteed that the SDP is conveyed over a secure channel. 861 k=uri: 863 A Universal Resource Identifier is included in the key field. 864 The URI refers to the data containing the key, and may require 865 additional authentication before the key can be returned. When 866 a request is made to the given URI, the reply should specify 867 the encoding for the key. The URI is often a secure HTTP URI, 868 although this is not required. 870 k=prompt 872 No key is included in this SDP description, but the session or 873 media stream referred to by this key field is encrypted. The 874 user should be prompted for the key when attempting to join the 875 session, and this user-supplied key should then be used to 876 decrypt the media streams. The use of user-specified keys is 877 NOT RECOMMENDED, since such keys tend to have weak security 878 properties. 880 The key field MUST NOT be used unless it can be guaranteed that the 881 SDP is conveyed over a secure and trusted channel. An example of such 882 a channel might be SDP embedded inside an S/MIME message or a TLS 883 protected HTTP or SIP session. It is important to ensure that the 884 secure channel is with the party that is authorized to join the 885 session, not an intermediary: if a caching proxy server is used, it 886 is important to ensure that the proxy is either trusted or unable to 887 access the SDP. Definition of appropriate security measures is beyond 888 the scope of this specification, and should be defined by the users 889 of SDP. 891 5.13 Attributes ("a=") 893 a= 894 a=: 896 Attributes are the primary means for extending SDP. Attributes may 897 be defined to be used as "session-level" attributes, "media-level" 898 attributes, or both. 900 A media description may have any number of attributes ("a=" fields) 901 which are media specific. These are referred to as "media-level" 902 attributes and add information about the media stream. Attribute 903 fields can also be added before the first media field; these 904 "session-level" attributes convey additional information that applies 905 to the conference as a whole rather than to individual media; an 906 example might be the conference's floor control policy. 908 Attribute fields may be of two forms: 910 o property attributes: 911 A property attribute is simply of the form "a=". 912 These are binary attributes, and the presence of the 913 attribute conveys that the attribute is a property of 914 the session. An example might be "a=recvonly". 916 o value attributes: 917 A value attribute is of the form "a=:". 918 For example, a whiteboard could have the value attribute 919 "a=orient:landscape" 921 Attribute interpretation depends on the media tool being invoked. 922 Thus receivers of session descriptions should be configurable in 923 their interpretation of session descriptions in general and of 924 attributes in particular. 926 Attribute names MUST be in the US-ASCII subset of ISO-10646/UTF-8. 928 Attribute values are octet strings, and MAY use any octet value 929 except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute 930 values are to be interpreted as in ISO-10646 character set with UTF-8 931 encoding. Unlike other text fields, attribute values are NOT 932 normally affected by the "charset" attribute as this would make 933 comparisons against known values problematic. However, when an 934 attribute is defined, it can be defined to be charset-dependent, in 935 which case it's value should be interpreted in the session charset 936 rather than in ISO-10646. 938 Attributes MUST be registered with IANA (see Section 9). If an 939 attribute is received that is not understood, it MUST be ignored by 940 the receiver. 942 5.14 Media Descriptions ("m=") 944 m= 946 A session description may contain a number of media descriptions. 947 Each media description starts with an "m=" field, and is terminated 948 by either the next "m=" field or by the end of the session 949 description. A media field has several sub-fields. 951 The first sub-field ("") is the media type. Currently defined 952 media are "audio", "video", "text", "application", "data" and 953 "control", though this list may be extended in future (see Section 954 9). The difference between "application" and "data" is that the 955 former is a media flow such as whiteboard information, and the latter 956 is bulk-data transfer such as multicasting of program executables 957 which will not typically be displayed to the user. "control" is used 958 to specify an additional conference control channel for the session. 960 The second sub-field ("") is the transport port to which the 961 media stream is sent. The meaning of the transport port depends on 962 the network being used as specified in the relevant "c=" field, and 963 on the transport protocol defined in the third sub-field. Other 964 ports used by the media application (such as the RTCP port [12]) MAY 965 be derived algorithmically from the base media port or MAY be 966 specified in a separate attribute (e.g. "a=rtcp:" as defined in 967 [14]). 969 For applications where hierarchically encoded streams are being sent 970 to a unicast address, it may be necessary to specify multiple 971 transport ports. This is done using a similar notation to that used 972 for IP multicast addresses in the "c=" field: 974 m= / 976 In such a case, the ports used depend on the transport protocol. For 977 RTP, the default is that only the even numbered ports are used for 978 data with the corresponding one-higher odd ports used for the RTCP 979 belonging to the RTP session, and the denoting the 980 number of RTP sessions. For example: 982 m=video 49170/2 RTP/AVP 31 984 would specify that ports 49170 and 49171 form one RTP/RTCP pair and 985 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the 986 transport protocol and 31 is the format (see below). If non- 987 contiguous ports are required, they must be signalled using a 988 separate attribute (e.g. "a=rtcp:" as defined in [14]). 990 If multiple addresses are specified in the "c=" field and multiple 991 ports are specified in the "m=" field, a one-to-one mapping from port 992 to the corresponding address is implied. For example: 994 c=IN IP4 224.2.1.1/127/2 995 m=video 49170/2 RTP/AVP 31 997 would imply that address 224.2.1.1 is used with ports 49170 and 998 49171, and address 224.2.1.2 is used with ports 49172 and 49173. 1000 The third sub-field ("") is the transport protocol. The 1001 transport protocol values are dependent on the address type field in 1002 the "c=" fields. Thus a "c=" field of IP4 defines that the transport 1003 protocol runs over IP4. For IP4, it is normally expected that most 1004 media traffic will be carried as RTP over UDP. The following 1005 transport protocols are defined, but may be extended through 1006 registration of new protocols with IANA (see Section 9): 1008 RTP/AVP - the IETF's Realtime Transport Protocol using the 1009 Audio/Video profile carried over UDP. 1010 udp - User Datagram Protocol 1012 If an application uses a single combined proprietary media format and 1013 transport protocol over UDP, then simply specifying the transport 1014 protocol as udp and using the format field to distinguish the 1015 combined protocol is recommended. If a transport protocol is used 1016 over UDP to carry several distinct media types that need to be 1017 distinguished by a session directory, then specifying the transport 1018 protocol and media format separately is necessary. RTP is an example 1019 of a transport-protocol that carries multiple payload formats that 1020 must be distinguished by the session directory for it to know how to 1021 start appropriate tools, relays, mixers or recorders. 1023 The main reason to specify the transport-protocol in addition to the 1024 media format is that the same standard media formats may be carried 1025 over different transport protocols even when the network protocol is 1026 the same - a historical example is vat PCM audio and RTP PCM audio. 1027 In addition, relays and monitoring tools that are 1028 transport-protocol-specific but format-independent are possible. 1030 For RTP media streams operating under the RTP Audio/Video Profile 1031 [13], the protocol field is "RTP/AVP". Should other RTP profiles be 1032 defined in the future, their profiles will be specified in the same 1033 way. For example, the protocol field "RTP/XYZ" would specify RTP 1034 operating under a profile whose short name is "XYZ". 1036 The fourth and subsequent sub-fields ("") are media formats. 1037 For audio, text and video, these SHOULD reference a MIME sub-type 1038 describing the format under the "audio", "text" and "video" top-level 1039 MIME types. 1041 When a list of payload formats is given, this implies that all of 1042 these formats may be used in the session, but the first of these 1043 formats SHOULD be used as the default format for the session. 1045 For media whose transport protocol is not RTP or UDP the format field 1046 is protocol specific. Such formats should be defined in an 1047 additional specification document. 1049 For media whose transport protocol is RTP, SDP can be used to provide 1050 a dynamic binding of media encoding to RTP payload type. The encoding 1051 names in the RTP AV Profile do not specify unique audio encodings (in 1052 terms of clock rate and number of audio channels), and so they are 1053 not used directly in SDP format fields. Instead, the payload type 1054 number should be used to specify the format for static payload types 1055 and the payload type number along with additional encoding 1056 information should be used for dynamically allocated payload types. 1058 An example of a static payload type is u-law PCM coded single channel 1059 audio sampled at 8kHz. This is completely defined in the RTP Audio/ 1060 Video profile as payload type 0, so the media field for such a stream 1061 sent to UDP port 49232 is: 1063 m=audio 49232 RTP/AVP 0 1065 An example of a dynamic payload type is 16 bit linear encoded stereo 1066 audio sampled at 16 kHz. If we wish to use dynamic RTP/AVP payload 1067 type 98 for such a stream, additional information is required to 1068 decode it: 1070 m=audio 49232 RTP/AVP 98 1071 a=rtpmap:98 L16/16000/2 1073 The general form of an rtpmap attribute is: 1075 a=rtpmap: / 1076 [/] 1078 For audio streams, may specify the number of 1079 audio channels. This parameter may be omitted if the number of 1080 channels is one provided no additional parameters are needed. 1082 For video streams, no encoding parameters are currently specified. 1084 Additional parameters may be defined in the future, but codec- 1085 specific parameters SHOULD NOT be added. Parameters added to an 1086 rtpmap attribute SHOULD only be those required for a session 1087 directory to make the choice of appropriate media to participate in a 1088 session. Codec-specific parameters should be added in other 1089 attributes (for example, "a=fmtp:"). 1091 Up to one rtpmap attribute can be defined for each media format 1092 specified. Thus we might have: 1094 m=audio 49230 RTP/AVP 96 97 98 1095 a=rtpmap:96 L8/8000 1096 a=rtpmap:97 L16/8000 1097 a=rtpmap:98 L16/11025/2 1099 RTP profiles that specify the use of dynamic payload types MUST 1100 define the set of valid encoding names and/or a means to register 1101 encoding names if that profile is to be used with SDP. 1103 Note that RTP audio formats typically do not include information 1104 about the number of samples per packet. If a non-default (as defined 1105 in the RTP Audio/Video Profile) packetisation is required, the 1106 "ptime" attribute is used as given below. 1108 For more details on RTP audio and video formats, see [13]. 1110 Predefined application formats for the UDP protocol with non-RTP 1111 media are as below: 1113 wb: LBL Whiteboard (transport: udp) 1114 nt: UCL Network Text Editor (transport: udp) 1116 6. Suggested Attributes 1118 The following attributes are defined. Since application writers may 1119 add new attributes as they are required, this list is not exhaustive. 1121 a=cat: 1123 This attribute gives the dot-separated hierarchical category 1124 of the session. This is to enable a receiver to filter 1125 unwanted sessions by category. It is a session-level 1126 attribute, and is not dependent on charset. 1128 a=keywds: 1130 Like the cat attribute, this is to assist identifying wanted 1131 sessions at the receiver. This allows a receiver to select 1132 interesting session based on keywords describing the purpose 1133 of the session. It is a session-level attribute. It is a 1134 charset dependent attribute, meaning that its value should be 1135 interpreted in the charset specified for the session 1136 description if one is specified, or by default in ISO 1137 10646/UTF-8. 1139 a=tool: 1141 This gives the name and version number of the tool used to 1142 create the session description. It is a session-level 1143 attribute, and is not dependent on charset. 1145 a=ptime: 1147 This gives the length of time in milliseconds represented by 1148 the media in a packet. This is probably only meaningful for 1149 audio data, but may be used with other media types if it makes 1150 sense. It should not be necessary to know ptime to decode RTP 1151 or vat audio, and it is intended as a recommendation for the 1152 encoding/packetisation of audio. It is a media attribute, and 1153 is not dependent on charset. 1155 a=maxptime: 1157 The maximum amount of media which can be encapsulated in each 1158 packet, expressed as time in milliseconds. The time SHALL be 1159 calculated as the sum of the time the media present in the 1160 packet represents. The time SHOULD be a multiple of the frame 1161 size. This attribute is probably only meaningful for audio 1162 data, but may be used with other media types if it makes 1163 sense. It is a media attribute, and is not dependent on 1164 charset. Note that this attribute was introduced after RFC 1165 2327, and non updated implementations will ignore this 1166 attribute. 1168 a=rtpmap: / 1169 [/] 1171 See Section 5.14. This is a media level attribute that is not 1172 dependent on charset. 1174 a=recvonly 1176 This specifies that the tools should be started in receive 1177 only mode where applicable. It can be either a session or 1178 media attribute, and is not dependent on charset. Note that 1179 recvonly applies to the media only, not to any associated 1180 control protocol (e.g. an RTP based system in recvonly mode 1181 SHOULD still send RTCP packets). 1183 a=sendrecv 1185 This specifies that the tools should be started in send and 1186 receive mode. This is necessary for interactive conferences 1187 with tools that default to receive only mode. It can be either 1188 a session or media attribute, and is not dependent on charset. 1190 If none of the attributes "sendonly", "recvonly", "inactive", 1191 and "sendrecv" is present, "sendrecv" SHOULD be assumed as the 1192 default for sessions which are not of the conference type 1193 "broadcast" or "H332" (see below). 1195 a=sendonly 1197 This specifies that the tools should be started in send-only 1198 mode. An example may be where a different unicast address is 1199 to be used for a traffic destination than for a traffic 1200 source. In such a case, two media descriptions may be use, 1201 one sendonly and one recvonly. It can be either a session or 1202 media attribute, but would normally only be used as a media 1203 attribute, and is not dependent on charset. Note that sendonly 1204 applies only to the media, and any associated control protocol 1205 (e.g. RTCP) SHOULD still be received and processed as normal. 1207 a=inactive 1209 This specifies that the tools should be started in inactive 1210 mode. This is necessary for interactive conferences where 1211 users can put other users on hold. No media is sent over an 1212 inactive media stream. Note that an RTP based system SHOULD 1213 still send RTCP, even if started inactive. It can be either a 1214 session or media attribute, and is not dependent on charset. 1216 a=orient: 1218 Normally this is only used in a whiteboard media specification. 1219 It specifies the orientation of a the whiteboard on the screen. 1220 It is a media attribute. Permitted values are "portrait", 1221 "landscape" and "seascape" (upside down landscape). It is not 1222 dependent on charset. 1224 a=type: 1226 This specifies the type of the conference. Suggested values 1227 are "broadcast", "meeting", "moderated", "test" and "H332". 1228 "recvonly" should be the default for "type:broadcast" 1229 sessions, "type:meeting" should imply "sendrecv" and 1230 "type:moderated" should indicate the use of a floor control 1231 tool and that the media tools are started so as to mute new 1232 sites joining the conference. 1234 Specifying the attribute "type:H332" indicates that this 1235 loosely coupled session is part of a H.332 session as defined 1236 in the ITU H.332 specification [15]. Media tools should be 1237 started "recvonly". 1239 Specifying the attribute "type:test" is suggested as a hint 1240 that, unless explicitly requested otherwise, receivers can 1241 safely avoid displaying this session description to users. 1243 The type attribute is a session-level attribute, and is not 1244 dependent on charset. 1246 a=charset: 1248 This specifies the character set to be used to display the 1249 session name and information data. By default, the ISO-10646 1250 character set in UTF-8 encoding is used. If a more compact 1251 representation is required, other character sets may be used. 1252 For example, the ISO 8859-1 is specified with the following 1253 SDP attribute: 1255 a=charset:ISO-8859-1 1257 This is a session-level attribute and is not dependent on 1258 charset. The charset specified MUST be one of those registered 1259 with IANA, such as ISO-8859-1. The character set identifier is 1260 a US-ASCII string and MUST be compared against the IANA 1261 identifiers using a case insensitive comparison. If the 1262 identifier is not recognised or not supported, all strings that 1263 are affected by it SHOULD be regarded as octet strings. 1265 Note that a character set specified MUST still prohibit the 1266 use of bytes 0x00 (Nul), 0x0A (LF) and 0x0d (CR). Character 1267 sets requiring the use of these characters MUST define a 1268 quoting mechanism that prevents these bytes appearing within 1269 text fields. 1271 a=sdplang: 1273 This can be a session level attribute or a media level 1274 attribute. As a session level attribute, it specifies the 1275 language for the session description. As a media level 1276 attribute, it specifies the language for any media-level SDP 1277 information field associated with that media. Multiple 1278 sdplang attributes can be provided either at session or media 1279 level if multiple languages in the session description or 1280 media use multiple languages, in which case the order of the 1281 attributes indicates the order of importance of the various 1282 languages in the session or media from most important to least 1283 important. 1285 In general, sending session descriptions consisting of 1286 multiple languages is discouraged. Instead, multiple 1287 descriptions SHOULD be sent describing the session, one in 1288 each language. However this is not possible with all 1289 transport mechanisms, and so multiple sdplang attributes are 1290 allowed although NOT RECOMMENDED. 1292 The "sdplang" attribute value must be a single RFC 3066 1293 language tag in US-ASCII [6]. It is not dependent on 1294 the charset attribute. An "sdplang" attribute SHOULD be 1295 specified when a session is of sufficient scope to cross 1296 geographic boundaries where the language of recipients cannot 1297 be assumed, or where the session is in a different language 1298 from the locally assumed norm. 1300 a=lang: 1302 This can be a session level attribute or a media level 1303 attribute. As a session level attribute, it specifies the 1304 default language for the session being described. As a media 1305 level attribute, it specifies the language for that media, 1306 overriding any session-level language specified. Multiple 1307 lang attributes can be provided either at session or media 1308 level if the session description or media use multiple 1309 languages, in which case the order of the attributes indicates 1310 the order of importance of the various languages in the 1311 session or media from most important to least important. 1313 The "lang" attribute value must be a single RFC 3066 language 1314 tag in US-ASCII [6]. It is not dependent on the charset 1315 attribute. A "lang" attribute SHOULD be specified when a 1316 session is of sufficient scope to cross geographic boundaries 1317 where the language of recipients cannot be assumed, or where 1318 the session is in a different language from the locally 1319 assumed norm. 1321 a=framerate: 1323 This gives the maximum video frame rate in frames/sec. It is 1324 intended as a recommendation for the encoding of video data. 1326 Decimal representations of fractional values using the 1327 notation "." are allowed. It is a 1328 media attribute, defined only for video media, and is not 1329 dependent on charset. 1331 a=quality: 1333 This gives a suggestion for the quality of the encoding as an 1334 integer value. The intention of the quality attribute for 1335 video is to specify a non-default trade-off between frame-rate 1336 and still-image quality. For video, the value in the range 0 1337 to 10, with the following suggested meaning: 1339 10 - the best still-image quality the compression scheme 1340 can give. 1341 5 - the default behaviour given no quality suggestion. 1342 0 - the worst still-image quality the codec designer 1343 thinks is still usable. 1345 It is a media attribute, and is not dependent on charset. 1347 a=fmtp: 1349 This attribute allows parameters that are specific to a 1350 particular format to be conveyed in a way that SDP doesn't 1351 have to understand them. The format must be one of the 1352 formats specified for the media. Format-specific parameters 1353 may be any set of parameters required to be conveyed by SDP 1354 and given unchanged to the media tool that will use this 1355 format. At most one instance of this attribute is allowed 1356 for each format. 1358 It is a media attribute, and is not dependent on charset. 1360 7. Communicating Conference Control Policy 1362 There is some debate over the way conference control policy should be 1363 communicated. In general, the authors believe that an implicit 1364 declarative style of specifying conference control is desirable where 1365 possible. 1367 A simple declarative style uses a single conference attribute field 1368 before the first media field, possibly supplemented by properties 1369 such as `recvonly' for some of the media tools. This conference 1370 attribute conveys the conference control policy. An example might 1371 be: 1373 a=type:moderated 1375 In some cases, however, it is possible that this may be insufficient 1376 to communicate the details of an unusual conference control policy. 1377 If this is the case, then a conference attribute specifying external 1378 control might be set, and then one or more "media" fields might be 1379 used to specify the conference control tools and configuration data 1380 for those tools. An example is an ITU H.332 session: 1382 ... 1383 c=IN IP4 224.5.6.7 1384 a=type:H332 1385 m=audio 49230 RTP/AVP 0 1386 m=video 49232 RTP/AVP 31 1387 m=application 12349 udp wb 1388 m=control 49234 H323 mc 1389 c=IN IP4 134.134.157.81 1391 In this example, a general conference attribute (type:H332) is 1392 specified stating that conference control will be provided by an 1393 external H.332 tool, and a contact addresses for the H.323 session 1394 multipoint controller is given. 1396 In this document, only the declarative style of conference control 1397 declaration is specified. Other forms of conference control should 1398 specify an appropriate type attribute, and should define the 1399 implications this has for control media. 1401 8. Security Considerations 1403 SDP is a session description format that describes multimedia 1404 sessions. A session description SHOULD NOT be trusted unless it has 1405 been obtained by an authenticated transport protocol from a trusted 1406 source. Many different transport protocols may be used to distribute 1407 session description, and the nature of the authentication will differ 1408 from transport to transport. 1410 One transport that will frequently be used to distribute session 1411 descriptions is the Session Announcement Protocol (SAP). SAP 1412 provides both encryption and authentication mechanisms but due to the 1413 nature of session announcements it is likely that there are many 1414 occasions where the originator of a session announcement cannot be 1415 authenticated because they are previously unknown to the receiver of 1416 the announcement and because no common public key infrastructure is 1417 available. 1419 On receiving a session description over an unauthenticated transport 1420 mechanism or from an untrusted party, software parsing the session 1421 should take a few precautions. Session descriptions contain 1422 information required to start software on the receivers system. 1423 Software that parses a session description MUST NOT be able to start 1424 other software except that which is specifically configured as 1425 appropriate software to participate in multimedia sessions. It is 1426 normally considered inappropriate for software parsing a session 1427 description to start, on a user's system, software that is 1428 appropriate to participate in multimedia sessions, without the user 1429 first being informed that such software will be started and giving 1430 their consent. Thus a session description arriving by session 1431 announcement, email, session invitation, or WWW page MUST NOT deliver 1432 the user into an interactive multimedia session unless the user has 1433 explicitly pre-authorized such action. As it is not always simple to 1434 tell whether a session is interactive or not, applications that are 1435 unsure should assume sessions are interactive. 1437 In this specification, there are no attributes which would allow the 1438 recipient of a session description to be informed to start multimedia 1439 tools in a mode where they default to transmitting. Under some 1440 circumstances it might be appropriate to define such attributes. If 1441 this is done an application parsing a session description containing 1442 such attributes SHOULD either ignore them, or inform the user that 1443 joining this session will result in the automatic transmission of 1444 multimedia data. The default behaviour for an unknown attribute is 1445 to ignore it. 1447 Session descriptions may be parsed at intermediate systems such as 1448 firewalls for the purposes of opening a hole in the firewall to allow 1449 the participation in multimedia sessions. It is considered 1450 inappropriate for a firewall to open such holes for unicast data 1451 streams unless the session description comes in a request from inside 1452 the firewall. For multicast sessions, it is likely that local 1453 administrators will apply their own policies, but the exclusive use 1454 of "local" or "site-local" administrative scope within the firewall 1455 and the refusal of the firewall to open a hole for such scopes will 1456 provide separation of global multicast sessions from local ones. 1458 Use of the "k=" field poses a significant security risk, since it 1459 conveys session encryption keys in the clear. SDP MUST NOT be used 1460 to convey key material, unless it can be guaranteed that the channel 1461 over which the SDP is delivered is both private and authenticated. 1463 9. IANA Considerations 1465 9.1 The "application/sdp" media type 1467 One MIME type is to be registered, as defined below. This updates the 1468 previous definition from RFC 2327. 1470 To: ietf-types@iana.org 1471 Subject: Registration of MIME media type application/sdp 1473 MIME media type name: application 1475 MIME subtype name: sdp 1477 Required parameters: None. 1479 Optional parameters: None. 1481 Encoding considerations: 1482 See section 5 of RFC XXXX 1484 Security considerations: 1485 See section 8 of RFC XXXX 1487 Interoperability considerations: 1488 See RFC XXXX 1490 Published specification: 1491 RFC XXXX 1493 Applications which use this media type: 1494 Voice over IP, video teleconferencing, streaming media, instant 1495 messaging, etc. See also section 3 of RFC XXXX. 1497 Additional information: 1499 Magic number(s): None. 1500 File extension(s): The extension ".sdp" is commonly used. 1501 Macintosh File Type Code(s): "sdp " 1503 Person & email address to contact for further information: 1504 Colin Perkins 1505 IETF MMUSIC working group 1507 Intended usage: COMMON 1509 Author/Change controller: 1510 Authors of RFC XXXX 1511 IETF MMUSIC working group 1513 9.2 Registration of Parameters 1515 There are seven field names that may be registered with IANA. Using 1516 the terminology in the SDP specification BNF, they are "media", 1517 "proto", "fmt", "att-field", "bwtype", "nettype" and "addrtype". 1519 9.2.1 Media types ("media") 1521 The set of media types is intended to be small and SHOULD NOT be 1522 extended except under rare circumstances. The same rules should 1523 apply for media names as for top-level MIME content types, and where 1524 possible the same name should be registered for SDP as for MIME. For 1525 media other than existing MIME top-level content types, a 1526 standards-track RFC MUST be produced for a new top-level content type 1527 to be registered, and the registration MUST provide good 1528 justification why no existing media name is appropriate (the 1529 "Standards Action" policy of RFC 2434 [5]. 1531 This memo registers the media types "audio", "video", "text", 1532 "application", "data" and "control". 1534 9.2.2 Transport protocols ("proto") 1536 The "proto" field describes the transport protocol used. This SHOULD 1537 reference a standards-track protocol RFC. This memo registers three 1538 values: "RTP/AVP" is a reference to RTP [12] used under the RTP 1539 Profile for Audio and Video Conferences with Minimal Control [13] 1540 running over UDP/IP, "RTP/SAVP" is a reference to the Secure 1541 Real-time Transport Protocol [15], and "udp" indicates an unspecified 1542 format over UDP. 1544 New transport protocols MAY be registered with IANA. Registrations 1545 MUST reference an RFC describing the protocol. Such an RFC MAY be 1546 Experimental or Informational, although it is preferable if it is 1547 Standards-Track. Registrations MUST also define the rules by which 1548 their "fmt" namespace is managed (see below). 1550 9.2.3 Media formats ("fmt") 1552 Each transport protocol, defined by the "proto" field, has an 1553 associated "fmt" namespace that describes the media formats which may 1554 conveyed by that protocol. Formats cover all the possible encodings 1555 that might want to be transported in a multimedia session. 1557 RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST 1558 use the payload type number as their "fmt" value. If the payload 1559 type number is dynamically assigned by this session description, an 1560 additional "rtpmap" attribute MUST be included to specify the format 1561 name and parameters as defined by the MIME type registration for the 1562 payload format. It is RECOMMENDED that other RTP profiles which are 1563 registered (in combination with RTP) as SDP transport protocols 1564 specify the same rules for the "fmt" namespace. 1566 For the "udp" protocol, new formats SHOULD be registered. Use of an 1567 existing MIME subtype for the format is encouraged. If no MIME 1568 subtype exists, it is RECOMMENDED that a suitable one is registered 1569 through the IETF process (RFC 2048) by production of, or reference 1570 to, a standards-track RFC. If a MIME subtype is for some reason 1571 inappropriate, an RFC publication describing the format MUST be 1572 referenced in the registration, but it may be Informational or 1573 Experimental if the protocol is not deemed to be of widespread 1574 deployment. 1576 For other protocols, formats MAY be registered according to the rules 1577 of the associated "proto" specification. 1579 Registrations of new formats MUST specify which transport protocols 1580 they apply to. 1582 9.2.4 Attribute names ("att-field") 1584 Attribute field names ("att-field") MUST be registered with IANA and 1585 documented, because of noticeable issues due to conflicting 1586 attributes under the same name. Unknown attributes in SDP are simply 1587 ignored, but conflicting ones that fragment the protocol are a 1588 serious problem. 1590 New attribute registerations are accepted according to the 1591 "Specification Required" policy of RFC 2434, provided that the 1592 specification includes the following information: 1593 o contact name, email address and telephone number 1594 o attribute-name (as it will appear in SDP) 1595 o long-form attribute name in English 1596 o type of attribute (session level, media level, or both) 1597 o whether the attribute value is subject to the charset attribute. 1598 o a one paragraph explanation of the purpose of the attribute. 1599 o a specification of appropriate attribute values for this 1600 attribute. 1602 The above is the minimum that IANA will accept. Attributes that are 1603 expected to see widespread use and interoperability, SHOULD be 1604 documented with a standards-track RFC that specifies the attribute 1605 more precisely. 1607 Submitters of registrations should ensure that the specification is 1608 in the spirit of SDP attributes, most notably that the attribute is 1609 platform independent in the sense that it makes no implicit 1610 assumptions about operating systems and does not name specific pieces 1611 of software in a manner that might inhibit interoperability. 1613 IANA is requested to register the following initial set of attribute 1614 names ("att-field" values), with definitions as in Section 6 of this 1615 memo (these definitions update those in RFC 2327): 1617 Name | Session or Media level? | Dependent on charset? 1618 ----------+-------------------------+---------------------- 1619 cat | Session | No 1620 keywds | Session | Yes 1621 tool | Session | No 1622 ptime | Media | No 1623 maxptime | Media | No 1624 rtpmap | Media | No 1625 recvonly | Either | No 1626 sendrecv | Either | No 1627 sendonly | Either | No 1628 inactive | Either | No 1629 orient | Media | No 1630 type | Session | No 1631 charset | Session | No 1632 sdplang | Either | No 1633 lang | Either | No 1634 framerate | Media | No 1635 quality | Media | No 1636 fmtp | Media | No 1638 9.2.5 Bandwidth specifiers ("bwtype") 1640 A proliferation of bandwidth specifiers is strongly discouraged. 1642 New bandwidth specifiers ("bwtype" fields) MUST be registered with 1643 IANA. The submission MUST reference a standards-track RFC specifying 1644 the semantics of the bandwidth specifier precisely, and indicating 1645 when it should be used, and why the existing registered bandwidth 1646 specifiers do not suffice. 1648 IANA is requested to register the bandwith specifiers "CT" and "AS" 1649 with definitions as in Section 5.8 of this memo (these definitions 1650 update those in RFC 2327). 1652 9.2.6 Network types ("nettype") 1654 New network types (the "nettype" field) may be registered with IANA 1655 if SDP needs to be used in the context of non-Internet environments. 1656 Whilst these are not normally the preserve of IANA, there may be 1657 circumstances when an Internet application needs to interoperate with 1658 a non- Internet application, such as when gatewaying an Internet 1659 telephony call into the PSTN. The number of network types should be 1660 small and should be rarely extended. A new network type cannot be 1661 registered without registering at least one address type to be used 1662 with that network type. A new network type registration MUST 1663 reference an RFC which gives details of the network type and address 1664 type and specifies how and when they would be used. Such an RFC MAY 1665 be Informational. 1667 IANA is requested to register the network type "IN" to represent the 1668 Internet, with definition as in Sections 5.2 and 5.7 of this memo 1669 (these definitions update those in RFC 2327). 1671 9.2.7 Address types ("addrtype") 1673 New address types ("addrtype") may be registered with IANA. An 1674 address type is only meaningful in the context of a network type, and 1675 any registration of an address type MUST specify a registered network 1676 type, or be submitted along with a network type registration. A new 1677 address type registration MUST reference an RFC giving details of the 1678 syntax of the address type. Such an RFC MAY be Informational. 1679 Address types are not expected to be registered frequently. 1681 IANA is requested to register the address types "IP4" and "IP6" with 1682 definitions as in Sections 5.2 and 5.7 of this memo (these 1683 definitions update those in RFC 2327). 1685 9.2.8 Registration Procedure 1687 In the RFC documentation that registers SDP "media", "proto", "fmt", 1688 "bwtype", "nettype" and "addrtype" fields, the authors MUST include 1689 the following information for IANA to place in the appropriate 1690 registry: 1691 o contact name, email address and telephone number 1692 o name being registered (as it will appear in SDP) 1693 o long-form name in English 1694 o type of name ("media", "proto", "fmt", "bwtype", "nettype", or 1695 "addrtype") 1696 o a one paragraph explanation of the purpose of the registered name. 1697 o a reference to the specification (e.g. RFC number) of the 1698 registered name. 1700 IANA may refer any registration to the IESG Transport Area Directors 1701 for review, and may request revisions to be made before a 1702 registration will be made. 1704 9.3 Encryption Key Access Methods 1706 The IANA currently maintains a table of SDP encryption key access 1707 method ("enckey") names. This table is obsolete and SHOULD be 1708 removed, since the "k=" line is not extensible. New registrations 1709 MUST NOT be accepted. 1711 Appendix A. SDP Grammar 1713 This appendix provides an Augmented BNF grammar for SDP. ABNF is 1714 defined in [2]. 1716 ; SDP Syntax 1717 session-description = proto-version 1718 origin-field 1719 session-name-field 1720 information-field 1721 uri-field 1722 email-fields 1723 phone-fields 1724 connection-field 1725 bandwidth-fields 1726 time-fields 1727 key-field 1728 attribute-fields 1729 media-descriptions 1731 proto-version = "v=" 1*DIGIT CRLF 1732 ;this memo describes version 0 1734 origin-field = "o=" username SP sess-id SP sess-version SP 1735 nettype SP addrtype SP unicast-address CRLF 1737 session-name-field = "s=" text CRLF 1739 information-field = ["i=" text CRLF] 1741 uri-field = ["u=" uri CRLF] 1743 email-fields = *("e=" email-address CRLF) 1745 phone-fields = *("p=" phone-number CRLF) 1747 connection-field = ["c=" nettype SP addrtype SP 1748 connection-address CRLF] 1749 ;a connection field must be present 1750 ;in every media description or at the 1751 ;session-level 1753 bandwidth-fields = *("b=" bwtype ":" bandwidth CRLF) 1755 time-fields = 1*( "t=" start-time SP stop-time 1756 *(CRLF repeat-fields) CRLF) 1757 [zone-adjustments CRLF] 1759 repeat-fields = "r=" repeat-interval SP typed-time 1760 1*(SP typed-time) 1762 zone-adjustments = "z=" time SP ["-"] typed-time 1763 *(SP time SP ["-"] typed-time) 1765 key-field = ["k=" key-type CRLF] 1767 attribute-fields = *("a=" attribute CRLF) 1769 media-descriptions = *( media-field 1770 information-field 1771 *connection-field 1772 bandwidth-fields 1773 key-field 1774 attribute-fields ) 1776 media-field = "m=" media SP port ["/" integer] 1777 SP proto 1*(SP fmt) CRLF 1779 ; sub-rules of 'o=' 1780 username = non-ws-string 1781 ;pretty wide definition, but doesn't 1782 ;include space 1784 sess-id = 1*DIGIT 1785 ;should be unique for this username/host 1787 sess-version = 1*DIGIT 1788 ;0 is a new session 1790 nettype = token 1791 ;typically "IN" 1793 addrtype = token 1794 ;typically "IP4" or "IP6" 1796 ; sub-rules of 'u=' 1797 uri = URI-reference; see RFC1630 and RFC2732 1799 ; sub-rules of 'e=' 1800 email-address = email *SP "(" 1*email-safe ")" / 1801 1*email-safe "<" email ">" / 1802 email 1804 email = addr-spec ; defined in RFC2822 1805 ; modified to remove CFWS 1807 ; sub-rules of 'p=' 1808 phone-number = phone *SP "(" 1*email-safe ")" / 1809 1*email-safe "<" phone ">" / 1810 phone 1812 phone = "+" POS-DIGIT 1*(SP / "-" / DIGIT) 1814 ; sub-rules of 'c=' 1815 connection-address = multicast-address / unicast-address 1817 ; sub-rules of 'b=' 1818 bwtype = token 1820 bandwidth = 1*DIGIT 1822 ; sub-rules of 't=' 1823 start-time = time / "0" 1825 stop-time = time / "0" 1827 time = POS-DIGIT 9*DIGIT 1828 ; 10-digit NTP time represents times between 1829 ; 1931 and 5068 AD. 9* allows times after 1830 ; that as well. 1832 ; sub-rules of 'r=' and 'z=' 1833 repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] 1835 typed-time = 1*DIGIT [fixed-len-time-unit] 1837 fixed-len-time-unit = "d" / "h" / "m" / "s" 1839 ; sub-rules of 'k=' 1840 key-type = "prompt" / 1841 "clear:" text / 1842 "base64:" base64 / 1843 "uri:" uri / 1844 key-method [ ":" text ] 1846 base64 = *base64-unit [base64-pad] 1847 base64-unit = 4base64-char 1848 base64-pad = 2base64-char "==" / 3base64-char "=" 1849 base64-char = ALPHA / DIGIT / "+" / "/" 1851 key-method = token 1852 ; sub-rules of 'a=' 1853 attribute = (att-field ":" att-value) / att-field 1855 att-field = token 1857 att-value = byte-string 1859 ; sub-rules of 'm=' 1860 media = token 1861 ;typically "audio", "video", "text", 1862 ;"application" or "data" 1864 fmt = token 1865 ;typically an RTP payload type for audio 1866 ;and video media 1868 proto = token *("/" token) 1869 ;typically "RTP/AVP" or "udp" 1871 port = 1*DIGIT 1872 ;should be either "0" or in the range "1024" 1873 ;to "65535" inclusive for UDP based media 1874 ;(a value of "0" is used to signal special 1875 ;conditions in some uses of SDP) 1877 ; generic sub-rules: addressing 1878 unicast-address = IP4-address / IP6-address / FQDN / extn-addr 1880 multicast-address = IP4-multicast / IP6-multicast 1882 IP4-multicast = m1 3( "." decimal-uchar ) 1883 "/" ttl [ "/" integer ] 1884 ; IPv4 multicast addresses may be in the 1885 ; range 224.0.0.0 to 239.255.255.255 1887 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / 1888 ("23" DIGIT ) 1890 IP6-multicast = hexpart [ "/" integer ] 1891 ; IPv6 address starting with FF 1893 ttl = (POS-DIGIT *2DIGIT) / "0" 1895 FQDN = 4*(alpha-numeric / "-" / ".") 1896 ; fully qualified domain name as specified 1897 ; in RFC1035 1899 IP4-address = b1 3("." decimal-uchar) / "0.0.0.0" 1900 b1 = decimal-uchar 1901 ; less than "224"; not "0" or "127" 1903 ; The following is from RFC2373 Appendix B. It is a direct copy. 1904 IP6-address = hexpart [ ":" IP4-address ] 1906 hexpart = hexseq / hexseq "::" [ hexseq ] / 1907 "::" [ hexseq ] 1909 hexseq = hex4 *( ":" hex4) 1911 hex4 = 1*4HEXDIG 1913 ; Generic for other address families 1914 extn-addr = non-ws-string 1916 ; generic sub-rules: datatypes 1917 text = byte-string 1918 ;default is to interpret this as UTF8 text. 1919 ;ISO 8859-1 requires "a=charset:ISO-8859-1" 1920 ;session-level attribute to be used 1922 byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) 1923 ;any byte except NUL, CR or LF 1925 non-ws-string = 1*(VCHAR/%x80-FF) 1926 ;string of visible characters 1928 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 1929 / %x41-5A / %x5E-7E 1931 token = 1*(token-char) 1933 email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF 1934 ;any byte except NUL, CR, LF, or the quoting 1935 ;characters ()<> 1937 integer = POS-DIGIT *DIGIT 1939 ; generic sub-rules: primitives 1940 alpha-numeric = ALPHA / DIGIT 1942 POS-DIGIT = %x31-39 ; 1 - 9 1944 decimal-uchar = DIGIT 1945 / POS-DIGIT DIGIT 1946 / ("1" 2*(DIGIT)) 1947 / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) 1948 / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) 1950 ; external references: 1951 ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 2234 1952 ; URI-reference: from RFC1630 and RFC2732 1953 ; addr-spec: from RFC 2822 1955 Appendix B. Acknowledgments 1957 Many people in the IETF MMUSIC working group have made comments and 1958 suggestions contributing to this document. In particular, we would 1959 like to thank Eve Schooler, Steve Casner, Bill Fenner, Allison 1960 Mankin, Ross Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, 1961 Steve Hanna, Jonathan Lennox and Keith Drage. 1963 10. References 1965 10.1 Normative References 1967 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1968 Levels", BCP 14, RFC 2119, March 1997. 1970 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1971 Specifications: ABNF", RFC 2234, November 1997. 1973 [3] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1974 2279, January 1998. 1976 [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource 1977 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 1979 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1980 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 1982 [6] Alvestrand, H., "Tags for the Identification of Languages", BCP 1983 47, RFC 3066, January 2001. 1985 10.2 Informative References 1987 [7] Mills, D., "Network Time Protocol (Version 3) Specification, 1988 Implementation", RFC 1305, March 1992. 1990 [8] Handley, M., Perkins, C. and E. Whelan, "Session Announcement 1991 Protocol", RFC 2974, October 2000. 1993 [9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1994 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1996 Session Initiation Protocol", RFC 3261, June 2002. 1998 [10] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 1999 Protocol (RTSP)", RFC 2326, April 1998. 2001 [11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2002 Session Description Protocol (SDP)", RFC 3264, June 2002. 2004 [12] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 2005 "RTP: A Transport Protocol for Real-Time Applications", RFC 2006 3550, July 2003. 2008 [13] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 2009 Conferences with Minimal Control", RFC 3551, July 2003. 2011 [14] Huitema, C., "Real Time Control Protocol (RTCP) attribute in 2012 Session Description Protocol (SDP)", RFC 3605, October 2003. 2014 [15] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K. 2015 Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 2016 3711, March 2004. 2018 [16] International Telecommunications Union, "H.323 extended for 2019 loosely coupled conferences", ITU Recommendation H.332, 2020 September 1998. 2022 [17] Arkko, J., "Key Management Extensions for Session Description 2023 Protocol (SDP) and Real Time Streaming Protocol (RTSP)", 2024 draft-ietf-mmusic-kmgmt-ext-09 (work in progress), October 2025 2003. 2027 [18] Andreasen, F., Baugher, M. and D. Wing, "SDP Security 2028 Descriptions for Media Streams", 2029 draft-ietf-mmusic-sdescriptions-02 (work in progress), October 2030 2003. 2032 Authors' Addresses 2034 Mark Handley 2035 University College London 2036 Gower Street 2037 London WC1E 6BT 2038 UK 2040 EMail: M.Handley@cs.ucl.ac.uk 2041 Van Jacobson 2042 Packet Design 2043 2465 Latham Street 2044 Mountain View, CA 94040 2045 USA 2047 EMail: van@packetdesign.com 2049 Colin Perkins 2050 University of Glasgow 2051 17 Lilybank Gardens 2052 Glasgow G12 8QQ 2053 UK 2055 EMail: csp@csperkins.org 2057 Intellectual Property Statement 2059 The IETF takes no position regarding the validity or scope of any 2060 Intellectual Property Rights or other rights that might be claimed to 2061 pertain to the implementation or use of the technology described in 2062 this document or the extent to which any license under such rights 2063 might or might not be available; nor does it represent that it has 2064 made any independent effort to identify any such rights. Information 2065 on the IETF's procedures with respect to rights in IETF Documents can 2066 be found in BCP 78 and BCP 79. 2068 Copies of IPR disclosures made to the IETF Secretariat and any 2069 assurances of licenses to be made available, or the result of an 2070 attempt made to obtain a general license or permission for the use of 2071 such proprietary rights by implementers or users of this 2072 specification can be obtained from the IETF on-line IPR repository at 2073 http://www.ietf.org/ipr. 2075 The IETF invites any interested party to bring to its attention any 2076 copyrights, patents or patent applications, or other proprietary 2077 rights that may cover technology that may be required to implement 2078 this standard. Please address the information to the IETF at 2079 ietf-ipr@ietf.org. 2081 Disclaimer of Validity 2083 This document and the information contained herein are provided on an 2084 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2085 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2086 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2087 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2088 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2089 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2091 Copyright Statement 2093 Copyright (C) The Internet Society (2004). This document is subject 2094 to the rights, licenses and restrictions contained in BCP 78, and 2095 except as set forth therein, the authors retain all their rights. 2097 Acknowledgment 2099 Funding for the RFC Editor function is currently provided by the 2100 Internet Society.