White Paper

eXeCuTiVe oVerVieWMobile network operators (MNO) are investing signifi cantly in the high-speed LTE and IMS network infrastructure to deliver richer forms of communication services, such as Joyn, which supports contacts, chat, fi le and video share together with voice and video services (VoLTE).

Although MNOs are building and delivering these real-time communication services, generating new revenue remains no easy task. They continue to witness declining service revenue and lose customers to free Over-The-Top (OTT) and Internet-based services, such as Skype and Facebook. WebRTC (Web Real Time Communications) technology offers many great opportunities to take advantage of existing investments by extending communication services to new customers, creating new services and augmenting old ones.

In this white paper we will look at this exciting emerging technology, how it can benefit MNOs and, most importantly, its impact on existing IMS/LTE MNOs network architecture. This paper is the fi rst in a series; future ones will examine different deployment use cases for WebRTC-enabled devices, networks and services, and how to ensure the reliable network infrastructure needed to realize the opportunities from WebRTC.

WebrTC: TeChnoloGY oVerVieWWebRTC is a standard-based technology that allows a Web or mobile application to use the browser to deliver robust real-time voice, video, data and conferencing services (as depicted in fi gure 1). This is like a browser-based multimedia telephone, or softphone, that is interoperable not only with other browsers, but also with other communication system, such as the PSTN or VoIP. Historically, attempts to build real-time solutions depended on expensive special hardware and custom-built software, placing tremendous demand on infrastructure. But thanks to WebRTC it has become possible to defi ne necessary interfaces in the browser platform to deliver any kind of real-time communication solutions. This is all due to the faster, high-speed computing hardware commonly available today.

In a traditional client-server browser model, by user request the browser downloads the content (HTML/JavaScript/CSS) from the Webserver and then executes and displays it in the browser. WebRTC adds a standards-based real-time communication function interface in the browser (seen in figure 2). This function is an enabler for delivering real-time communication services across Web browsers, which can be controlled using simple JavaScript APIs and HTML5 from the downloaded content.

WebrTC: MoneTiZinG oPPorTuniTYAccess to the Internet via browsers has become a fundamental activity in both personal and business lives. More than a billion devices—from tablets and smartphones to PCs—already support browsers and that number is expected to increase to four billion by 2016, according to Disruptive Analysis. This means that client devices for WebRTC are already used widespread and affordably available. This is the biggest opportunity for MNOs.

MNOs can capitalize on this opportunity by extending existing IMS services they already offer to mobile customers to a new, wider subscriber base, enhance current services to existing subscribers and create new services. As an example, a VoLTE user can establish multimedia communications with a non-VoLTE user running a WebRTC-compatible Web browser on their PC. For MNOs, this signifi cantly expands the pool of clients able to access their IMS services by connecting to “last unconnected” devices (as seen in fi gure 3).

Figure 2. WebRTC browser model

Figure 1. Browser-to-browser RTC

Betting on WebrTC: Technology overview and architectural impactsBy Kader Khan, Product Line Manager, EXFO

© 2014 EXFO Inc. All rights reserved.

White Paper

But the benefi ts of WebRTC don’t begin and end with extending service reach. Some of the other MNO opportunities include:

1. Connecting WebRTC users with legacy PLMN and PSTN voice users through the IMS infrastructure, creating convergence between their legacy network and Internet telephony;

2. Facilitating Network Function Virtualization Infrastructure (NFVI) to host their own or third-party WebRTC value-added services to specifi c verticals, such as education and healthcare;

3. Strengthening enterprise service offerings, such as browser to IP-PBX, unifi ed communications, contact centre, voice and video conferencing;

4. Enabling interworking with consumer-based services, such as SMS and MMS with WebRTC users; and

5. Delivering their own “Telco-OTT” WebRTC services or partnering with third-party WebRTC OTT players.

In a nutshell, WebRTC promises an opportunity for MNOs to become more than bit-pipe providers, and offers monetizing opportunities by leveraging their existing strength and expertise in authentication, security, policy, charging, roaming and handover. This technology can help ease of development, functionality and time-to-market.

