idnits 2.17.1 draft-ietf-mmusic-sdp-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-ietf-mmusic-sdp-06.ps', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-mmusic-sdp-06.ps', does not give the document revision number == Mismatching filename: the document gives the document name as 'draft-ietf-mmusic-sdp-06.ps', but the file name used is 'draft-ietf-mmusic-sdp-06' ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 458 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There is 1 instance of too long lines in the document, the longest one being 9 characters in excess of 72. ** There are 949 instances of lines with control characters in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 9 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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 817: '...yte strings, and MAY use any byte va...' RFC 2119 keyword, line 1100: '... field. The charset specified MUST be...' RFC 2119 keyword, line 1102: '...ASCII string and MUST be compared agai...' RFC 2119 keyword, line 1105: '... affected by it SHOULD be regarded as...' RFC 2119 keyword, line 1107: '...er set specified MUST still prohibit t...' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 11 has weird spacing: '...fts are worki...' == Line 12 has weird spacing: '...ments of the ...' == Line 13 has weird spacing: '...t other group...' == Line 17 has weird spacing: '...and may be ...' == Line 21 has weird spacing: '... please check...' == (453 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: On receiving a session description over an unauthenticated transport mechanism or from an untrusted party, software parsing the session should take a few precautions. Session description contain information required to start software on the receivers system. Software that parses a session description MUST not be able to start other software except that which is specifically configured as appropriate software to participate in multimedia sessions. It is normally considered INAP-PROPRIATE for software parsing a session description to start, on a user's system, software that is appropriate to participate in multimedia sessions, without the user first being informed that such software will be started and giving their consent. Thus a session description arriv-ing by session announcement, email, session invitation, or WWW page SHOULD not deliver the user into an {it interactive} multimedia session without the user being aware that this will happen. As it is not always simple to tell whether a session is interactive or not, applications that are unsure should assume sessions are interactive. == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (Jul 1997) is 9754 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: '5' is defined on line 1647, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1650, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1655, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1658, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1661, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1119 (ref. '1') (Obsoleted by RFC 1305) ** Obsolete normative reference: RFC 1889 (ref. '2') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 1890 (ref. '3') (Obsoleted by RFC 3551) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Downref: Normative reference to an Experimental RFC: RFC 1641 (ref. '8') ** Obsolete normative reference: RFC 2044 (ref. '9') (Obsoleted by RFC 2279) -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' Summary: 22 errors (**), 0 flaws (~~), 17 warnings (==), 8 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/Van Jacobson 3 draft-ietf-mmusic-sdp-06.ps ISI/LBNL 4 22nd Jan 1997 5 Expires: 22nd Jul 1997 7 SDP: Session Description Protocol 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and its 13 working groups. Note that other groups may also distribute working 14 documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Distribution of this document is unlimited. 29 Abstract 31 This document defines the Session Description Protocol, SDP. 32 SDP is intended for describing multimedia sessions for the 33 purposes of session announcement, session invitation, and 34 other forms of multimedia session initiation. 36 This document is a product of the Multiparty Multimedia Session Control 37 (MMUSIC) working group of the Internet Engineering Task Force. Comments 38 are solicited and should be addressed to the working group's mailing 39 list at confctrl@isi.edu and/or the authors. 41 1. Introduction 43 On the Internet multicast backbone (Mbone), a session directory tool is 44 used to advertise multimedia conferences and communicate the conference 45 addresses and conference tool-specific information necessary for parti- 46 cipation. This document defines a session description protocol for this 47 purpose, and for general real-time multimedia session description pur- 48 poses. This draft does not describe multicast address allocation or the 49 distribution of SDP messages in detail. These are described in accom- 50 panying drafts. SDP is not intended for negotiation of media encodings. 52 2. Background 54 The Mbone is the part of the internet that supports IP multicast, and 55 thus permits efficient many-to-many communication. It is used exten- 56 sively for multimedia conferencing. Such conferences usually have the 57 property that tight coordination of conference membership is not neces- 58 sary; to receive a conference, a user at an Mbone site only has to know 59 the conference's multicast group address and the UDP ports for the 60 conference data streams. 62 Session directories assist the advertisement of conference sessions and 63 communicate the relevant conference setup information to prospective 64 participants. SDP is designed to convey such information to recipients. 65 SDP is purely a format for session description - it does not incorporate 66 a transport protocol, and is intended to use different transport proto- 67 cols as appropriate including the Session Announcement Protocol [4], 68 Session Initiation Protocol [11], Real-Time Streaming Protocol [12], 69 electronic mail using the MIME extensions, and the Hypertext Transport 70 Protocol. 72 SDP is intended to be general purpose so that it can be used for a wider 73 range of network environments and applications than just multicast ses- 74 sion directories. However, it is not intended to support negotiation of 75 session content or media encodings - this is viewed as outside the scope 76 of session description. 78 3. Glossary of Terms 80 The following terms are used in this document, and have specific meaning 81 within the context of this document. 83 Conference 84 A multimedia conference is a set of two or more communicating users 85 along with the software they are using to communicate. 87 Session 88 A multimedia session is a set of multimedia senders and receivers 89 and the data streams flowing from senders to receivers. A mul- 90 timedia conference is an example of a multimedia session. 92 Session Advertisement 93 See session announcement. 95 Session Announcement 96 A session announcement is a mechanism by which a session description 97 is conveyed to users in a pro-active fashion, i.e., the session 98 description was not explicitly requested by the user. 100 Session Description 101 A well defined format for conveying sufficient information to dis- 102 cover and participate in a multimedia session. 104 4. SDP Usage 106 4.1. Multicast Announcements 108 SDP is a session description protocol for multimedia sessions. A common 109 mode of usage is for a client to announce a conference session by 110 periodically multicasting an announcement packet to a well known multi- 111 cast address and port using the Session Announcement Protocol (SAP). 113 SAP packets are UDP packets with the following format: 115 0 31 116 |--------------------| 117 | SAP header | 118 |--------------------| 119 | text payload | 120 |////////// 122 The header is the Session Announcement Protocol header. SAP is 123 described in more detail in a companion draft [4] 125 The text payload is an SDP session description, as described in this 126 draft. The text payload should be no greater than 1 Kbyte in length. 127 If announced by SAP, only one session announcement is permitted in a 128 single packet. 130 4.2. Email and WWW Announcements 132 Alternative means of conveying session descriptions include electronic 133 mail and the World Wide Web. For both email and WWW distribution, the 134 use of the MIME content type ``application/sdp'' should be used. This 135 enables the automatic launching of applications for participation in the 136 session from the WWW client or mail reader in a standard manner. 138 Note that announcements of multicast sessions made only via email or the 139 World Wide Web (WWW) do not have the property that the receiver of a 140 session announcement can necessarily receive the session because the 141 multicast sessions may be restricted in scope, and access to the WWW 142 server or reception of email is possible outside this scope. SAP 143 announcements do not suffer from this mismatch. 145 5. Requirements and Recommendations 147 The purpose of SDP is to convey information about media streams in mul- 148 timedia sessions to allow the recipients of a session description to 149 participate in the session. SDP is primarily intended for use in an 150 internetwork, although it is sufficiently general that it can describe 151 conferences in other network environments. 153 A multimedia session, for these purposes, is defined as a set of media 154 streams that exist for some duration of time. Media streams can be 155 many-to-many. The times during which the session is active need not be 156 continuous. 158 Thus far, multicast based sessions on the Internet have differed from 159 many other forms of conferencing in that anyone receiving the traffic 160 can join the session (unless the session traffic is encrypted). In such 161 an environment, SDP serves two primary purposes. It is a means to com- 162 municate the existence of a session, and is a means to convey sufficient 163 information to enable joining and participating in the session. In a 164 unicast environment, only the latter purpose is likely to be relevant. 166 Thus SDP includes: 168 o Session name and purpose 170 o Time(s) the session is active 172 o The media comprising the session 174 o Information to receive those media (addresses, ports, formats and 175 so on) 177 As resources necessary to participate in a session may be limited, some 178 additional information may also be desirable: 180 o Information about the bandwidth to be used by the conference 182 o Contact information for the person responsible for the session 184 In general, SDP must convey sufficient information to be able to join a 185 session (with the possible exception of encryption keys) and to announce 186 the resources to be used to non-participants that may need to know. 188 5.1. Media Information 190 SDP includes: 192 o The type of media (video, audio, etc) 194 o The transport protocol (RTP/UDP/IP, H.320, etc) 196 o The format of the media (H.261 video, MPEG video, etc) 198 For an IP multicast session, the following are also conveyed: 200 o Multicast address for media 202 o Transport Port for media 204 This address and port are the destination address and destination port 205 of the multicast stream, whether being sent, received, or both. 207 For an IP unicast session, the following are conveyed: 209 o Remote address for media 211 o Transport port for contact address 213 The semantics of this address and port depend on the media and transport 214 protocol defined. By default, this is the remote address and remote 215 port to which data is sent, and the remote address and local port on 216 which to receive data. However, some media may define to use these to 217 establish a control channel for the actual media flow. 219 5.2. Timing Information 221 Sessions may either be bounded or unbounded in time. Whether or not 222 they are bounded, they may be only active at specific times. 224 SDP can convey: 226 o An arbitrary list of start and stop times bounding the session 227 o For each bound, repeat times such as "every Wednesday at 10am for 228 one hour" 230 This timing information is globally consistent, irrespective of local 231 time zone or daylight saving time. 233 5.3. Private Sessions 235 It is possible to create both public sessions and private sessions. 236 Private sessions will typically be conveyed by encrypting the session 237 description to distribute it. The details of how encryption is per- 238 formed are dependent on the mechanism used to convey SDP - see [4] for 239 how this is done for session announcements. 241 If a session announcement is private it is possible to use that private 242 announcement to convey encryption keys necessary to decode each of the 243 media in a conference, including enough information to know which 244 encryption scheme is used for each media. 246 5.4. Obtaining Further Information about a Session 248 A session description should convey enough information to decide whether 249 or not to participate in a session. SDP may include additional pointers 250 in the form of Universal Resources Identifiers (URIs) for more informa- 251 tion about the session. 253 5.5. Categorisation 255 When many session descriptions are being distributed by SAP or any other 256 advertisement mechanism, it may be desirable to filter announcements 257 that are of interest from those that are not. SDP supports a categori- 258 sation mechanism for sessions that is capable of being automated. 260 5.6. Internationalization 262 The SDP specification recommends the use of the ISO 10646 character sets 263 in the UTF-8 encoding (RFC 2044) to allow many different languages to be 264 represented. However, to assist in compact representations, SDP also 265 allows other character sets such as ISO 8859-1 to be used when desired. 266 Internationalization only applies to free-text fields (session name and 267 background information), and not to SDP as a whole. 269 6. SDP Specification 271 SDP session descriptions are entirely textual using the ISO 10646 char- 272 acter set in UTF-8 encoding. SDP field names and attributes names use 273 only the US-ASCII subset of UTF-8, but textual fields and attribute 274 values may use the full ISO 10646 character set. The textual form, as 275 opposed to a binary encoding such as ASN/1 or XDR, was chosen to enhance 276 portability, to enable a variety of transports to be used (e.g, session 277 description in a MIME email message) and to allow flexible, text-based 278 toolkits (e.g., Tcl/Tk ) to be used to generate and to process session 279 descriptions. However, since the total bandwidth allocated to all SAP 280 announcements is strictly limited, the encoding is deliberately compact. 281 Also, since announcements may be transported via very unreliable means 282 (e.g., email) or damaged by an intermediate caching server, the encoding 283 was designed with strict order and formatting rules so that most errors 284 would result in malformed announcements which could be detected easily 285 and discarded. This also allows rapid discarding of encrypted announce- 286 ments for which a receiver does not have the correct key. 288 An SDP session description consists of a number of lines of text of the 289 form 290 = 291 is always exactly one character and is case-significant. 292 is a structured text string whose format depends on . It also 293 will be case-significant unless a specific field defines otherwise. 294 Whitespace is not permitted either side of the `=' sign. In general 295 is either a number of fields delimited by a single space charac- 296 ter or a free format string. 298 A session description consists of a session-level description (details 299 that apply to the whole session and all media streams) and optionally 300 several media-level descriptions (details that apply onto to a single 301 media stream). 303 An announcement consists of a session-level section followed by zero or 304 more media-level sections. The session-level part starts with a `v=' 305 line and continues to the first media-level section. The media descrip- 306 tion starts with an `m=' line and continues to the next media descrip- 307 tion or end of the whole session description. In general, session-level 308 values are the default for all media unless overridden by an equivalent 309 media-level value. 311 When SDP is conveyed by SAP, only one session description is allowed per 312 packet. When SDP is conveyed by other means, many SDP session descrip- 313 tions may be concatenated together (the `v=' line indicating the start 314 of a session description terminates the previous description). Some 315 lines in each description are required and some are optional but all 316 must appear in exactly the order given here (the fixed order greatly 317 enhances error detection and allows for a simple parser). Optional 318 items are marked with a `*'. 320 Session description 321 v= (protocol version) 322 o= (owner/creator and session identifier). 323 s= (session name) 324 i=* (session information) 325 u=* (URI of description) 326 e=* (email address) 327 p=* (phone number) 328 c=* (connection information - not required if included in all media) 329 b=* (bandwidth information) 330 One or more time descriptions (see below) 331 z=* (time zone adjustments) 332 k=* (encryption key) 333 a=* (zero or more session attribute lines) 334 Zero or more media descriptions (see below) 336 Time description 337 t= (time the session is active) 338 r=* (zero or more repeat times) 340 Media description 341 m= (media name and transport address) 342 i=* (media title) 343 c=* (connection information - optional if included at session-level) 344 b=* (bandwidth information) 345 k=* (encryption key) 346 a=* (zero or more media attribute lines) 348 The set of `type' letters is deliberately small and not intended to be 349 extensible -- SDP parsers must completely ignore any announcement that 350 contains a `type' letter that it does not understand. The `attribute' 351 mechanism ("a=" described below) is the primary means for extending SDP 352 and tailoring it to particular applications or media. Some attributes 353 (the ones listed in this document) have a defined meaning but others may 354 be added on an application-, media- or session-specific basis. A ses- 355 sion directory must ignore any attribute it doesn't understand. 357 The connection (`c=') and attribute (`a=') information in the session- 358 level section applies to all the media of that session unless overridden 359 by connection information or an attribute of the same name in the media 360 description. For instance, in the example below, each media behaves as 361 if it were given a `recvonly' attribute. 363 An example SDP description is: 365 v=0 366 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 367 s=SDP Seminar 368 i=A Seminar on the session description protocol 369 u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps 370 e=mjh@isi.edu (Mark Handley) 371 c=IN IP4 224.2.17.12/127 372 t=2873397496 2873404696 373 a=recvonly 374 m=audio 49170 RTP/AVP 0 375 m=video 51372 RTP/AVP 31 376 m=application 32416 udp wb 377 a=orient:portrait 379 Text records such as the session name and information are bytes strings 380 which may contain any byte with the exceptions of 0x00 (Nul), 0x0a 381 (ASCII newline) and 0x0d (ASCII carriage return). The sequence CRLF 382 (0x0d0a) is used to end a record, although parsers should be tolerant 383 and also accept records terminated with a single newline character. By 384 default these byte strings contain ISO-10646 characters in UTF-8 encod- 385 ing, but this default may be changed using the `charset' attribute. 387 Protocol Version 389 v=0 391 The ``v='' field gives the version of the Session Description Protocol. 392 There is no minor version number. 394 Origin 396 o=
397
399 The ``o='' field gives the originator of the session (their username and 400 the address of the user's host) plus a session id and session version 401 number. is the user's login on the originating host, or it 402 is ``-'' if the originating host does not support the concept of user 403 ids. must not contain spaces. is a numeric 404 string such that the tuple of , , , 405
and
form a globally unique identifier for the 406 session. The method of session id allocation is up to the creating 407 tool, but it has been suggested that a Network Time Protocol (NTP) 408 timestamp be used to ensure uniqueness [1]. is a version 409 number for this announcement. It is needed for proxy announcements to 410 detect which of several announcements for the same session is the most 411 recent. Again its usage is up to the creating tool, so long as is increased when a modification is made to the session data. 413 Again, it is recommended (but not mandatory) that an NTP timestamp is 414 used. is a text string giving the type of network. Ini- 415 tially ``IN'' is defined to have the meaning ``Internet''.
is a text string giving the type of the address that follows. 417 Initially ``IP4'' and ``IP6'' are defined.
is the globally 418 unique address of the machine from which the session was created. For 419 an address type of IP4, this is the dotted-decimal representation of the 420 IP version 4 address of the machine. For an address type of IP6, this 421 is the compressed textual representation of the IP version 6 address of 422 the machine. 424 In general, the ``o='' field serves as a globally unique identifier for 425 this version of this session description, and the subfields excepting 426 the version taken together identify the session irrespective of any 427 modifications. 429 Session Name 431 s= 433 The ``s='' field is the session name. There must be one and only one 434 ``s='' field per session description, and it must contain ISO 10646 435 characters (but see also the `charset' attribute below). 437 Session and Media Information 439 i= 441 The ``i='' field is information about the session. There may be at most 442 one session-level ``i='' field per session description, and at most one 443 ``i='' field per media. Although it may be omitted, this is discouraged 444 for session announcements, and user interfaces for composing sessions 445 should require text to be entered. If it is present it must contain ISO 446 10646 characters (but see also the `charset' attribute below). 448 A single ``i='' field can also be used for each media definition. In 449 media definitions, ``i='' fields are primarily intended for labeling 450 media streams. As such, they are most likely to be useful when a single 451 session has more than one distinct media stream of the same media type. 452 An example would be two different whiteboards, one for slides and one 453 for feedback and questions. 455 URI 456 u= 458 o A URI is a Universal Resource Identifier as used by WWW clients 460 o The URI should be a pointer to additional information about the 461 conference 463 o This field is optional, but if it is present it should be specified 464 before the first media field 466 o No more than one URI field is allowed per session description 468 Email Address and Phone Number 470 e= 471 p= 473 o These specify contact information for the person responsible for 474 the conference. This is not necessarily the same person that 475 created the conference announcement. 477 o Either an email field or a phone field must be specified. Addi- 478 tional email and phone fields are allowed. 480 o If these are present, they should be specified before the first 481 media field. 483 o More than one email or phone field can be given for a session 484 description. 486 o Phone numbers should be given in the conventional international 487 format - preceded by a ``+'' and the international country code. 488 There must be a space or a hyphen (``-'') between the country code 489 and the rest of the phone number. Spaces and hyphens may be used to 490 split up a phone field to aid readability if desired. For example: 492 p=+44-171-380-7777 or p=+1 617 253 6011 494 o Both email addresses and phone numbers can have an optional free 495 text string associated with them, normally giving the name of the 496 person who may be contacted. This should be enclosed in parenthesis 497 if it is present. For example: 499 e=mjh@isi.edu (Mark Handley) 500 The alternative RFC822 name quoting convention is also allowed for 501 both email addresses and phone numbers. For example, 503 e=Mark Handley 505 The free text string should be in the ISO-10646 character set with 506 UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if 507 the appropriate charset session-level attribute is set. 509 Connection Data 511 c=
513 The ``c='' field contains connection data. 515 A session announcement must contain one ``c='' field in each media 516 description (see below) or a ``c='' field at the session-level. It may 517 contain a session-level ``c='' field and one additional ``c='' field per 518 media description, in which case the per-media values override the 519 session-level settings for the relevant media. 521 The first sub-field is the network type, which is a text string giving 522 the type of network. Initially ``IN'' is defined to have the meaning 523 ``Internet''. 525 The second sub-field is the address type. This allows SDP to be used 526 for sessions that are not IP based. Currently only IP4 is defined. 528 The third sub-field is the connection address. Optional extra sub- 529 fields may be added after the connection address depending on the value 530 of the
field. 532 For IP4 addresses, the connection address is defined as follows: 534 o Typically the connection address will be a class-D IP multicast 535 group address. If the conference is not multicast, then the connec- 536 tion address contains the unicast IP address of the expected data 537 source or data relay or data sink as determined by additional attri- 538 bute fields. It is not expected that unicast addresses will be 539 given in a session description that is communicated by a multicast 540 announcement, though this is not prohibited. 542 o Conferences using an IP multicast connection address must also have 543 a time to live (TTL) value present in addition to the multicast 544 address. The TTL and the address together define the scope with 545 which multicast packets sent in this conference will be sent. TTL 546 values must be in the range 0-255. 548 The TTL for the session is appended to the address using a slash as 549 a separator. An example is: 551 c=IN IP4 224.2.1.1/127 553 Hierarchical or layered encoding schemes are data streams where the 554 encoding from a single media source is split into a number of 555 layers. The receiver can choose the desired quality (and hence 556 bandwidth) by only subscribing to a subset of these layers. Such 557 layered encodings are normally transmitted in multiple multicast 558 groups to allow multicast pruning. This technique keeps unwanted 559 traffic from sites only requiring certain levels of the hierarchy. 560 For applications requiring multiple multicast groups, we allow the 561 following notation to be used for the connection address: 563 // 565 If the number of addresses is not given it is assumed to be one. 566 Multicast addresses so assigned are contiguously allocated above the 567 base address, so that, for example: 569 c=IN IP4 224.2.1.1/127/3 571 would state that addresses 224.2.1.1, 224.2.1.2 and 224.2.1.3 are to 572 be used at a ttl of 127. This is semantically identical to includ- 573 ing multiple ``c='' lines in a media description: 575 c=IN IP4 224.2.1.1/127 576 c=IN IP4 224.2.1.2/127 577 c=IN IP4 224.2.1.3/127 579 Multiple addresses or ``c='' lines can only be specified on a per- 580 media basis, and not for a session-level ``c='' field. 582 It is illegal for the slash notation described above to be used for 583 IP unicast addresses. 585 Bandwidth 587 b=: 589 o This specifies the proposed bandwidth to be used by the session or 590 media, and is optional. 592 o is in kilobits per second 593 o is a single alphanumeric word giving the meaning of the 594 bandwidth figure. 596 o Two modifiers are initially defined: 598 CT Conference Total: An implicit maximum bandwidth is associated with 599 each TTL on the Mbone or within a particular multicast administra- 600 tive scope region (the Mbone bandwidth vs. TTL limits are given in 601 the MBone FAQ). If the bandwidth of a session or media in a ses- 602 sion is different from the bandwidth implicit from the scope, a 603 `b=CT:...' line should be supplied for the session giving the pro- 604 posed upper limit to the bandwidth used. The primary purpose of 605 this is to give an approximate idea as to whether two or more 606 conferences can co-exist simultaneously. 608 AS Application-Specific Maximum: The bandwidth is interpreted to be 609 application-specific, i.e., will be the application's concept of 610 maximum bandwidth. Normally this will coincide with what is set 611 on the application's ``maximum bandwidth'' control if applicable. 613 Note that CT gives a total bandwidth figure for all the media at all 614 sites. AS gives a bandwidth figure for a single media at a single 615 site, although there may be many sites sending simultaneously. 617 o Extension Mechanism: Tool writers can define experimental bandwidth 618 modifiers by prefixing their modifier with ``X-''. For example: 620 b=X-YZ:128 622 SDP parsers should ignore bandwidth fields with unknown modifiers. 623 Modifiers should be alpha-numeric and, although no length limit is 624 given, they are recommended to be short. 626 Times, Repeat Times and Time Zones 628 t= 630 o ``t='' fields specify the start and stop times for a conference 631 session. Multiple ``t='' fields may be used if a session is active 632 at multiple irregularly spaced times; each additional ``t='' field 633 specifies an additional period of time for which the session will be 634 active. If the session is active at regular times, an ``r='' field 635 (see below) should be used in addition to and following a ``t='' 636 field - in which case the ``t='' field specifies the start and stop 637 times of the repeat sequence. 639 o The first and second sub-fields give the start and stop times for 640 the conference respectively. These values are the decimal 641 representation of Network Time Protocol (NTP) time values in seconds 642 [1]. To convert these values to UNIX time, subtract decimal 643 2208988800. 645 o If the stop-time is set to zero, then the session is not bounded, 646 though it will not become active until after the start-time. If the 647 start-time is also zero, the session is regarded as permanent. 649 User interfaces should strongly discourage the creation of unbounded 650 and permanent sessions as they give no information about when the 651 session is actually going to terminate, and so make scheduling dif- 652 ficult. 654 The general assumption may be made, when displaying unbounded ses- 655 sions that have not timed out to the user, that an unbounded session 656 will only be active until half an hour from the current time or the 657 session start time, whichever is the later. If behaviour other than 658 this is required, an end-time should be given and modified as 659 appropriate when new information becomes available about when the 660 session should really end. 662 Permanent sessions may be shown to the user as never being active 663 unless there are associated repeat times which state precisely when 664 the session will be active. In general, permanent sessions should 665 not be created for any session expected to have a duration of less 666 than 2 months, and should be discouraged for sessions expected to 667 have a duration of less than 6 months. 669 r= 671 o ``r='' fields specify repeat times for a session. For example, if 672 a session is active at 10am on Monday and 11am on Tuesday for one 673 hour each week for three months, then the in the 674 corresponding ``t='' field would be the NTP representation of 10am 675 on the first Monday, the would be 1 week, the 676 would be 1 hour, and the offsets would be zero and 677 25 hours. The corresponding ``t='' field stop time would be the NTP 678 representation of the end of the last session three months later. By 679 default all fields are in seconds, so the ``r='' and ``t='' fields 680 might be: 682 t=3034423619 3042462419 683 r=604800 3600 0 90000 685 To make announcements more compact, times may also be given in 686 units of days, hours or minutes. The syntax for these is a number 687 immediately followed by a single case-sensitive character. 689 Fractional units are not allowed - a smaller unit should be used 690 instead. The following unit specification characters are allowed: 692 d - days (86400 seconds) 693 h - minutes (3600 seconds) 694 m - minutes (60 seconds) 695 s - seconds (allowed for completeness but not recommended) 697 Thus, the above announcement could also have been written: 699 r=7d 1h 0 25h 701 Monthly and yearly repeats cannot currently be directly specified 702 with a single SDP repeat time - instead separate "t" fields should 703 be used to explicitly list the session times. 705 z= .... 707 o To schedule a repeated session which spans a change from daylight- 708 saving time to standard time or vice-versa, it is necessary to 709 specify offsets from the base repeat times. This is required because 710 different time zones change time at different times of day, dif- 711 ferent countries change to or from daylight time on different dates, 712 and some countries do not have daylight saving time at all. 714 Thus in order to schedule a session that is at the same time winter 715 and summer, it must be possible to specify unambiguously by whose 716 time zone a session is scheduled. To simplify this task for 717 receivers, we allow the sender to specify the NTP time that a time 718 zone adjustment happens and the offset from the time when the ses- 719 sion was first scheduled. The ``z'' field allows the sender to 720 specify a list of these adjustment times and offsets from the base 721 time. 723 An example might be: 725 z=2882844526 -1h 2898848070 0 727 This specifies that at time 2882844526 the time base by which the 728 session's repeat times are calculated is shifted back by 1 hour, and 729 that at time 2898848070 the session's original time base is 730 restored. Adjustments are always relative to the specified start 731 time - they are not cumulative. 733 o If a session is likely to last several years, it is expected that 734 the session announcement will be modified periodically rather than 735 transmit several years worth of adjustments in one announcement. 737 Encryption Keys 739 k= 740 k=: 742 o The session description protocol may be used to convey encryption 743 keys. A key field is permitted before the first media entry (in 744 which case it applies to all media in the session), or for each 745 media entry as required. 747 o The format of keys and their usage is outside the scope of this 748 document, but see [3]. 750 o The method indicates the mechanism to be used to obtain a usable 751 key by external means, or from the encoded encryption key given. 752 The following methods are defined: 754 k=clear: 755 The encryption key (as described in [3] for RTP media streams 756 under the AV profile) is included untransformed in this key 757 field. 759 k=base64: 760 The encryption key (as described in [3] for RTP media streams 761 under the AV profile) is included in this key field but has been 762 base64 encoded because it includes characters that are prohi- 763 bited in SDP. 765 k=uri: 766 A Universal Resource Identifier as used by WWW clients is 767 included in this key field. The URI refers to the data contain- 768 ing the key, and may require additional authentication before 769 the key can be returned. When a request is made to the given 770 URI, the MIME content-type of the reply specifies the encoding 771 for the key in the reply. The key should not be obtained until 772 the user wishes to join the session to reduce synchronisation of 773 requests to the WWW server(s). 775 k=prompt 776 No key is included in this SDP description, but the session or 777 media stream referred to by this key field is encrypted. The 778 user should be prompted for the key when attempting to join the 779 session, and this user-supplied key should then be used to 780 decrypt the media streams. 782 Attributes 784 a= 785 a=: 787 Attributes are the primary means for extending SDP. Attributes may be 788 defined to be used as "session-level" attributes, "media-level" attri- 789 butes, or both. 791 A media description may have any number of attributes (``a='' fields) 792 which are media specific. These are refered to as "media-level" attri- 793 butes and add information about the media stream. Attribute fields can 794 also be added before the first media field; these "session-level" attri- 795 butes convey additional information that applies to the conference as a 796 whole rather than to individual media; an example might be the 797 conference's floor control policy. 799 Attribute fields may be of two forms: 801 o property attributes. A property attribute is simply of the form 802 ``a=''. These are binary attributes, and the presence of the 803 attribute conveys that the attribute is a property of the session. 804 An example might be ``a=recvonly''. 806 o value attributes. A value attribute is of the form 807 ``a=:''. An example might be that a whiteboard 808 could have the value attribute ``a=orient:landscape'' 810 Attribute interpretation depends on the media tool being invoked. Thus 811 receivers of session descriptions should be configurable in their 812 interpretation of announcements in general and of attributes in particu- 813 lar. 815 Attribute names must be in the US-ASCII subset of ISO-10646/UTF-8. 817 Attribute values are byte strings, and MAY use any byte value except 818 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute values are 819 to be interpreted as in ISO-10646 character set with UTF-8 encoding. 820 Unlike other text fields, attribute values are NOT normally affected by 821 the `charset' attribute as this would make comparisons against known 822 values problematic. However, when an attribute is defined, it can be 823 defined to be charset-dependent, in which case it's value should be 824 interpreted in the session charset rather than in ISO-10646. 826 Attributes that will be commonly used can be registered with IANA (see 827 Appendix B). Unregistered attributes should begin with "X-" to prevent 828 inadvertant collision with registered attributes. In either case, if an 829 attribute is received that is not understood, it should simply be 830 ignored by the receiver. 832 Media Announcements 834 m= 836 A session description may contain a number of media descriptions. Each 837 media description starts with an ``m='' field, and is terminated by 838 either the next ``m='' field or by the end of the session description. 839 A media field also has several sub-fields: 841 o The first sub-field is the media type. Currently defined media are 842 ``audio'', ``video'', ``application'', ``data'' and ``control'', 843 though this list may be extended as new communication modalities 844 emerge (e.g., telepresense). The difference between ``application'' 845 and ``data'' is that the former is a media flow such as whiteboard 846 information, and the latter is bulk-data transfer such as multicast- 847 ing of program executables which will not typically be displayed to 848 the user. ``control'' is used to specify an additional conference 849 control channel for the session. 851 o The second sub-field is the transport port to which the media 852 stream will be sent. The meaning of the transport port depends on 853 the network being used as specified in the relevant ``c'' field and 854 on the transport protocol defined in the third sub-field. Other 855 ports used by the media application (such as the RTCP port, see [2]) 856 should be derived algorithmically from the base media port. 858 Note: For transports based on UDP, the value should be in the range 859 1024 to 65535 inclusive. For RTP compliance it should be an even 860 number. 862 For applications where hierarchically encoded streams are being sent 863 to a unicast address, it may be necessary to specify multiple tran- 864 sport ports. This is done using a similar notation to that used for 865 IP multicast addresses in the ``c='' field: 867 m= / 869 In such a case, the ports used depend on the transport protocol. 870 For RTP, only the even ports are used for data and the corresponding 871 one-higher odd port is used for RTCP. For example: 873 m=video 49170/2 RTP/AVP 31 875 would specify that ports 49170 and 49171 form one RTP/RTCP pair and 876 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the tran- 877 sport protocol and 31 is the format (see below). 879 It is illegal for both multiple addresses to be specified in the 880 ``c='' field and for multiple ports to be specified in the ``m='' 881 field in the same session description. 883 o The third sub-field is the transport protocol. The transport pro- 884 tocol values are dependent on the address-type field in the ``c='' 885 fields. Thus a ``c='' field of IP4 defines that the transport pro- 886 tocol runs over IP4. For IP4, it is normally expected that most 887 media traffic will be carried as RTP over UDP. The following tran- 888 sport protocols are preliminarily defined, but may be extended 889 through registration of new protocols with IANA: 891 - RTP/AVP - the IETF's Realtime Transport Protocol using the 892 Audio/Video profile carried over UDP. 894 - udp - User Datagram Protocol 896 If an application uses a single combined proprietary media format 897 and transport protocol over UDP, then simply specifying the tran- 898 sport protocol as udp and using the format field to distinguish the 899 combined protocol is recommended. If a transport protocol is used 900 over UDP to carry several distinct media types that need to be dis- 901 tinguished by a session directory, then specifying the transport 902 protocol and media format separately is necessary. RTP is an exam- 903 ple of a transport-protocol that carries multiple payload formats 904 that must be distinguished by the session directory for it to know 905 how to start appropriate tools, relays, mixers or recorders. 907 The main reason to specify the transport-protocol in addition to the 908 media format is that the same standard media formats may be carried 909 over different transport protocols even when the network protocol is 910 the same - a historical example is vat PCM audio and RTP PCM audio. 911 In addition, relays and monitoring tools that are transport- 912 protocol-specific but format-independent are possible. 914 For RTP media streams operating under the RTP Audio/Video Profile 915 [3], the protocol field is ``RTP/AVP''. Should other RTP profiles 916 be defined in the future, their profiles will be specified in the 917 same way. For example, the protocol field ``RTP/XYZ'' would specify 918 RTP operating under a profile whose short name is ``XYZ''. 920 o The fourth and subsequent sub-fields are media formats. For audio 921 and video, these will normally be a media payload type as defined in 922 the RTP Audio/Video Profile. 924 When a list of payload formats is given, this implies that all of 925 these formats may be used in the session, but the first of these 926 formats is the default format for the session. 928 For media whose transport protocol is not RTP or UDP the format 929 field is protocol specific. Such formats should be defined in an 930 additional specification document. 932 For media whose transport protocol is RTP, SDP can be used to pro- 933 vide a dynamic binding of media encoding to RTP payload type. The 934 encoding names in the RTP AV Profile do not specify unique audio 935 encodings (in terms of clock rate and number of audio channels), and 936 so they are not used directly in SDP format fields. Instead, the 937 payload type number should be used to specify the format for static 938 payload types and the payload type number along with additional 939 encoding information should be used for dynamically allocated pay- 940 load types. 942 An example of a static payload type is u-law PCM coded single chan- 943 nel audio sampled at 8KHz. This is completely defined in the RTP 944 Audio/Video profile as payload type 0, so the media field for such a 945 stream sent to UDP port 49232 is: 947 m=video 49232 RTP/AVP 0 949 An example of a dynamic payload type is 16 bit linear encoded stereo 950 audio sampled at 16KHz. If we wish to use dynamic RTP/AVP payload 951 type 98 for such a stream, additional information is required to 952 decode it: 954 m=video 49232 RTP/AVP 98 955 a=rtpmap:98 L16/16000/2 957 The general form of an rtpmap attribute is: 959 a=rtpmap: /[/] 961 For audio streams, may specify the number of 962 audio channels. This parameter may be omitted if the number of 963 channels is one provided no additional parameters are needed. 964 For video streams, no encoding parameters are currently specified. 966 Additional parameters may be defined in the future, but codec- 967 specific parameters should not be added. Parameters added to an 968 rtpmap attribute should only be those required for a session 969 directory to make the choice of appropriate media too to participate 970 in a session. Codec-specific parameters should be added in other 971 attributes. 973 Up to one rtpmap attribute can be defined for each media format 974 specified. Thus we might have: 976 m=audio 49230 RTP/AVP 96 97 98 977 a=rtpmap:96 L8/8000 978 a=rtpmap:97 L16/8000 979 a=rtpmap:98 L16/11025/2 981 RTP profiles that specify the use of dynamic payload types must 982 define the set of valid encoding names and/or a means to register 983 encoding names if that profile is to be used with SDP. 985 Experimental encoding formats can also be specified using rtpmap. 986 RTP formats that are not registered as standard format names must be 987 preceded by ``X-''. Thus a new experimental redundant audio stream 988 called GSMLPC using dynamic payload type 99 could be specified as: 990 m=video 49232 RTP/AVP 99 991 a=rtpmap:99 X-GSMLPC/8000 993 Such an experimental encoding requires that any site wishing to 994 receive the media stream has relevant configured state in its ses- 995 sion directory to know which tools are appropriate. 997 Note that RTP audio formats typically do not include information 998 about the number of samples per packet. If a non-default (as 999 defined in the RTP Audio/Video Profile) packetisation is required, 1000 the``ptime'' attribute is used as given below. 1002 For more details on RTP audio and video formats, see [3]. 1004 o Predefined formats for UDP protocol non-RTP media are as below. 1006 Application Formats: 1008 wb: LBL Whiteboard (transport: udp) 1010 nt: UCL Network Text Editor (transport: udp) 1012 Suggested Attributes 1013 The following attributes are suggested. Since application writers may 1014 add new attributes as they are required, this list is not exhaustive. 1016 a=cat: 1017 This attribute gives the dot-separated hierarchical category of the 1018 session. This is to enable a receiver to filter unwanted sessions 1019 by category. It would probably have been a compulsory separate 1020 field, except for its experimental nature at this time. It is a 1021 session-level attribute, and is not dependent on charset. 1023 a=keywds: 1024 Like the cat attribute, this is to assist identifying wanted ses- 1025 sions at the receiver. This allows a receiver to select interesting 1026 session based on keywords describing the purpose of the session. It 1027 is a session-level attribute. It is a charset dependent attribute, 1028 meaning that its value should be interpreted in the charset speci- 1029 fied for the session description if one is specified, or by default 1030 in ISO 10646/UTF-8. 1032 a=tool: 1033 This gives the name and version number of the tool used to create 1034 the session description. It is a session-level attribute, and is 1035 not dependent on charset. 1037 a=ptime: 1038 This gives the length of time in milliseconds represented by the 1039 media in a packet. This is probably only meaningful for audio data. 1040 It should not be necessary to know ptime to decode RTP or vat audio, 1041 and it is intended as a recommendation for the 1042 encoding/packetisation of audio. It is a media attribute, and is 1043 not dependent on charset. 1045 a=recvonly 1046 This specifies that the tools should be started in receive-only mode 1047 where applicable. It can be either a session or media attribute, and 1048 is not dependent on charset. 1050 a=sendrecv 1051 This specifies that the tools should be started in send and receive 1052 mode. This is necessary for interactive conferences with tools such 1053 as wb which defaults to receive only mode. It can be either a ses- 1054 sion or media attribute, and is not dependent on charset. 1056 a=sendonly 1057 This specifies that the tools should be started in send-only mode. 1058 An example may be where a different unicast address is to be used 1059 for a traffic destination than for a traffic source. In such a case, 1060 two media descriptions may be use, one sendonly and one recvonly. It 1061 can be either a session or media attribute, but would normally only 1062 be used as a media attribute, and is not dependent on charset. 1064 a=orient: 1065 Normally this is only used in a whiteboard media specification. It 1066 specifies the orientation of a the whiteboard on the screen. It is 1067 a media attribute. Permitted values are `portrait', `landscape' and 1068 `seascape' (upside down landscape). It is not dependent on charset 1070 a=type: 1071 This specifies the type of the conference. Suggested values are 1072 `broadcast', `meeting', `moderated', `test' and `H332'. `recvonly' 1073 should be the default for `type:broadcast' sessions, `type:meeting' 1074 should imply `sendrecv' and `type:moderated' should indicate the use 1075 of a floor control tool and that the media tools are started so as 1076 to ``mute'' new sites joining the conference. 1078 Specifying the attribute type:H332 indicates that this loosely cou- 1079 pled session is part of a H.332 session as defined in the ITU H.332 1080 specification [10]. Media tools should be started `recvonly'. 1082 Specifying the attribute type:test is suggested as a hint that, 1083 unless explicitly requested otherwise, receivers can safely avoid 1084 displaying this session description to users. 1086 The type attribute is a session-level attribute, and is not depen- 1087 dent on charset. 1089 a=charset: 1090 This specifies the character set to be used to display the session 1091 name and information data. By default, the ISO-10646 character set 1092 in UTF-8 encoding is used. If a more compact representation is 1093 required, other character sets may be used such as ISO-8859-1 for 1094 Northern European languages. In particular, the ISO 8859-1 is 1095 specified with the following SDP attribute: 1097 a=charset:ISO-8859-1 1099 This is a session-level attribute; if this attribute is present, it 1100 must be before the first media field. The charset specified MUST be 1101 one of those registered with IANA, such as ISO-8859-1. The charac- 1102 ter set identifier is a US-ASCII string and MUST be compared against 1103 the IANA identifiers using a case-insensitive comparison. If the 1104 identifier is not recognised or not supported, all strings that are 1105 affected by it SHOULD be regarded as byte strings. 1107 Note that a character set specified MUST still prohibit the use of 1108 bytes 0x00 (Nul), 0x0A (LF) and 0x0d (CR). Character sets requiring 1109 the use of these characters MUST define a quoting mechanism that 1110 prevents these bytes appearing within text fields. 1112 a=sdplang: 1113 This can be a session level attribute or a media level attribute. 1114 As a session level attribute, it specifies the language for the ses- 1115 sion description. As a media level attribute, it specifies the 1116 language for any media-level SDP information field associated with 1117 that media. Multiple sdplang attributes can be provided either at 1118 session or media level if multiple languages if the session descrip- 1119 tion or media use multiple languages, in which case the order of the 1120 attributes indicates the order of importance of the various 1121 languages in the session or media from most important to least 1122 important. 1124 The sdplang attribute value must be a single RFC 1766 language tag 1125 in US-ASCII. It is not dependent on the charset attribute. An 1126 sdplang attribute SHOULD be specified when a session is of suffi- 1127 cient scope to cross geographic boundaries where the language of 1128 recipients cannot be assumed, or where the session is in a different 1129 language from the locally assumed norm. 1131 a=lang: 1132 This can be a session level attribute or a media level attribute. 1133 As a session level attribute, it specifies the default language for 1134 the session being described. As a media level attribute, it speci- 1135 fies the language for that media, overriding any session-level 1136 language specified. Multiple lang attributes can be provided either 1137 at session or media level if multiple languages if the session 1138 description or media use multiple languages, in which case the order 1139 of the attributes indicates the order of importance of the various 1140 languages in the session or media from most important to least 1141 important. 1143 The lang attribute value must be a single RFC 1766 language tag in 1144 US-ASCII. It is not dependent on the charset attribute. A lang 1145 attribute SHOULD be specified when a session is of sufficient scope 1146 to cross geographic boundaries where the language of recipients can- 1147 not be assumed, or where the session is in a different language from 1148 the locally assumed norm. 1150 a=framerate: 1151 This gives the maximum video frame rate in frames/sec. It is 1152 intended as a recommendation for the encoding of video data. 1153 Decimal representations of fractional values using the notation 1154 "." are allowed. It is a media attribute, is 1155 only defined for video media, and is not dependent on charset. 1157 a=quality: 1158 This gives a suggestion for the quality of the encoding as an 1159 integer value. 1161 The intention of the quality attribute for video is to specify a 1162 non-default trade-off between frame-rate and still-image quality. 1163 For video, the value in the range 0 to 10, with the following sug- 1164 gested meaning: 1166 10 - the best still-image quality the compression scheme can give. 1168 5 - the default behaviour given no quality suggestion. 1170 0 - the worst still-image quality the codec designer thinks is 1171 still usable. 1173 It is a media attribute, and is not dependent on charset. 1175 a=fmtp: 1176 This attribute allows parameters that are specific to a particular 1177 format to be conveyed in a way that SDP doesn't have to understand 1178 them. The format must be one of the formats specified for the 1179 media. Format-specific parameters may be any set of parameters 1180 required to be conveyed by SDP and given unchanged to the media tool 1181 that will use this format. 1183 It is a media attribute, and is not dependent on charset. 1185 6.1. Communicating Conference Control Policy 1187 There is some debate over the way conference control policy should be 1188 communicated. In general, the authors believe that an implicit declara- 1189 tive style of specifying conference control is desirable where possible. 1191 A simple declarative style uses a single conference attribute field 1192 before the first media field, possibly supplemented by properties such 1193 as `recvonly' for some of the media tools. This conference attribute 1194 conveys the conference control policy. An example might be: 1196 a=type:moderated 1197 In some cases, however, it is possible that this may be insufficient to 1198 communicate the details of an unusual conference control policy. If 1199 this is the case, then a conference attribute specifying external con- 1200 trol might be set, and then one or more ``media'' fields might be used 1201 to specify the conference control tools and configuration data for those 1202 tools. An example is an ITU H.332 session: 1204 ... 1205 c=IN IP4 224.5.6.7 1206 a=type:H332 1207 m=audio 49230 RTP/AVP 0 1208 m=video 49232 RTP/AVP 31 1209 m=application 12349 udp wb 1210 m=control 49234 H323 mc 1211 c=IN IP4 134.134.157.81 1213 In this example, a general conference attribute (type:H332) is specified 1214 stating that conference control will be provided by an external H.332 1215 tool, and a contact addresses for the H.323 session multipoint con- 1216 troller is given. 1218 In this document, only the declarative style of conference control 1219 declaration is specified. Other forms of conference control should 1220 specify an appropriate type attribute, and should define the implica- 1221 tions this has for control media. 1223 7. Security Considerations 1225 SDP is a session description format that describes multimedia sessions. 1226 A session description should not be trusted unless it has been obtained 1227 by an authenticated transport protocol from a trusted source. Many dif- 1228 ferent transport protocols may be used to distribute session descrip- 1229 tion, and the nature of the authentication will differ from transport to 1230 transport. 1232 One transport that will frequently be used to distribute session 1233 descriptions is the Session Announcement Protocol (SAP). SAP provides 1234 both encryption and authentication mechanisms but due to the nature of 1235 session announcements it is likely that there are many occasions where 1236 the originator of a session announcement cannot be authenticated because 1237 they are previously unknown to the receiver of the announcement and 1238 because no common public key infrastructure is available. 1240 On receiving a session description over an unauthenticated transport 1241 mechanism or from an untrusted party, software parsing the session 1242 should take a few precautions. Session description contain information 1243 required to start software on the receivers system. Software that 1244 parses a session description MUST not be able to start other software 1245 except that which is specifically configured as appropriate software to 1246 participate in multimedia sessions. It is normally considered INAP- 1247 PROPRIATE for software parsing a session description to start, on a 1248 user's system, software that is appropriate to participate in multimedia 1249 sessions, without the user first being informed that such software will 1250 be started and giving their consent. Thus a session description arriv- 1251 ing by session announcement, email, session invitation, or WWW page 1252 SHOULD not deliver the user into an {it interactive} multimedia session 1253 without the user being aware that this will happen. As it is not always 1254 simple to tell whether a session is interactive or not, applications 1255 that are unsure should assume sessions are interactive. 1257 In this specification, there are no attributes which would allow the 1258 recipient of a session description to be informed to start multimedia 1259 tools in a mode where they default to transmitting. Under some cir- 1260 cumstances it might be appropriate to define such attributes. If this 1261 is done an application parsing a session description containing such 1262 attributes SHOULD either ignore them, or inform the user that joining 1263 this session will result in the automatic transmission of multimedia 1264 data. The default behaviour for an unknown attribute is to ignore it. 1266 Session descriptions may be parsed at intermediate systems such as 1267 firewalls for the purposes of opening a hole in the firewall to allow 1268 the participation in multimedia sessions. It is considered INAPPROPRI- 1269 ATE for a firewall to open such holes for unicast data streams unless 1270 the session description comes in a request from inside the firewall. 1272 For multicast sessions, it is likely that local administrators will 1273 apply their own policies, but the exclusive use of "local" or "site- 1274 local" administrative scope within the firewall and the refusal of the 1275 firewall to open a hole for such scopes will provide separation of glo- 1276 bal multicast sessions from local ones. 1278 Appendix A: SDP Grammar 1280 This appendix provides an Augmented BNF grammar for SDP. 1282 announcement ::= proto-version 1283 origin-field 1284 session-name-field 1285 information-field 1286 uri-field 1287 email-fields 1288 phone-fields 1289 connection-field 1290 bandwidth-fields 1291 time-fields 1292 key-field 1293 attribute-fields 1294 media-descriptions 1296 proto-version ::= "v=" 1*(DIGIT) CRLF 1297 ;this draft describes version 0 1299 origin-field ::= "o=" username space 1300 sess-id space sess-version space 1301 nettype space addrtype space 1302 addr CRLF 1304 session-name-field ::= "s=" text CRLF 1306 information-field ::= ["i=" text CRLF] 1308 uri-field ::= ["u=" uri CRLF] 1310 email-fields ::= *("e=" email-address CRLF) 1312 phone-fields ::= *("p=" phone-number CRLF) 1314 connection-field ::= ["c=" nettype space addrtype space 1315 connection-address CRLF] 1316 ;a connection field must be present 1317 ;in every media description or at the 1318 ;session-level 1320 bandwidth-fields ::= *("b=" bwtype ":" bandwidth CRLF) 1321 time-fields ::= 1*( "t=" start-time space stop-time 1322 *(CRLF repeat-fields) CRLF) 1323 [zone-adjustments CRLF] 1325 repeat-fields ::= "r=" repeat-interval space typed-time 1326 1*(space typed-time) 1328 zone-adjustments ::= time space [``-''] typed-time 1329 *(space time space [``-''] typed-time) 1331 key-field ::= ["k=" key-type CRLF] 1333 key-type ::= "prompt" | 1334 "clear:" key-data | 1335 "base64:" key-data | 1336 "uri:" uri 1338 key-data ::= email-safe | "~" | " 1340 attribute-fields ::= *("a=" attribute CRLF) 1342 media-descriptions ::= *( media-field 1343 information-field 1344 *(connection-field) 1345 bandwidth-fields 1346 key-field 1347 attribute-fields ) 1349 media-field ::= "m=" media space port ["/" integer] 1350 space proto (space fmt)+ CRLF 1352 media ::= 1*(alpha-numeric) 1353 ;typically "audio", "video", "application" 1354 ;or "data" 1355 fmt ::= 1*(alpha-numeric) 1356 ;typically an RTP payload type for audio 1357 ;and video media 1359 proto ::= 1*(alpha-numeric) 1360 ;typically "RTP/AVP" or "udp" for IP4 1362 port ::= 1*(DIGIT) 1363 ;should in the range "1024" to "65535" inclusive 1364 ;for UDP based media 1366 attribute ::= (att-field ":" att-value) | att-field 1368 att-field ::= 1*(alpha-numeric) 1370 att-value ::= byte-string 1372 sess-id ::= 1*(DIGIT) 1373 ;should be unique for this originating username/host 1375 sess-version ::= 1*(DIGIT) 1376 ;0 is a new session 1378 connection-address ::= multicast-address 1379 | unicast-address 1381 multicast-address ::= 1382 3*(decimal_uchar ".") decimal_uchar "/" ttl 1383 [ "/" integer ] 1384 ;multicast addresses may be in the range 1385 ;224.0.0.0 to 239.255.255.255 1386 ttl ::= decimal_uchar 1388 start-time ::= time | "0" 1390 stop-time ::= time | "0" 1392 time ::= POS-DIGIT 9*(DIGIT) 1393 ;sufficient for 2 more centuries 1395 repeat-interval ::= typed-time 1397 typed-time ::= 1*(DIGIT) [fixed-len-time-unit] 1399 fixed-len-time-unit ::= ``d'' | ``h'' | ``m'' | ``s'' 1401 bwtype ::= 1*(alpha-numeric) 1403 bandwidth ::= 1*(DIGIT) 1405 username ::= safe 1406 ;pretty wide definition, but doesn't include space 1408 email-address ::= email | email "(" email-safe ")" | 1409 email-safe "<" email ">" 1411 email ::= ;defined in RFC822 1413 uri::= ;defined in RFC1630 1415 phone-number ::= phone | phone "(" email-safe ")" | 1416 email-safe "<" phone ">" 1418 phone ::= "+" POS-DIGIT 1*(space | "-" | DIGIT) 1419 ;there must be a space or hyphen between the 1420 ;international code and the rest of the number. 1422 nettype ::= "IN" 1423 ;list to be extended 1425 addrtype ::= "IP4" | "IP6" 1426 ;list to be extended 1428 addr ::= unicast-address 1430 unicast-address ::= IP4-address | IP6-address 1432 IP4-address ::= b1 "." decimal_uchar "." decimal_uchar "." b4 1433 b1 ::= decimal_uchar 1434 ;less than "224"; not "0" or "127" 1435 b4 ::= decimal_uchar 1436 ;not "0" 1438 IP6-address ::= ;to be defined 1440 text ::= byte-string 1441 ;default is to interpret this as IS0-10646 UTF8 1442 ;ISO 8859-1 requires a "a=charset:ISO-8859-1" 1443 ;session-level attribute to be used 1445 byte-string ::= 1*(0x01..0x09|0x0b|0x0c|0x0e..0xff) 1446 ;any byte except NUL, CR or LF 1448 decimal_uchar ::= DIGIT 1449 | POS-DIGIT DIGIT 1450 | (1 2*(DIGIT)) 1451 | (2 (0|1|2|3|4) DIGIT) 1452 | (2 5 (0|1|2|3|4|5)) 1454 integer ::= POS-DIGIT *(DIGIT) 1456 alpha-numeric ::= ALPHA | DIGIT 1458 DIGIT ::= 0 | POS-DIGIT 1459 POS-DIGIT ::= 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 1461 ALPHA ::= a | b | c | d | e | f | g | h | i | j | k | 1462 l | m | n | o | p | q | r | s | t | u | v | 1463 w | x | y | z | A | B | C | D | E | F | G | 1464 H | I | J | K | L | M | N | O | P | Q | R | 1465 S | T | U | V | W | X | Y | Z 1467 email-safe ::= safe | space | tab 1469 safe ::= alpha-numeric | 1470 "'" | "'" | "-" | "." | "/" | ":" | "?" | """ | 1471 "#" | "$" | "&" | "*" | ";" | "=" | "@" | "[" | 1472 "]" | "^" | "_" | "`" | "{" | "|" | "}" | "+" | 1473 "~" | " 1475 space ::= ;ascii code 32 1476 tab ::= ;ascii code 9 1477 CRLF ::= ;ascii code 13 followed by ascii code 10 1478 Appendix B: Guidelines for registering SDP names with IANA 1480 There are five field names that may be registered with IANA. Using the 1481 terminology in the SDP specification BNF, they are "media", "proto", 1482 "fmt", "att-field" and "bwtype". 1484 "media" (eg, audio, video, application, data). 1486 The set of media is intended to be small and not to be extended 1487 except under rare circumstances. The same rules should apply for 1488 media names as for top-level MIME content types, and where possible 1489 the same name should be registered for SDP as for MIME. For media 1490 other than existing MIME top-level content types, a standards-track 1491 RFC MUST be produced for a new top-level content type to be 1492 registered, and the registration MUST provide good justification why 1493 no existing media name is appropriate. 1495 "proto" 1497 In general this should be an IETF standards-track transport protocol 1498 identifier such as RTP/AVP (rfc 1889 under the rfc 1890 profile). 1500 However, people will want to invent their own proprietary transport 1501 protocols. Some of these should be registered as a "fmt" using 1502 "udp" as the protocol and some of which probably can't be. 1504 Where the protocol and the application are intimately linked, such 1505 as with the LBL whiteboard wb which used a proprietary and special 1506 purpose protocol over UDP, the protocol name should be "udp" and the 1507 format name that should be registered is "wb". The rules for for- 1508 mats (see below) apply to such registrations. 1510 Where the proprietary transport protocol really carries many dif- 1511 ferent data formats, it is possible to register a new protocol name 1512 with IANA. In such a case, an RFC MUST be produced describing the 1513 protocol and referenced in the registration. Such an RFC MAY be 1514 informational, although it is preferable if it is standards-track. 1516 "fmt" 1518 The format namespace is dependent on the context of the "proto" 1519 field, so a format cannot be registered without specifying one or 1520 more transport protocols that it applies to. 1522 Formats cover all the possible encodings that might want to be tran- 1523 sported in a multimedia session. 1525 For RTP formats that have been assigned static payload types, the 1526 payload type number is used. For RTP formats using a dynamic pay- 1527 load type number, the dynamic payload type number is given as the 1528 format and an additional "rtpmap" attribute specifies the format and 1529 parameters. 1531 For non-RTP formats, any unregistered format name may be registered. 1532 If there is a suitable mapping from a MIME subtype to the format, 1533 then the MIME subtype name should be registered. If there is no 1534 suitable mapping from a MIME subtype, a new name should be 1535 registered. In either case, unless there are strong reasons not to 1536 do so, a standards-track RFC SHOULD be produced describing the for- 1537 mat and this RFC SHOULD be referenced in the registration. 1539 "att-field" (Attribute names) 1541 Attribute field names MAY be registered with IANA, although this is 1542 not compulsory, and unknown attributes are simply ignored. 1544 When an attribute is registered, it must be accompanied by a brief 1545 specification stating the following: 1547 o contact name, email address and telephone number 1549 o attribute-name (as it will appear in SDP) 1551 o long-form attribute name in English 1553 o type of attribute (session level, media level, or both) 1555 o a one paragraph explanation of the purpose of the attribute. 1557 o a specification of appropriate attribute values for this 1558 attribute. 1560 IANA will not sanity check such attribute registrations except to 1561 ensure that they do not clash with existing registrations. 1563 Although the above is the minimum that IANA will accept, if the 1564 attribute is expected to see widespread use and interoperability is 1565 an issue, authors are encouraged to produce a standards-track RFC 1566 that specifies the attribute more precisely. 1568 Submitters of registrations should ensure that the specification is 1569 in the spirit of SDP attributes, most notably that the attribute is 1570 platform independent in the sense that it makes no implicit assump- 1571 tions about operating systems and does not name specific pieces of 1572 software in a manner that might inhibit interoperability. 1574 "bwtype" (bandwidth specifiers) 1576 A proliferation of bandwidth specifiers is strongly discouraged. 1578 New bandwidth specifiers may be registered with IANA. The submis- 1579 sion MUST reference a standards-track RFC specifying the semantics 1580 of the bandwidth specifier precisely, and indicating when it should 1581 be used, and why the existing registered bandwidth specifiers do not 1582 suffice. 1584 Registration Procedure 1586 To register a name the above guidelines should be followed regarding the 1587 required level of documentation that is required. The registration 1588 itself should be sent to IANA. Attribute registrations should include 1589 the information given above. Other registrations should include the 1590 following additional information: 1592 o contact name, email address and telephone number 1594 o name being registered (as it will appear in SDP) 1596 o long-form name in English 1598 o type of name ("media", "proto", "fmt" or "bwtype") 1600 o a one paragraph explanation of the purpose of the registered name. 1602 o a reference to the specification (eg RFC number) of the registered 1603 name. 1605 IANA may refer any registration to the IESG or to any appropriate IETF 1606 working group for review, and may request revisions to be made before a 1607 registration will be made. 1609 Appendix C: Authors' Addresses 1611 Mark Handley 1612 Information Sciences Institute 1613 c/o MIT Laboratory for Computer Science 1614 545 Technology Square 1615 Cambridge, MA 02139 1616 United States 1617 electronic mail: mjh@isi.edu 1619 Van Jacobson 1620 MS 46a-1121 1621 Lawrence Berkeley Laboratory 1622 Berkeley, CA 94720 1623 United States 1624 electronic mail: van@ee.lbl.gov 1626 Acknowledgments 1628 Many people in the IETF MMUSIC working group have made comments and 1629 suggestions contributing to this document. In particular, we would like 1630 to thank Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross 1631 Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann and Steve Hanna. 1633 References 1635 [1] D. Mills, ``Network Time Protocol version 2 specification and imple- 1636 mentation", RFC1119, 1st Sept 1989. 1638 [2] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, ``RTP: A Tran- 1639 sport Protocol for Real-Time Applications'', RFC 1889 1641 [3] H. Schulzrinne, ``RTP Profile for Audio and Video Conferences with 1642 Minimal Control'', RFC 1890 1644 [4] M. Handley, ``SAP - Session Announcement Protocol'', INTERNET-DRAFT, 1645 November 25th 1996. 1647 [5] V. Jacobson, S. McCanne, ``vat - X11-based audio teleconferencing 1648 tool'' vat manual page, Lawrence Berkeley Laboratory, 1994. 1650 [6] ``The Unicode Standard, Version 1.1'': Version 1.0, Volume 1 (ISBN 1651 0-201-56788-1), Version 1.0, Volume 2 (ISBN 0-201-60845-6), and "Unicode 1652 Technical Report #4, The Unicode Standard, Version 1.1" (available from 1653 The Unicode Consortium, and soon to be published by Addison- Wesley). 1655 [7] ISO/IEC 10646-1:1993(E) Information Technology--Universal Multiple- 1656 octet Coded Character Set (UCS). 1658 [8] D. Goldsmith, M. Davis, ``Using Unicode with MIME'', RFC1641, July 1659 1994 1661 [9] F. Yergeau, ``UTF-8, a transformation format of Unicode and ISO 1662 10646'', RFC 2044, Oct 30th 1996 1664 [10] ITU-T Recommendation H.332 (1998): "Multimedia Terminal for Receiv- 1665 ing Internet-based H.323 Conferences", ITU, Geneva. 1667 [11] M. Handley, E. Schooler, H. Schulzrinne, ``Session Initiation Pro- 1668 tocol (SIP)'' Internet Draft, Nov 1997. 1670 [12] H. Schulzrinne, A. Rao, R. Lanphier, ``Real Time Streaming Protocol 1671 (RTSP)'' Internet Draft, Jan 1998.