--- 1/draft-ietf-mmusic-sdp-new-14.txt 2006-02-05 00:28:46.000000000 +0100 +++ 2/draft-ietf-mmusic-sdp-new-15.txt 2006-02-05 00:28:46.000000000 +0100 @@ -1,21 +1,21 @@ Network Working Group M. Handley Internet-Draft UCL Obsoletes: 2327, 3266 (if V. Jacobson approved) Packet Design -Expires: March 4, 2004 C. Perkins +Expires: April 26, 2004 C. Perkins University of Glasgow - September 4, 2003 + October 27, 2003 SDP: Session Description Protocol - draft-ietf-mmusic-sdp-new-14.txt + draft-ietf-mmusic-sdp-new-15.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. @@ -23,99 +23,95 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on March 4, 2004. + This Internet-Draft will expire on April 26, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . 4 - 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . 5 - 3.1 Multicast Announcement . . . . . . . . . . . . . . . . . . . 5 - 3.2 Session Initiation . . . . . . . . . . . . . . . . . . . . . 5 - 3.3 Streaming media . . . . . . . . . . . . . . . . . . . . . . 5 - 3.4 Email and the World Wide Web . . . . . . . . . . . . . . . . 5 - 4. Requirements and Recommendations . . . . . . . . . . . . . . 6 - 4.1 Media Information . . . . . . . . . . . . . . . . . . . . . 7 - 4.2 Timing Information . . . . . . . . . . . . . . . . . . . . . 7 - 4.3 Private Sessions . . . . . . . . . . . . . . . . . . . . . . 8 - 4.4 Obtaining Further Information about a Session . . . . . . . 8 - 4.5 Categorisation . . . . . . . . . . . . . . . . . . . . . . . 8 - 4.6 Internationalization . . . . . . . . . . . . . . . . . . . . 8 - 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . 8 - 5.1 Protocol Version ("v=") . . . . . . . . . . . . . . . . . . 11 - 5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . . 11 - 5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . . . 12 - 5.4 Session and Media Information ("i=") . . . . . . . . . . . . 12 - 5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . . 13 - 5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . . 14 - 5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . . 16 - 5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . . 17 - 5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . . 18 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . 3 + 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . 4 + 3.1 Multicast Announcement . . . . . . . . . . . . . . . . . . . 4 + 3.2 Session Initiation . . . . . . . . . . . . . . . . . . . . . 4 + 3.3 Streaming media . . . . . . . . . . . . . . . . . . . . . . 4 + 3.4 Email and the World Wide Web . . . . . . . . . . . . . . . . 4 + 4. Requirements and Recommendations . . . . . . . . . . . . . . 5 + 4.1 Media Information . . . . . . . . . . . . . . . . . . . . . 6 + 4.2 Timing Information . . . . . . . . . . . . . . . . . . . . . 6 + 4.3 Private Sessions . . . . . . . . . . . . . . . . . . . . . . 7 + 4.4 Obtaining Further Information about a Session . . . . . . . 7 + 4.5 Categorisation . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.6 Internationalization . . . . . . . . . . . . . . . . . . . . 7 + 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . 7 + 5.1 Protocol Version ("v=") . . . . . . . . . . . . . . . . . . 10 + 5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . . 10 + 5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . . . 11 + 5.4 Session and Media Information ("i=") . . . . . . . . . . . . 11 + 5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . . 12 + 5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . . 13 + 5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . . 15 + 5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . . 16 + 5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . . 17 5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . . . 18 - 5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . . . 19 + 5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . . . 18 5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . . . 20 5.14 Media Announcements ("m=") . . . . . . . . . . . . . . . . . 21 - 6. Suggested Attributes . . . . . . . . . . . . . . . . . . . . 25 + 6. Suggested Attributes . . . . . . . . . . . . . . . . . . . . 24 7. Communicating Conference Control Policy . . . . . . . . . . 30 - 8. Security Considerations . . . . . . . . . . . . . . . . . . 31 + 8. Security Considerations . . . . . . . . . . . . . . . . . . 30 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32 - 9.1 Media types ("media") . . . . . . . . . . . . . . . . . . . 32 - 9.2 Transport protocols ("proto") . . . . . . . . . . . . . . . 32 - 9.3 Media formats ("fmt") . . . . . . . . . . . . . . . . . . . 33 - 9.4 Attribute names ("att-field") . . . . . . . . . . . . . . . 33 - 9.5 Bandwidth specifiers ("bwtype") . . . . . . . . . . . . . . 34 - 9.6 Network types ("nettype") . . . . . . . . . . . . . . . . . 34 - 9.7 Address types ("addrtype") . . . . . . . . . . . . . . . . . 35 - 9.8 Registration Procedure . . . . . . . . . . . . . . . . . . . 35 - A. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 35 - B. Changes from RFC 2327 . . . . . . . . . . . . . . . . . . . 41 - C. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 42 + 9.1 The "application/sdp" media type . . . . . . . . . . . . . . 32 + 9.2 Registration of Parameters . . . . . . . . . . . . . . . . . 33 + A. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 36 + B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 41 Normative References . . . . . . . . . . . . . . . . . . . . 42 Informative References . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 43 - Intellectual Property and Copyright Statements . . . . . . . 45 + Intellectual Property and Copyright Statements . . . . . . . 44 1. Introduction + [Note to RFC Editor: All references to RFC XXXX should be replaced by + the RFC number of this document, when published.] + When initiating multimedia teleconferences, voice-over-IP calls, streaming video, or other real-time sessions, there is a requirement to convey media details, transport addresses, and other session description metadata to the participants. SDP provides a standard representation for such information, irrespective of how that information is transported. SDP is purely a format for session description - it does not incorporate a transport protocol, and is intended to use different transport protocols as - appropriate, including the Session Announcement Protocol [RFC2974], - Session Initiation Protocol [RFC3261], Real-Time Streaming Protocol - [RFC2326], electronic mail using the MIME extensions, and the - Hypertext Transport Protocol. + appropriate, including the Session Announcement Protocol [8], Session + Initiation Protocol [9], Real-Time Streaming Protocol [10], + electronic mail using the MIME extensions, and the Hypertext + Transport Protocol. SDP is intended to be general purpose so that it can be used in a wide range of network environments and applications. However, it is not intended to support negotiation of session content or media encodings: this is viewed as outside the scope of session description. 2. Glossary of Terms The following terms are used in this document, and have specific @@ -134,56 +130,55 @@ Session Announcement: A session announcement is a mechanism by which a session description is conveyed to users in a pro-active fashion, i.e., the session description was not explicitly requested by the user. Session Description: A well defined format for conveying sufficient information to discover and participate in a multimedia session. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. + document are to be interpreted as described in RFC 2119 [1]. 3. Examples of SDP Usage 3.1 Multicast Announcement In order to assist the advertisement of multicast multimedia conferences and other multicast sessions, and to communicate the relevant session setup information to prospective participants, a distributed session directory may be used. An instance of such a session directory periodically sends packets containing a description of the session to a well known multicast group. These advertisements are received by other session directories such that potential remote participants can use the session description to start the tools required to participate in the session. One protocol commonly used to implement such a distributed directory - is the Session Announcement Protocol, SAP [RFC2974]. SDP provides the + is the Session Announcement Protocol, SAP [8]. SDP provides the recommended session description format for such announcements. 3.2 Session Initiation - The Session Initiation Protocol, SIP [RFC3261] is an application - layer control protocol for creating, modifying and terminating - sessions such as Internet multimedia conferences, Internet telephone - calls and multimedia distribution. The SIP messages used to create - sessions carry session descriptions which allow participants to agree - on a set of compatible media types. These session descriptions are - commonly formatted using SDP. When used with SIP, the offer/answer - model [RFC3264] provides a limited framework for negotiation using - SDP. + The Session Initiation Protocol, SIP [9] is an application layer + control protocol for creating, modifying and terminating sessions + such as Internet multimedia conferences, Internet telephone calls and + multimedia distribution. The SIP messages used to create sessions + carry session descriptions which allow participants to agree on a set + of compatible media types. These session descriptions are commonly + formatted using SDP. When used with SIP, the offer/answer model [11] + provides a limited framework for negotiation using SDP. 3.3 Streaming media - The Real Time Streaming Protocol, RTSP [RFC2326], is an application- - level protocol for control over the delivery of data with real-time + The Real Time Streaming Protocol, RTSP [10], is an application- level + protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. An RTSP client and server negotiate an appropriate set of parameters for media delivery, partially using SDP syntax to describe those parameters. 3.4 Email and the World Wide Web Alternative means of conveying session descriptions include electronic mail and the World Wide Web. For both email and WWW @@ -289,21 +282,21 @@ This timing information is globally consistent, irrespective of local time zone or daylight saving time. 4.3 Private Sessions It is possible to create both public sessions and private sessions. SDP itself does not distinguish between these: private sessions are typically conveyed by encrypting the session description during distribution. The details of how encryption is performed are dependent on the mechanism used to convey SDP - e.g. mechanisms are - defined for SDP transported using SAP [RFC2974] and SIP [RFC3261]. + defined for SDP transported using SAP [8] and SIP [9]. If a session announcement is private it is possible to use that private announcement to convey encryption keys necessary to decode each of the media in a conference, including enough information to know which encryption scheme is used for each media. 4.4 Obtaining Further Information about a Session A session description should convey enough information to decide whether or not to participate in a session. SDP may include @@ -314,47 +307,54 @@ When many session descriptions are being distributed by SAP, or any other advertisement mechanism, it may be desirable to filter announcements that are of interest from those that are not. SDP supports a categorisation mechanism for sessions that is capable of being automated. 4.6 Internationalization The SDP specification recommends the use of the ISO 10646 character - sets in the UTF-8 encoding [RFC2279] to allow many different - languages to be represented. However, to assist in compact - representations, SDP also allows other character sets such as ISO - 8859-1 to be used when desired. Internationalization only applies to - free-text fields (session name and background information), and not - to SDP as a whole. + sets in the UTF-8 encoding [3] to allow many different languages to + be represented. However, to assist in compact representations, SDP + also allows other character sets such as ISO 8859-1 to be used when + desired. Internationalization only applies to free-text fields + (session name and background information), and not to SDP as a whole. 5. SDP Specification SDP session descriptions are entirely textual using the ISO 10646 character set in UTF-8 encoding. SDP field names and attribute names use only the US-ASCII subset of UTF-8, but textual fields and - attribute values MAY use the full ISO 10646 character set. The - textual form, as opposed to a binary encoding such as ASN.1 or XDR, - was chosen to enhance portability, to enable a variety of transports - to be used (e.g, session description in a MIME email message) and to - allow flexible, text-based toolkits (e.g., Tcl/Tk) to be used to - generate and to process session descriptions. However, since SDP may - be used in environments where the maximum permissable size of a - session description is limited (e.g. SAP announcements; SIP - transported in UDP), the encoding is deliberately compact. Also, - since announcements may be transported via very unreliable means or - damaged by an intermediate caching server, the encoding was designed - with strict order and formatting rules so that most errors would - result in malformed announcements which could be detected easily and - discarded. This also allows rapid discarding of encrypted - announcements for which a receiver does not have the correct key. + attribute values MAY use the full ISO 10646 character set. Field and + attribute values which use the full UTF-8 character set are never + directly compared, hence there is no requirement for UTF-8 + normalization. The textual form, as opposed to a binary encoding + such as ASN.1 or XDR, was chosen to enhance portability, to enable a + variety of transports to be used (e.g, session description in a MIME + email message) and to allow flexible, text-based toolkits (e.g., Tcl/ + Tk) to be used to generate and to process session descriptions. + However, since SDP may be used in environments where the maximum + permissable size of a session description is limited (e.g. SAP + announcements; SIP transported in UDP), the encoding is deliberately + compact. Also, since announcements may be transported via very + unreliable means or damaged by an intermediate caching server, the + encoding was designed with strict order and formatting rules so that + most errors would result in malformed announcements which could be + detected easily and discarded. This also allows rapid discarding of + encrypted announcements for which a receiver does not have the + correct key. + + An SDP session description may contain URIs which reference external + content in the "u=", "k=" and "a=" lines. These URIs may be + dereferenced in some cases, making the session description non-self + contained. An SDP session description consists of a number of lines of text of the form: = where MUST be exactly one case-significant character and is structured text whose format depends on . In general is either a number of fields delimited by a single space character, or a free format string. Whitespace MUST NOT be used @@ -376,37 +376,37 @@ Session description v= (protocol version) o= (owner/creator and session identifier). s= (session name) i=* (session information) u=* (URI of description) e=* (email address) p=* (phone number) c=* (connection information - not required if included in all media) - b=* (bandwidth information) + b=* (zero or more bandwidth information lines) One or more time descriptions (see below) z=* (time zone adjustments) k=* (encryption key) a=* (zero or more session attribute lines) Zero or more media descriptions (see below) Time description t= (time the session is active) r=* (zero or more repeat times) Media description m= (media name and transport address) i=* (media title) c=* (connection information - optional if included at session-level) - b=* (bandwidth information) + b=* (zero or more bandwidth information lines) k=* (encryption key) a=* (zero or more media attribute lines) The set of type letters is deliberately small and not intended to be extensible -- an SDP parser MUST completely ignore any announcement that contains a type letter that it does not understand. The attribute mechanism ("a=" described below) is the primary means for extending SDP and tailoring it to particular applications or media. Some attributes (the ones listed in this document) have a defined meaning but others may be added on an application-, media- or @@ -462,21 +462,21 @@ is the user's login on the originating host, or it is "-" if the originating host does not support the concept of user ids. MUST NOT contain spaces. is a numeric string such that the tuple of , , ,
and
form a globally unique identifier for the session. The method of session id allocation is up to the creating tool, but it has been suggested that a Network Time Protocol (NTP) format timestamp be - used to ensure uniqueness [RFC1305]. + used to ensure uniqueness [7]. is a version number for this announcement. It is needed for proxy announcements to detect which of several announcements for the same session is the most recent. Again its usage is up to the creating tool, so long as is increased when a modification is made to the session data. Again, it is RECOMMENDED (but not mandatory) that an NTP format timestamp is used. is a text string giving the type of network. Initially "IN" is defined to have the meaning "Internet". @@ -528,22 +528,22 @@ media definitions, "i=" fields are primarily intended for labeling media streams. As such, they are most likely to be useful when a single session has more than one distinct media stream of the same media type. An example would be two different whiteboards, one for slides and one for feedback and questions. 5.5 URI ("u=") u= - A URI is a Universal Resource Identifier as used by WWW clients. The - URI should be a pointer to additional information about the + A URI is a Universal Resource Identifier as used by WWW clients [4]. + The URI should be a pointer to additional information about the conference. This field is OPTIONAL, but if it is present it MUST be specified before the first media field. No more than one URI field is allowed per session description. 5.6 Email Address and Phone Number ("e=" and "p=") e= p= These specify contact information for the person responsible for the @@ -667,54 +666,56 @@ which is semantically equivalent to: c=IN IP6 FF15::101 c=IN IP6 FF15::102 c=IN IP6 FF15::103 (remembering that the TTL field is not present in IPv6 multicast). Multiple addresses or "c=" lines MAY be specified on a per-media - basis. They MUST NOT be specified for a session-level "c=" field. + basis only if they provide multicast addresses for different layers + in a hierarchical or layered encoding scheme. They MUST NOT be + specified for a session-level "c=" field. The slash notation described above MUST NOT be used for IP unicast addresses. 5.8 Bandwidth ("b=") b=: This specifies the proposed bandwidth to be used by the session or media, and is OPTIONAL. The is in kilobits per second by default. Modifiers MAY specify that alternative units are to be used (the modifiers defined in this memo use the default units). The is a single alphanumeric word giving the meaning of the bandwidth figure. Two modifiers are initially defined: - CT Conference Total - If the bandwidth of a session or media in a session is - different from the bandwidth implicit from the scope, a - "b=CT:..." line should be supplied for the session giving - the proposed upper limit to the bandwidth used. The primary - purpose of this is to give an approximate idea as to whether - two or more sessions can co-exist simultaneously. + CT If the bandwidth of a session or media in a session is different + from the bandwidth implicit from the scope, a "b=CT:..." line + should be supplied for the session giving the proposed upper limit + to the bandwidth used. The primary purpose of this is to give an + approximate idea as to whether two or more sessions can co-exist + simultaneously. When using the CT modifier with RTP, if several + RTP sessions are part of the conference, the conference total + refers to total bandwidth of all RTP sessions. - AS Application-Specific Maximum - The bandwidth is interpreted to be application-specific (it - will be the application's concept of maximum bandwidth). - Normally this will coincide with what is set on the - application's "maximum bandwidth" control if applicable. - For RTP based applications, AS gives the RTP "session - bandwidth" as defined in section 6.2 of [RFC1889]. + AS The bandwidth is interpreted to be application-specific (it will + be the application's concept of maximum bandwidth). Normally this + will coincide with what is set on the application's "maximum + bandwidth" control if applicable. For RTP based applications, AS + gives the RTP "session bandwidth" as defined in section 6.2 of + [12]. Note that CT gives a total bandwidth figure for all the media at all sites. AS gives a bandwidth figure for a single media at a single site, although there may be many sites sending simultaneously. Tool writers MAY define experimental bandwidth modifiers by prefixing their modifier with "X-". For example: b=X-YZ:128 @@ -732,22 +733,22 @@ "t=" fields MAY be used if a session is active at multiple irregularly spaced times; each additional "t=" field specifies an additional period of time for which the session will be active. If the session is active at regular times, an "r=" field (see below) should be used in addition to and following a "t=" field - in which case the "t=" field specifies the start and stop times of the repeat sequence. The first and second sub-fields give the start and stop times for the session respectively. These values are the decimal representation of - Network Time Protocol (NTP) time values in seconds [RFC1305]. To - convert these values to UNIX time, subtract decimal 2208988800. + Network Time Protocol (NTP) time values in seconds [7]. To convert + these values to UNIX time, subtract decimal 2208988800. NTP timestamps are 64 bit values which wrap sometime in the year 2036. Since SDP uses an arbitrary length decimal representation, this should not cause an issue (SDP timestamps will continue counting seconds since 1900, NTP will use the value modulo the 64 bit limit). If the stop-time is set to zero, then the session is not bounded, though it will not become active until after the start-time. If the start-time is also zero, the session is regarded as permanent. @@ -841,27 +842,38 @@ If a session is likely to last several years, it is expected that the session announcement will be modified periodically rather than transmit several years worth of adjustments in one announcement. 5.12 Encryption Keys ("k=") k= k=: If transported over a secure and trusted channel, the session - description protocol MAY be used to convey encryption keys. A key - field is permitted before the first media entry (in which case it - applies to all media in the session), or for each media entry as - required. + description protocol MAY be used to convey encryption keys. A simple + mechanism for key exchange is provided by the key field ("k=") + although this is primarily supported for compatibility with older + implementations and its use is NOT RECOMMENDED. Work is in progress + to define new key exchange mechanisms for use with SDP [17][16] and + it is expected that new applications will use those mechanisms. - The format of keys and their usage is outside the scope of this - document, but see [RFC1890] for an example. + A key field is permitted before the first media entry (in which case + it applies to all media in the session), or for each media entry as + required. The format of keys and their usage is outside the scope of + this document, and the key field provides no way to indicate the + encryption algorithm to be used, key type, or other information about + the key: this is assumed to be provided by the higher-level protocol + using SDP. If there is a need to convey this information within SDP, + the extensions mentioned previously SHOULD be used. Many security + protocols require two keys, one for confidentiality and another for + integrity. This specification does not support the transfer of two + keys. The method indicates the mechanism to be used to obtain a usable key by external means, or from the encoded encryption key given. The following methods are defined: k=clear: The encryption key is included untransformed in this key field. This method MUST NOT be used unless it can be guaranteed that the SDP is conveyed over a secure channel. @@ -870,36 +883,44 @@ The encryption key is included in this key field but has been base64 encoded because it includes characters that are prohibited in SDP. This method MUST NOT be used unless it can be guaranteed that the SDP is conveyed over a secure channel. k=uri: A Universal Resource Identifier is included in the key field. The URI refers to the data containing the key, and may require additional authentication before the key can be returned. When - a request is made to the given URI, the MIME content-type of - the reply specifies the encoding for the key in the reply. + a request is made to the given URI, the reply should specify + the encoding for the key. The URI is often a secure HTTP URI, + although this is not required. k=prompt No key is included in this SDP description, but the session or media stream referred to by this key field is encrypted. The user should be prompted for the key when attempting to join the session, and this user-supplied key should then be used to decrypt the media streams. The use of user-specified keys is NOT RECOMMENDED, since such keys tend to have weak security properties. The key field MUST NOT be used unless it can be guaranteed that the SDP is conveyed over a secure and trusted channel. An example of such - a channel might be SDP embedded inside an S/MIME message. + a channel might be SDP embedded inside an S/MIME message or a TLS + protected HTTP or SIP session. It is important to ensure that the + secure channel is with the party that is authorized to join the + session, not an intermediary: if a caching proxy server is used, it + is important to ensure that the proxy is either trusted or unable to + access the SDP. Definition of appropriate security measures is beyond + the scope of this specification, and should be defined by the users + of SDP. 5.13 Attributes ("a=") a= a=: Attributes are the primary means for extending SDP. Attributes may be defined to be used as "session-level" attributes, "media-level" attributes, or both. @@ -961,43 +981,43 @@ and "data" is that the former is a media flow such as whiteboard information, and the latter is bulk-data transfer such as multicasting of program executables which will not typically be displayed to the user. "control" is used to specify an additional conference control channel for the session. The second sub-field is the transport port to which the media stream is sent. The meaning of the transport port depends on the network being used as specified in the relevant "c=" field, and on the transport protocol defined in the third sub-field. Other ports used - by the media application (such as the RTCP port [RFC1889]) MAY be - derived algorithmically from the base media port or MAY be specified - in a separate attribute (e.g. "a=rtcp:" as defined in [RTCPSDP]). + by the media application (such as the RTCP port [12]) MAY be derived + algorithmically from the base media port or MAY be specified in a + separate attribute (e.g. "a=rtcp:" as defined in [14]). For applications where hierarchically encoded streams are being sent to a unicast address, it may be necessary to specify multiple transport ports. This is done using a similar notation to that used for IP multicast addresses in the "c=" field: m= / - In such a case, the ports used depend on the transport protocol. For RTP, the default is that only the even numbered ports are used for - data and the corresponding one-higher odd port is used for RTCP. For - example: + data with the corresponding one-higher odd ports used for the RTCP + belonging to the RTP session, and the denoting the + number of RTP sessions. For example: m=video 49170/2 RTP/AVP 31 would specify that ports 49170 and 49171 form one RTP/RTCP pair and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the transport protocol and 31 is the format (see below). If non- contiguous ports are required, they must be signalled using a - separate attribute (e.g. "a=rtcp:" as defined in [RTCPSDP]). + separate attribute (e.g. "a=rtcp:" as defined in [14]). If multiple addresses are specified in the "c=" field and multiple ports are specified in the "m=" field, a one-to-one mapping from port to the corresponding address is implied. For example: c=IN IP4 224.2.1.1/127/2 m=video 49170/2 RTP/AVP 31 would imply that address 224.2.1.1 is used with ports 49170 and 49171, and address 224.2.1.2 is used with ports 49172 and 49173. @@ -1028,24 +1047,24 @@ start appropriate tools, relays, mixers or recorders. The main reason to specify the transport-protocol in addition to the media format is that the same standard media formats may be carried over different transport protocols even when the network protocol is the same - a historical example is vat PCM audio and RTP PCM audio. In addition, relays and monitoring tools that are transport-protocol-specific but format-independent are possible. For RTP media streams operating under the RTP Audio/Video Profile - [RFC1890], the protocol field is "RTP/AVP". Should other RTP - profiles be defined in the future, their profiles will be specified - in the same way. For example, the protocol field "RTP/XYZ" would - specify RTP operating under a profile whose short name is "XYZ". + [13], the protocol field is "RTP/AVP". Should other RTP profiles be + defined in the future, their profiles will be specified in the same + way. For example, the protocol field "RTP/XYZ" would specify RTP + operating under a profile whose short name is "XYZ". The fourth and subsequent sub-fields are media formats. For audio and video, these SHOULD reference a MIME sub-type describing the format under the "audio" and "video" top-level MIME types. When a list of payload formats is given, this implies that all of these formats may be used in the session, but the first of these formats SHOULD be used as the default format for the session. For media whose transport protocol is not RTP or UDP the format field @@ -1104,21 +1122,21 @@ RTP profiles that specify the use of dynamic payload types MUST define the set of valid encoding names and/or a means to register encoding names if that profile is to be used with SDP. Note that RTP audio formats typically do not include information about the number of samples per packet. If a non-default (as defined in the RTP Audio/Video Profile) packetisation is required, the "ptime" attribute is used as given below. - For more details on RTP audio and video formats, see [RFC1890]. + For more details on RTP audio and video formats, see [13]. Predefined application formats for the UDP protocol with non-RTP media are as below: wb: LBL Whiteboard (transport: udp) nt: UCL Network Text Editor (transport: udp) 6. Suggested Attributes The following attributes are suggested. Since application writers @@ -1232,21 +1249,21 @@ This specifies the type of the conference. Suggested values are "broadcast", "meeting", "moderated", "test" and "H332". "recvonly" should be the default for "type:broadcast" sessions, "type:meeting" should imply "sendrecv" and "type:moderated" should indicate the use of a floor control tool and that the media tools are started so as to mute new sites joining the conference. Specifying the attribute "type:H332" indicates that this loosely coupled session is part of a H.332 session as defined - in the ITU H.332 specification [H.332]. Media tools should be + in the ITU H.332 specification [15]. Media tools should be started "recvonly". Specifying the attribute "type:test" is suggested as a hint that, unless explicitly requested otherwise, receivers can safely avoid displaying this session description to users. The type attribute is a session-level attribute, and is not dependent on charset. a=charset: @@ -1291,42 +1308,42 @@ important. In general, sending session descriptions consisting of multiple languages is discouraged. Instead, multiple descriptions SHOULD be sent describing the session, one in each language. However this is not possible with all transport mechanisms, and so multiple sdplang attributes are allowed although NOT RECOMMENDED. The "sdplang" attribute value must be a single RFC 3066 - language tag in US-ASCII [RFC3066]. It is not dependent on + language tag in US-ASCII [6]. It is not dependent on the charset attribute. An "sdplang" attribute SHOULD be specified when a session is of sufficient scope to cross geographic boundaries where the language of recipients cannot be assumed, or where the session is in a different language from the locally assumed norm. a=lang: This can be a session level attribute or a media level attribute. As a session level attribute, it specifies the default language for the session being described. As a media level attribute, it specifies the language for that media, overriding any session-level language specified. Multiple lang attributes can be provided either at session or media level if the session description or media use multiple languages, in which case the order of the attributes indicates the order of importance of the various languages in the session or media from most important to least important. The "lang" attribute value must be a single RFC 3066 language - tag in US-ASCII [RFC3066]. It is not dependent on the charset + tag in US-ASCII [6]. It is not dependent on the charset attribute. A "lang" attribute SHOULD be specified when a session is of sufficient scope to cross geographic boundaries where the language of recipients cannot be assumed, or where the session is in a different language from the locally assumed norm. a=framerate: This gives the maximum video frame rate in frames/sec. It is intended as a recommendation for the encoding of video data. @@ -1427,25 +1444,25 @@ should take a few precautions. Session descriptions 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 inappropriate 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 arriving by session - announcement, email, session invitation, or WWW page SHOULD NOT - deliver the user into an 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. + announcement, email, session invitation, or WWW page MUST NOT deliver + the user into an interactive multimedia session unless the user has + explicitly pre-authorized such action. As it is not always simple to + tell whether a session is interactive or not, applications that are + unsure should assume sessions are interactive. In this specification, there are no attributes which would allow the recipient of a session description to be informed to start multimedia tools in a mode where they default to transmitting. Under some circumstances it might be appropriate to define such attributes. If this is done an application parsing a session description containing such attributes SHOULD either ignore them, or inform the user that joining this session will result in the automatic transmission of multimedia data. The default behaviour for an unknown attribute is to ignore it. @@ -1461,52 +1478,102 @@ and the refusal of the firewall to open a hole for such scopes will provide separation of global multicast sessions from local ones. Use of the "k=" field poses a significant security risk, since it conveys session encryption keys in the clear. SDP MUST NOT be used to convey key material, unless it can be guaranteed that the channel over which the SDP is delivered is both private and authenticated. 9. IANA Considerations +9.1 The "application/sdp" media type + + One new MIME type is to be registered, as defined below. This updates + the previous definition from RFC 2327. + + To: ietf-types@iana.org + Subject: Registration of MIME media type application/sdp + + MIME media type name: application + + MIME subtype name: sdp + + Required parameters: None. + + Optional parameters: None. + + Encoding considerations: + See section 5 of RFC XXXX + + Security considerations: + See section 8 of RFC XXXX + + Interoperability considerations: + See RFC XXXX + + Published specification: + RFC XXXX + + Applications which use this media type: + Voice over IP, video teleconferencing, streaming media, instant + messaging, etc. See also section 3 of RFC XXXX. + + Additional information: + + Magic number(s): None. + File extension(s): The extension ".sdp" is commonly used. + Macintosh File Type Code(s): + + Person & email address to contact for further information: + Colin Perkins + IETF MMUSIC working group + + Intended usage: COMMON + + Author/Change controller: + Authors of RFC XXXX + IETF MMUSIC working group + +9.2 Registration of Parameters + There are seven field names that may be registered with IANA. Using the terminology in the SDP specification BNF, they are "media", "proto", "fmt", "att-field", "bwtype", "nettype" and "addrtype". -9.1 Media types ("media") +9.2.1 Media types ("media") The set of media types is intended to be small and SHOULD NOT be extended except under rare circumstances. The same rules should apply for media names as for top-level MIME content types, and where possible the same name should be registered for SDP as for MIME. For media other than existing MIME top-level content types, a standards-track RFC MUST be produced for a new top-level content type to be registered, and the registration MUST provide good justification why no existing media name is appropriate (the - "Standards Action" policy of RFC 2434 [RFC2434]). + "Standards Action" policy of RFC 2434 [5]. -9.2 Transport protocols ("proto") +9.2.2 Transport protocols ("proto") The "proto" field describes the transport protocol used. This SHOULD reference a standards-track protocol RFC. This memo registers three - values: "RTP/AVP" is a reference to RTP [RFC1889] used under the RTP - Profile for Audio and Video Conferences with Minimal Control - [RFC1890]) running over UDP/IP; "TCP" denotes an unspecified format - over TCP; and "udp" indicates an unspecified format over UDP. + values: "RTP/AVP" is a reference to RTP [12] used under the RTP + Profile for Audio and Video Conferences with Minimal Control [13] + running over UDP/IP; "TCP" denotes an unspecified format over TCP; + and "udp" indicates an unspecified format over UDP. New transport protocols MAY be registered with IANA. Registrations MUST reference an RFC describing the protocol. Such an RFC MAY be Experimental or Informational, although it is preferable if it is Standards-Track. Registrations MUST also define the rules by which their "fmt" namespace is managed (see below). -9.3 Media formats ("fmt") +9.2.3 Media formats ("fmt") Each transport protocol, defined by the "proto" field, has an associated "fmt" namespace that describes the media formats which may conveyed by that protocol. Formats cover all the possible encodings that might want to be transported in a multimedia session. RTP payload formats under the "RTP/AVP" protocol that have been assigned static payload types MUST use the static payload type as their "fmt" value. For payload formats under "RTP/AVP" that have a dynamic payload type number, the dynamic payload type number is given @@ -1523,21 +1590,21 @@ referenced in the registration, but it may be Informational or Experimental if the protocol is not deemed to be of widespread deployment. For other protocols, formats MAY be registered according to the rules of the associated "proto" specification. Registrations of new formats MUST specify which transport protocols they apply to. -9.4 Attribute names ("att-field") +9.2.4 Attribute names ("att-field") Attribute field names ("att-field") MUST be registered with IANA and documented, because of noticeable issues due to conflicting attributes under the same name. Unknown attributes in SDP are simply ignored, but conflicting ones that fragment the protocol are a serious problem. New attribute registerations are accepted according to the "Specification Required" policy of RFC 2434, provided that the specification includes the following information: @@ -1561,56 +1627,56 @@ expected to see widespread use and interoperability, SHOULD be documented with a standards-track RFC that specifies the attribute more precisely. Submitters of registrations should ensure that the specification is in the spirit of SDP attributes, most notably that the attribute is platform independent in the sense that it makes no implicit assumptions about operating systems and does not name specific pieces of software in a manner that might inhibit interoperability. -9.5 Bandwidth specifiers ("bwtype") +9.2.5 Bandwidth specifiers ("bwtype") A proliferation of bandwidth specifiers is strongly discouraged. New bandwidth specifiers ("bwtype" fields) MUST be registered with IANA. The submission MUST reference a standards-track RFC specifying the semantics of the bandwidth specifier precisely, and indicating when it should be used, and why the existing registered bandwidth specifiers do not suffice. -9.6 Network types ("nettype") +9.2.6 Network types ("nettype") New network types (the "nettype" field) may be registered with IANA if SDP needs to be used in the context of non-Internet environments. Whilst these are not normally the preserve of IANA, there may be circumstances when an Internet application needs to interoperate with a non- Internet application, such as when gatewaying an Internet telephony call into the PSTN. The number of network types should be small and should be rarely extended. A new network type cannot be registered without registering at least one address type to be used with that network type. A new network type registration MUST reference an RFC which gives details of the network type and address type and specifies how and when they would be used. Such an RFC MAY be Informational. -9.7 Address types ("addrtype") +9.2.7 Address types ("addrtype") New address types ("addrtype") may be registered with IANA. An address type is only meaningful in the context of a network type, and any registration of an address type MUST specify a registered network type, or be submitted along with a network type registration. A new address type registration MUST reference an RFC giving details of the syntax of the address type. Such an RFC MAY be Informational. Address types are not expected to be registered frequently. -9.8 Registration Procedure +9.2.8 Registration Procedure In the RFC documentation that registers SDP "media", "proto", "fmt", "bwtype", "nettype" and "addrtype" fields, the authors MUST include the following information for IANA to place in the appropriate registry: o contact name, email address and telephone number o name being registered (as it will appear in SDP) @@ -1624,21 +1690,21 @@ o a reference to the specification (e.g. RFC number) of the registered name. IANA may refer any registration to the IESG Transport Area Directors for review, and may request revisions to be made before a registration will be made. Appendix A. SDP Grammar This appendix provides an Augmented BNF grammar for SDP. ABNF is - defined in [RFC2234]. + defined in [2]. ; SDP Syntax announcement = proto-version origin-field session-name-field information-field uri-field email-fields phone-fields connection-field @@ -1801,21 +1868,21 @@ unicast-address = IP4-address / IP6-address / FQDN / extn-addr multicast-address = IP4-multicast / IP6-multicast IP4-multicast = m1 3( "." decimal-uchar ) "/" ttl [ "/" integer ] ; IPv4 multicast addresses may be in the ; range 224.0.0.0 to 239.255.255.255 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / - ("23" DIGIT )) + ("23" DIGIT ) IP6-multicast = hexpart [ "/" integer ] ; IPv6 address starting with FF ttl = (POS-DIGIT *2DIGIT) / "0" FQDN = 4*(alpha-numeric / "-" / ".") ; fully qualified domain name as specified ; in RFC1035 @@ -1843,24 +1910,20 @@ ;session-level attribute to be used byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) ;any byte except NUL, CR or LF non-ws-string = 1*(VCHAR/%x80-FF) ;string of visible characters token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / %x5E-7E - ; definition from RFC 2045 - - ; "any (US-ASCII) CHAR except SPACE, CTLs, - ; or tspecials". - ; the tspecials are ()<>@,;: token = 1*(token-char) email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF ;any byte except NUL, CR, LF, or the quoting ;characters ()<> integer = POS-DIGIT *DIGIT ; generic sub-rules: primitives @@ -1866,139 +1929,95 @@ ; generic sub-rules: primitives alpha-numeric = ALPHA / DIGIT POS-DIGIT = %x31-39 ; 1 - 9 decimal-uchar = DIGIT / POS-DIGIT DIGIT / ("1" 2*(DIGIT)) / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) + ; external references: ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 2234 ; URI-reference: from RFC1630 and RFC2732 ; addr-spec: from RFC 2822 -Appendix B. Changes from RFC 2327 - - o Deprecate X- notation for experimental parameters - - o Clarify that a=recvonly does NOT mean that you don't send RTCP, - and similarly for sendonly and inactive. These only effect the RTP - stream. - - o Rewrite and correct the ABNF syntax (thanks to Jonathan Lennox) - - o Update BNF to support IPv6. - - o Add a=inactive attribute. - - o Add a=maxptime attribute. - - o RFC 2327 mandated that either e= or p= was required. Both are now - optional, to reflect actual usage. - - o Removed references to "conference" from the description of the t= - line, to make it less SAP oriented. - - o Note about wrap-around of NTP timestamps in t= - - o References have been updated and split into normative and - informative sections. - - o Section 3.1 was replaced with a reference to RFC 2119, and the - memo has been updated to use the RFC 2119 terminology (MUST, - SHOULD, etc). - - o Use of "application/sdp" as MIME a type for SDP files is now - "MUST" rather than "SHOULD". - - o Many sections have been updated to be less SAP specific, and to - reference other current uses of SDP such as RTSP and SIP. - - o The introduction and background has been rewritten, to remove - references to the Mbone, reflecting current use of SDP. - - o The section on concatenation of session descriptions (which was - not allowed in SAP, but allowed in other cases) has been removed. - - It is assumed that transports of SDP specify will specify this. - - o The description of the c= line has been updated to reflect common - usage of SDP, rather than Mbone conferencing with SAP. - - o The b= line no longer makes a normative reference to the Mbone FAQ - for bandwidth limits at various TTLs. The AS modifier to b= is - noted as being the RTP session bandwidth. - - o Define relation between the m= line and MIME types - - o Note use of s= in sessions with no meaningful name - - o Allow a=rtpmap to be a session level attribute, in addition to a - media level attribute - - o Clarify the limitations of the k= field - - o Clarify IANA considerations - -Appendix C. Acknowledgments +Appendix B. Acknowledgments Many people in the IETF MMUSIC working group have made comments and suggestions contributing to this document. In particular, we would like to thank Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna and Jonathan Lennox. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [3] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. - [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource + Identifiers (URI): Generic Syntax", RFC 2396, August 1998. + + [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. - [5] Alvestrand, H., "Tags for the Identification of Languages", BCP + [6] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. Informative References - [6] Mills, D., "Network Time Protocol (Version 3) Specification, - Implementation", RFC 1305, March 1992. - - [7] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, - "RTP: A Transport Protocol for Real-Time Applications", RFC - 1889, January 1996. - [8] Schulzrinne, H., "RTP Profile for Audio and Video Conferences - with Minimal Control", RFC 1890, January 1996. + [7] Mills, D., "Network Time Protocol (Version 3) Specification, + Implementation", RFC 1305, March 1992. - [9] Handley, M., Perkins, C. and E. Whelan, "Session Announcement + [8] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000. - [10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., + [9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. - [11] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming + [10] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. - [12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with + [11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. - [13] Huitema, C., "RTCP attribute in SDP", - draft-ietf-mmusic-sdp4nat-05 (work in progress), June 2003. + [12] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, + "RTP: A Transport Protocol for Real-Time Applications", RFC + 3550, July 2003. + + [13] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video + Conferences with Minimal Control", RFC 3551, July 2003. + + [14] Huitema, C., "Real Time Control Protocol (RTCP) attribute in + Session Description Protocol (SDP)", RFC 3605, October 2003. + + [15] International Telecommunications Union, "H.323 extended for + loosely coupled conferences", ITU Recommendation H.332, + September 1998. + + [16] Arkko, J., "Key Management Extensions for Session Description + Protocol (SDP) and Real Time Streaming Protocol (RTSP)", + draft-ietf-mmusic-kmgmt-ext-09 (work in progress), October + 2003. + + [17] Andreasen, F., Baugher, M. and D. Wing, "SDP Security + Descriptions for Media Streams", + draft-ietf-mmusic-sdescriptions-02 (work in progress), October + 2003. Authors' Addresses Mark Handley University College London Gower Street London WC1E 6BT UK EMail: M.Handley@cs.ucl.ac.uk