WebrTC: arChiTeCTure anD ProToCol sTaCKsFor easy understanding of architecture, let’s look at a basic WebRTC triangle architecture (in fi gure 4). In this architecture a mobile phone with ‘Browser M’ and a laptop with ‘Browser L’ are connected via a Webserver. To establish real-time media communication, both devices have to know each other’s media capabilities, which are exchanged using a call control signaling protocol. Such signaling protocol is not specified in WebRTC standards and is left for application implementers to decide.

The steps required to establish RTC session between browsers are:

1. Both browsers download the WebRTC application (HTML5/JavaScript) from the webserver;

2. Both browsers exchange call control signaling message via Web server (with in-built signaling server in this case) to negotiate and agree on media capabilities;

3. Finally, both browsers establish RTC media path directly with each other for audio, video and data communication.

WebRTC uses unique peer-to-peer media fl ows, where audio, video, and data connections are established directly between browsers. However, browsers are typically hidden behind Network Address Translation (NAT) and fi rewalls, which complicates the establishment of peer-to-peer media sessions. As such, procedures and protocols, such as ICE or Trickle ICE, STUN and TURN, are required to make peer-to-peer media fl ows work.

Figure 4. WebRTC triangle architecture

Figure 5. STUN NAT traversal

Figure 3. IMC client access to others

© 2014 EXFO Inc. All rights reserved.

White Paper

A simplifi ed version of the ICE procedure using STUN protocol to establish peer-to-peer RTC media (as illustrated in fi gure 5) is:

1. Both browsers discover their own public IP address by contacting STUN Server using STUN protocol messages;

2. Both browsers exchange their discovered public IP addresses (ICE candidates) in call control signaling message using SDP offer/answer mechanism;

3. Both browsers perform connectivity checks (ICE hole-punching) to ensure the peer-to-peer connectivity is possible; then

4. RTC media session is established and media is exchanged.

In certain cases of a highly-restrictive NAT or fi rewall, though, such direct paths will fail and only the TURN server can be reached. This will result the media being relayed through the TURN server (as depicted in fi gure 6).

The standard-based interoperable communication model and protocol stack for WebRTC technology is defi ned in detail (see fi gure 7) by the Internet Engineering Task Force (IETF). These are:

› The Signaling stack, which as stated before is not defi ned by WebRTC but left for implementers to decide. We will use SIP-over-WebSocket (SIPoWS) as the signaling stack in our examples. The HTTP protocol is used for downloading the HTML5/JavaScript application content to the browser

› The NAT stack resolves peer-to-peer connectivity issues over NAT.

› The Media stack is used to send and receive RTC audio and video. IETF standards have mandated G.711 and Opus as voice/audio codecs. The video codecs are not yet mandated, but H.248 and VP8 are being considered. This stack is also used to exchange RTC data. Examples are Message Session Relay Protocol (MSRP) used in real-time messaging, Binary Floor Control Protocol (BFCP) used in real-time conferencing and T.140 used in real-time text services.

WebrTC: iMPaCT on Mno neTWorK arChiTeCTure As we’ve seen, WebRTC triangle architecture is best suited for browser-to-browser Internet communication and uses WebRTC protocols and stacks. In contrast, IMS architecture uses different protocols and stacks. To support WebRTC user access to IMS requires an architectural change—the addition of a WebRTC Gateway that supports the interworking between the two (as shown in fi gure 8). The new architecture should support a unifi ed authentication framework between WebRTC and IMS users, as well as a Policy and Charging Control (PCC) function that allows WebRTC users to use QoS function of the LTE/EPC access network.

The WebRTC gateway has to support both signaling and media function for WebRTC-IMS Interworking (as shown in fi gure 9). The important signaling interworking functions that a WebRTC gateway must support are:

1. Signaling protocol translation, for example SIPoWS to SIP;

2. WebRTC SDP extension normalization to IMS SDP extensions, such as RTP multiplexing/de-multiplexing;

3. ICE candidates exchange towards the WebRTC UE; such as Public IP address returned by STUN server; and

4. The confi guration of the media functions according to the negotiated capabilities.

Figure 6. Media via TURN server

Figure 8. WebRTC-IMS interworking

Figure 7. WebRTC stack

NAT

Media Signaling

STUN TURN ICE

Voice/Video Data

SRTP SCTP

SIP

WebSocketHTTP

DTLS DTLS TLS

UDP

IP

L1

TCP

© 2014 EXFO Inc. All rights reserved.

White Paper

