Context aware communication

Bowser – The World’s First WebRTC-Enabled Mobile Browser

Start experimenting with WebRTC on mobile devices

Ericsson Research today proudly announces the world’s first WebRTC-enabled browser, called Bowser, for mobile devices. Mobility is part of Ericsson's DNA and we are very excited to provide developers with a mobile browser that they can start experimenting with. This commitment to WebRTC from Ericsson Research is a continuation of the the world’s first WebRTC-enabled browser for desktops that we released in May of 2011.

Bowser will finally enable web developers to add audio and video functionality to their mobile web applications. A web application can establish audio and video calls with another device or call audio/visual services using the WebRTC API that Bowser implements and exposes.

Some browsers on mobile devices limit the use of the <video> element to fullscreen only; Bowser does not have such limitations. It is possible to render the video in an application controlled by part of the screen or in fullscreen. The video below demonstrates a video conferencing application, showing how the remote video can be non-fullscreen as well as fullscreen. It also shows how you can add even more advanced CSS effects to the self-view. We think developers will have a lot of fun with this.

As with our previous WebRTC implementation efforts, the media engine in Bowser is based on the powerful GStreamer framework. To avoid confusion, we would like to clarify that we are not using the framework. Having independent implementations of WebRTC, using different media back-ends will help push the WebRTC standard forward.

The API definition is still evolving in the standard bodies (W3C and IETF), we have chosen an earlier version of the API for this particular release, but we aim for full standard compliance in the future.

For Bowser, we have selected to implement the H.264 video codec. H.264 is a well-known codec with proven performance and quality. The audio codec currently used in Bowser is the G.711 codec.

A description of the version of the API that we have implemented, including application examples, can be found in the sample code page. The Bowser page includes the known limitations of the current Bowser implementation as well as a list of devices on which we have verified Bowser functionality.

Ericsson Research will continue to update Bowser to improve the stability and media quality, as well as move to a newer API as it becomes more stable.

We welcome comments, questions, feedback, and bug reports on Bowser. The channel for communication is the Google group “Ericsson Labs WebRTC”. Bowser is available today as a free download from iTunes App Store and Google Play.

If you are interested in future updates related to Bowser, please follow our blog. Happy hacking!

-- The Ericsson Research WebRTC Team


starlog's picture

bravo on bowser. does it support websockets (for SIP interworking)?

Maxim's picture

What is the address videochat?

StefanAlund's picture

WebSockets are currently only supported in the iOS version of Bowser.

StarryNight's picture

It's great to see a WebRTC implementation for iOS and Android, but don't the existing WebRTC implementations use VP8? Just trying to understand whether Bowser is expected to be compatible with Google's WebRTC and other existing implementations. It is confusing because I don't understand the benefit of supporting WebRTC if it is not compatible with other implementations.

StefanAlund's picture

The discussion on which video codecs should be supported in WebRTC is currently being debated. The main 2 candidates that has been put forward is H.264 and VP8. Google suggest VP8 as a mandatory-to-implement codec, while H.264 was suggested by Apple, Microsoft, Ericsson, Cisco and others.

Google's Chrome uses VP8 and Bowser supports H.264, i.e. at the moment these browsers are not compatible.

afullagar's picture

Which H.264 vifro codec is being supported H.264 AVC or SVC. I thought AVC was licensed and SVC / VP8 was not? SVC is the way to go not AVC. And why not iLBC for a narrowband codec so that voip pbx's can support interop? Whats the point of not following the WebRTC API and standards being developed. Is that just vendor arrogance getting in the way of a good solution?

afullagar's picture

vifro = video :)

Subscribe to Comments for &quot;&quot;