Yet, there are some obstacles for WebRTC deployment, like lack of complete mobile support. Also, in many cases it is more convenient to use a native client. Native client is understood as an RTC client built for a specific system such as Android, iOS, WP8 etc. Such applications give a developer more freedom in accessing a device’s APIs, and allow creating more customized clients tailored to render certain functionalities and to work with a particular back end solution.
By contrast, the WebRTC browser’s API is simplified and does not allow any deeper control of the engine. The challenge, then, is to make the WebRTC client work with the native client.
Even though WebRTC uses open standards, they are not necessarily supported by native clients already deployed by a provider.
Firstly, mobile dialers are usually SIP based with RTP for media transport. WebRTC does not define the signaling path at all. To interwork with SIP, a protocol translation has to be employed through a Web to SiP gateway which translates commands sent over a web based communication channel (for example, Web sockets) to a server which converts them to SIP.
As for the RTP, the browser’s implementation allows only encrypted RTP, i.e. SRTP; so, this is another requirement which must be met by the mobile dialer. The encryption is enforced for both audio and video streams.
Native mobile VoIP dialers usually come with support for the most popular voice codecs like g729 and some wideband codecs like AMR, g722 or SILK. For video there is h264. WebRTC opted for the OPUS codec for audio and VP8 for video, which for many reasons is a very good choice in terms of quality and the fact that they are royalty free. The good news is that they are also open source and available for various platforms, including mobile ones, and can be incorporated into a media engine used in our own application.
Another important feature of WebRTC is the ICE mechanism, whose use is also mandatory. Interactive Connectivity Establishment is the most efficient NAT traversal technology when establishing a session in which both clients are trying to find a path for sending media to each other. They will try to connect peer to peer and if this is not possible, they will fall back to media relay server (TURN). This combination enables traversing most NATs. In addition, peer to peer greatly offloads a provider’s network and enhances quality (assuming the peer to peer path check is faster than through the relay server path).
Summarizing the above, the approach taken by WebRTC designers is really well thought out and utilizes the best available open standards. It caters for VoIP communication security, HD voice with efficient audio preprocessing, and video codec, which is now becoming standard for web video. tThis is what users expect from communication services nowadays.
For a provider, it means that it has to revamp its mobile dialers to meet the above specifications.
VoipSwitch provides a complete framework for OTT and Rich Communication Suite mobile dialers for building fully customized private label clients compatible with WebRTC.
More on the VoipSwitch solution can be found here: