Mozilla’s Firefox is harnessed by almost 20% of all internet users, which makes it the third most popular browser worldwide.1 When WebRTC on Firefox is combined with Chrome’s market share, the total percentage of the world’s WebRTC-enabled browsers comes to 63.84%. As an open source project since its release in 2004, Firefox is the only Big Three browser that remains entirely in the public domain. With its focus on openness and freeness from third party plugins, Firefox embraced WebRTC early in the project’s genesis.
The WebRTC API that the Chrome team released in 2011 has spawned several modified versions. Perhaps most crucial of these is the Firefox WebRTC API, which is maintained by the Mozilla team. The crucial MozillaWiki WebRTC group, founded in April 2012, focuses on WebRTC-based development projects and discussions. In December 2012, Firefox began introducing the three WebRTC APIs into its official source code. As of Firefox 29, WebRTC has been fully integrated into the browser. Chrome WebRTC and Firefox WebRTC have been interoperable since May 2013.
WebRTC on Firefox is essentially implemented in the same way as Chrome WebRTC. Three JavaScript APIs - getUserMedia, RTCPeerConnection, and RTCDataChannel - form the core architecture of Firefox WebRTC. getUserMedia captures and transmits media through the computer’s microphone and video camera. RTCPeerConnection transmits this data in an offer/answer model via a signaling mechanism. RTCDataChannel is capable of sharing arbitrary data (text chat, file sharing, etc.) Taken together, these APIs are capable of documenting and transmitting almost any conceivable form of real-time data.
From a larger view, the most pressing issue facing a Firefox WebRTC developer is not the API code itself, but rather the external, server-side signaling mechanism that allows peers to establish connections with each other. This crucial mechanism is not included with the Firefox browser. The solution often comes in the form of a preexisting signaling platform, such as OnSIP's. Our mature, scalable SIP signaling platform is primed to traverse the complexities of NAT and firewall based impediments that obstruct clear communication between peers.
WebRTC on Firefox uses the same APIs as Chrome WebRTC, but the projects are not completely identical implementations. WebRTC on Chrome has a few features that Firefox’s version does not. Although the G.711, Opus, and VP8 codecs are natively supported by Firefox, the iLBC, iSAC, and G.722 codecs are only natively supported by Chrome. The exclusion of these codecs from Firefox WebRTC only affects applications where specific voice frequencies are required.
The signaling mechanism of a WebRTC application solves the issue of interoperability between Firefox WebRTC and Chrome WebRTC. The offer/answer method is used by the signaling mechanism to compare the getUserMedia specifications of each caller, and then a shared codec is implemented to initiate the connection. If a Firefox browser attempts to connect to a Chrome browser using the iLBC codec, then the signaling mechanism will force the Chrome browser to adopt either G.711 or Opus to be compatible with Firefox. Signaling platforms, such as OnSIP's, automatically negotiate these matters of browser interoperability during the offer/answer phase of the call.
By recent projections, it appears that Firefox may surpass Internet Explorer’s market share in the near future. Regardless, as a technology that bolsters a fifth of the internet, Firefox is integrally important to the future of the web. Mozilla’s speedy and successful bid to incorporate Google’s project into its browser speaks to the WebRTC API’s effective and efficient design. Now that interoperability issues are behind them, Firefox and Chrome can communicate with different forms of WebRTC without any noticeable disruptions. Now over half of the internet has been equipped with in-browser, real-time communications.
1. “Global Browser Stats” - StatCounter ↩