Session Description Protocol (SDP) is a fundamental, but very unintuitive concept behind how WebRTC works today. Its no wonder that the Anatomy of a WebRTC SDP post and the interactive SDP guide by Quobis CTO, Antón Román has been so popular here on webrtcHacks. With all things WebRTC, things have changed and we were due for an update.

We also had some rendering issues on the interactive guide. After failing to figure out how to fix it, I decided to completely rewrite it. It is still has some issues, so please make your pull requests to fix and update it on our github repo here.

Please see Antón’s update comments immediately below, his original post immediately below that, or just go to the interactive SDP guide if you want to dive right in.

{“editor”, “Chad Hart“}

Update – April 2016

The SDP generated by the browser to start a WebRTC PeerConnection has not changed substantially since the original SDP post was published two years ago. Just some corrections to be compliant with the standards and a few additions related to new supported features. However, we consider this a good opportunity to publish an updated version of this post which has been a useful and reference tool for those who need to know what means every single line of the SDPs used in WebRTC.

The  WebRTC 1.0 specification is almost closed so no relevant changes in the SDP are expected in the near future, which is good news for the WebRTC systems that are already in production.

The ORTC specification is getting mature and it is being implemented by Edge. With ORTC the SDP may not  a pivotal part of WebRTC anymore. Even so, a good knowledge of the “hidden” meaning behind the SDP lines will be very helpful to understand how the media or data real-time WebRTC session are being negotiated. In fact there is even some discussion of removing the ability to let applications change – i.e munge – SDP all together once these APIs are introduced.

{“author”, “Antón Román“}

 

---

Anatomy of a WebRTC SDP (original by Antón Román)

If you are reading this blog you likely know that Session Description Protocol (SDP)  plays a central role in the setup of WebRTC sessions. SDP is the protocol used to exchange  media information between SIP endpoints, and it has also been chosen by IETF and W3C to exchange media information in WebRTC. A WebRTC peer uses SDP to inform the other end about which transport protocols, ports, codecs and  other parameters to use in a media session.

SDP use in WebRTC has been criticized by many since the beginning. These critiques have a good rationale behind and I strongly recommend the Iñaki Baz Interview about Object RTC (ORTC), the proposed alternative to SDP for WebRTC, to learn more about these arguments. SDP may not be the more flexible or scalable way to negotiate WebRTC sessions, but nonetheless it has been adopted by the current standard (namely WebRTC 1.0) and all the existing implementations are based on it.  Therefore we will not deal with the SDP debate (and what could happen in WebRTC 2.0) in this post but will instead focus on reviewing the information that is included in the SDP at the time of this writing and how this information is used in the WebRTC multimedia session creation.

SDP is defined in RFC4566 but this specification only defines the main headers and how the offer/answer models works. There are many RFCs that cover how to add  various different media capabilities to SDP. This draft reviews all the RFCs involved in the SDPs for WebRTC – I strongly encourage you to reading it if you need a deeper understanding about any of the SDP elements.

The Javascript API methods used to generate and set SDPs, as well as the sequence used to exchange offer and answer, are perfectly explained in the diagram at section 13.4 Call Flow Browser to Browser from the W3C working draft for WebRTC 1.0. In this diagram you just have to replace offer, pranwser (provisional answer) and answer by SDPs messages and you will have a clear picture about how WebRTC works. If you prefer a human readable version of that you can refer to Reid’s post about STUN protocol.

Let’s take a look at a real SDP message that was created just prior to being sent to the other peer by Chromium version 32.0.1700.19 to start a video/audio session. Click on the SDP image below to go to our interactive SDP anatomy page for a line-by-line description:

I would like to end this post with a brief comment about SDP incompatibilities among Chrome versions. Finding that your WebRTC app is not working with the last version of Chrome is not an uncommon issue. New features are added, the implementation is improved and bugs are fixed and these changes may have an impact in the SDP. SDP problems are expected to become less common as the implementation gets more mature and homogenised among browser vendors but it is something that must be taken into consideration for the time being.

{“author”,”Antón Román”}