WebRTC World Feature Article

October 02, 2013

Convergence Between Telephony and IP Services - How Network Operators Can Offer New Added Value

By TMCnet Special Guest
Metin Sezer, Product Manager, Contact Center and WebRTC, European Computer Telecoms AG

One of the biggest challenges for carriers is how to deal with the Internet and IP services. If they are not careful, they will earn less and less money with voice telephony and will be, due to a lack of new services, reduced to being mere bit-pipes. Competition would only be in who can offer the highest bandwidth. However, bandwidth becomes a commodity and there is hardly any money to be earned. At the same time, always providing more bandwidth is a costly endeavor.

With voice telephony, operators’ core business, they still have a very good source of revenue. Yet here the battle rages. Because maintaining voice networks is costly and many analysts regarded it as outdated and without a future, some carriers also see it as a dying technology. They reduce personnel and hardly invest in their voice networks.

Operators would have to add new value to voice telephony by intelligently merging telephony and Internet services. There is an ongoing debate in their think tanks how new applications for corporate and private subscribers could be provided with regard to the opportunities the Internet offers, and how carriers can include the ingenuity of the app developers out there.

Merging telephony with applications on the Internet/intranet

In the corporate sector there are more and more standardized data services that are used over the Internet or intranet. Examples are LinkedIn, SAP or Outlook. The trend is to include these services when providing telephony. Imagine: a subscriber wants to reach a colleague who is, according to his Outlook Calendar, in a meeting. The incoming call will, depending on the calling party’s number, go to the voicemail, or there will be a busy sign, or the call is sent to a colleague. It is possible that the called party receives the message via e-mail or as a message in LinkedIn or a similar business application. Here, the operators’ strength lies in offering added value by incorporating Internet services.

There is a similar development with contact center solutions: they combine the processing of agent’s phone calls with social media, like Facebook and Twitter, as well as with services like Salesforce.

For the private subscribers, there are also new scenarios when telephony and social media move closer. SMS can be sent as direct messages in Facebook and also as tweets. The same way, a voice message or MMS can be displayed as a Facebook direct message or timeline post.

The designated SMS successor joyn should work in a similar way, even though this may be hard to realize, technically: there are security concerns and it is costly to implement. With an easier solution that converges telephony and IP services, operators would have a much lower risk.

New opportunities with WebRTC

WebRTC is the new buzzword in the telecommunications industry. This new technology, propagated by Google, turns the browser into a voice and video telephone. The user opens the browser on the PC, tablet or smartphone and can talk to another user from browser to browser. An additional device or softphone is not required. As with Skype, the communication happens over the Internet, which is bad news for operators.

Nevertheless, here it gets interesting because WebRTC is far from having all the features and functionalities that are known from the telco network. The best example: there is no call control. There is no search and find either because a WebRTC subscriber is not reachable over a telephone number. WebRTC lacks the intelligence of the good, old voice telephony.

There is no interconnectivity between WebRTC and non-WebRTC users, either. Per default, it is not possible to call a PSTN, thus one cannot dial a number. At the same time, a WebRTC user is not reachable from the telco network, as he does not have a phone number.

This is the big opportunity for network operators. They can connect WebRTC with their IMS core (IMS= IP Multimedia Subsystem) and create convergence between their network and internet telephony. When they treat a WebRTC call like an ordinary phone call that runs through their network, they could even charge for it.

This enables the convergence with classical telephony. If someone calls a WebRTC user who does not have the browser open, the telephone could ring instead. If a subscriber does not pick up the phone, the call could be transferred to the browser, in case the user has it open.

Embedding WebRTC into the telco network

From a technical perspective, this is a solvable task, even though WebRTC uses a proprietary protocol to transmit the call control. The signaling is based on WebSocket, where speech is usually transmitted via RTP (Real-Time Transport Protocol). To make the convergence between WebRTC and the telco network work, the network has to “speak” WebSocket. A WebRTC gateway helps, which translates WebSocket into the standard signaling protocol in IMS i.e. SIP (Session Initiation Protocol).

Providers of IMS infrastructure make this possible. They turn the WebRTC user into an IMS subscriber by translating WebSockets into SIP via a gateway. This is the easiest way to use WebRTC over a PSTN and makes it irrelevant, which devices both parties are using.

New opportunities with open networks

Things get exciting when operators provide an API (Application Programming Interface), open their networks and integrate WebRTC. They open their networks for third parties that write apps that run in the browser and, via WebRTC, use the resources in the telco network.

These apps can be complex contact center or PBX applications but also videogames in the browser where players in a multiplayer game talk to each other in real-time over WebRTC. Programmers use HTML5 to write their applications in the browser because, thanks to HTML5, the browser becomes a programmable platform. It is up to the creativity and imagination of these developers, which other applications are possible. They have the reliability of a telecoms network to their avail.

The API should make life easier for the app programmers. Some say the REST API in RCS could take over that role. However, a JavaScript API is better suited to enable developers to use resources in the network, like call control. Telecom networks are highly complex; there is a large variety of protocols managing the call control. For app developers, whose strength is internet applications, this would be a very big challenge. They need an API that bundles the complexity in a way that they can handle it easily without having to learn things anew. Nothing is better suited than a JavaScript API.

The same technology enables developers to include internet application into their apps. These can be social networks but also business applications like LinkedIn, Oracle, Salesforce, services by Google or SAP. All these services have their own APIs and app developers can use them. They can e.g. integrate the Google Calendar into a PBX app. Information from the calendar influences what happens to the incoming call. It is also possible to include multiple social networks and applications simultaneously.

To keep complexity at bay, APIs from these services should also be bundled into one handy JavaScript API. Thus app developers use one JavaScript API each, to converge voice telephony and Internet applications in the browser. To enable them to do so, operators will have to open their networks and make the APIs available to these programmers.

New sources of revenue thanks to openness

This enables new sources of revenue for carriers. They can charge the app developers for using their network; they can offer app stores and rent shelf space there. They can also demand a share in the revenue of each app. Or they can license the usage of their APIs and charge for it. There are many different options.

Network operators that want to be more than just a bit-pipe must offer their customers real added value, embrace new technologies like WebRTC and converge classical telephony and Internet services. They would have to open their networks and move their offering into the browser. There they can offer their customers convergent services that use well-adopted services like Facebook, Salesforce and Google via APIs and add WebRTC to them. Doing this, they rely on resources from the telco network.

Of course, operators can react defensively to WebRTC, block the service or charge for it. They can try an arms race with ISPs and declare having the highest bandwidth their business model. However, they would not offer their customers added value and it remains questionable whether this is future-proof. Instead, they can open their network and enable new applications. WebRTC enables them to explore new business and new sources of revenue by intelligently converging telephony and the internet.

Metin Sezer is an expert in value-added services. He started his career as a software engineer, moved to project management and ultimately to pre-sales and product management within European Computer Telecoms, where he’s been working for over thirteen years.

He has deep knowledge on IVR and contact center technology as well as their integration into a carrier’s network. Due to his activity in pre-sales, Metin has excellent connections to Tier 1 carriers around the world, where he finds out about their particular requirements and explains them how they can incorporate WebRTC in their network to offer even more added value.

Edited by Rachel Ramsey


Free WebRTC eNewsletter


Featured Videos