The important media interworking functions a WebRTC gateway must support are:

1. ICE hole punching and keepalive messages towards WebRTC UE, for example STUN connectivity checks and keepalives;

2. Media transcoding and multiplexing/de-multiplexing capabilities, such as Opus to G.711

3. And, terminate DTLS-SRTP messages and mediate towards the RTP variant used in IMS.

Network equipment manufacturers (NEMs) are currently either evolving their existing product or introducing new products (WebRTC gateways) that include WebRTC-IMS interworking functions. Examples of the existing products being evolved to handle this interworking are Session Border Controller (SBC), Media Gateway Controller (MGC) and Media Gateway (MGW).

WebrTC: enD-To-enD floWSo far we had explained WebRTC technology, MNO opportunities, architecture and requirement of WebRTC gateway. Let’s put all these pieces together and examine WebRTC from an end-to-end fl ow perspective. In this example, the key considerations are:

1. A WebRTC user is calling a VoLTE user connected Via IMS;

2. The WebRTC user is also connected to a Webserver and STUN Server; and

3. The WebRTC gateway supports WebRTC-IMS interworking functions.

Note: For simplicity, LTE/EPC access network attachment, PCC fl ows, NAT traversal on IMS and unifi ed authentication fl ows are not shown in this example.

Figure 10 shows the end-to-end fl ow is categorized in to six easy steps. They are:

Step 1 – The WebRTC user downloads Web application content from the Webserver to his or her browser.

Step 2 – The WebRTC user upgrades the HTTP port (80 or 443) to WebSocket in the WebRTC gateway to send SIP messages over WebSocket. If not WebSocket transport, the SIP messages will be blocked by the HTTP fi rewall.

Step 3 – The WebRTC user and VoLTE user register to the IMS network.

Step 4 – The WebRTC user gets a public IP address from STUN server, after which it originates the call to VoLTE user, and exchanges and agrees on media capabilities via SDP offer/answer. The ICE candidates (private and public IP addresses) are also exchanged. The WebRTC gateway performs necessary signaling interworking function.

Step 5 – The WebRTC user initiates connectivity check (ICE hole punching) with the WebRTC gateway for every ICE candidate that was exchanged. Once this connectivity check is passed, a DTLS-SRTP media session is established between WebRTC user and WebRTC gateway. In the IMS network, an SDES-SRTP or RTP session is established between VoLTE user and WebRTC gateway. The media is exchanged between both WebRTC and VoLTE users, while the WebRTC gateway performs necessary media interworking function.

Step 6 – All done. The WebRTC user disconnects the call with VoLTE user or vice versa.

Figure 9. WebRTC signaling and media functions

Figure 10. WebRTC user calling VoLTE user call fl ow

EXFO Headquarters > Tel.: +1 418 683-0211 | Toll-free: +1 800 663-3936 (USA and Canada) | Fax: +1 418 683-2170 | info@EXFO.com | www.EXFO.com

EXFO serves over 2000 customers in more than 100 countries. To find your local office contact details, please go to www.EXFO.com/contact.

White Paper

ConClusionWhile WebRTC offers MNOs great opportunities to leverage existing investments in their IMS networks, it is not without a considerable impact on that network. In particular, using WebRTC to extend IMS services to browser users requires network architecture changes that support interworking through a WebRTC gateway or similar equipment.

If smartly introduced to the network—with an eye on the impact and changes that must be incorporated—WebRTC can truly benefit MNOs struggling to compete and recoup infrastructure investments. All the hard work and investment made to meet the high demand for real-time services can be transformed into an opportunity to more effectively reach tomorrow’s customers and bring exciting new services to existing ones.

The firsT in a seriesThe customer expectations in today’s highly-competitive environment leave little room for failure in the delivery of such innovative technologies and services. Only by offering uncompromising performance can operators maximize their goals. This is best done by understanding how WebRTC affects the existing networks and services to ensure the reliable network infrastructure in the labs in order to mitigate live network failures to avoid customer dissatisfaction.

In the next part of this series of whitepapers, we will investigate different deployment use cases for WebRTC-enabled devices, networks and services to help MNOs get a better jump on the WebRTC opportunity and succeed.

WHITEPAPER039.1AN © 2014 EXFO Inc. All rights reserved. 2008

Printed in Canada 14/04