Session Description Protocol - Session Description

Session Description

A session is described by a series of fields, one per line. The form of each field is as follows.

=

Where is a single case-significant character and value is structured text whose format depends upon attribute type. Values are typically a UTF-8 encoding. Whitespace is not allowed immediately to either side of the =.

Within an SDP message there are three main sections, detailing the session, timing, and media descriptions. Each message may contain multiple timing and media descriptions. Names are only unique within the associated syntactic construct, i.e. within the session, time, or media.

Optional values are specified with =* and each field must appear in the order shown below.

Session description v= (protocol version number, currently only 0) o= (originator and session identifier : username, id, version number, network address) s= (session name : mandatory with at least one UTF-8-encoded character) i=* (session title or short information) u=* (URI of description) e=* (zero of more email address with optional name of contacts) p=* (zero of more phone number with optional name of contacts) c=* (connection information—not required if included in all media) b=* (zero or more bandwidth information lines) One or more Time descriptions ("t=" and "r=" lines; see below) z=* (time zone adjustments) k=* (encryption key) a=* (zero or more session attribute lines) Zero or more Media descriptions (each one starting by an "m=" line; see below) Time description (mandatory) t= (time the session is active) r=* (zero or more repeat times) Media description (if present) m= (media name and transport address) i=* (media title or information field) c=* (connection information — optional if included at session level) b=* (zero or more bandwidth information lines) k=* (encryption key) a=* (zero or more media attribute lines — overriding the Session attribute lines)

Here is an example session description (from RFC 4566). This session description is being proposed to a receiving client (with username "jdoe") who was requesting a session from his host located at IPv4 address 10.47.16.5 in order to play a session named "SDP Seminar" (announced separately by the media server) that the SDP server describes as being titled more completely "A Seminar on the session description protocol" (with an available PDF documentation that the client could download separately if needed to get more information). It also contains the description of two non interactive (receive only) medias (audio and video) that are part of this proposed session. The media contents are both available (without any apparent secure access control in this example) on the same media server host (indicated in the Sesssion-level parameters, whose contact name is "Jane Doe" and reachable by his indicated email address), emitting and transporting its two media streams with the RTP protocol over UDP in the basic RTP Audio Video Profile (RTP/AVP), from an IPv4 multicast address 224.2.17.12 (with an IP Multicast Time To Live of up to 127 hops), and using UDP port 49170 for the media data of the audio stream encoded with the RTP/AVP audio format 0 (whose mapping is registered on the IANA registry of standard RTP formats) with its associated UDP port 49171 for its control channel (implicitly added for RTP), and UDP port 51372 for the media data of the video stream (encoded with with the server-defined RTP/AVP video format 99, which the SDP server defines and maps as being a "video/h263-1998" media codec) with its associated UDP port 51373 for its control channel (implicitly added for RTP) :

v=0 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane Doe) c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 a=recvonly m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000

Note that the SDP description just contains the description to user "jdoe" of the medias proposed by the described RTP/AVP media server(s) for his session. However it does not specify how the user (or his user user agent) reached the SDP server in order to get that description. it also does not indicate if (and how) "jdoe" was knowing the session name "SDP Seminar" and where it could locate the SDP server proposing this description (this requires a separate protocol for SDP announcement of available sessions). Also this SDP description does not say if (and how) these medias will be played by jdoe's user agent. At this point, the RTP/AVP media server has still not been reached by the client for these medias.

Also the SDP specifications do not indicate by which transport protocol this SDP description can be delivered to the client. Typically it would be sent by a SAP server in an announcement message, but it could as well be delivered by a web server, or sent as is in an email attachment. In fact, this SDP is not really a protocol but a message format by itself, with its own content type. As this content may be valid for a limited time, the SDP description contains a range of dates of validity during which it should be available, using here a single pair of start and stop times (see the next section about time formats).