Review of Chrome's migration to WebRTC's Unified Plan, how false metrics may have misguided this effort, and what that means moving forward.
webrtcH4cKS: ~ A playground for Simulcast without an SFU
Simulcast is one of the more interesting aspects of WebRTC for multiparty conferencing. In a nutshell, it means sending three different resolution (spatial scalability) and different frame rates (temporal scalability) at the same time. Oscar Divorra’s post contains the full details.
Usually, one needs a SFU to take advantage of simulcast. But there is a hack to make the effect visible between two browsers — or inside a single page. This is very helpful for single-page tests or fiddling with simulcast features, particular the ability to enable only certain spatial layers or to control the target bitrate of a particular stream.
As the year 2017 comes to an end, there was a small present. Hangouts started to support Firefox with WebRTC instead of rejecting access – plugin access had been unavailable since Firefox 53 removed NPAPI in April 2017. While it had been public for a while that the Firefox WebRTC team had been testing this, it was a nice Christmas present to see this shipped. Tsahi Levent-Levi was one of the first people to notice.
This comes at a time where other Google teams are being criticized for promoting Chrome-only experiences. Kudos to the Hangouts team for showing that you still care about the web as an open platform!
webrtcH4cKS: ~ SDP: Your Fears Are Unleashed (Iñaki Baz Castillo)
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.