The KrankyGeek team has done it again! They’ve put together another great event filled with WebRTC content. This time KrankyGeek was held in São Paulo Brazil, and our team at WebRTC.ventures was proud to sponsor the event as well as have one of our own (Germán Goldenstein) present an introduction to WebRTC.

The following is our summary of the event, and we’ll also include the videos produced by KrankyGeek as soon as they are publicly released.

The WebRTC Journey

Tsahi Levent-Levi introduced the event with a description of the journey to WebRTC, and how we got here today, from telephones to javascript based telephony. I liked Tsahi’s comment that “Many WebRTC devs were never taught VOIP, and that’s a good thing because they don’t all think the same.”

WebRTC reduces friction for both developers and users in video based applications, and Tsahi pointed out how many large companies now use WebRTC, including Facebook, Slack, Snapchat, and even Kickstarter.

Main industry verticals for WebRTC applications include healthcare, education, experts markets, and on a smaller level job interview services and gaming. Example applications that Tsahi mentioned included ProctorExam (virtual exam proctors for students taking tests remotely), Vedantu (tutoring service), FemiPremium (telehealth), NiNiSpeech (to help people who stutter), Symphony (messaging application for financial services market), and Cepteteb (Turkish bank).

Introduction to WebRTC

Germán Goldenstein from our team at WebRTC.ventures was up next, and he gave an overview of WebRTC, covering the 3 API’s for GetUserMedia, RTCPeerConnection, and getStats. He showed a quick WebRTC call using Jitsi Meet, and sample code for a basic call, and the platforms that WebRTC currently supports.

The Role of Servers in WebRTC

Chad Wallace Hart of Voxbone showed a few more details on the roles of servers in WebRTC. He talked a little more about the Offer/Answer process and signaling in WebRTC, with an example in Socket.IO. The signaling layer is not specified by the WebRTC standard, and Chad pointed out in theory you can even exchange the Session Description Protocol over twitter if you really want. The point is you just need to get that Offer/Answer to the other peer and be able to receive their response.

He also discussed how hard the NAT Traversal problem is, which is how you identify the two peers with unique IP addresses so they can establish the RTCPeerConnection. This is the job of the Interactive Connectivity Establishment (ICE) protocol, which sends ICE candidates back and forth between the peers with the assistance of STUN and TURN servers to establish that direct peer connection.

Chad also gave a great overview of media server configurations like how to use Selective Forwarding Units (SFU) for broadcast or group chat scenarios where a classic P2P WebRTC connection does not scale well. He wrapped up talking about how you can use Gateway servers if you want to integrate your WebRTC app with traditional telephony networks.

Building Scalable WebRTC apps

