|Issue:||North America II 2014|
|Topic:||Although WEBRTC is disruptve, carriers may be winners by providing WEBRTC-ready quality internet access|
Karl Ståhl, Chairman and CTO of Ingate Systems AB and merged Intertex Data AB, founded both these companies which developed the world’s first SIP-capable firewalls and since then has been driving global real-time multimedia communication to take over in the POTS world. These Swedish companies have 25 years of experience of innovative telecommunications and development of high-quality communication and security products. Ståhl holds several patents in the audio, electrical, security and IP communications fields. Stahl was recently honored with the WebRTC Pioneer Award (2014).
WebRTC is gaining momentum, but its standards need to be in place and implemented in major browsers. The network-provided TURN server is essential for full and proper resolution of firewall traversal and usage over all network types. It also returns control to the network administrator and can prioritize WebRTC media for quality. WebRTC usage in the enterprise PBX, UC solution and call center may come early.
The features and benefits of WebRTC
WebRTC brings features and functions that make us question why those features aren’t already available to us. A child in front of a smartphone can point out the use cases:
• Why can’t I just click on the support button, rather than having to stretch out for the phone and dial a number? And what bug makes the sound inferior and removes the picture from this smartphone, just because I use the phone app?
• Why do I have to go through all these irritating voice menu DTMF keypad entries before reaching the call agent, when all that information and more is already available after I logged in to their website?
• I can enjoy HD-quality movies, YouTube videos and music and even record such myself, but when I communicate with a person using the base functionality of the (smart)phone, I only get pre-AM radio quality audio!
The simple idea behind WebRTC is that nowadays the web browser is well standardized and always available in every connected device. Standardizing and implementing high quality real-time communication capabilities with media directly between the Web browsers is just where we want it when finding someone on the web to communicate with.
The disruption is overdue
It is sometimes claimed that we don’t pay for quality or multimedia and thereby WebRTC is of little interest. I would rather question how there can be 50 years of lost Moore’s Law development to recover in the most important and valuable IT and communication market segment. With devices capable of telepresence HD and HiFi quality, and broadband access being widely available, we are only getting the Plain Old Telephony Service (POTS) pre-AM radio quality voice. It cannot be unnoticed that since the days of AM radio we have enjoyed FM radio, black-and-white television, stereo, high-fidelity, color television, high-definition television etc. The enterprise PBX transformation into unified communications with real-time communication far beyond POTS service also proves the value.
The consequences and implications are huge. Much traveling will be saved, by having telepresence video conferencing available for everyone, everywhere.
The main disruption for carriers has already happened
After the iPhone was introduced, it became evident that the value carriers bring to their users is the Internet connectivity (named OTT in the mobile world) rather than the telephony service. As a consequence, carriers have invested heavily in 4G/LTE networks for OTT bandwidth delivery and are now charging for gigabytes rather than for telephone calls.
Charging gigabytes instead of service
Charging for usage of network resources is healthy for both the carrier and its users, but will be even better if the network resource was not just data gigabytes. The available bandwidth can be better utilized by providing prioritized transport for quality demanding real-time traffic and down-prioritized transport for bandwidth-hungry but delay-insensitive streaming video like movies and TV.
No one is disturbed by waiting a few seconds for a movie, while such a delay makes surfing a pain. Internet traffic simply has to be delivered in different quality or priority classes. The gigabytes supplied to customers have very different user values for surfing, real-time communication and streaming video.
Forward-thinking carriers will be prepared for that the major WebRTC will be over the Internet / OTT and will require more valuable priority gigabytes.
NAT/firewalls blocking real-time communication
The NAT/firewall traversal issue has plagued real-time communication since VoIP was introduced. SIP-based real-time communication mostly uses session border controllers (SBCs) for firewall traversal.
WebRTC instead uses IETF-standardized ICE/STUN/TURN to traverse firewalls being unaware of the real-time traffic that has to pass through them. Those methods are similar to what Skype uses and the far-end traversal methods for remote SIP clients.
None of these methods can take real-time traffic through the most restrictive firewalls. However, a blessing of the ICE/STUN/TURN protocols is that they allow a TURN server with one WAN interface and another LAN interface to open a controlled path paralleling the firewall (rather than fooling the media traffic through a firewall unaware of what is happening).
Thus, such a network-provided TURN server can fully resolve the NAT/firewall traversal issue. Media will not take an extra turn via an external turn server and control of what is allowed on the private network is back in the right place. The WebRTC application is also relieved of the burden of providing the TURN server. ICE can then be seen as a legitimate pre-protocol requesting a controlled media path through the firewall.
Standards have to be in place and politics set aside
A standard for auto-discovering and using network-provided TURN servers is in progress with the IETF.
Mandatory HD video codecs also have to be agreed upon before wide adoption of WebRTC. Hopefully both Google’s VP8 (or even better VP9) and the already widely used H.264 will be mandatory, as downloadable codecs can remove concerns about royalties and patent infringements for both codecs.
Mozilla’s Firefox WebRTC browser is announced to support both VP8 and H.264 by year’s end.
Microsoft’s and Apple’s support of WebRTC cannot be expected until the H.264 video codec is among the mandatory ones, at which time we may see integration with Microsoft’s Skype and Lync and Apple’s Facetime, allowing a WebRTC browser to be used as their client.
Quality and the network provided TURN server
The network-provided TURN server is also required for routing the media into pipes specifically provided for real-time traffic. Such pipes are frequently provided for voice e.g. in carrier’s huge triple-play deployments, when SIP trunking with PBXs over MPLS, or using a separate Internet access for real-time media only.
Such network-provided TURN servers can prioritize the real-time traffic over data traffic at the often data-congested Internet access router or firewall. It can also set DSCP bits for further prioritization in diffserv types of networks and request bandwidth in reservation types of networks.
Without bandwidth reservation, WebRTC cannot be successfully used in MSOs cable networks and over the mobile OTT / Internet access. Network-provided TURN servers can be integrated VDSL, cable and fiber access CPEs.
The quality efforts within the IETF are not focused at using the available network-level quality mechanisms and will have limited success.
While some have no quality concerns about WebRTC even though it is 30 percent more bandwidth hungry than voice, others question if OTT access can provide the required quality and be as good as VoLTE.
WebRTC quality can be perfect over unmanaged LTE OTT access, but not when it is data-crowded, heavily used or under other less-than-perfect conditions. Then the bandwidth reservation mechanism has to be used to protect the WebRTC media from packet loss.
The OTT access uses the same underlying IP network and bandwidth reservation as VoLTE and if that mechanism is put to use, e.g. by a smart TURN at the DPI point, the quality should be equal and sufficient.
Killer applications and integrating with SIP-based services
WebRTC applications by themselves, such as video conferencing with Facebook friends instead of just chatting with them, will be widespread when WebRTC is available in all major browsers.
A variety of other WebRTC applications that use the Internet / OTT without involving any application-specific network such as IMS and VoLTE, can be expected.
Using WebRTC as an Internet client for the Rich Communication Suite multimedia of IMS (marketed under the joyn name and only available in the mobile world as an extension to VoLTE) requires a WebRTC/SIP gateway already offered by some vendors. It will bring multimedia capabilities to IMS using fixed, Wi-Fi or mobile OTT Internet access. However, since a global multimedia telephony service based on IMS/RCS requires widespread IMS peering between carriers, a fast growth cannot be expected, especially since most LTE networks are only used for OTT / Internet delivery and don’t implement IMS and VoLTE.
WebRTC browsers can be used as clients for the enterprise PBX, UC solution or call center as soon as WebRTC browsers and WebRTC/SIP gateways have matured and can soon be a killer application due to the built-in NAT/firewall traversal for remote PBX users and the telepresence quality video conferencing capability. If such gateways have a WAN and LAN interface, WebRTC traffic can parallel the firewall and use both SBC and TURN technology for traversal and prioritization at the often data-congested enterprise Internet access without waiting for further standards.
Avaya demonstrated the call center killer application at the recent WebRTCIV conference. A logged-in customer could call the right call agent within their SIP UC infrastructure by clicking on a web page button, while all customer information was provided to the call agent. Such web-based click-to-call applications will be widespread when WebRTC is available in the major browsers.