This is a part of our interview with Oxagile CTO & Co-founder Sergey Marchuk about his impressions, feelings & future projections on the WebRTC advancements left after the second geek community meetup – WebRTC Conference & Expo in Atlanta.
I: Were there any topical hot issues discussed at the Conference?
Sergey: Well, I’d like to point out two WebRTC development roadblocks: (a) cross-browser compatibility, meaning support from Apple and Microsoft, and (b) video codec debate and WebRTC performance on mobile devices aimed at making this solution viable and mainstream for common users with an average mobile device.
I: So, when do we get WebRTC support for iOS?
Sergey: I talked to the guys from Google. By the end of this year they promise WebRTC support for iOS (they never say when). However, a number of companies have already managed to establish WebRTC running on iOS, they had to spend a lot, probably too much time and efforts to make that happen.
I: The WebRTC initiative is a project supported by the largest web browser owners like Google and Mozilla. What are Microsoft and Apple up to?
Sergey: Microsoft became much more flexible in terms of new technology support in Explorer. “Internet Explorer 10 is rather well-polished browser when compared to its previous versions and now offers a bunch of nice, well-tuned features. Last week Microsoft contributed a piece of code to Firefox open-source project”. We shall not expect them to block WebRTC development.
Whereas, Safari from Apple with its 4% global web browser market share represents little interest to WebRTC technology spread-out.
I: What about WebRTC on mobile devices? Is it something that already lures users to abandon Skype and Viber clients on their handhelds and plunge into plugin-/client-free communication?
Sergey: Well, not yet or at least not all mobile users can take advantage of this technology now. The owners of flagship power-boosters in Google Nexus line can indulge themselves in mobile RTC, others are still constrained by hardware performance of their devices.
As we have said before, currently there is no problem to use WebRTC on mobile web browsers like Chrome for instance as long as hardware capacity of a particular devise is enough to ensure the required performance.
The major blocker today for this type of browser communication is that super-optimized open-source VP8 codec by Google lacks hardware encoders, that’s why developers have to resort to software-level encoding, which, in turn reduces the performance of mobile devices.
However, many chipset producers ensure to include VP8 encoding on a hardware level and start manufacturing mobile devices that support hardware VP8 encoding from the next year. This would mean another step in mobile WebRTC communication.
At the same time, in terms of software support we can witness the shift from browser to native APIs support. These days Google is pushing WebRTC into mobile apps because native-app experience is more common for mobile users than pure mobile web. We have not tried yet, but Google has released an API for Android and, as I have mentioned before, its team has promised native iOS support by the end of this year.
I: Any interesting WebRTC-related projects you can share with us?
Sergey: In general, I see great future for WebRTC development. Especially when it comes to peer-to-peer usage that Oxagile company is currently most interested in.
Oxagile has been working on several projects with XirSys, a California-based company specializing in real-time web communications.
The value of Xirsys is that it lets you establish peer-to-peer connection between browsers using one line of code without any third party tools or plugins.
Instead, when you are working with “plain” WebRTC you are required to do additional steps. First, you need to establish a connection between involved parties. Then TURN server goes. When peer-to-peer connection between browsers is unavailable, users are relayed through TURN servers. According to statistics, 14% of connections go through TURN.
Learn more about Oxagile WebRTC initiatives here.