We have have had many posts on Session Description Protocol (SDP) here at werbrtcHacks. Why? Because it is often the most confusing yet critical aspects of WebRTC. It has also been among the most controversial. Earlier in WebRTC debates over SDP lead the to the development of the parallel ORTC standard which is now largely merging back into the core specifications. However, the reality is non-SDP based WebRTC is still a small minority of deployments and many have doubts this will change any time soon despite its formal acceptance.
webrtcH4cKS: ~ How to limit WebRTC bandwidth by modifying the SDP
WebRTC 1.0 uses SDP for negotiating capabilities between parties. While there are a growing number of objects coming to WebRTC to avoid this protocol from the 90’s , the reality is SDP will be with us for some time. If you want to do things like change codecs or adjust bandwidth limits, then you’re going to need to “munge” SDP for the time being.
At a recent WebRTC Boston, Nick Gauthier of MeetSpace described how he used SDP modification and other techniques to jam up to 10 video callers into a single conference without a media server. Not everyone has a good reason to do this, but there are certainly plenty of applications where having more precise control of your bandwidth consumption would be useful. You can see his video here or check out his technique and thorough explanation on how to munge SDP to adjust individual bandwidth usage below.
webrtcH4cKS: ~ Update: Anatomy of a WebRTC SDP (Antón Román)
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.
webrtcH4cKS: ~ Hello Chrome and Firefox, this is Edge calling
tl;dr: don’t worry, audio works. codec interop issue…
|ICE||yes||Edge requires end-of-candidate signaling|
|audio||yes||using G.722, Opus or G.711 codecs|
|video||no||standard H.264 is not supported in Edge yet|
|DataChannels||no||Edge does not support dataChannels|
As a reader of this blog, you probably know what WebRTC is but let me quote this:
WebRTC is a new set of technologies that brings clear crisp voice, sharp high-definition (HD) video and low-delay communication to the web browser.
In order to succeed, a web-based communications platform needs to work across browsers. Thanks to the work and participation of the W3C and IETF communities in developing the platform, Chrome and Firefox can now communicate by using standard technologies such as the Opus and VP8 codecs for audio and video, DTLS-SRTP for encryption, and ICE for networking.
webrtcH4cKS: ~ The Minimum Viable SDP
One evening last week, I was nerd-sniped by a question Max Ogden asked:
That is quite an interesting question. I somewhat dislike using Session Description Protocol (SDP) in the signaling protocol anyway and prefer nice JSON objects for the API and ugly XML blobs on the wire to the ugly SDP blobs used by the WebRTC API.
The question is really about the minimum amount of information that needs to be exchanged for a WebRTC connection to succeed.
WebRTC uses ICE and DTLS to establish a secure connection between peers. This mandates two constraints:
As WebRTC implementations and field trials evolve, field experience is telling us there are still a number of open issues to make this technology deployable in the real world and the fact that we would probably do some things differently if we started all over again. As an example, see the recent W3C discussion What is missing for building (WebRTC) real services or Quobis‘ CTO post on WebRTC use of SDP.
Tim Panton, contextual communications consultant at Westhawk Ltd, has gone through some of these issues. During the last couple of years we had the chance to run some workshops together and have some good discussions in the IETF and W3C context. Tim’s expertise is very valuable and I thought it would be a good idea to have him here to share some of his experiences with our readers. It ended up as a rant.
webrtcH4cKS: ~ Anatomy of a WebRTC SDP (Antón Román)
Editor note: see the updated version of this post here.
As described in previous posts, WebRTC does not specify a particular signalling model other than the generic need to exchange Session Description Protocol (SDP) media descriptions in the offer/answer fashion.
During the last few months, my friend Antón Román (CTO of Quobis) and I spent a lot of time with our team figuring out how to manipulate and adapt the SDP’s generated by web browsers to make them compatible with the different server/gateway technologies we’re working with.
As WebRTC makes use of new mechanisms but also existing ones that have seen few deployment in real networks to date. SDP’s generated by Web Browsers are more complex and contain a number of new attributes that are unfamiliar in SIP or IMS networks. In the following post, Antón analyses the anatomy of a WebRTC SDP, giving a detailed description of what all those lines do.
Updated 25 Aug 2013 – some minor edits fixing some ORTC API references and added ORTC sample code.
In my post on WebRTC standardization I mentioned that one of the controversial points of discussion in the W3C context was whether the SDP Offer/Answer model and the current API provided the level of flexibility a wide range of WebRTC use cases would require. In order to avoid the endless and repetitive discussions that have already occurred on this topic, developers unsatisfied with the current API have just announced an alternative to the existing WebRTC API. This new proposal is called WebRTC Object API, motivation behind it is presented in this IETF draft and some example code can be found on GitHub. Note that this is not the first time an alternative API aiming to provide more control to web developers has been proposed- Microsoft’s CU-RTC-Web introduced last year took a similar approach by introducing an alternative along with a working prototype.