idnits 2.17.1 draft-ietf-mmusic-sdp-new-19.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2149. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2126. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2133. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2139. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 2155), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 12 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 -- The draft header indicates that this document obsoletes RFC3266, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC2327, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (August 11, 2004) is 7197 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 2028, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 2070, 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: 12 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: February 9, 2005 C. Perkins 6 University of Glasgow 7 August 11, 2004 9 SDP: Session Description Protocol 10 draft-ietf-mmusic-sdp-new-19.txt 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on February 9, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 This memo defines the Session Description Protocol (SDP). SDP is 44 intended for describing multimedia sessions for the purposes of 45 session announcement, session invitation, and other forms of 46 multimedia session initiation. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . 3 52 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . 3 53 3.1 Multicast Session Announcement . . . . . . . . . . . . . . 3 54 3.2 Session Initiation . . . . . . . . . . . . . . . . . . . . 4 55 3.3 Streaming media . . . . . . . . . . . . . . . . . . . . . 4 56 3.4 Email and the World Wide Web . . . . . . . . . . . . . . . 4 57 4. Requirements and Recommendations . . . . . . . . . . . . . . 5 58 4.1 Media and Transport Information . . . . . . . . . . . . . 5 59 4.2 Timing Information . . . . . . . . . . . . . . . . . . . . 6 60 4.3 Private Sessions . . . . . . . . . . . . . . . . . . . . . 6 61 4.4 Obtaining Further Information about a Session . . . . . . 7 62 4.5 Categorisation . . . . . . . . . . . . . . . . . . . . . . 7 63 4.6 Internationalization . . . . . . . . . . . . . . . . . . . 7 64 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . 7 65 5.1 Protocol Version ("v=") . . . . . . . . . . . . . . . . . 10 66 5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 10 67 5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . . 11 68 5.4 Session Information ("i=") . . . . . . . . . . . . . . . . 12 69 5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 12 70 5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . 12 71 5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . 13 72 5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 15 73 5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 16 74 5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . 17 75 5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . 18 76 5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 19 77 5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . 20 78 5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . . 21 79 6. Suggested Attributes . . . . . . . . . . . . . . . . . . . . 23 80 7. Communicating Conference Control Policy . . . . . . . . . . 30 81 8. Security Considerations . . . . . . . . . . . . . . . . . . 31 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32 83 9.1 The "application/sdp" media type . . . . . . . . . . . . . 32 84 9.2 Registration of Parameters . . . . . . . . . . . . . . . . 33 85 9.3 Encryption Key Access Methods . . . . . . . . . . . . . . 37 86 A. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 38 87 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 43 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 89 10.1 Normative References . . . . . . . . . . . . . . . . . . . 43 90 10.2 Informative References . . . . . . . . . . . . . . . . . . 43 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 45 92 Intellectual Property and Copyright Statements . . . . . . . 46 94 1. Introduction 96 When initiating multimedia teleconferences, voice-over-IP calls, 97 streaming video, or other sessions, there is a requirement to convey 98 media details, transport addresses, and other session description 99 metadata to the participants. 101 SDP provides a standard representation for such information, 102 irrespective of how that information is transported. SDP is purely a 103 format for session description - it does not incorporate a transport 104 protocol, and is intended to use different transport protocols as 105 appropriate, including the Session Announcement Protocol [9], Session 106 Initiation Protocol [10], Real-Time Streaming Protocol [11], 107 electronic mail using the MIME extensions, and the Hypertext 108 Transport Protocol. 110 SDP is intended to be general purpose so that it can be used in a 111 wide range of network environments and applications. However, it is 112 not intended to support negotiation of session content or media 113 encodings: this is viewed as outside the scope of session 114 description. 116 2. Glossary of Terms 118 The following terms are used in this document, and have specific 119 meaning within the context of this document. 121 Conference: A multimedia conference is a set of two or more 122 communicating users along with the software they are using to 123 communicate. 125 Session: A multimedia session is a set of multimedia senders and 126 receivers and the data streams flowing from senders to receivers. 127 A multimedia conference is an example of a multimedia session. 129 Session Description: A well defined format for conveying sufficient 130 information to discover and participate in a multimedia session. 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [1]. 136 3. Examples of SDP Usage 138 3.1 Multicast Session Announcement 140 In order to assist the advertisement of multicast multimedia 141 conferences and other multicast sessions, and to communicate the 142 relevant session setup information to prospective participants, a 143 distributed session directory may be used. An instance of such a 144 session directory periodically sends packets containing a description 145 of the session to a well known multicast group. These advertisements 146 are received by other session directories such that potential remote 147 participants can use the session description to start the tools 148 required to participate in the session. 150 One protocol commonly used to implement such a distributed directory 151 is the Session Announcement Protocol, SAP [9]. SDP provides the 152 recommended session description format for such session 153 announcements. 155 3.2 Session Initiation 157 The Session Initiation Protocol, SIP [10] is an application layer 158 control protocol for creating, modifying and terminating sessions 159 such as Internet multimedia conferences, Internet telephone calls and 160 multimedia distribution. The SIP messages used to create sessions 161 carry session descriptions which allow participants to agree on a set 162 of compatible media types. These session descriptions are commonly 163 formatted using SDP. When used with SIP, the offer/answer model [12] 164 provides a limited framework for negotiation using SDP. 166 3.3 Streaming media 168 The Real Time Streaming Protocol, RTSP [11], is an application-level 169 protocol for control over the delivery of data with real-time 170 properties. RTSP provides an extensible framework to enable 171 controlled, on-demand delivery of real-time data, such as audio and 172 video. An RTSP client and server negotiate an appropriate set of 173 parameters for media delivery, partially using SDP syntax to describe 174 those parameters. 176 3.4 Email and the World Wide Web 178 Alternative means of conveying session descriptions include 179 electronic mail and the World Wide Web. For both email and WWW 180 distribution, the MIME content type "application/sdp" is used. This 181 enables the automatic launching of applications for participation in 182 the session from the WWW client or mail reader in a standard manner. 184 Note that announcements of multicast sessions made only via email or 185 the World Wide Web (WWW) do not have the property that the receiver 186 of a session announcement can necessarily receive the session because 187 the multicast sessions may be restricted in scope, and access to the 188 WWW server or reception of email is possible outside this scope. 189 Session announcements made using SAP do not suffer this mismatch. 191 4. Requirements and Recommendations 193 The purpose of SDP is to convey information about media streams in 194 multimedia sessions to allow the recipients of a session description 195 to participate in the session. SDP is primarily intended for use in 196 an internetwork, although it is sufficiently general that it can 197 describe conferences in other network environments. Media streams 198 can be many-to-many. The times during which the session is active 199 need not be continuous. 201 Thus far, multicast based sessions on the Internet have differed from 202 many other forms of conferencing in that anyone receiving the traffic 203 can join the session (unless the session traffic is encrypted). In 204 such an environment, SDP serves two primary purposes. It is a means 205 to communicate the existence of a session, and is a means to convey 206 sufficient information to enable joining and participating in the 207 session. In a unicast environment, only the latter purpose is likely 208 to be relevant. 210 An SDP session description includes: 212 o Session name and purpose 214 o Time(s) the session is active 216 o The media comprising the session 218 o Information needed to receive those media (addresses, ports, 219 formats and so on) 221 As resources necessary to participate in a session may be limited, 222 some additional information may also be desirable: 224 o Information about the bandwidth to be used by the session 226 o Contact information for the person responsible for the session 228 In general, SDP must convey sufficient information to enable 229 applications to join a session (with the possible exception of 230 encryption keys), and to announce the resources to be used to any 231 non-participants that may need to know (this latter feature is 232 primarily useful when SDP is used with a multicast session 233 announcement protocol). 235 4.1 Media and Transport Information 237 An SDP session description includes the following media information: 239 o The type of media (video, audio, etc) 241 o The transport protocol (RTP/UDP/IP, H.320, etc) 243 o The format of the media (H.261 video, MPEG video, etc) 245 In addition to media format and transport protocol, SDP conveys 246 address and port details. For an IP multicast session, these 247 comprise: 249 o The multicast group address for media 251 o The transport port for media 253 This address and port are the destination address and destination 254 port of the multicast stream, whether being sent, received, or both. 256 For unicast IP sessions, the following are conveyed: 258 o The remote address for media 260 o The transport port for media 262 The semantics of this address and port depend on the media and 263 transport protocol defined. By default, this SHOULD be the remote 264 address and remote port to which data is sent. Some media types MAY 265 redefine this behaviour, but this is NOT RECOMMENDED. 267 4.2 Timing Information 269 Sessions may either be bounded or unbounded in time. Whether or not 270 they are bounded, they may be only active at specific times. SDP can 271 convey: 273 o An arbitrary list of start and stop times bounding the session 275 o For each bound, repeat times such as "every Wednesday at 10am for 276 one hour" 278 This timing information is globally consistent, irrespective of local 279 time zone or daylight saving time. 281 4.3 Private Sessions 283 It is possible to create both public sessions and private sessions. 284 SDP itself does not distinguish between these: private sessions are 285 typically conveyed by encrypting the session description during 286 distribution. The details of how encryption is performed are 287 dependent on the mechanism used to convey SDP: mechanisms are 288 currently defined for SDP transported using SAP [9] and SIP [10], 289 others may be defined in future. 291 If a session announcement is private it is possible to use that 292 private announcement to convey encryption keys necessary to decode 293 each of the media in a conference, including enough information to 294 know which encryption scheme is used for each media. 296 4.4 Obtaining Further Information about a Session 298 A session description should convey enough information to decide 299 whether or not to participate in a session. SDP may include 300 additional pointers in the form of Universal Resources Identifiers 301 (URIs) for more information about the session. 303 4.5 Categorisation 305 When many session descriptions are being distributed by SAP, or any 306 other advertisement mechanism, it may be desirable to filter session 307 announcements that are of interest from those that are not. SDP 308 supports a categorisation mechanism for sessions that is capable of 309 being automated. 311 4.6 Internationalization 313 The SDP specification recommends the use of the ISO 10646 character 314 sets in the UTF-8 encoding [3] to allow many different languages to 315 be represented. However, to assist in compact representations, SDP 316 also allows other character sets such as ISO 8859-1 to be used when 317 desired. Internationalization only applies to free-text fields 318 (session name and background information), and not to SDP as a whole. 320 5. SDP Specification 322 An SDP session description is denoted by the MIME content type 323 "application/sdp" (See Section 9). 325 An SDP session description is entirely textual using the ISO 10646 326 character set in UTF-8 encoding. SDP field names and attribute names 327 use only the US-ASCII subset of UTF-8, but textual fields and 328 attribute values MAY use the full ISO 10646 character set. Field and 329 attribute values which use the full UTF-8 character set are never 330 directly compared, hence there is no requirement for UTF-8 331 normalization. The textual form, as opposed to a binary encoding 332 such as ASN.1 or XDR, was chosen to enhance portability, to enable a 333 variety of transports to be used, and to allow flexible, text-based 334 toolkits to be used to generate and process session descriptions. 336 However, since SDP may be used in environments where the maximum 337 permissable size of a session description is limited, the encoding is 338 deliberately compact. Also, since announcements may be transported 339 via very unreliable means or damaged by an intermediate caching 340 server, the encoding was designed with strict order and formatting 341 rules so that most errors would result in malformed session 342 announcements which could be detected easily and discarded. This 343 also allows rapid discarding of encrypted session announcements for 344 which a receiver does not have the correct key. 346 An SDP session description consists of a number of lines of text of 347 the form: 349 = 351 where MUST be exactly one case-significant character and 352 is structured text whose format depends on . In 353 general is either a number of fields delimited by a single 354 space character, or a free format string. Whitespace MUST NOT be 355 used either side of the "=" sign. 357 An SDP session description consists of a session-level section 358 followed by zero or more media-level sections. The session-level 359 part starts with a "v=" line and continues to the first media-level 360 section. The media description starts with an "m=" line and 361 continues to the next media description or end of the whole session 362 description. In general, session-level values are the default for 363 all media unless overridden by an equivalent media-level value. 365 Some lines in each description are REQUIRED and some are OPTIONAL but 366 all MUST appear in exactly the order given here (the fixed order 367 greatly enhances error detection and allows for a simple parser). 368 OPTIONAL items are marked with a "*". 370 Session description 371 v= (protocol version) 372 o= (owner/creator and session identifier). 373 s= (session name) 374 i=* (session information) 375 u=* (URI of description) 376 e=* (email address) 377 p=* (phone number) 378 c=* (connection information - not required if included in 379 all media) 380 b=* (zero or more bandwidth information lines) 381 One or more time descriptions ("t=" and "r=" lines, see below) 382 z=* (time zone adjustments) 383 k=* (encryption key) 384 a=* (zero or more session attribute lines) 385 Zero or more media descriptions 387 Time description 388 t= (time the session is active) 389 r=* (zero or more repeat times) 391 Media description 392 m= (media name and transport address) 393 i=* (media title) 394 c=* (connection information - optional if included at 395 session-level) 396 b=* (zero or more bandwidth information lines) 397 k=* (encryption key) 398 a=* (zero or more media attribute lines) 400 The set of type letters is deliberately small and not intended to be 401 extensible -- an SDP parser MUST completely ignore any session 402 description that contains a type letter that it does not understand. 403 The attribute mechanism ("a=" described below) is the primary means 404 for extending SDP and tailoring it to particular applications or 405 media. Some attributes (the ones listed in Section 6 of this memo) 406 have a defined meaning, but others may be added on an application-, 407 media- or session-specific basis. An SDP parser MUST ignore any 408 attribute it doesn't understand. 410 An SDP session description may contain URIs which reference external 411 content in the "u=", "k=" and "a=" lines. These URIs may be 412 dereferenced in some cases, making the session description non-self 413 contained. 415 The connection ("c=") and attribute ("a=") information in the 416 session-level section applies to all the media of that session unless 417 overridden by connection information or an attribute of the same name 418 in the media description. For instance, in the example below, each 419 media behaves as if it were given a "recvonly" attribute. 421 An example SDP description is: 423 v=0 424 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 425 s=SDP Seminar 426 i=A Seminar on the session description protocol 427 u=http://www.example.com/seminars/sdp.pdf 428 e=j.doe@example.com (Jane Doe) 429 c=IN IP4 224.2.17.12/127 430 t=2873397496 2873404696 431 a=recvonly 432 m=audio 49170 RTP/AVP 0 433 m=video 51372 RTP/AVP 31 434 m=application 32416 udp wb 435 a=orient:portrait 437 Text fields such as the session name and information are octet 438 strings which may contain any octet with the exceptions of 0x00 439 (Nul), 0x0a (ASCII newline) and 0x0d (ASCII carriage return). The 440 sequence CRLF (0x0d0a) is used to end a record, although parsers 441 SHOULD be tolerant and also accept records terminated with a single 442 newline character. If the "a=charset" attribute is not present, 443 these octet strings MUST be interpreted as containing ISO-10646 444 characters in UTF-8 encoding (the presence of the "a=charset" 445 attribute MAY force some fields to be interpreted differently). 447 5.1 Protocol Version ("v=") 449 v=0 451 The "v=" field gives the version of the Session Description Protocol. 452 This memo defines version 0. There is no minor version number. 454 5.2 Origin ("o=") 456 o= 457 459 The "o=" field gives the originator of the session (her username and 460 the address of the user's host) plus a session identifier and version 461 number: 463 is the user's login on the originating host, or it is "-" 464 if the originating host does not support the concept of user ids. 465 The MUST NOT contain spaces. 467 is a numeric string such that the tuple of , 468 , , and form a 469 globally unique identifier for the session. The method of 470 allocation is up to the creating tool, but it has been 471 suggested that a Network Time Protocol (NTP) format timestamp be 472 used to ensure uniqueness [8]. 474 is a version number for this session description. Its 475 usage is up to the creating tool, so long as is 476 increased when a modification is made to the session data. Again, 477 it is RECOMMENDED that an NTP format timestamp is used. 479 is a text string giving the type of network. Initially 480 "IN" is defined to have the meaning "Internet", but other values 481 MAY be registered in future (see Section 9). 483 is a text string giving the type of the address that 484 follows. Initially "IP4" and "IP6" are defined, but other values 485 MAY be registered in future (see Section 9). 487 is the address of the machine from which the 488 session was created. For an address type of IP4, this is either 489 the fully-qualified domain name of the machine, or the 490 dotted-decimal representation of the IP version 4 address of the 491 machine. For an address type of IP6, this is either the 492 fully-qualified domain name of the machine, or the compressed 493 textual representation of the IP version 6 address of the machine. 494 For both IP4 and IP6, the fully-qualified domain name is the form 495 that SHOULD be given unless this is unavailable, in which case the 496 globally unique address MAY be substituted. A local IP address 497 MUST NOT be used in any context where the SDP description might 498 leave the scope in which the address is meaningful. 500 In general, the "o=" field serves as a globally unique identifier for 501 this version of this session description, and the subfields excepting 502 the version taken together identify the session irrespective of any 503 modifications. 505 5.3 Session Name ("s=") 507 s= 509 The "s=" field is the textual session name. There MUST be one and 510 only one "s=" field per session description. The "s=" field MUST NOT 511 be empty and SHOULD contain ISO 10646 characters (but see also the 512 "a=charset" attribute). If a session has no meaningful name, the 513 value "s= " SHOULD be used (i.e. a single space as the session 514 name). 516 5.4 Session Information ("i=") 518 i= 520 The "i=" field provides textual information about the session. There 521 may be at most one session-level "i=" field per session description, 522 and at most one "i=" field per media. If the "a=charset" attribute 523 is present, it specifies the character set used in the "i=" field. 524 If the "a=charset" attribute is not present, the "i=" field MUST 525 contain ISO 10646 characters in UTF-8 encoding. 527 A single "i=" field MAY also be used for each media definition. In 528 media definitions, "i=" fields are primarily intended for labeling 529 media streams. As such, they are most likely to be useful when a 530 single session has more than one distinct media stream of the same 531 media type. An example would be two different whiteboards, one for 532 slides and one for feedback and questions. 534 The "i=" field is intended to provide a free-form human readable 535 description of the session or the purpose of a media stream. It is 536 not suitable for parsing by automata. 538 5.5 URI ("u=") 540 u= 542 A URI is a Universal Resource Identifier as used by WWW clients [4], 543 [6]. The URI should be a pointer to additional information about the 544 conference. This field is OPTIONAL, but if it is present it MUST be 545 specified before the first media field. No more than one URI field 546 is allowed per session description. 548 5.6 Email Address and Phone Number ("e=" and "p=") 550 e= 551 p= 553 The "e=" and "p=" lines specify contact information for the person 554 responsible for the conference. This is not necessarily the same 555 person that created the conference announcement. 557 Inclusion of an email address or phone number is OPTIONAL. Note that 558 the previous version of SDP specified that either an email field or a 559 phone field MUST be specified, but this was widely ignored. The 560 change brings the specification into line with common usage. 562 If the email addres or phone number are present, they MUST be 563 specified before the first media field. More than one email or phone 564 field can be given for a session description. 566 Phone numbers SHOULD be given in the form of an international public 567 telecommunication number (see ITU-T Recommendation E.164) preceded by 568 a "+". Spaces and hyphens may be used to split up a phone field to 569 aid readability if desired. For example: 571 p=+1 617 555-6011 573 Both email addresses and phone numbers can have an OPTIONAL free text 574 string associated with them, normally giving the name of the person 575 who may be contacted. This MUST be enclosed in parenthesis if it is 576 present. For example: 578 e=j.doe@example.com (Jane Doe) 580 The alternative RFC 2822 name quoting convention is also allowed for 581 both email addresses and phone numbers. For example: 583 e=Jane Doe 585 The free text string SHOULD be in the ISO-10646 character set with 586 UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if 587 the appropriate session-level "a=charset" attribute is set. 589 5.7 Connection Data ("c=") 591 c= 593 The "c=" field contains connection data. 595 A session description MUST contain either at least one "c=" field in 596 each media description or a single "c=" field at the session level. 597 It MAY contain a single session-level "c=" field and additional "c=" 598 field(s) per media description, in which case the per-media values 599 override the session-level settings for the respective media. 601 The first sub-field ("") is the network type, which is a 602 text string giving the type of network. Initially "IN" is defined to 603 have the meaning "Internet", but other values MAY be registered in 604 the future (see Section 9). 606 The second sub-field ("") is the address type. This allows 607 SDP to be used for sessions that are not IP based. Currently only 608 IP4 and IP6 are defined, but other values MAY be registered in the 609 future (see Section 9). 611 The third sub-field ("") is the connection 612 address. OPTIONAL sub-fields MAY be added after the connection 613 address depending on the value of the field. 615 When the is IP4 and IP6, the connection address is defined 616 as follows: 618 o If the session is multicast, the connection address will be an IP 619 multicast group address. If the session is not multicast, then 620 the connection address contains the unicast IP address of the 621 expected data source or data relay or data sink as determined by 622 additional attribute fields. It is not expected that unicast 623 addresses will be given in a session description that is 624 communicated by a multicast announcement, though this is not 625 prohibited. 627 o Conferences using an IPv4 multicast connection address MUST also 628 have a time to live (TTL) value present in addition to the 629 multicast address. The TTL and the address together define the 630 scope with which multicast packets sent in this conference will be 631 sent. TTL values MUST be in the range 0-255. 633 The TTL for the session is appended to the address using a slash as a 634 separator. An example is: 636 c=IN IP4 224.2.36.42/127 638 IPv6 multicast does not use TTL scoping, and hence the TTL value MUST 639 NOT be present for IPv6 multicast. It is expected that IPv6 scoped 640 addresses will be used to limit the scope of conferences. 642 Hierarchical or layered encoding schemes are data streams where the 643 encoding from a single media source is split into a number of layers. 644 The receiver can choose the desired quality (and hence bandwidth) by 645 only subscribing to a subset of these layers. Such layered encodings 646 are normally transmitted in multiple multicast groups to allow 647 multicast pruning. This technique keeps unwanted traffic from sites 648 only requiring certain levels of the hierarchy. For applications 649 requiring multiple multicast groups, we allow the following notation 650 to be used for the connection address: 652 [/]/ 654 If the number of addresses is not given it is assumed to be one. 656 Multicast addresses so assigned are contiguously allocated above the 657 base address, so that, for example: 659 c=IN IP4 224.2.1.1/127/3 661 would state that addresses 224.2.1.1, 224.2.1.2 and 224.2.1.3 are to 662 be used at a TTL of 127. This is semantically identical to including 663 multiple "c=" lines in a media description: 665 c=IN IP4 224.2.1.1/127 666 c=IN IP4 224.2.1.2/127 667 c=IN IP4 224.2.1.3/127 669 Similarly, an IPv6 example would be: 671 c=IN IP6 FF15::101/3 673 which is semantically equivalent to: 675 c=IN IP6 FF15::101 676 c=IN IP6 FF15::102 677 c=IN IP6 FF15::103 679 (remembering that the TTL field is not present in IPv6 multicast). 681 Multiple addresses or "c=" lines MAY be specified on a per-media 682 basis only if they provide multicast addresses for different layers 683 in a hierarchical or layered encoding scheme. They MUST NOT be 684 specified for a session-level "c=" field. 686 The slash notation for multiple addresses described above MUST NOT be 687 used for IP unicast addresses. 689 5.8 Bandwidth ("b=") 691 b=: 693 This OPTIONAL field denotes the proposed bandwidth to be used by the 694 session or media. The is an alphanumeric modifier giving 695 the meaning of the figure. Two values are defined in 696 this specification, but other values MAY be registered in future (see 697 Section 9 and [22], [16]): 699 CT If the bandwidth of a session or media in a session is different 700 from the bandwidth implicit from the scope, a "b=CT:..." line 701 SHOULD be supplied for the session giving the proposed upper limit 702 to the bandwidth used. The primary purpose of this is to give an 703 approximate idea as to whether two or more sessions can co-exist 704 simultaneously. When using the CT modifier with RTP, if several 705 RTP sessions are part of the conference, the conference total 706 refers to total bandwidth of all RTP sessions. 708 AS The bandwidth is interpreted to be application-specific (it will 709 be the application's concept of maximum bandwidth). Normally this 710 will coincide with what is set on the application's "maximum 711 bandwidth" control if applicable. For RTP based applications, AS 712 gives the RTP "session bandwidth" as defined in section 6.2 of 713 [14]. 715 Note that CT gives a total bandwidth figure for all the media at all 716 sites. AS gives a bandwidth figure for a single media at a single 717 site, although there may be many sites sending simultaneously. 719 A prefix "X-" is defined for names. This is intended for 720 experimental purposes only. For example: 722 b=X-YZ:128 724 Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers 725 SHOULD be registered with IANA in the standard namespace. SDP 726 parsers MUST ignore bandwidth fields with unknown modifiers. 727 Modifiers MUST be alpha-numeric and, although no length limit is 728 given, they are recommended to be short. 730 The is in kilobits per second by default. Modifiers MAY 731 specify that alternative units are to be used (the modifiers defined 732 in this memo use the default units). 734 5.9 Timing ("t=") 736 t= 738 The "t=" lines specify the start and stop times for a session. 739 Multiple "t=" lines MAY be used if a session is active at multiple 740 irregularly spaced times; each additional "t=" lines specifies an 741 additional period of time for which the session will be active. If 742 the session is active at regular times, an "r=" line (see below) 743 should be used in addition to, and following, a "t=" line - in which 744 case the "t=" line specifies the start and stop times of the repeat 745 sequence. 747 The first and second sub-fields give the start and stop times for the 748 session respectively. These values are the decimal representation of 749 Network Time Protocol (NTP) time values in seconds since 1900 [8]. 750 To convert these values to UNIX time, subtract decimal 2208988800. 752 NTP timestamps are elsewhere represented by 64 bit values which wrap 753 sometime in the year 2036. Since SDP uses an arbitrary length 754 decimal representation, this should not cause an issue (SDP 755 timestamps MUST continue counting seconds since 1900, NTP will use 756 the value modulo the 64 bit limit). 758 If the is set to zero, then the session is not bounded, 759 though it will not become active until after the . If 760 the is also zero, the session is regarded as permanent. 762 User interfaces SHOULD strongly discourage the creation of unbounded 763 and permanent sessions as they give no information about when the 764 session is actually going to terminate, and so make scheduling 765 difficult. 767 The general assumption may be made, when displaying unbounded 768 sessions that have not timed out to the user, that an unbounded 769 session will only be active until half an hour from the current time 770 or the session start time, whichever is the later. If behaviour 771 other than this is required, an end-time should be given and modified 772 as appropriate when new information becomes available about when the 773 session should really end. 775 Permanent sessions may be shown to the user as never being active 776 unless there are associated repeat times which state precisely when 777 the session will be active. In general, permanent sessions SHOULD 778 NOT be created for any session expected to have a duration of less 779 than 2 months, and should be discouraged for sessions expected to 780 have a duration of less than 6 months. 782 5.10 Repeat Times ("r=") 784 r= 786 "r=" fields specify repeat times for a session. For example, if a 787 session is active at 10am on Monday and 11am on Tuesday for one hour 788 each week for three months, then the in the 789 corresponding "t=" field would be the NTP representation of 10am on 790 the first Monday, the would be 1 week, the would be 1 hour, and the offsets would be zero and 25 792 hours. The corresponding "t=" field stop time would be the NTP 793 representation of the end of the last session three months later. By 794 default all fields are in seconds, so the "r=" and "t=" fields might 795 be: 797 t=3034423619 3042462419 798 r=604800 3600 0 90000 800 To make description more compact, times may also be given in units of 801 days, hours or minutes. The syntax for these is a number immediately 802 followed by a single case-sensitive character. Fractional units are 803 not allowed - a smaller unit should be used instead. The following 804 unit specification characters are allowed: 806 d - days (86400 seconds) 807 h - hours (3600 seconds) 808 m - minutes (60 seconds) 809 s - seconds (allowed for completeness but NOT RECOMMENDED) 811 Thus, the above session announcement could also have been written: 813 r=7d 1h 0 25h 815 Monthly and yearly repeats cannot be directly specified with a single 816 SDP repeat time - instead separate "t=" fields should be used to 817 explicitly list the session times. 819 5.11 Time Zones ("z=") 821 z= .... 823 To schedule a repeated session which spans a change from daylight 824 saving time to standard time or vice-versa, it is necessary to 825 specify offsets from the base time. This is required because 826 different time zones change time at different times of day, different 827 countries change to or from daylight time on different dates, and 828 some countries do not have daylight saving time at all. 830 Thus in order to schedule a session that is at the same time winter 831 and summer, it must be possible to specify unambiguously by whose 832 time zone a session is scheduled. To simplify this task for 833 receivers, we allow the sender to specify the NTP time that a time 834 zone adjustment happens and the offset from the time when the session 835 was first scheduled. The "z=" field allows the sender to specify a 836 list of these adjustment times and offsets from the base time. 838 An example might be: 840 z=2882844526 -1h 2898848070 0 842 This specifies that at time 2882844526 the time base by which the 843 session's repeat times are calculated is shifted back by 1 hour, and 844 that at time 2898848070 the session's original time base is restored. 845 Adjustments are always relative to the specified start time - they 846 are not cumulative. Adjustments apply to all "t=" and "r=" lines in 847 a session description. 849 If a session is likely to last several years, it is expected that the 850 session announcement will be modified periodically rather than 851 transmit several years worth of adjustments in one session 852 announcement. 854 5.12 Encryption Keys ("k=") 856 k= 857 k=: 859 If transported over a secure and trusted channel, the session 860 description protocol MAY be used to convey encryption keys. A simple 861 mechanism for key exchange is provided by the key field ("k=") 862 although this is primarily supported for compatibility with older 863 implementations and its use is NOT RECOMMENDED. Work is in progress 864 to define new key exchange mechanisms for use with SDP [20][21] and 865 it is expected that new applications will use those mechanisms. 867 A key field is permitted before the first media entry (in which case 868 it applies to all media in the session), or for each media entry as 869 required. The format of keys and their usage is outside the scope of 870 this document, and the key field provides no way to indicate the 871 encryption algorithm to be used, key type, or other information about 872 the key: this is assumed to be provided by the higher-level protocol 873 using SDP. If there is a need to convey this information within SDP, 874 the extensions mentioned previously SHOULD be used. Many security 875 protocols require two keys: one for confidentiality, another for 876 integrity. This specification does not support transfer of two keys. 878 The method indicates the mechanism to be used to obtain a usable key 879 by external means, or from the encoded encryption key given. The 880 following methods are defined: 882 k=clear: 884 The encryption key is included untransformed in this key field. 885 This method MUST NOT be used unless it can be guaranteed that 886 the SDP is conveyed over a secure channel. The encryption key 887 is interpreted as text according to the charset attribute, use 888 the "k=base64:" method to convey characters that are otherwise 889 prohibited in SDP. 891 k=base64: 893 The encryption key is included in this key field but has been 894 base64 encoded [13] because it includes characters that are 895 prohibited in SDP. This method MUST NOT be used unless it can 896 be guaranteed that the SDP is conveyed over a secure channel. 898 k=uri: 900 A Universal Resource Identifier is included in the key field. 901 The URI refers to the data containing the key, and may require 902 additional authentication before the key can be returned. When 903 a request is made to the given URI, the reply should specify 904 the encoding for the key. The URI is often a secure HTTP URI, 905 although this is not required. 907 k=prompt 909 No key is included in this SDP description, but the session or 910 media stream referred to by this key field is encrypted. The 911 user should be prompted for the key when attempting to join the 912 session, and this user-supplied key should then be used to 913 decrypt the media streams. The use of user-specified keys is 914 NOT RECOMMENDED, since such keys tend to have weak security 915 properties. 917 The key field MUST NOT be used unless it can be guaranteed that the 918 SDP is conveyed over a secure and trusted channel. An example of 919 such a channel might be SDP embedded inside an S/MIME message or a 920 TLS protected HTTP or SIP session. It is important to ensure that 921 the secure channel is with the party that is authorized to join the 922 session, not an intermediary: if a caching proxy server is used, it 923 is important to ensure that the proxy is either trusted or unable to 924 access the SDP. Definition of appropriate security measures is 925 beyond the scope of this specification, and should be defined by the 926 users of SDP. 928 5.13 Attributes ("a=") 930 a= 931 a=: 933 Attributes are the primary means for extending SDP. Attributes may 934 be defined to be used as "session-level" attributes, "media-level" 935 attributes, or both. 937 A media description may have any number of attributes ("a=" fields) 938 which are media specific. These are referred to as "media-level" 939 attributes and add information about the media stream. Attribute 940 fields can also be added before the first media field; these 941 "session-level" attributes convey additional information that applies 942 to the conference as a whole rather than to individual media; an 943 example might be the conference's floor control policy. 945 Attribute fields may be of two forms: 947 o A property attribute is simply of the form "a=". These are 948 binary attributes, and the presence of the attribute conveys that 949 the attribute is a property of the session. An example might be 950 "a=recvonly". 952 o A value attribute is of the form "a=:". For 953 example, a whiteboard could have the value attribute 954 "a=orient:landscape" 956 Attribute interpretation depends on the media tool being invoked. 957 Thus receivers of session descriptions should be configurable in 958 their interpretation of session descriptions in general and of 959 attributes in particular. 961 Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. 963 Attribute values are octet strings, and MAY use any octet value 964 except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute 965 values are to be interpreted as in ISO-10646 character set with UTF-8 966 encoding. Unlike other text fields, attribute values are NOT 967 normally affected by the "charset" attribute as this would make 968 comparisons against known values problematic. However, when an 969 attribute is defined, it can be defined to be charset-dependent, in 970 which case it's value should be interpreted in the session charset 971 rather than in ISO-10646. 973 Attributes MUST be registered with IANA (see Section 9). If an 974 attribute is received that is not understood, it MUST be ignored by 975 the receiver. 977 5.14 Media Descriptions ("m=") 979 m= ... 981 A session description may contain a number of media descriptions. 982 Each media description starts with an "m=" field, and is terminated 983 by either the next "m=" field or by the end of the session 984 description. A media field has several sub-fields: 986 is the media type. Currently defined media are "audio", 987 "video", "text", "application", "data" and "control", although 988 this list may be extended in future (see Section 9). The 989 difference between "application" and "data" is that the former is 990 a media flow such as whiteboard information, and the latter is 991 bulk-data transfer such as multicasting of program executables 992 which will not typically be displayed to the user. "control" is 993 used to specify an additional conference control channel for the 994 session. 996 is the transport port to which the media stream is sent. The 997 meaning of the transport port depends on the network being used as 998 specified in the relevant "c=" field, and on the transport 999 protocol defined in the sub-field of the media field. 1000 Other ports used by the media application (such as the RTCP port 1001 [14]) MAY be derived algorithmically from the base media port or 1002 MAY be specified in a separate attribute (for example "a=rtcp:" as 1003 defined in [17]). 1005 For applications where hierarchically encoded streams are being 1006 sent to a unicast address, it may be necessary to specify multiple 1007 transport ports. This is done using a similar notation to that 1008 used for IP multicast addresses in the "c=" field: 1010 m= / 1012 In such a case, the ports used depend on the transport protocol. 1013 For RTP, the default is that only the even numbered ports are used 1014 for data with the corresponding one-higher odd ports used for the 1015 RTCP belonging to the RTP session, and the 1016 denoting the number of RTP sessions. For example: 1018 m=video 49170/2 RTP/AVP 31 1020 would specify that ports 49170 and 49171 form one RTP/RTCP pair 1021 and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the 1022 transport protocol and 31 is the format (see below). If 1023 non-contiguous ports are required, they must be signalled using a 1024 separate attribute (for example "a=rtcp:" as defined in [17]). 1026 If multiple addresses are specified in the "c=" field and multiple 1027 ports are specified in the "m=" field, a one-to-one mapping from 1028 port to the corresponding address is implied. For example: 1030 c=IN IP4 224.2.1.1/127/2 1031 m=video 49170/2 RTP/AVP 31 1033 would imply that address 224.2.1.1 is used with ports 49170 and 1034 49171, and address 224.2.1.2 is used with ports 49172 and 49173. 1036 is the transport protocol. The meaning of the transport 1037 protocol is dependent on the address type field in the relevant 1038 "c=" field. Thus a "c=" field of IP4 indicates that the transport 1039 protocol runs over IP4. The following transport protocols are 1040 defined, but may be extended through registration of new protocols 1041 with IANA (see Section 9): 1043 * udp: denotes an unspecified protocol running over UDP. 1045 * RTP/AVP: denotes RTP [14] used under the RTP Profile for Audio 1046 and Video Conferences with Minimal Control [15] running over 1047 UDP. 1049 * RTP/SAVP: denotes the Secure Real-time Transport Protocol [18] 1050 running over UDP. 1052 The main reason to specify the transport-protocol in addition to 1053 the media format is that the same standard media formats may be 1054 carried over different transport protocols even when the network 1055 protocol is the same - a historical example is vat PCM audio and 1056 RTP PCM audio. In addition, relays and monitoring tools that are 1057 transport-protocol-specific but format-independent are possible. 1059 is a media format description. The fourth and any subsequent 1060 sub-fields describe the format of the media. The interpretation 1061 of the media format depends on the value of the sub-field. 1063 If the sub-field is "RTP/AVP" or "RTP/SAVP" the 1064 sub-fields contain RTP payload type numbers. When a list of 1065 payload type numbers is given, this implies that all of these 1066 payload formats MAY be used in the session, but the first of these 1067 formats SHOULD be used as the default format for the session. For 1068 dynamic payload type assignments the "a=rtpmap:" attribute (see 1069 Section 6) SHOULD be used to map from an RTP payload type number 1070 to a media encoding name that identifies the payload format. The 1071 "a=fmtp:" attribute MAY be used to specify format parameters (see 1072 Section 6). 1074 If the sub-field is "udp" the sub-fields MUST 1075 reference a media type describing the format under the "audio", 1076 "text" and "video" top-level MIME types. The media type 1077 registration SHOULD define the packetization format for use with 1078 UDP transport. 1080 For media using other transport protocols, the field is 1081 protocol specific. Rules for interpretation of the 1082 sub-field MUST be defined when registering new protocols (see 1083 section 9.2.2). 1085 6. Suggested Attributes 1087 The following attributes are defined. Since application writers may 1088 add new attributes as they are required, this list is not exhaustive. 1089 Registration procedures for new attributes are defined in Section 1090 9.2.4. 1092 a=cat: 1094 This attribute gives the dot-separated hierarchical category 1095 of the session. This is to enable a receiver to filter 1096 unwanted sessions by category. It is a session-level 1097 attribute, and is not dependent on charset. 1099 a=keywds: 1101 Like the cat attribute, this is to assist identifying wanted 1102 sessions at the receiver. This allows a receiver to select 1103 interesting session based on keywords describing the purpose 1104 of the session. It is a session-level attribute. It is a 1105 charset dependent attribute, meaning that its value should be 1106 interpreted in the charset specified for the session 1107 description if one is specified, or by default in ISO 1108 10646/UTF-8. 1110 a=tool: 1112 This gives the name and version number of the tool used to 1113 create the session description. It is a session-level 1114 attribute, and is not dependent on charset. 1116 a=ptime: 1118 This gives the length of time in milliseconds represented by 1119 the media in a packet. This is probably only meaningful for 1120 audio data, but may be used with other media types if it makes 1121 sense. It should not be necessary to know ptime to decode RTP 1122 or vat audio, and it is intended as a recommendation for the 1123 encoding/packetisation of audio. It is a media attribute, and 1124 is not dependent on charset. 1126 a=maxptime: 1128 The maximum amount of media which can be encapsulated in each 1129 packet, expressed as time in milliseconds. The time SHALL be 1130 calculated as the sum of the time the media present in the 1131 packet represents. The time SHOULD be a multiple of the frame 1132 size. This attribute is probably only meaningful for audio 1133 data, but may be used with other media types if it makes 1134 sense. It is a media attribute, and is not dependent on 1135 charset. Note that this attribute was introduced after RFC 1136 2327, and non updated implementations will ignore this 1137 attribute. 1139 a=rtpmap: / 1140 [/] 1142 This attribute maps from an RTP payload type number (as used in 1143 an "m=" line) to an encoding name denoting the payload format 1144 to be used. It also provides information on the clock rate and 1145 encoding parameters. It is a media level attribute that is not 1146 dependent on charset. 1148 While an RTP profile may make static assignments of payload 1149 type numbers to payload formats, it is more common for that 1150 assignment to be done dynamically using "a=rtpmap:" attributes. 1151 As an example of a static payload type, consider u-law PCM 1152 coded single channel audio sampled at 8kHz. This is completely 1153 defined in the RTP Audio/Video profile as payload type 0, so 1154 there is no need for an "a=rtpmap: attribute, and the media for 1155 such a stream sent to UDP port 49232 can be specified as: 1157 m=audio 49232 RTP/AVP 0 1159 An example of a dynamic payload type is 16 bit linear encoded 1160 stereo audio sampled at 16 kHz. If we wish to use the dynamic 1161 RTP/AVP payload type 98 for this stream, additional information 1162 is required to decode it: 1164 m=audio 49232 RTP/AVP 98 1165 a=rtpmap:98 L16/16000/2 1167 Up to one rtpmap attribute can be defined for each media format 1168 specified. Thus we might have: 1170 m=audio 49230 RTP/AVP 96 97 98 1171 a=rtpmap:96 L8/8000 1172 a=rtpmap:97 L16/8000 1173 a=rtpmap:98 L16/11025/2 1175 RTP profiles that specify the use of dynamic payload types MUST 1176 define the set of valid encoding names and/or a means to 1177 register encoding names if that profile is to be used with SDP. 1178 The "RTP/AVP" and "RTP/SAVP" profiles use MIME sub-types for 1179 encoding names, under the top-level media type denoted in the 1180 "m=" line. In the example above, the media types are "audio/l8" 1181 and "audio/l16". 1183 For audio streams, indicates the 1184 number of audio channels. This parameter is OPTIONAL and 1185 may be omitted if the number of channels is one, provided 1186 no additional parameters are needed. 1188 For video streams, no encoding parameters are currently 1189 specified. 1191 Additional encoding parameters MAY be defined in the future, 1192 but codec specific parameters SHOULD NOT be added. Parameters 1193 added to an "a=rtpmap:" attribute SHOULD only be those required 1194 for a session directory to make the choice of appropriate media 1195 to participate in a session. Codec-specific parameters should 1196 be added in other attributes (for example, "a=fmtp:"). 1198 Note: RTP audio formats typically do not include information 1199 about the number of samples per packet. If a non-default (as 1200 defined in the RTP Audio/Video Profile) packetisation is 1201 required, the "ptime" attribute is used as given below. 1203 a=recvonly 1205 This specifies that the tools should be started in receive 1206 only mode where applicable. It can be either a session or 1207 media attribute, and is not dependent on charset. Note that 1208 recvonly applies to the media only, not to any associated 1209 control protocol (e.g. an RTP based system in recvonly mode 1210 SHOULD still send RTCP packets). 1212 a=sendrecv 1214 This specifies that the tools should be started in send and 1215 receive mode. This is necessary for interactive conferences 1216 with tools that default to receive only mode. It can be either 1217 a session or media attribute, and is not dependent on charset. 1219 If none of the attributes "sendonly", "recvonly", "inactive", 1220 and "sendrecv" is present, "sendrecv" SHOULD be assumed as the 1221 default for sessions which are not of the conference type 1222 "broadcast" or "H332" (see below). 1224 a=sendonly 1226 This specifies that the tools should be started in send-only 1227 mode. An example may be where a different unicast address is 1228 to be used for a traffic destination than for a traffic 1229 source. In such a case, two media descriptions may be use, 1230 one sendonly and one recvonly. It can be either a session or 1231 media attribute, but would normally only be used as a media 1232 attribute, and is not dependent on charset. Note that sendonly 1233 applies only to the media, and any associated control protocol 1234 (e.g. RTCP) SHOULD still be received and processed as normal. 1236 a=inactive 1238 This specifies that the tools should be started in inactive 1239 mode. This is necessary for interactive conferences where 1240 users can put other users on hold. No media is sent over an 1241 inactive media stream. Note that an RTP based system SHOULD 1242 still send RTCP, even if started inactive. It can be either a 1243 session or media attribute, and is not dependent on charset. 1245 a=orient: 1247 Normally this is only used in a whiteboard media specification. 1248 It specifies the orientation of a the whiteboard on the screen. 1249 It is a media attribute. Permitted values are "portrait", 1250 "landscape" and "seascape" (upside down landscape). It is not 1251 dependent on charset. 1253 a=type: 1255 This specifies the type of the conference. Suggested values 1256 are "broadcast", "meeting", "moderated", "test" and "H332". 1257 "recvonly" should be the default for "type:broadcast" 1258 sessions, "type:meeting" should imply "sendrecv" and 1259 "type:moderated" should indicate the use of a floor control 1260 tool and that the media tools are started so as to mute new 1261 sites joining the conference. 1263 Specifying the attribute "type:H332" indicates that this 1264 loosely coupled session is part of a H.332 session as defined 1265 in the ITU H.332 specification [15]. Media tools should be 1266 started "recvonly". 1268 Specifying the attribute "type:test" is suggested as a hint 1269 that, unless explicitly requested otherwise, receivers can 1270 safely avoid displaying this session description to users. 1272 The type attribute is a session-level attribute, and is not 1273 dependent on charset. 1275 a=charset: 1277 This specifies the character set to be used to display the 1278 session name and information data. By default, the ISO-10646 1279 character set in UTF-8 encoding is used. If a more compact 1280 representation is required, other character sets may be used. 1281 For example, the ISO 8859-1 is specified with the following 1282 SDP attribute: 1284 a=charset:ISO-8859-1 1286 This is a session-level attribute and is not dependent on 1287 charset. The charset specified MUST be one of those registered 1288 with IANA, such as ISO-8859-1. The character set identifier is 1289 a US-ASCII string and MUST be compared against the IANA 1290 identifiers using a case insensitive comparison. If the 1291 identifier is not recognised or not supported, all strings that 1292 are affected by it SHOULD be regarded as octet strings. 1294 Note that a character set specified MUST still prohibit the 1295 use of bytes 0x00 (Nul), 0x0A (LF) and 0x0d (CR). Character 1296 sets requiring the use of these characters MUST define a 1297 quoting mechanism that prevents these bytes appearing within 1298 text fields. 1300 a=sdplang: 1302 This can be a session level attribute or a media level 1303 attribute. As a session level attribute, it specifies the 1304 language for the session description. As a media level 1305 attribute, it specifies the language for any media-level SDP 1306 information field associated with that media. Multiple 1307 sdplang attributes can be provided either at session or media 1308 level if multiple languages in the session description or 1309 media use multiple languages, in which case the order of the 1310 attributes indicates the order of importance of the various 1311 languages in the session or media from most important to least 1312 important. 1314 In general, sending session descriptions consisting of 1315 multiple languages is discouraged. Instead, multiple 1316 descriptions SHOULD be sent describing the session, one in 1317 each language. However this is not possible with all 1318 transport mechanisms, and so multiple sdplang attributes are 1319 allowed although NOT RECOMMENDED. 1321 The "sdplang" attribute value must be a single RFC 3066 1322 language tag in US-ASCII [6]. It is not dependent on 1323 the charset attribute. An "sdplang" attribute SHOULD be 1324 specified when a session is of sufficient scope to cross 1325 geographic boundaries where the language of recipients cannot 1326 be assumed, or where the session is in a different language 1327 from the locally assumed norm. 1329 a=lang: 1331 This can be a session level attribute or a media level 1332 attribute. As a session level attribute, it specifies the 1333 default language for the session being described. As a media 1334 level attribute, it specifies the language for that media, 1335 overriding any session-level language specified. Multiple 1336 lang attributes can be provided either at session or media 1337 level if the session description or media use multiple 1338 languages, in which case the order of the attributes indicates 1339 the order of importance of the various languages in the 1340 session or media from most important to least important. 1342 The "lang" attribute value must be a single RFC 3066 language 1343 tag in US-ASCII [6]. It is not dependent on the charset 1344 attribute. A "lang" attribute SHOULD be specified when a 1345 session is of sufficient scope to cross geographic boundaries 1346 where the language of recipients cannot be assumed, or where 1347 the session is in a different language from the locally 1348 assumed norm. 1350 a=framerate: 1352 This gives the maximum video frame rate in frames/sec. It is 1353 intended as a recommendation for the encoding of video data. 1354 Decimal representations of fractional values using the 1355 notation "." are allowed. It is a 1356 media attribute, defined only for video media, and is not 1357 dependent on charset. 1359 a=quality: 1361 This gives a suggestion for the quality of the encoding as an 1362 integer value. The intention of the quality attribute for 1363 video is to specify a non-default trade-off between frame-rate 1364 and still-image quality. For video, the value in the range 0 1365 to 10, with the following suggested meaning: 1367 10 - the best still-image quality the compression scheme 1368 can give. 1369 5 - the default behaviour given no quality suggestion. 1370 0 - the worst still-image quality the codec designer 1371 thinks is still usable. 1373 It is a media attribute, and is not dependent on charset. 1375 a=fmtp: 1377 This attribute allows parameters that are specific to a 1378 particular format to be conveyed in a way that SDP doesn't 1379 have to understand them. The format must be one of the 1380 formats specified for the media. Format-specific parameters 1381 may be any set of parameters required to be conveyed by SDP 1382 and given unchanged to the media tool that will use this 1383 format. At most one instance of this attribute is allowed 1384 for each format. 1386 It is a media attribute, and is not dependent on charset. 1388 7. Communicating Conference Control Policy 1390 There is some debate over the way conference control policy should be 1391 communicated. In general, the authors believe that an implicit 1392 declarative style of specifying conference control is desirable where 1393 possible. 1395 A simple declarative style uses a single conference attribute field 1396 before the first media field, possibly supplemented by properties 1397 such as `recvonly' for some of the media tools. This conference 1398 attribute conveys the conference control policy. An example might 1399 be: 1401 a=type:moderated 1403 In some cases, however, it is possible that this may be insufficient 1404 to communicate the details of an unusual conference control policy. 1405 If this is the case, then a conference attribute specifying external 1406 control might be set, and then one or more "media" fields might be 1407 used to specify the conference control tools and configuration data 1408 for those tools. An example is an ITU H.332 session: 1410 ... 1411 c=IN IP4 224.5.6.7 1412 a=type:H332 1413 m=audio 49230 RTP/AVP 0 1414 m=video 49232 RTP/AVP 31 1415 m=application 12349 udp wb 1416 m=control 49234 H323 mc 1417 c=IN IP4 134.134.157.81 1419 In this example, a general conference attribute (type:H332) is 1420 specified stating that conference control will be provided by an 1421 external H.332 tool, and a contact addresses for the H.323 session 1422 multipoint controller is given. 1424 In this document, only the declarative style of conference control 1425 declaration is specified. Other forms of conference control should 1426 specify an appropriate type attribute, and should define the 1427 implications this has for control media. 1429 8. Security Considerations 1431 SDP is a session description format that describes multimedia 1432 sessions. A session description SHOULD NOT be trusted unless it has 1433 been obtained by an authenticated transport protocol from a trusted 1434 source. Many different transport protocols may be used to distribute 1435 session description, and the nature of the authentication will differ 1436 from transport to transport. 1438 One transport that will frequently be used to distribute session 1439 descriptions is the Session Announcement Protocol (SAP). SAP 1440 provides both encryption and authentication mechanisms but due to the 1441 nature of session announcements it is likely that there are many 1442 occasions where the originator of a session announcement cannot be 1443 authenticated because they are previously unknown to the receiver of 1444 the announcement and because no common public key infrastructure is 1445 available. 1447 On receiving a session description over an unauthenticated transport 1448 mechanism or from an untrusted party, software parsing the session 1449 should take a few precautions. Session descriptions contain 1450 information required to start software on the receivers system. 1451 Software that parses a session description MUST NOT be able to start 1452 other software except that which is specifically configured as 1453 appropriate software to participate in multimedia sessions. It is 1454 normally considered inappropriate for software parsing a session 1455 description to start, on a user's system, software that is 1456 appropriate to participate in multimedia sessions, without the user 1457 first being informed that such software will be started and giving 1458 their consent. Thus a session description arriving by session 1459 announcement, email, session invitation, or WWW page MUST NOT deliver 1460 the user into an interactive multimedia session unless the user has 1461 explicitly pre-authorized such action. As it is not always simple to 1462 tell whether a session is interactive or not, applications that are 1463 unsure should assume sessions are interactive. 1465 In this specification, there are no attributes which would allow the 1466 recipient of a session description to be informed to start multimedia 1467 tools in a mode where they default to transmitting. Under some 1468 circumstances it might be appropriate to define such attributes. If 1469 this is done an application parsing a session description containing 1470 such attributes SHOULD either ignore them, or inform the user that 1471 joining this session will result in the automatic transmission of 1472 multimedia data. The default behaviour for an unknown attribute is 1473 to ignore it. 1475 Session descriptions may be parsed at intermediate systems such as 1476 firewalls for the purposes of opening a hole in the firewall to allow 1477 the participation in multimedia sessions. It is considered 1478 inappropriate for a firewall to open such holes for unicast data 1479 streams unless the session description comes in a request from inside 1480 the firewall. For multicast sessions, it is likely that local 1481 administrators will apply their own policies, but the exclusive use 1482 of "local" or "site-local" administrative scope within the firewall 1483 and the refusal of the firewall to open a hole for such scopes will 1484 provide separation of global multicast sessions from local ones. 1486 Use of the "k=" field poses a significant security risk, since it 1487 conveys session encryption keys in the clear. SDP MUST NOT be used 1488 to convey key material, unless it can be guaranteed that the channel 1489 over which the SDP is delivered is both private and authenticated. 1491 9. IANA Considerations 1493 9.1 The "application/sdp" media type 1495 One MIME type is to be registered, as defined below. This updates 1496 the previous definition from RFC 2327. 1498 To: ietf-types@iana.org 1499 Subject: Registration of media type "application/sdp" 1501 MIME media type name: application 1503 MIME subtype name: sdp 1505 Required parameters: None. 1507 Optional parameters: None. 1509 Encoding considerations: 1510 See section 5 of RFC XXXX 1512 Security considerations: 1513 See section 8 of RFC XXXX 1515 Interoperability considerations: 1516 See RFC XXXX 1518 Published specification: 1519 See RFC XXXX 1521 Applications which use this media type: 1522 Voice over IP, video teleconferencing, streaming media, instant 1523 messaging, etc. See also section 3 of RFC XXXX. 1525 Additional information: 1527 Magic number(s): None. 1528 File extension(s): The extension ".sdp" is commonly used. 1529 Macintosh File Type Code(s): "sdp " 1531 Person & email address to contact for further information: 1532 Colin Perkins 1533 IETF MMUSIC working group 1535 Intended usage: COMMON 1537 Author/Change controller: 1538 Authors of RFC XXXX 1539 IETF MMUSIC working group delegated from the IESG 1541 9.2 Registration of Parameters 1543 There are seven field names that may be registered with IANA. Using 1544 the terminology in the SDP specification BNF, they are "media", 1545 "proto", "fmt", "att-field", "bwtype", "nettype" and "addrtype". 1547 9.2.1 Media types ("media") 1549 The set of media types is intended to be small and SHOULD NOT be 1550 extended except under rare circumstances. The same rules should 1551 apply for media names as for top-level MIME content types, and where 1552 possible the same name should be registered for SDP as for MIME. For 1553 media other than existing MIME top-level content types, a 1554 standards-track RFC MUST be produced for a new top-level content type 1555 to be registered, and the registration MUST provide good 1556 justification why no existing media name is appropriate (the 1557 "Standards Action" policy of RFC 2434 [5]. 1559 This memo registers the media types "audio", "video", "text", 1560 "application", "data" and "control". 1562 9.2.2 Transport protocols ("proto") 1564 The "proto" field describes the transport protocol used. This SHOULD 1565 reference a standards-track protocol RFC. This memo registers three 1566 values: "RTP/AVP" is a reference to RTP [14] used under the RTP 1567 Profile for Audio and Video Conferences with Minimal Control [15] 1568 running over UDP/IP, "RTP/SAVP" is a reference to the Secure 1569 Real-time Transport Protocol [18], and "udp" indicates an unspecified 1570 protocol over UDP. 1572 If other RTP profiles are defined in the future, their "proto" name 1573 SHOULD be specified in the same manner. For example, an RTP profile 1574 whose short name is "XYZ" would be denoted by a "proto" field of 1575 "RTP/XYZ". 1577 New transport protocols SHOULD be registered with IANA. 1578 Registrations MUST reference an RFC describing the protocol. Such an 1579 RFC MAY be Experimental or Informational, although it is preferable 1580 if it is Standards-Track. Registrations MUST also define the rules 1581 by which their "fmt" namespace is managed (see below). 1583 9.2.3 Media formats ("fmt") 1585 Each transport protocol, defined by the "proto" field, has an 1586 associated "fmt" namespace that describes the media formats which may 1587 conveyed by that protocol. Formats cover all the possible encodings 1588 that might want to be transported in a multimedia session. 1590 RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST 1591 use the payload type number as their "fmt" value. If the payload 1592 type number is dynamically assigned by this session description, an 1593 additional "rtpmap" attribute MUST be included to specify the format 1594 name and parameters as defined by the MIME type registration for the 1595 payload format. It is RECOMMENDED that other RTP profiles which are 1596 registered (in combination with RTP) as SDP transport protocols 1597 specify the same rules for the "fmt" namespace. 1599 For the "udp" protocol, new formats SHOULD be registered. Use of an 1600 existing MIME subtype for the format is encouraged. If no MIME 1601 subtype exists, it is RECOMMENDED that a suitable one is registered 1602 through the IETF process (RFC 2048) by production of, or reference 1603 to, a standards-track RFC that defines the transport protocol for the 1604 format. 1606 For other protocols, formats MAY be registered according to the rules 1607 of the associated "proto" specification. 1609 Registrations of new formats MUST specify which transport protocols 1610 they apply to. 1612 9.2.4 Attribute names ("att-field") 1614 Attribute field names ("att-field") MUST be registered with IANA and 1615 documented, because of noticeable issues due to conflicting 1616 attributes under the same name. Unknown attributes in SDP are simply 1617 ignored, but conflicting ones that fragment the protocol are a 1618 serious problem. 1620 New attribute registerations are accepted according to the 1621 "Specification Required" policy of RFC 2434, provided that the 1622 specification includes the following information: 1624 o contact name, email address and telephone number 1626 o attribute-name (as it will appear in SDP) 1628 o long-form attribute name in English 1630 o type of attribute (session level, media level, or both) 1632 o whether the attribute value is subject to the charset attribute. 1634 o a one paragraph explanation of the purpose of the attribute. 1636 o a specification of appropriate attribute values for this 1637 attribute. 1639 The above is the minimum that IANA will accept. Attributes that are 1640 expected to see widespread use and interoperability, SHOULD be 1641 documented with a standards-track RFC that specifies the attribute 1642 more precisely. 1644 Submitters of registrations should ensure that the specification is 1645 in the spirit of SDP attributes, most notably that the attribute is 1646 platform independent in the sense that it makes no implicit 1647 assumptions about operating systems and does not name specific pieces 1648 of software in a manner that might inhibit interoperability. 1650 IANA is requested to register the following initial set of attribute 1651 names ("att-field" values), with definitions as in Section 6 of this 1652 memo (these definitions update those in RFC 2327): 1654 Name | Session or Media level? | Dependent on charset? 1655 ----------+-------------------------+---------------------- 1656 cat | Session | No 1657 keywds | Session | Yes 1658 tool | Session | No 1659 ptime | Media | No 1660 maxptime | Media | No 1661 rtpmap | Media | No 1662 recvonly | Either | No 1663 sendrecv | Either | No 1664 sendonly | Either | No 1665 inactive | Either | No 1666 orient | Media | No 1667 type | Session | No 1668 charset | Session | No 1669 sdplang | Either | No 1670 lang | Either | No 1671 framerate | Media | No 1672 quality | Media | No 1673 fmtp | Media | No 1675 9.2.5 Bandwidth specifiers ("bwtype") 1677 A proliferation of bandwidth specifiers is strongly discouraged. 1679 New bandwidth specifiers ("bwtype" fields) MUST be registered with 1680 IANA. The submission MUST reference a standards-track RFC specifying 1681 the semantics of the bandwidth specifier precisely, and indicating 1682 when it should be used, and why the existing registered bandwidth 1683 specifiers do not suffice. 1685 IANA is requested to register the bandwith specifiers "CT" and "AS" 1686 with definitions as in Section 5.8 of this memo (these definitions 1687 update those in RFC 2327). 1689 9.2.6 Network types ("nettype") 1691 New network types (the "nettype" field) may be registered with IANA 1692 if SDP needs to be used in the context of non-Internet environments. 1693 Whilst these are not normally the preserve of IANA, there may be 1694 circumstances when an Internet application needs to interoperate with 1695 a non- Internet application, such as when gatewaying an Internet 1696 telephony call into the PSTN. The number of network types should be 1697 small and should be rarely extended. A new network type cannot be 1698 registered without registering at least one address type to be used 1699 with that network type. A new network type registration MUST 1700 reference an RFC which gives details of the network type and address 1701 type and specifies how and when they would be used. 1703 IANA is requested to register the network type "IN" to represent the 1704 Internet, with definition as in Sections 5.2 and 5.7 of this memo 1705 (these definitions update those in RFC 2327). 1707 9.2.7 Address types ("addrtype") 1709 New address types ("addrtype") may be registered with IANA. An 1710 address type is only meaningful in the context of a network type, and 1711 any registration of an address type MUST specify a registered network 1712 type, or be submitted along with a network type registration. A new 1713 address type registration MUST reference an RFC giving details of the 1714 syntax of the address type. Address types are not expected to be 1715 registered frequently. 1717 IANA is requested to register the address types "IP4" and "IP6" with 1718 definitions as in Sections 5.2 and 5.7 of this memo (these 1719 definitions update those in RFC 2327). 1721 9.2.8 Registration Procedure 1723 In the RFC documentation that registers SDP "media", "proto", "fmt", 1724 "bwtype", "nettype" and "addrtype" fields, the authors MUST include 1725 the following information for IANA to place in the appropriate 1726 registry: 1728 o contact name, email address and telephone number 1730 o name being registered (as it will appear in SDP) 1732 o long-form name in English 1734 o type of name ("media", "proto", "fmt", "bwtype", "nettype", or 1735 "addrtype") 1737 o a one paragraph explanation of the purpose of the registered name. 1739 o a reference to the specification for the registered name (this 1740 will typically be an RFC number). 1742 IANA may refer any registration to the IESG Transport Area Directors 1743 for review, and may request revisions to be made before a 1744 registration will be made. 1746 9.3 Encryption Key Access Methods 1748 The IANA currently maintains a table of SDP encryption key access 1749 method ("enckey") names. This table is obsolete and SHOULD be 1750 removed, since the "k=" line is not extensible. New registrations 1751 MUST NOT be accepted. 1753 Appendix A. SDP Grammar 1755 This appendix provides an Augmented BNF grammar for SDP. ABNF is 1756 defined in [2]. 1758 ; SDP Syntax 1759 session-description = proto-version 1760 origin-field 1761 session-name-field 1762 information-field 1763 uri-field 1764 email-fields 1765 phone-fields 1766 connection-field 1767 bandwidth-fields 1768 time-fields 1769 key-field 1770 attribute-fields 1771 media-descriptions 1773 proto-version = "v=" 1*DIGIT CRLF 1774 ;this memo describes version 0 1776 origin-field = "o=" username SP sess-id SP sess-version SP 1777 nettype SP addrtype SP unicast-address CRLF 1779 session-name-field = "s=" text CRLF 1781 information-field = ["i=" text CRLF] 1783 uri-field = ["u=" uri CRLF] 1785 email-fields = *("e=" email-address CRLF) 1787 phone-fields = *("p=" phone-number CRLF) 1789 connection-field = ["c=" nettype SP addrtype SP 1790 connection-address CRLF] 1791 ;a connection field must be present 1792 ;in every media description or at the 1793 ;session-level 1795 bandwidth-fields = *("b=" bwtype ":" bandwidth CRLF) 1796 time-fields = 1*( "t=" start-time SP stop-time 1797 *(CRLF repeat-fields) CRLF) 1798 [zone-adjustments CRLF] 1800 repeat-fields = "r=" repeat-interval SP typed-time 1801 1*(SP typed-time) 1803 zone-adjustments = "z=" time SP ["-"] typed-time 1804 *(SP time SP ["-"] typed-time) 1806 key-field = ["k=" key-type CRLF] 1808 attribute-fields = *("a=" attribute CRLF) 1810 media-descriptions = *( media-field 1811 information-field 1812 *connection-field 1813 bandwidth-fields 1814 key-field 1815 attribute-fields ) 1817 media-field = "m=" media SP port ["/" integer] 1818 SP proto 1*(SP fmt) CRLF 1820 ; sub-rules of 'o=' 1821 username = non-ws-string 1822 ;pretty wide definition, but doesn't 1823 ;include space 1825 sess-id = 1*DIGIT 1826 ;should be unique for this username/host 1828 sess-version = 1*DIGIT 1829 ;0 is a new session 1831 nettype = token 1832 ;typically "IN" 1834 addrtype = token 1835 ;typically "IP4" or "IP6" 1837 ; sub-rules of 'u=' 1838 uri = URI-reference 1839 ; see RFC2396 and RFC2732 1841 ; sub-rules of 'e=' 1842 email-address = email *SP "(" 1*email-safe ")" / 1843 1*email-safe "<" email ">" / 1844 email 1846 email = addr-spec ; defined in RFC2822 1847 ; modified to remove CFWS 1849 ; sub-rules of 'p=' 1850 phone-number = phone *SP "(" 1*email-safe ")" / 1851 1*email-safe "<" phone ">" / 1852 phone 1854 phone = ["+"] DIGIT 1*(SP / "-" / DIGIT) 1856 ; sub-rules of 'c=' 1857 connection-address = multicast-address / unicast-address 1859 ; sub-rules of 'b=' 1860 bwtype = token 1862 bandwidth = 1*DIGIT 1864 ; sub-rules of 't=' 1865 start-time = time / "0" 1867 stop-time = time / "0" 1869 time = POS-DIGIT 9*DIGIT 1870 ; Decimal representation of NTP time in 1871 ; seconds since 1900. The representation 1872 ; of NTP time is an unbounded length field 1873 ; containing at least 10 digits. Unlike the 1874 ; 64-bit representation used elsewhere, time 1875 ; in SDP does not wrap in the year 2036. 1877 ; sub-rules of 'r=' and 'z=' 1878 repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] 1880 typed-time = 1*DIGIT [fixed-len-time-unit] 1882 fixed-len-time-unit = "d" / "h" / "m" / "s" 1884 ; sub-rules of 'k=' 1885 key-type = "prompt" / 1886 "clear:" text / 1887 "base64:" base64 / 1888 "uri:" uri 1890 base64 = *base64-unit [base64-pad] 1891 base64-unit = 4base64-char 1892 base64-pad = 2base64-char "==" / 3base64-char "=" 1893 base64-char = ALPHA / DIGIT / "+" / "/" 1895 ; sub-rules of 'a=' 1896 attribute = (att-field ":" att-value) / att-field 1898 att-field = token 1900 att-value = byte-string 1902 ; sub-rules of 'm=' 1903 media = token 1904 ;typically "audio", "video", "text", 1905 ;"application" or "data" 1907 fmt = token 1908 ;typically an RTP payload type for audio 1909 ;and video media 1911 proto = token *("/" token) 1912 ;typically "RTP/AVP" or "udp" 1914 port = 1*DIGIT 1915 ;should be either "0" or in the range "1024" 1916 ;to "65535" inclusive for UDP based media 1917 ;(a value of "0" is used to signal special 1918 ;conditions in some uses of SDP) 1920 ; generic sub-rules: addressing 1921 unicast-address = IP4-address / IP6-address / FQDN / extn-addr 1923 multicast-address = IP4-multicast / IP6-multicast / extn-addr 1925 IP4-multicast = m1 3( "." decimal-uchar ) 1926 "/" ttl [ "/" integer ] 1927 ; IPv4 multicast addresses may be in the 1928 ; range 224.0.0.0 to 239.255.255.255 1930 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / 1931 ("23" DIGIT ) 1933 IP6-multicast = hexpart [ "/" integer ] 1934 ; IPv6 address starting with FF 1936 ttl = (POS-DIGIT *2DIGIT) / "0" 1938 FQDN = 4*(alpha-numeric / "-" / ".") 1939 ; fully qualified domain name as specified 1940 ; in RFC1035 1942 IP4-address = b1 3("." decimal-uchar) / "0.0.0.0" 1944 b1 = decimal-uchar 1945 ; less than "224"; not "0" or "127" 1947 ; The following is from RFC2373 Appendix B. It is a direct copy. 1948 IP6-address = hexpart [ ":" IP4-address ] 1950 hexpart = hexseq / hexseq "::" [ hexseq ] / 1951 "::" [ hexseq ] 1953 hexseq = hex4 *( ":" hex4) 1955 hex4 = 1*4HEXDIG 1957 ; Generic for other address families 1958 extn-addr = non-ws-string 1960 ; generic sub-rules: datatypes 1961 text = byte-string 1962 ;default is to interpret this as UTF8 text. 1963 ;ISO 8859-1 requires "a=charset:ISO-8859-1" 1964 ;session-level attribute to be used 1966 byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) 1967 ;any byte except NUL, CR or LF 1969 non-ws-string = 1*(VCHAR/%x80-FF) 1970 ;string of visible characters 1972 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 1973 / %x41-5A / %x5E-7E 1975 token = 1*(token-char) 1977 email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF 1978 ;any byte except NUL, CR, LF, or the quoting 1979 ;characters ()<> 1981 integer = POS-DIGIT *DIGIT 1983 ; generic sub-rules: primitives 1984 alpha-numeric = ALPHA / DIGIT 1986 POS-DIGIT = %x31-39 ; 1 - 9 1987 decimal-uchar = DIGIT 1988 / POS-DIGIT DIGIT 1989 / ("1" 2*(DIGIT)) 1990 / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) 1991 / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) 1993 ; external references: 1994 ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 2234 1995 ; URI-reference: from RFC2396 and RFC2732 1996 ; addr-spec: from RFC 2822 1998 Appendix B. Acknowledgments 2000 Many people in the IETF MMUSIC working group have made comments and 2001 suggestions contributing to this document. In particular, we would 2002 like to thank Eve Schooler, Steve Casner, Bill Fenner, Allison 2003 Mankin, Ross Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, 2004 Steve Hanna, Jonathan Lennox and Keith Drage. 2006 10. References 2008 10.1 Normative References 2010 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2011 Levels", BCP 14, RFC 2119, March 1997. 2013 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2014 Specifications: ABNF", RFC 2234, November 1997. 2016 [3] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2017 2279, January 1998. 2019 [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource 2020 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 2022 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2023 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 2025 [6] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal 2026 IPv6 Addresses in URL's", RFC 2732, December 1999. 2028 [7] Alvestrand, H., "Tags for the Identification of Languages", BCP 2029 47, RFC 3066, January 2001. 2031 10.2 Informative References 2033 [8] Mills, D., "Network Time Protocol (Version 3) Specification, 2034 Implementation", RFC 1305, March 1992. 2036 [9] Handley, M., Perkins, C. and E. Whelan, "Session Announcement 2037 Protocol", RFC 2974, October 2000. 2039 [10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2040 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 2041 Session Initiation Protocol", RFC 3261, June 2002. 2043 [11] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 2044 Protocol (RTSP)", RFC 2326, April 1998. 2046 [12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2047 Session Description Protocol (SDP)", RFC 3264, June 2002. 2049 [13] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 2050 RFC 3548, July 2003. 2052 [14] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 2053 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 2054 RFC 3550, July 2003. 2056 [15] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 2057 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 2059 [16] Casner, S., "Session Description Protocol (SDP) Bandwidth 2060 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, 2061 July 2003. 2063 [17] Huitema, C., "Real Time Control Protocol (RTCP) attribute in 2064 Session Description Protocol (SDP)", RFC 3605, October 2003. 2066 [18] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K. 2067 Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 2068 3711, March 2004. 2070 [19] International Telecommunications Union, "H.323 extended for 2071 loosely coupled conferences", ITU Recommendation H.332, 2072 September 1998. 2074 [20] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K. 2075 Norrman, "Key Management Extensions for Session Description 2076 Protocol (SDP) and Real Time Streaming Protocol (RTSP)", 2077 draft-ietf-mmusic-kmgmt-ext-11 (work in progress), April 2004. 2079 [21] Andreasen, F., Baugher, M. and D. Wing, "Session Description 2080 Protocol Security Descriptions for Media Streams", 2081 draft-ietf-mmusic-sdescriptions-07 (work in progress), July 2082 2004. 2084 [22] Westerlund, M., "A Transport Independent Bandwidth Modifier for 2085 the Session Description Protocol (SDP)", 2086 draft-ietf-mmusic-sdp-bwparam-06 (work in progress), April 2087 2004. 2089 Authors' Addresses 2091 Mark Handley 2092 University College London 2093 Department of Computer Science 2094 Gower Street 2095 London WC1E 6BT 2096 UK 2098 EMail: M.Handley@cs.ucl.ac.uk 2100 Van Jacobson 2101 Packet Design 2102 2465 Latham Street 2103 Mountain View, CA 94040 2104 USA 2106 EMail: van@packetdesign.com 2108 Colin Perkins 2109 University of Glasgow 2110 Department of Computing Science 2111 17 Lilybank Gardens 2112 Glasgow G12 8QQ 2113 UK 2115 EMail: csp@csperkins.org 2117 Intellectual Property Statement 2119 The IETF takes no position regarding the validity or scope of any 2120 Intellectual Property Rights or other rights that might be claimed to 2121 pertain to the implementation or use of the technology described in 2122 this document or the extent to which any license under such rights 2123 might or might not be available; nor does it represent that it has 2124 made any independent effort to identify any such rights. Information 2125 on the procedures with respect to rights in RFC documents can be 2126 found in BCP 78 and BCP 79. 2128 Copies of IPR disclosures made to the IETF Secretariat and any 2129 assurances of licenses to be made available, or the result of an 2130 attempt made to obtain a general license or permission for the use of 2131 such proprietary rights by implementers or users of this 2132 specification can be obtained from the IETF on-line IPR repository at 2133 http://www.ietf.org/ipr. 2135 The IETF invites any interested party to bring to its attention any 2136 copyrights, patents or patent applications, or other proprietary 2137 rights that may cover technology that may be required to implement 2138 this standard. Please address the information to the IETF at 2139 ietf-ipr@ietf.org. 2141 Disclaimer of Validity 2143 This document and the information contained herein are provided on an 2144 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2145 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2146 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2147 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2148 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2149 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2151 Copyright Statement 2153 Copyright (C) The Internet Society (2004). This document is subject 2154 to the rights, licenses and restrictions contained in BCP 78, and 2155 except as set forth therein, the authors retain all their rights. 2157 Acknowledgment 2159 Funding for the RFC Editor function is currently provided by the 2160 Internet Society.