Deploying media servers for WebRTC has two major challenges, scaling beyond a single server as well as optimizing the media latency for all users in the conference. While simple sharding approaches like “send all users in conference X to server Y” are easy to scale horizontally, they are far from optimal in terms of the media latency which is a key factor in the user experience. Distributing a conference to a network of servers located close to the users and interconnected with each other on a reliable backbone promises a solution to both problems at the same time. Boris Grozev from the Jitsi team describes the cascading SFU problem in-depth and shows their approach as well as some of the challenges they ran into.
Technology
webrtcH4cKS: ~ Breaking Point: WebRTC SFU Load Testing (Alex Gouaillard)
If you plan to have multiple participants in your WebRTC calls then you will probably end up using a Selective Forwarding Unit (SFU). Capacity planning for SFU’s can be difficult – there are estimates to be made for where they should be placed, how much bandwidth they will consume, and what kind of servers you need.
To help network architects and WebRTC engineers make some of these decisions, webrtcHacks contributor Dr. Alex Gouaillard and his team at CoSMo Software put together a load test suite to measure load vs. video quality. They published their results for all of the major open source WebRTC SFU’s. This suite based is the Karoshi Interoperability Testing Engine (KITE) Google funded and uses on webrtc.org to show interoperability status. The CoSMo team also developed a machine learning based video quality assessment framework optimized for real time communications scenarios.
If you’re new to WebRTC, Jitsi was the first open source Selective Forwarding Unit (SFU) and continues to be one of the most popular WebRTC platforms. They were in the news last week because their parent group inside Atlassian was sold off to Slack but the team clarified this does not have any impact on the Jitsi team. Helping to show they are still chugging along, they released a new feature they wanted to talk about – off-stage layer suspension. This is a technique for minimizing bandwidth and CPU consumption when using simulcast. Simulcast is a common technique used in multi-party video scenarios. See Oscar Divorra’s post on this topic and that Fippo post just last week for more on that. Even if you are not implementing a simulcast, this is a good post for understanding how to control bandwidth and to see some follow-along reverse-engineering on how Google does things in its Hangouts upgrade called Meet.
webrtcH4cKS: ~ Chrome Screensharing Blues – preparing for getDisplayMedia
The Chrome Webstore has decided to stop allowing inline installation for Chrome extensions. This has quite an impact on WebRTC applications since screensharing in Chrome currently requires an extension. Will the getDisplayMedia API come to the rescue?
Screensharing in Chrome
When screensharing was introduced in Chrome 33, it required implementation via an extension as a way to address the security concerns. This was better than the previous experience of putting this capability behind a flag which lead to sites asking their users to change that flag… that got those sites an official yikes.
webrtcH4cKS: ~ Autoplay restrictions and WebRTC (Dag-Inge Aas)
One of the great things about WebRTC is that it is built right into the web platform. The web platform is generally great for WebRTC, but occasionally it can cause huge headaches when specific WebRTC needs do not exactly align with more general browser usage requirements. The latest example of this is has to do with the autoplay of media where sound(s) suddenly went missing for many users. Former webrtcHacks guest author Dag-Inge Aas has been dealing with this first hand. See below for his write-up on browser expectations around the playback of media, the recent Chrome 66+ changes, and some tips and tricks for working around these issues.
webrtcH4cKS: ~ So your VPN is leaking because of Chrome’s WebRTC…
Brussel’s Mannneken Pis. Original photo by Flickr user Francisco Antunes (CC BY 2.0)
We have covered the “WebRTC is leaking your IP address” topic a few times, like when I reported what the NY Times was doing and in my WebRTC-Notifier. Periodically this topic comes up now and again in the blogosphere, generally with great shock and horror. This happened again recently, so here is an updated look into this alleged issue.
The recent blog post titled VPN Leak by voidsec highlighting how 19 out of more than 100 VPN services tested “leak” IP addresses via WebRTC is a quite interesting read. Some of the details about WebRTC are not quite correct the results are interesting nonetheless. At is core this is someone who sat down to test a long list of services and their behaviour, one by one. This is not the most exciting research task, but exhaustive studies like this often find something interesting.
webrtcH4cKS: ~ Progressive Web Apps (PWA) for WebRTC (Trond Kjetil Bremnes)
One of WebRTC’s biggest challenges has been providing consistent, reliable support across platforms. For most apps, especially those that started on the web, this generally means developing a native or hybrid mobile app in addition to supporting the web app. Progressive Web Apps (PWA) is a new concept that promises to unify the web for many applications by allowing web-based apps to look and act like native mobile ones without introducing an intermediary hybrid framework. As will be discussed, this approach has a lot of advantages, but does it make any sense for a WebRTC app?
Imaged modified from Window in Seattle airport by Flickr user Robert Scoble (CC BY-2.0)
Want to keep up on our latest posts? Please click here to subscribe to our mailing list if you have not already. We only email post updates. You can also follow us on twitter at @webrtcHacks for blog updates.
Multi-party calling architectures are a common topic here at webrtcHacks, largely because group calling is widely needed but difficult to implement and understand. Most would agree Scalable Video Coding (SVC) is the most advanced, but the most complex multi-party calling architecture.
To help explain how it works we have brought in not one, but two WebRTC video architecture experts. Sergio Garcia Murillo is a long time media server developer and founder of Medooze. Most recently, and most relevant for this post, he has been working on an open source SFU that leverages VP9 and SVC (the first open source project to do this that I am aware of). In addition, frequent webrtcHacks guest author and renown video expert Gustavo Garcia Bernando joins him.
webrtcH4cKS: ~ Slack Does WebRTC Video – Here’s How (Gustavo Garcia)
Slack is an über popular and fast growing communications tool that has a ton of integrations with various WebRTC services. Slack acquired a WebRTC company a year ago and launched its own audio conferencing service earlier this year which we analyzed here and here. Earlier this week they launched video. Does this work the same? Are there any tricks we can learn from their implementation? Long time WebRTC expert and webrtcHacks guest author Gustavo Garica takes a deeper dive into Slack’s new video conferencing feature below to see what’s going on under the hood.
