RCS or WebRTC? Maybe Both?

Virtualization Reality

RCS or WebRTC? Maybe Both?

By Frank Yue, Technical Marketing Manager  |  March 17, 2014

Mobile data services are becoming robust and fast enough to reliably support real-time multimedia streaming due to the introduction of 4G LTE networks. VoIP through OTT providers and VoLTE are starting to become ubiquitous. Vendors such as Skype (News - Alert) are delivering services with a high consistent quality and the communications service providers are delivering VoLTE voice services at an increasing rate of adoption.

The next stage in this evolution of real-time services in the mobile environment is the delivery of multimedia services such as images, video, and other content through different technologies in the wireless network.  There are two primary competing technologies vying to provide the vehicle for these services.

Data Services in an All-IP and LTE World

The first is the Rich Communications Suite, created in 2007 and managed by the GSMA (News - Alert). RCS was designed to deliver voice and multimedia services such as chat, file sharing, and video calling in a 4G LTE environment. RCS leverages the same IP multimedia subsystem infrastructure that is required for VoLTE communications. 

The IMS architecture relies on SIP communications to manage the connection for RCS services.  By utilizing the same architecture and infrastructure as the VoLTE services that are being delivered, CSPs are able to realize a significant savings in infrastructure costs and operational support.

HTTP Delivers Ubiquitous Transport

The primary competing technology is web real-time communication. WebRTC was released as open source in 2011 by Google (News - Alert) and is backed by the World Wide Web Consortium. WebRTC, as the name implies, is an API that allows people to use the HTTP protocol through web browsers to connect with real-time communications such as voice, chat, video, and file sharing. WebRTC takes advantage of the ubiquitous nature of web browsers and the dominance of the HTTP protocol as an application transport method.

It is important to note that both RCS and WebRTC technologies require some directory services technology to find and connect users and devices to each other. In RCS, the directory services lookup is performed through the IMS infrastructure and SIP. SIP addresses are located through a directory service to determine the IP address where the user resides. If this IP address is at a phone number, there is process to map an E.164 number to an IP address through the ENUM DNS extension.

There is no one standard for the lookup of users through WebRTC and mapping them to an IP address for connection purposes. WebRTC is designed to be inherently agnostic to the signaling method to identify and connect users to each other. Some implementations leverage the existing SIP protocol and can leverage the IMS infrastructure already in place. Other models use identity information found in other applications such as DNS or even web identities found in social media applications like Facebook (News - Alert).

Competing or Complimentary?

These technologies are not necessarily exclusive and competitive in all scenarios. As mentioned, WebRTC could utilize SIP as the signaling method to identify and connect users through the same IMS infrastructure that supports RCS. WebRTC is also designed to be used in any environment where there is access to an HTTP browser or user agent. This includes smartphones, PCs, laptops, tablets, and other devices that have HTTP agents available.

RCS is designed to be utilized through wireless networks that implement an IMS architecture.  This means devices that have 4G LTE connections, for the most part. This is limited primarily to smartphones and tablets that have applications to take advantage of the RCS architecture. As such, RCS must be implemented and supported by the mobile CSP (News - Alert).

This means that there may not be the technology standards fight between RCS and WebRTC that many people have been predicting. It is probable that both real-time communications architectures will exist and even pleasantly co-exist for the foreseeable future.

Frank Yue is the technical marketing manager at F5 Networks (www.f5.com).

Frank Yue is the Technical Marketing Manager for the Service Provider vertical at F5 Networks. Mr. Yue has over 15 years of experience building large-scale networks and working with high performance application technologies, including deep packet inspection, network security, and application delivery. He is based in North Carolina and is a scuba diving instructor in his spare time.

Edited by Stefania Viscusi