The Session Description Protocol (SDP) is a format for describing multimedia communication sessions for the purposes of announcement and invitation.[1] Its predominant use is in support of streaming media applications, such as voice over IP (VoIP) and video conferencing. SDP does not deliver any media streams itself but is used between endpoints for negotiation of network metrics, media types, and other associated properties. The set of properties and parameters is called a session profile.
The IETF published the original specification as a Proposed Standard in April 1998 (RFC 2327).[3] Revised specifications were released in 2006 (RFC 4566),[1] and in 2021 (RFC 8866).[4]
Session description
The Session Description Protocol describes a session as a group of fields in a text-based format, one field per line.[note 1] The form of each field is as follows.
<character>=<value><CR><LF>
Where <character> is a single case-sensitive character and <value> is structured text in a format that depends on the character. Values are typically UTF-8 encoded.[note 2]Whitespace is not allowed immediately to either side of the equal sign.[1]:Section 5
Session descriptions consist of three sections: session, timing, and media descriptions. Each description may contain multiple timing and media descriptions. Names are only unique within the associated syntactic construct.[5]
Fields must appear in the order shown; optional fields are marked with an asterisk:
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 or more email address with optional name of contacts) p=* (zero or 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 (optional)
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)
Below is a sample session description from RFC 4566. This session is originated by the user "jdoe", at IPv4 address 10.47.16.5. Its name is "SDP Seminar" and extended session information ("A Seminar on the session description protocol") is included along with a link for additional information and an email address to contact the responsible party, Jane Doe. This session is specified to last for two hours using NTP timestamps, with a connection address (which indicates the address clients must connect to or — when a multicast address is provided, as it is here — subscribe to) specified as IPv4 224.2.17.12 with a TTL of 127. Recipients of this session description are instructed to only receive media. Two media descriptions are provided, both using RTP Audio Video Profile. The first is an audio stream on port 49170 using RTP/AVP payload type 0 (defined by RFC 3551 as PCMU), and the second is a video stream on port 51372 using RTP/AVP payload type 99 (defined as "dynamic"). Finally, an attribute is included which maps RTP/AVP payload type 99 to format h263-1998 with a 90kHz clock rate. RTCP ports for the audio and video streams of 49171 and 51373, respectively, are implied.
The SDP specification is purely a format for session description. It is intended to be distributed over different transport protocols as necessary, including SAP, SIP, and RTSP. SDP could even be transmitted by email or as an HTTP payload.
Attributes
SDP uses attributes to extend the core protocol. Attributes can appear within the Session or Media sections and are scoped accordingly as session-level or media-level. New attributes are added to the standard occasionally through registration with IANA.[6]
Attributes are either properties or values:
Property: a=flag conveys a Boolean property of the media or session.
Value: a=attribute:value provides a named parameter.
Two of these attributes are specially defined:
a=charset:encoding is used in the session or media sections to specify a different character encoding (as registered in the IANA registry[7]) from the recommended default value (UTF-8) for standard protocol keys. These values contain a text that is intended to be displayed to a user.
a=sdplang:code is used to specify the language of text. Alternate text in multiple languages may be carried in the session, and selected automatically by the user agent according to user preferences.[clarification needed]
In both cases, text fields intended to be displayed to a user are interpreted as opaque strings, but rendered to the user or application with the values indicated in the last occurrence of the fields charset and sdplang in the current media section, or otherwise their last value in the session section.
The parameters v, s, and o are mandatory, must not be empty, and should be UTF-8-encoded. They are used as identifiers and are not intended to be displayed to users.
A few other attributes are also present in the example, either as a session-level attribute (such as the attribute in property form a=recvonly),[note 3] or as a media-level attribute (such as the attribute in value form a=rtpmap:99 h263-1998/90000 for the video in the example).
Time formats and repetitions
Absolute times are represented in Network Time Protocol (NTP) format (the number of seconds since 1900). If the stop time is 0 then the session is unbounded. If the start time is also zero then the session is considered permanent. Unbounded and permanent sessions are discouraged but not prohibited. Intervals can be represented with NTP times or in typed time: a value and time units (days: d, hours: h, minutes: m and seconds: s) sequence.
Thus an hour meeting from 10 am UTC on 1 August 2010, with a single repeat time a week later at the same time can be represented as:
t=12806568001281265200 r=604800 3600 0
Or using typed time:
t=12806568001281265200 r=7d 1h 0
When repeat times are specified, the start time of each repetition may need to be adjusted to compensate for daylight saving time changes so that it will occur at the same local time in a specific time zone throughout the period between the start time and the stop time.
Instead of specifying this time zone and having to support a database of time zones for knowing when and where daylight adjustments will be needed, the repeat times are assumed to be all defined within the same time zone, and SDP supports the indication of NTP absolute times when a daylight offset (expressed in seconds or using a type time) will need to be applied to the repeated start time or end time falling at or after each daylight adjustment. All these offsets are relative to the start time, they are not cumulative. NTP supports this with field z, which indicates a series of pairs whose first item is the NTP absolute time when a daylight adjustment will occur, and the second item indicates the offset to apply relative to the absolute times computed with the field r.
For example, if a daylight adjustment will subtract 1 hour on 31 October 2010 at 3am UTC (i.e. 60 days minus 7 hours after the start time on Sunday 1 August 2010 at 10am UTC), and this will be the only daylight adjustment to apply in the scheduled period which would occur between 1 August 2010 up to the 28 November 2010 at 10am UTC (the stop time of the repeated 1-hour session which is repeated each week at the same local time, which occurs 88 days later), this can be specified as:
t=12806568001290938400 r=7d 1h 0 z=1288494000 -1h
If the weekly 1-hour session was repeated every Sunday for one full year, i.e. from Sunday 1 August 2010 3 am UTC to Sunday 26 June 2011 4 am UTC (stop time of the last repeat, i.e. 360 days plus 1 hour later, or 31107600 seconds later), so that it would include the transition back to Summer time on Sunday 27 March 2011 at 2am (1 hour is added again to local time so that the second daylight transition would occur 209 days after the first start time):
As SDP announcements for repeated sessions should not be made to cover very long periods exceeding a few years, the number of daylight adjustments to include in the z= parameter should remain small.
Sessions may be repeated irregularly over a week but scheduled the same way for all weeks in the period, by adding more tuples in the r parameter. For example, to schedule the same event also on Saturday (at the same time of the day) you would use:
The SDP protocol does not support repeating sessions monthly and yearly schedules with such simple repeat times, because they are irregularly spaced in time; instead, additional t/r tuples may be supplied for each month or year.
Notes
↑ Lines are terminated by a carriage return and a line feed character, but implementations may relax this by omitting the carriage return.
↑ The session information and session name values are subject to the encoding specified in any charset attribute of the section.
↑ This session-level attribute also applies to the described media unless the value is overridden by a media-level attribute.
Related Research Articles
The Real-Time Streaming Protocol (RTSP) is an application-level network protocol designed for multiplexing and packetizing multimedia transport streams over a suitable transport protocol. RTSP is used in entertainment and communications systems to control streaming media servers. The protocol is used for establishing and controlling media sessions between endpoints. Clients of media servers issue commands such as play, record and pause, to facilitate real-time control of the media streaming from the server to a client or from a client to the server.
The Real-time Transport Protocol (RTP) is a network protocol for delivering audio and video over IP networks. RTP is used in communication and entertainment systems that involve streaming media, such as telephony, video teleconference applications including WebRTC, television services and web-based push-to-talk features.
The Session Initiation Protocol (SIP) is a signaling protocol used for initiating, maintaining, and terminating communication sessions that include voice, video and messaging applications. SIP is used in Internet telephony, in private IP telephone systems, as well as mobile phone calling over LTE (VoLTE).
A multicast address is a logical identifier for a group of hosts in a computer network that are available to process datagrams or frames intended to be multicast for a designated network service. Multicast addressing can be used in the link layer, such as Ethernet multicast, and at the internet layer for Internet Protocol Version 4 (IPv4) or Version 6 (IPv6) multicast.
8-bit clean is an attribute of computer systems, communication channels, and other devices and software, that process 8-bit character encodings without treating any byte as an in-band control code.
The Network Time Protocol (NTP) is a networking protocol for clock synchronization between computer systems over packet-switched, variable-latency data networks. In operation since before 1985, NTP is one of the oldest Internet protocols in current use. NTP was designed by David L. Mills of the University of Delaware.
An application layer is an abstraction layer that specifies the shared communication protocols and interface methods used by hosts in a communications network. An application layer abstraction is specified in both the Internet Protocol Suite (TCP/IP) and the OSI model. Although both models use the same term for their respective highest-level layer, the detailed definitions and purposes are different.
Remote Authentication Dial-In User Service (RADIUS) is a networking protocol that provides centralized authentication, authorization, and accounting (AAA) management for users who connect and use a network service. RADIUS was developed by Livingston Enterprises in 1991 as an access server authentication and accounting protocol. It was later brought into IEEE 802 and IETF standards.
In computer programming, Base64 is a group of binary-to-text encoding schemes that transforms binary data into a sequence of printable characters, limited to a set of 64 unique characters. More specifically, the source binary data is taken 6 bits at a time, then this group of 6 bits is mapped to one of 64 unique characters.
The Internet Calendaring and Scheduling Core Object Specification (iCalendar) is a media type which allows users to store and exchange calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information, and together with its associated standards has been a cornerstone of the standardization and interoperability of digital calendars across different vendors. Files formatted according to the specification usually have an extension of .ics. With supporting software, such as an email reader or calendar application, recipients of an iCalendar data file can respond to the sender easily or counter-propose another meeting date/time. The file format is specified in a proposed Internet standard for calendar data exchange. The standard and file type are sometimes referred to as "iCal", which was the name of the Apple Inc. calendar program until 2012, which provides one of the implementations of the standard.
A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that uses the urn scheme. URNs are globally unique persistent identifiers assigned within defined namespaces so they will be available for a long period of time, even after the resource which they identify ceases to exist or becomes unavailable. URNs cannot be used to directly locate an item and need not be resolvable, as they are simply templates that another parser may use to find an item.
The Extensible Provisioning Protocol (EPP) is a flexible protocol designed for allocating objects within registries over the Internet. The motivation for the creation of EPP was to create a robust and flexible protocol that could provide communication between domain name registries and domain name registrars. These transactions are required whenever a domain name is registered or renewed, thereby also preventing domain hijacking. Prior to its introduction, registries had no uniform approach, and many different proprietary interfaces existed. While its use for domain names was the initial driver, the protocol is designed to be usable for any kind of ordering and fulfilment system.
The RTP Control Protocol (RTCP) is a binary-encoded out-of-band signaling protocol that functions alongside the Real-time Transport Protocol (RTP). Its basic functionality and packet structure is defined in RFC 3550. RTCP provides statistics and control information for an RTP session. It partners with RTP in the delivery and packaging of multimedia data but does not transport any media data itself.
In the context of an HTTP transaction, basic access authentication is a method for an HTTP user agent to provide a user name and password when making a request. In basic HTTP authentication, a request contains a header field in the form of Authorization: Basic <credentials>, where <credentials> is the Base64 encoding of ID and password joined by a single colon :.
Text over IP is a means of providing a real-time text (RTT) service that operates over IP-based networks. It complements Voice over IP (VoIP) and Video over IP.
The Real-time Transport Protocol (RTP) specifies a general-purpose data format and network protocol for transmitting digital media streams on Internet Protocol (IP) networks. The details of media encoding, such as signal sampling rate, frame size and timing, are specified in an RTP payload format. The format parameters of the RTP payload are typically communicated between transmission endpoints with the Session Description Protocol (SDP), but other protocols, such as the Extensible Messaging and Presence Protocol (XMPP) may be used.
In computer networking, the Message Session Relay Protocol (MSRP) is a protocol for transmitting a series of related instant messages in the context of a communications session. An application instantiates the session with the Session Description Protocol (SDP) over Session Initiation Protocol (SIP) or other rendezvous methods.
The Session Initiation Protocol (SIP) is the signaling protocol selected by the 3rd Generation Partnership Project (3GPP) to create and control multimedia sessions with multiple participants in the IP Multimedia Subsystem (IMS). It is therefore a key element in the IMS framework.
A uniform resource locator (URL), colloquially known as an address on the Web, is a reference to a resource that specifies its location on a computer network and a mechanism for retrieving it. A URL is a specific type of Uniform Resource Identifier (URI), although many people use the two terms interchangeably. URLs occur most commonly to reference web pages (HTTP/HTTPS) but are also used for file transfer (FTP), email (mailto), database access (JDBC), and many other applications.
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.
