idnits 2.17.1 draft-ietf-mmusic-sdp-new-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 45 form feeds but 47 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 12 instances of too long lines in the document, the longest one being 8 characters in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 12 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 524 has weird spacing: '...7 or p=+...' == Line 560 has weird spacing: '... used for s...' == Line 782 has weird spacing: '...it must be po...' == Line 1970 has weird spacing: '...for the purpo...' == 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 (2 March 2003) is 7719 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 1889 (Obsoleted by RFC 3550) -- Obsolete informational reference (is this intentional?): RFC 1890 (Obsoleted by RFC 3551) -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force MMUSIC WG 2 INTERNET-DRAFT Mark Handley/ACIRI 3 draft-ietf-mmusic-sdp-new-12.txt Van Jacobson/Packet Design 4 Colin Perkins/ISI 5 2 March 2003 6 Expires: September 2003 8 SDP: Session Description Protocol 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This document is a product of the Multiparty Multimedia Session 32 Control (MMUSIC) working group of the Internet Engineering Task 33 Force. Comments are solicited and should be addressed to the working 34 group's mailing list at mmusic@ietf.org and/or the authors. 36 Copyright Notice 38 Copyright (C) The Internet Society (2003). All Rights Reserved. 40 Abstract 42 This memo defines the Session Description Protocol (SDP). SDP is 43 intended for describing multimedia sessions for the purposes of 44 session announcement, session invitation, and other forms of 45 multimedia session initiation. 47 1. Introduction 49 When initiating multimedia teleconferences, voice-over-IP calls, 50 streaming video, or other real-time sessions, there is a requirement 51 to convey media details, transport addresses, and other session 52 description metadata to the participants. 54 SDP provides a standard representation for such information, 55 irrespective of how that information is transported. SDP is purely a 56 format for session description - it does not incorporate a transport 57 protocol, and is intended to use different transport protocols as 58 appropriate, including the Session Announcement Protocol [RFC2974], 59 Session Initiation Protocol [RFC3261], Real-Time Streaming Protocol 60 [RFC2326], electronic mail using the MIME extensions, and the 61 Hypertext Transport Protocol. 63 SDP is intended to be general purpose so that it can be used in a 64 wide range of network environments and applications. However, it is 65 not intended to support negotiation of session content or media 66 encodings: this is viewed as outside the scope of session 67 description. 69 2. Glossary of Terms 71 The following terms are used in this document, and have specific 72 meaning within the context of this document. 74 Conference 75 A multimedia conference is a set of two or more communicating 76 users along with the software they are using to communicate. 78 Session 79 A multimedia session is a set of multimedia senders and receivers 80 and the data streams flowing from senders to receivers. A 81 multimedia conference is an example of a multimedia session. 83 Session Advertisement 84 See session announcement. 86 Session Announcement 87 A session announcement is a mechanism by which a session 88 description is conveyed to users in a pro-active fashion, i.e., 89 the session description was not explicitly requested by the user. 91 Session Description 92 A well defined format for conveying sufficient information to 93 discover and participate in a multimedia session. 95 2.1. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 3. Examples of SDP Usage 103 3.1. Multicast Announcement 105 In order to assist the advertisement of multicast multimedia 106 conferences and other multicast sessions, and to communicate the 107 relevant session setup information to prospective participants, a 108 distributed session directory may be used. An instance of such a 109 session directory periodically sends packets containing a description 110 of the session to a well known multicast group. These advertisements 111 are received by other session directories such that potential remote 112 participants can use the session description to start the tools 113 required to participate in the session. 115 One protocol commonly used to implement such a distributed directory 116 is the Session Announcement Protocol, SAP [RFC2974]. SDP provides the 117 recommended session description format for such announcements. 119 3.2. Session Initiation 121 The Session Initiation Protocol, SIP [RFC3261] is an application- 122 layer control protocol for creating, modifying and terminating 123 sessions such as Internet multimedia conferences, Internet telephone 124 calls and multimedia distribution. The SIP messages used to create 125 sessions carry session descriptions which allow participants to agree 126 on a set of compatible media types. These session descriptions are 127 commonly formatted using SDP. When used with SIP, the offer/answer 128 model [RFC3264] provides a framework for negotiation using SDP. 130 3.3. Streaming media 132 The Real Time Streaming Protocol, RTSP [RFC2326], is an application- 133 level protocol for control over the delivery of data with real-time 134 properties. RTSP provides an extensible framework to enable 135 controlled, on-demand delivery of real-time data, such as audio and 136 video. An RTSP client and server negotiate an appropriate set of 137 parameters for media delivery, partially using SDP syntax to describe 138 those parameters. 140 3.4. Email and the World Wide Web 142 Alternative means of conveying session descriptions include 143 electronic mail and the World Wide Web. For both email and WWW 144 distribution, the use of the MIME content type "application/sdp" MUST 145 be used. This enables the automatic launching of applications for 146 participation in the session from the WWW client or mail reader in a 147 standard manner. 149 Note that announcements of multicast sessions made only via email or 150 the World Wide Web (WWW) do not have the property that the receiver 151 of a session announcement can necessarily receive the session because 152 the multicast sessions may be restricted in scope, and access to the 153 WWW server or reception of email is possible outside this scope. SAP 154 announcements do not suffer from this mismatch. 156 4. Requirements and Recommendations 158 The purpose of SDP is to convey information about media streams in 159 multimedia sessions to allow the recipients of a session description 160 to participate in the session. SDP is primarily intended for use in 161 an internetwork, although it is sufficiently general that it can 162 describe conferences in other network environments. 164 A multimedia session, for these purposes, is defined as a set of 165 media streams that exist for some duration of time. Media streams 166 can be many-to-many. The times during which the session is active 167 need not be continuous. 169 Thus far, multicast based sessions on the Internet have differed from 170 many other forms of conferencing in that anyone receiving the traffic 171 can join the session (unless the session traffic is encrypted). In 172 such an environment, SDP serves two primary purposes. It is a means 173 to communicate the existence of a session, and is a means to convey 174 sufficient information to enable joining and participating in the 175 session. In a unicast environment, only the latter purpose is likely 176 to be relevant. 178 Thus SDP includes: 180 o Session name and purpose 182 o Time(s) the session is active 184 o The media comprising the session 185 o Information to receive those media (addresses, ports, formats 186 and so on) 188 As resources necessary to participate in a session may be limited, 189 some additional information may also be desirable: 191 o Information about the bandwidth to be used by the conference 193 o Contact information for the person responsible for the session 195 In general, SDP must convey sufficient information to enable 196 applications to join a session (with the possible exception of 197 encryption keys) and to announce the resources to be used to non- 198 participants that may need to know. 200 4.1. Media Information 202 SDP includes: 204 o The type of media (video, audio, etc) 206 o The transport protocol (RTP/UDP/IP, H.320, etc) 208 o The format of the media (H.261 video, MPEG video, etc) 210 For an IP multicast session, the following are also conveyed: 212 o Multicast address for media 214 o Transport port for media 216 This address and port are the destination address and destination 217 port of the multicast stream, whether being sent, received, or both. 219 For an IP unicast session, the following are conveyed: 221 o Remote address for media 223 o Transport port for media 225 The semantics of this address and port depend on the media and 226 transport protocol defined. By default, this is the remote address 227 and remote port to which data is sent, however some media types may 228 redefine this behaviour. 230 4.2. Timing Information 232 Sessions may either be bounded or unbounded in time. Whether or not 233 they are bounded, they may be only active at specific times. 235 SDP can convey: 237 o An arbitrary list of start and stop times bounding the session 239 o For each bound, repeat times such as "every Wednesday at 10am 240 for one hour" 242 This timing information is globally consistent, irrespective of local 243 time zone or daylight saving time. 245 4.3. Private Sessions 247 It is possible to create both public sessions and private sessions. 248 SDP itself does not distinguish between these: private sessions are 249 typically conveyed by encrypting the session description during 250 distribution. The details of how encryption is performed are 251 dependent on the mechanism used to convey SDP - e.g. mechanisms are 252 defined for SDP transported using SAP [RFC2974] and SIP [RFC3261]. 254 If a session announcement is private it is possible to use that 255 private announcement to convey encryption keys necessary to decode 256 each of the media in a conference, including enough information to 257 know which encryption scheme is used for each media. 259 4.4. Obtaining Further Information about a Session 261 A session description should convey enough information to decide 262 whether or not to participate in a session. SDP may include 263 additional pointers in the form of Universal Resources Identifiers 264 (URIs) for more information about the session. 266 4.5. Categorisation 268 When many session descriptions are being distributed by SAP, or any 269 other advertisement mechanism, it may be desirable to filter 270 announcements that are of interest from those that are not. SDP 271 supports a categorisation mechanism for sessions that is capable of 272 being automated. 274 4.6. Internationalization 276 The SDP specification recommends the use of the ISO 10646 character 277 sets in the UTF-8 encoding (RFC 2279) to allow many different 278 languages to be represented. However, to assist in compact 279 representations, SDP also allows other character sets such as ISO 280 8859-1 to be used when desired. Internationalization only applies to 281 free-text fields (session name and background information), and not 282 to SDP as a whole. 284 5. SDP Specification 286 SDP session descriptions are entirely textual using the ISO 10646 287 character set in UTF-8 encoding. SDP field names and attribute names 288 use only the US-ASCII subset of UTF-8, but textual fields and 289 attribute values MAY use the full ISO 10646 character set. The 290 textual form, as opposed to a binary encoding such as ASN.1 or XDR, 291 was chosen to enhance portability, to enable a variety of transports 292 to be used (e.g, session description in a MIME email message) and to 293 allow flexible, text-based toolkits (e.g., Tcl/Tk) to be used to 294 generate and to process session descriptions. However, since SDP may 295 be used in environments where the maximum permissable size of a 296 session description is limited (e.g. SAP announcements; SIP 297 transported in UDP), the encoding is deliberately compact. Also, 298 since announcements may be transported via very unreliable means or 299 damaged by an intermediate caching server, the encoding was designed 300 with strict order and formatting rules so that most errors would 301 result in malformed announcements which could be detected easily and 302 discarded. This also allows rapid discarding of encrypted 303 announcements for which a receiver does not have the correct key. 305 An SDP session description consists of a number of lines of text of 306 the form: 308 = 310 where MUST be exactly one case-significant character and 311 is structured text whose format depends on . In 312 general is either a number of fields delimited by a single 313 space character, or a free format string. Whitespace MUST NOT be used 314 either side of the "=" sign. 316 A session description consists of a session-level section followed by 317 zero or more media-level sections. The session-level part starts 318 with a "v=" line and continues to the first media-level section. The 319 media description starts with an "m=" line and continues to the next 320 media description or end of the whole session description. In 321 general, session-level values are the default for all media unless 322 overridden by an equivalent media-level value. 324 Some lines in each description are REQUIRED and some are OPTIONAL but 325 all MUST appear in exactly the order given here (the fixed order 326 greatly enhances error detection and allows for a simple parser). 327 OPTIONAL items are marked with a "*". 329 Session description 330 v= (protocol version) 331 o= (owner/creator and session identifier). 332 s= (session name) 333 i=* (session information) 334 u=* (URI of description) 335 e=* (email address) 336 p=* (phone number) 337 c=* (connection information - not required if included in all media) 338 b=* (bandwidth information) 339 One or more time descriptions (see below) 340 z=* (time zone adjustments) 341 k=* (encryption key) 342 a=* (zero or more session attribute lines) 343 Zero or more media descriptions (see below) 345 Time description 346 t= (time the session is active) 347 r=* (zero or more repeat times) 349 Media description 350 m= (media name and transport address) 351 i=* (media title) 352 c=* (connection information - optional if included at session-level) 353 b=* (bandwidth information) 354 k=* (encryption key) 355 a=* (zero or more media attribute lines) 357 The set of type letters is deliberately small and not intended to be 358 extensible -- an SDP parser MUST completely ignore any announcement 359 that contains a type letter that it does not understand. The 360 attribute mechanism ("a=" described below) is the primary means for 361 extending SDP and tailoring it to particular applications or media. 362 Some attributes (the ones listed in this document) have a defined 363 meaning but others may be added on an application-, media- or 364 session-specific basis. An SDP parser MUST ignore any attribute it 365 doesn't understand. 367 The connection ("c=") and attribute ("a=") information in the 368 session-level section applies to all the media of that session unless 369 overridden by connection information or an attribute of the same name 370 in the media description. For instance, in the example below, each 371 media behaves as if it were given a "recvonly" attribute. 373 An example SDP description is: 375 v=0 376 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 377 s=SDP Seminar 378 i=A Seminar on the session description protocol 379 u=http://www.example.com/seminars/sdp.pdf 380 e=j.doe@example.com (Jane Doe) 381 c=IN IP4 224.2.17.12/127 382 t=2873397496 2873404696 383 a=recvonly 384 m=audio 49170 RTP/AVP 0 385 m=video 51372 RTP/AVP 31 386 m=application 32416 udp wb 387 a=orient:portrait 389 Text records such as the session name and information are octet 390 strings which may contain any octet with the exceptions of 0x00 391 (Nul), 0x0a (ASCII newline) and 0x0d (ASCII carriage return). The 392 sequence CRLF (0x0d0a) is used to end a record, although parsers 393 SHOULD be tolerant and also accept records terminated with a single 394 newline character. By default these byte strings contain ISO-10646 395 characters in UTF-8 encoding, but this default MAY be changed using 396 the "charset" attribute. 398 Protocol Version 400 v=0 402 The "v=" field gives the version of the Session Description 403 Protocol. There is no minor version number. 405 Origin 407 o=
408
410 The "o=" field gives the originator of the session (her username 411 and the address of the user's host) plus a session id and session 412 version number. 414 is the user's login on the originating host, or it 415 is "-" if the originating host does not support the concept of 416 user ids. MUST NOT contain spaces. 418 is a numeric string such that the tuple of 419 , , ,
and 420
form a globally unique identifier for the session. 421 The method of session id allocation is up to the creating tool, 422 but it has been suggested that a Network Time Protocol (NTP) 423 format timestamp be used to ensure uniqueness [RFC1305]. 425 is a version number for this announcement. It is 426 needed for proxy announcements to detect which of several 427 announcements for the same session is the most recent. Again 428 its usage is up to the creating tool, so long as is 429 increased when a modification is made to the session data. 430 Again, it is RECOMMENDED (but not mandatory) that an NTP format 431 timestamp is used. 433 is a text string giving the type of network. 434 Initially "IN" is defined to have the meaning "Internet". 436
is a text string giving the type of the address 437 that follows. Initially "IP4" and "IP6" are defined. 439
is the globally unique address of the machine from 440 which the session was created. For an address type of IP4, 441 this is either the fully-qualified domain name of the machine, 442 or the dotted-decimal representation of the IP version 4 443 address of the machine. For an address type of IP6, this is 444 either the fully-qualified domain name of the machine, or the 445 compressed textual representation of the IP version 6 address 446 of the machine. For both IP4 and IP6, the fully-qualified 447 domain name is the form that SHOULD be given unless this is 448 unavailable, in which case the globally unique address may be 449 substituted. A local IP address MUST NOT be used in any 450 context where the SDP description might leave the scope in 451 which the address is meaningful. 453 In general, the "o=" field serves as a globally unique identifier 454 for this version of this session description, and the subfields 455 excepting the version taken together identify the session 456 irrespective of any modifications. 458 Session Name 460 s= 462 The "s=" field is the session name. There MUST be one and only 463 one "s=" field per session description. The "s=" field MUST NOT be 464 empty and SHOULD contain ISO 10646 characters (but see also the 465 "a=charset" attribute below). If a session has no meaningful name, 466 the value "s= " SHOULD be used (i.e. a single space as the 467 session name). 469 Session and Media Information 471 i= 473 The "i=" field is information about the session. There may be at 474 most one session-level "i=" field per session description, and at 475 most one "i=" field per media. Although it may be omitted, this is 476 NOT RECOMMENDED for session announcements, and user interfaces for 477 composing sessions should require text to be entered. If it is 478 present it must contain ISO 10646 characters (but see also the 479 "a=charset" attribute below). 481 A single "i=" field can also be used for each media definition. 482 In media definitions, "i=" fields are primarily intended for 483 labeling media streams. As such, they are most likely to be 484 useful when a single session has more than one distinct media 485 stream of the same media type. An example would be two different 486 whiteboards, one for slides and one for feedback and questions. 488 URI 490 u= 492 A URI is a Universal Resource Identifier as used by WWW clients. 493 The URI should be a pointer to additional information about the 494 conference. This field is OPTIONAL, but if it is present it MUST 495 be specified before the first media field. No more than one URI 496 field is allowed per session description. 498 Email Address and Phone Number 500 e= 501 p= 503 These specify contact information for the person responsible for 504 the conference. This is not necessarily the same person that 505 created the conference announcement. 507 Inclusion of an email address or phone number is OPTIONAL. Note 508 that the previous version of SDP specified that either an email 509 field or a phone field MUST be specified, but this was widely 510 ignored. The change brings the specification into line with 511 common usage. 513 If the email addres or phone number are present, they MUST be 514 specified before the first media field. More than one email or 515 phone field can be given for a session description. 517 Phone numbers SHOULD be given in the conventional international 518 format: preceded by a "+" and the international country code. 519 There must be a space or a hyphen ("-") between the country code 520 and the rest of the phone number. Spaces and hyphens may be used 521 to split up a phone field to aid readability if desired. For 522 example: 524 p=+44-171-380-7777 or p=+1 617 555 6011 526 Both email addresses and phone numbers can have an optional free 527 text string associated with them, normally giving the name of the 528 person who may be contacted. This should be enclosed in 529 parenthesis if it is present. For example: 531 e=j.doe@example.com (Jane Doe) 533 The alternative RFC822 name quoting convention is also allowed for 534 both email addresses and phone numbers. For example, 536 e=Jane Doe 538 The free text string SHOULD be in the ISO-10646 character set with 539 UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings 540 if the appropriate charset session-level attribute is set. 542 Connection Data 544 c=
546 The "c=" field contains connection data. 548 A session announcement MUST contain either at least one "c=" field 549 in each media description (see below) or a single "c=" field at 550 the session-level. It MAY contain a single session-level "c=" 551 field and additional "c=" field(s) per media description, in which 552 case the per-media values override the session-level settings for 553 the respective media. 555 The first sub-field is the network type, which is a text string 556 giving the type of network. Initially "IN" is defined to have the 557 meaning "Internet". 559 The second sub-field is the address type. This allows SDP to be 560 used for sessions that are not IP based. Currently only IP4 and 561 IP6 are defined. 563 The third sub-field is the connection address. Optional extra 564 sub-fields MAY be added after the connection address depending on 565 the value of the
field. 567 For IP4 and IP6 addresses, the connection address is defined as 568 follows: 570 o If the session is multicast, the connection address will be 571 an IP multicast group address. If the conference is not 572 multicast, then the connection address contains the unicast 573 IP address of the expected data source or data relay or data 574 sink as determined by additional attribute fields. It is not 575 expected that unicast addresses will be given in a session 576 description that is communicated by a multicast announcement, 577 though this is not prohibited. 579 o Conferences using an IPv4 multicast connection address MUST 580 also have a time to live (TTL) value present in addition to 581 the multicast address. The TTL and the address together 582 define the scope with which multicast packets sent in this 583 conference will be sent. TTL values MUST be in the range 584 0-255. 586 The TTL for the session is appended to the address using a slash 587 as a separator. An example is: 589 c=IN IP4 224.2.36.42/127 591 IPv6 multicast does not use TTL scoping, and hence the TTL value 592 MUST NOT be present for IPv6 multicast. It is expected that IPv6 593 scoped addresses will be used to limit the scope of conferences. 595 Hierarchical or layered encoding schemes are data streams where 596 the encoding from a single media source is split into a number of 597 layers. The receiver can choose the desired quality (and hence 598 bandwidth) by only subscribing to a subset of these layers. Such 599 layered encodings are normally transmitted in multiple multicast 600 groups to allow multicast pruning. This technique keeps unwanted 601 traffic from sites only requiring certain levels of the hierarchy. 602 For applications requiring multiple multicast groups, we allow the 603 following notation to be used for the connection address: 605 [/]/ 607 If the number of addresses is not given it is assumed to be one. 608 Multicast addresses so assigned are contiguously allocated above 609 the base address, so that, for example: 611 c=IN IP4 224.2.1.1/127/3 613 would state that addresses 224.2.1.1, 224.2.1.2 and 224.2.1.3 are 614 to be used at a ttl of 127. This is semantically identical to 615 including multiple "c=" lines in a media description: 617 c=IN IP4 224.2.1.1/127 618 c=IN IP4 224.2.1.2/127 619 c=IN IP4 224.2.1.3/127 621 Similarly, an IPv6 example would be: 623 c=IN IP6 FF15::101/3 625 which is semantically equivalent to: 627 c=IN IP6 FF15::101 628 c=IN IP6 FF15::102 629 c=IN IP6 FF15::103 631 (remembering that the TTL field is not present in IPv6 multicast). 633 Multiple addresses or "c=" lines MAY be specified on a per-media 634 basis. They MUST NOT be specified for a session-level "c=" field. 636 The slash notation described above MUST NOT be used for IP unicast 637 addresses. 639 Bandwidth 641 b=: 643 This specifies the proposed bandwidth to be used by the session or 644 media, and is OPTIONAL. 646 The is in kilobits per second by default. 647 Modifiers MAY specify that alternative units are to be used (the 648 modifiers defined in this memo use the default units). 650 The is a single alphanumeric word giving the meaning of 651 the bandwidth figure. 653 Two modifiers are initially defined: 655 CT Conference Total 656 If the bandwidth of a session or media in a session is 657 different from the bandwidth implicit from the scope, a 658 "b=CT:..." line should be supplied for the session giving 659 the proposed upper limit to the bandwidth used. The primary 660 purpose of this is to give an approximate idea as to whether 661 two or more sessions can co-exist simultaneously. 663 AS Application-Specific Maximum 664 The bandwidth is interpreted to be application-specific (it 665 will be the application's concept of maximum bandwidth). 666 Normally this will coincide with what is set on the 667 application's "maximum bandwidth" control if applicable. 668 For RTP based applications, AS gives the RTP "session 669 bandwidth" as defined in section 6.2 of [RFC1889]. 671 Note that CT gives a total bandwidth figure for all the media at 672 all sites. AS gives a bandwidth figure for a single media at a 673 single site, although there may be many sites sending 674 simultaneously. 676 Tool writers MAY define experimental bandwidth modifiers by 677 prefixing their modifier with "X-". For example: 679 b=X-YZ:128 681 Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers 682 SHOULD be registered with IANA in the standard namespace. SDP 683 parsers MUST ignore bandwidth fields with unknown modifiers. 684 Modifiers MUST be alpha-numeric and, although no length limit is 685 given, they are recommended to be short. 687 Times, Repeat Times and Time Zones 689 t= 691 "t=" fields specify the start and stop times for a session. 692 Multiple "t=" fields MAY be used if a session is active at 693 multiple irregularly spaced times; each additional "t=" field 694 specifies an additional period of time for which the session will 695 be active. If the session is active at regular times, an "r=" 696 field (see below) should be used in addition to and following a 697 "t=" field - in which case the "t=" field specifies the start and 698 stop times of the repeat sequence. 700 The first and second sub-fields give the start and stop times for 701 the session respectively. These values are the decimal 702 representation of Network Time Protocol (NTP) time values in 703 seconds [RFC1305]. To convert these values to UNIX time, subtract 704 decimal 2208988800. 706 NTP timestamps are 64 bit values which wrap sometime in the year 707 2036. Since SDP uses an arbitrary length decimal representation, 708 this should not cause an issue (SDP timestamps will continue 709 counting seconds since 1900, NTP will use the value modulo the 64 710 bit limit). 712 If the stop-time is set to zero, then the session is not bounded, 713 though it will not become active until after the start-time. If 714 the start-time is also zero, the session is regarded as permanent. 716 User interfaces SHOULD strongly discourage the creation of 717 unbounded and permanent sessions as they give no information about 718 when the session is actually going to terminate, and so make 719 scheduling difficult. 721 The general assumption may be made, when displaying unbounded 722 sessions that have not timed out to the user, that an unbounded 723 session will only be active until half an hour from the current 724 time or the session start time, whichever is the later. If 725 behaviour other than this is required, an end-time should be given 726 and modified as appropriate when new information becomes available 727 about when the session should really end. 729 Permanent sessions may be shown to the user as never being active 730 unless there are associated repeat times which state precisely 731 when the session will be active. In general, permanent sessions 732 SHOULD NOT be created for any session expected to have a duration 733 of less than 2 months, and should be discouraged for sessions 734 expected to have a duration of less than 6 months. 736 r= 739 "r=" fields specify repeat times for a session. For example, if a 740 session is active at 10am on Monday and 11am on Tuesday for one 741 hour each week for three months, then the in the 742 corresponding "t=" field would be the NTP representation of 10am 743 on the first Monday, the would be 1 week, the 744 would be 1 hour, and the offsets would be zero 745 and 25 hours. The corresponding "t=" field stop time would be the 746 NTP representation of the end of the last session three months 747 later. By default all fields are in seconds, so the "r=" and "t=" 748 fields might be: 750 t=3034423619 3042462419 751 r=604800 3600 0 90000 753 To make description more compact, times may also be given in units 754 of days, hours or minutes. The syntax for these is a number 755 immediately followed by a single case-sensitive character. 756 Fractional units are not allowed - a smaller unit should be used 757 instead. The following unit specification characters are allowed: 759 d - days (86400 seconds) 760 h - hours (3600 seconds) 761 m - minutes (60 seconds) 762 s - seconds (allowed for completeness but not recommended) 764 Thus, the above announcement could also have been written: 766 r=7d 1h 0 25h 768 Monthly and yearly repeats cannot be directly specified with a 769 single SDP repeat time - instead separate "t" fields should be 770 used to explicitly list the session times. 772 z= .... 774 To schedule a repeated session which spans a change from daylight- 775 saving time to standard time or vice-versa, it is necessary to 776 specify offsets from the base time. This is required because 777 different time zones change time at different times of day, 778 different countries change to or from daylight time on different 779 dates, and some countries do not have daylight saving time at all. 781 Thus in order to schedule a session that is at the same time 782 winter and summer, it must be possible to specify unambiguously 783 by whose time zone a session is scheduled. To simplify this task 784 for receivers, we allow the sender to specify the NTP time that a 785 time zone adjustment happens and the offset from the time when the 786 session was first scheduled. The "z" field allows the sender to 787 specify a list of these adjustment times and offsets from the base 788 time. 790 An example might be: 792 z=2882844526 -1h 2898848070 0 794 This specifies that at time 2882844526 the time base by which the 795 session's repeat times are calculated is shifted back by 1 hour, 796 and that at time 2898848070 the session's original time base is 797 restored. Adjustments are always relative to the specified start 798 time - they are not cumulative. Adjustments apply to all "t=" and 799 "r=" lines in a session description. 801 If a session is likely to last several years, it is expected that 802 the session announcement will be modified periodically rather than 803 transmit several years worth of adjustments in one announcement. 805 Encryption Keys 807 k= 808 k=: 810 If transported over a secure and trusted channel, the session 811 description protocol MAY be used to convey encryption keys. A key 812 field is permitted before the first media entry (in which case it 813 applies to all media in the session), or for each media entry as 814 required. 816 The format of keys and their usage is outside the scope of this 817 document, but see [RFC1890] for an example. 819 The method indicates the mechanism to be used to obtain a usable 820 key by external means, or from the encoded encryption key given. 821 The following methods are defined: 823 k=clear: 825 The encryption key is included untransformed in this key field. 826 This method MUST NOT be used unless it can be guaranteed that 827 the SDP is conveyed over a secure channel. 829 k=base64: 831 The encryption key is included in this key field but has been 832 base64 encoded because it includes characters that are 833 prohibited in SDP. This method MUST NOT be used unless it can 834 be guaranteed that the SDP is conveyed over a secure channel. 836 k=uri: 838 A Universal Resource Identifier is included in the key field. 839 The URI refers to the data containing the key, and may require 840 additional authentication before the key can be returned. When 841 a request is made to the given URI, the MIME content-type of 842 the reply specifies the encoding for the key in the reply. 844 k=prompt 846 No key is included in this SDP description, but the session or 847 media stream referred to by this key field is encrypted. The 848 user should be prompted for the key when attempting to join the 849 session, and this user-supplied key should then be used to 850 decrypt the media streams. The use of user-specified keys is 851 NOT RECOMMENDED, since such keys tend to have weak security 852 properties. 854 The key field MUST NOT be used unless it can be guaranteed that 855 the SDP is conveyed over a secure and trusted channel. Examples of 856 such channels might include an SSL encrypted SIP or HTTP session 857 where any intermediate proxies are trusted, or SDP embedded inside 858 an encrypted S/MIME message. 860 Attributes 862 a= 863 a=: 865 Attributes are the primary means for extending SDP. Attributes 866 may be defined to be used as "session-level" attributes, "media- 867 level" attributes, or both. 869 A media description may have any number of attributes ("a=" 870 fields) which are media specific. These are referred to as 871 "media-level" attributes and add information about the media 872 stream. Attribute fields can also be added before the first media 873 field; these "session-level" attributes convey additional 874 information that applies to the conference as a whole rather than 875 to individual media; an example might be the conference's floor 876 control policy. 878 Attribute fields may be of two forms: 880 o property attributes: 881 A property attribute is simply of the form "a=". 882 These are binary attributes, and the presence of the 883 attribute conveys that the attribute is a property of 884 the session. An example might be "a=recvonly". 886 o value attributes: 887 A value attribute is of the form "a=:". 888 For example, a whiteboard could have the value attribute 889 "a=orient:landscape" 891 Attribute interpretation depends on the media tool being invoked. 892 Thus receivers of session descriptions should be configurable in 893 their interpretation of announcements in general and of attributes 894 in particular. 896 Attribute names MUST be in the US-ASCII subset of ISO-10646/UTF-8. 898 Attribute values are octet strings, and MAY use any octet value 899 except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, 900 attribute values are to be interpreted as in ISO-10646 character 901 set with UTF-8 encoding. Unlike other text fields, attribute 902 values are NOT normally affected by the "charset" attribute as 903 this would make comparisons against known values problematic. 904 However, when an attribute is defined, it can be defined to be 905 charset-dependent, in which case it's value should be interpreted 906 in the session charset rather than in ISO-10646. 908 Attributes SHOULD be registered with IANA (see Appendix B). Names 909 of unregistered attributes SHOULD begin with "X-" to prevent 910 inadvertent collision with registered attributes, however the use 911 of unregistered attributes is NOT RECOMMENDED. If an attribute is 912 received that is not understood, it MUST be ignored by the 913 receiver. 915 Media Announcements 917 m= 919 A session description may contain a number of media descriptions. 920 Each media description starts with an "m=" field, and is 921 terminated by either the next "m=" field or by the end of the 922 session description. A media field has several four sub-fields. 924 The first sub-field is the media type. Currently defined media 925 are "audio", "video", "application", "data" and "control", though 926 this list may be extended in future. The difference between 927 "application" and "data" is that the former is a media flow such 928 as whiteboard information, and the latter is bulk-data transfer 929 such as multicasting of program executables which will not 930 typically be displayed to the user. "control" is used to specify 931 an additional conference control channel for the session. 933 The second sub-field is the transport port to which the media 934 stream is sent. The meaning of the transport port depends on the 935 network being used as specified in the relevant "c=" field, and on 936 the transport protocol defined in the third sub-field. Other 937 ports used by the media application (such as the RTCP port 938 [RFC1889]) MAY be derived algorithmically from the base media port 939 or MAY be specified in a separate attribute (e.g. "a=rtcp:" as 940 defined in [RTCPSDP]). 942 For applications where hierarchically encoded streams are being 943 sent to a unicast address, it may be necessary to specify multiple 944 transport ports. This is done using a similar notation to that 945 used for IP multicast addresses in the "c=" field: 947 m= / 949 In such a case, the ports used depend on the transport protocol. 950 For RTP, only the even ports are used for data and the 951 corresponding one-higher odd port is used for RTCP. For example: 953 m=video 49170/2 RTP/AVP 31 955 would specify that ports 49170 and 49171 form one RTP/RTCP pair 956 and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the 957 transport protocol and 31 is the format (see below). 959 If multiple addresses are specified in the "c=" field and multiple 960 ports are specified in the "m=" field, a one-to-one mapping from 961 port to the corresponding address is implied. For example: 963 c=IN IP4 224.2.1.1/127/2 964 m=video 49170/2 RTP/AVP 31 966 would imply that address 224.2.1.1 is used with ports 49170 and 967 49171, and address 224.2.1.2 is used with ports 49172 and 49173. 969 The third sub-field is the transport protocol. The transport 970 protocol values are dependent on the address-type field in the 971 "c=" fields. Thus a "c=" field of IP4 defines that the transport 972 protocol runs over IP4. For IP4, it is normally expected that 973 most media traffic will be carried as RTP over UDP. The following 974 transport protocols are defined, but may be extended through 975 registration of new protocols with IANA (see Appendix B): 977 RTP/AVP - the IETF's Realtime Transport Protocol using the 978 Audio/Video profile carried over UDP. 979 udp - User Datagram Protocol 980 TCP - Transmission Control Protocol 982 If an application uses a single combined proprietary media format 983 and transport protocol over UDP, then simply specifying the 984 transport protocol as udp and using the format field to 985 distinguish the combined protocol is recommended. If a transport 986 protocol is used over UDP to carry several distinct media types 987 that need to be distinguished by a session directory, then 988 specifying the transport protocol and media format separately is 989 necessary. RTP is an example of a transport-protocol that carries 990 multiple payload formats that must be distinguished by the session 991 directory for it to know how to start appropriate tools, relays, 992 mixers or recorders. 994 The main reason to specify the transport-protocol in addition to 995 the media format is that the same standard media formats may be 996 carried over different transport protocols even when the network 997 protocol is the same - a historical example is vat PCM audio and 998 RTP PCM audio. In addition, relays and monitoring tools that are 999 transport-protocol-specific but format-independent are possible. 1001 For RTP media streams operating under the RTP Audio/Video Profile 1002 [RFC1890], the protocol field is "RTP/AVP". Should other RTP 1003 profiles be defined in the future, their profiles will be 1004 specified in the same way. For example, the protocol field 1005 "RTP/XYZ" would specify RTP operating under a profile whose short 1006 name is "XYZ". 1008 The fourth and subsequent sub-fields are media formats. For audio 1009 and video, these SHOULD reference a MIME sub-type describing the 1010 format under the "audio" and "video" top-level MIME types. 1012 When a list of payload formats is given, this implies that all of 1013 these formats may be used in the session, but the first of these 1014 formats SHOULD be used as the default format for the session. 1016 For media whose transport protocol is not RTP or UDP the format 1017 field is protocol specific. Such formats should be defined in an 1018 additional specification document. 1020 For media whose transport protocol is RTP, SDP can be used to 1021 provide a dynamic binding of media encoding to RTP payload type. 1022 The encoding names in the RTP AV Profile do not specify unique 1023 audio encodings (in terms of clock rate and number of audio 1024 channels), and so they are not used directly in SDP format fields. 1025 Instead, the payload type number should be used to specify the 1026 format for static payload types and the payload type number along 1027 with additional encoding information should be used for 1028 dynamically allocated payload types. 1030 An example of a static payload type is u-law PCM coded single 1031 channel audio sampled at 8kHz. This is completely defined in the 1032 RTP Audio/Video profile as payload type 0, so the media field for 1033 such a stream sent to UDP port 49232 is: 1035 m=audio 49232 RTP/AVP 0 1037 An example of a dynamic payload type is 16 bit linear encoded 1038 stereo audio sampled at 16 kHz. If we wish to use dynamic RTP/AVP 1039 payload type 98 for such a stream, additional information is 1040 required to decode it: 1042 m=audio 49232 RTP/AVP 98 1043 a=rtpmap:98 L16/16000/2 1045 The general form of an rtpmap attribute is: 1047 a=rtpmap: /[/] 1050 For audio streams, may specify the number of 1051 audio channels. This parameter may be omitted if the number of 1052 channels is one provided no additional parameters are needed. 1054 For video streams, no encoding parameters are currently specified. 1056 Additional parameters may be defined in the future, but codec- 1057 specific parameters SHOULD NOT be added. Parameters added to an 1058 rtpmap attribute SHOULD only be those required for a session 1059 directory to make the choice of appropriate media to participate 1060 in a session. Codec-specific parameters should be added in other 1061 attributes (for example, "a=fmtp:"). 1063 Up to one rtpmap attribute can be defined for each media format 1064 specified. Thus we might have: 1066 m=audio 49230 RTP/AVP 96 97 98 1067 a=rtpmap:96 L8/8000 1068 a=rtpmap:97 L16/8000 1069 a=rtpmap:98 L16/11025/2 1071 RTP profiles that specify the use of dynamic payload types MUST 1072 define the set of valid encoding names and/or a means to register 1073 encoding names if that profile is to be used with SDP. 1075 Experimental encoding formats can also be specified using rtpmap. 1076 RTP formats that are not registered as standard format names MUST 1077 be preceded by "X-". Use of the ``X-'' prefix is deprecated, and 1078 all new formats SHOULD be registered with IANA. Thus a new 1079 experimental redundant audio stream called GSMLPC using dynamic 1080 payload type 99 could be specified as: 1082 m=audio 49232 RTP/AVP 99 1083 a=rtpmap:99 X-GSMLPC/8000 1085 Such an experimental encoding requires that any site wishing to 1086 receive the media stream has relevant configured state in its 1087 session directory to know which tools are appropriate. 1089 Note that RTP audio formats typically do not include information 1090 about the number of samples per packet. If a non-default (as 1091 defined in the RTP Audio/Video Profile) packetisation is required, 1092 the"ptime" attribute is used as given below. 1094 For more details on RTP audio and video formats, see [RFC1890]. 1096 Predefined applicarion formats for the UDP protocol with non-RTP 1097 media are as below: 1098 wb: LBL Whiteboard (transport: udp) 1099 nt: UCL Network Text Editor (transport: udp) 1101 Suggested Attributes 1103 The following attributes are suggested. Since application writers 1104 may add new attributes as they are required, this list is not 1105 exhaustive. 1107 a=cat: 1109 This attribute gives the dot-separated hierarchical category of 1110 the session. This is to enable a receiver to filter unwanted 1111 sessions by category. It would probably have been a compulsory 1112 separate field, except for its experimental nature at this 1113 time. It is a session-level attribute, and is not dependent on 1114 charset. 1116 a=keywds: 1118 Like the cat attribute, this is to assist identifying wanted 1119 sessions at the receiver. This allows a receiver to select 1120 interesting session based on keywords describing the purpose of 1121 the session. It is a session-level attribute. It is a charset 1122 dependent attribute, meaning that its value should be 1123 interpreted in the charset specified for the session 1124 description if one is specified, or by default in ISO 1125 10646/UTF-8. 1127 a=tool: 1129 This gives the name and version number of the tool used to 1130 create the session description. It is a session-level 1131 attribute, and is not dependent on charset. 1133 a=ptime: 1135 This gives the length of time in milliseconds represented by 1136 the media in a packet. This is probably only meaningful for 1137 audio data, but may be used with other media types if it makes 1138 sense. It should not be necessary to know ptime to decode RTP 1139 or vat audio, and it is intended as a recommendation for the 1140 encoding/packetisation of audio. It is a media attribute, and 1141 is not dependent on charset. 1143 a=maxptime: 1145 The maximum amount of media which can be encapsulated in each 1146 packet, expressed as time in milliseconds. The time SHALL be 1147 calculated as the sum of the time the media present in the 1148 packet represents. The time SHOULD be a multiple of the frame 1149 size. This attribute is probably only meaningful for audio 1150 data, but may be used with other media types if it makes sense. 1151 It is a media attribute, and is not dependent on charset. Note 1152 that this attribute was introduced after RFC 2327, and non 1153 updated implementations will ignore this attribute. 1155 a=rtpmap: /[/] 1158 See the section on Media Announcements (the "m=" field). This 1159 may be either a session or media attribute. 1161 a=recvonly 1163 This specifies that the tools should be started in receive-only 1164 mode where applicable. It can be either a session or media 1165 attribute, and is not dependent on charset. Note that recvonly 1166 applies to the media only, not to any associated control 1167 protocol (e.g. an RTP based system in recvonly mode SHOULD 1168 still send RTCP packets). 1170 a=sendrecv 1172 This specifies that the tools should be started in send and 1173 receive mode. This is necessary for interactive conferences 1174 with tools such as wb which defaults to receive only mode. It 1175 can be either a session or media attribute, and is not 1176 dependent on charset. 1178 If none of the attributes "sendonly", "recvonly", "inactive", 1179 and "sendrecv" is present, "sendrecv" SHOULD be assumed as the 1180 default for sessions which are not of the conference type 1181 "broadcast" or "H332" (see below). 1183 a=sendonly 1185 This specifies that the tools should be started in send-only 1186 mode. An example may be where a different unicast address is 1187 to be used for a traffic destination than for a traffic source. 1188 In such a case, two media descriptions may be use, one sendonly 1189 and one recvonly. It can be either a session or media 1190 attribute, but would normally only be used as a media 1191 attribute, and is not dependent on charset. Note that sendonly 1192 applies only to the media, and any associated control protocol 1193 (e.g. RTCP) SHOULD still be received and processed as normal. 1195 a=inactive 1197 This specifies that the tools should be started in inactive 1198 mode. This is necessary for interactive conferences where 1199 users can put other users on hold. No media is sent over an 1200 inactive media stream. Note that an RTP based system SHOULD 1201 still send RTCP, even if started inactive. It can be either a 1202 session or media attribute, and is not dependent on charset. 1204 a=orient: 1206 Normally this is only used in a whiteboard media specification. 1207 It specifies the orientation of a the whiteboard on the screen. 1208 It is a media attribute. Permitted values are "portrait", 1209 "landscape" and "seascape" (upside down landscape). It is not 1210 dependent on charset. 1212 a=type: 1214 This specifies the type of the conference. Suggested values 1215 are "broadcast", "meeting", "moderated", "test" and "H332". 1216 "recvonly" should be the default for "type:broadcast" sessions, 1217 "type:meeting" should imply "sendrecv" and "type:moderated" 1218 should indicate the use of a floor control tool and that the 1219 media tools are started so as to mute new sites joining the 1220 conference. 1222 Specifying the attribute "type:H332" indicates that this 1223 loosely coupled session is part of a H.332 session as defined 1224 in the ITU H.332 specification [H.332]. Media tools should be 1225 started "recvonly". 1227 Specifying the attribute "type:test" is suggested as a hint 1228 that, unless explicitly requested otherwise, receivers can 1229 safely avoid displaying this session description to users. 1231 The type attribute is a session-level attribute, and is not 1232 dependent on charset. 1234 a=charset: 1235 This specifies the character set to be used to display the 1236 session name and information data. By default, the ISO-10646 1237 character set in UTF-8 encoding is used. If a more compact 1238 representation is required, other character sets may be used 1239 such as ISO-8859-1 for Northern European languages. In 1240 particular, the ISO 8859-1 is specified with the following SDP 1241 attribute: 1243 a=charset:ISO-8859-1 1245 This is a session-level attribute; if this attribute is 1246 present, it must be before the first media field. The charset 1247 specified MUST be one of those registered with IANA, such as 1248 ISO-8859-1. The character set identifier is a US-ASCII string 1249 and MUST be compared against the IANA identifiers using a case- 1250 insensitive comparison. If the identifier is not recognised or 1251 not supported, all strings that are affected by it SHOULD be 1252 regarded as octet strings. 1254 Note that a character set specified MUST still prohibit the use 1255 of bytes 0x00 (Nul), 0x0A (LF) and 0x0d (CR). Character sets 1256 requiring the use of these characters MUST define a quoting 1257 mechanism that prevents these bytes appearing within text 1258 fields. 1260 a=sdplang: 1262 This can be a session level attribute or a media level 1263 attribute. As a session level attribute, it specifies the 1264 language for the session description. As a media level 1265 attribute, it specifies the language for any media-level SDP 1266 information field associated with that media. Multiple sdplang 1267 attributes can be provided either at session or media level if 1268 multiple languages in the session description or media use 1269 multiple languages, in which case the order of the attributes 1270 indicates the order of importance of the various languages in 1271 the session or media from most important to least important. 1273 In general, sending session descriptions consisting of multiple 1274 languages is discouraged. Instead, multiple descriptions 1275 SHOULD be sent describing the session, one in each language. 1276 However this is not possible with all transport mechanisms, and 1277 so multiple sdplang attributes are allowed although NOT 1278 RECOMMENDED. 1280 The "sdplang" attribute value must be a single RFC 1766 1281 language tag in US-ASCII. It is not dependent on the charset 1282 attribute. An "sdplang" attribute SHOULD be specified when a 1283 session is of sufficient scope to cross geographic boundaries 1284 where the language of recipients cannot be assumed, or where 1285 the session is in a different language from the locally assumed 1286 norm. 1288 a=lang: 1290 This can be a session level attribute or a media level 1291 attribute. As a session level attribute, it specifies the 1292 default language for the session being described. As a media 1293 level attribute, it specifies the language for that media, 1294 overriding any session-level language specified. Multiple lang 1295 attributes can be provided either at session or media level if 1296 multiple languages if the session description or media use 1297 multiple languages, in which case the order of the attributes 1298 indicates the order of importance of the various languages in 1299 the session or media from most important to least important. 1301 The "lang" attribute value must be a single RFC 1766 language 1302 tag in US-ASCII. It is not dependent on the charset attribute. 1303 A "lang" attribute SHOULD be specified when a session is of 1304 sufficient scope to cross geographic boundaries where the 1305 language of recipients cannot be assumed, or where the session 1306 is in a different language from the locally assumed norm. 1308 a=framerate: 1310 This gives the maximum video frame rate in frames/sec. It is 1311 intended as a recommendation for the encoding of video data. 1312 Decimal representations of fractional values using the notation 1313 "." are allowed. It is a media attribute, 1314 is only defined for video media, and is not dependent on 1315 charset. 1317 a=quality: 1319 This gives a suggestion for the quality of the encoding as an 1320 integer value. The intention of the quality attribute for 1321 video is to specify a non-default trade-off between frame-rate 1322 and still-image quality. For video, the value in the range 0 1323 to 10, with the following suggested meaning: 1325 10 - the best still-image quality the compression scheme can 1326 give. 1327 5 - the default behaviour given no quality suggestion. 1328 0 - the worst still-image quality the codec designer thinks 1329 is still usable. 1331 It is a media attribute, and is not dependent on charset. 1333 a=fmtp: 1335 This attribute allows parameters that are specific to a 1336 particular format to be conveyed in a way that SDP doesn't have 1337 to understand them. The format must be one of the formats 1338 specified for the media. Format-specific parameters may be any 1339 set of parameters required to be conveyed by SDP and given 1340 unchanged to the media tool that will use this format. 1342 It is a media attribute, and is not dependent on charset. 1344 5.1. Communicating Conference Control Policy 1346 There is some debate over the way conference control policy should be 1347 communicated. In general, the authors believe that an implicit 1348 declarative style of specifying conference control is desirable where 1349 possible. 1351 A simple declarative style uses a single conference attribute field 1352 before the first media field, possibly supplemented by properties 1353 such as `recvonly' for some of the media tools. This conference 1354 attribute conveys the conference control policy. An example might 1355 be: 1357 a=type:moderated 1359 In some cases, however, it is possible that this may be insufficient 1360 to communicate the details of an unusual conference control policy. 1361 If this is the case, then a conference attribute specifying external 1362 control might be set, and then one or more "media" fields might be 1363 used to specify the conference control tools and configuration data 1364 for those tools. An example is an ITU H.332 session: 1366 ... 1367 c=IN IP4 224.5.6.7 1368 a=type:H332 1369 m=audio 49230 RTP/AVP 0 1370 m=video 49232 RTP/AVP 31 1371 m=application 12349 udp wb 1372 m=control 49234 H323 mc 1373 c=IN IP4 134.134.157.81 1375 In this example, a general conference attribute (type:H332) is 1376 specified stating that conference control will be provided by an 1377 external H.332 tool, and a contact addresses for the H.323 session 1378 multipoint controller is given. 1380 In this document, only the declarative style of conference control 1381 declaration is specified. Other forms of conference control should 1382 specify an appropriate type attribute, and should define the 1383 implications this has for control media. 1385 6. Security Considerations 1387 SDP is a session description format that describes multimedia 1388 sessions. A session description SHOULD NOT be trusted unless it has 1389 been obtained by an authenticated transport protocol from a trusted 1390 source. Many different transport protocols may be used to distribute 1391 session description, and the nature of the authentication will differ 1392 from transport to transport. 1394 One transport that will frequently be used to distribute session 1395 descriptions is the Session Announcement Protocol (SAP). SAP 1396 provides both encryption and authentication mechanisms but due to the 1397 nature of session announcements it is likely that there are many 1398 occasions where the originator of a session announcement cannot be 1399 authenticated because they are previously unknown to the receiver of 1400 the announcement and because no common public key infrastructure is 1401 available. 1403 On receiving a session description over an unauthenticated transport 1404 mechanism or from an untrusted party, software parsing the session 1405 should take a few precautions. Session descriptions contain 1406 information required to start software on the receivers system. 1407 Software that parses a session description MUST NOT be able to start 1408 other software except that which is specifically configured as 1409 appropriate software to participate in multimedia sessions. It is 1410 normally considered inappropriate for software parsing a session 1411 description to start, on a user's system, software that is 1412 appropriate to participate in multimedia sessions, without the user 1413 first being informed that such software will be started and giving 1414 their consent. Thus a session description arriving by session 1415 announcement, email, session invitation, or WWW page SHOULD NOT 1416 deliver the user into an interactive multimedia session without the 1417 user being aware that this will happen. As it is not always simple 1418 to tell whether a session is interactive or not, applications that 1419 are unsure should assume sessions are interactive. 1421 In this specification, there are no attributes which would allow the 1422 recipient of a session description to be informed to start multimedia 1423 tools in a mode where they default to transmitting. Under some 1424 circumstances it might be appropriate to define such attributes. If 1425 this is done an application parsing a session description containing 1426 such attributes SHOULD either ignore them, or inform the user that 1427 joining this session will result in the automatic transmission of 1428 multimedia data. The default behaviour for an unknown attribute is 1429 to ignore it. 1431 Session descriptions may be parsed at intermediate systems such as 1432 firewalls for the purposes of opening a hole in the firewall to allow 1433 the participation in multimedia sessions. It is considered 1434 inappropriate for a firewall to open such holes for unicast data 1435 streams unless the session description comes in a request from inside 1436 the firewall. For multicast sessions, it is likely that local 1437 administrators will apply their own policies, but the exclusive use 1438 of "local" or "site-local" administrative scope within the firewall 1439 and the refusal of the firewall to open a hole for such scopes will 1440 provide separation of global multicast sessions from local ones. 1442 Use of the "k=" field poses a significant security risk, since it 1443 conveys session encryption keys in the clear. SDP MUST NOT be used 1444 to convey key material, unless it can be guaranteed that the channel 1445 over which the SDP is delivered is both private and authenticated. 1447 Appendix A: SDP Grammar 1449 This appendix provides an Augmented BNF grammar for SDP. ABNF is 1450 defined in RFC 2234. 1452 ; SDP Syntax 1453 announcement = proto-version 1454 origin-field 1455 session-name-field 1456 information-field 1457 uri-field 1458 email-fields 1459 phone-fields 1460 connection-field 1461 bandwidth-fields 1462 time-fields 1463 key-field 1464 attribute-fields 1465 media-descriptions 1467 proto-version = "v=" 1*DIGIT CRLF 1468 ;this memo describes version 0 1470 origin-field = "o=" username SP sess-id SP sess-version SP 1471 nettype SP addrtype SP unicast-address CRLF 1473 session-name-field = "s=" text CRLF 1475 information-field = ["i=" text CRLF] 1477 uri-field = ["u=" uri CRLF] 1479 email-fields = *("e=" email-address CRLF) 1481 phone-fields = *("p=" phone-number CRLF) 1482 connection-field = ["c=" nettype SP addrtype SP 1483 connection-address CRLF] 1484 ;a connection field must be present 1485 ;in every media description or at the 1486 ;session-level 1488 bandwidth-fields = *("b=" bwtype ":" bandwidth CRLF) 1490 time-fields = 1*( "t=" start-time SP stop-time 1491 *(CRLF repeat-fields) CRLF) 1492 [zone-adjustments CRLF] 1494 repeat-fields = "r=" repeat-interval SP typed-time 1495 1*(SP typed-time) 1497 zone-adjustments = "z=" time SP ["-"] typed-time 1498 *(SP time SP ["-"] typed-time) 1500 key-field = ["k=" key-type CRLF] 1502 attribute-fields = *("a=" attribute CRLF) 1504 media-descriptions = *( media-field 1505 information-field 1506 *connection-field 1507 bandwidth-fields 1508 key-field 1509 attribute-fields ) 1511 media-field = "m=" media SP port ["/" integer] 1512 SP proto 1*(SP fmt) CRLF 1514 ; sub-rules of 'o=' 1515 username = non-ws-string 1516 ;pretty wide definition, but doesn't 1517 ;include space 1519 sess-id = 1*DIGIT 1520 ;should be unique for this username/host 1522 sess-version = 1*DIGIT 1523 ;0 is a new session 1525 nettype = token 1526 ;typically "IN" 1528 addrtype = token 1529 ;typically "IP4" or "IP6" 1531 ; sub-rules of 'u=' 1532 uri = URI-reference; defined in RFC1630 and RFC2732 1534 ; sub-rules of 'e=' 1535 email-address = email *SP "(" 1*email-safe ")" / 1536 1*email-safe "<" email ">" / 1537 email 1539 email = addr-spec ; defined in RFC2822 1540 ; modified to remove CFWS 1542 ; sub-rules of 'p=' 1543 phone-number = phone *SP "(" 1*email-safe ")" / 1544 1*email-safe "<" phone ">" / 1545 phone 1547 phone = "+" POS-DIGIT 1*(SP / "-" / DIGIT) 1548 ;there must be a space or hyphen between the 1549 ;international code and the rest of the number. 1551 ; sub-rules of 'c=' 1552 connection-address = multicast-address / unicast-address 1554 ; sub-rules of 'b=' 1555 bwtype = token 1556 bandwidth = 1*DIGIT 1558 ; sub-rules of 't=' 1559 start-time = time / "0" 1561 stop-time = time / "0" 1563 time = POS-DIGIT 9*DIGIT 1564 ; 10-digit NTP time represents times between 1565 ; 1931 and 5068 AD. 9* allows times after that 1566 ; as well. 1568 ; sub-rules of 'r=' and 'z=' 1569 repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] 1571 typed-time = 1*DIGIT [fixed-len-time-unit] 1573 fixed-len-time-unit = "d" / "h" / "m" / "s" 1575 ; sub-rules of 'k=' 1576 key-type = "prompt" / 1577 "clear:" text / 1578 "base64:" base64 / 1579 "uri:" uri / 1580 key-method [ ":" text ] 1582 base64 = *base64-unit [base64-pad] 1583 base64-unit = 4base64-char 1584 base64-pad = 2base64-char "==" / 3base64-char "=" 1585 base64-char = ALPHA / DIGIT / "+" / "/" 1587 key-method = token 1589 ; sub-rules of 'a=' 1590 attribute = (att-field ":" att-value) / att-field 1591 att-field = token 1593 att-value = byte-string 1595 ; sub-rules of 'm=' 1596 media = token 1597 ;typically "audio", "video", "application" 1598 ;or "data" 1600 fmt = token 1601 ;typically an RTP payload type for audio 1602 ;and video media 1604 proto = token "/" token 1605 / token 1606 ;typically "RTP/AVP" or "udp" for IP4 1608 port = 1*DIGIT 1609 ;should be either "0" or in the range "1024" to 1610 ;"65535" inclusive for UDP based media (a value 1611 ;"0" is used to signal special conditions in some 1612 ;uses of SDP) 1614 ; generic sub-rules: addressing 1615 unicast-address = IP4-address / IP6-address / FQDN / extension-addr 1617 multicast-address = IP4-multicast / IP6-multicast 1619 IP4-multicast = m1 3( "." decimal-uchar ) 1620 "/" ttl [ "/" integer ] 1621 ; IPv4 multicast addresses may be in the 1622 ; range 224.0.0.0 to 239.255.255.255 1624 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / 1625 ("23" DIGIT )) 1627 IP6-multicast = hexpart [ "/" integer ] 1628 ; IPv6 address starting with FF 1630 ttl = (POS-DIGIT *2DIGIT) / "0" 1632 FQDN = 4*(alpha-numeric / "-" / ".") 1633 ; fully qualified domain name as specified 1634 ; in RFC1035 1636 IP4-address = b1 3("." decimal-uchar) / "0.0.0.0" 1638 b1 = decimal-uchar 1639 ; less than "224"; not "0" or "127" 1641 ; The following is from RFC2373 Appendix B. It is a direct copy. 1642 IP6-address = hexpart [ ":" IP4-address ] 1644 hexpart = hexseq / hexseq "::" [ hexseq ] / 1645 "::" [ hexseq ] 1647 hexseq = hex4 *( ":" hex4) 1649 hex4 = 1*4HEXDIG 1651 ; Generic for other address families 1652 extension-addr = non-ws-string 1654 ; generic sub-rules: datatypes 1655 text = byte-string 1656 ;default is to interpret this as IS0-10646 UTF8 1657 ;ISO 8859-1 requires a "a=charset:ISO-8859-1" 1658 ;session-level attribute to be used 1660 byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) 1661 ;any byte except NUL, CR or LF 1663 non-ws-string = 1*(VCHAR/%x80-FF) 1664 ;string of visible characters 1666 token-char = %x21/%x23-27/%x2A-2B/%x2D-2E/%x30-39/%x41-5A/%x5E-7E 1667 ; definition from RFC 2045 - 1668 ; "any (US-ASCII) CHAR except SPACE, CTLs, 1669 ; or tspecials". 1670 ; the tspecials are ()<>@,;: 1672 token = 1*(token-char) 1674 email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF 1675 ;any byte except NUL, CR, LF, or the quoting 1676 ;characters ()<> 1678 integer = POS-DIGIT *DIGIT 1680 ; generic sub-rules: primitives 1681 alpha-numeric = ALPHA / DIGIT 1683 POS-DIGIT = %x31-39 ; 1 - 9 1685 decimal-uchar = DIGIT 1686 / POS-DIGIT DIGIT 1687 / ("1" 2*(DIGIT)) 1688 / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) 1689 / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) 1691 ; external references: 1692 ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 2234 1693 ; URI-reference: from RFC1630 and RFC2732 1694 ; addr-spec: from RFC 2822 1696 Appendix B: IANA Considerations 1698 There are seven field names that may be registered with IANA. Using 1699 the terminology in the SDP specification BNF, they are "media", 1700 "proto", "fmt", "att-field", "bwtype", "nettype" and "addrtype". 1702 "media" (e.g., audio, video, application, data). 1704 The set of media is intended to be small and SHOULD NOT be 1705 extended except under rare circumstances. The same rules should 1706 apply for media names as for top-level MIME content types, and 1707 where possible the same name should be registered for SDP as for 1708 MIME. For media other than existing MIME top-level content types, 1709 a standards-track RFC MUST be produced for a new top-level content 1710 type to be registered, and the registration MUST provide good 1711 justification why no existing media name is appropriate (the 1712 "Standards Action" policy of RFC 2434 [RFC2434]). 1714 "proto" 1716 The "proto" field describes the transport protocol used. This 1717 SHOULD reference a standards-track protocol RFC. This memo 1718 registers three values: "RTP/AVP" is a reference to RTP [RFC1889] 1719 used under the RTP Profile for Audio and Video Conferences with 1720 Minimal Control [RFC1890]) running over UDP/IP; "TCP" denotes an 1721 unspecified format over TCP; and "udp" indicates an unspecified 1722 format over UDP. 1724 New transport protocols MAY be registered with IANA. Registrations 1725 MUST reference an RFC describing the protocol. Such an RFC MAY be 1726 Experimental or Informational, although it is preferable if it is 1727 Standards-Track. Registrations MUST also define the rules by which 1728 their "fmt" namespace is managed (see below). 1730 Application-specific proprietary protocols that run over an 1731 existing transport protocol SHOULD be registered as a "fmt". The 1732 rules for formats (see below) apply to such registrations. An 1733 example is the LBL whiteboard application, which uses the proto 1734 "udp" with "wb" as the format. 1736 "fmt" 1738 Each transport protocol, defined by the "proto" field, has an 1739 associated "fmt" namespace that describes the media formats which 1740 may conveyed by that protocol. Formats cover all the possible 1741 encodings that might want to be transported in a multimedia 1742 session. 1744 RTP payload formats under the "RTP/AVP" protocol that have been 1745 assigned static payload types MUST use the static payload type as 1746 their "fmt" value. For payload formats under "RTP/AVP" that have 1747 a dynamic payload type number, the dynamic payload type number is 1748 given as the "fmt" and an additional "rtpmap" attribute specifies 1749 the format name and parameters. 1751 For "TCP" and "udp" protocols, new formats may be registered. If 1752 there is a suitable mapping from a MIME subtype to the format, it 1753 is RECOMMENDED that the MIME subtype name be used as the "fmt" 1754 name. If there is no suitable mapping from a MIME subtype, a new 1755 name should be registered. In either case, a standards-track RFC 1756 MUST be produced describing the format and this RFC MUST be 1757 referenced in the registration. 1759 For other protocols, formats MAY be registered according to the 1760 rules of the associated "proto" specification. 1762 Registrations of new formats MUST specify which transport 1763 protocols they apply to. 1765 "att-field" (Attribute names) 1767 Attribute field names MUST be registered with IANA and documented, 1768 because of noticeable issues due to conflicting attributes under 1769 the same name. Unknown attributes in SDP are simply ignored, but 1770 conflicting ones that fragment the protocol are a serious problem. 1772 New attributes MAY be registered according to the "Specification 1773 Required" policy of RFC 2434, provided that the specification 1774 includes the following information: 1776 o contact name, email address and telephone number 1778 o attribute-name (as it will appear in SDP) 1780 o long-form attribute name in English 1782 o type of attribute (session level, media level, or both) 1784 o whether the attribute value is subject to the charset 1785 attribute. 1787 o a one paragraph explanation of the purpose of the attribute. 1789 o a specification of appropriate attribute values for this 1790 attribute. 1792 The above is the minimum that IANA will accept. Attributes that 1793 are expected to see widespread use and interoperability, SHOULD be 1794 documented with a standards-track RFC that specifies the attribute 1795 more precisely. 1797 Submitters of registrations should ensure that the specification 1798 is in the spirit of SDP attributes, most notably that the 1799 attribute is platform independent in the sense that it makes no 1800 implicit assumptions about operating systems and does not name 1801 specific pieces of software in a manner that might inhibit 1802 interoperability. 1804 "bwtype" (bandwidth specifiers) 1806 A proliferation of bandwidth specifiers is strongly discouraged. 1808 New bandwidth specifiers MUST be registered with IANA. The 1809 submission MUST reference a standards-track RFC specifying the 1810 semantics of the bandwidth specifier precisely, and indicating 1811 when it should be used, and why the existing registered bandwidth 1812 specifiers do not suffice. 1814 "nettype" (Network Type) 1816 New network types may be registered with IANA if SDP needs to be 1817 used in the context of non-Internet environments. Whilst these 1818 are not normally the preserve of IANA, there may be circumstances 1819 when an Internet application needs to interoperate with a non- 1820 Internet application, such as when gatewaying an Internet 1821 telephony call into the PSTN. The number of network types should 1822 be small and should be rarely extended. A new network type cannot 1823 be registered without registering at least one address type to be 1824 used with that network type. A new network type registration MUST 1825 reference an RFC which gives details of the network type and 1826 address type and specifies how and when they would be used. Such 1827 an RFC MAY be Informational. 1829 "addrtype" (Address Type) 1831 New address types may be registered with IANA. An address type is 1832 only meaningful in the context of a network type, and any 1833 registration of an address type MUST specify a registered network 1834 type, or be submitted along with a network type registration. A 1835 new address type registration MUST reference an RFC giving details 1836 of the syntax of the address type. Such an RFC MAY be 1837 Informational. Address types are not expected to be registered 1838 frequently. 1840 Registration Procedure 1842 In the RFC documentation that registers SDP "media", "proto", "fmt", 1843 "bwtype", "nettype" and "addrtype" fields, the authors MUST include 1844 the following information for IANA to place in the appropriate 1845 registry: 1847 o contact name, email address and telephone number 1848 o name being registered (as it will appear in SDP) 1850 o long-form name in English 1852 o type of name ("media", "proto", "fmt", "bwtype", "nettype", or 1853 "addrtype") 1855 o a one paragraph explanation of the purpose of the registered 1856 name. 1858 o a reference to the specification (e.g. RFC number) of the 1859 registered name. 1861 IANA may refer any registration to the IESG Transport Area Directors 1862 for review, and may request revisions to be made before a 1863 registration will be made. 1865 Appendix C: Changes from RFC 2327 1867 o Deprecate X- notation for experimental parameters 1869 o Clarify that a=recvonly does NOT mean that you don't send 1870 RTCP, and similarly for sendonly and inactive. These only 1871 effect the RTP stream. 1873 o Rewrite and correct the ABNF syntax (thanks to Jonathan Lennox) 1875 o Update BNF to support IPv6. 1877 o Add a=inactive attribute. 1879 o Add a=maxptime attribute. 1881 o RFC 2327 mandated that either e= or p= was required. Both are 1882 now optional, to reflect actual usage. 1884 o Removed references to "conference" from the description of 1885 the t= line, to make it less SAP oriented. 1887 o Note about wrap-around of NTP timestamps in t= 1889 o References have been updated and split into normative and 1890 informative sections. 1892 o Section 3.1 was replaced with a reference to RFC 2119, and 1893 the memo has been updated to use the RFC 2119 terminology 1894 (MUST, SHOULD, etc). 1896 o Use of "application/sdp" as MIME a type for SDP files is now 1897 "MUST" rather than "SHOULD". 1899 o Many sections have been updated to be less SAP specific, and 1900 to reference other current uses of SDP such as RTSP and SIP. 1902 o The introduction and background has been rewritten, to remove 1903 references to the Mbone, reflecting current use of SDP. 1905 o The section on concatenation of session descriptions (which 1906 was not allowed in SAP, but allowed in other cases) has been 1907 removed. It is assumed that transports of SDP specify will 1908 specify this. 1910 o The description of the c= line has been updated to reflect 1911 common usage of SDP, rather than Mbone conferencing with SAP. 1913 o The b= line no longer makes a normative reference to the 1914 Mbone FAQ for bandwidth limits at various TTLs. The AS 1915 modifier to b= is noted as being the RTP session bandwidth. 1917 o Define relation between the m= line and MIME types 1919 o Note use of s= in sessions with no meaningful name 1921 o Allow a=rtpmap to be a session level attribute, in addition 1922 to a media level attribute 1924 o Clarify the limitations of the k= field 1926 o Clarify IANA considerations 1928 Appendix D: Authors' Addresses 1929 Mark Handley 1930 International Computer Science Institute, 1931 1947 Center Street, Suite 600, 1932 Berkeley, CA 94704 1933 United States 1934 Email: mjh@icir.org 1936 Van Jacobson 1937 Packet Design 1938 2465 Latham Street 1939 Mountain View, CA 94040 1940 United States 1941 Email: van@packetdesign.com 1943 Colin Perkins 1944 USC Information Sciences Institute 1945 3811 N. Fairfax Drive, Suite 200 1946 Arlington, VA 22203 1947 United States 1948 Email: csp@csperkins.org 1950 Acknowledgments 1952 Many people in the IETF MMUSIC working group have made comments and 1953 suggestions contributing to this document. In particular, we would 1954 like to thank Eve Schooler, Steve Casner, Bill Fenner, Allison 1955 Mankin, Ross Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, 1956 Steve Hanna and Jonathan Lennox. 1958 Full Copyright Statement 1960 Copyright (C) The Internet Society 2003. All Rights Reserved. 1962 This document and translations of it may be copied and furnished to 1963 others, and derivative works that comment on or otherwise explain it 1964 or assist in its implmentation may be prepared, copied, published and 1965 distributed, in whole or in part, without restriction of any kind, 1966 provided that the above copyright notice and this paragraph are 1967 included on all such copies and derivative works. However, this 1968 document itself may not be modified in any way, such as by removing 1969 the copyright notice or references to the Internet Society or other 1970 Internet organizations, except as needed for the purpose of 1971 developing Internet standards in which case the procedures for 1972 copyrights defined in the Internet Standards process must be 1973 followed, or as required to translate it into languages other than 1974 English. 1976 The limited permissions granted above are perpetual and will not be 1977 revoked by the Internet Society or its successors or assigns. 1979 This document and the information contained herein is provided on an 1980 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1981 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1982 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1983 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1984 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1986 Intellectual Property 1988 The IETF takes no position regarding the validity or scope of any 1989 intellectual property or other rights that might be claimed to 1990 pertain to the implementation or use of the technology described in 1991 this document or the extent to which any license under such rights 1992 might or might not be available; neither does it represent that it 1993 has made any effort to identify any such rights. Information on the 1994 IETF's procedures with respect to rights in standards-track and 1995 standards-related documentation can be found in BCP-11. Copies of 1996 claims of rights made available for publication and any assurances of 1997 licenses to be made available, or the result of an attempt made to 1998 obtain a general license or permission for the use of such 1999 proprietary rights by implementors or users of this specification can 2000 be obtained from the IETF Secretariat. 2002 The IETF invites any interested party to bring to its attention any 2003 copyrights, patents or patent applications, or other proprietary 2004 rights which may cover technology that may be required to practice 2005 this standard. Please address the information to the IETF Executive 2006 Director. 2008 Normative References 2010 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 2011 Requirement Levels", RFC 2119, March 1997. 2013 [RFC2434] T. Narten and H. Alvestrand, "Guidelines for Writing an 2014 IANA Considerations Section in RFCs", RFC 2434, October 2015 1998. 2017 Informative References 2019 [RFC1305] D. Mills, "Network Time Protocol (version 3) specification 2020 and implementation", RFC 1305, March 1992. 2022 [RFC1889] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, 2023 "RTP: A Transport Protocol for Real-Time Applications", 2024 RFC 1889, January 1996. 2026 [RFC1890] H. Schulzrinne, "RTP Profile for Audio and Video 2027 Conferences with Minimal Control", RFC 1890, January 2028 1996. 2030 [RFC2974] M. Handley, C. Perkins and E. Whelan, "Session 2031 Announcement Protocol", RFC 2974, October 2000. 2033 [H.332] ITU-T Recommendation H.332 (1998): "Multimedia Terminal for 2034 Receiving Internet-based H.323 Conferences", ITU, Geneva. 2036 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 2037 Peterson, R. Sparks, M. Handley, E. Schooler "SIP: Session 2038 Initiatation Protocol", RFC 3261, May 2002. 2040 [RFC2326] H. Schulzrinne, A. Rao and R. Lanphier, "Real Time 2041 Streaming Protocol (RTSP)" RFC 2326, April 1998. 2043 [RFC3264] J. Rosenberg and H. Schulzrinne, "An Offer/Answer Model 2044 with SDP", RFC 3264, May 2002. 2046 [RTCPSDP] C. Huitema, "RTCP Attribute in SDP", RFC XXXX, May 2002