Daniel Petersson from Google gave a further detailed description of Signaling, and discussed common pitfalls and best practices for building a scalable signaling system. He talked about client/server protocols, dealing with mobile networks, reconnections, etc. He showed a reliable gRPC solution for signaling – gRPC is an open source framework for remote procedure calls that is good for mobile apps, or other situations where low latency, scalability and high reliability are important. (more on gRPC: http://www.grpc.io/faq/) Using a fairly complex architecture with connections servers and a global connection manager, Daniel presented a solution that will scale globally. Interested? It’s best to watch the video for the details. There’s also an interesting question at the end about gRPC vs WebSockets.

How to make every WebRTC call work

Marcio Alfonso from Tokbox talked about how to make WebRTC work on every call. He started with common problems they hear about from customers. These included video quality, or when video or audio cannot be established. How do you answer your customers in these situations, how do you address and avoid problems like these?

Test.WebRTC.org is one site you can ask your problem users to visit in order to confirm that their browser can support WebRTC and that it handles the appropriate, mic, camera, and network connections. Marcio talked about how to find the cameras and microphones available to the user, and to do pre-call checks to help ensure users have the best experience possible.

WebRTC statistics and call quality

Varun Singh from callstats.io discussed how the getStats API works, and how the multimedia protocols associated with WebRTC try to ensure that your video and audio are kept in synch with low latency. The goal is to have optimal audio/video while maintaining low enough latency that you can still have interactivity between the participants.

The getStats API can be called on particular streams and as often as you want, however there’s no benefit from calling more more often than every 150ms or you will get the same results back. Most of the metrics returned are cumulative metrics for that media stream. Looking at those results and correlating them to specific problems you had in your calls can tell you why there were periods when call quality dropped significantly.

Varun is one of the co-authors of the getStats API and so this is definitely a talk worth checking out if you are interested in getting more data on your WebRTC calls!

Debugging WebRTC applications

Philip Hancke (from Appear.in) discussed how to debug your WebRTC apps using WebRTC internals (chrome://webertc-internals). Most of the time WebRTC works great, with high quality, but there are still many cases in production where calls fail and you need to debug why. The WebRTC Internals tool in Chrome will give you statistics and API traces that you can use to understand what happened in your app and where an error occurred. If you run into a bug with WebRTC itself, then getting a dump from WebRTC internals is a crucial step to log your bug with the Google WebRTC team.

Philip also talked about using the getStats API, and how you can log that data yourself while debugging specific issues. Just poll the API on a regular basis and log the data for later graphing.

If the connection failed, the look at ICEConnectionStateChange – the status is probably failed. So look at the candidates to confirm you are using TURN servers and getting relay candidates.

What about when people can’t hear each other anymore? Sometimes this is due to problems internal to Chrome, when it can’t get access to the microphone after your laptop has fallen asleep. This is why restarting the Chrome browser sometimes fixes this (Google is expecting to fix this bug in 2017).

RTC Stats is also an open source project you can use to get the data from each call and log it, this is a joint project of Tokbox and Appear.in. This can be helpful since getting an end-user to use the Chrome WebRTC Internals tool for you to diagnose their problems is very hard. It’s better to log that data long the way instead.

Philip’s slides are located at: http://hancke.name/webrtc/internals/#/

WebRTC Update and Roadmap from Google

Niklas Blum from Google’s WebRTC team gave a status update on WebRTC and the upcoming roadmap. This is similar to the update he gave previously at the Kranky Geek event in San Francisco one week earlier.

WebRTC was open sourced on June 1 2011 and so it’s now over 5 years old! There are over 2 billion Chrome browsers on the desktop and mobile, and all of them are enabled for WebRTC. That’s just Chrome, but of course there is also large support from Firefox and Opera, and Microsoft has become very involved too with Microsoft Edge. Apple is also actively working on adding WebRTC to the WebKit browser, so this is a positive sign.

In Chrome, there are over 1 billion aggregated minutes of audio and video each week. Plus over 1 petabyte of data is transferred on the WebRTC DataChannel each week. That is still only 0.1% of Chrome HTTP traffic which shows the potential for growth is huge. Google estimates there are also more than 5 billion apps that have been downloaded which use WebRTC. This shows massive adoption of WebRTC – it’s a great 5th birthday for the project!

Niklas gave an overview of the WebRTC API stack, and noted areas they continue to work on such as working with the Alliance for Open Media on video codecs VP8 and VP9. H.264 support is also enabled and hardware encoding is enabled on available devices to help save battery life and processing power. Niklas showed a Google demo video that shows how the VP9 codec provides the same level of quality for about 30% less than bandwidth than VP8.

On the audio side, Google continues to invest in the Opus audio codec and enable it to work better on ultralow bitrates so that audio calls can still perform well in any network.

MediaRecorder was one of the most voted-for features by developers, and Chrome has added support for it starting in Chrome 49. MediaRecorder allows you to record streams locally, which is an interesting use case that Google sees growing.

On the mobile side, they continue to work on iOS and Android video improvements for WebRTC. On Android, Google has also launched native screen captures on Android with version M55 – this allows you to share the full screen even outside your app. Tab sharing has also been added in the desktop screen sharing on Chrome. This allows you to share just a tab instead of the full window or full desktop.

Finally, it’s worth noting that Chrome policies are being updated to allow system administrators to limit UDP traffic on their network to certain ports, which will make it easier for them to allow WebRTC traffic on corporate managed networks and to better traverse networks with authenticated proxy support.

Check out Niklas’ video and all the speaker videos for more details! My summary here certainly does not capture everything.

Thank you KrankyGeek for a great event

Thanks to the KrankyGeek.com team of Tsahi, Chris, and Chad for creating another excellent WebRTC event that produced quality content all of us in the WebRTC development community will benefit from. We’re honored at WebRTC.ventures to have been part of the event and to be one of the sponsors!

If you enjoyed the talks above, and want to dive deeper into mobile development with WebRTC, then you should check out our summary of the Kranky Geek WebRTC Show held in San Francisco in 2016. You can read that summary at our site RealTimeWeekly.co, and while you’re there you might as well sign up for that free newsletter we write on WebRTC and real time development!

Sponsors of Kranky Geek Brazil 2016