idnits 2.17.1 draft-ietf-mmusic-sdp-new-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of lines with control characters in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 12 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 -- The draft header indicates that this document obsoletes RFC3266, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC2327, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 569 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 (October 27, 2003) is 7484 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2279 (ref. '3') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2396 (ref. '4') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2434 (ref. '5') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3066 (ref. '6') (Obsoleted by RFC 4646, RFC 4647) -- Obsolete informational reference (is this intentional?): RFC 1305 (ref. '7') (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '10') (Obsoleted by RFC 7826) == Outdated reference: A later version (-15) exists of draft-ietf-mmusic-kmgmt-ext-09 == Outdated reference: A later version (-12) exists of draft-ietf-mmusic-sdescriptions-02 Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Handley 3 Internet-Draft UCL 4 Obsoletes: 2327, 3266 (if V. Jacobson 5 approved) Packet Design 6 Expires: April 26, 2004 C. Perkins 7 University of Glasgow 8 October 27, 2003 10 SDP: Session Description Protocol 11 draft-ietf-mmusic-sdp-new-15.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 26, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 This memo defines the Session Description Protocol (SDP). SDP is 42 intended for describing multimedia sessions for the purposes of 43 session announcement, session invitation, and other forms of 44 multimedia session initiation. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . 3 50 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . 4 51 3.1 Multicast Announcement . . . . . . . . . . . . . . . . . . . 4 52 3.2 Session Initiation . . . . . . . . . . . . . . . . . . . . . 4 53 3.3 Streaming media . . . . . . . . . . . . . . . . . . . . . . 4 54 3.4 Email and the World Wide Web . . . . . . . . . . . . . . . . 4 55 4. Requirements and Recommendations . . . . . . . . . . . . . . 5 56 4.1 Media Information . . . . . . . . . . . . . . . . . . . . . 6 57 4.2 Timing Information . . . . . . . . . . . . . . . . . . . . . 6 58 4.3 Private Sessions . . . . . . . . . . . . . . . . . . . . . . 7 59 4.4 Obtaining Further Information about a Session . . . . . . . 7 60 4.5 Categorisation . . . . . . . . . . . . . . . . . . . . . . . 7 61 4.6 Internationalization . . . . . . . . . . . . . . . . . . . . 7 62 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . 7 63 5.1 Protocol Version ("v=") . . . . . . . . . . . . . . . . . . 10 64 5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . . 10 65 5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . . . 11 66 5.4 Session and Media Information ("i=") . . . . . . . . . . . . 11 67 5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . . 12 69 5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . . 13 70 5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . . 15 71 5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . . 16 72 5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . . 17 73 5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . . . 18 74 5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . . . 18 75 5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . . . 20 76 5.14 Media Announcements ("m=") . . . . . . . . . . . . . . . . . 21 77 6. Suggested Attributes . . . . . . . . . . . . . . . . . . . . 24 78 7. Communicating Conference Control Policy . . . . . . . . . . 30 79 8. Security Considerations . . . . . . . . . . . . . . . . . . 30 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32 81 9.1 The "application/sdp" media type . . . . . . . . . . . . . . 32 82 9.2 Registration of Parameters . . . . . . . . . . . . . . . . . 33 83 A. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 36 84 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 41 85 Normative References . . . . . . . . . . . . . . . . . . . . 42 86 Informative References . . . . . . . . . . . . . . . . . . . 42 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 43 88 Intellectual Property and Copyright Statements . . . . . . . 44 90 1. Introduction 92 [Note to RFC Editor: All references to RFC XXXX should be replaced by 93 the RFC number of this document, when published.] 95 When initiating multimedia teleconferences, voice-over-IP calls, 96 streaming video, or other real-time sessions, there is a requirement 97 to convey media details, transport addresses, and other session 98 description metadata to the participants. 100 SDP provides a standard representation for such information, 101 irrespective of how that information is transported. SDP is purely a 102 format for session description - it does not incorporate a transport 103 protocol, and is intended to use different transport protocols as 104 appropriate, including the Session Announcement Protocol [8], Session 105 Initiation Protocol [9], Real-Time Streaming Protocol [10], 106 electronic mail using the MIME extensions, and the Hypertext 107 Transport Protocol. 109 SDP is intended to be general purpose so that it can be used in a 110 wide range of network environments and applications. However, it is 111 not intended to support negotiation of session content or media 112 encodings: this is viewed as outside the scope of session 113 description. 115 2. Glossary of Terms 117 The following terms are used in this document, and have specific 118 meaning within the context of this document. 120 Conference: A multimedia conference is a set of two or more 121 communicating users along with the software they are using to 122 communicate. 124 Session: A multimedia session is a set of multimedia senders and 125 receivers and the data streams flowing from senders to receivers. 126 A multimedia conference is an example of a multimedia session. 128 Session Advertisement: See session announcement. 130 Session Announcement: A session announcement is a mechanism by which 131 a session description is conveyed to users in a pro-active 132 fashion, i.e., the session description was not explicitly 133 requested by the user. 135 Session Description: A well defined format for conveying sufficient 136 information to discover and participate in a multimedia session. 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [1]. 142 3. Examples of SDP Usage 144 3.1 Multicast Announcement 146 In order to assist the advertisement of multicast multimedia 147 conferences and other multicast sessions, and to communicate the 148 relevant session setup information to prospective participants, a 149 distributed session directory may be used. An instance of such a 150 session directory periodically sends packets containing a description 151 of the session to a well known multicast group. These advertisements 152 are received by other session directories such that potential remote 153 participants can use the session description to start the tools 154 required to participate in the session. 156 One protocol commonly used to implement such a distributed directory 157 is the Session Announcement Protocol, SAP [8]. SDP provides the 158 recommended session description format for such announcements. 160 3.2 Session Initiation 162 The Session Initiation Protocol, SIP [9] is an application layer 163 control protocol for creating, modifying and terminating sessions 164 such as Internet multimedia conferences, Internet telephone calls and 165 multimedia distribution. The SIP messages used to create sessions 166 carry session descriptions which allow participants to agree on a set 167 of compatible media types. These session descriptions are commonly 168 formatted using SDP. When used with SIP, the offer/answer model [11] 169 provides a limited framework for negotiation using SDP. 171 3.3 Streaming media 173 The Real Time Streaming Protocol, RTSP [10], is an application- level 174 protocol for control over the delivery of data with real-time 175 properties. RTSP provides an extensible framework to enable 176 controlled, on-demand delivery of real-time data, such as audio and 177 video. An RTSP client and server negotiate an appropriate set of 178 parameters for media delivery, partially using SDP syntax to describe 179 those parameters. 181 3.4 Email and the World Wide Web 183 Alternative means of conveying session descriptions include 184 electronic mail and the World Wide Web. For both email and WWW 185 distribution, the use of the MIME content type "application/sdp" MUST 186 be used. This enables the automatic launching of applications for 187 participation in the session from the WWW client or mail reader in a 188 standard manner. 190 Note that announcements of multicast sessions made only via email or 191 the World Wide Web (WWW) do not have the property that the receiver 192 of a session announcement can necessarily receive the session because 193 the multicast sessions may be restricted in scope, and access to the 194 WWW server or reception of email is possible outside this scope. SAP 195 announcements do not suffer from this mismatch. 197 4. Requirements and Recommendations 199 The purpose of SDP is to convey information about media streams in 200 multimedia sessions to allow the recipients of a session description 201 to participate in the session. SDP is primarily intended for use in 202 an internetwork, although it is sufficiently general that it can 203 describe conferences in other network environments. 205 A multimedia session, for these purposes, is defined as a set of 206 media streams that exist for some duration of time. Media streams 207 can be many-to-many. The times during which the session is active 208 need not be continuous. 210 Thus far, multicast based sessions on the Internet have differed from 211 many other forms of conferencing in that anyone receiving the traffic 212 can join the session (unless the session traffic is encrypted). In 213 such an environment, SDP serves two primary purposes. It is a means 214 to communicate the existence of a session, and is a means to convey 215 sufficient information to enable joining and participating in the 216 session. In a unicast environment, only the latter purpose is likely 217 to be relevant. 219 Thus SDP includes: 221 o Session name and purpose 223 o Time(s) the session is active 225 o The media comprising the session 227 o Information needed to receive those media (addresses, ports, 228 formats and so on) 230 As resources necessary to participate in a session may be limited, 231 some additional information may also be desirable: 233 o Information about the bandwidth to be used by the conference 234 o Contact information for the person responsible for the session 236 In general, SDP must convey sufficient information to enable 237 applications to join a session (with the possible exception of 238 encryption keys) and to announce the resources to be used to non- 239 participants that may need to know. 241 4.1 Media Information 243 SDP includes: 245 o The type of media (video, audio, etc) 247 o The transport protocol (RTP/UDP/IP, H.320, etc) 249 o The format of the media (H.261 video, MPEG video, etc) 251 For an IP multicast session, the following are also conveyed: 253 o Multicast address for media 255 o Transport port for media 257 This address and port are the destination address and destination 258 port of the multicast stream, whether being sent, received, or both. 260 For an IP unicast session, the following are conveyed: 262 o Remote address for media 264 o Transport port for media 266 The semantics of this address and port depend on the media and 267 transport protocol defined. By default, this is the remote address 268 and remote port to which data is sent, however some media types may 269 redefine this behaviour. 271 4.2 Timing Information 273 Sessions may either be bounded or unbounded in time. Whether or not 274 they are bounded, they may be only active at specific times. 276 SDP can convey: 278 o An arbitrary list of start and stop times bounding the session 280 o For each bound, repeat times such as "every Wednesday at 10am for 281 one hour" 283 This timing information is globally consistent, irrespective of local 284 time zone or daylight saving time. 286 4.3 Private Sessions 288 It is possible to create both public sessions and private sessions. 289 SDP itself does not distinguish between these: private sessions are 290 typically conveyed by encrypting the session description during 291 distribution. The details of how encryption is performed are 292 dependent on the mechanism used to convey SDP - e.g. mechanisms are 293 defined for SDP transported using SAP [8] and SIP [9]. 295 If a session announcement is private it is possible to use that 296 private announcement to convey encryption keys necessary to decode 297 each of the media in a conference, including enough information to 298 know which encryption scheme is used for each media. 300 4.4 Obtaining Further Information about a Session 302 A session description should convey enough information to decide 303 whether or not to participate in a session. SDP may include 304 additional pointers in the form of Universal Resources Identifiers 305 (URIs) for more information about the session. 307 4.5 Categorisation 309 When many session descriptions are being distributed by SAP, or any 310 other advertisement mechanism, it may be desirable to filter 311 announcements that are of interest from those that are not. SDP 312 supports a categorisation mechanism for sessions that is capable of 313 being automated. 315 4.6 Internationalization 317 The SDP specification recommends the use of the ISO 10646 character 318 sets in the UTF-8 encoding [3] to allow many different languages to 319 be represented. However, to assist in compact representations, SDP 320 also allows other character sets such as ISO 8859-1 to be used when 321 desired. Internationalization only applies to free-text fields 322 (session name and background information), and not to SDP as a whole. 324 5. SDP Specification 326 SDP session descriptions are entirely textual using the ISO 10646 327 character set in UTF-8 encoding. SDP field names and attribute names 328 use only the US-ASCII subset of UTF-8, but textual fields and 329 attribute values MAY use the full ISO 10646 character set. Field and 330 attribute values which use the full UTF-8 character set are never 331 directly compared, hence there is no requirement for UTF-8 332 normalization. The textual form, as opposed to a binary encoding 333 such as ASN.1 or XDR, was chosen to enhance portability, to enable a 334 variety of transports to be used (e.g, session description in a MIME 335 email message) and to allow flexible, text-based toolkits (e.g., Tcl/ 336 Tk) to be used to generate and to process session descriptions. 337 However, since SDP may be used in environments where the maximum 338 permissable size of a session description is limited (e.g. SAP 339 announcements; SIP transported in UDP), the encoding is deliberately 340 compact. Also, since announcements may be transported via very 341 unreliable means or damaged by an intermediate caching server, the 342 encoding was designed with strict order and formatting rules so that 343 most errors would result in malformed announcements which could be 344 detected easily and discarded. This also allows rapid discarding of 345 encrypted announcements for which a receiver does not have the 346 correct key. 348 An SDP session description may contain URIs which reference external 349 content in the "u=", "k=" and "a=" lines. These URIs may be 350 dereferenced in some cases, making the session description non-self 351 contained. 353 An SDP session description consists of a number of lines of text of 354 the form: 356 = 358 where MUST be exactly one case-significant character and 359 is structured text whose format depends on . In 360 general is either a number of fields delimited by a single 361 space character, or a free format string. Whitespace MUST NOT be used 362 either side of the "=" sign. 364 A session description consists of a session-level section followed by 365 zero or more media-level sections. The session-level part starts 366 with a "v=" line and continues to the first media-level section. The 367 media description starts with an "m=" line and continues to the next 368 media description or end of the whole session description. In 369 general, session-level values are the default for all media unless 370 overridden by an equivalent media-level value. 372 Some lines in each description are REQUIRED and some are OPTIONAL but 373 all MUST appear in exactly the order given here (the fixed order 374 greatly enhances error detection and allows for a simple parser). 375 OPTIONAL items are marked with a "*". 377 Session description 378 v= (protocol version) 379 o= (owner/creator and session identifier). 380 s= (session name) 381 i=* (session information) 382 u=* (URI of description) 383 e=* (email address) 384 p=* (phone number) 385 c=* (connection information - not required if included in 386 all media) 387 b=* (zero or more bandwidth information lines) 388 One or more time descriptions (see below) 389 z=* (time zone adjustments) 390 k=* (encryption key) 391 a=* (zero or more session attribute lines) 392 Zero or more media descriptions (see below) 394 Time description 395 t= (time the session is active) 396 r=* (zero or more repeat times) 398 Media description 399 m= (media name and transport address) 400 i=* (media title) 401 c=* (connection information - optional if included at 402 session-level) 403 b=* (zero or more bandwidth information lines) 404 k=* (encryption key) 405 a=* (zero or more media attribute lines) 407 The set of type letters is deliberately small and not intended to be 408 extensible -- an SDP parser MUST completely ignore any announcement 409 that contains a type letter that it does not understand. The 410 attribute mechanism ("a=" described below) is the primary means for 411 extending SDP and tailoring it to particular applications or media. 412 Some attributes (the ones listed in this document) have a defined 413 meaning but others may be added on an application-, media- or 414 session-specific basis. An SDP parser MUST ignore any attribute it 415 doesn't understand. 417 The connection ("c=") and attribute ("a=") information in the 418 session-level section applies to all the media of that session unless 419 overridden by connection information or an attribute of the same name 420 in the media description. For instance, in the example below, each 421 media behaves as if it were given a "recvonly" attribute. 423 An example SDP description is: 425 v=0 426 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 427 s=SDP Seminar 428 i=A Seminar on the session description protocol 429 u=http://www.example.com/seminars/sdp.pdf 430 e=j.doe@example.com (Jane Doe) 431 c=IN IP4 224.2.17.12/127 432 t=2873397496 2873404696 433 a=recvonly 434 m=audio 49170 RTP/AVP 0 435 m=video 51372 RTP/AVP 31 436 m=application 32416 udp wb 437 a=orient:portrait 439 Text records such as the session name and information are octet 440 strings which may contain any octet with the exceptions of 0x00 441 (Nul), 0x0a (ASCII newline) and 0x0d (ASCII carriage return). The 442 sequence CRLF (0x0d0a) is used to end a record, although parsers 443 SHOULD be tolerant and also accept records terminated with a single 444 newline character. By default these byte strings contain ISO-10646 445 characters in UTF-8 encoding, but this default MAY be changed using 446 the "charset" attribute. 448 5.1 Protocol Version ("v=") 450 v=0 452 The "v=" field gives the version of the Session Description Protocol. 453 There is no minor version number. 455 5.2 Origin ("o=") 457 o=
458
460 The "o=" field gives the originator of the session (her username and 461 the address of the user's host) plus a session id and session version 462 number. 464 is the user's login on the originating host, or it is "-" 465 if the originating host does not support the concept of user ids. 466 MUST NOT contain spaces. 468 is a numeric string such that the tuple of , 469 , ,
and
form a 470 globally unique identifier for the session. The method of session 471 id allocation is up to the creating tool, but it has been 472 suggested that a Network Time Protocol (NTP) format timestamp be 473 used to ensure uniqueness [7]. 475 is a version number for this announcement. It is needed for 476 proxy announcements to detect which of several announcements for 477 the same session is the most recent. Again its usage is up to the 478 creating tool, so long as is increased when a 479 modification is made to the session data. Again, it is RECOMMENDED 480 (but not mandatory) that an NTP format timestamp is used. 482 is a text string giving the type of network. 483 Initially "IN" is defined to have the meaning "Internet". 485
is a text string giving the type of the address that 486 follows. Initially "IP4" and "IP6" are defined. 488
is the globally unique address of the machine from which 489 the session was created. For an address type of IP4, this is 490 either the fully-qualified domain name of the machine, or the 491 dotted-decimal representation of the IP version 4 address of the 492 machine. For an address type of IP6, this is either the 493 fully-qualified domain name of the machine, or the compressed 494 textual representation of the IP version 6 address of the machine. 495 For both IP4 and IP6, the fully-qualified domain name is the form 496 that SHOULD be given unless this is unavailable, in which case the 497 globally unique address may be substituted. A local IP address 498 MUST NOT be used in any context where the SDP description might 499 leave the scope in which the address is meaningful. 501 In general, the "o=" field serves as a globally unique identifier for 502 this version of this session description, and the subfields excepting 503 the version taken together identify the session irrespective of any 504 modifications. 506 5.3 Session Name ("s=") 508 s= 510 The "s=" field is the session name. There MUST be one and only one 511 "s=" field per session description. The "s=" field MUST NOT be empty 512 and SHOULD contain ISO 10646 characters (but see also the "a=charset" 513 attribute). If a session has no meaningful name, the value "s= " 514 SHOULD be used (i.e. a single space as the session name). 516 5.4 Session and Media Information ("i=") 518 i= 520 The "i=" field is information about the session. There may be at 521 most one session-level "i=" field per session description, and at 522 most one "i=" field per media. Although it may be omitted, this is 523 NOT RECOMMENDED for session announcements, and user interfaces for 524 composing sessions should require text to be entered. If it is 525 present it must contain ISO 10646 characters (but see also the 526 "a=charset" attribute below). 528 A single "i=" field can also be used for each media definition. In 529 media definitions, "i=" fields are primarily intended for labeling 530 media streams. As such, they are most likely to be useful when a 531 single session has more than one distinct media stream of the same 532 media type. An example would be two different whiteboards, one for 533 slides and one for feedback and questions. 535 5.5 URI ("u=") 537 u= 539 A URI is a Universal Resource Identifier as used by WWW clients [4]. 540 The URI should be a pointer to additional information about the 541 conference. This field is OPTIONAL, but if it is present it MUST be 542 specified before the first media field. No more than one URI field is 543 allowed per session description. 545 5.6 Email Address and Phone Number ("e=" and "p=") 547 e= 548 p= 550 These specify contact information for the person responsible for the 551 conference. This is not necessarily the same person that created the 552 conference announcement. 554 Inclusion of an email address or phone number is OPTIONAL. Note that 555 the previous version of SDP specified that either an email field or a 556 phone field MUST be specified, but this was widely ignored. The 557 change brings the specification into line with common usage. 559 If the email addres or phone number are present, they MUST be 560 specified before the first media field. More than one email or phone 561 field can be given for a session description. 563 Phone numbers SHOULD be given in the conventional international 564 format: preceded by a "+" and the international country code. There 565 must be a space or a hyphen ("-") between the country code and the 566 rest of the phone number. Spaces and hyphens may be used to split up 567 a phone field to aid readability if desired. For example: 569 p=+44-171-380-7777 or p=+1 617 555 6011 571 Both email addresses and phone numbers can have an optional free text 572 string associated with them, normally giving the name of the person 573 who may be contacted. This should be enclosed in parenthesis if it 574 is present. For example: 576 e=j.doe@example.com (Jane Doe) 578 The alternative RFC822 name quoting convention is also allowed for 579 both email addresses and phone numbers. For example: 581 e=Jane Doe 583 The free text string SHOULD be in the ISO-10646 character set with 584 UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if 585 the appropriate charset session-level attribute is set. 587 5.7 Connection Data ("c=") 589 c=
591 The "c=" field contains connection data. 593 A session announcement MUST contain either at least one "c=" field in 594 each media description (see below) or a single "c=" field at the 595 session-level. It MAY contain a single session-level "c=" field and 596 additional "c=" field(s) per media description, in which case the 597 per-media values override the session-level settings for the 598 respective media. 600 The first sub-field is the network type, which is a text string 601 giving the type of network. Initially "IN" is defined to have the 602 meaning "Internet". 604 The second sub-field is the address type. This allows SDP to be used 605 for sessions that are not IP based. Currently only IP4 and IP6 are 606 defined. 608 The third sub-field is the connection address. Optional extra 609 sub-fields MAY be added after the connection address depending on the 610 value of the
field. 612 For IP4 and IP6 addresses, the connection address is defined as 613 follows: 615 o If the session is multicast, the connection address will be an IP 616 multicast group address. If the session is not multicast, then 617 the connection address contains the unicast IP address of the 618 expected data source or data relay or data sink as determined by 619 additional attribute fields. It is not expected that unicast 620 addresses will be given in a session description that is 621 communicated by a multicast announcement, though this is not 622 prohibited. 624 o Conferences using an IPv4 multicast connection address MUST also 625 have a time to live (TTL) value present in addition to the 626 multicast address. The TTL and the address together define the 627 scope with which multicast packets sent in this conference will be 628 sent. TTL values MUST be in the range 0-255. 630 The TTL for the session is appended to the address using a slash as a 631 separator. An example is: 633 c=IN IP4 224.2.36.42/127 635 IPv6 multicast does not use TTL scoping, and hence the TTL value MUST 636 NOT be present for IPv6 multicast. It is expected that IPv6 scoped 637 addresses will be used to limit the scope of conferences. 639 Hierarchical or layered encoding schemes are data streams where the 640 encoding from a single media source is split into a number of layers. 641 The receiver can choose the desired quality (and hence bandwidth) by 642 only subscribing to a subset of these layers. Such layered encodings 643 are normally transmitted in multiple multicast groups to allow 644 multicast pruning. This technique keeps unwanted traffic from sites 645 only requiring certain levels of the hierarchy. For applications 646 requiring multiple multicast groups, we allow the following notation 647 to be used for the connection address: 649 [/]/ 651 If the number of addresses is not given it is assumed to be one. 652 Multicast addresses so assigned are contiguously allocated above the 653 base address, so that, for example: 655 c=IN IP4 224.2.1.1/127/3 657 would state that addresses 224.2.1.1, 224.2.1.2 and 224.2.1.3 are to 658 be used at a ttl of 127. This is semantically identical to including 659 multiple "c=" lines in a media description: 661 c=IN IP4 224.2.1.1/127 662 c=IN IP4 224.2.1.2/127 663 c=IN IP4 224.2.1.3/127 665 Similarly, an IPv6 example would be: 667 c=IN IP6 FF15::101/3 669 which is semantically equivalent to: 671 c=IN IP6 FF15::101 672 c=IN IP6 FF15::102 673 c=IN IP6 FF15::103 675 (remembering that the TTL field is not present in IPv6 multicast). 677 Multiple addresses or "c=" lines MAY be specified on a per-media 678 basis only if they provide multicast addresses for different layers 679 in a hierarchical or layered encoding scheme. They MUST NOT be 680 specified for a session-level "c=" field. 682 The slash notation described above MUST NOT be used for IP unicast 683 addresses. 685 5.8 Bandwidth ("b=") 687 b=: 689 This specifies the proposed bandwidth to be used by the session or 690 media, and is OPTIONAL. 692 The is in kilobits per second by default. Modifiers 693 MAY specify that alternative units are to be used (the modifiers 694 defined in this memo use the default units). 696 The is a single alphanumeric word giving the meaning of 697 the bandwidth figure. Two modifiers are initially defined: 699 CT If the bandwidth of a session or media in a session is different 700 from the bandwidth implicit from the scope, a "b=CT:..." line 701 should be supplied for the session giving the proposed upper limit 702 to the bandwidth used. The primary purpose of this is to give an 703 approximate idea as to whether two or more sessions can co-exist 704 simultaneously. When using the CT modifier with RTP, if several 705 RTP sessions are part of the conference, the conference total 706 refers to total bandwidth of all RTP sessions. 708 AS The bandwidth is interpreted to be application-specific (it will 709 be the application's concept of maximum bandwidth). Normally this 710 will coincide with what is set on the application's "maximum 711 bandwidth" control if applicable. For RTP based applications, AS 712 gives the RTP "session bandwidth" as defined in section 6.2 of 713 [12]. 715 Note that CT gives a total bandwidth figure for all the media at all 716 sites. AS gives a bandwidth figure for a single media at a single 717 site, although there may be many sites sending simultaneously. 719 Tool writers MAY define experimental bandwidth modifiers by prefixing 720 their modifier with "X-". For example: 722 b=X-YZ:128 724 Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers 725 SHOULD be registered with IANA in the standard namespace. SDP parsers 726 MUST ignore bandwidth fields with unknown modifiers. Modifiers MUST 727 be alpha-numeric and, although no length limit is given, they are 728 recommended to be short. 730 5.9 Timing ("t=") 732 t= 734 "t=" fields specify the start and stop times for a session. Multiple 735 "t=" fields MAY be used if a session is active at multiple 736 irregularly spaced times; each additional "t=" field specifies an 737 additional period of time for which the session will be active. If 738 the session is active at regular times, an "r=" field (see below) 739 should be used in addition to and following a "t=" field - in which 740 case the "t=" field specifies the start and stop times of the repeat 741 sequence. 743 The first and second sub-fields give the start and stop times for the 744 session respectively. These values are the decimal representation of 745 Network Time Protocol (NTP) time values in seconds [7]. To convert 746 these values to UNIX time, subtract decimal 2208988800. 748 NTP timestamps are 64 bit values which wrap sometime in the year 749 2036. Since SDP uses an arbitrary length decimal representation, 750 this should not cause an issue (SDP timestamps will continue counting 751 seconds since 1900, NTP will use the value modulo the 64 bit limit). 753 If the stop-time is set to zero, then the session is not bounded, 754 though it will not become active until after the start-time. If the 755 start-time is also zero, the session is regarded as permanent. 757 User interfaces SHOULD strongly discourage the creation of unbounded 758 and permanent sessions as they give no information about when the 759 session is actually going to terminate, and so make scheduling 760 difficult. 762 The general assumption may be made, when displaying unbounded 763 sessions that have not timed out to the user, that an unbounded 764 session will only be active until half an hour from the current time 765 or the session start time, whichever is the later. If behaviour 766 other than this is required, an end-time should be given and modified 767 as appropriate when new information becomes available about when the 768 session should really end. 770 Permanent sessions may be shown to the user as never being active 771 unless there are associated repeat times which state precisely when 772 the session will be active. In general, permanent sessions SHOULD 773 NOT be created for any session expected to have a duration of less 774 than 2 months, and should be discouraged for sessions expected to 775 have a duration of less than 6 months. 777 5.10 Repeat Times ("r=") 779 r= 781 "r=" fields specify repeat times for a session. For example, if a 782 session is active at 10am on Monday and 11am on Tuesday for one hour 783 each week for three months, then the in the 784 corresponding "t=" field would be the NTP representation of 10am on 785 the first Monday, the would be 1 week, the would be 1 hour, and the offsets would be zero and 25 787 hours. The corresponding "t=" field stop time would be the NTP 788 representation of the end of the last session three months later. By 789 default all fields are in seconds, so the "r=" and "t=" fields might 790 be: 792 t=3034423619 3042462419 793 r=604800 3600 0 90000 795 To make description more compact, times may also be given in units of 796 days, hours or minutes. The syntax for these is a number immediately 797 followed by a single case-sensitive character. Fractional units are 798 not allowed - a smaller unit should be used instead. The following 799 unit specification characters are allowed: 801 d - days (86400 seconds) 802 h - hours (3600 seconds) 803 m - minutes (60 seconds) 804 s - seconds (allowed for completeness but not recommended) 806 Thus, the above announcement could also have been written: 808 r=7d 1h 0 25h 810 Monthly and yearly repeats cannot be directly specified with a single 811 SDP repeat time - instead separate "t=" fields should be used to 812 explicitly list the session times. 814 5.11 Time Zones ("z=") 816 z= .... 818 To schedule a repeated session which spans a change from daylight- 819 saving time to standard time or vice-versa, it is necessary to 820 specify offsets from the base time. This is required because 821 different time zones change time at different times of day, different 822 countries change to or from daylight time on different dates, and 823 some countries do not have daylight saving time at all. 825 Thus in order to schedule a session that is at the same time winter 826 and summer, it must be possible to specify unambiguously by whose 827 time zone a session is scheduled. To simplify this task for 828 receivers, we allow the sender to specify the NTP time that a time 829 zone adjustment happens and the offset from the time when the session 830 was first scheduled. The "z=" field allows the sender to specify a 831 list of these adjustment times and offsets from the base time. 833 An example might be: 835 z=2882844526 -1h 2898848070 0 837 This specifies that at time 2882844526 the time base by which the 838 session's repeat times are calculated is shifted back by 1 hour, and 839 that at time 2898848070 the session's original time base is restored. 840 Adjustments are always relative to the specified start time - they 841 are not cumulative. Adjustments apply to all "t=" and "r=" lines in 842 a session description. 844 If a session is likely to last several years, it is expected that the 845 session announcement will be modified periodically rather than 846 transmit several years worth of adjustments in one announcement. 848 5.12 Encryption Keys ("k=") 850 k= 851 k=: 853 If transported over a secure and trusted channel, the session 854 description protocol MAY be used to convey encryption keys. A simple 855 mechanism for key exchange is provided by the key field ("k=") 856 although this is primarily supported for compatibility with older 857 implementations and its use is NOT RECOMMENDED. Work is in progress 858 to define new key exchange mechanisms for use with SDP [17][16] and 859 it is expected that new applications will use those mechanisms. 861 A key field is permitted before the first media entry (in which case 862 it applies to all media in the session), or for each media entry as 863 required. The format of keys and their usage is outside the scope of 864 this document, and the key field provides no way to indicate the 865 encryption algorithm to be used, key type, or other information about 866 the key: this is assumed to be provided by the higher-level protocol 867 using SDP. If there is a need to convey this information within SDP, 868 the extensions mentioned previously SHOULD be used. Many security 869 protocols require two keys, one for confidentiality and another for 870 integrity. This specification does not support the transfer of two 871 keys. 873 The method indicates the mechanism to be used to obtain a usable key 874 by external means, or from the encoded encryption key given. The 875 following methods are defined: 877 k=clear: 879 The encryption key is included untransformed in this key field. 880 This method MUST NOT be used unless it can be guaranteed that 881 the SDP is conveyed over a secure channel. 883 k=base64: 885 The encryption key is included in this key field but has been 886 base64 encoded because it includes characters that are 887 prohibited in SDP. This method MUST NOT be used unless it can 888 be guaranteed that the SDP is conveyed over a secure channel. 890 k=uri: 892 A Universal Resource Identifier is included in the key field. 893 The URI refers to the data containing the key, and may require 894 additional authentication before the key can be returned. When 895 a request is made to the given URI, the reply should specify 896 the encoding for the key. The URI is often a secure HTTP URI, 897 although this is not required. 899 k=prompt 901 No key is included in this SDP description, but the session or 902 media stream referred to by this key field is encrypted. The 903 user should be prompted for the key when attempting to join the 904 session, and this user-supplied key should then be used to 905 decrypt the media streams. The use of user-specified keys is 906 NOT RECOMMENDED, since such keys tend to have weak security 907 properties. 909 The key field MUST NOT be used unless it can be guaranteed that the 910 SDP is conveyed over a secure and trusted channel. An example of such 911 a channel might be SDP embedded inside an S/MIME message or a TLS 912 protected HTTP or SIP session. It is important to ensure that the 913 secure channel is with the party that is authorized to join the 914 session, not an intermediary: if a caching proxy server is used, it 915 is important to ensure that the proxy is either trusted or unable to 916 access the SDP. Definition of appropriate security measures is beyond 917 the scope of this specification, and should be defined by the users 918 of SDP. 920 5.13 Attributes ("a=") 922 a= 923 a=: 925 Attributes are the primary means for extending SDP. Attributes may 926 be defined to be used as "session-level" attributes, "media-level" 927 attributes, or both. 929 A media description may have any number of attributes ("a=" fields) 930 which are media specific. These are referred to as "media-level" 931 attributes and add information about the media stream. Attribute 932 fields can also be added before the first media field; these 933 "session-level" attributes convey additional information that applies 934 to the conference as a whole rather than to individual media; an 935 example might be the conference's floor control policy. 937 Attribute fields may be of two forms: 939 o property attributes: 940 A property attribute is simply of the form "a=". 941 These are binary attributes, and the presence of the 942 attribute conveys that the attribute is a property of 943 the session. An example might be "a=recvonly". 945 o value attributes: 946 A value attribute is of the form "a=:". 947 For example, a whiteboard could have the value attribute 948 "a=orient:landscape" 950 Attribute interpretation depends on the media tool being invoked. 951 Thus receivers of session descriptions should be configurable in 952 their interpretation of announcements in general and of attributes in 953 particular. 955 Attribute names MUST be in the US-ASCII subset of ISO-10646/UTF-8. 957 Attribute values are octet strings, and MAY use any octet value 958 except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute 959 values are to be interpreted as in ISO-10646 character set with UTF-8 960 encoding. Unlike other text fields, attribute values are NOT 961 normally affected by the "charset" attribute as this would make 962 comparisons against known values problematic. However, when an 963 attribute is defined, it can be defined to be charset-dependent, in 964 which case it's value should be interpreted in the session charset 965 rather than in ISO-10646. 967 Attributes MUST be registered with IANA (see Section 9). If an 968 attribute is received that is not understood, it MUST be ignored by 969 the receiver. 971 5.14 Media Announcements ("m=") 973 m= 975 A session description may contain a number of media descriptions. 976 Each media description starts with an "m=" field, and is terminated 977 by either the next "m=" field or by the end of the session 978 description. A media field has several sub-fields. 980 The first sub-field is the media type. Currently defined media are 981 "audio", "video", "application", "data" and "control", though this 982 list may be extended in future. The difference between "application" 983 and "data" is that the former is a media flow such as whiteboard 984 information, and the latter is bulk-data transfer such as 985 multicasting of program executables which will not typically be 986 displayed to the user. "control" is used to specify an additional 987 conference control channel for the session. 989 The second sub-field is the transport port to which the media stream 990 is sent. The meaning of the transport port depends on the network 991 being used as specified in the relevant "c=" field, and on the 992 transport protocol defined in the third sub-field. Other ports used 993 by the media application (such as the RTCP port [12]) MAY be derived 994 algorithmically from the base media port or MAY be specified in a 995 separate attribute (e.g. "a=rtcp:" as defined in [14]). 997 For applications where hierarchically encoded streams are being sent 998 to a unicast address, it may be necessary to specify multiple 999 transport ports. This is done using a similar notation to that used 1000 for IP multicast addresses in the "c=" field: 1002 m= / 1004 In such a case, the ports used depend on the transport protocol. For 1005 RTP, the default is that only the even numbered ports are used for 1006 data with the corresponding one-higher odd ports used for the RTCP 1007 belonging to the RTP session, and the denoting the 1008 number of RTP sessions. For example: 1010 m=video 49170/2 RTP/AVP 31 1012 would specify that ports 49170 and 49171 form one RTP/RTCP pair and 1013 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the 1014 transport protocol and 31 is the format (see below). If non- 1015 contiguous ports are required, they must be signalled using a 1016 separate attribute (e.g. "a=rtcp:" as defined in [14]). 1018 If multiple addresses are specified in the "c=" field and multiple 1019 ports are specified in the "m=" field, a one-to-one mapping from port 1020 to the corresponding address is implied. For example: 1022 c=IN IP4 224.2.1.1/127/2 1023 m=video 49170/2 RTP/AVP 31 1025 would imply that address 224.2.1.1 is used with ports 49170 and 1026 49171, and address 224.2.1.2 is used with ports 49172 and 49173. 1028 The third sub-field is the transport protocol. The transport 1029 protocol values are dependent on the address-type field in the "c=" 1030 fields. Thus a "c=" field of IP4 defines that the transport protocol 1031 runs over IP4. For IP4, it is normally expected that most media 1032 traffic will be carried as RTP over UDP. The following transport 1033 protocols are defined, but may be extended through registration of 1034 new protocols with IANA (see Section 9): 1036 RTP/AVP - the IETF's Realtime Transport Protocol using the 1037 Audio/Video profile carried over UDP. 1038 udp - User Datagram Protocol 1039 TCP - Transmission Control Protocol 1041 If an application uses a single combined proprietary media format and 1042 transport protocol over UDP, then simply specifying the transport 1043 protocol as udp and using the format field to distinguish the 1044 combined protocol is recommended. If a transport protocol is used 1045 over UDP to carry several distinct media types that need to be 1046 distinguished by a session directory, then specifying the transport 1047 protocol and media format separately is necessary. RTP is an example 1048 of a transport-protocol that carries multiple payload formats that 1049 must be distinguished by the session directory for it to know how to 1050 start appropriate tools, relays, mixers or recorders. 1052 The main reason to specify the transport-protocol in addition to the 1053 media format is that the same standard media formats may be carried 1054 over different transport protocols even when the network protocol is 1055 the same - a historical example is vat PCM audio and RTP PCM audio. 1056 In addition, relays and monitoring tools that are 1057 transport-protocol-specific but format-independent are possible. 1059 For RTP media streams operating under the RTP Audio/Video Profile 1060 [13], the protocol field is "RTP/AVP". Should other RTP profiles be 1061 defined in the future, their profiles will be specified in the same 1062 way. For example, the protocol field "RTP/XYZ" would specify RTP 1063 operating under a profile whose short name is "XYZ". 1065 The fourth and subsequent sub-fields are media formats. For audio 1066 and video, these SHOULD reference a MIME sub-type describing the 1067 format under the "audio" and "video" top-level MIME types. 1069 When a list of payload formats is given, this implies that all of 1070 these formats may be used in the session, but the first of these 1071 formats SHOULD be used as the default format for the session. 1073 For media whose transport protocol is not RTP or UDP the format field 1074 is protocol specific. Such formats should be defined in an 1075 additional specification document. 1077 For media whose transport protocol is RTP, SDP can be used to provide 1078 a dynamic binding of media encoding to RTP payload type. The encoding 1079 names in the RTP AV Profile do not specify unique audio encodings (in 1080 terms of clock rate and number of audio channels), and so they are 1081 not used directly in SDP format fields. Instead, the payload type 1082 number should be used to specify the format for static payload types 1083 and the payload type number along with additional encoding 1084 information should be used for dynamically allocated payload types. 1086 An example of a static payload type is u-law PCM coded single channel 1087 audio sampled at 8kHz. This is completely defined in the RTP Audio/ 1088 Video profile as payload type 0, so the media field for such a stream 1089 sent to UDP port 49232 is: 1091 m=audio 49232 RTP/AVP 0 1093 An example of a dynamic payload type is 16 bit linear encoded stereo 1094 audio sampled at 16 kHz. If we wish to use dynamic RTP/AVP payload 1095 type 98 for such a stream, additional information is required to 1096 decode it: 1098 m=audio 49232 RTP/AVP 98 1099 a=rtpmap:98 L16/16000/2 1101 The general form of an rtpmap attribute is: 1103 a=rtpmap: / 1104 [/] 1106 For audio streams, may specify the number of 1107 audio channels. This parameter may be omitted if the number of 1108 channels is one provided no additional parameters are needed. 1110 For video streams, no encoding parameters are currently specified. 1112 Additional parameters may be defined in the future, but codec- 1113 specific parameters SHOULD NOT be added. Parameters added to an 1114 rtpmap attribute SHOULD only be those required for a session 1115 directory to make the choice of appropriate media to participate in a 1116 session. Codec-specific parameters should be added in other 1117 attributes (for example, "a=fmtp:"). 1119 Up to one rtpmap attribute can be defined for each media format 1120 specified. Thus we might have: 1122 m=audio 49230 RTP/AVP 96 97 98 1123 a=rtpmap:96 L8/8000 1124 a=rtpmap:97 L16/8000 1125 a=rtpmap:98 L16/11025/2 1127 RTP profiles that specify the use of dynamic payload types MUST 1128 define the set of valid encoding names and/or a means to register 1129 encoding names if that profile is to be used with SDP. 1131 Note that RTP audio formats typically do not include information 1132 about the number of samples per packet. If a non-default (as defined 1133 in the RTP Audio/Video Profile) packetisation is required, the 1134 "ptime" attribute is used as given below. 1136 For more details on RTP audio and video formats, see [13]. 1138 Predefined application formats for the UDP protocol with non-RTP 1139 media are as below: 1141 wb: LBL Whiteboard (transport: udp) 1142 nt: UCL Network Text Editor (transport: udp) 1144 6. Suggested Attributes 1146 The following attributes are suggested. Since application writers 1147 may add new attributes as they are required, this list is not 1148 exhaustive. 1150 a=cat: 1152 This attribute gives the dot-separated hierarchical category 1153 of the session. This is to enable a receiver to filter 1154 unwanted sessions by category. It is a session-level 1155 attribute, and is not dependent on charset. 1157 a=keywds: 1159 Like the cat attribute, this is to assist identifying wanted 1160 sessions at the receiver. This allows a receiver to select 1161 interesting session based on keywords describing the purpose 1162 of the session. It is a session-level attribute. It is a 1163 charset dependent attribute, meaning that its value should be 1164 interpreted in the charset specified for the session 1165 description if one is specified, or by default in ISO 1166 10646/UTF-8. 1168 a=tool: 1170 This gives the name and version number of the tool used to 1171 create the session description. It is a session-level 1172 attribute, and is not dependent on charset. 1174 a=ptime: 1176 This gives the length of time in milliseconds represented by 1177 the media in a packet. This is probably only meaningful for 1178 audio data, but may be used with other media types if it makes 1179 sense. It should not be necessary to know ptime to decode RTP 1180 or vat audio, and it is intended as a recommendation for the 1181 encoding/packetisation of audio. It is a media attribute, and 1182 is not dependent on charset. 1184 a=maxptime: 1186 The maximum amount of media which can be encapsulated in each 1187 packet, expressed as time in milliseconds. The time SHALL be 1188 calculated as the sum of the time the media present in the 1189 packet represents. The time SHOULD be a multiple of the frame 1190 size. This attribute is probably only meaningful for audio 1191 data, but may be used with other media types if it makes 1192 sense. It is a media attribute, and is not dependent on 1193 charset. Note that this attribute was introduced after RFC 1194 2327, and non updated implementations will ignore this 1195 attribute. 1197 a=rtpmap: / 1198 [/] 1200 See Section 5.14. This may be a session or media attribute. 1202 a=recvonly 1204 This specifies that the tools should be started in receive 1205 only mode where applicable. It can be either a session or 1206 media attribute, and is not dependent on charset. Note that 1207 recvonly applies to the media only, not to any associated 1208 control protocol (e.g. an RTP based system in recvonly mode 1209 SHOULD still send RTCP packets). 1211 a=sendrecv 1213 This specifies that the tools should be started in send and 1214 receive mode. This is necessary for interactive conferences 1215 with tools that default to receive only mode. It can be either 1216 a session or media attribute, and is not dependent on charset. 1218 If none of the attributes "sendonly", "recvonly", "inactive", 1219 and "sendrecv" is present, "sendrecv" SHOULD be assumed as the 1220 default for sessions which are not of the conference type 1221 "broadcast" or "H332" (see below). 1223 a=sendonly 1225 This specifies that the tools should be started in send-only 1226 mode. An example may be where a different unicast address is 1227 to be used for a traffic destination than for a traffic 1228 source. In such a case, two media descriptions may be use, 1229 one sendonly and one recvonly. It can be either a session or 1230 media attribute, but would normally only be used as a media 1231 attribute, and is not dependent on charset. Note that sendonly 1232 applies only to the media, and any associated control protocol 1233 (e.g. RTCP) SHOULD still be received and processed as normal. 1235 a=inactive 1237 This specifies that the tools should be started in inactive 1238 mode. This is necessary for interactive conferences where 1239 users can put other users on hold. No media is sent over an 1240 inactive media stream. Note that an RTP based system SHOULD 1241 still send RTCP, even if started inactive. It can be either a 1242 session or media attribute, and is not dependent on charset. 1244 a=orient: 1245 Normally this is only used in a whiteboard media specification. 1246 It specifies the orientation of a the whiteboard on the screen. 1247 It is a media attribute. Permitted values are "portrait", 1248 "landscape" and "seascape" (upside down landscape). It is not 1249 dependent on charset. 1251 a=type: 1253 This specifies the type of the conference. Suggested values 1254 are "broadcast", "meeting", "moderated", "test" and "H332". 1255 "recvonly" should be the default for "type:broadcast" 1256 sessions, "type:meeting" should imply "sendrecv" and 1257 "type:moderated" should indicate the use of a floor control 1258 tool and that the media tools are started so as to mute new 1259 sites joining the conference. 1261 Specifying the attribute "type:H332" indicates that this 1262 loosely coupled session is part of a H.332 session as defined 1263 in the ITU H.332 specification [15]. Media tools should be 1264 started "recvonly". 1266 Specifying the attribute "type:test" is suggested as a hint 1267 that, unless explicitly requested otherwise, receivers can 1268 safely avoid displaying this session description to users. 1270 The type attribute is a session-level attribute, and is not 1271 dependent on charset. 1273 a=charset: 1275 This specifies the character set to be used to display the 1276 session name and information data. By default, the ISO-10646 1277 character set in UTF-8 encoding is used. If a more compact 1278 representation is required, other character sets may be used 1279 such as ISO-8859-1 for Northern European languages. In 1280 particular, the ISO 8859-1 is specified with the following 1281 SDP attribute: 1283 a=charset:ISO-8859-1 1285 This is a session-level attribute; if this attribute is 1286 present, it MUST be before the first media field. The charset 1287 specified MUST be one of those registered with IANA, such as 1288 ISO-8859-1. The character set identifier is a US-ASCII string 1289 and MUST be compared against the IANA identifiers using a 1290 case- insensitive comparison. If the identifier is not 1291 recognised or not supported, all strings that are affected by 1292 it SHOULD be regarded as octet strings. 1294 Note that a character set specified MUST still prohibit the 1295 use of bytes 0x00 (Nul), 0x0A (LF) and 0x0d (CR). Character 1296 sets requiring the use of these characters MUST define a 1297 quoting mechanism that prevents these bytes appearing within 1298 text fields. 1300 a=sdplang: 1302 This can be a session level attribute or a media level 1303 attribute. As a session level attribute, it specifies the 1304 language for the session description. As a media level 1305 attribute, it specifies the language for any media-level SDP 1306 information field associated with that media. Multiple 1307 sdplang attributes can be provided either at session or media 1308 level if multiple languages in the session description or 1309 media use multiple languages, in which case the order of the 1310 attributes indicates the order of importance of the various 1311 languages in the session or media from most important to least 1312 important. 1314 In general, sending session descriptions consisting of 1315 multiple languages is discouraged. Instead, multiple 1316 descriptions SHOULD be sent describing the session, one in 1317 each language. However this is not possible with all 1318 transport mechanisms, and so multiple sdplang attributes are 1319 allowed although NOT RECOMMENDED. 1321 The "sdplang" attribute value must be a single RFC 3066 1322 language tag in US-ASCII [6]. It is not dependent on 1323 the charset attribute. An "sdplang" attribute SHOULD be 1324 specified when a session is of sufficient scope to cross 1325 geographic boundaries where the language of recipients cannot 1326 be assumed, or where the session is in a different language 1327 from the locally assumed norm. 1329 a=lang: 1331 This can be a session level attribute or a media level 1332 attribute. As a session level attribute, it specifies the 1333 default language for the session being described. As a media 1334 level attribute, it specifies the language for that media, 1335 overriding any session-level language specified. Multiple 1336 lang attributes can be provided either at session or media 1337 level if the session description or media use multiple 1338 languages, in which case the order of the attributes indicates 1339 the order of importance of the various languages in the 1340 session or media from most important to least important. 1342 The "lang" attribute value must be a single RFC 3066 language 1343 tag in US-ASCII [6]. It is not dependent on the charset 1344 attribute. A "lang" attribute SHOULD be specified when a 1345 session is of sufficient scope to cross geographic boundaries 1346 where the language of recipients cannot be assumed, or where 1347 the session is in a different language from the locally 1348 assumed norm. 1350 a=framerate: 1352 This gives the maximum video frame rate in frames/sec. It is 1353 intended as a recommendation for the encoding of video data. 1354 Decimal representations of fractional values using the 1355 notation "." are allowed. It is a 1356 media attribute, defined only for video media, and is not 1357 dependent on charset. 1359 a=quality: 1361 This gives a suggestion for the quality of the encoding as an 1362 integer value. The intention of the quality attribute for 1363 video is to specify a non-default trade-off between frame-rate 1364 and still-image quality. For video, the value in the range 0 1365 to 10, with the following suggested meaning: 1367 10 - the best still-image quality the compression scheme 1368 can give. 1369 5 - the default behaviour given no quality suggestion. 1370 0 - the worst still-image quality the codec designer 1371 thinks is still usable. 1373 It is a media attribute, and is not dependent on charset. 1375 a=fmtp: 1377 This attribute allows parameters that are specific to a 1378 particular format to be conveyed in a way that SDP doesn't 1379 have to understand them. The format must be one of the 1380 formats specified for the media. Format-specific parameters 1381 may be any set of parameters required to be conveyed by SDP 1382 and given unchanged to the media tool that will use this 1383 format. 1385 It is a media attribute, and is not dependent on charset. 1387 7. Communicating Conference Control Policy 1389 There is some debate over the way conference control policy should be 1390 communicated. In general, the authors believe that an implicit 1391 declarative style of specifying conference control is desirable where 1392 possible. 1394 A simple declarative style uses a single conference attribute field 1395 before the first media field, possibly supplemented by properties 1396 such as `recvonly' for some of the media tools. This conference 1397 attribute conveys the conference control policy. An example might 1398 be: 1400 a=type:moderated 1402 In some cases, however, it is possible that this may be insufficient 1403 to communicate the details of an unusual conference control policy. 1404 If this is the case, then a conference attribute specifying external 1405 control might be set, and then one or more "media" fields might be 1406 used to specify the conference control tools and configuration data 1407 for those tools. An example is an ITU H.332 session: 1409 ... 1410 c=IN IP4 224.5.6.7 1411 a=type:H332 1412 m=audio 49230 RTP/AVP 0 1413 m=video 49232 RTP/AVP 31 1414 m=application 12349 udp wb 1415 m=control 49234 H323 mc 1416 c=IN IP4 134.134.157.81 1418 In this example, a general conference attribute (type:H332) is 1419 specified stating that conference control will be provided by an 1420 external H.332 tool, and a contact addresses for the H.323 session 1421 multipoint controller is given. 1423 In this document, only the declarative style of conference control 1424 declaration is specified. Other forms of conference control should 1425 specify an appropriate type attribute, and should define the 1426 implications this has for control media. 1428 8. Security Considerations 1430 SDP is a session description format that describes multimedia 1431 sessions. A session description SHOULD NOT be trusted unless it has 1432 been obtained by an authenticated transport protocol from a trusted 1433 source. Many different transport protocols may be used to distribute 1434 session description, and the nature of the authentication will differ 1435 from transport to transport. 1437 One transport that will frequently be used to distribute session 1438 descriptions is the Session Announcement Protocol (SAP). SAP 1439 provides both encryption and authentication mechanisms but due to the 1440 nature of session announcements it is likely that there are many 1441 occasions where the originator of a session announcement cannot be 1442 authenticated because they are previously unknown to the receiver of 1443 the announcement and because no common public key infrastructure is 1444 available. 1446 On receiving a session description over an unauthenticated transport 1447 mechanism or from an untrusted party, software parsing the session 1448 should take a few precautions. Session descriptions contain 1449 information required to start software on the receivers system. 1450 Software that parses a session description MUST NOT be able to start 1451 other software except that which is specifically configured as 1452 appropriate software to participate in multimedia sessions. It is 1453 normally considered inappropriate for software parsing a session 1454 description to start, on a user's system, software that is 1455 appropriate to participate in multimedia sessions, without the user 1456 first being informed that such software will be started and giving 1457 their consent. Thus a session description arriving by session 1458 announcement, email, session invitation, or WWW page MUST NOT deliver 1459 the user into an interactive multimedia session unless the user has 1460 explicitly pre-authorized such action. As it is not always simple to 1461 tell whether a session is interactive or not, applications that are 1462 unsure should assume sessions are interactive. 1464 In this specification, there are no attributes which would allow the 1465 recipient of a session description to be informed to start multimedia 1466 tools in a mode where they default to transmitting. Under some 1467 circumstances it might be appropriate to define such attributes. If 1468 this is done an application parsing a session description containing 1469 such attributes SHOULD either ignore them, or inform the user that 1470 joining this session will result in the automatic transmission of 1471 multimedia data. The default behaviour for an unknown attribute is 1472 to ignore it. 1474 Session descriptions may be parsed at intermediate systems such as 1475 firewalls for the purposes of opening a hole in the firewall to allow 1476 the participation in multimedia sessions. It is considered 1477 inappropriate for a firewall to open such holes for unicast data 1478 streams unless the session description comes in a request from inside 1479 the firewall. For multicast sessions, it is likely that local 1480 administrators will apply their own policies, but the exclusive use 1481 of "local" or "site-local" administrative scope within the firewall 1482 and the refusal of the firewall to open a hole for such scopes will 1483 provide separation of global multicast sessions from local ones. 1485 Use of the "k=" field poses a significant security risk, since it 1486 conveys session encryption keys in the clear. SDP MUST NOT be used 1487 to convey key material, unless it can be guaranteed that the channel 1488 over which the SDP is delivered is both private and authenticated. 1490 9. IANA Considerations 1492 9.1 The "application/sdp" media type 1494 One new MIME type is to be registered, as defined below. This updates 1495 the previous definition from RFC 2327. 1497 To: ietf-types@iana.org 1498 Subject: Registration of MIME media type application/sdp 1500 MIME media type name: application 1502 MIME subtype name: sdp 1504 Required parameters: None. 1506 Optional parameters: None. 1508 Encoding considerations: 1509 See section 5 of RFC XXXX 1511 Security considerations: 1512 See section 8 of RFC XXXX 1514 Interoperability considerations: 1515 See RFC XXXX 1517 Published specification: 1518 RFC XXXX 1520 Applications which use this media type: 1521 Voice over IP, video teleconferencing, streaming media, instant 1522 messaging, etc. See also section 3 of RFC XXXX. 1524 Additional information: 1526 Magic number(s): None. 1527 File extension(s): The extension ".sdp" is commonly used. 1528 Macintosh File Type Code(s): 1530 Person & email address to contact for further information: 1531 Colin Perkins 1532 IETF MMUSIC working group 1534 Intended usage: COMMON 1536 Author/Change controller: 1537 Authors of RFC XXXX 1538 IETF MMUSIC working group 1540 9.2 Registration of Parameters 1542 There are seven field names that may be registered with IANA. Using 1543 the terminology in the SDP specification BNF, they are "media", 1544 "proto", "fmt", "att-field", "bwtype", "nettype" and "addrtype". 1546 9.2.1 Media types ("media") 1548 The set of media types is intended to be small and SHOULD NOT be 1549 extended except under rare circumstances. The same rules should 1550 apply for media names as for top-level MIME content types, and where 1551 possible the same name should be registered for SDP as for MIME. For 1552 media other than existing MIME top-level content types, a 1553 standards-track RFC MUST be produced for a new top-level content type 1554 to be registered, and the registration MUST provide good 1555 justification why no existing media name is appropriate (the 1556 "Standards Action" policy of RFC 2434 [5]. 1558 9.2.2 Transport protocols ("proto") 1560 The "proto" field describes the transport protocol used. This SHOULD 1561 reference a standards-track protocol RFC. This memo registers three 1562 values: "RTP/AVP" is a reference to RTP [12] used under the RTP 1563 Profile for Audio and Video Conferences with Minimal Control [13] 1564 running over UDP/IP; "TCP" denotes an unspecified format over TCP; 1565 and "udp" indicates an unspecified format over UDP. 1567 New transport protocols MAY be registered with IANA. Registrations 1568 MUST reference an RFC describing the protocol. Such an RFC MAY be 1569 Experimental or Informational, although it is preferable if it is 1570 Standards-Track. Registrations MUST also define the rules by which 1571 their "fmt" namespace is managed (see below). 1573 9.2.3 Media formats ("fmt") 1575 Each transport protocol, defined by the "proto" field, has an 1576 associated "fmt" namespace that describes the media formats which may 1577 conveyed by that protocol. Formats cover all the possible encodings 1578 that might want to be transported in a multimedia session. 1580 RTP payload formats under the "RTP/AVP" protocol that have been 1581 assigned static payload types MUST use the static payload type as 1582 their "fmt" value. For payload formats under "RTP/AVP" that have a 1583 dynamic payload type number, the dynamic payload type number is given 1584 as the "fmt" and an additional "rtpmap" attribute specifies the 1585 format name and parameters as defined by the MIME type registration 1586 for the payload format. 1588 For "TCP" and "udp" protocols, new formats SHOULD be registered. Use 1589 of an existing MIME subtype for the format is encouraged. If no MIME 1590 subtype exists, it is RECOMMENDED that a suitable one is registered 1591 through the IETF process (RFC 2048) by production of, or reference 1592 to, a standards-track RFC. If a MIME subtype is for some reason 1593 inappropriate, an RFC publication describing the format MUST be 1594 referenced in the registration, but it may be Informational or 1595 Experimental if the protocol is not deemed to be of widespread 1596 deployment. 1598 For other protocols, formats MAY be registered according to the rules 1599 of the associated "proto" specification. 1601 Registrations of new formats MUST specify which transport protocols 1602 they apply to. 1604 9.2.4 Attribute names ("att-field") 1606 Attribute field names ("att-field") MUST be registered with IANA and 1607 documented, because of noticeable issues due to conflicting 1608 attributes under the same name. Unknown attributes in SDP are simply 1609 ignored, but conflicting ones that fragment the protocol are a 1610 serious problem. 1612 New attribute registerations are accepted according to the 1613 "Specification Required" policy of RFC 2434, provided that the 1614 specification includes the following information: 1616 o contact name, email address and telephone number 1618 o attribute-name (as it will appear in SDP) 1620 o long-form attribute name in English 1622 o type of attribute (session level, media level, or both) 1623 o whether the attribute value is subject to the charset attribute. 1625 o a one paragraph explanation of the purpose of the attribute. 1627 o a specification of appropriate attribute values for this 1628 attribute. 1630 The above is the minimum that IANA will accept. Attributes that are 1631 expected to see widespread use and interoperability, SHOULD be 1632 documented with a standards-track RFC that specifies the attribute 1633 more precisely. 1635 Submitters of registrations should ensure that the specification is 1636 in the spirit of SDP attributes, most notably that the attribute is 1637 platform independent in the sense that it makes no implicit 1638 assumptions about operating systems and does not name specific pieces 1639 of software in a manner that might inhibit interoperability. 1641 9.2.5 Bandwidth specifiers ("bwtype") 1643 A proliferation of bandwidth specifiers is strongly discouraged. 1645 New bandwidth specifiers ("bwtype" fields) MUST be registered with 1646 IANA. The submission MUST reference a standards-track RFC specifying 1647 the semantics of the bandwidth specifier precisely, and indicating 1648 when it should be used, and why the existing registered bandwidth 1649 specifiers do not suffice. 1651 9.2.6 Network types ("nettype") 1653 New network types (the "nettype" field) may be registered with IANA 1654 if SDP needs to be used in the context of non-Internet environments. 1655 Whilst these are not normally the preserve of IANA, there may be 1656 circumstances when an Internet application needs to interoperate with 1657 a non- Internet application, such as when gatewaying an Internet 1658 telephony call into the PSTN. The number of network types should be 1659 small and should be rarely extended. A new network type cannot be 1660 registered without registering at least one address type to be used 1661 with that network type. A new network type registration MUST 1662 reference an RFC which gives details of the network type and address 1663 type and specifies how and when they would be used. Such an RFC MAY 1664 be Informational. 1666 9.2.7 Address types ("addrtype") 1668 New address types ("addrtype") may be registered with IANA. An 1669 address type is only meaningful in the context of a network type, and 1670 any registration of an address type MUST specify a registered network 1671 type, or be submitted along with a network type registration. A new 1672 address type registration MUST reference an RFC giving details of the 1673 syntax of the address type. Such an RFC MAY be Informational. 1674 Address types are not expected to be registered frequently. 1676 9.2.8 Registration Procedure 1678 In the RFC documentation that registers SDP "media", "proto", "fmt", 1679 "bwtype", "nettype" and "addrtype" fields, the authors MUST include 1680 the following information for IANA to place in the appropriate 1681 registry: 1683 o contact name, email address and telephone number 1685 o name being registered (as it will appear in SDP) 1687 o long-form name in English 1689 o type of name ("media", "proto", "fmt", "bwtype", "nettype", or 1690 "addrtype") 1692 o a one paragraph explanation of the purpose of the registered name. 1694 o a reference to the specification (e.g. RFC number) of the 1695 registered name. 1697 IANA may refer any registration to the IESG Transport Area Directors 1698 for review, and may request revisions to be made before a 1699 registration will be made. 1701 Appendix A. SDP Grammar 1703 This appendix provides an Augmented BNF grammar for SDP. ABNF is 1704 defined in [2]. 1706 ; SDP Syntax 1707 announcement = proto-version 1708 origin-field 1709 session-name-field 1710 information-field 1711 uri-field 1712 email-fields 1713 phone-fields 1714 connection-field 1715 bandwidth-fields 1716 time-fields 1717 key-field 1718 attribute-fields 1719 media-descriptions 1721 proto-version = "v=" 1*DIGIT CRLF 1722 ;this memo describes version 0 1724 origin-field = "o=" username SP sess-id SP sess-version SP 1725 nettype SP addrtype SP unicast-address CRLF 1727 session-name-field = "s=" text CRLF 1729 information-field = ["i=" text CRLF] 1731 uri-field = ["u=" uri CRLF] 1733 email-fields = *("e=" email-address CRLF) 1735 phone-fields = *("p=" phone-number CRLF) 1737 connection-field = ["c=" nettype SP addrtype SP 1738 connection-address CRLF] 1739 ;a connection field must be present 1740 ;in every media description or at the 1741 ;session-level 1743 bandwidth-fields = *("b=" bwtype ":" bandwidth CRLF) 1745 time-fields = 1*( "t=" start-time SP stop-time 1746 *(CRLF repeat-fields) CRLF) 1747 [zone-adjustments CRLF] 1749 repeat-fields = "r=" repeat-interval SP typed-time 1750 1*(SP typed-time) 1752 zone-adjustments = "z=" time SP ["-"] typed-time 1753 *(SP time SP ["-"] typed-time) 1755 key-field = ["k=" key-type CRLF] 1757 attribute-fields = *("a=" attribute CRLF) 1759 media-descriptions = *( media-field 1760 information-field 1761 *connection-field 1762 bandwidth-fields 1763 key-field 1764 attribute-fields ) 1766 media-field = "m=" media SP port ["/" integer] 1767 SP proto 1*(SP fmt) CRLF 1769 ; sub-rules of 'o=' 1770 username = non-ws-string 1771 ;pretty wide definition, but doesn't 1772 ;include space 1774 sess-id = 1*DIGIT 1775 ;should be unique for this username/host 1777 sess-version = 1*DIGIT 1778 ;0 is a new session 1780 nettype = token 1781 ;typically "IN" 1783 addrtype = token 1784 ;typically "IP4" or "IP6" 1786 ; sub-rules of 'u=' 1787 uri = URI-reference; see RFC1630 and RFC2732 1789 ; sub-rules of 'e=' 1790 email-address = email *SP "(" 1*email-safe ")" / 1791 1*email-safe "<" email ">" / 1792 email 1794 email = addr-spec ; defined in RFC2822 1795 ; modified to remove CFWS 1797 ; sub-rules of 'p=' 1798 phone-number = phone *SP "(" 1*email-safe ")" / 1799 1*email-safe "<" phone ">" / 1800 phone 1802 phone = "+" POS-DIGIT 1*(SP / "-" / DIGIT) 1803 ;there must be a space or hyphen between 1804 ;the international code and the rest of 1805 ;the number. 1807 ; sub-rules of 'c=' 1808 connection-address = multicast-address / unicast-address 1810 ; sub-rules of 'b=' 1811 bwtype = token 1813 bandwidth = 1*DIGIT 1814 ; sub-rules of 't=' 1815 start-time = time / "0" 1817 stop-time = time / "0" 1819 time = POS-DIGIT 9*DIGIT 1820 ; 10-digit NTP time represents times between 1821 ; 1931 and 5068 AD. 9* allows times after 1822 ; that as well. 1824 ; sub-rules of 'r=' and 'z=' 1825 repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] 1827 typed-time = 1*DIGIT [fixed-len-time-unit] 1829 fixed-len-time-unit = "d" / "h" / "m" / "s" 1831 ; sub-rules of 'k=' 1832 key-type = "prompt" / 1833 "clear:" text / 1834 "base64:" base64 / 1835 "uri:" uri / 1836 key-method [ ":" text ] 1838 base64 = *base64-unit [base64-pad] 1839 base64-unit = 4base64-char 1840 base64-pad = 2base64-char "==" / 3base64-char "=" 1841 base64-char = ALPHA / DIGIT / "+" / "/" 1843 key-method = token 1845 ; sub-rules of 'a=' 1846 attribute = (att-field ":" att-value) / att-field 1848 att-field = token 1850 att-value = byte-string 1852 ; sub-rules of 'm=' 1853 media = token 1854 ;typically "audio", "video", "application" 1855 ;or "data" 1857 fmt = token 1858 ;typically an RTP payload type for audio 1859 ;and video media 1861 proto = token "/" token 1862 / token 1863 ;typically "RTP/AVP" or "udp" for IP4 1865 port = 1*DIGIT 1866 ;should be either "0" or in the range "1024" 1867 ;to "65535" inclusive for UDP based media 1868 ;(a value of "0" is used to signal special 1869 ;conditions in some uses of SDP) 1871 ; generic sub-rules: addressing 1872 unicast-address = IP4-address / IP6-address / FQDN / extn-addr 1874 multicast-address = IP4-multicast / IP6-multicast 1876 IP4-multicast = m1 3( "." decimal-uchar ) 1877 "/" ttl [ "/" integer ] 1878 ; IPv4 multicast addresses may be in the 1879 ; range 224.0.0.0 to 239.255.255.255 1881 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / 1882 ("23" DIGIT ) 1884 IP6-multicast = hexpart [ "/" integer ] 1885 ; IPv6 address starting with FF 1887 ttl = (POS-DIGIT *2DIGIT) / "0" 1889 FQDN = 4*(alpha-numeric / "-" / ".") 1890 ; fully qualified domain name as specified 1891 ; in RFC1035 1893 IP4-address = b1 3("." decimal-uchar) / "0.0.0.0" 1895 b1 = decimal-uchar 1896 ; less than "224"; not "0" or "127" 1898 ; The following is from RFC2373 Appendix B. It is a direct copy. 1899 IP6-address = hexpart [ ":" IP4-address ] 1901 hexpart = hexseq / hexseq "::" [ hexseq ] / 1902 "::" [ hexseq ] 1904 hexseq = hex4 *( ":" hex4) 1906 hex4 = 1*4HEXDIG 1908 ; Generic for other address families 1909 extn-addr = non-ws-string 1910 ; generic sub-rules: datatypes 1911 text = byte-string 1912 ;default is to interpret this as UTF8 text. 1913 ;ISO 8859-1 requires "a=charset:ISO-8859-1" 1914 ;session-level attribute to be used 1916 byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) 1917 ;any byte except NUL, CR or LF 1919 non-ws-string = 1*(VCHAR/%x80-FF) 1920 ;string of visible characters 1922 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 1923 / %x41-5A / %x5E-7E 1925 token = 1*(token-char) 1927 email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF 1928 ;any byte except NUL, CR, LF, or the quoting 1929 ;characters ()<> 1931 integer = POS-DIGIT *DIGIT 1933 ; generic sub-rules: primitives 1934 alpha-numeric = ALPHA / DIGIT 1936 POS-DIGIT = %x31-39 ; 1 - 9 1938 decimal-uchar = DIGIT 1939 / POS-DIGIT DIGIT 1940 / ("1" 2*(DIGIT)) 1941 / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) 1942 / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) 1944 ; external references: 1945 ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 2234 1946 ; URI-reference: from RFC1630 and RFC2732 1947 ; addr-spec: from RFC 2822 1949 Appendix B. Acknowledgments 1951 Many people in the IETF MMUSIC working group have made comments and 1952 suggestions contributing to this document. In particular, we would 1953 like to thank Eve Schooler, Steve Casner, Bill Fenner, Allison 1954 Mankin, Ross Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, 1955 Steve Hanna and Jonathan Lennox. 1957 Normative References 1959 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1960 Levels", BCP 14, RFC 2119, March 1997. 1962 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1963 Specifications: ABNF", RFC 2234, November 1997. 1965 [3] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1966 2279, January 1998. 1968 [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource 1969 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 1971 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1972 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 1974 [6] Alvestrand, H., "Tags for the Identification of Languages", BCP 1975 47, RFC 3066, January 2001. 1977 Informative References 1979 [7] Mills, D., "Network Time Protocol (Version 3) Specification, 1980 Implementation", RFC 1305, March 1992. 1982 [8] Handley, M., Perkins, C. and E. Whelan, "Session Announcement 1983 Protocol", RFC 2974, October 2000. 1985 [9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1986 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1987 Session Initiation Protocol", RFC 3261, June 2002. 1989 [10] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 1990 Protocol (RTSP)", RFC 2326, April 1998. 1992 [11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1993 Session Description Protocol (SDP)", RFC 3264, June 2002. 1995 [12] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 1996 "RTP: A Transport Protocol for Real-Time Applications", RFC 1997 3550, July 2003. 1999 [13] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 2000 Conferences with Minimal Control", RFC 3551, July 2003. 2002 [14] Huitema, C., "Real Time Control Protocol (RTCP) attribute in 2003 Session Description Protocol (SDP)", RFC 3605, October 2003. 2005 [15] International Telecommunications Union, "H.323 extended for 2006 loosely coupled conferences", ITU Recommendation H.332, 2007 September 1998. 2009 [16] Arkko, J., "Key Management Extensions for Session Description 2010 Protocol (SDP) and Real Time Streaming Protocol (RTSP)", 2011 draft-ietf-mmusic-kmgmt-ext-09 (work in progress), October 2012 2003. 2014 [17] Andreasen, F., Baugher, M. and D. Wing, "SDP Security 2015 Descriptions for Media Streams", 2016 draft-ietf-mmusic-sdescriptions-02 (work in progress), October 2017 2003. 2019 Authors' Addresses 2021 Mark Handley 2022 University College London 2023 Gower Street 2024 London WC1E 6BT 2025 UK 2027 EMail: M.Handley@cs.ucl.ac.uk 2029 Van Jacobson 2030 Packet Design 2031 2465 Latham Street 2032 Mountain View, CA 94040 2033 USA 2035 EMail: van@packetdesign.com 2037 Colin Perkins 2038 University of Glasgow 2039 17 Lilybank Gardens 2040 Glasgow G12 8QQ 2041 UK 2043 EMail: csp@csperkins.org 2045 Intellectual Property Statement 2047 The IETF takes no position regarding the validity or scope of any 2048 intellectual property or other rights that might be claimed to 2049 pertain to the implementation or use of the technology described in 2050 this document or the extent to which any license under such rights 2051 might or might not be available; neither does it represent that it 2052 has made any effort to identify any such rights. Information on the 2053 IETF's procedures with respect to rights in standards-track and 2054 standards-related documentation can be found in BCP-11. Copies of 2055 claims of rights made available for publication and any assurances of 2056 licenses to be made available, or the result of an attempt made to 2057 obtain a general license or permission for the use of such 2058 proprietary rights by implementors or users of this specification can 2059 be obtained from the IETF Secretariat. 2061 The IETF invites any interested party to bring to its attention any 2062 copyrights, patents or patent applications, or other proprietary 2063 rights which may cover technology that may be required to practice 2064 this standard. Please address the information to the IETF Executive 2065 Director. 2067 Full Copyright Statement 2069 Copyright (C) The Internet Society (2003). All Rights Reserved. 2071 This document and translations of it may be copied and furnished to 2072 others, and derivative works that comment on or otherwise explain it 2073 or assist in its implementation may be prepared, copied, published 2074 and distributed, in whole or in part, without restriction of any 2075 kind, provided that the above copyright notice and this paragraph are 2076 included on all such copies and derivative works. However, this 2077 document itself may not be modified in any way, such as by removing 2078 the copyright notice or references to the Internet Society or other 2079 Internet organizations, except as needed for the purpose of 2080 developing Internet standards in which case the procedures for 2081 copyrights defined in the Internet Standards process must be 2082 followed, or as required to translate it into languages other than 2083 English. 2085 The limited permissions granted above are perpetual and will not be 2086 revoked by the Internet Society or its successors or assignees. 2088 This document and the information contained herein is provided on an 2089 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2090 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2091 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2092 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2093 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2095 Acknowledgment 2097 Funding for the RFC Editor function is currently provided by the 2098 Internet Society.