May 9, 2018

Better privacy on camera mute in Firefox 60

Contributed by Jan-Ivar Bruaroey,

On a web conference call, have you ever wondered if people can see you? Maybe you’ve tried to decipher the site’s video-mute button, often some red camera symbol with a slash through it—“Is it on or off? Does red mean stop or live? Is the slash telling me I’m muted now, or to click here to mute?”—All the while the camera light at the top of your laptop keeps glaring at you brightly.

We have fixed this in Firefox 60.

We can’t fix the websites, but in Firefox 60, whenever you video-mute, your laptop or USB camera hardware light will now extinguish. Whenever you unmute again, it will light back up. No more worrying if you’re live! (more…)

April 4, 2018

Exploring RTCRtpTransceiver.

Contributed by Jan-Ivar Bruaroey,

Firefox now implements the RTCRtpTransceiver API, a.k.a. stage 3 in my blog post “The evolution of WebRTC 1.0.” from last year. Transceivers more accurately reflect the SDP-rooted network behaviors of an RTCPeerConnection. E.g. addTransceiver() (or addTrack) now creates a receiver at the same time, which correlates better with the bi-directional m-line that begins life in the SDP offer, rather than being something that arrives later once negotiation completes. This lets media arrive early on renegotiation.

But most WebRTC sites today are still written the old way, and there are subtle differences to trip over. Web developers are stuck in a bit of limbo, as other browsers haven’t caught up yet. In light of that, we should probably dive right into two immediate breaking spec changes you might have run into in Firefox 59:

  • Remote tracks are now muted and temporarily removed from their stream(s), rather than ended, in response to direction changes (e.g. from the poorly named removeTrack).
  • track.ids at the two end-points rarely correlate anymore.

Importantly, this affects you whether you use transceivers or not. addTrack (even addStream) is just a tweaked version of addTransceiver these days. This blog will look at how to handle this – tying up lose ends from last year’s blog post – and demonstrate how Firefox works. (more…)

November 3, 2017

Large Data Channel Messages

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

Until very recently you had to be careful about the maximum message size you could send over a WebRTC data channel. Especially if the data channel had been established between Firefox and Chrome. See here for a very good explanation of the problem.

The good news is that bug 979417, a big contribution by Lennart Grahl, has landed in Firefox 57, which adds EOR handling to Firefox data channels.

(more…)

September 30, 2017

When your video freezes

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

We recently fixed a regression in Firefox 57 that the max-fs parameter in fmtp lines had stopped working in Firefox 56. Because it got reported to us while Firefox 56 was still in it’s Beta cycle we uplifted the patch for Firefox 56 as well.

It got diagnosed a short time ago that this patch had unforeseen consequences: it can result in Firefox stopping to send video in the middle of a call.
(more…)

June 5, 2017

The evolution of WebRTC 1.0.

Contributed by Jan-Ivar Bruaroey,

March 2018 update: Firefox 59 now implements transceivers (stage 3) as described in this article. Remote tracks are now muted and temporarily removed from their stream(s), rather than ended, in response to direction changes (e.g. from removeTrack). Listen to stream.onremovetrack instead of track.onended.

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…)