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.

H.265: high-quality mobile video or low-bandwidth video?

The International Telecommunications Union (ITU) has announced the first stage for H.265 video codec standard has been completed and that the new codecs will be twice as efficient in video compression, requiring half the bandwidth for the same quality as H.264 compressed video.

The new standard is intended to improve video on smartphones, tablets, TVs, and other devices as screen resolutions increase over the next 10 years, while reducing the burden on wired and wireless networks. Notice that today’s estimations point to half of all network traffic to be video, which should go up to as much as 90 percent of all network traffic by 2015.

The current specification, also known as MPEG-4, is the most used video-compression standard in the world, according to ITU. It’s the coding and decoding system for more than 80 percent of all Web video and is used to deliver high-definition video over broadcast, cable, satellite, and Internet TV. H.264 is also used in mobile phones, video conferencing, digital storage, and Blu-ray discs.

Informally known as ‘High Efficiency Video Coding’ (HEVC), H.265 has been drafted in August of 2012, supporting resolutions up to 7680-by-4320, enough for the new Ultra HD (4K and 8K) resolutions. Work is also underway to develop an extension of H.265 for stereoscopic and 3D video coding.

The new standard is expected to be more efficient than its predecessor, H.264 Advanced Video Coding, but how much better it will perform is a crucial question to understand if it will be enough to justify widespread industry adoption.

Studies (see Comparison of Compression Performance of HEVC Working Draft 4 with AVC High Profile by Bin Li, Gary Sullivan and Jizheng Xu and Comparison of the Coding Efficiency of Video Coding Standards – Including High Efficiency Video Coding (HEVC) by Jens-Rainer Ohm, Gary J. Sullivan, Heiko Schwarz, Thiow Keng Tan, and Thomas Wiegand) show that on average, H.265 outperforms H.264 by 39% for random access scenarios (e.g. broadcast) and by 44% for low delay scenarios (e.g. video calling). Meaning that H.265 codec can achieve the same quality as H.264 with a bit rate saving of around 39-44% bandwidth.

What most media reports seem to have focused on is the potential effect that H.265 will have on bringing us closer to 4K video resolution in OTT delivery, speculating that H.265 will allow 4K video to be delivered over the Internet at bit rates between 20 and 30 Mbps. But given the current state of video streaming technology, we can actually be able to deliver 4K video at lower bit rates when the time comes for 4K streaming. Moreover, as many studies show, the law of diminishing returns applies to video/image resolution too – if you sit at a fixed distance from your video display device eventually you will no longer be able to distinguish the difference between 720p, 1080p and 4K resolutions due to your eye’s inability to resolve tiny pixels from a certain distance.

Historically, bit rates used for OTT video delivery and streaming have been much lower than those used in broadcasting, consumer electronics and physical media. On average:

  • Digital broadcast HDTV: ~19 Mbps for video (in CBR mode);
  • Blu-ray (1080p): ~15-20 Mbps (in 2-pass VBR mode);
  • Streaming video (720p): ~2.5-3.5 Mbps;
  • Streaming video (1080p): ~5-6 Mbps.

Whereas Blu-ray aims to provide a high-definition movies, streaming/OTT is completely driven by the economics of bandwidth and consequently only gives us video at the minimum bit rate required to make the video look generally acceptable. Considering that currently, 1080p video is being widely streamed online using H.264 compression at 6 Mbps, then 4K (4096×2304) video could probably be delivered at bit rates around 18-20 Mbps using the same codec and similar quality levels. Switching from H.264 to H.265 compression we can expect 4K video at bit rates closer to 12-15 Mbps!

Posted on Feb 11, 2013