Over-the-top or through the network?

Standards can be a burden. Proprietary over-the-top services have shown that public Internet can be a viable transport for secure, high-quality communications. However, for telco service providers, globally accessibility and the lack of regulation create challenges to launch new real-time communications services via the Internet.

Strict firewalls deployed by most enterprises are configured to block and/or suppress Internet access to hosted unified communications and other interactive services. Also, privacy and confidentiality are a basic requirement for Internet-based communications, with encryption adding communication overhead and complexity to endpoints.

Firewalls can be configured to block IMS protocols when carried natively over IP on different transport protocols (e.g. SIP over UDP/TCP/TLS, RTP over UDP, MSRP over TCP/TLS…) and although 3GPP standards exist for tunneling IMS protocols over IPsec (e.g. TS 43.318, TS 33.234 and TS 33.402), these solutions still do not work over firewalls which block IPsec.

Faced with these issues, there has been several approaches and proposals from vendors but now Acme Packet is working on an emerging standard known as Tunneled Service Control Function (TSCF), which delivers an infrastructure-based alternative for real-time, over-the-top (OTT) communications. This new network element has been proposed for standardization to the Third Generation Partnership Project (3GPP) which already approved initial specifications to be included in TR SA3#68 (TSCF Control Message Header & Control Message TLV’s for TSCF).

TSCF High-level architecture

Diagram courtesy of The Packet blog

Tunneled Service Control Function makes use of TLS tunneling (very similar to HTTP/HTTPS) and HTTP_CONNECT mechanism for allowing IMS traffic to flow seamlessly through all types non-IMS firewalls. Endpoints, upon registering to the network, initiate a tunnel, which persists as long as the application is active and which is capable of transporting all the signaling and media flows that comprise real-time communications sessions. Unencrypted SIP and RTP flow securely within the tunnel, minimizing the overhead caused by separately encrypting (SIP/TLS and SRTP) the individual flows.

Looking into WebRTC

WebRTC is an HTML5 standard being drafted by the World Wide Web Consortium (W3C) Web Real-Time Communications Working Group and the Internet Engineering Task Force (IETF) Real-Time Communication in WEB-browsers Working Group with first working on standardizing the interaction with HTML and the second the underlying protocols. The framework was open sourced in June 2011 by Google under a royalty free BSD (Berkeley Software Distribution) style license as Google bought the company Global IP Solutions which owned the intellectual property.

WebRTC framework includes iLBC (Internet Low Bitrate Codec), iSAC (Internet Speech and Audio Coder), G.711, and G.722 codecs for audio and VP8 for video. These codecs include capabilities such as packet loss concealment and echo cancellation so they can robustly cope with a lack of guaranteed quality of service.

Although still under development, WebRTC standards aim to provide simple access to a robust, state-of-the-art, real-time voice and video engine, placed in the web browser, along with all the transport and security tools required to make it work. However, it is important to highlight that WebRTC is only a media tool, without any specific signaling channel. Technology relies on the developer to implement session management mechanisms to establish and manage real-time communications between two or more parties.

Traditionally, the roles of signaling and media in real-time communications are fairly straightforward:

  • Media or bearer, is the channel, stream, or circuit that is actually carrying the voice or video image across the network;
  • Signaling is separated from media, and responsible for user management, including identity, authorization and authentication, charging, location management, and routing.

Although signaling and media are separate, they are connected at the core of any real-time communication service because the signaling must negotiate and establish the media sessions. WebRTC abstracts signaling by offering a signaling state machine that maps directly to PeerConnection.

WebRTC also manages a number of practical issues: includes and abstracts key NAT (Network Address Translator) and firewall traversal technology such as STUN (Simple Traversal of User datagram protocol through Network address translators), ICE (Interactive Connectivity Establishment), TURN (Traversal Using Relay NAT), RTP-over-TCP (Real-time Transport Protocol over Transmission Control Protocol) and support for proxies.

However, a deeper look into the WebRTC landscape shows that there are still a number of technical battlegrounds and topics to debate:

  • Codec choices: particularly VP8 vs. H.264 for video;
  • Current draft WebRTC vs. Microsoft’s proposed CU-RTC-Web vs. other proprietary approaches;
  • The role of WebSockets, PeerConnection, SPDY and other assorted protocols for creating real time-suitable browser or application connections;
  • Signalling protocols adopted along with WebRTC – SIP, XMPP…;
  • Specification support across major browsers and devices, including when and how.

Both Cisco and Ericsson are fans of H.264 being made a mandatory video codec for WebRTC as it is widespread on the Internet and mobile devices and it is acknowledged for its good quality and bandwidth-efficiency. But it is not open-source and requires royalty payments. On the other hand, Google’s preferred VP8 is royalty-free but has limited support today.

From an end-to-end solution architecture perspective, there are also several aspects to define and clarify such as the roles of WebSockets (a browser-server protocol) and PeerConnection (browser-browser protocol) as well as the role of SIP (server/gateway-centric). In browser-to-browser communications scenario, there is very little space for communications service providers but without a server-side infrastructure able to connect and inter-work WebRTC applications with our endpoints, WebRTC will be the Internet equivalent of a pair of walkie-talkies blended into applications and web-pages.

There is an exciting open space for network vendors to close the gap on SIP/IMS-based platforms supporting WebRTC. It will be interesting to see how vendors design their solutions: Application Servers vendors will present WebRTC-to-SIP Gateways but SBC vendors might have an edge as they are seat on the network border and can enforce security mechanisms preventing exposing the network core.