idnits 2.17.1 draft-ietf-mmusic-sdp-new-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2105. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2082. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2089. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2095. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 11 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 -- The draft header indicates that this document obsoletes RFC3266, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC2327, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 19, 2004) is 7159 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '7' is defined on line 1984, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 2026, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2279 (ref. '3') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2396 (ref. '4') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2434 (ref. '5') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2732 (ref. '6') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 3066 (ref. '7') (Obsoleted by RFC 4646, RFC 4647) -- Obsolete informational reference (is this intentional?): RFC 1305 (ref. '8') (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '11') (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 3548 (ref. '13') (Obsoleted by RFC 4648) == Outdated reference: A later version (-15) exists of draft-ietf-mmusic-kmgmt-ext-11 == Outdated reference: A later version (-12) exists of draft-ietf-mmusic-sdescriptions-07 Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Handley 2 Internet-Draft UCL 3 Obsoletes: 2327, 3266 (if V. Jacobson 4 approved) Packet Design 5 Expires: March 20, 2005 C. Perkins 6 University of Glasgow 7 September 19, 2004 9 SDP: Session Description Protocol 10 draft-ietf-mmusic-sdp-new-20.txt 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on March 20, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). 43 Abstract 45 This memo defines the Session Description Protocol (SDP). SDP is 46 intended for describing multimedia sessions for the purposes of 47 session announcement, session invitation, and other forms of 48 multimedia session initiation. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . 3 54 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . 3 55 3.1 Multicast Session Announcement . . . . . . . . . . . . . . 3 56 3.2 Session Initiation . . . . . . . . . . . . . . . . . . . . 4 57 3.3 Streaming media . . . . . . . . . . . . . . . . . . . . . 4 58 3.4 Email and the World Wide Web . . . . . . . . . . . . . . . 4 59 4. Requirements and Recommendations . . . . . . . . . . . . . . 5 60 4.1 Media and Transport Information . . . . . . . . . . . . . 5 61 4.2 Timing Information . . . . . . . . . . . . . . . . . . . . 6 62 4.3 Private Sessions . . . . . . . . . . . . . . . . . . . . . 6 63 4.4 Obtaining Further Information about a Session . . . . . . 7 64 4.5 Categorisation . . . . . . . . . . . . . . . . . . . . . . 7 65 4.6 Internationalization . . . . . . . . . . . . . . . . . . . 7 66 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . 7 67 5.1 Protocol Version ("v=") . . . . . . . . . . . . . . . . . 10 68 5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 10 69 5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . . 11 70 5.4 Session Information ("i=") . . . . . . . . . . . . . . . . 12 71 5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 12 72 5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . 12 73 5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . 13 74 5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 15 75 5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 16 76 5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . 17 77 5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . 18 78 5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 19 79 5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . 20 80 5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . . 21 81 6. Suggested Attributes . . . . . . . . . . . . . . . . . . . . 23 82 7. Security Considerations . . . . . . . . . . . . . . . . . . 30 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31 84 8.1 The "application/sdp" media type . . . . . . . . . . . . . 31 85 8.2 Registration of Parameters . . . . . . . . . . . . . . . . 32 86 8.3 Encryption Key Access Methods . . . . . . . . . . . . . . 36 87 A. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 37 88 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 42 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 90 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 42 91 9.2 Informative References . . . . . . . . . . . . . . . . . . . 42 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 44 93 Intellectual Property and Copyright Statements . . . . . . . 45 95 1. Introduction 97 When initiating multimedia teleconferences, voice-over-IP calls, 98 streaming video, or other sessions, there is a requirement to convey 99 media details, transport addresses, and other session description 100 metadata to the participants. 102 SDP provides a standard representation for such information, 103 irrespective of how that information is transported. SDP is purely a 104 format for session description - it does not incorporate a transport 105 protocol, and is intended to use different transport protocols as 106 appropriate, including the Session Announcement Protocol [9], Session 107 Initiation Protocol [10], Real-Time Streaming Protocol [11], 108 electronic mail using the MIME extensions, and the Hypertext 109 Transport Protocol. 111 SDP is intended to be general purpose so that it can be used in a 112 wide range of network environments and applications. However, it is 113 not intended to support negotiation of session content or media 114 encodings: this is viewed as outside the scope of session 115 description. 117 2. Glossary of Terms 119 The following terms are used in this document, and have specific 120 meaning within the context of this document. 122 Conference: A multimedia conference is a set of two or more 123 communicating users along with the software they are using to 124 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. 130 Session Description: A well defined format for conveying sufficient 131 information to discover and participate in a multimedia session. 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [1]. 137 3. Examples of SDP Usage 139 3.1 Multicast Session Announcement 141 In order to assist the advertisement of multicast multimedia 142 conferences and other multicast sessions, and to communicate the 143 relevant session setup information to prospective participants, a 144 distributed session directory may be used. An instance of such a 145 session directory periodically sends packets containing a description 146 of the session to a well known multicast group. These advertisements 147 are received by other session directories such that potential remote 148 participants can use the session description to start the tools 149 required to participate in the session. 151 One protocol commonly used to implement such a distributed directory 152 is the Session Announcement Protocol, SAP [9]. SDP provides the 153 recommended session description format for such session 154 announcements. 156 3.2 Session Initiation 158 The Session Initiation Protocol, SIP [10] is an application layer 159 control protocol for creating, modifying and terminating sessions 160 such as Internet multimedia conferences, Internet telephone calls and 161 multimedia distribution. The SIP messages used to create sessions 162 carry session descriptions which allow participants to agree on a set 163 of compatible media types. These session descriptions are commonly 164 formatted using SDP. When used with SIP, the offer/answer model [12] 165 provides a limited framework for negotiation using SDP. 167 3.3 Streaming media 169 The Real Time Streaming Protocol, RTSP [11], is an application-level 170 protocol for control over the delivery of data with real-time 171 properties. RTSP provides an extensible framework to enable 172 controlled, on-demand delivery of real-time data, such as audio and 173 video. An RTSP client and server negotiate an appropriate set of 174 parameters for media delivery, partially using SDP syntax to describe 175 those parameters. 177 3.4 Email and the World Wide Web 179 Alternative means of conveying session descriptions include 180 electronic mail and the World Wide Web. For both email and WWW 181 distribution, the MIME content type "application/sdp" is used. This 182 enables the automatic launching of applications for participation in 183 the session from the WWW client or mail reader in a standard manner. 185 Note that announcements of multicast sessions made only via email or 186 the World Wide Web (WWW) do not have the property that the receiver 187 of a session announcement can necessarily receive the session because 188 the multicast sessions may be restricted in scope, and access to the 189 WWW server or reception of email is possible outside this scope. 190 Session announcements made using SAP do not suffer this mismatch. 192 4. Requirements and Recommendations 194 The purpose of SDP is to convey information about media streams in 195 multimedia sessions to allow the recipients of a session description 196 to participate in the session. SDP is primarily intended for use in 197 an internetwork, although it is sufficiently general that it can 198 describe conferences in other network environments. Media streams 199 can be many-to-many. The times during which the session is active 200 need not be continuous. 202 Thus far, multicast based sessions on the Internet have differed from 203 many other forms of conferencing in that anyone receiving the traffic 204 can join the session (unless the session traffic is encrypted). In 205 such an environment, SDP serves two primary purposes. It is a means 206 to communicate the existence of a session, and is a means to convey 207 sufficient information to enable joining and participating in the 208 session. In a unicast environment, only the latter purpose is likely 209 to be relevant. 211 An SDP session description includes: 213 o Session name and purpose 215 o Time(s) the session is active 217 o The media comprising the session 219 o Information needed to receive those media (addresses, ports, 220 formats and so on) 222 As resources necessary to participate in a session may be limited, 223 some additional information may also be desirable: 225 o Information about the bandwidth to be used by the session 227 o Contact information for the person responsible for the session 229 In general, SDP must convey sufficient information to enable 230 applications to join a session (with the possible exception of 231 encryption keys), and to announce the resources to be used to any 232 non-participants that may need to know (this latter feature is 233 primarily useful when SDP is used with a multicast session 234 announcement protocol). 236 4.1 Media and Transport Information 238 An SDP session description includes the following media information: 240 o The type of media (video, audio, etc) 242 o The transport protocol (RTP/UDP/IP, H.320, etc) 244 o The format of the media (H.261 video, MPEG video, etc) 246 In addition to media format and transport protocol, SDP conveys 247 address and port details. For an IP multicast session, these 248 comprise: 250 o The multicast group address for media 252 o The transport port for media 254 This address and port are the destination address and destination 255 port of the multicast stream, whether being sent, received, or both. 257 For unicast IP sessions, the following are conveyed: 259 o The remote address for media 261 o The transport port for media 263 The semantics of this address and port depend on the media and 264 transport protocol defined. By default, this SHOULD be the remote 265 address and remote port to which data is sent. Some media types MAY 266 redefine this behaviour, but this is NOT RECOMMENDED. 268 4.2 Timing Information 270 Sessions may either be bounded or unbounded in time. Whether or not 271 they are bounded, they may be only active at specific times. SDP can 272 convey: 274 o An arbitrary list of start and stop times bounding the session 276 o For each bound, repeat times such as "every Wednesday at 10am for 277 one hour" 279 This timing information is globally consistent, irrespective of local 280 time zone or daylight saving time. 282 4.3 Private Sessions 284 It is possible to create both public sessions and private sessions. 285 SDP itself does not distinguish between these: private sessions are 286 typically conveyed by encrypting the session description during 287 distribution. The details of how encryption is performed are 288 dependent on the mechanism used to convey SDP: mechanisms are 289 currently defined for SDP transported using SAP [9] and SIP [10], 290 others may be defined in future. 292 If a session announcement is private it is possible to use that 293 private announcement to convey encryption keys necessary to decode 294 each of the media in a conference, including enough information to 295 know which encryption scheme is used for each media. 297 4.4 Obtaining Further Information about a Session 299 A session description should convey enough information to decide 300 whether or not to participate in a session. SDP may include 301 additional pointers in the form of Universal Resources Identifiers 302 (URIs) for more information about the session. 304 4.5 Categorisation 306 When many session descriptions are being distributed by SAP, or any 307 other advertisement mechanism, it may be desirable to filter session 308 announcements that are of interest from those that are not. SDP 309 supports a categorisation mechanism for sessions that is capable of 310 being automated. 312 4.6 Internationalization 314 The SDP specification recommends the use of the ISO 10646 character 315 sets in the UTF-8 encoding [3] to allow many different languages to 316 be represented. However, to assist in compact representations, SDP 317 also allows other character sets such as ISO 8859-1 to be used when 318 desired. Internationalization only applies to free-text fields 319 (session name and background information), and not to SDP as a whole. 321 5. SDP Specification 323 An SDP session description is denoted by the MIME content type 324 "application/sdp" (See Section 8). 326 An SDP session description is 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, and to allow flexible, text-based 335 toolkits to be used to generate and process session descriptions. 337 However, since SDP may be used in environments where the maximum 338 permissable size of a session description is limited, the encoding is 339 deliberately compact. Also, since announcements may be transported 340 via very unreliable means or damaged by an intermediate caching 341 server, the encoding was designed with strict order and formatting 342 rules so that most errors would result in malformed session 343 announcements which could be detected easily and discarded. This 344 also allows rapid discarding of encrypted session announcements for 345 which a receiver does not have the correct key. 347 An SDP session description consists of a number of lines of text of 348 the form: 350 = 352 where MUST be exactly one case-significant character and 353 is structured text whose format depends on . In 354 general is either a number of fields delimited by a single 355 space character, or a free format string. Whitespace MUST NOT be 356 used either side of the "=" sign. 358 An SDP session description consists of a session-level section 359 followed by zero or more media-level sections. The session-level 360 part starts with a "v=" line and continues to the first media-level 361 section. The media description starts with an "m=" line and 362 continues to the next media description or end of the whole session 363 description. In general, session-level values are the default for 364 all media unless overridden by an equivalent media-level value. 366 Some lines in each description are REQUIRED and some are OPTIONAL but 367 all MUST appear in exactly the order given here (the fixed order 368 greatly enhances error detection and allows for a simple parser). 369 OPTIONAL items are marked with a "*". 371 Session description 372 v= (protocol version) 373 o= (owner/creator and session identifier). 374 s= (session name) 375 i=* (session information) 376 u=* (URI of description) 377 e=* (email address) 378 p=* (phone number) 379 c=* (connection information - not required if included in 380 all media) 381 b=* (zero or more bandwidth information lines) 382 One or more time descriptions ("t=" and "r=" lines, see below) 383 z=* (time zone adjustments) 384 k=* (encryption key) 385 a=* (zero or more session attribute lines) 386 Zero or more media descriptions 388 Time description 389 t= (time the session is active) 390 r=* (zero or more repeat times) 392 Media description 393 m= (media name and transport address) 394 i=* (media title) 395 c=* (connection information - optional if included at 396 session-level) 397 b=* (zero or more bandwidth information lines) 398 k=* (encryption key) 399 a=* (zero or more media attribute lines) 401 The set of type letters is deliberately small and not intended to be 402 extensible -- an SDP parser MUST completely ignore any session 403 description that contains a type letter that it does not understand. 404 The attribute mechanism ("a=" described below) is the primary means 405 for extending SDP and tailoring it to particular applications or 406 media. Some attributes (the ones listed in Section 6 of this memo) 407 have a defined meaning, but others may be added on an application-, 408 media- or session-specific basis. An SDP parser MUST ignore any 409 attribute it doesn't understand. 411 An SDP session description may contain URIs which reference external 412 content in the "u=", "k=" and "a=" lines. These URIs may be 413 dereferenced in some cases, making the session description non-self 414 contained. 416 The connection ("c=") and attribute ("a=") information in the 417 session-level section applies to all the media of that session unless 418 overridden by connection information or an attribute of the same name 419 in the media description. For instance, in the example below, each 420 media behaves as if it were given a "recvonly" attribute. 422 An example SDP description is: 424 v=0 425 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 426 s=SDP Seminar 427 i=A Seminar on the session description protocol 428 u=http://www.example.com/seminars/sdp.pdf 429 e=j.doe@example.com (Jane Doe) 430 c=IN IP4 224.2.17.12/127 431 t=2873397496 2873404696 432 a=recvonly 433 m=audio 49170 RTP/AVP 0 434 m=video 51372 RTP/AVP 31 435 m=application 32416 udp wb 436 a=orient:portrait 438 Text fields such as the session name and information are octet 439 strings which may contain any octet with the exceptions of 0x00 440 (Nul), 0x0a (ASCII newline) and 0x0d (ASCII carriage return). The 441 sequence CRLF (0x0d0a) is used to end a record, although parsers 442 SHOULD be tolerant and also accept records terminated with a single 443 newline character. If the "a=charset" attribute is not present, 444 these octet strings MUST be interpreted as containing ISO-10646 445 characters in UTF-8 encoding (the presence of the "a=charset" 446 attribute MAY force some fields to be interpreted differently). 448 5.1 Protocol Version ("v=") 450 v=0 452 The "v=" field gives the version of the Session Description Protocol. 453 This memo defines version 0. There is no minor version number. 455 5.2 Origin ("o=") 457 o= 458 460 The "o=" field gives the originator of the session (her username and 461 the address of the user's host) plus a session identifier and version 462 number: 464 is the user's login on the originating host, or it is "-" 465 if the originating host does not support the concept of user ids. 466 The MUST NOT contain spaces. 468 is a numeric string such that the tuple of , 469 , , and form a 470 globally unique identifier for the session. The method of 471 allocation is up to the creating tool, but it has been 472 suggested that a Network Time Protocol (NTP) format timestamp be 473 used to ensure uniqueness [8]. 475 is a version number for this session description. Its 476 usage is up to the creating tool, so long as is 477 increased when a modification is made to the session data. Again, 478 it is RECOMMENDED that an NTP format timestamp is used. 480 is a text string giving the type of network. Initially 481 "IN" is defined to have the meaning "Internet", but other values 482 MAY be registered in future (see Section 8). 484 is a text string giving the type of the address that 485 follows. Initially "IP4" and "IP6" are defined, but other values 486 MAY be registered in future (see Section 8). 488 is the address of the machine from which the 489 session was created. For an address type of IP4, this is either 490 the fully-qualified domain name of the machine, or the 491 dotted-decimal representation of the IP version 4 address of the 492 machine. For an address type of IP6, this is either the 493 fully-qualified domain name of the machine, or the compressed 494 textual representation of the IP version 6 address of the machine. 495 For both IP4 and IP6, the fully-qualified domain name is the form 496 that SHOULD be given unless this is unavailable, in which case the 497 globally unique address MAY be substituted. A local IP address 498 MUST NOT be used in any context where the SDP description might 499 leave the scope in which the address is meaningful. 501 In general, the "o=" field serves as a globally unique identifier for 502 this version of this session description, and the subfields excepting 503 the version taken together identify the session irrespective of any 504 modifications. 506 5.3 Session Name ("s=") 508 s= 510 The "s=" field is the textual session name. There MUST be one and 511 only one "s=" field per session description. The "s=" field MUST NOT 512 be empty and SHOULD contain ISO 10646 characters (but see also the 513 "a=charset" attribute). If a session has no meaningful name, the 514 value "s= " SHOULD be used (i.e. a single space as the session 515 name). 517 5.4 Session Information ("i=") 519 i= 521 The "i=" field provides textual information about the session. There 522 may be at most one session-level "i=" field per session description, 523 and at most one "i=" field per media. If the "a=charset" attribute 524 is present, it specifies the character set used in the "i=" field. 525 If the "a=charset" attribute is not present, the "i=" field MUST 526 contain ISO 10646 characters in UTF-8 encoding. 528 A single "i=" field MAY also be used for each media definition. In 529 media definitions, "i=" fields are primarily intended for labeling 530 media streams. As such, they are most likely to be useful when a 531 single session has more than one distinct media stream of the same 532 media type. An example would be two different whiteboards, one for 533 slides and one for feedback and questions. 535 The "i=" field is intended to provide a free-form human readable 536 description of the session or the purpose of a media stream. It is 537 not suitable for parsing by automata. 539 5.5 URI ("u=") 541 u= 543 A URI is a Universal Resource Identifier as used by WWW clients [4], 544 [6]. The URI should be a pointer to additional information about the 545 conference. This field is OPTIONAL, but if it is present it MUST be 546 specified before the first media field. No more than one URI field 547 is allowed per session description. 549 5.6 Email Address and Phone Number ("e=" and "p=") 551 e= 552 p= 554 The "e=" and "p=" lines specify contact information for the person 555 responsible for the conference. This is not necessarily the same 556 person that created the conference announcement. 558 Inclusion of an email address or phone number is OPTIONAL. Note that 559 the previous version of SDP specified that either an email field or a 560 phone field MUST be specified, but this was widely ignored. The 561 change brings the specification into line with common usage. 563 If the email addres or phone number are present, they MUST be 564 specified before the first media field. More than one email or phone 565 field can be given for a session description. 567 Phone numbers SHOULD be given in the form of an international public 568 telecommunication number (see ITU-T Recommendation E.164) preceded by 569 a "+". Spaces and hyphens may be used to split up a phone field to 570 aid readability if desired. For example: 572 p=+1 617 555-6011 574 Both email addresses and phone numbers can have an OPTIONAL free text 575 string associated with them, normally giving the name of the person 576 who may be contacted. This MUST be enclosed in parenthesis if it is 577 present. For example: 579 e=j.doe@example.com (Jane Doe) 581 The alternative RFC 2822 name quoting convention is also allowed for 582 both email addresses and phone numbers. For example: 584 e=Jane Doe 586 The free text string SHOULD be in the ISO-10646 character set with 587 UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if 588 the appropriate session-level "a=charset" attribute is set. 590 5.7 Connection Data ("c=") 592 c= 594 The "c=" field contains connection data. 596 A session description MUST contain either at least one "c=" field in 597 each media description or a single "c=" field at the session level. 598 It MAY contain a single session-level "c=" field and additional "c=" 599 field(s) per media description, in which case the per-media values 600 override the session-level settings for the respective media. 602 The first sub-field ("") is the network type, which is a 603 text string giving the type of network. Initially "IN" is defined to 604 have the meaning "Internet", but other values MAY be registered in 605 the future (see Section 8). 607 The second sub-field ("") is the address type. This allows 608 SDP to be used for sessions that are not IP based. Currently only 609 IP4 and IP6 are defined, but other values MAY be registered in the 610 future (see Section 8). 612 The third sub-field ("") is the connection 613 address. OPTIONAL sub-fields MAY be added after the connection 614 address depending on the value of the field. 616 When the is IP4 and IP6, the connection address is defined 617 as follows: 619 o If the session is multicast, the connection address will be an IP 620 multicast group address. If the session is not multicast, then 621 the connection address contains the unicast IP address of the 622 expected data source or data relay or data sink as determined by 623 additional attribute fields. It is not expected that unicast 624 addresses will be given in a session description that is 625 communicated by a multicast announcement, though this is not 626 prohibited. 628 o Conferences using an IPv4 multicast connection address MUST also 629 have a time to live (TTL) value present in addition to the 630 multicast address. The TTL and the address together define the 631 scope with which multicast packets sent in this conference will be 632 sent. TTL values MUST be in the range 0-255. 634 The TTL for the session is appended to the address using a slash as a 635 separator. An example is: 637 c=IN IP4 224.2.36.42/127 639 IPv6 multicast does not use TTL scoping, and hence the TTL value MUST 640 NOT be present for IPv6 multicast. It is expected that IPv6 scoped 641 addresses will be used to limit the scope of conferences. 643 Hierarchical or layered encoding schemes are data streams where the 644 encoding from a single media source is split into a number of layers. 645 The receiver can choose the desired quality (and hence bandwidth) by 646 only subscribing to a subset of these layers. Such layered encodings 647 are normally transmitted in multiple multicast groups to allow 648 multicast pruning. This technique keeps unwanted traffic from sites 649 only requiring certain levels of the hierarchy. For applications 650 requiring multiple multicast groups, we allow the following notation 651 to be used for the connection address: 653 [/]/ 655 If the number of addresses is not given it is assumed to be one. 657 Multicast addresses so assigned are contiguously allocated above the 658 base address, so that, for example: 660 c=IN IP4 224.2.1.1/127/3 662 would state that addresses 224.2.1.1, 224.2.1.2 and 224.2.1.3 are to 663 be used at a TTL of 127. This is semantically identical to including 664 multiple "c=" lines in a media description: 666 c=IN IP4 224.2.1.1/127 667 c=IN IP4 224.2.1.2/127 668 c=IN IP4 224.2.1.3/127 670 Similarly, an IPv6 example would be: 672 c=IN IP6 FF15::101/3 674 which is semantically equivalent to: 676 c=IN IP6 FF15::101 677 c=IN IP6 FF15::102 678 c=IN IP6 FF15::103 680 (remembering that the TTL field is not present in IPv6 multicast). 682 Multiple addresses or "c=" lines MAY be specified on a per-media 683 basis only if they provide multicast addresses for different layers 684 in a hierarchical or layered encoding scheme. They MUST NOT be 685 specified for a session-level "c=" field. 687 The slash notation for multiple addresses described above MUST NOT be 688 used for IP unicast addresses. 690 5.8 Bandwidth ("b=") 692 b=: 694 This OPTIONAL field denotes the proposed bandwidth to be used by the 695 session or media. The is an alphanumeric modifier giving 696 the meaning of the figure. Two values are defined in 697 this specification, but other values MAY be registered in future (see 698 Section 8 and [22], [16]): 700 CT If the bandwidth of a session or media in a session is different 701 from the bandwidth implicit from the scope, a "b=CT:..." line 702 SHOULD be supplied for the session giving the proposed upper limit 703 to the bandwidth used. The primary purpose of this is to give an 704 approximate idea as to whether two or more sessions can co-exist 705 simultaneously. When using the CT modifier with RTP, if several 706 RTP sessions are part of the conference, the conference total 707 refers to total bandwidth of all RTP sessions. 709 AS The bandwidth is interpreted to be application-specific (it will 710 be the application's concept of maximum bandwidth). Normally this 711 will coincide with what is set on the application's "maximum 712 bandwidth" control if applicable. For RTP based applications, AS 713 gives the RTP "session bandwidth" as defined in section 6.2 of 714 [14]. 716 Note that CT gives a total bandwidth figure for all the media at all 717 sites. AS gives a bandwidth figure for a single media at a single 718 site, although there may be many sites sending simultaneously. 720 A prefix "X-" is defined for names. This is intended for 721 experimental purposes only. For example: 723 b=X-YZ:128 725 Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers 726 SHOULD be registered with IANA in the standard namespace. SDP 727 parsers MUST ignore bandwidth fields with unknown modifiers. 728 Modifiers MUST be alpha-numeric and, although no length limit is 729 given, they are recommended to be short. 731 The is in kilobits per second by default. Modifiers MAY 732 specify that alternative units are to be used (the modifiers defined 733 in this memo use the default units). 735 5.9 Timing ("t=") 737 t= 739 The "t=" lines specify the start and stop times for a session. 740 Multiple "t=" lines MAY be used if a session is active at multiple 741 irregularly spaced times; each additional "t=" lines specifies an 742 additional period of time for which the session will be active. If 743 the session is active at regular times, an "r=" line (see below) 744 should be used in addition to, and following, a "t=" line - in which 745 case the "t=" line specifies the start and stop times of the repeat 746 sequence. 748 The first and second sub-fields give the start and stop times for the 749 session respectively. These values are the decimal representation of 750 Network Time Protocol (NTP) time values in seconds since 1900 [8]. 751 To convert these values to UNIX time, subtract decimal 2208988800. 753 NTP timestamps are elsewhere represented by 64 bit values which wrap 754 sometime in the year 2036. Since SDP uses an arbitrary length 755 decimal representation, this should not cause an issue (SDP 756 timestamps MUST continue counting seconds since 1900, NTP will use 757 the value modulo the 64 bit limit). 759 If the is set to zero, then the session is not bounded, 760 though it will not become active until after the . If 761 the is also zero, the session is regarded as permanent. 763 User interfaces SHOULD strongly discourage the creation of unbounded 764 and permanent sessions as they give no information about when the 765 session is actually going to terminate, and so make scheduling 766 difficult. 768 The general assumption may be made, when displaying unbounded 769 sessions that have not timed out to the user, that an unbounded 770 session will only be active until half an hour from the current time 771 or the session start time, whichever is the later. If behaviour 772 other than this is required, an end-time should be given and modified 773 as appropriate when new information becomes available about when the 774 session should really end. 776 Permanent sessions may be shown to the user as never being active 777 unless there are associated repeat times which state precisely when 778 the session will be active. In general, permanent sessions SHOULD 779 NOT be created for any session expected to have a duration of less 780 than 2 months, and should be discouraged for sessions expected to 781 have a duration of less than 6 months. 783 5.10 Repeat Times ("r=") 785 r= 787 "r=" fields specify repeat times for a session. For example, if a 788 session is active at 10am on Monday and 11am on Tuesday for one hour 789 each week for three months, then the in the 790 corresponding "t=" field would be the NTP representation of 10am on 791 the first Monday, the would be 1 week, the would be 1 hour, and the offsets would be zero and 25 793 hours. The corresponding "t=" field stop time would be the NTP 794 representation of the end of the last session three months later. By 795 default all fields are in seconds, so the "r=" and "t=" fields might 796 be: 798 t=3034423619 3042462419 799 r=604800 3600 0 90000 801 To make description more compact, times may also be given in units of 802 days, hours or minutes. The syntax for these is a number immediately 803 followed by a single case-sensitive character. Fractional units are 804 not allowed - a smaller unit should be used instead. The following 805 unit specification characters are allowed: 807 d - days (86400 seconds) 808 h - hours (3600 seconds) 809 m - minutes (60 seconds) 810 s - seconds (allowed for completeness but NOT RECOMMENDED) 812 Thus, the above session announcement could also have been written: 814 r=7d 1h 0 25h 816 Monthly and yearly repeats cannot be directly specified with a single 817 SDP repeat time - instead separate "t=" fields should be used to 818 explicitly list the session times. 820 5.11 Time Zones ("z=") 822 z= .... 824 To schedule a repeated session which spans a change from daylight 825 saving time to standard time or vice-versa, it is necessary to 826 specify offsets from the base time. This is required because 827 different time zones change time at different times of day, different 828 countries change to or from daylight time on different dates, and 829 some countries do not have daylight saving time at all. 831 Thus in order to schedule a session that is at the same time winter 832 and summer, it must be possible to specify unambiguously by whose 833 time zone a session is scheduled. To simplify this task for 834 receivers, we allow the sender to specify the NTP time that a time 835 zone adjustment happens and the offset from the time when the session 836 was first scheduled. The "z=" field allows the sender to specify a 837 list of these adjustment times and offsets from the base time. 839 An example might be: 841 z=2882844526 -1h 2898848070 0 843 This specifies that at time 2882844526 the time base by which the 844 session's repeat times are calculated is shifted back by 1 hour, and 845 that at time 2898848070 the session's original time base is restored. 846 Adjustments are always relative to the specified start time - they 847 are not cumulative. Adjustments apply to all "t=" and "r=" lines in 848 a session description. 850 If a session is likely to last several years, it is expected that the 851 session announcement will be modified periodically rather than 852 transmit several years worth of adjustments in one session 853 announcement. 855 5.12 Encryption Keys ("k=") 857 k= 858 k=: 860 If transported over a secure and trusted channel, the session 861 description protocol MAY be used to convey encryption keys. A simple 862 mechanism for key exchange is provided by the key field ("k=") 863 although this is primarily supported for compatibility with older 864 implementations and its use is NOT RECOMMENDED. Work is in progress 865 to define new key exchange mechanisms for use with SDP [20][21] and 866 it is expected that new applications will use those mechanisms. 868 A key field is permitted before the first media entry (in which case 869 it applies to all media in the session), or for each media entry as 870 required. The format of keys and their usage is outside the scope of 871 this document, and the key field provides no way to indicate the 872 encryption algorithm to be used, key type, or other information about 873 the key: this is assumed to be provided by the higher-level protocol 874 using SDP. If there is a need to convey this information within SDP, 875 the extensions mentioned previously SHOULD be used. Many security 876 protocols require two keys: one for confidentiality, another for 877 integrity. This specification does not support transfer of two keys. 879 The method indicates the mechanism to be used to obtain a usable key 880 by external means, or from the encoded encryption key given. The 881 following methods are defined: 883 k=clear: 885 The encryption key is included untransformed in this key field. 886 This method MUST NOT be used unless it can be guaranteed that 887 the SDP is conveyed over a secure channel. The encryption key 888 is interpreted as text according to the charset attribute, use 889 the "k=base64:" method to convey characters that are otherwise 890 prohibited in SDP. 892 k=base64: 894 The encryption key is included in this key field but has been 895 base64 encoded [13] because it includes characters that are 896 prohibited in SDP. This method MUST NOT be used unless it can 897 be guaranteed that the SDP is conveyed over a secure channel. 899 k=uri: 901 A Universal Resource Identifier is included in the key field. 902 The URI refers to the data containing the key, and may require 903 additional authentication before the key can be returned. When 904 a request is made to the given URI, the reply should specify 905 the encoding for the key. The URI is often a secure HTTP URI, 906 although this is not required. 908 k=prompt 910 No key is included in this SDP description, but the session or 911 media stream referred to by this key field is encrypted. The 912 user should be prompted for the key when attempting to join the 913 session, and this user-supplied key should then be used to 914 decrypt the media streams. The use of user-specified keys is 915 NOT RECOMMENDED, since such keys tend to have weak security 916 properties. 918 The key field MUST NOT be used unless it can be guaranteed that the 919 SDP is conveyed over a secure and trusted channel. An example of 920 such a channel might be SDP embedded inside an S/MIME message or a 921 TLS protected HTTP or SIP session. It is important to ensure that 922 the secure channel is with the party that is authorized to join the 923 session, not an intermediary: if a caching proxy server is used, it 924 is important to ensure that the proxy is either trusted or unable to 925 access the SDP. Definition of appropriate security measures is 926 beyond the scope of this specification, and should be defined by the 927 users of SDP. 929 5.13 Attributes ("a=") 931 a= 932 a=: 934 Attributes are the primary means for extending SDP. Attributes may 935 be defined to be used as "session-level" attributes, "media-level" 936 attributes, or both. 938 A media description may have any number of attributes ("a=" fields) 939 which are media specific. These are referred to as "media-level" 940 attributes and add information about the media stream. Attribute 941 fields can also be added before the first media field; these 942 "session-level" attributes convey additional information that applies 943 to the conference as a whole rather than to individual media; an 944 example might be the conference's floor control policy. 946 Attribute fields may be of two forms: 948 o A property attribute is simply of the form "a=". These are 949 binary attributes, and the presence of the attribute conveys that 950 the attribute is a property of the session. An example might be 951 "a=recvonly". 953 o A value attribute is of the form "a=:". For 954 example, a whiteboard could have the value attribute 955 "a=orient:landscape" 957 Attribute interpretation depends on the media tool being invoked. 958 Thus receivers of session descriptions should be configurable in 959 their interpretation of session descriptions in general and of 960 attributes in particular. 962 Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. 964 Attribute values are octet strings, and MAY use any octet value 965 except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute 966 values are to be interpreted as in ISO-10646 character set with UTF-8 967 encoding. Unlike other text fields, attribute values are NOT 968 normally affected by the "charset" attribute as this would make 969 comparisons against known values problematic. However, when an 970 attribute is defined, it can be defined to be charset-dependent, in 971 which case it's value should be interpreted in the session charset 972 rather than in ISO-10646. 974 Attributes MUST be registered with IANA (see Section 8). If an 975 attribute is received that is not understood, it MUST be ignored by 976 the receiver. 978 5.14 Media Descriptions ("m=") 980 m= ... 982 A session description may contain a number of media descriptions. 983 Each media description starts with an "m=" field, and is terminated 984 by either the next "m=" field or by the end of the session 985 description. A media field has several sub-fields: 987 is the media type. Currently defined media are "audio", 988 "video", "text" and "application", although this list may be 989 extended in future (see Section 8). 991 is the transport port to which the media stream is sent. The 992 meaning of the transport port depends on the network being used as 993 specified in the relevant "c=" field, and on the transport 994 protocol defined in the sub-field of the media field. 995 Other ports used by the media application (such as the RTCP port 997 [14]) MAY be derived algorithmically from the base media port or 998 MAY be specified in a separate attribute (for example "a=rtcp:" as 999 defined in [17]). 1001 For applications where hierarchically encoded streams are being 1002 sent to a unicast address, it may be necessary to specify multiple 1003 transport ports. This is done using a similar notation to that 1004 used for IP multicast addresses in the "c=" field: 1006 m= / 1008 In such a case, the ports used depend on the transport protocol. 1009 For RTP, the default is that only the even numbered ports are used 1010 for data with the corresponding one-higher odd ports used for the 1011 RTCP belonging to the RTP session, and the 1012 denoting the number of RTP sessions. For example: 1014 m=video 49170/2 RTP/AVP 31 1016 would specify that ports 49170 and 49171 form one RTP/RTCP pair 1017 and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the 1018 transport protocol and 31 is the format (see below). If 1019 non-contiguous ports are required, they must be signalled using a 1020 separate attribute (for example "a=rtcp:" as defined in [17]). 1022 If multiple addresses are specified in the "c=" field and multiple 1023 ports are specified in the "m=" field, a one-to-one mapping from 1024 port to the corresponding address is implied. For example: 1026 c=IN IP4 224.2.1.1/127/2 1027 m=video 49170/2 RTP/AVP 31 1029 would imply that address 224.2.1.1 is used with ports 49170 and 1030 49171, and address 224.2.1.2 is used with ports 49172 and 49173. 1032 is the transport protocol. The meaning of the transport 1033 protocol is dependent on the address type field in the relevant 1034 "c=" field. Thus a "c=" field of IP4 indicates that the transport 1035 protocol runs over IP4. The following transport protocols are 1036 defined, but may be extended through registration of new protocols 1037 with IANA (see Section 8): 1039 * udp: denotes an unspecified protocol running over UDP. 1041 * RTP/AVP: denotes RTP [14] used under the RTP Profile for Audio 1042 and Video Conferences with Minimal Control [15] running over 1043 UDP. 1045 * RTP/SAVP: denotes the Secure Real-time Transport Protocol [18] 1046 running over UDP. 1048 The main reason to specify the transport-protocol in addition to 1049 the media format is that the same standard media formats may be 1050 carried over different transport protocols even when the network 1051 protocol is the same - a historical example is vat PCM audio and 1052 RTP PCM audio. In addition, relays and monitoring tools that are 1053 transport-protocol-specific but format-independent are possible. 1055 is a media format description. The fourth and any subsequent 1056 sub-fields describe the format of the media. The interpretation 1057 of the media format depends on the value of the sub-field. 1059 If the sub-field is "RTP/AVP" or "RTP/SAVP" the 1060 sub-fields contain RTP payload type numbers. When a list of 1061 payload type numbers is given, this implies that all of these 1062 payload formats MAY be used in the session, but the first of these 1063 formats SHOULD be used as the default format for the session. For 1064 dynamic payload type assignments the "a=rtpmap:" attribute (see 1065 Section 6) SHOULD be used to map from an RTP payload type number 1066 to a media encoding name that identifies the payload format. The 1067 "a=fmtp:" attribute MAY be used to specify format parameters (see 1068 Section 6). 1070 If the sub-field is "udp" the sub-fields MUST 1071 reference a media type describing the format under the "audio", 1072 "text" and "video" top-level MIME types. The media type 1073 registration SHOULD define the packetization format for use with 1074 UDP transport. 1076 For media using other transport protocols, the field is 1077 protocol specific. Rules for interpretation of the 1078 sub-field MUST be defined when registering new protocols (see 1079 section 8.2.2). 1081 6. Suggested Attributes 1083 The following attributes are defined. Since application writers may 1084 add new attributes as they are required, this list is not exhaustive. 1085 Registration procedures for new attributes are defined in Section 1086 8.2.4. 1088 a=cat: 1090 This attribute gives the dot-separated hierarchical category 1091 of the session. This is to enable a receiver to filter 1092 unwanted sessions by category. It is a session-level 1093 attribute, and is not dependent on charset. 1095 a=keywds: 1097 Like the cat attribute, this is to assist identifying wanted 1098 sessions at the receiver. This allows a receiver to select 1099 interesting session based on keywords describing the purpose 1100 of the session. It is a session-level attribute. It is a 1101 charset dependent attribute, meaning that its value should be 1102 interpreted in the charset specified for the session 1103 description if one is specified, or by default in ISO 1104 10646/UTF-8. 1106 a=tool: 1108 This gives the name and version number of the tool used to 1109 create the session description. It is a session-level 1110 attribute, and is not dependent on charset. 1112 a=ptime: 1114 This gives the length of time in milliseconds represented by 1115 the media in a packet. This is probably only meaningful for 1116 audio data, but may be used with other media types if it makes 1117 sense. It should not be necessary to know ptime to decode RTP 1118 or vat audio, and it is intended as a recommendation for the 1119 encoding/packetisation of audio. It is a media attribute, and 1120 is not dependent on charset. 1122 a=maxptime: 1124 The maximum amount of media which can be encapsulated in each 1125 packet, expressed as time in milliseconds. The time SHALL be 1126 calculated as the sum of the time the media present in the 1127 packet represents. The time SHOULD be a multiple of the frame 1128 size. This attribute is probably only meaningful for audio 1129 data, but may be used with other media types if it makes 1130 sense. It is a media attribute, and is not dependent on 1131 charset. Note that this attribute was introduced after RFC 1132 2327, and non updated implementations will ignore this 1133 attribute. 1135 a=rtpmap: / 1136 [/] 1138 This attribute maps from an RTP payload type number (as used in 1139 an "m=" line) to an encoding name denoting the payload format 1140 to be used. It also provides information on the clock rate and 1141 encoding parameters. It is a media level attribute that is not 1142 dependent on charset. 1144 While an RTP profile may make static assignments of payload 1145 type numbers to payload formats, it is more common for that 1146 assignment to be done dynamically using "a=rtpmap:" attributes. 1147 As an example of a static payload type, consider u-law PCM 1148 coded single channel audio sampled at 8kHz. This is completely 1149 defined in the RTP Audio/Video profile as payload type 0, so 1150 there is no need for an "a=rtpmap: attribute, and the media for 1151 such a stream sent to UDP port 49232 can be specified as: 1153 m=audio 49232 RTP/AVP 0 1155 An example of a dynamic payload type is 16 bit linear encoded 1156 stereo audio sampled at 16 kHz. If we wish to use the dynamic 1157 RTP/AVP payload type 98 for this stream, additional information 1158 is required to decode it: 1160 m=audio 49232 RTP/AVP 98 1161 a=rtpmap:98 L16/16000/2 1163 Up to one rtpmap attribute can be defined for each media format 1164 specified. Thus we might have: 1166 m=audio 49230 RTP/AVP 96 97 98 1167 a=rtpmap:96 L8/8000 1168 a=rtpmap:97 L16/8000 1169 a=rtpmap:98 L16/11025/2 1171 RTP profiles that specify the use of dynamic payload types MUST 1172 define the set of valid encoding names and/or a means to 1173 register encoding names if that profile is to be used with SDP. 1174 The "RTP/AVP" and "RTP/SAVP" profiles use MIME sub-types for 1175 encoding names, under the top-level media type denoted in the 1176 "m=" line. In the example above, the media types are "audio/l8" 1177 and "audio/l16". 1179 For audio streams, indicates the 1180 number of audio channels. This parameter is OPTIONAL and 1181 may be omitted if the number of channels is one, provided 1182 no additional parameters are needed. 1184 For video streams, no encoding parameters are currently 1185 specified. 1187 Additional encoding parameters MAY be defined in the future, 1188 but codec specific parameters SHOULD NOT be added. Parameters 1189 added to an "a=rtpmap:" attribute SHOULD only be those required 1190 for a session directory to make the choice of appropriate media 1191 to participate in a session. Codec-specific parameters should 1192 be added in other attributes (for example, "a=fmtp:"). 1194 Note: RTP audio formats typically do not include information 1195 about the number of samples per packet. If a non-default (as 1196 defined in the RTP Audio/Video Profile) packetisation is 1197 required, the "ptime" attribute is used as given below. 1199 a=recvonly 1201 This specifies that the tools should be started in receive 1202 only mode where applicable. It can be either a session or 1203 media attribute, and is not dependent on charset. Note that 1204 recvonly applies to the media only, not to any associated 1205 control protocol (e.g. an RTP based system in recvonly mode 1206 SHOULD still send RTCP packets). 1208 a=sendrecv 1210 This specifies that the tools should be started in send and 1211 receive mode. This is necessary for interactive conferences 1212 with tools that default to receive only mode. It can be either 1213 a session or media attribute, and is not dependent on charset. 1215 If none of the attributes "sendonly", "recvonly", "inactive", 1216 and "sendrecv" is present, "sendrecv" SHOULD be assumed as the 1217 default for sessions which are not of the conference type 1218 "broadcast" or "H332" (see below). 1220 a=sendonly 1222 This specifies that the tools should be started in send-only 1223 mode. An example may be where a different unicast address is 1224 to be used for a traffic destination than for a traffic 1225 source. In such a case, two media descriptions may be use, 1226 one sendonly and one recvonly. It can be either a session or 1227 media attribute, but would normally only be used as a media 1228 attribute, and is not dependent on charset. Note that sendonly 1229 applies only to the media, and any associated control protocol 1230 (e.g. RTCP) SHOULD still be received and processed as normal. 1232 a=inactive 1234 This specifies that the tools should be started in inactive 1235 mode. This is necessary for interactive conferences where 1236 users can put other users on hold. No media is sent over an 1237 inactive media stream. Note that an RTP based system SHOULD 1238 still send RTCP, even if started inactive. It can be either a 1239 session or media attribute, and is not dependent on charset. 1241 a=orient: 1243 Normally this is only used in a whiteboard media specification. 1244 It specifies the orientation of a the whiteboard on the screen. 1245 It is a media attribute. Permitted values are "portrait", 1246 "landscape" and "seascape" (upside down landscape). It is not 1247 dependent on charset. 1249 a=type: 1251 This specifies the type of the conference. Suggested values 1252 are "broadcast", "meeting", "moderated", "test" and "H332". 1253 "recvonly" should be the default for "type:broadcast" 1254 sessions, "type:meeting" should imply "sendrecv" and 1255 "type:moderated" should indicate the use of a floor control 1256 tool and that the media tools are started so as to mute new 1257 sites joining the conference. 1259 Specifying the attribute "type:H332" indicates that this 1260 loosely coupled session is part of a H.332 session as defined 1261 in the ITU H.332 specification [15]. Media tools should be 1262 started "recvonly". 1264 Specifying the attribute "type:test" is suggested as a hint 1265 that, unless explicitly requested otherwise, receivers can 1266 safely avoid displaying this session description to users. 1268 The type attribute is a session-level attribute, and is not 1269 dependent on charset. 1271 a=charset: 1273 This specifies the character set to be used to display the 1274 session name and information data. By default, the ISO-10646 1275 character set in UTF-8 encoding is used. If a more compact 1276 representation is required, other character sets may be used. 1277 For example, the ISO 8859-1 is specified with the following 1278 SDP attribute: 1280 a=charset:ISO-8859-1 1282 This is a session-level attribute and is not dependent on 1283 charset. The charset specified MUST be one of those registered 1284 with IANA, such as ISO-8859-1. The character set identifier is 1285 a US-ASCII string and MUST be compared against the IANA 1286 identifiers using a case insensitive comparison. If the 1287 identifier is not recognised or not supported, all strings that 1288 are affected by it SHOULD be regarded as octet strings. 1290 Note that a character set specified MUST still prohibit the 1291 use of bytes 0x00 (Nul), 0x0A (LF) and 0x0d (CR). Character 1292 sets requiring the use of these characters MUST define a 1293 quoting mechanism that prevents these bytes appearing within 1294 text fields. 1296 a=sdplang: 1298 This can be a session level attribute or a media level 1299 attribute. As a session level attribute, it specifies the 1300 language for the session description. As a media level 1301 attribute, it specifies the language for any media-level SDP 1302 information field associated with that media. Multiple 1303 sdplang attributes can be provided either at session or media 1304 level if multiple languages in the session description or 1305 media use multiple languages, in which case the order of the 1306 attributes indicates the order of importance of the various 1307 languages in the session or media from most important to least 1308 important. 1310 In general, sending session descriptions consisting of 1311 multiple languages is discouraged. Instead, multiple 1312 descriptions SHOULD be sent describing the session, one in 1313 each language. However this is not possible with all 1314 transport mechanisms, and so multiple sdplang attributes are 1315 allowed although NOT RECOMMENDED. 1317 The "sdplang" attribute value must be a single RFC 3066 1318 language tag in US-ASCII [6]. It is not dependent on 1319 the charset attribute. An "sdplang" attribute SHOULD be 1320 specified when a session is of sufficient scope to cross 1321 geographic boundaries where the language of recipients cannot 1322 be assumed, or where the session is in a different language 1323 from the locally assumed norm. 1325 a=lang: 1327 This can be a session level attribute or a media level 1328 attribute. As a session level attribute, it specifies the 1329 default language for the session being described. As a media 1330 level attribute, it specifies the language for that media, 1331 overriding any session-level language specified. Multiple 1332 lang attributes can be provided either at session or media 1333 level if the session description or media use multiple 1334 languages, in which case the order of the attributes indicates 1335 the order of importance of the various languages in the 1336 session or media from most important to least important. 1338 The "lang" attribute value must be a single RFC 3066 language 1339 tag in US-ASCII [6]. It is not dependent on the charset 1340 attribute. A "lang" attribute SHOULD be specified when a 1341 session is of sufficient scope to cross geographic boundaries 1342 where the language of recipients cannot be assumed, or where 1343 the session is in a different language from the locally 1344 assumed norm. 1346 a=framerate: 1348 This gives the maximum video frame rate in frames/sec. It is 1349 intended as a recommendation for the encoding of video data. 1350 Decimal representations of fractional values using the 1351 notation "." are allowed. It is a 1352 media attribute, defined only for video media, and is not 1353 dependent on charset. 1355 a=quality: 1357 This gives a suggestion for the quality of the encoding as an 1358 integer value. The intention of the quality attribute for 1359 video is to specify a non-default trade-off between frame-rate 1360 and still-image quality. For video, the value in the range 0 1361 to 10, with the following suggested meaning: 1363 10 - the best still-image quality the compression scheme 1364 can give. 1365 5 - the default behaviour given no quality suggestion. 1366 0 - the worst still-image quality the codec designer 1367 thinks is still usable. 1369 It is a media attribute, and is not dependent on charset. 1371 a=fmtp: 1373 This attribute allows parameters that are specific to a 1374 particular format to be conveyed in a way that SDP doesn't 1375 have to understand them. The format must be one of the 1376 formats specified for the media. Format-specific parameters 1377 may be any set of parameters required to be conveyed by SDP 1378 and given unchanged to the media tool that will use this 1379 format. At most one instance of this attribute is allowed 1380 for each format. 1382 It is a media attribute, and is not dependent on charset. 1384 7. Security Considerations 1386 SDP is a session description format that describes multimedia 1387 sessions. A session description SHOULD NOT be trusted unless it has 1388 been obtained by an authenticated transport protocol from a trusted 1389 source. Many different transport protocols may be used to distribute 1390 session description, and the nature of the authentication will differ 1391 from transport to transport. 1393 One transport that will frequently be used to distribute session 1394 descriptions is the Session Announcement Protocol (SAP). SAP 1395 provides both encryption and authentication mechanisms but due to the 1396 nature of session announcements it is likely that there are many 1397 occasions where the originator of a session announcement cannot be 1398 authenticated because they are previously unknown to the receiver of 1399 the announcement and because no common public key infrastructure is 1400 available. 1402 On receiving a session description over an unauthenticated transport 1403 mechanism or from an untrusted party, software parsing the session 1404 should take a few precautions. Session descriptions contain 1405 information required to start software on the receivers system. 1406 Software that parses a session description MUST NOT be able to start 1407 other software except that which is specifically configured as 1408 appropriate software to participate in multimedia sessions. It is 1409 normally considered inappropriate for software parsing a session 1410 description to start, on a user's system, software that is 1411 appropriate to participate in multimedia sessions, without the user 1412 first being informed that such software will be started and giving 1413 their consent. Thus a session description arriving by session 1414 announcement, email, session invitation, or WWW page MUST NOT deliver 1415 the user into an interactive multimedia session unless the user has 1416 explicitly pre-authorized such action. As it is not always simple to 1417 tell whether a session is interactive or not, applications that are 1418 unsure should assume sessions are interactive. 1420 In this specification, there are no attributes which would allow the 1421 recipient of a session description to be informed to start multimedia 1422 tools in a mode where they default to transmitting. Under some 1423 circumstances it might be appropriate to define such attributes. If 1424 this is done an application parsing a session description containing 1425 such attributes SHOULD either ignore them, or inform the user that 1426 joining this session will result in the automatic transmission of 1427 multimedia data. The default behaviour for an unknown attribute is 1428 to ignore it. 1430 Session descriptions may be parsed at intermediate systems such as 1431 firewalls for the purposes of opening a hole in the firewall to allow 1432 the participation in multimedia sessions. It is considered 1433 inappropriate for a firewall to open such holes for unicast data 1434 streams unless the session description comes in a request from inside 1435 the firewall. For multicast sessions, it is likely that local 1436 administrators will apply their own policies, but the exclusive use 1437 of "local" or "site-local" administrative scope within the firewall 1438 and the refusal of the firewall to open a hole for such scopes will 1439 provide separation of global multicast sessions from local ones. 1441 Use of the "k=" field poses a significant security risk, since it 1442 conveys session encryption keys in the clear. SDP MUST NOT be used 1443 to convey key material, unless it can be guaranteed that the channel 1444 over which the SDP is delivered is both private and authenticated. 1446 8. IANA Considerations 1448 8.1 The "application/sdp" media type 1450 One MIME type is to be registered, as defined below. This updates 1451 the previous definition from RFC 2327. 1453 To: ietf-types@iana.org 1454 Subject: Registration of media type "application/sdp" 1456 MIME media type name: application 1458 MIME subtype name: sdp 1460 Required parameters: None. 1462 Optional parameters: None. 1464 Encoding considerations: 1465 See section 5 of RFC XXXX 1467 Security considerations: 1468 See section 8 of RFC XXXX 1470 Interoperability considerations: 1471 See RFC XXXX 1473 Published specification: 1475 See RFC XXXX 1477 Applications which use this media type: 1478 Voice over IP, video teleconferencing, streaming media, instant 1479 messaging, etc. See also section 3 of RFC XXXX. 1481 Additional information: 1483 Magic number(s): None. 1484 File extension(s): The extension ".sdp" is commonly used. 1485 Macintosh File Type Code(s): "sdp " 1487 Person & email address to contact for further information: 1488 Colin Perkins 1489 IETF MMUSIC working group 1491 Intended usage: COMMON 1493 Author/Change controller: 1494 Authors of RFC XXXX 1495 IETF MMUSIC working group delegated from the IESG 1497 8.2 Registration of Parameters 1499 There are seven field names that may be registered with IANA. Using 1500 the terminology in the SDP specification BNF, they are "media", 1501 "proto", "fmt", "att-field", "bwtype", "nettype" and "addrtype". 1503 8.2.1 Media types ("media") 1505 The set of media types is intended to be small and SHOULD NOT be 1506 extended except under rare circumstances. The same rules should 1507 apply for media names as for top-level MIME content types, and where 1508 possible the same name should be registered for SDP as for MIME. For 1509 media other than existing MIME top-level content types, a 1510 standards-track RFC MUST be produced for a new top-level content type 1511 to be registered, and the registration MUST provide good 1512 justification why no existing media name is appropriate (the 1513 "Standards Action" policy of RFC 2434 [5]. 1515 This memo registers the media types "audio", "video", "text" and 1516 "application". 1518 8.2.2 Transport protocols ("proto") 1520 The "proto" field describes the transport protocol used. This SHOULD 1521 reference a standards-track protocol RFC. This memo registers three 1522 values: "RTP/AVP" is a reference to RTP [14] used under the RTP 1523 Profile for Audio and Video Conferences with Minimal Control [15] 1524 running over UDP/IP, "RTP/SAVP" is a reference to the Secure 1525 Real-time Transport Protocol [18], and "udp" indicates an unspecified 1526 protocol over UDP. 1528 If other RTP profiles are defined in the future, their "proto" name 1529 SHOULD be specified in the same manner. For example, an RTP profile 1530 whose short name is "XYZ" would be denoted by a "proto" field of 1531 "RTP/XYZ". 1533 New transport protocols SHOULD be registered with IANA. 1534 Registrations MUST reference an RFC describing the protocol. Such an 1535 RFC MAY be Experimental or Informational, although it is preferable 1536 if it is Standards-Track. Registrations MUST also define the rules 1537 by which their "fmt" namespace is managed (see below). 1539 8.2.3 Media formats ("fmt") 1541 Each transport protocol, defined by the "proto" field, has an 1542 associated "fmt" namespace that describes the media formats which may 1543 conveyed by that protocol. Formats cover all the possible encodings 1544 that might want to be transported in a multimedia session. 1546 RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST 1547 use the payload type number as their "fmt" value. If the payload 1548 type number is dynamically assigned by this session description, an 1549 additional "rtpmap" attribute MUST be included to specify the format 1550 name and parameters as defined by the MIME type registration for the 1551 payload format. It is RECOMMENDED that other RTP profiles which are 1552 registered (in combination with RTP) as SDP transport protocols 1553 specify the same rules for the "fmt" namespace. 1555 For the "udp" protocol, new formats SHOULD be registered. Use of an 1556 existing MIME subtype for the format is encouraged. If no MIME 1557 subtype exists, it is RECOMMENDED that a suitable one is registered 1558 through the IETF process (RFC 2048) by production of, or reference 1559 to, a standards-track RFC that defines the transport protocol for the 1560 format. 1562 For other protocols, formats MAY be registered according to the rules 1563 of the associated "proto" specification. 1565 Registrations of new formats MUST specify which transport protocols 1566 they apply to. 1568 8.2.4 Attribute names ("att-field") 1570 Attribute field names ("att-field") MUST be registered with IANA and 1571 documented, because of noticeable issues due to conflicting 1572 attributes under the same name. Unknown attributes in SDP are simply 1573 ignored, but conflicting ones that fragment the protocol are a 1574 serious problem. 1576 New attribute registerations are accepted according to the 1577 "Specification Required" policy of RFC 2434, provided that the 1578 specification includes the following information: 1580 o contact name, email address and telephone number 1582 o attribute-name (as it will appear in SDP) 1584 o long-form attribute name in English 1586 o type of attribute (session level, media level, or both) 1588 o whether the attribute value is subject to the charset attribute. 1590 o a one paragraph explanation of the purpose of the attribute. 1592 o a specification of appropriate attribute values for this 1593 attribute. 1595 The above is the minimum that IANA will accept. Attributes that are 1596 expected to see widespread use and interoperability, SHOULD be 1597 documented with a standards-track RFC that specifies the attribute 1598 more precisely. 1600 Submitters of registrations should ensure that the specification is 1601 in the spirit of SDP attributes, most notably that the attribute is 1602 platform independent in the sense that it makes no implicit 1603 assumptions about operating systems and does not name specific pieces 1604 of software in a manner that might inhibit interoperability. 1606 IANA is requested to register the following initial set of attribute 1607 names ("att-field" values), with definitions as in Section 6 of this 1608 memo (these definitions update those in RFC 2327): 1610 Name | Session or Media level? | Dependent on charset? 1611 ----------+-------------------------+---------------------- 1612 cat | Session | No 1613 keywds | Session | Yes 1614 tool | Session | No 1615 ptime | Media | No 1616 maxptime | Media | No 1617 rtpmap | Media | No 1618 recvonly | Either | No 1619 sendrecv | Either | No 1620 sendonly | Either | No 1621 inactive | Either | No 1622 orient | Media | No 1623 type | Session | No 1624 charset | Session | No 1625 sdplang | Either | No 1626 lang | Either | No 1627 framerate | Media | No 1628 quality | Media | No 1629 fmtp | Media | No 1631 8.2.5 Bandwidth specifiers ("bwtype") 1633 A proliferation of bandwidth specifiers is strongly discouraged. 1635 New bandwidth specifiers ("bwtype" fields) MUST be registered with 1636 IANA. The submission MUST reference a standards-track RFC specifying 1637 the semantics of the bandwidth specifier precisely, and indicating 1638 when it should be used, and why the existing registered bandwidth 1639 specifiers do not suffice. 1641 IANA is requested to register the bandwith specifiers "CT" and "AS" 1642 with definitions as in Section 5.8 of this memo (these definitions 1643 update those in RFC 2327). 1645 8.2.6 Network types ("nettype") 1647 New network types (the "nettype" field) may be registered with IANA 1648 if SDP needs to be used in the context of non-Internet environments. 1649 Whilst these are not normally the preserve of IANA, there may be 1650 circumstances when an Internet application needs to interoperate with 1651 a non- Internet application, such as when gatewaying an Internet 1652 telephony call into the PSTN. The number of network types should be 1653 small and should be rarely extended. A new network type cannot be 1654 registered without registering at least one address type to be used 1655 with that network type. A new network type registration MUST 1656 reference an RFC which gives details of the network type and address 1657 type and specifies how and when they would be used. 1659 IANA is requested to register the network type "IN" to represent the 1660 Internet, with definition as in Sections 5.2 and 5.7 of this memo 1661 (these definitions update those in RFC 2327). 1663 8.2.7 Address types ("addrtype") 1665 New address types ("addrtype") may be registered with IANA. An 1666 address type is only meaningful in the context of a network type, and 1667 any registration of an address type MUST specify a registered network 1668 type, or be submitted along with a network type registration. A new 1669 address type registration MUST reference an RFC giving details of the 1670 syntax of the address type. Address types are not expected to be 1671 registered frequently. 1673 IANA is requested to register the address types "IP4" and "IP6" with 1674 definitions as in Sections 5.2 and 5.7 of this memo (these 1675 definitions update those in RFC 2327). 1677 8.2.8 Registration Procedure 1679 In the RFC documentation that registers SDP "media", "proto", "fmt", 1680 "bwtype", "nettype" and "addrtype" fields, the authors MUST include 1681 the following information for IANA to place in the appropriate 1682 registry: 1684 o contact name, email address and telephone number 1686 o name being registered (as it will appear in SDP) 1688 o long-form name in English 1690 o type of name ("media", "proto", "fmt", "bwtype", "nettype", or 1691 "addrtype") 1693 o a one paragraph explanation of the purpose of the registered name. 1695 o a reference to the specification for the registered name (this 1696 will typically be an RFC number). 1698 IANA may refer any registration to the IESG Transport Area Directors 1699 for review, and may request revisions to be made before a 1700 registration will be made. 1702 8.3 Encryption Key Access Methods 1704 The IANA currently maintains a table of SDP encryption key access 1705 method ("enckey") names. This table is obsolete and SHOULD be 1706 removed, since the "k=" line is not extensible. New registrations 1707 MUST NOT be accepted. 1709 Appendix A. SDP Grammar 1711 This appendix provides an Augmented BNF grammar for SDP. ABNF is 1712 defined in [2]. 1714 ; SDP Syntax 1715 session-description = proto-version 1716 origin-field 1717 session-name-field 1718 information-field 1719 uri-field 1720 email-fields 1721 phone-fields 1722 connection-field 1723 bandwidth-fields 1724 time-fields 1725 key-field 1726 attribute-fields 1727 media-descriptions 1729 proto-version = "v=" 1*DIGIT CRLF 1730 ;this memo describes version 0 1732 origin-field = "o=" username SP sess-id SP sess-version SP 1733 nettype SP addrtype SP unicast-address CRLF 1735 session-name-field = "s=" text CRLF 1737 information-field = ["i=" text CRLF] 1739 uri-field = ["u=" uri CRLF] 1741 email-fields = *("e=" email-address CRLF) 1743 phone-fields = *("p=" phone-number CRLF) 1745 connection-field = ["c=" nettype SP addrtype SP 1746 connection-address CRLF] 1747 ;a connection field must be present 1748 ;in every media description or at the 1749 ;session-level 1751 bandwidth-fields = *("b=" bwtype ":" bandwidth CRLF) 1752 time-fields = 1*( "t=" start-time SP stop-time 1753 *(CRLF repeat-fields) CRLF) 1754 [zone-adjustments CRLF] 1756 repeat-fields = "r=" repeat-interval SP typed-time 1757 1*(SP typed-time) 1759 zone-adjustments = "z=" time SP ["-"] typed-time 1760 *(SP time SP ["-"] typed-time) 1762 key-field = ["k=" key-type CRLF] 1764 attribute-fields = *("a=" attribute CRLF) 1766 media-descriptions = *( media-field 1767 information-field 1768 *connection-field 1769 bandwidth-fields 1770 key-field 1771 attribute-fields ) 1773 media-field = "m=" media SP port ["/" integer] 1774 SP proto 1*(SP fmt) CRLF 1776 ; sub-rules of 'o=' 1777 username = non-ws-string 1778 ;pretty wide definition, but doesn't 1779 ;include space 1781 sess-id = 1*DIGIT 1782 ;should be unique for this username/host 1784 sess-version = 1*DIGIT 1785 ;0 is a new session 1787 nettype = token 1788 ;typically "IN" 1790 addrtype = token 1791 ;typically "IP4" or "IP6" 1793 ; sub-rules of 'u=' 1794 uri = URI-reference 1795 ; see RFC2396 and RFC2732 1797 ; sub-rules of 'e=' 1798 email-address = email *SP "(" 1*email-safe ")" / 1799 1*email-safe "<" email ">" / 1800 email 1802 email = addr-spec ; defined in RFC2822 1803 ; modified to remove CFWS 1805 ; sub-rules of 'p=' 1806 phone-number = phone *SP "(" 1*email-safe ")" / 1807 1*email-safe "<" phone ">" / 1808 phone 1810 phone = ["+"] DIGIT 1*(SP / "-" / DIGIT) 1812 ; sub-rules of 'c=' 1813 connection-address = multicast-address / unicast-address 1815 ; sub-rules of 'b=' 1816 bwtype = token 1818 bandwidth = 1*DIGIT 1820 ; sub-rules of 't=' 1821 start-time = time / "0" 1823 stop-time = time / "0" 1825 time = POS-DIGIT 9*DIGIT 1826 ; Decimal representation of NTP time in 1827 ; seconds since 1900. The representation 1828 ; of NTP time is an unbounded length field 1829 ; containing at least 10 digits. Unlike the 1830 ; 64-bit representation used elsewhere, time 1831 ; in SDP does not wrap in the year 2036. 1833 ; sub-rules of 'r=' and 'z=' 1834 repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] 1836 typed-time = 1*DIGIT [fixed-len-time-unit] 1838 fixed-len-time-unit = "d" / "h" / "m" / "s" 1840 ; sub-rules of 'k=' 1841 key-type = "prompt" / 1842 "clear:" text / 1843 "base64:" base64 / 1844 "uri:" uri 1846 base64 = *base64-unit [base64-pad] 1847 base64-unit = 4base64-char 1848 base64-pad = 2base64-char "==" / 3base64-char "=" 1849 base64-char = ALPHA / DIGIT / "+" / "/" 1851 ; sub-rules of 'a=' 1852 attribute = (att-field ":" att-value) / att-field 1854 att-field = token 1856 att-value = byte-string 1858 ; sub-rules of 'm=' 1859 media = token 1860 ;typically "audio", "video", "text" or 1861 ;"application" 1863 fmt = token 1864 ;typically an RTP payload type for audio 1865 ;and video media 1867 proto = token *("/" token) 1868 ;typically "RTP/AVP" or "udp" 1870 port = 1*DIGIT 1871 ;should be either "0" or in the range "1024" 1872 ;to "65535" inclusive for UDP based media 1873 ;(a value of "0" is used to signal special 1874 ;conditions in some uses of SDP) 1876 ; generic sub-rules: addressing 1877 unicast-address = IP4-address / IP6-address / FQDN / extn-addr 1879 multicast-address = IP4-multicast / IP6-multicast / extn-addr 1881 IP4-multicast = m1 3( "." decimal-uchar ) 1882 "/" ttl [ "/" integer ] 1883 ; IPv4 multicast addresses may be in the 1884 ; range 224.0.0.0 to 239.255.255.255 1886 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / 1887 ("23" DIGIT ) 1889 IP6-multicast = hexpart [ "/" integer ] 1890 ; IPv6 address starting with FF 1892 ttl = (POS-DIGIT *2DIGIT) / "0" 1894 FQDN = 4*(alpha-numeric / "-" / ".") 1895 ; fully qualified domain name as specified 1896 ; in RFC1035 1898 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 1943 decimal-uchar = DIGIT 1944 / POS-DIGIT DIGIT 1945 / ("1" 2*(DIGIT)) 1946 / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) 1947 / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) 1949 ; external references: 1950 ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 2234 1951 ; URI-reference: from RFC2396 and RFC2732 1952 ; addr-spec: from RFC 2822 1954 Appendix B. Acknowledgments 1956 Many people in the IETF MMUSIC working group have made comments and 1957 suggestions contributing to this document. In particular, we would 1958 like to thank Eve Schooler, Steve Casner, Bill Fenner, Allison 1959 Mankin, Ross Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, 1960 Steve Hanna, Jonathan Lennox and Keith Drage. 1962 9. References 1964 9.1 Normative References 1966 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1967 Levels", BCP 14, RFC 2119, March 1997. 1969 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1970 Specifications: ABNF", RFC 2234, November 1997. 1972 [3] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1973 2279, January 1998. 1975 [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource 1976 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 1978 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1979 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 1981 [6] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal 1982 IPv6 Addresses in URL's", RFC 2732, December 1999. 1984 [7] Alvestrand, H., "Tags for the Identification of Languages", BCP 1985 47, RFC 3066, January 2001. 1987 9.2 Informative References 1989 [8] Mills, D., "Network Time Protocol (Version 3) Specification, 1990 Implementation", RFC 1305, March 1992. 1992 [9] Handley, M., Perkins, C. and E. Whelan, "Session Announcement 1993 Protocol", RFC 2974, October 2000. 1995 [10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1996 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1997 Session Initiation Protocol", RFC 3261, June 2002. 1999 [11] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 2000 Protocol (RTSP)", RFC 2326, April 1998. 2002 [12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2003 Session Description Protocol (SDP)", RFC 3264, June 2002. 2005 [13] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 2006 RFC 3548, July 2003. 2008 [14] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 2009 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 2010 RFC 3550, July 2003. 2012 [15] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 2013 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 2015 [16] Casner, S., "Session Description Protocol (SDP) Bandwidth 2016 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, 2017 July 2003. 2019 [17] Huitema, C., "Real Time Control Protocol (RTCP) attribute in 2020 Session Description Protocol (SDP)", RFC 3605, October 2003. 2022 [18] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K. 2023 Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 2024 3711, March 2004. 2026 [19] International Telecommunications Union, "H.323 extended for 2027 loosely coupled conferences", ITU Recommendation H.332, 2028 September 1998. 2030 [20] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K. 2031 Norrman, "Key Management Extensions for Session Description 2032 Protocol (SDP) and Real Time Streaming Protocol (RTSP)", 2033 draft-ietf-mmusic-kmgmt-ext-11 (work in progress), April 2004. 2035 [21] Andreasen, F., Baugher, M. and D. Wing, "Session Description 2036 Protocol Security Descriptions for Media Streams", 2037 draft-ietf-mmusic-sdescriptions-07 (work in progress), July 2038 2004. 2040 [22] Westerlund, M., "A Transport Independent Bandwidth Modifier for 2041 the Session Description Protocol (SDP)", 2042 draft-ietf-mmusic-sdp-bwparam-06 (work in progress), April 2043 2004. 2045 Authors' Addresses 2047 Mark Handley 2048 University College London 2049 Department of Computer Science 2050 Gower Street 2051 London WC1E 6BT 2052 UK 2054 EMail: M.Handley@cs.ucl.ac.uk 2056 Van Jacobson 2057 Packet Design 2058 2465 Latham Street 2059 Mountain View, CA 94040 2060 USA 2062 EMail: van@packetdesign.com 2064 Colin Perkins 2065 University of Glasgow 2066 Department of Computing Science 2067 17 Lilybank Gardens 2068 Glasgow G12 8QQ 2069 UK 2071 EMail: csp@csperkins.org 2073 Intellectual Property Statement 2075 The IETF takes no position regarding the validity or scope of any 2076 Intellectual Property Rights or other rights that might be claimed to 2077 pertain to the implementation or use of the technology described in 2078 this document or the extent to which any license under such rights 2079 might or might not be available; nor does it represent that it has 2080 made any independent effort to identify any such rights. Information 2081 on the procedures with respect to rights in RFC documents can be 2082 found in BCP 78 and BCP 79. 2084 Copies of IPR disclosures made to the IETF Secretariat and any 2085 assurances of licenses to be made available, or the result of an 2086 attempt made to obtain a general license or permission for the use of 2087 such proprietary rights by implementers or users of this 2088 specification can be obtained from the IETF on-line IPR repository at 2089 http://www.ietf.org/ipr. 2091 The IETF invites any interested party to bring to its attention any 2092 copyrights, patents or patent applications, or other proprietary 2093 rights that may cover technology that may be required to implement 2094 this standard. Please address the information to the IETF at 2095 ietf-ipr@ietf.org. 2097 Disclaimer of Validity 2099 This document and the information contained herein are provided on an 2100 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2101 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2102 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2103 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2104 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2105 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2107 Copyright Statement 2109 Copyright (C) The Internet Society (2004). This document is subject 2110 to the rights, licenses and restrictions contained in BCP 78, and 2111 except as set forth therein, the authors retain all their rights. 2113 Acknowledgment 2115 Funding for the RFC Editor function is currently provided by the 2116 Internet Society.