June 5, 2017

The evolution of WebRTC 1.0.

Contributed by Jan-Ivar Bruaroey,
You can view a recording of a related Q&A session on WebRTC standards from Monday 5/05/17 here.

The WebRTC spec is nearing completion, going to Candidate Recommendation real soon. With Google planning to finish 1.0 in Chrome by the end of the year, it seems a good time to recap what this means, as far as changes to what folks are doing today.

Under the hood, the biggest remaining obstacle to advanced wire interop, is that, unlike Firefox, Chrome hasn’t implement the spec’s “Unified Plan” for multiple audio and video tracks yet. Be sad or happy, but this blog isn’t about bridging that gap through SDP mangling. At this point, it’s probably better to wait for Google to address this.

But web developers need to prepare, because the JavaScript API will be different. This may be a surprise to those who haven’t followed the spec. A good start is to look at what Firefox is already doing. But there’s more. I don’t mean superficial things like promises, which all browsers support now. Instead, expect a change in the media model. (more…)

June 2, 2017

Fiddle-of-the-week: microphone constraints

Contributed by Jan-Ivar Bruaroey,

Two new microphone constraints got standardized last week, available now with adapter.js or Firefox Nightly:

{ autoGainControl: true, noiseSuppression: false }

Handy if you’re a musician or a doctor (or both), since audio in WebRTC, unsurprisingly, is tuned for talking heads by default, not guitar riffs or listening to heartbeats remotely.

Basically, Firefox and Chrome have had these since forever with vendor prefixes, but they’ve remained underappreciated. Maybe hearing the difference will help?

The following shows off other bits of the media capture spec as well. This demo only works in Firefox right now because it uses applyConstraints, which Chrome doesn’t support just yet. (more…)

May 4, 2017

Moving STUN address gathering to the parent process

Contributed by Michael Froman, crossing IP communication streams since 2005

E10s (for electrolysis) adds multi-process to Firefox. With e10s, the parent Firefox browser process communicates with background child processes responsible for hosting web related content. For some users, depending on installed add-ons, e10s availability started as early as Firefox 48. In the effort to improve security and enable future additional sandbox restrictions on the content process, Firefox’s STUN address gathering now happens via Inter-Process Communication (IPC) in the parent process not in the content process. (more…)

April 6, 2017

Active ICE TCP to punch through firewalls directly

Contributed by Nils Ohlmeier, Hacking on real time communications since 2002

Iceberg with hole near Sandersons Hope 2007-07-28 2

With the landing of bug 1335939 in Firefox 54 we will finally turn on active ICE TCP connections by default.

Does ICE TCP matter for me?

In essence it means that Firefox will try opening ICE connections over TCP towards any other ICE endpoint which provides ICE TCP candidates where it is listening for incoming connections. The most common use case for this is Firefox now being able to make direct TCP connections to media servers without the help of TURN TCP. (more…)

March 15, 2017

Debugging encrypted RTP is more fun than it used to be

Contributed by Nils Ohlmeier, Hacking on real time communications since 2002

If you ever were in the situation to try to find out why the video quality of your WebRTC call was not good, you probably have also sworn at the encrypted RTP and RTCP. Instead of trying to put log statements into your locally compiled Firefox version, you can now simply request logging of the RTP and RTCP packets.

Bug 1343640 adds support in Firefox version 55 to log the RTP header plus the first five bytes of the payload unencrypted. RTCP will be logged in full and unencrypted. (more…)

March 13, 2017

Fiddle-of-the-week: await WebRTC in Firefox 52

Contributed by Jan-Ivar Bruaroey,

This isn’t a post about a new WebRTC feature. Rather, we’ll explore the new async/await JavaScript syntax in the just-released Firefox 52 and Chrome! Two new keywords let us write asynchronous code the same way we’d write synchronous code. WebRTC APIs, as you’re probably aware, are quite asynchronous. Luckily they support promises – a requirement to use this new syntax – and it just works! I’ve always found callbacks and even monadic promise-chains hard to follow, but now we can write short, yet meaningful code that gets stuff done. (more…)

March 2, 2017

Firefox’s audio backend

Contributed by achronopoulos@mozilla.com,

Let us talk about Firefox’s backend audio system. Every sound you hear while you are watching a video or using a WebRTC service comes from the backend audio library. The role of the library is to communicate with audio devices and to provide audio input and/or output. This library is called ‘cubeb’ and it is part of the Firefox source code.

(more…)

February 27, 2017

Fiddle-of-the-week: Downscale video in RTCPeerConnection

Contributed by Jan-Ivar Bruaroey,
You can view a recording of the Q&A session on WebRTC standards from Monday 2/27/17 here.

 

More of last year’s new laptop cameras have few or no low-resolution modes. These reveal a big difference in how Chrome and Firefox implement the getUserMedia camera API. Whereas Chrome re-scales video to whatever constraints you put in, Firefox does not, instead guaranteeing the closest native resolution. Both are technically within spec. That said, the elaborate constraints language offered by getUserMedia, with minmax ranges and ideal values, was clearly designed for resolution discovery; it is overkill for setting a target resolution override.

But sending large resolution video over a peer connection is expensive. Here’s how you downscale it in Firefox (more…)

February 25, 2017

Fiddle-of-the-week: Spec-compliant getStats

Contributed by Jan-Ivar Bruaroey,

Firefox has supported getStats to the spec for a couple of years now, and Chrome Canary finally has a spec-compliant version, so it’s a good time to check in how to write code that (soon!) will work across browsers.

Unfortunately, the specification has changed several times over the years, even breaking Firefox. Here’s how to tell whether your getStats code is up to spec as of 2017 (more…)

February 22, 2017

DTMF available in Firefox Beta

Contributed by dminor@mozilla.com,

Firefox Beta now supports DTMF. Try it out now in webrtc samples! This means you no longer need workarounds to accomplish this.

The spec JavaScript API we’ve implemented is newer and different from what is in Chrome at the moment. Therefore, we recommend using adapter.js until Chrome updates their API. That way, you only deal with one API that works on all browsers.

In the new API, the dtmf sender already exists, so you don’t create it. It hangs off of the RTCRtpSender associated with a track. So instead of writing the following (more…)