idnits 2.17.1 draft-ietf-mmusic-sdp-new-24.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2233. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2210. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2217. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2223. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 11 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 -- The draft header indicates that this document obsoletes RFC3266, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC2327, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 18, 2005) is 6999 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: '10' is defined on line 2106, but no explicit reference was found in the text == Unused Reference: '25' is defined on line 2159, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '4') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2279 (ref. '5') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2327 (ref. '6') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2396 (ref. '7') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2434 (ref. '8') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2732 (ref. '9') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 3066 (ref. '10') (Obsoleted by RFC 4646, RFC 4647) ** Obsolete normative reference: RFC 3490 (ref. '11') (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 3548 (ref. '12') (Obsoleted by RFC 4648) -- Obsolete informational reference (is this intentional?): RFC 1305 (ref. '13') (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '16') (Obsoleted by RFC 7826) == Outdated reference: A later version (-15) exists of draft-ietf-mmusic-kmgmt-ext-12 == Outdated reference: A later version (-12) exists of draft-ietf-mmusic-sdescriptions-07 Summary: 14 errors (**), 0 flaws (~~), 9 warnings (==), 11 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: August 19, 2005 C. Perkins 6 University of Glasgow 7 February 18, 2005 9 SDP: Session Description Protocol 10 draft-ietf-mmusic-sdp-new-24.txt 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 19, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 This memo defines the Session Description Protocol (SDP). SDP is 46 intended for describing multimedia sessions for the purposes of 47 session announcement, session invitation, and other forms of 48 multimedia session initiation. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . 3 54 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . 4 55 3.1 Multicast Session Announcement . . . . . . . . . . . . . . 4 56 3.2 Session Initiation . . . . . . . . . . . . . . . . . . . . 4 57 3.3 Streaming media . . . . . . . . . . . . . . . . . . . . . 4 58 3.4 Email and the World Wide Web . . . . . . . . . . . . . . . 4 59 4. Requirements and Recommendations . . . . . . . . . . . . . . 5 60 4.1 Media and Transport Information . . . . . . . . . . . . . 6 61 4.2 Timing Information . . . . . . . . . . . . . . . . . . . . 6 62 4.3 Private Sessions . . . . . . . . . . . . . . . . . . . . . 7 63 4.4 Obtaining Further Information about a Session . . . . . . 7 64 4.5 Categorisation . . . . . . . . . . . . . . . . . . . . . . 7 65 4.6 Internationalisation . . . . . . . . . . . . . . . . . . . 7 66 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . 7 67 5.1 Protocol Version ("v=") . . . . . . . . . . . . . . . . . 10 68 5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 11 69 5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . . 12 70 5.4 Session Information ("i=") . . . . . . . . . . . . . . . . 12 71 5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 12 72 5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . 13 73 5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . 14 74 5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 16 75 5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 17 76 5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . 18 77 5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . 18 78 5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 19 79 5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . 21 80 5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . . 22 81 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 25 82 7. Security Considerations . . . . . . . . . . . . . . . . . . 31 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32 84 8.1 The "application/sdp" media type . . . . . . . . . . . . . 32 85 8.2 Registration of Parameters . . . . . . . . . . . . . . . . 33 86 8.3 Encryption Key Access Methods . . . . . . . . . . . . . . 38 87 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 38 88 10. Summary of Changes from RFC 2327 . . . . . . . . . . . . . . 43 89 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 91 12.1 Normative References . . . . . . . . . . . . . . . . . . . 44 92 12.2 Informative References . . . . . . . . . . . . . . . . . . 45 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 46 94 Intellectual Property and Copyright Statements . . . . . . . 48 96 1. Introduction 98 When initiating multimedia teleconferences, voice-over-IP calls, 99 streaming video, or other sessions, there is a requirement to convey 100 media details, transport addresses, and other session description 101 metadata to the participants. 103 SDP provides a standard representation for such information, 104 irrespective of how that information is transported. SDP is purely a 105 format for session description - it does not incorporate a transport 106 protocol, and is intended to use different transport protocols as 107 appropriate, including the Session Announcement Protocol [14], 108 Session Initiation Protocol [15], Real-Time Streaming Protocol [16], 109 electronic mail using the MIME extensions, and the Hypertext 110 Transport Protocol. 112 SDP is intended to be general purpose so that it can be used in a 113 wide range of network environments and applications. However, it is 114 not intended to support negotiation of session content or media 115 encodings: this is viewed as outside the scope of session 116 description. 118 This memo updates RFC 2327 [6] in the light of implementation 119 experience, and adds a small number of new features. Section 10 120 outlines the changes introduced in this memo. 122 2. Glossary of Terms 124 The following terms are used in this document, and have specific 125 meaning within the context of this document. 127 Conference: A multimedia conference is a set of two or more 128 communicating users along with the software they are using to 129 communicate. 131 Session: A multimedia session is a set of multimedia senders and 132 receivers and the data streams flowing from senders to receivers. 133 A multimedia conference is an example of a multimedia session. 135 Session Description: A well defined format for conveying sufficient 136 information to discover and participate in a multimedia session. 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [3]. 142 3. Examples of SDP Usage 144 3.1 Multicast Session Announcement 146 In order to assist the advertisement of multicast multimedia 147 conferences and other multicast sessions, and to communicate the 148 relevant session setup information to prospective participants, a 149 distributed session directory may be used. An instance of such a 150 session directory periodically sends packets containing a description 151 of the session to a well known multicast group. These advertisements 152 are received by other session directories such that potential remote 153 participants can use the session description to start the tools 154 required to participate in the session. 156 One protocol commonly used to implement such a distributed directory 157 is the Session Announcement Protocol, SAP [14]. SDP provides the 158 recommended session description format for such session 159 announcements. 161 3.2 Session Initiation 163 The Session Initiation Protocol, SIP [15] is an application layer 164 control protocol for creating, modifying and terminating sessions 165 such as Internet multimedia conferences, Internet telephone calls and 166 multimedia distribution. The SIP messages used to create sessions 167 carry session descriptions which allow participants to agree on a set 168 of compatible media types. These session descriptions are commonly 169 formatted using SDP. When used with SIP, the offer/answer model [17] 170 provides a limited framework for negotiation using SDP. 172 3.3 Streaming media 174 The Real Time Streaming Protocol, RTSP [16], is an application-level 175 protocol for control over the delivery of data with real-time 176 properties. RTSP provides an extensible framework to enable 177 controlled, on-demand delivery of real-time data, such as audio and 178 video. An RTSP client and server negotiate an appropriate set of 179 parameters for media delivery, partially using SDP syntax to describe 180 those parameters. 182 3.4 Email and the World Wide Web 184 Alternative means of conveying session descriptions include 185 electronic mail and the World Wide Web. For both email and WWW 186 distribution, the MIME content type "application/sdp" is used. This 187 enables the automatic launching of applications for participation in 188 the session from the WWW client or mail reader in a standard manner. 190 Note that announcements of multicast sessions made only via email or 191 the World Wide Web (WWW) do not have the property that the receiver 192 of a session announcement can necessarily receive the session because 193 the multicast sessions may be restricted in scope, and access to the 194 WWW server or reception of email is possible outside this scope. 195 Session announcements made using SAP do not suffer this mismatch. 197 4. Requirements and Recommendations 199 The purpose of SDP is to convey information about media streams in 200 multimedia sessions to allow the recipients of a session description 201 to participate in the session. SDP is primarily intended for use in 202 an internetwork, although it is sufficiently general that it can 203 describe conferences in other network environments. Media streams 204 can be many-to-many. The times during which the session is active 205 need not be continuous. 207 Thus far, multicast based sessions on the Internet have differed from 208 many other forms of conferencing in that anyone receiving the traffic 209 can join the session (unless the session traffic is encrypted). In 210 such an environment, SDP serves two primary purposes. It is a means 211 to communicate the existence of a session, and is a means to convey 212 sufficient information to enable joining and participating in the 213 session. In a unicast environment, only the latter purpose is likely 214 to be relevant. 216 An SDP session description includes: 218 o Session name and purpose 220 o Time(s) the session is active 222 o The media comprising the session 224 o Information needed to receive those media (addresses, ports, 225 formats and so on) 227 As resources necessary to participate in a session may be limited, 228 some additional information may also be desirable: 230 o Information about the bandwidth to be used by the session 232 o Contact information for the person responsible for the session 234 In general, SDP must convey sufficient information to enable 235 applications to join a session (with the possible exception of 236 encryption keys), and to announce the resources to be used to any 237 non-participants that may need to know (this latter feature is 238 primarily useful when SDP is used with a multicast session 239 announcement protocol). 241 4.1 Media and Transport Information 243 An SDP session description includes the following media information: 245 o The type of media (video, audio, etc.) 247 o The transport protocol (RTP/UDP/IP, H.320, etc.) 249 o The format of the media (H.261 video, MPEG video, etc.) 251 In addition to media format and transport protocol, SDP conveys 252 address and port details. For an IP multicast session, these 253 comprise: 255 o The multicast group address for media 257 o The transport port for media 259 This address and port are the destination address and destination 260 port of the multicast stream, whether being sent, received, or both. 262 For unicast IP sessions, the following are conveyed: 264 o The remote address for media 266 o The remote transport port for media 268 The semantics of this address and port depend on the media and 269 transport protocol defined. By default, this SHOULD be the remote 270 address and remote port to which data is sent. Some media types MAY 271 redefine this behaviour, but this is NOT RECOMMENDED. 273 4.2 Timing Information 275 Sessions may either be bounded or unbounded in time. Whether or not 276 they are bounded, they may be only active at specific times. SDP can 277 convey: 279 o An arbitrary list of start and stop times bounding the session 281 o For each bound, repeat times such as "every Wednesday at 10am for 282 one hour" 284 This timing information is globally consistent, irrespective of local 285 time zone or daylight saving time. 287 4.3 Private Sessions 289 It is possible to create both public sessions and private sessions. 290 SDP itself does not distinguish between these: private sessions are 291 typically conveyed by encrypting the session description during 292 distribution. The details of how encryption is performed are 293 dependent on the mechanism used to convey SDP: mechanisms are 294 currently defined for SDP transported using SAP [14] and SIP [15], 295 others may be defined in future. 297 If a session announcement is private it is possible to use that 298 private announcement to convey encryption keys necessary to decode 299 each of the media in a conference, including enough information to 300 know which encryption scheme is used for each media. 302 4.4 Obtaining Further Information about a Session 304 A session description should convey enough information to decide 305 whether or not to participate in a session. SDP may include 306 additional pointers in the form of Universal Resources Identifiers 307 (URIs) for more information about the session. 309 4.5 Categorisation 311 When many session descriptions are being distributed by SAP, or any 312 other advertisement mechanism, it may be desirable to filter session 313 announcements that are of interest from those that are not. SDP 314 supports a categorisation mechanism for sessions that is capable of 315 being automated. 317 4.6 Internationalisation 319 The SDP specification recommends the use of the ISO 10646 character 320 sets in the UTF-8 encoding [5] to allow many different languages to 321 be represented. However, to assist in compact representations, SDP 322 also allows other character sets such as ISO 8859-1 to be used when 323 desired. Internationalisation only applies to free-text fields 324 (session name and background information), and not to SDP as a whole. 326 5. SDP Specification 328 An SDP session description is denoted by the MIME content type 329 "application/sdp" (See Section 8). 331 An SDP session description is entirely textual using the ISO 10646 332 character set in UTF-8 encoding. SDP field names and attribute names 333 use only the US-ASCII subset of UTF-8, but textual fields and 334 attribute values MAY use the full ISO 10646 character set. Field and 335 attribute values which use the full UTF-8 character set are never 336 directly compared, hence there is no requirement for UTF-8 337 normalisation. The textual form, as opposed to a binary encoding 338 such as ASN.1 or XDR, was chosen to enhance portability, to enable a 339 variety of transports to be used, and to allow flexible, text-based 340 toolkits to be used to generate and process session descriptions. 341 However, since SDP may be used in environments where the maximum 342 permissible size of a session description is limited, the encoding is 343 deliberately compact. Also, since announcements may be transported 344 via very unreliable means or damaged by an intermediate caching 345 server, the encoding was designed with strict order and formatting 346 rules so that most errors would result in malformed session 347 announcements which could be detected easily and discarded. This 348 also allows rapid discarding of encrypted session announcements for 349 which a receiver does not have the correct key. 351 An SDP session description consists of a number of lines of text of 352 the form: 354 = 356 where MUST be exactly one case-significant character and 357 is structured text whose format depends on . In 358 general is either a number of fields delimited by a single 359 space character, or a free format string. Whitespace MUST NOT be 360 used either side of the "=" sign. 362 An SDP session description consists of a session-level section 363 followed by zero or more media-level sections. The session-level 364 part starts with a "v=" line and continues to the first media-level 365 section. The media description starts with an "m=" line and 366 continues to the next media description or end of the whole session 367 description. In general, session-level values are the default for 368 all media unless overridden by an equivalent media-level value. 370 Some lines in each description are REQUIRED and some are OPTIONAL but 371 all MUST appear in exactly the order given here (the fixed order 372 greatly enhances error detection and allows for a simple parser). 373 OPTIONAL items are marked with a "*". 375 Session description 376 v= (protocol version) 377 o= (owner/creator and session identifier) 378 s= (session name) 379 i=* (session information) 380 u=* (URI of description) 381 e=* (email address) 382 p=* (phone number) 383 c=* (connection information - not required if included in 384 all media) 385 b=* (zero or more bandwidth information lines) 386 One or more time descriptions ("t=" and "r=" lines, see below) 387 z=* (time zone adjustments) 388 k=* (encryption key) 389 a=* (zero or more session attribute lines) 390 Zero or more media descriptions 392 Time description 393 t= (time the session is active) 394 r=* (zero or more repeat times) 396 Media description, if present 397 m= (media name and transport address) 398 i=* (media title) 399 c=* (connection information - optional if included at 400 session-level) 401 b=* (zero or more bandwidth information lines) 402 k=* (encryption key) 403 a=* (zero or more media attribute lines) 405 The set of type letters is deliberately small and not intended to be 406 extensible -- an SDP parser MUST completely ignore any session 407 description that contains a type letter that it does not understand. 408 The attribute mechanism ("a=" described below) is the primary means 409 for extending SDP and tailoring it to particular applications or 410 media. Some attributes (the ones listed in Section 6 of this memo) 411 have a defined meaning, but others may be added on an application-, 412 media- or session-specific basis. An SDP parser MUST ignore any 413 attribute it doesn't understand. 415 An SDP session description may contain URIs which reference external 416 content in the "u=", "k=" and "a=" lines. These URIs may be 417 dereferenced in some cases, making the session description non-self 418 contained. 420 The connection ("c=") and attribute ("a=") information in the 421 session-level section applies to all the media of that session unless 422 overridden by connection information or an attribute of the same name 423 in the media description. For instance, in the example below, each 424 media behaves as if it were given a "recvonly" attribute. 426 An example SDP description is: 428 v=0 429 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 430 s=SDP Seminar 431 i=A Seminar on the session description protocol 432 u=http://www.example.com/seminars/sdp.pdf 433 e=j.doe@example.com (Jane Doe) 434 c=IN IP4 224.2.17.12/127 435 t=2873397496 2873404696 436 a=recvonly 437 m=audio 49170 RTP/AVP 0 438 m=video 51372 RTP/AVP 99 439 a=rtpmap:99 h263-1998/90000 441 Text fields such as the session name and information are octet 442 strings which may contain any octet with the exceptions of 0x00 443 (Nul), 0x0a (ASCII newline) and 0x0d (ASCII carriage return). The 444 sequence CRLF (0x0d0a) is used to end a record, although parsers 445 SHOULD be tolerant and also accept records terminated with a single 446 newline character. If the "a=charset" attribute is not present, 447 these octet strings MUST be interpreted as containing ISO-10646 448 characters in UTF-8 encoding (the presence of the "a=charset" 449 attribute MAY force some fields to be interpreted differently). 451 A session description can contain domain names in the "o=", "u=", 452 "e=", "c=" and "a=" lines. Any domain name used in SDP MUST comply 453 with [1], [2]. Internationalised domain names (IDNs) MUST be 454 represented using the ASCII Compatible Encoding (ACE) form defined in 455 [11] and MUST NOT be directly represented in UTF-8 or any other 456 encoding (this requirement is for compatibility with RFC 2327 and 457 other SDP-related standards, which predate the development of 458 internationalized domain names). 460 5.1 Protocol Version ("v=") 462 v=0 464 The "v=" field gives the version of the Session Description Protocol. 465 This memo defines version 0. There is no minor version number. 467 5.2 Origin ("o=") 469 o= 470 472 The "o=" field gives the originator of the session (her username and 473 the address of the user's host) plus a session identifier and version 474 number: 476 is the user's login on the originating host, or it is "-" 477 if the originating host does not support the concept of user ids. 478 The MUST NOT contain spaces. 480 is a numeric string such that the tuple of , 481 , , and form a 482 globally unique identifier for the session. The method of 483 allocation is up to the creating tool, but it has been 484 suggested that a Network Time Protocol (NTP) format timestamp be 485 used to ensure uniqueness [13]. 487 is a version number for this session description. Its 488 usage is up to the creating tool, so long as is 489 increased when a modification is made to the session data. Again, 490 it is RECOMMENDED that an NTP format timestamp is used. 492 is a text string giving the type of network. Initially 493 "IN" is defined to have the meaning "Internet", but other values 494 MAY be registered in future (see Section 8). 496 is a text string giving the type of the address that 497 follows. Initially "IP4" and "IP6" are defined, but other values 498 MAY be registered in future (see Section 8). 500 is the address of the machine from which the 501 session was created. For an address type of IP4, this is either 502 the fully-qualified domain name of the machine, or the 503 dotted-decimal representation of the IP version 4 address of the 504 machine. For an address type of IP6, this is either the 505 fully-qualified domain name of the machine, or the compressed 506 textual representation of the IP version 6 address of the machine. 507 For both IP4 and IP6, the fully-qualified domain name is the form 508 that SHOULD be given unless this is unavailable, in which case the 509 globally unique address MAY be substituted. A local IP address 510 MUST NOT be used in any context where the SDP description might 511 leave the scope in which the address is meaningful. 513 In general, the "o=" field serves as a globally unique identifier for 514 this version of this session description, and the subfields excepting 515 the version taken together identify the session irrespective of any 516 modifications. 518 For privacy reasons, it is sometimes desirable to obfuscate the 519 username and IP address of the session originator. If this is a 520 concern, an arbitrary and private MAY be 521 chosen to populate the "o=" field, provided these are selected in a 522 manner that does not affect the global uniqueness of the field. 524 5.3 Session Name ("s=") 526 s= 528 The "s=" field is the textual session name. There MUST be one and 529 only one "s=" field per session description. The "s=" field MUST NOT 530 be empty and SHOULD contain ISO 10646 characters (but see also the 531 "a=charset" attribute). If a session has no meaningful name, the 532 value "s= " SHOULD be used (i.e. a single space as the session 533 name). 535 5.4 Session Information ("i=") 537 i= 539 The "i=" field provides textual information about the session. There 540 MUST be at most one session-level "i=" field per session description, 541 and at most one "i=" field per media. If the "a=charset" attribute 542 is present, it specifies the character set used in the "i=" field. 543 If the "a=charset" attribute is not present, the "i=" field MUST 544 contain ISO 10646 characters in UTF-8 encoding. 546 A single "i=" field MAY also be used for each media definition. In 547 media definitions, "i=" fields are primarily intended for labelling 548 media streams. As such, they are most likely to be useful when a 549 single session has more than one distinct media stream of the same 550 media type. An example would be two different whiteboards, one for 551 slides and one for feedback and questions. 553 The "i=" field is intended to provide a free-form human readable 554 description of the session or the purpose of a media stream. It is 555 not suitable for parsing by automata. 557 5.5 URI ("u=") 559 u= 561 A URI is a Universal Resource Identifier as used by WWW clients [7], 562 [9]. The URI should be a pointer to additional information about the 563 session. This field is OPTIONAL, but if it is present it MUST be 564 specified before the first media field. No more than one URI field 565 is allowed per session description. 567 5.6 Email Address and Phone Number ("e=" and "p=") 569 e= 570 p= 572 The "e=" and "p=" lines specify contact information for the person 573 responsible for the conference. This is not necessarily the same 574 person that created the conference announcement. 576 Inclusion of an email address or phone number is OPTIONAL. Note that 577 the previous version of SDP specified that either an email field or a 578 phone field MUST be specified, but this was widely ignored. The 579 change brings the specification into line with common usage. 581 If the email address or phone number are present, they MUST be 582 specified before the first media field. More than one email or phone 583 field can be given for a session description. 585 Phone numbers SHOULD be given in the form of an international public 586 telecommunication number (see ITU-T Recommendation E.164) preceded by 587 a "+". Spaces and hyphens may be used to split up a phone field to 588 aid readability if desired. For example: 590 p=+1 617 555-6011 592 Both email addresses and phone numbers can have an OPTIONAL free text 593 string associated with them, normally giving the name of the person 594 who may be contacted. This MUST be enclosed in parenthesis if it is 595 present. For example: 597 e=j.doe@example.com (Jane Doe) 599 The alternative RFC 2822 name quoting convention is also allowed for 600 both email addresses and phone numbers. For example: 602 e=Jane Doe 604 The free text string SHOULD be in the ISO-10646 character set with 605 UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if 606 the appropriate session-level "a=charset" attribute is set. 608 5.7 Connection Data ("c=") 610 c= 612 The "c=" field contains connection data. 614 A session description MUST contain either at least one "c=" field in 615 each media description or a single "c=" field at the session level. 616 It MAY contain a single session-level "c=" field and additional "c=" 617 field(s) per media description, in which case the per-media values 618 override the session-level settings for the respective media. 620 The first sub-field ("") is the network type, which is a 621 text string giving the type of network. Initially "IN" is defined to 622 have the meaning "Internet", but other values MAY be registered in 623 the future (see Section 8). 625 The second sub-field ("") is the address type. This allows 626 SDP to be used for sessions that are not IP based. This memo only 627 defines IP4 and IP6, but other values MAY be registered in the future 628 (see Section 8). 630 The third sub-field ("") is the connection 631 address. OPTIONAL sub-fields MAY be added after the connection 632 address depending on the value of the field. 634 When the is IP4 and IP6, the connection address is defined 635 as follows: 637 o If the session is multicast, the connection address will be an IP 638 multicast group address. If the session is not multicast, then 639 the connection address contains the unicast IP address of the 640 expected data source or data relay or data sink as determined by 641 additional attribute fields. It is not expected that unicast 642 addresses will be given in a session description that is 643 communicated by a multicast announcement, though this is not 644 prohibited. 646 o Sessions using an IPv4 multicast connection address MUST also have 647 a time to live (TTL) value present in addition to the multicast 648 address. The TTL and the address together define the scope with 649 which multicast packets sent in this conference will be sent. TTL 650 values MUST be in the range 0-255. While the TTL MUST be 651 specified, its use to scope multicast traffic is deprecated; 652 applications SHOULD use an administratively scoped address 653 instead. 655 The TTL for the session is appended to the address using a slash as a 656 separator. An example is: 658 c=IN IP4 224.2.36.42/127 660 IPv6 multicast does not use TTL scoping, and hence the TTL value MUST 661 NOT be present for IPv6 multicast. It is expected that IPv6 scoped 662 addresses will be used to limit the scope of conferences. 664 Hierarchical or layered encoding schemes are data streams where the 665 encoding from a single media source is split into a number of layers. 666 The receiver can choose the desired quality (and hence bandwidth) by 667 only subscribing to a subset of these layers. Such layered encodings 668 are normally transmitted in multiple multicast groups to allow 669 multicast pruning. This technique keeps unwanted traffic from sites 670 only requiring certain levels of the hierarchy. For applications 671 requiring multiple multicast groups, we allow the following notation 672 to be used for the connection address: 674 [/]/ 676 If the number of addresses is not given it is assumed to be one. 677 Multicast addresses so assigned are contiguously allocated above the 678 base address, so that, for example: 680 c=IN IP4 224.2.1.1/127/3 682 would state that addresses 224.2.1.1, 224.2.1.2 and 224.2.1.3 are to 683 be used at a TTL of 127. This is semantically identical to including 684 multiple "c=" lines in a media description: 686 c=IN IP4 224.2.1.1/127 687 c=IN IP4 224.2.1.2/127 688 c=IN IP4 224.2.1.3/127 690 Similarly, an IPv6 example would be: 692 c=IN IP6 FF15::101/3 694 which is semantically equivalent to: 696 c=IN IP6 FF15::101 697 c=IN IP6 FF15::102 698 c=IN IP6 FF15::103 700 (remembering that the TTL field is not present in IPv6 multicast). 702 Multiple addresses or "c=" lines MAY be specified on a per-media 703 basis only if they provide multicast addresses for different layers 704 in a hierarchical or layered encoding scheme. They MUST NOT be 705 specified for a session-level "c=" field. 707 The slash notation for multiple addresses described above MUST NOT be 708 used for IP unicast addresses. 710 5.8 Bandwidth ("b=") 712 b=: 714 This OPTIONAL field denotes the proposed bandwidth to be used by the 715 session or media. The is an alphanumeric modifier giving 716 the meaning of the figure. Two values are defined in 717 this specification, but other values MAY be registered in future (see 718 Section 8 and [20], [24]): 720 CT If the bandwidth of a session or media in a session is different 721 from the bandwidth implicit from the scope, a "b=CT:..." line 722 SHOULD be supplied for the session giving the proposed upper limit 723 to the bandwidth used (the "conference total" bandwidth). The 724 primary purpose of this is to give an approximate idea as to 725 whether two or more sessions can co-exist simultaneously. When 726 using the CT modifier with RTP, if several RTP sessions are part 727 of the conference, the conference total refers to total bandwidth 728 of all RTP sessions. 730 AS The bandwidth is interpreted to be application-specific (it will 731 be the application's concept of maximum bandwidth). Normally this 732 will coincide with what is set on the application's "maximum 733 bandwidth" control if applicable. For RTP based applications, AS 734 gives the RTP "session bandwidth" as defined in Section 6.2 of 735 [18]. 737 Note that CT gives a total bandwidth figure for all the media at all 738 sites. AS gives a bandwidth figure for a single media at a single 739 site, although there may be many sites sending simultaneously. 741 A prefix "X-" is defined for names. This is intended for 742 experimental purposes only. For example: 744 b=X-YZ:128 746 Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers 747 SHOULD be registered with IANA in the standard namespace. SDP 748 parsers MUST ignore bandwidth fields with unknown modifiers. 749 Modifiers MUST be alpha-numeric and, although no length limit is 750 given, they are recommended to be short. 752 The is interpreted as kilobits per second by default. 753 The definition of a new modifier MAY specify that the 754 bandwidth is to be interpreted in some alternative unit (the "CT" and 755 "AS" modifiers defined in this memo use the default units). 757 5.9 Timing ("t=") 759 t= 761 The "t=" lines specify the start and stop times for a session. 762 Multiple "t=" lines MAY be used if a session is active at multiple 763 irregularly spaced times; each additional "t=" lines specifies an 764 additional period of time for which the session will be active. If 765 the session is active at regular times, an "r=" line (see below) 766 should be used in addition to, and following, a "t=" line - in which 767 case the "t=" line specifies the start and stop times of the repeat 768 sequence. 770 The first and second sub-fields give the start and stop times for the 771 session respectively. These values are the decimal representation of 772 Network Time Protocol (NTP) time values in seconds since 1900 [13]. 773 To convert these values to UNIX time, subtract decimal 2208988800. 775 NTP timestamps are elsewhere represented by 64 bit values which wrap 776 sometime in the year 2036. Since SDP uses an arbitrary length 777 decimal representation, this should not cause an issue (SDP 778 timestamps MUST continue counting seconds since 1900, NTP will use 779 the value modulo the 64 bit limit). 781 If the is set to zero, then the session is not bounded, 782 though it will not become active until after the . If 783 the is also zero, the session is regarded as permanent. 785 User interfaces SHOULD strongly discourage the creation of unbounded 786 and permanent sessions as they give no information about when the 787 session is actually going to terminate, and so make scheduling 788 difficult. 790 The general assumption may be made, when displaying unbounded 791 sessions that have not timed out to the user, that an unbounded 792 session will only be active until half an hour from the current time 793 or the session start time, whichever is the later. If behaviour 794 other than this is required, an end-time SHOULD be given and modified 795 as appropriate when new information becomes available about when the 796 session should really end. 798 Permanent sessions may be shown to the user as never being active 799 unless there are associated repeat times which state precisely when 800 the session will be active. In general, permanent sessions SHOULD 801 NOT be created for any session expected to have a duration of less 802 than 2 months, and should be discouraged for sessions expected to 803 have a duration of less than 6 months. 805 5.10 Repeat Times ("r=") 807 r= 809 "r=" fields specify repeat times for a session. For example, if a 810 session is active at 10am on Monday and 11am on Tuesday for one hour 811 each week for three months, then the in the 812 corresponding "t=" field would be the NTP representation of 10am on 813 the first Monday, the would be 1 week, the would be 1 hour, and the offsets would be zero and 25 815 hours. The corresponding "t=" field stop time would be the NTP 816 representation of the end of the last session three months later. By 817 default all fields are in seconds, so the "r=" and "t=" fields might 818 be: 820 t=3034423619 3042462419 821 r=604800 3600 0 90000 823 To make description more compact, times may also be given in units of 824 days, hours or minutes. The syntax for these is a number immediately 825 followed by a single case-sensitive character. Fractional units are 826 not allowed - a smaller unit should be used instead. The following 827 unit specification characters are allowed: 829 d - days (86400 seconds) 830 h - hours (3600 seconds) 831 m - minutes (60 seconds) 832 s - seconds (allowed for completeness but NOT RECOMMENDED) 834 Thus, the above session announcement could also have been written: 836 r=7d 1h 0 25h 838 Monthly and yearly repeats cannot be directly specified with a single 839 SDP repeat time - instead separate "t=" fields should be used to 840 explicitly list the session times. 842 5.11 Time Zones ("z=") 844 z= .... 846 To schedule a repeated session which spans a change from daylight 847 saving time to standard time or vice-versa, it is necessary to 848 specify offsets from the base time. This is required because 849 different time zones change time at different times of day, different 850 countries change to or from daylight time on different dates, and 851 some countries do not have daylight saving time at all. 853 Thus in order to schedule a session that is at the same time winter 854 and summer, it must be possible to specify unambiguously by whose 855 time zone a session is scheduled. To simplify this task for 856 receivers, we allow the sender to specify the NTP time that a time 857 zone adjustment happens and the offset from the time when the session 858 was first scheduled. The "z=" field allows the sender to specify a 859 list of these adjustment times and offsets from the base time. 861 An example might be: 863 z=2882844526 -1h 2898848070 0 865 This specifies that at time 2882844526 the time base by which the 866 session's repeat times are calculated is shifted back by 1 hour, and 867 that at time 2898848070 the session's original time base is restored. 868 Adjustments are always relative to the specified start time - they 869 are not cumulative. Adjustments apply to all "t=" and "r=" lines in 870 a session description. 872 If a session is likely to last several years, it is expected that the 873 session announcement will be modified periodically rather than 874 transmit several years worth of adjustments in one session 875 announcement. 877 5.12 Encryption Keys ("k=") 879 k= 880 k=: 882 If transported over a secure and trusted channel, the session 883 description protocol MAY be used to convey encryption keys. A simple 884 mechanism for key exchange is provided by the key field ("k=") 885 although this is primarily supported for compatibility with older 886 implementations and its use is NOT RECOMMENDED. Work is in progress 887 to define new key exchange mechanisms for use with SDP [26][27] and 888 it is expected that new applications will use those mechanisms. 890 A key field is permitted before the first media entry (in which case 891 it applies to all media in the session), or for each media entry as 892 required. The format of keys and their usage is outside the scope of 893 this document, and the key field provides no way to indicate the 894 encryption algorithm to be used, key type, or other information about 895 the key: this is assumed to be provided by the higher-level protocol 896 using SDP. If there is a need to convey this information within SDP, 897 the extensions mentioned previously SHOULD be used. Many security 898 protocols require two keys: one for confidentiality, another for 899 integrity. This specification does not support transfer of two keys. 901 The method indicates the mechanism to be used to obtain a usable key 902 by external means, or from the encoded encryption key given. The 903 following methods are defined: 905 k=clear: 907 The encryption key is included untransformed in this key field. 908 This method MUST NOT be used unless it can be guaranteed that 909 the SDP is conveyed over a secure channel. The encryption key 910 is interpreted as text according to the charset attribute, use 911 the "k=base64:" method to convey characters that are otherwise 912 prohibited in SDP. 914 k=base64: 916 The encryption key is included in this key field but has been 917 base64 encoded [12] because it includes characters that are 918 prohibited in SDP. This method MUST NOT be used unless it can 919 be guaranteed that the SDP is conveyed over a secure channel. 921 k=uri: 923 A Universal Resource Identifier is included in the key field. 924 The URI refers to the data containing the key, and may require 925 additional authentication before the key can be returned. When 926 a request is made to the given URI, the reply should specify 927 the encoding for the key. The URI is often a secure HTTP URI, 928 although this is not required. 930 k=prompt 932 No key is included in this SDP description, but the session or 933 media stream referred to by this key field is encrypted. The 934 user should be prompted for the key when attempting to join the 935 session, and this user-supplied key should then be used to 936 decrypt the media streams. The use of user-specified keys is 937 NOT RECOMMENDED, since such keys tend to have weak security 938 properties. 940 The key field MUST NOT be used unless it can be guaranteed that the 941 SDP is conveyed over a secure and trusted channel. An example of 942 such a channel might be SDP embedded inside an S/MIME message or a 943 TLS-protected HTTP session. It is important to ensure that the 944 secure channel is with the party that is authorised to join the 945 session, not an intermediary: if a caching proxy server is used, it 946 is important to ensure that the proxy is either trusted or unable to 947 access the SDP. Definition of appropriate security measures is 948 beyond the scope of this specification, and should be defined by the 949 users of SDP. 951 5.13 Attributes ("a=") 953 a= 954 a=: 956 Attributes are the primary means for extending SDP. Attributes may 957 be defined to be used as "session-level" attributes, "media-level" 958 attributes, or both. 960 A media description may have any number of attributes ("a=" fields) 961 which are media specific. These are referred to as "media-level" 962 attributes and add information about the media stream. Attribute 963 fields can also be added before the first media field; these 964 "session-level" attributes convey additional information that applies 965 to the conference as a whole rather than to individual media. 967 Attribute fields may be of two forms: 969 o A property attribute is simply of the form "a=". These are 970 binary attributes, and the presence of the attribute conveys that 971 the attribute is a property of the session. An example might be 972 "a=recvonly". 974 o A value attribute is of the form "a=:". For 975 example, a whiteboard could have the value attribute 976 "a=orient:landscape" 978 Attribute interpretation depends on the media tool being invoked. 979 Thus receivers of session descriptions should be configurable in 980 their interpretation of session descriptions in general and of 981 attributes in particular. 983 Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. 985 Attribute values are octet strings, and MAY use any octet value 986 except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute 987 values are to be interpreted as in ISO-10646 character set with UTF-8 988 encoding. Unlike other text fields, attribute values are NOT 989 normally affected by the "charset" attribute as this would make 990 comparisons against known values problematic. However, when an 991 attribute is defined, it can be defined to be charset-dependent, in 992 which case its value should be interpreted in the session charset 993 rather than in ISO-10646. 995 Attributes MUST be registered with IANA (see Section 8). If an 996 attribute is received that is not understood, it MUST be ignored by 997 the receiver. 999 5.14 Media Descriptions ("m=") 1001 m= ... 1003 A session description may contain a number of media descriptions. 1004 Each media description starts with an "m=" field, and is terminated 1005 by either the next "m=" field or by the end of the session 1006 description. A media field has several sub-fields: 1008 is the media type. Currently defined media are "audio", 1009 "video", "text", "application" and "message", although this list 1010 may be extended in future (see Section 8). 1012 is the transport port to which the media stream is sent. The 1013 meaning of the transport port depends on the network being used as 1014 specified in the relevant "c=" field, and on the transport 1015 protocol defined in the sub-field of the media field. 1016 Other ports used by the media application (such as the RTCP port 1017 [18]) MAY be derived algorithmically from the base media port or 1018 MAY be specified in a separate attribute (for example "a=rtcp:" as 1019 defined in [21]). 1021 If non-contiguous ports are used or if they don't follow the 1022 parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" 1023 attribute MUST be used. Applications that are requested to send 1024 media to a that is odd and where the "a=rtcp:" is present 1025 MUST NOT substract 1 to the RTP port: i.e, they MUST send the RTP 1026 to the port indicated in and send the RTCP to the port 1027 indicated in the "a=rtcp" attribute. 1029 For applications where hierarchically encoded streams are being 1030 sent to a unicast address, it may be necessary to specify multiple 1031 transport ports. This is done using a similar notation to that 1032 used for IP multicast addresses in the "c=" field: 1034 m= / ... 1036 In such a case, the ports used depend on the transport protocol. 1037 For RTP, the default is that only the even numbered ports are used 1038 for data with the corresponding one-higher odd ports used for the 1039 RTCP belonging to the RTP session, and the 1040 denoting the number of RTP sessions. For example: 1042 m=video 49170/2 RTP/AVP 31 1044 would specify that ports 49170 and 49171 form one RTP/RTCP pair 1045 and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the 1046 transport protocol and 31 is the format (see below). If 1047 non-contiguous ports are required, they must be signalled using a 1048 separate attribute (for example "a=rtcp:" as defined in [21]). 1050 If multiple addresses are specified in the "c=" field and multiple 1051 ports are specified in the "m=" field, a one-to-one mapping from 1052 port to the corresponding address is implied. For example: 1054 c=IN IP4 224.2.1.1/127/2 1055 m=video 49170/2 RTP/AVP 31 1057 would imply that address 224.2.1.1 is used with ports 49170 and 1058 49171, and address 224.2.1.2 is used with ports 49172 and 49173. 1060 The combination of ports specified in "m=" lines and IP addresses 1061 specified in "c=" lines MUST comply with the following rules for 1062 RTP-based media streams (other protocols SHOULD define similar 1063 rules): 1065 1. If two media sessions have the same transport address (i.e. 1066 identical IP address and port numbers), the associated payload 1067 types (e.g. given in the "a=rtpmap:" attribute) MUST NOT be 1068 in conflict, i.e. the same payload type MUST NOT be mapped to 1069 different media types. 1071 2. If two media sessions have the same transport address, they 1072 MUST use compatible media (e.g. both audio or both video). 1074 3. If two media sessions have the same transport address, they 1075 SHOULD operate under the same RTP profile. The sessions MAY 1076 use two different RTP profiles only if those profiles are 1077 specifically designed to be compatible. 1079 4. If two media sessions have the same RTP transport address, 1080 they MUST also use the same RTCP address and vice versa. 1082 Two media sessions with the same transport address indicate 1083 alternatives for the same media stream, i.e. all profiles, media 1084 types, and payload types provided in any of the "m=" lines are 1085 valid. 1087 is the transport protocol. The meaning of the transport 1088 protocol is dependent on the address type field in the relevant 1089 "c=" field. Thus a "c=" field of IP4 indicates that the transport 1090 protocol runs over IP4. The following transport protocols are 1091 defined, but may be extended through registration of new protocols 1092 with IANA (see Section 8): 1094 * udp: denotes an unspecified protocol running over UDP. 1096 * RTP/AVP: denotes RTP [18] used under the RTP Profile for Audio 1097 and Video Conferences with Minimal Control [19] running over 1098 UDP. 1100 * RTP/SAVP: denotes the Secure Real-time Transport Protocol [22] 1101 running over UDP. 1103 The main reason to specify the transport-protocol in addition to 1104 the media format is that the same standard media formats may be 1105 carried over different transport protocols even when the network 1106 protocol is the same - a historical example is vat PCM audio and 1107 RTP PCM audio, another might be TCP/RTP PCM audio. In addition, 1108 relays and monitoring tools that are transport-protocol-specific 1109 but format-independent are possible. 1111 is a media format description. The fourth and any subsequent 1112 sub-fields describe the format of the media. The interpretation 1113 of the media format depends on the value of the sub-field. 1115 If the sub-field is "RTP/AVP" or "RTP/SAVP" the 1116 sub-fields contain RTP payload type numbers. When a list of 1117 payload type numbers is given, this implies that all of these 1118 payload formats MAY be used in the session, but the first of these 1119 formats SHOULD be used as the default format for the session. For 1120 dynamic payload type assignments the "a=rtpmap:" attribute (see 1121 Section 6) SHOULD be used to map from an RTP payload type number 1122 to a media encoding name that identifies the payload format. The 1123 "a=fmtp:" attribute MAY be used to specify format parameters (see 1124 Section 6). 1126 If the sub-field is "udp" the sub-fields MUST 1127 reference a media type describing the format under the "audio", 1128 "video", "text", "application" or "message" top-level MIME types. 1129 The media type registration SHOULD define the packet format for 1130 use with UDP transport. 1132 For media using other transport protocols, the field is 1133 protocol specific. Rules for interpretation of the 1134 sub-field MUST be defined when registering new protocols (see 1135 section 8.2.2). 1137 6. SDP Attributes 1139 The following attributes are defined. Since application writers may 1140 add new attributes as they are required, this list is not exhaustive. 1141 Registration procedures for new attributes are defined in Section 1142 8.2.4. 1144 a=cat: 1146 This attribute gives the dot-separated hierarchical category 1147 of the session. This is to enable a receiver to filter 1148 unwanted sessions by category. It is a session-level 1149 attribute, and is not dependent on charset. 1151 a=keywds: 1153 Like the cat attribute, this is to assist identifying wanted 1154 sessions at the receiver. This allows a receiver to select 1155 interesting session based on keywords describing the purpose 1156 of the session. It is a session-level attribute. It is a 1157 charset dependent attribute, meaning that its value should be 1158 interpreted in the charset specified for the session 1159 description if one is specified, or by default in ISO 1160 10646/UTF-8. 1162 a=tool: 1164 This gives the name and version number of the tool used to 1165 create the session description. It is a session-level 1166 attribute, and is not dependent on charset. 1168 a=ptime: 1170 This gives the length of time in milliseconds represented by 1171 the media in a packet. This is probably only meaningful for 1172 audio data, but may be used with other media types if it makes 1173 sense. It should not be necessary to know ptime to decode RTP 1174 or vat audio, and it is intended as a recommendation for the 1175 encoding/packetisation of audio. It is a media attribute, and 1176 is not dependent on charset. 1178 a=maxptime: 1180 The maximum amount of media which can be encapsulated in each 1181 packet, expressed as time in milliseconds. The time SHALL be 1182 calculated as the sum of the time the media present in the 1183 packet represents. For frame based codecs, the time SHOULD 1184 be an integer multiple of the frame size. This attribute is 1185 probably only meaningful for audio data, but may be used with 1186 other media types if it makes sense. It is a media attribute, 1187 and is not dependent on charset. Note that this attribute was 1188 introduced after RFC 2327, and non updated implementations will 1189 ignore this attribute. 1191 a=rtpmap: / 1192 [/] 1194 This attribute maps from an RTP payload type number (as used in 1195 an "m=" line) to an encoding name denoting the payload format 1196 to be used. It also provides information on the clock rate and 1197 encoding parameters. It is a media level attribute that is not 1198 dependent on charset. 1200 While an RTP profile may make static assignments of payload 1201 type numbers to payload formats, it is more common for that 1202 assignment to be done dynamically using "a=rtpmap:" attributes. 1203 As an example of a static payload type, consider u-law PCM 1204 coded single channel audio sampled at 8kHz. This is completely 1205 defined in the RTP Audio/Video profile as payload type 0, so 1206 there is no need for an "a=rtpmap: attribute, and the media for 1207 such a stream sent to UDP port 49232 can be specified as: 1209 m=audio 49232 RTP/AVP 0 1211 An example of a dynamic payload type is 16 bit linear encoded 1212 stereo audio sampled at 16 kHz. If we wish to use the dynamic 1213 RTP/AVP payload type 98 for this stream, additional information 1214 is required to decode it: 1216 m=audio 49232 RTP/AVP 98 1217 a=rtpmap:98 L16/16000/2 1219 Up to one rtpmap attribute can be defined for each media format 1220 specified. Thus we might have: 1222 m=audio 49230 RTP/AVP 96 97 98 1223 a=rtpmap:96 L8/8000 1224 a=rtpmap:97 L16/8000 1225 a=rtpmap:98 L16/11025/2 1227 RTP profiles that specify the use of dynamic payload types MUST 1228 define the set of valid encoding names and/or a means to 1229 register encoding names if that profile is to be used with SDP. 1231 The "RTP/AVP" and "RTP/SAVP" profiles use MIME sub-types for 1232 encoding names, under the top-level media type denoted in the 1233 "m=" line. In the example above, the media types are "audio/l8" 1234 and "audio/l16". 1236 For audio streams, indicates the 1237 number of audio channels. This parameter is OPTIONAL and 1238 may be omitted if the number of channels is one, provided 1239 no additional parameters are needed. 1241 For video streams, no encoding parameters are currently 1242 specified. 1244 Additional encoding parameters MAY be defined in the future, 1245 but codec specific parameters SHOULD NOT be added. Parameters 1246 added to an "a=rtpmap:" attribute SHOULD only be those required 1247 for a session directory to make the choice of appropriate media 1248 to participate in a session. Codec-specific parameters should 1249 be added in other attributes (for example, "a=fmtp:"). 1251 Note: RTP audio formats typically do not include information 1252 about the number of samples per packet. If a non-default (as 1253 defined in the RTP Audio/Video Profile) packetisation is 1254 required, the "ptime" attribute is used as given below. 1256 a=recvonly 1258 This specifies that the tools should be started in receive 1259 only mode where applicable. It can be either a session or 1260 media attribute, and is not dependent on charset. Note that 1261 recvonly applies to the media only, not to any associated 1262 control protocol (e.g. an RTP based system in recvonly mode 1263 SHOULD still send RTCP packets). 1265 a=sendrecv 1267 This specifies that the tools should be started in send and 1268 receive mode. This is necessary for interactive conferences 1269 with tools that default to receive only mode. It can be either 1270 a session or media attribute, and is not dependent on charset. 1272 If none of the attributes "sendonly", "recvonly", "inactive", 1273 and "sendrecv" is present, "sendrecv" SHOULD be assumed as the 1274 default for sessions which are not of the conference type 1275 "broadcast" or "H332" (see below). 1277 a=sendonly 1278 This specifies that the tools should be started in send-only 1279 mode. An example may be where a different unicast address is 1280 to be used for a traffic destination than for a traffic 1281 source. In such a case, two media descriptions may be used, 1282 one sendonly and one recvonly. It can be either a session or 1283 media attribute, but would normally only be used as a media 1284 attribute. It is not dependent on charset. Note that sendonly 1285 applies only to the media, and any associated control protocol 1286 (e.g. RTCP) SHOULD still be received and processed as normal. 1288 a=inactive 1290 This specifies that the tools should be started in inactive 1291 mode. This is necessary for interactive conferences where 1292 users can put other users on hold. No media is sent over an 1293 inactive media stream. Note that an RTP based system SHOULD 1294 still send RTCP, even if started inactive. It can be either a 1295 session or media attribute, and is not dependent on charset. 1297 a=orient: 1299 Normally this is only used for a whiteboard or presentation 1300 tool. It specifies the orientation of a the workspace on 1301 the screen. It is a media attribute. Permitted values are 1302 "portrait", "landscape" and "seascape" (upside down landscape). 1303 It is not dependent on charset. 1305 a=type: 1307 This specifies the type of the conference. Suggested values 1308 are "broadcast", "meeting", "moderated", "test" and "H332". 1309 "recvonly" should be the default for "type:broadcast" 1310 sessions, "type:meeting" should imply "sendrecv" and 1311 "type:moderated" should indicate the use of a floor control 1312 tool and that the media tools are started so as to mute new 1313 sites joining the conference. 1315 Specifying the attribute "type:H332" indicates that this 1316 loosely coupled session is part of a H.332 session as defined 1317 in the ITU H.332 specification [15]. Media tools should be 1318 started "recvonly". 1320 Specifying the attribute "type:test" is suggested as a hint 1321 that, unless explicitly requested otherwise, receivers can 1322 safely avoid displaying this session description to users. 1324 The type attribute is a session-level attribute, and is not 1325 dependent on charset. 1327 a=charset: 1329 This specifies the character set to be used to display the 1330 session name and information data. By default, the ISO-10646 1331 character set in UTF-8 encoding is used. If a more compact 1332 representation is required, other character sets may be used. 1333 For example, the ISO 8859-1 is specified with the following 1334 SDP attribute: 1336 a=charset:ISO-8859-1 1338 This is a session-level attribute and is not dependent on 1339 charset. The charset specified MUST be one of those registered 1340 with IANA, such as ISO-8859-1. The character set identifier is 1341 a US-ASCII string and MUST be compared against the IANA 1342 identifiers using a case insensitive comparison. If the 1343 identifier is not recognised or not supported, all strings that 1344 are affected by it SHOULD be regarded as octet strings. 1346 Note that a character set specified MUST still prohibit the 1347 use of bytes 0x00 (Nul), 0x0A (LF) and 0x0d (CR). Character 1348 sets requiring the use of these characters MUST define a 1349 quoting mechanism that prevents these bytes appearing within 1350 text fields. 1352 a=sdplang: 1354 This can be a session level attribute or a media level 1355 attribute. As a session level attribute, it specifies the 1356 language for the session description. As a media level 1357 attribute, it specifies the language for any media-level SDP 1358 information field associated with that media. Multiple 1359 sdplang attributes can be provided either at session or media 1360 level if multiple languages in the session description or 1361 media use multiple languages, in which case the order of the 1362 attributes indicates the order of importance of the various 1363 languages in the session or media from most important to least 1364 important. 1366 In general, sending session descriptions consisting of 1367 multiple languages is discouraged. Instead, multiple 1368 descriptions SHOULD be sent describing the session, one in 1369 each language. However this is not possible with all 1370 transport mechanisms, and so multiple sdplang attributes are 1371 allowed although NOT RECOMMENDED. 1373 The "sdplang" attribute value must be a single RFC 3066 1374 language tag in US-ASCII [6]. It is not dependent on 1375 the charset attribute. An "sdplang" attribute SHOULD be 1376 specified when a session is of sufficient scope to cross 1377 geographic boundaries where the language of recipients cannot 1378 be assumed, or where the session is in a different language 1379 from the locally assumed norm. 1381 a=lang: 1383 This can be a session level attribute or a media level 1384 attribute. As a session level attribute, it specifies the 1385 default language for the session being described. As a media 1386 level attribute, it specifies the language for that media, 1387 overriding any session-level language specified. Multiple 1388 lang attributes can be provided either at session or media 1389 level if the session description or media use multiple 1390 languages, in which case the order of the attributes indicates 1391 the order of importance of the various languages in the 1392 session or media from most important to least important. 1394 The "lang" attribute value must be a single RFC 3066 language 1395 tag in US-ASCII [6]. It is not dependent on the charset 1396 attribute. A "lang" attribute SHOULD be specified when a 1397 session is of sufficient scope to cross geographic boundaries 1398 where the language of recipients cannot be assumed, or where 1399 the session is in a different language from the locally 1400 assumed norm. 1402 a=framerate: 1404 This gives the maximum video frame rate in frames/sec. It is 1405 intended as a recommendation for the encoding of video data. 1406 Decimal representations of fractional values using the 1407 notation "." are allowed. It is a 1408 media attribute, defined only for video media, and is not 1409 dependent on charset. 1411 a=quality: 1413 This gives a suggestion for the quality of the encoding as an 1414 integer value. The intention of the quality attribute for 1415 video is to specify a non-default trade-off between frame-rate 1416 and still-image quality. For video, the value in the range 0 1417 to 10, with the following suggested meaning: 1419 10 - the best still-image quality the compression scheme 1420 can give. 1421 5 - the default behaviour given no quality suggestion. 1422 0 - the worst still-image quality the codec designer 1423 thinks is still usable. 1425 It is a media attribute, and is not dependent on charset. 1427 a=fmtp: 1429 This attribute allows parameters that are specific to a 1430 particular format to be conveyed in a way that SDP doesn't 1431 have to understand them. The format must be one of the 1432 formats specified for the media. Format-specific parameters 1433 may be any set of parameters required to be conveyed by SDP 1434 and given unchanged to the media tool that will use this 1435 format. At most one instance of this attribute is allowed 1436 for each format. 1438 It is a media attribute, and is not dependent on charset. 1440 7. Security Considerations 1442 SDP is frequently used with the Session Initiation Protocol [15] 1443 using the offer/answer model [17] to agree parameters for unicast 1444 sessions. When used in this manner, the security considerations of 1445 those protocols apply. 1447 SDP is a session description format that describes multimedia 1448 sessions. A session description SHOULD NOT be trusted unless it has 1449 been obtained by an authenticated transport protocol from a trusted 1450 source. Many different transport protocols may be used to distribute 1451 session description, and the nature of the authentication will differ 1452 from transport to transport. 1454 One transport that will frequently be used to distribute session 1455 descriptions is the Session Announcement Protocol (SAP). SAP 1456 provides both encryption and authentication mechanisms but due to the 1457 nature of session announcements it is likely that there are many 1458 occasions where the originator of a session announcement cannot be 1459 authenticated because they are previously unknown to the receiver of 1460 the announcement and because no common public key infrastructure is 1461 available. 1463 On receiving a session description over an unauthenticated transport 1464 mechanism or from an untrusted party, software parsing the session 1465 should take a few precautions. Session descriptions contain 1466 information required to start software on the receivers system. 1467 Software that parses a session description MUST NOT be able to start 1468 other software except that which is specifically configured as 1469 appropriate software to participate in multimedia sessions. It is 1470 normally considered inappropriate for software parsing a session 1471 description to start, on a user's system, software that is 1472 appropriate to participate in multimedia sessions, without the user 1473 first being informed that such software will be started and giving 1474 their consent. Thus a session description arriving by session 1475 announcement, email, session invitation, or WWW page MUST NOT deliver 1476 the user into an interactive multimedia session unless the user has 1477 explicitly pre-authorized such action. As it is not always simple to 1478 tell whether a session is interactive or not, applications that are 1479 unsure should assume sessions are interactive. 1481 In this specification, there are no attributes which would allow the 1482 recipient of a session description to be informed to start multimedia 1483 tools in a mode where they default to transmitting. Under some 1484 circumstances it might be appropriate to define such attributes. If 1485 this is done an application parsing a session description containing 1486 such attributes SHOULD either ignore them, or inform the user that 1487 joining this session will result in the automatic transmission of 1488 multimedia data. The default behaviour for an unknown attribute is 1489 to ignore it. 1491 Session descriptions may be parsed at intermediate systems such as 1492 firewalls for the purposes of opening a hole in the firewall to allow 1493 participation in multimedia sessions. This SHOULD NOT be done unless 1494 the SDP is conveyed in a manner that allows proper authentication and 1495 authorization checks to ensure that firewall holes are only opened in 1496 accordance with applicable security policy. SDP by itself does not 1497 include sufficient information to enable these checks: they depend on 1498 the encapsulating protocol (e.g. SIP or RTSP). 1500 Use of the "k=" field poses a significant security risk, since it 1501 conveys session encryption keys in the clear. SDP MUST NOT be used 1502 to convey key material, unless it can be guaranteed that the channel 1503 over which the SDP is delivered is both private and authenticated. 1505 8. IANA Considerations 1507 8.1 The "application/sdp" media type 1509 One MIME type is to be registered, as defined below. This updates 1510 the previous definition from RFC 2327. 1512 To: ietf-types@iana.org 1513 Subject: Registration of media type "application/sdp" 1515 MIME media type name: application 1517 MIME subtype name: sdp 1518 Required parameters: None. 1520 Optional parameters: None. 1522 Encoding considerations: 1523 SDP files are primarily 7-bit ASCII text. The "a=charset:" 1524 attribute may be used to signal the presence of other, 1525 possibly 8-bit, text in certain parts of an SDP file (see 1526 section 6 of RFC XXXX). Arbitrary binary content cannot 1527 be directly represented in SDP. 1529 Security considerations: 1530 See section 7 of RFC XXXX 1532 Interoperability considerations: 1533 See RFC XXXX 1535 Published specification: 1536 See RFC XXXX 1538 Applications which use this media type: 1539 Voice over IP, video teleconferencing, streaming media, instant 1540 messaging, etc. See also section 3 of RFC XXXX. 1542 Additional information: 1544 Magic number(s): None. 1545 File extension(s): The extension ".sdp" is commonly used. 1546 Macintosh File Type Code(s): "sdp " 1548 Person & email address to contact for further information: 1549 Mark Handley 1550 Colin Perkins 1551 IETF MMUSIC working group 1553 Intended usage: COMMON 1555 Author/Change controller: 1556 Authors of RFC XXXX 1557 IETF MMUSIC working group delegated from the IESG 1559 8.2 Registration of Parameters 1561 There are seven field names that may be registered with IANA. Using 1562 the terminology in the SDP specification BNF, they are "media", 1563 "proto", "fmt", "att-field", "bwtype", "nettype" and "addrtype". 1565 8.2.1 Media types ("media") 1567 The set of media types is intended to be small and SHOULD NOT be 1568 extended except under rare circumstances. The same rules should 1569 apply for media names as for top-level MIME content types, and where 1570 possible the same name should be registered for SDP as for MIME. For 1571 media other than existing MIME top-level content types, a 1572 standards-track RFC MUST be produced for a new top-level content type 1573 to be registered, and the registration MUST provide good 1574 justification why no existing media name is appropriate (the 1575 "Standards Action" policy of RFC 2434 [8]. 1577 This memo registers the media types "audio", "video", "text", 1578 "application" and "message". 1580 Note: The media types "control" and "data" were listed as valid in 1581 the previous version of this specification [6], however their 1582 semantics were never fully specified and they are not widely used. 1583 These media types have been removed in this specification, although 1584 they still remain valid media type capabilities for a SIP user agent 1585 as defined in RFC 3840 [23]. If these media types are considered 1586 useful in future, a Standards Track RFC MUST be produced to document 1587 their use. Until that is done, applications SHOULD NOT use these 1588 types and SHOULD NOT declare support for them in SIP capabilities 1589 declarations (even though they exist in the registry created by RFC 1590 3840). 1592 8.2.2 Transport protocols ("proto") 1594 The "proto" field describes the transport protocol used. This SHOULD 1595 reference a standards-track protocol RFC. This memo registers three 1596 values: "RTP/AVP" is a reference to RTP [18] used under the RTP 1597 Profile for Audio and Video Conferences with Minimal Control [19] 1598 running over UDP/IP, "RTP/SAVP" is a reference to the Secure 1599 Real-time Transport Protocol [22], and "udp" indicates an unspecified 1600 protocol over UDP. 1602 If other RTP profiles are defined in the future, their "proto" name 1603 SHOULD be specified in the same manner. For example, an RTP profile 1604 whose short name is "XYZ" would be denoted by a "proto" field of 1605 "RTP/XYZ". 1607 New transport protocols SHOULD be registered with IANA. 1608 Registrations MUST reference an RFC describing the protocol. Such an 1609 RFC MAY be Experimental or Informational, although it is preferable 1610 if it is Standards-Track. Registrations MUST also define the rules 1611 by which their "fmt" namespace is managed (see below). 1613 8.2.3 Media formats ("fmt") 1615 Each transport protocol, defined by the "proto" field, has an 1616 associated "fmt" namespace that describes the media formats which may 1617 conveyed by that protocol. Formats cover all the possible encodings 1618 that might want to be transported in a multimedia session. 1620 RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST 1621 use the payload type number as their "fmt" value. If the payload 1622 type number is dynamically assigned by this session description, an 1623 additional "rtpmap" attribute MUST be included to specify the format 1624 name and parameters as defined by the MIME type registration for the 1625 payload format. It is RECOMMENDED that other RTP profiles which are 1626 registered (in combination with RTP) as SDP transport protocols 1627 specify the same rules for the "fmt" namespace. 1629 For the "udp" protocol, new formats SHOULD be registered. Use of an 1630 existing MIME subtype for the format is encouraged. If no MIME 1631 subtype exists, it is RECOMMENDED that a suitable one is registered 1632 through the IETF process (RFC 2048) by production of, or reference 1633 to, a standards-track RFC that defines the transport protocol for the 1634 format. 1636 For other protocols, formats MAY be registered according to the rules 1637 of the associated "proto" specification. 1639 Registrations of new formats MUST specify which transport protocols 1640 they apply to. 1642 8.2.4 Attribute names ("att-field") 1644 Attribute field names ("att-field") MUST be registered with IANA and 1645 documented, because of noticeable issues due to conflicting 1646 attributes under the same name. Unknown attributes in SDP are simply 1647 ignored, but conflicting ones that fragment the protocol are a 1648 serious problem. 1650 New attribute registrations are accepted according to the 1651 "Specification Required" policy of RFC 2434, provided that the 1652 specification includes the following information: 1654 o contact name, email address and telephone number 1656 o attribute-name (as it will appear in SDP) 1658 o long-form attribute name in English 1660 o type of attribute (session level, media level, or both) 1661 o whether the attribute value is subject to the charset attribute. 1663 o a one paragraph explanation of the purpose of the attribute. 1665 o a specification of appropriate attribute values for this 1666 attribute. 1668 The above is the minimum that IANA will accept. Attributes that are 1669 expected to see widespread use and interoperability, SHOULD be 1670 documented with a standards-track RFC that specifies the attribute 1671 more precisely. 1673 Submitters of registrations should ensure that the specification is 1674 in the spirit of SDP attributes, most notably that the attribute is 1675 platform independent in the sense that it makes no implicit 1676 assumptions about operating systems and does not name specific pieces 1677 of software in a manner that might inhibit interoperability. 1679 IANA is requested to register the following initial set of attribute 1680 names ("att-field" values), with definitions as in Section 6 of this 1681 memo (these definitions update those in RFC 2327): 1683 Name | Session or Media level? | Dependent on charset? 1684 ----------+-------------------------+---------------------- 1685 cat | Session | No 1686 keywds | Session | Yes 1687 tool | Session | No 1688 ptime | Media | No 1689 maxptime | Media | No 1690 rtpmap | Media | No 1691 recvonly | Either | No 1692 sendrecv | Either | No 1693 sendonly | Either | No 1694 inactive | Either | No 1695 orient | Media | No 1696 type | Session | No 1697 charset | Session | No 1698 sdplang | Either | No 1699 lang | Either | No 1700 framerate | Media | No 1701 quality | Media | No 1702 fmtp | Media | No 1704 8.2.5 Bandwidth specifiers ("bwtype") 1706 A proliferation of bandwidth specifiers is strongly discouraged. 1708 New bandwidth specifiers ("bwtype" fields) MUST be registered with 1709 IANA. The submission MUST reference a standards-track RFC specifying 1710 the semantics of the bandwidth specifier precisely, and indicating 1711 when it should be used, and why the existing registered bandwidth 1712 specifiers do not suffice. 1714 IANA is requested to register the bandwith specifiers "CT" and "AS" 1715 with definitions as in Section 5.8 of this memo (these definitions 1716 update those in RFC 2327). 1718 8.2.6 Network types ("nettype") 1720 New network types (the "nettype" field) may be registered with IANA 1721 if SDP needs to be used in the context of non-Internet environments. 1722 Whilst these are not normally the preserve of IANA, there may be 1723 circumstances when an Internet application needs to interoperate with 1724 a non- Internet application, such as when gatewaying an Internet 1725 telephony call into the PSTN. The number of network types should be 1726 small and should be rarely extended. A new network type cannot be 1727 registered without registering at least one address type to be used 1728 with that network type. A new network type registration MUST 1729 reference an RFC which gives details of the network type and address 1730 type and specifies how and when they would be used. 1732 IANA is requested to register the network type "IN" to represent the 1733 Internet, with definition as in Sections 5.2 and 5.7 of this memo 1734 (these definitions update those in RFC 2327). 1736 8.2.7 Address types ("addrtype") 1738 New address types ("addrtype") may be registered with IANA. An 1739 address type is only meaningful in the context of a network type, and 1740 any registration of an address type MUST specify a registered network 1741 type, or be submitted along with a network type registration. A new 1742 address type registration MUST reference an RFC giving details of the 1743 syntax of the address type. Address types are not expected to be 1744 registered frequently. 1746 IANA is requested to register the address types "IP4" and "IP6" with 1747 definitions as in Sections 5.2 and 5.7 of this memo (these 1748 definitions update those in RFC 2327). 1750 8.2.8 Registration Procedure 1752 In the RFC documentation that registers SDP "media", "proto", "fmt", 1753 "bwtype", "nettype" and "addrtype" fields, the authors MUST include 1754 the following information for IANA to place in the appropriate 1755 registry: 1757 o contact name, email address and telephone number 1759 o name being registered (as it will appear in SDP) 1761 o long-form name in English 1763 o type of name ("media", "proto", "fmt", "bwtype", "nettype", or 1764 "addrtype") 1766 o a one paragraph explanation of the purpose of the registered name. 1768 o a reference to the specification for the registered name (this 1769 will typically be an RFC number). 1771 IANA may refer any registration to the IESG Transport Area Directors 1772 for review, and may request revisions to be made before a 1773 registration will be made. 1775 8.3 Encryption Key Access Methods 1777 The IANA currently maintains a table of SDP encryption key access 1778 method ("enckey") names. This table is obsolete and SHOULD be 1779 removed, since the "k=" line is not extensible. New registrations 1780 MUST NOT be accepted. 1782 9. SDP Grammar 1784 This section provides an Augmented BNF grammar for SDP. ABNF is 1785 defined in [4]. 1787 ; SDP Syntax 1788 session-description = proto-version 1789 origin-field 1790 session-name-field 1791 information-field 1792 uri-field 1793 email-fields 1794 phone-fields 1795 connection-field 1796 bandwidth-fields 1797 time-fields 1798 key-field 1799 attribute-fields 1800 media-descriptions 1802 proto-version = "v=" 1*DIGIT CRLF 1803 ;this memo describes version 0 1805 origin-field = "o=" username SP sess-id SP sess-version SP 1806 nettype SP addrtype SP unicast-address CRLF 1808 session-name-field = "s=" text CRLF 1810 information-field = ["i=" text CRLF] 1812 uri-field = ["u=" uri CRLF] 1814 email-fields = *("e=" email-address CRLF) 1816 phone-fields = *("p=" phone-number CRLF) 1818 connection-field = ["c=" nettype SP addrtype SP 1819 connection-address CRLF] 1820 ;a connection field must be present 1821 ;in every media description or at the 1822 ;session-level 1824 bandwidth-fields = *("b=" bwtype ":" bandwidth CRLF) 1826 time-fields = 1*( "t=" start-time SP stop-time 1827 *(CRLF repeat-fields) CRLF) 1828 [zone-adjustments CRLF] 1830 repeat-fields = "r=" repeat-interval SP typed-time 1831 1*(SP typed-time) 1833 zone-adjustments = "z=" time SP ["-"] typed-time 1834 *(SP time SP ["-"] typed-time) 1836 key-field = ["k=" key-type CRLF] 1838 attribute-fields = *("a=" attribute CRLF) 1840 media-descriptions = *( media-field 1841 information-field 1842 *connection-field 1843 bandwidth-fields 1844 key-field 1845 attribute-fields ) 1847 media-field = "m=" media SP port ["/" integer] 1848 SP proto 1*(SP fmt) CRLF 1850 ; sub-rules of 'o=' 1851 username = non-ws-string 1852 ;pretty wide definition, but doesn't 1853 ;include space 1855 sess-id = 1*DIGIT 1856 ;should be unique for this username/host 1858 sess-version = 1*DIGIT 1860 nettype = token 1861 ;typically "IN" 1863 addrtype = token 1864 ;typically "IP4" or "IP6" 1866 ; sub-rules of 'u=' 1867 uri = URI-reference 1868 ; see RFC2396 and RFC2732 1870 ; sub-rules of 'e=' 1871 email-address = email *SP "(" 1*email-safe ")" / 1872 1*email-safe "<" email ">" / 1873 email 1875 email = addr-spec ; defined in RFC2822 1876 ; modified to remove CFWS 1878 ; sub-rules of 'p=' 1879 phone-number = phone *SP "(" 1*email-safe ")" / 1880 1*email-safe "<" phone ">" / 1881 phone 1883 phone = ["+"] DIGIT 1*(SP / "-" / DIGIT) 1885 ; sub-rules of 'c=' 1886 connection-address = multicast-address / unicast-address 1888 ; sub-rules of 'b=' 1889 bwtype = token 1891 bandwidth = 1*DIGIT 1893 ; sub-rules of 't=' 1894 start-time = time / "0" 1896 stop-time = time / "0" 1898 time = POS-DIGIT 9*DIGIT 1899 ; Decimal representation of NTP time in 1900 ; seconds since 1900. The representation 1901 ; of NTP time is an unbounded length field 1902 ; containing at least 10 digits. Unlike the 1903 ; 64-bit representation used elsewhere, time 1904 ; in SDP does not wrap in the year 2036. 1906 ; sub-rules of 'r=' and 'z=' 1907 repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] 1909 typed-time = 1*DIGIT [fixed-len-time-unit] 1911 fixed-len-time-unit = "d" / "h" / "m" / "s" 1913 ; sub-rules of 'k=' 1914 key-type = "prompt" / 1915 "clear:" text / 1916 "base64:" base64 / 1917 "uri:" uri 1919 base64 = *base64-unit [base64-pad] 1920 base64-unit = 4base64-char 1921 base64-pad = 2base64-char "==" / 3base64-char "=" 1922 base64-char = ALPHA / DIGIT / "+" / "/" 1924 ; sub-rules of 'a=' 1925 attribute = (att-field ":" att-value) / att-field 1927 att-field = token 1929 att-value = byte-string 1931 ; sub-rules of 'm=' 1932 media = token 1933 ;typically "audio", "video", "text" or 1934 ;"application" 1936 fmt = token 1937 ;typically an RTP payload type for audio 1938 ;and video media 1940 proto = token *("/" token) 1941 ;typically "RTP/AVP" or "udp" 1943 port = 1*DIGIT 1945 ; generic sub-rules: addressing 1946 unicast-address = IP4-address / IP6-address / FQDN / extn-addr 1948 multicast-address = IP4-multicast / IP6-multicast / FQDN 1949 / extn-addr 1951 IP4-multicast = m1 3( "." decimal-uchar ) 1952 "/" ttl [ "/" integer ] 1953 ; IPv4 multicast addresses may be in the 1954 ; range 224.0.0.0 to 239.255.255.255 1956 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / 1957 ("23" DIGIT ) 1959 IP6-multicast = hexpart [ "/" integer ] 1960 ; IPv6 address starting with FF 1962 ttl = (POS-DIGIT *2DIGIT) / "0" 1964 FQDN = 4*(alpha-numeric / "-" / ".") 1965 ; fully qualified domain name as specified 1966 ; in RFC1035 (and updates) 1968 IP4-address = b1 3("." decimal-uchar) 1970 b1 = decimal-uchar 1971 ; less than "224" 1973 ; The following is from RFC2373 Appendix B. It is a direct copy. 1974 IP6-address = hexpart [ ":" IP4-address ] 1976 hexpart = hexseq / hexseq "::" [ hexseq ] / 1977 "::" [ hexseq ] 1979 hexseq = hex4 *( ":" hex4) 1981 hex4 = 1*4HEXDIG 1983 ; Generic for other address families 1984 extn-addr = non-ws-string 1986 ; generic sub-rules: datatypes 1987 text = byte-string 1988 ;default is to interpret this as UTF8 text. 1989 ;ISO 8859-1 requires "a=charset:ISO-8859-1" 1990 ;session-level attribute to be used 1992 byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) 1993 ;any byte except NUL, CR or LF 1995 non-ws-string = 1*(VCHAR/%x80-FF) 1996 ;string of visible characters 1998 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 1999 / %x41-5A / %x5E-7E 2001 token = 1*(token-char) 2003 email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF 2004 ;any byte except NUL, CR, LF, or the quoting 2005 ;characters ()<> 2007 integer = POS-DIGIT *DIGIT 2009 ; generic sub-rules: primitives 2010 alpha-numeric = ALPHA / DIGIT 2012 POS-DIGIT = %x31-39 ; 1 - 9 2014 decimal-uchar = DIGIT 2015 / POS-DIGIT DIGIT 2016 / ("1" 2*(DIGIT)) 2017 / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) 2018 / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) 2020 ; external references: 2021 ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 2234 2022 ; URI-reference: from RFC2396 and RFC2732 2023 ; addr-spec: from RFC 2822 2025 10. Summary of Changes from RFC 2327 2027 The memo has been significantly restructured, incorporating a large 2028 number of clarifications to the specification in light of use. With 2029 the exception of those items noted below, the changes to the memo are 2030 intended to be backwards compatible clarifications. However, due to 2031 inconsistencies and unclear definitions in RFC 2327 it is likely that 2032 some implementations interpreted that memo in ways that differ from 2033 this version of SDP. 2035 The ABNF grammar in Section 9 has been extensively revised and 2036 updated, correcting a number of mistakes and incorporating the RFC 2037 3266 IPv6 extensions. Known inconsistencies between the grammar and 2038 the specification text have been resolved. 2040 A media type registration for SDP is included. Requirements for the 2041 registration of attributes and other parameters with IANA have been 2042 clarified and tightened (Section 8). It is noted that "text" and 2043 "message" are valid media types for use with SDP, but that "control" 2044 and "data" are under-specified and deprecated. 2046 RFC 2119 terms are now used throughout to specify requirements 2047 levels. Certain of those requirements, in particular in relation to 2048 parameter registration, are stricter than those in RFC 2327. 2050 The "RTP/SAVP" RTP profile and its "fmt" namespace are registered. 2052 The attributes "a=inactive" and "a=maxptime" have been added. 2054 RFC 2327 mandated that either "e=" or "p=" was required. Both are 2055 now optional, to reflect actual usage. 2057 The significant limitations of the "k=" field are noted, and its use 2058 is deprecated. 2060 Most uses of the "x-" prefix notation for experimental parameters are 2061 disallowed and the other uses are deprecated. 2063 11. Acknowledgements 2065 Many people in the IETF Multiparty Multimedia Session Control 2066 (MMUSIC) working group have made comments and suggestions 2067 contributing to this document. In particular, we would like to thank 2068 Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross 2069 Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna, 2070 Jonathan Lennox, Keith Drage, Sean Olson, Bernie Hoeneisen and 2071 Jonathan Rosenberg. 2073 12. References 2075 12.1 Normative References 2077 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 2078 13, RFC 1034, November 1987. 2080 [2] Mockapetris, P., "Domain names - implementation and 2081 specification", STD 13, RFC 1035, November 1987. 2083 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2084 Levels", BCP 14, RFC 2119, March 1997. 2086 [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2087 Specifications: ABNF", RFC 2234, November 1997. 2089 [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2090 2279, January 1998. 2092 [6] Handley, M. and V. Jacobson, "SDP: Session Description 2093 Protocol", RFC 2327, April 1998. 2095 [7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 2096 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 2097 1998. 2099 [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2100 Considerations Section in RFCs", BCP 26, RFC 2434, October 2101 1998. 2103 [9] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal 2104 IPv6 Addresses in URL's", RFC 2732, December 1999. 2106 [10] Alvestrand, H., "Tags for the Identification of Languages", BCP 2107 47, RFC 3066, January 2001. 2109 [11] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing 2110 Domain Names in Applications (IDNA)", RFC 3490, March 2003. 2112 [12] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 2113 RFC 3548, July 2003. 2115 12.2 Informative References 2117 [13] Mills, D., "Network Time Protocol (Version 3) Specification, 2118 Implementation", RFC 1305, March 1992. 2120 [14] Handley, M., Perkins, C. and E. Whelan, "Session Announcement 2121 Protocol", RFC 2974, October 2000. 2123 [15] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2124 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 2125 Session Initiation Protocol", RFC 3261, June 2002. 2127 [16] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 2128 Protocol (RTSP)", RFC 2326, April 1998. 2130 [17] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2131 Session Description Protocol (SDP)", RFC 3264, June 2002. 2133 [18] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 2134 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 2135 RFC 3550, July 2003. 2137 [19] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 2138 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 2140 [20] Casner, S., "Session Description Protocol (SDP) Bandwidth 2141 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, 2142 July 2003. 2144 [21] Huitema, C., "Real Time Control Protocol (RTCP) attribute in 2145 Session Description Protocol (SDP)", RFC 3605, October 2003. 2147 [22] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K. 2148 Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 2149 3711, March 2004. 2151 [23] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Indicating User 2152 Agent Capabilities in the Session Initiation Protocol (SIP)", 2153 RFC 3840, August 2004. 2155 [24] Westerlund, M., "A Transport Independent Bandwidth Modifier for 2156 the Session Description Protocol (SDP)", RFC 3890, September 2157 2004. 2159 [25] International Telecommunications Union, "H.323 extended for 2160 loosely coupled conferences", ITU Recommendation H.332, 2161 September 1998. 2163 [26] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K. 2164 Norrman, "Key Management Extensions for Session Description 2165 Protocol (SDP) and Real Time Streaming Protocol (RTSP)", 2166 draft-ietf-mmusic-kmgmt-ext-12 (work in progress), November 2167 2004. 2169 [27] Andreasen, F., Baugher, M. and D. Wing, "Session Description 2170 Protocol Security Descriptions for Media Streams", 2171 draft-ietf-mmusic-sdescriptions-07 (work in progress), July 2172 2004. 2174 Authors' Addresses 2176 Mark Handley 2177 University College London 2178 Department of Computer Science 2179 Gower Street 2180 London WC1E 6BT 2181 UK 2183 EMail: M.Handley@cs.ucl.ac.uk 2184 Van Jacobson 2185 Packet Design 2186 2465 Latham Street 2187 Mountain View, CA 94040 2188 USA 2190 EMail: van@packetdesign.com 2192 Colin Perkins 2193 University of Glasgow 2194 Department of Computing Science 2195 17 Lilybank Gardens 2196 Glasgow G12 8QQ 2197 UK 2199 EMail: csp@csperkins.org 2201 Intellectual Property Statement 2203 The IETF takes no position regarding the validity or scope of any 2204 Intellectual Property Rights or other rights that might be claimed to 2205 pertain to the implementation or use of the technology described in 2206 this document or the extent to which any license under such rights 2207 might or might not be available; nor does it represent that it has 2208 made any independent effort to identify any such rights. Information 2209 on the procedures with respect to rights in RFC documents can be 2210 found in BCP 78 and BCP 79. 2212 Copies of IPR disclosures made to the IETF Secretariat and any 2213 assurances of licenses to be made available, or the result of an 2214 attempt made to obtain a general license or permission for the use of 2215 such proprietary rights by implementers or users of this 2216 specification can be obtained from the IETF on-line IPR repository at 2217 http://www.ietf.org/ipr. 2219 The IETF invites any interested party to bring to its attention any 2220 copyrights, patents or patent applications, or other proprietary 2221 rights that may cover technology that may be required to implement 2222 this standard. Please address the information to the IETF at 2223 ietf-ipr@ietf.org. 2225 Disclaimer of Validity 2227 This document and the information contained herein are provided on an 2228 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2229 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2230 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2231 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2232 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2233 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2235 Copyright Statement 2237 Copyright (C) The Internet Society (2005). This document is subject 2238 to the rights, licenses and restrictions contained in BCP 78, and 2239 except as set forth therein, the authors retain all their rights. 2241 Acknowledgment 2243 Funding for the RFC Editor function is currently provided by the 2244 Internet Society.