Peering into the Communication Crystal Ball: WebRTC

The reaction is all too recognizable—that “a-HA!” moment—a slight tilt of the head, followed by a look that suggests that the mind is racing.  I had that reaction when I first began to learn about Web Real-Time-Communications (WebRTC), and I saw it again last week in the widening of the eyes of those realizing that WebRTC has the potential to shake the foundations of real-time communications.

Last week, Acme Packet participated in the Illinois Institute of Technology Real-Time Communications Conference (IIT-RTC) in Chicago, which brought together some of the key, instrumental figures in guiding the ongoing efforts toward WebRTC.  Organizations ranging from Google, Microsoft, Voxeo, Mozilla, AT&T, and Digium, to the IETF and FCC engaged in an open discussion and debate, providing a glimpse into the IP communications crystal ball.  The Illinois Institute of Technology prides itself on being a key contributor to research and development in areas like Real Time Communications (RTC), providing the perfect setting for the discussion.

What is WebRTC? Getting into the Technology

Although the standards for WebRTC are still undergoing development, WebRTC provides simple access to a robust, state-of-the-art, real-time voice and video engine, which is placed in the web browser, along with all the transport and security tools needed to make it work.  Web developers are given access to use it in any application they can imagine, tapping into the creativity of one of the largest, most dynamic development communities around. 

It is worth noting that WebRTC is only a media tool, without any specified signaling channel.  The technology still relies on the web developer to exchange the session information to establish and manage real-time communications between two or more parties.  Signaling is left completely up to the developer to choose a mechanism that they feel suits the application best.  This point has sparked debate in the past within the standardization efforts, and it was a topic at the IIT-RTC event as well.

Traditionally the roles of signaling vs. media in RTC are fairly straightforward: 

• The media, or bearer, is the channel, stream, or circuit that is actually carrying the voice or video image across the network. 
   
• The signaling is separate from media, and is traditionally responsible for items supplementary to the media. It establishes a namespace for a given RTC service, which includes things like managing user identity, authorization and authentication, charging, location management, and routing.  

In the traditional public switch telephone network (PSTN), telephone numbers could be considered a namespace for the service. In more modern SIP networks, telephone numbers may be SIP URIs, and signaling establishes and manages users and sessions within and between domains. 

Although signaling and media are separate, the two are connected at the core of any RTC service because the signaling must negotiate and establish the media session.  The real-time session establishment of WebRTC boils down to this fundamental notion of negotiation, requiring only that two endpoints negotiate a session description, leaving all the other attributes of signaling up to the application.  Some may compare WebRTC to SIP, but this would be like comparing apples to oranges.  WebRTC is decidedly without a traditional signaling protocol, so you could say that WebRTC is the absence of SIP in it’s purest form – peer-to-peer communication.

WebRTC at the IIT RTC Conference

This fact sparked up a lively discussion during an IIT RTC panel with Tim Panton from Voxeo Labs, Bernard Aboba from Microsoft, Harald Alverstrand from Google, and Anant Narayanan from Mozilla.  Some asked, “Without a standardized signaling protocol for WebRTC, are we not creating service islands and signaling non-interoperability?” 

Harald proposed that services on the web are happy to build islands.  Indeed, not having a mandated signaling protocol provides freedom for an application to utilize the namespace and signaling that they already have established within their service.  Tim added that, “We are making islands with WebRTC, and it doesn’t matter.  WebRTC is communications for the web.  It is not a telephone.”  Most on the panel seemed to agree that having RTC in the browser will mean that the context within a web service can be maintained and extended into real-time communication. 

Henning Schulzrinne, CTO of the FCC, gave a contrasting perspective in his presentation, mentioning that WebRTC provided a new access technology to the traditional RTC networks.  Joshua Colp of Digium presented new capabilities within Asterisk that enabled WebRTC communications.  This showed how an established signaling channel, served by Asterisk, could be leveraged and opened to a flexible, programmable, and ubiquitous client—the web browser.  Having a common signaling language is truly one of the strengths of the traditional RTC networks.  It allows interoperability between many devices, vendors, and services, and it is what allows users to be able to contact anyone, anywhere.  Giving the web secure and simple access to the established signaling channel of enterprise PBXs, call centers, IMS networks, VoIP networks, and the PSTN provides existing providers a new and exciting way to deliver their services.  Acme Packet would consider this the service-reach component of what a session delivery network should provide.  Allowing traditional RTC providers to participate in the rapid innovation that the web development community is known for, while utilizing investments in traditional RTC infrastructure, can truly allow them to have their cake, and eat it too.

In all, the week provided a fantastic forum for thought-leaders in the emerging area of WebRTC.  Possibly the one thing everyone could agree on, is that WebRTC represents significant shifts in the way we communicate over IP networks.  While the technical answer to, “What is WebRTC” is easy, clearly the philosophical answer depends on who you ask.  Perhaps the true beauty of WebRTC is in the eye of the beholder, and it will mean many things to many different services—and probably all at the same time. 

Regardless of its application, certainly new session delivery challenges will emerge, and the lessons we’ve already learned will become applicable in new places.  Acme Packet’s pragmatic approach, and focus on addressing the underlying challenges of delivering real-time IP communication sessions, gives Acme Packet’s session delivery network a strategically important role to play in the unfolding future of enterprise, government, and service provider networks.  For most peering into the IP communications crystal ball, the notion of having access to ubiquitous real-time communications tools in almost every type of device might be meaningful in different ways, but it is sure to provide a common reaction as one ponders the possibilities.

Biography: Reid Stidolph is a Senior Systems and Sales Engineer at Acme Packet, where he works on aligning technology with Mobile Network Operators (MNOs) and Multi System Operators (MSOs) in North America.  He specializes in VoIP and Data architectures and technologies such as IP Multimedia Subsystem (IMS) and Evolved Packet Core (EPC). Reid also has a focus on web technologies, and their interactions with communications networks. He studied Electrical Engineering at the University of Wyoming, and has over 12 years’ experience in networking and telecommunications. In addition to his current role at Acme Packet, Reid's professional career includes experience with rural wireline Local Exchange Carriers (LEC), nationwide VoIP and Broadband carriers, and wireless network operators.