Firefox 49 was released and release notes can be found here. In this post we are covering 3 main topics from the release note.
- Better support for specs and synchronization with Chrome – This comes to close gaps Firefox had with the specs themselves and the implementation in Chrome. There are several sub-items to this one
- Improved bandwidth management – This topic includes a groups of SDP related items that allow for unidirectional media and better bandwidth handling
- NAT traversal tests – This item is about a SW NAT server developed by the Mozilla team to allow for testing NAT traversal in different NAT topologies
Has immediate impact on those supporting Firefox in their application.
Firefox 48 is the current stable version so version 49 will become a stable release in the coming weeks.
Better support for specs and synchronization with Chrome
Several bugs reported for Firefox were related to non-compliance with the standards. These are now fixed. The getUserMedia Specs are considered final, so fixing these issues is very good news for all apps out there. The webrtc specs (add stream, add track, ….) are less advanced (in the standardization process) but quite stable nowadays, and this is a good step forward as well.
Most of the APIs changes in Firefox 49 represent changes from the original PeerConnection API to the object model API. Media Streams lose some of their importance, becoming mainly containers, and tracks become the main objects, with corresponding APIs to manipulate them.
Of course, adapter.js is updated accordingly by the Firefox team and is still the recommended way to support WebRTC APIs while the specs are not final.
Here is the list of bugs fixed:
- Added support for MediaStream.getTrackById(). (See bug 1208390.)
You cannot query a track by it’s ID directly, as per the specifications. Tracks become their own objects, mostly separated from mediastreams. - getUserMedia(cam+mic) is now all-or-nothing. The MediaCapture and Streams spec [1] says that sites requesting both camera and microphone at the same time, must get both or nothing (in the form of an error). (See bug 802326.) – Implementation has now changed to conform with this so in case of failure getting either mic or camera an error will be returned and both media sources will not be received by application.
- Aligned with spec: Fixed issue where ontrack and onaddstream fired too late. (See bug 998546.) – The onAddStream event is supposed to be fired almost as soon as the remote Description was set, independently of the number of tracks, and independently of the negotiation being over or not. However, early implementation in firefox would wait for all the track information being available before they fire this event. In most cases, it would result in a much longer delay than necessary before the event gets fired. In some very unfortunate cases (where the stream has no track), a stream would be created but the event would never be fired! This version of firefox fixes that.
- Allow any MediaStream to be passed to RTCPeerConnection.addTrack. (See bug 1271669.) – In earlier versions of firefox, medistream was a full object that would own addTrack allows now to be passed in a MediaStream which does not own the track. The MediaStream is mainly used as an identifier / accessor.
Improved bandwidth management
The SDP specs include a lot of features that are not mandatory with WebRTC but can be useful. Some of them have been included in Firefox 49.
a=inactive allow to negotiate unidirectional media (I’m sending you my video, but I’m not expecting you to send me yours).
b=TIAS is one of the SDP lines that allow bandwidth handling, but with a different granularity than the already supported b=AS. TIAS is for setting bandwidth limitation by controlling only the maximum size of payload (media itself) that is being sent in a packet. b=AS on the other hand includes all that goes on the wire including transport overhead.
Note that:
1. While Chrome supports usage of b=AS in the SDP, internally it computes TIAS metric.
2. The WebRTC specs point to TIAS and not AS.
REMB and TMMBR are two feedback mechanisms of RTP send media used for bandwidth congestion control, including the speed of ramping up bandwidth consumption at the beginning of a call (how fast it increases bandwidth consumption until congestion occurs). While enabling them can lead to slower set up of a call in full resolution, enabling this provides better stability all together.
REMB is a proposed standard by Google, and has been included in Chrome, and the WebRTC stack, for some time now. Firefox 49 decided to go for the more established and standardized TMMBR. However, while implementing, they realized that adding REMB support was a compilation flag away (since Firefox use parts of the same WebRTC stack as Chrome). Those mechanisms have been both added, and are turned on automatically.
Here is the list from the Firefox release notes:
- Properly handle a=inactive in the remote SDP during renegotiation. (See bug 1213773.)
- Implement receiving ‘b=TIAS’ on media description to restrict sending bandwidth. (See bug 1276368.)
- REMB is now enabled by default. (See bug 1155435.)
- Enabled TMMBR support by default. (See bug 1270230.)
NAT traversal tests
The Mozilla team has developed a full software NAT server (in python) to test ICE against. While not as versatile as the NTT approach [slides here], it allows for testing of many if not all NAT configurations without setting up virtual networks.
Mentioning in the Firefox release notes:
- Automated tests now include NAT simulation and TURN server mochitests. (See bug 1231975 and bug 1231981.)