WebRTC Disruptive Potential to Communications Networks

This is the first of our WebRTC articles this week, Greg Zweig, Director of Solutions Marketing at GENBAND, introduces WebRTC and suggests that its solid engineering and developer-accessibility has the potential to disrupt how we communicate today.

Some background on VoIP

Until fifteen years ago communications networks were primarily built on predictable and reliable circuit-switched networks.  In the late 1990s Voice over IP (VoIP) started making inroads as it allowed service providers to better leverage the massive investments they were making in data networks; they could simply add voice as another application.  It’s easy to see their logic, why keep building two networks when they could invest in one and use it for multiple services?  In the end, the basic math couldn’t be denied, VoIP won.  However, it’s important to appreciate that the pace of change is slow and that even today, the majority of voice services are still circuit switched.

VoIP has gained the most ground in new network builds such as fibre to the home and cable television.  More recently VoIP is being used in mobile networks that have adopted 4G.  Service providers learned quickly that there is a big difference between making one VoIP phone call that connects quickly and sounds fine and creating a network that consistently supports tens of thousands of calls.  Not surprisingly, as a VoIP call traverses more networks and touches more devices the opportunity for issues grow.  Service providers quickly found that customers were far more accepting of VoIP when it was deployed in a more predictable network environment with a well understood set of endpoints.

The explosion in Internet access and IP-connected devices have made it more and more impractical to try to limit endpoint choices or potential connectivity paths.  The trade-off for greater flexibility assures occasional issues with disparate audio and video devices, variations in OS or hardware platforms, local network or Internet access limitations as well as issues with intermediary elements like NAT or firewalls or VPN.  Additionally, basic issues such as blocked media stream routes between the devices or incompatibilities with the media encoding are still common.

Certainly, all of these issues can be solved.  If you’re a massive global cloud service provider looking at providing “freemium” voice and video services to complement your application suite then you could roll up your sleeves and start building some great end-user software apps that solve many of the client related problems.  In fact, maintaining a walled garden for the user community is just another way of streamlining variables to manage quality.  Deploying Session Border Controllers (SBCs) can ease firewall and NAT issues and in theory the SBC could encrypt every call.  Unfortunately, many of these answers may be fine for a walled garden but they don’t actually encourage extemporaneous communication.  They may be cost-effective for narrowband voice access with a low peer-to-peer call ratio but they don’t necessarily scale for mass-market peer-to-peer HD voice and video.  And, the reality is that encryption is rarely applied while lowly narrowband G.711, not HD, often prevails.

Introducing WebRTC

A more radical approach was taken when WebRTC emerged.  Initially driven by Google, WebRTC specifies how two endpoints on the internet can securely, reliably and cost-effectively establish a session to exchange real-time voice, video and data.  Today it is natively implemented in Chrome, Firefox and Opera browsers and is made available through a JavaScript API that an average web developer should be able to understand.

 

WebRTC defines internet tolerant and royalty free-codecs to promote an interoperable high definition experience.  It mandates security for media flows between peers to ensure security is not an option but is also not difficult to implement.  It leverages ICE to be facilitate peer-to-peer connections where possible, dealing with NATs and minimising usage of media relay servers.  Media can even be configured to run on TCP port 443 (common HTTPS port) so that it busts through firewalls often found in corporate or guest WiFi networks.

WebRTC implementation in the browsers abstract the details of the OS and the platform, manage audio/video input devices and provide things like echo cancellation (it is a joy to simply “talk-at” your laptop built-in speaker/mic/camera and not fuss with USB headsets).

WebRTC does not however specify what it should be used for or how two [or more] parties should locate each other and exchange connectivity information.  The common expectation is that this will be done using well understood web client-server protocols (secure, reliable, firewall tolerant and supported by web browsers) and will be considered as part of other user identification and communication flows already provided by the web application.

WebRTC your Application

The network engineering and developer-accessibility of WebRTC catalyse the integration of real-time communications into web applications.  Web applications today usually operate at a tangent to the communications network with users pivoting between them to meet their objectives.

With WebRTC, the expectation is that communications will become an embedded part of the application.  Where we have an ability for a buyer to send a message to a seller on an e-commerce website, this can be extended with WebRTC to provide real-time voice and video.

The fact that users do not need to install software on their machines means that you can build services which are only used occasionally.  The ease of application development means that you can build services that might serve a very specific niche of users.  The royalty free clients, preference for peer-to-peer media and attention to security means that you can build services that might serve a global user base of millions of users.

Not the complete picture

Stepping down from the hype, there are still things that need to be worked – not least the place that WebRTC has on mobile devices.  You can run a WebRTC app in a compatible browser on a compatible smart-phone but it might not be how users actually want to use your application (they use an installed “app”) and you may be restricted in user experience because browser applications can’t receive notifications or access the device address book.

It is also not quite as easy as you’d like to get started… there is still some generic “state machine” requirements to deal with for the WebRTC implementation, its use of ICE and the co-ordination between the two parties.  And, there is still some wrinkles between different WebRTC engines in browsers or apps.

We’ll deal with these points in a subsequent article but we should also see that there is sufficient positives with WebRTC and industry momentum that there is no excuse for not getting started with the technology.  It is quite simple to dip your toe into the WebRTC water and see how it might change your application or relationship with your customers.

Try out WebRTC for yourself… GENBAND KANDY is a real-time communications Platform-as-a-Service that provides access to voice, video, rich-messaging and collaboration services using WebRTC as an enabling technology.  Developers can sign up to KANDY and start using their free accounts to run Quick-Start tutorials before integrating into their own applications.  ITSPA UK members can enter their KANDY applications and ideas into the GENBAND UK Summer of Apps competition. http://www.trefor.net/events/webrtc-apps-competition/

Loads of posts on WebRTC in general on this site here.