Network Working Group M. Handley Request for Comments: 2327 V. Jacobson Category: Standards Track ISI/LBNL April 1998 SDP: Session Description Protocol Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This document 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. This document is a product of the Multiparty Multimedia Session Control (MMUSIC) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at confctrl@isi.edu and/or the authors. 1. Introduction On the Internet multicast backbone (Mbone), a session directory tool is used to advertise multimedia conferences and communicate the conference addresses and conference tool-specific information necessary for participation. This document defines a session description protocol for this purpose, and for general real-time multimedia session description purposes. This memo does not describe multicast address allocation or the distribution of SDP messages in detail. These are described in accompanying memos. SDP is not intended for negotiation of media encodings. Handley & Jacobson Standards Track [Page 1] RFC 2327 SDP April 1998 2. Background The Mbone is the part of the internet that supports IP multicast, and thus permits efficient many-to-many communication. It is used extensively for multimedia conferencing. Such conferences usually have the property that tight coordination of conference membership is not necessary; to receive a conference, a user at an Mbone site only has to know the conference's multicast group address and the UDP ports for the conference data streams. Session directories assist the advertisement of conference sessions and communicate the relevant conference setup information to prospective participants. SDP is designed to convey such information to recipients. 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 [4], Session Initiation Protocol [11], Real- Time Streaming Protocol [12], electronic mail using the MIME extensions, and the Hypertext Transport Protocol. SDP is intended to be general purpose so that it can be used for a wider range of network environments and applications than just multicast session directories. However, it is not intended to support negotiation of session content or media encodings - this is viewed as outside the scope of session description. 3. Glossary of Terms The following terms are used in this document, and have specific meaning within the context of this document. Conference A multimedia conference is a set of two or more communicating users along with the software they are using to communicate. Session A multimedia session is a set of multimedia senders and receivers and the data streams flowing from senders to receivers. A multimedia conference is an example of a multimedia session. Session Advertisement See session announcement. Session Announcement A session announcement is a mechanism by which a session description is conveyed to users in a proactive fashion, i.e., the session description was not explicitly requested by the user. Handley & Jacobson Standards Track [Page 2] RFC 2327 SDP April 1998 Session Description A well defined format for conveying sufficient information to discover and participate in a multimedia session. 3.1. Terminology 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. 4. SDP Usage 4.1. Multicast Announcements SDP is a session description protocol for multimedia sessions. A common mode of usage is for a client to announce a conference session by periodically multicasting an announcement packet to a well known multicast address and port using the Session Announcement Protocol (SAP). SAP packets are UDP packets with the following format: |--------------------| | SAP header | |--------------------| | text payload | |////////// The header is the Session Announcement Protocol header. SAP is described in more detail in a companion memo [4] The text payload is an SDP session description, as described in this memo. The text payload should be no greater than 1 Kbyte in length. If announced by SAP, only one session announcement is permitted in a single packet. 4.2. Email and WWW Announcements Alternative means of conveying session descriptions include electronic mail and the World Wide Web. For both email and WWW distribution, the use of the MIME content type "application/sdp" should be used. This enables the automatic launching of applications for participation in the session from the WWW client or mail reader in a standard manner. Handley & Jacobson Standards Track [Page 3] RFC 2327 SDP April 1998 Note that announcements of multicast sessions made only via email or the World Wide Web (WWW) do not have the property that the receiver of a session announcement can necessarily receive the session because the multicast sessions may be restricted in scope, and access to the WWW server or reception of email is possible outside this scope. SAP announcements do not suffer from this mismatch. 5. Requirements and Recommendations The purpose of SDP is to convey information about media streams in multimedia sessions to allow the recipients of a session description to participate in the session. SDP is primarily intended for use in an internetwork, although it is sufficiently general that it can describe conferences in other network environments. A multimedia session, for these purposes, is defined as a set of media streams that exist for some duration of time. Media streams can be many-to-many. The times during which the session is active need not be continuous. Thus far, multicast based sessions on the Internet have differed from many other forms of conferencing in that anyone receiving the traffic can join the session (unless the session traffic is encrypted). In such an environment, SDP serves two primary purposes. It is a means to communicate the existence of a session, and is a means to convey sufficient information to enable joining and participating in the session. In a unicast environment, only the latter purpose is likely to be relevant. Thus SDP includes: o Session name and purpose o Time(s) the session is active o The media comprising the session o Information to receive those media (addresses, ports, formats and so on) As resources necessary to participate in a session may be limited, some additional information may also be desirable: o Information about the bandwidth to be used by the conference o Contact information for the person responsible for the session Handley & Jacobson Standards Track [Page 4] RFC 2327 SDP April 1998 In general, SDP must convey sufficient information to be able to join a session (with the possible exception of encryption keys) and to announce the resources to be used to non-participants that may need to know. 5.1. Media Information SDP includes: o The type of media (video, audio, etc) o The transport protocol (RTP/UDP/IP, H.320, etc) o The format of the media (H.261 video, MPEG video, etc) For an IP multicast session, the following are also conveyed: o Multicast address for media o Transport Port for media This address and port are the destination address and destination port of the multicast stream, whether being sent, received, or both. For an IP unicast session, the following are conveyed: o Remote address for media o Transport port for contact address The semantics of this address and port depend on the media and transport protocol defined. By default, this is the remote address and remote port to which data is sent, and the remote address and local port on which to receive data. However, some media may define to use these to establish a control channel for the actual media flow. 5.2. Timing Information Sessions may either be bounded or unbounded in time. Whether or not they are bounded, they may be only active at specific times. SDP can convey: o An arbitrary list of start and stop times bounding the session o For each bound, repeat times such as "every Wednesday at 10am for one hour" Handley & Jacobson Standards Track [Page 5] RFC 2327 SDP April 1998 This timing information is globally consistent, irrespective of local time zone or daylight saving time. 5.3. Private Sessions It is possible to create both public sessions and private sessions. Private sessions will typically be conveyed by encrypting the session description to distribute it. The details of how encryption is performed are dependent on the mechanism used to convey SDP - see [4] for how this is done for session announcements. 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. 5.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 additional pointers in the form of Universal Resources Identifiers (URIs) for more information about the session. 5.5. Categorisation 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. 5.6. Internationalization The SDP specification recommends the use of the ISO 10646 character sets in the UTF-8 encoding (RFC 2044) 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. 6. SDP Specification SDP session descriptions are entirely textual using the ISO 10646 character set in UTF-8 encoding. SDP field names and attributes 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, Handley & Jacobson Standards Track [Page 6] RFC 2327 SDP April 1998 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 the total bandwidth allocated to all SAP announcements is strictly limited, the encoding is deliberately compact. Also, since announcements may be transported via very unreliable means (e.g., email) 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 consists of a number of lines of text of the form = is always exactly one character and is case-significant. is a structured text string whose format depends on . It also will be case-significant unless a specific field defines otherwise. Whitespace is not permitted either side of the `=' sign. In general is either a number of fields delimited by a single space character or a free format string. A session description consists of a session-level description (details that apply to the whole session and all media streams) and optionally several media-level descriptions (details that apply onto to a single media stream). An announcement consists of a session-level section followed by zero or more media-level sections. The session-level part starts with a `v=' line and continues to the first media-level section. The media description starts with an `m=' line and continues to the next media description or end of the whole session description. In general, session-level values are the default for all media unless overridden by an equivalent media-level value. When SDP is conveyed by SAP, only one session description is allowed per packet. When SDP is conveyed by other means, many SDP session descriptions may be concatenated together (the `v=' line indicating the start of a session description terminates the previous description). Some lines in each description are required and some are optional but all must appear in exactly the order given here (the fixed order greatly enhances error detection and allows for a simple parser). Optional items are marked with a `*'. Session description v= (protocol version) o= (owner/creator and session identifier). s= (session name) i=* (session information) Handley & Jacobson Standards Track [Page 7] RFC 2327 SDP April 1998 u=* (URI of description) e=* (email address) p=* (phone number) c=* (connection information - not required if included in all media) b=* (bandwidth information) 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) k=* (encryption key) a=* (zero or more media attribute lines) The set of `type' letters is deliberately small and not intended to be extensible -- SDP parsers must completely ignore any announcement that contains a `type' letter that it does not under