Did-The-Telco-Bell-Ring

What is WebRTC for Telcos?

Did the Telco bell ring?

Did-The-Telco-Bell-RingI often read statements from the “Internet advocates” or from vendors around Telco’s and their views/mistakes in relation to WebRTC, but barely any share experience from within.

I would like to share my thoughts on how the “democratization of voice” is seen by those who (still) earn a large portion of their annual revenues from it. What does it mean when various departments within an operator “want WebRTC” all of a sudden – what is “WebRTC for Telcos” – because sometimes, it is quite far from the obvious.

To follow up my last blog, let me share some first-hand thoughts how I perceive this (of course not only from within the company I work for, but also when I exchange thoughts with peers from various other operators). Some point out the believe the dial tone is still considered more important than actual web development or highlight that to some extent operators are bad for WebRTC. Parts of these arguments are often true. I asked myself: Why do operators most of the time start with telephony or consider IMS first when thinking about WebRTC?

Natural evolution vs the need for radical change

Well, why actually would they not start with it – that is after all the area they know and earn money from? Is it not natural that classical Telco people working day in/day out with SIP and deploying their brand new IMS consider using it for WebRTC as well (especially since IMS is mostly built for telephony)? I fully agree that we need a dramatic shift, but I wonder if anyone thought about how this can happen if not step by step, and how education inside the old structures can be done best in order to do so.

Change will not happen radically for everything, for everyone, for all our services, for our thinking, our culture – not just yet anyways. By doing a radical change in offering communications services, we can of course bet on the future already now, but which manager would risk revenues for the next years just to be the forerunner? Not to mention whether the people are ready (both from their knowledge and expectation perspective) to drive this change. I think it won’t happen overnight, it most likely cannot happen overnight, but that does not mean it is not happening at all.

Taking this into account: What is more natural than evolving your existing services and trying out new things when possible? An internal trial here and there perhaps, some laboratory deployments showcasing some of the functions the fancy new boxes have, but that are not used yet, or a student working on an innovative topic. As outlined by me before, it is easier than ever to try things out. Unfortunately that seems to happen mostly in the labs in a creative way and does not yet impact the thinking of the main organization unit dealing with (tele-) communication at the moment. This has to change!

How does the average Telco learn about WebRTC

Coming back to examining why it is that Telco’s seem to start always with classic click-to-dial use cases and are so keen on getting their IMS hooked up with WebRTC I asked myself: How did WebRTC actually “infiltrate” the average operator fellow’s mind set (of those looking at it at the moment – it is still far from being the majority within an operator) in the first place? Web 2.0 has not done that, neither have apps or Flash, or a move to IP in the core with NGN a while ago. What happened – why now?

At the moment I would say this has happened mostly through vendors. Our current technology vendors (mostly traditional ones that also provided technology decades back) come, present roadmaps, evolution of our currently running services, and also new boxes or features. These presentations are either given to technology and marketing together or separately. I can bet that certainly every single presentation of this kind contains WebRTC.

Here lies also one of the reasons for the Telco’s perception that IMS & WebRTC is closely related: Their first contact point is not Google, the larger Internet vision, or an excitement/drive for new things. They touch base with WebRTC mostly exclusively in relation to IMS and traditional services or the “classical” well-known suspects of “new” IMS services through their known partners.

It is not ignorance of alternatives to IMS or insistence towards SIP as signaling protocol, it is simply because many do not even know there is a need to think for alternatives. For the more conservative parts, using open-source software such as OpenSIPS/Kamilio for SIP in their core or thinking about IMS alternatives is already considered extravagant, and now those folks should question current approaches as a whole, even for their main services and change overnight? This is highly unlikely if you ask me.

Those who did not understand the transition yet and still believe in core legacy principles will most likely not change their view just because of WebRTC.

Operator services have not changed tremendously when the iPhone and apps came along.
Why should it happen now – just because of WebRTC?

Let’s assume people in charge of technology or products heard about WebRTC as described, think (in the context they have learned about it) about new possibilities, and come to ask one day to “add WebRTC to something”.

Now what does that mean?

  • They think about a service that should be accessible in browsers, e.g., an existing service such as “classic telephony”. Usually this means the request does not come along with any further requests. People don’t even think about “more” – new possibilities
  • They like the idea of adding voice or video to some website where this does currently not exist as a feature, but do not yet think about the potential that actually brings along
  • People operating new telephony platforms that evolved to IP will naturally hear about WebRTC, and since it is all IP the assumption of “just adding another end point” is rather obvious. Now they want also “the fixed line accessible with WebRTC”
  • Try out new “WebRTC capabilities” that have been part of a delivery (e.g. an SBC, media server, RCS platform) and simply explore what is now possible “on the web”

I have yet to meet somebody from an operator that till now requests any of the “real” WebRTC differentiators, such as contextual awareness, anonymity, or better codecs, and knows about that being worked on actively outside of some lab.

Chances: Enhance the existing & explore the new

So where do I see chances in the mid-term?

I tried to highlight that already in an earlier post: The Internet world will certainly teach us how to embed communications into the web and will do a much better job than us – despite our history with implementing real-time communication.

It is very crucial not to forget the value that can be delivered by evolving traditional services. New enhanced services are the ones mostly expected from an operator (by that I mean the evolution of services we currently offer) and also the ones where we can calm down controlling by keeping to some extend traditional less-risky operator business models. Maybe not per-minute pricing for the average consumer (but hey, they have flat rates anyways and just need to be properly identified), but for example “call center minutes” towards businesses can easily be charged even if the request is coming from a browser – at least for some time. And if existing traditional services are enhanced, maybe the current subscription will also not be cancelled just yet, even though alternatives arise. I do not suggest to keep this as long term strategy or that no change is needed; rather the opposite: Change is overdue, we’ve missed out before, let’s use our chances now and start with the easiest use cases immediately (it should be easy thanks to “All-IP” one might think).

Looking at embedding communications is also something I would try as an operator, but finding their real potential that will result in commitments of investing into it will take time I believe. I urge absolutely everyone to try gathering experiences in this area, but not to have too high expectations in the beginning. The cheering about the future value is unfortunately something that needs proven figures and an adaptation in the ”Telco mindset” to be fully understood. Motivations here are often cost savings or the simple unavailability of any budget for a new product idea (“Hey, we want video communication but have no budget – maybe we can use WebRTC”) rather than completely and thoroughly evaluated use cases. To follow up the call center use case – clearly the context can be exploited here and value can be added, but less with “pure end to end WebRTC” in the short term.

What is worth to mention is that I restricted some of my operator arguments by adding the apodosis “… unless it happens in their labs”. I believe that while WebRTC has its place in the labs, the new way of thinking has to make its way very, very quickly into the normal business units. I believe it is very important to gather experiences, not only for the development of so called new businesses, but even more importantly to reshape the existing business and adapt the new technology, new mindset step by step in as many areas as possible. This does in fact not even have to mean “do WebRTC” as understood by Google or anyone in the community. It simply means re-think current strategies how to best evolve legacy services and align with the new technologies and potentials that are available. We missed out on apps – let’s not miss out again!

Outlook and Conclusion

What are my expectations from the upcoming conference?

  • Share as many experiences from within as I can. Hopefully by then I can talk about some of our work as well.
  • See how other operators approach it. Learn about their experiences, less from technical perspective than from cultural, integration, coexistence of the old and new
  • Provide a balance between traditionalists/conservatives and the forerunners for whom change cannot come fast enough. I know where many concerns come from and am trying day in, day out to understand them and try to address them and clear them in a sensible way, and move forward – one step at a time J

Black-and-WhiteI summarized many points in this initial post that are worth a follow up, and I will try to highlight where I see the potential first and also tangle why some things just are not moving as fast as one would expect. My presentation will also highlight lessons learned so far (what is harder, what is easier) and look at where WebRTC – or rather the evolution of new paradigms that come along with it – can realistically be seen “at the average Telco” in the short term.

Remember: I believe the story is not black or white. For any shade of gray you want to draw, however, you need to understand and have both colors to do so and achieve the expected outcome.

Read more
WebRTC Orchestration-Quobis

Five Points to Consider for Real WebRTC Deployments

There are nowadays lots of ongoing proof of concepts and field trials involving WebRTC, having some of them reached the production stage. In this post we are going to explore which problems arise when you move from the lab to a production environment. These are five points to take into account when you are working with real field deployments of WebRTC.

Hide complexity of the user device

WebRTC is designed to run in any type of device and platform with the sole requirement to use a browser that supports it. Unfortunately, and even though they are implementing the standard specification, different platforms and browsers present unique peculiarities that require some degree of customization by the applications running on top.

In addition, recent movements from Microsoft indicate that they will support ORTC instead. This forces web communication applications to have their own version for Internet Explorer. Despite this, it’s possible to use elements to hide this particular implementation via a middleware that make applications work on any device and browser with no changes in the code.

WebRTC Orchestration-Quobis

Hide complexity of vendors

WebRTC does not mandate anything for signaling and it’s up to the application developer to select or even define the appropriate signaling mechanism for each environment and use case. This has been discussed in details in a Webinar focusing on WebRTC Standards. Gateway vendors have chosen different ways to manage signaling from standard based solutions, that are being adopted by some vendors and the open source community, to proprietary solutions based on SDK or proprietary APIs.

To deal with this fragmentation the industry is working on abstraction libraries like ORCAjs.

Manage the integration with existing services

It is easy to Implement WebRTC services, as you can see from demos that are available on the Internet. The big problem is when you want to create a WebRTC based service that is fully interconnected with your existing platforms, especially when you need to deal with authentication, authorization or accounting.

There are different possibilities out there to authenticate users, from anonymous calls where authentication is not needed (for instance, in some click-to-call solutions where only DoS protections or temporal accounts are dynamically provided), to the use of strong telco (or enterprise) authentication mechanisms (like AD, HSS or others)

Authorization or the management of user privileges and billing are other points to take into account. Service providers need to federate with their operation systems and policy managers, so the new WebRTC architecture will need some connectors to OSS, BSS and other existing elements.

Manage multi-tenancy services

Services providers and telcos are willing to offer new services to corporate customers that help to retain the revenues from this market. In this scenario it’s critical to have the possibility to offer services that are able to work in a multi-tenancy way. This means being able to run different instances of the solution to allow all the administrators of each company to manage different features like users, privileges and services.

Prevent security concerns

Some new potential threads appear with the use of WebRTC and part of the traditional VoIP attacks will be inherited.

Ad-hoc attacks in WebRTC include access to physical devices. It is easy to figure out how risky it would be to allow any web application to access users’ webcam or screen without asking permission of the user.  Other attacks on WebRTC include cross-domain and DoS. This means that you can connect to a server whose domain is different from the domain you downloaded the code from. This gives the necessary flexibility to make this web communications useful, but it also could allow some kind of distributed Denial of Service attack, that should be prevented.

A tool is needed to provide security mechanisms that prevent attacks and fraud in WebRTC sessions.

In summary

These are some of the points that are not part of the current feature lists of WebRTC gateway vendors, that should be looked at when planning real field deployments. Different user devices, signaling protocols, gateway vendors, user topologies or user privileges may represent a huge complexity in the delivery of WebRTC services and a potential threat in terms of security.

Read more
Nikolay Rodionov

Another View on WebRTC Data Channel – Interview with StreamRoot

Nikolay RodionovContinuing the WebRTC Data Channel series of interviews I took the opportunity to get Nikolay Robionov’s, Co-Founder of StreamRoot, point of view.

Can you tell us what your company is all about and what makes it stick out of the crowd of WebRTC start-ups?

Nikolay Rodionov:

StreamRoot is a peer-to-peer video delivery solution that helps online broadcasters to cut their bandwidth costs by up to 90%, while improving the quality of streaming. Our solution also solves the scaling issues most of the big streaming platforms still struggle with, as its efficiency increases with the number of simultaneous users.

Unlike other WebRTC DataChannel startups, our company is focused on video streaming, because video is very data consuming (it will represent 70% of total web traffic in 2017!), and because video providers have very specific needs. We work together with our clients to give them a solution that integrates almost instantly in their workflow, and provides a completely seamless experience for the end-user.

We are always on the edge of the technology, and succeeded to have the first commercial P2P player for Live Streaming on the market, and the support of adaptive bitrate technologies as MPEG-DASH. We want to become the reference in P2P video streaming by leveraging WebRTC, and we already are acknowledged as such by the the biggest players in the industry.

StreamRoot-Solution-Diagram

The data channel is one of the more interesting capabilities of WebRTC with boundless innovation opportunities. How are you innovating with it?

Nikolay Rodionov:

We saw data channels as a huge opportunity to deeply transform how the web is working today. Datachannels enables to create client-to-client transfers of any type of data without anything to install on top of the browsers, so we decided to use it to create a distributed video delivery solution. Data channels enable us to not struggle too much with the very low-level transfer issues, so we can concentrate on build a complex peer-to-peer protocol optimized for video streaming.

While there are many start-ups dealing with WebRTC not many of them are looking at the data channel. Do you think there is any special reason for that?

Nikolay Rodionov:

WebRTC was created by people and companies coming from the Telcos, so their number one focus was the Visio-conference usecase. They see WebRTC as an evolution of their existing protocols and softwares ported into the browsers, so they are not very interested in Datachannels. But WebRTC Datachannels has given developers a completely new possibilities to interact on the web, and we think the biggest innovations will come from this area as WebRTC will become more mainstream.

Lately there has been a lot of buzz around net neutrality and the FCC actions in this regards. In addition to that there are announcements about Netflix relationship with Comcast and Verizon, while on the other hand there are rumors about Netflix looking at P2P technology to save on bandwidth and cost. Can your company provide remedy to this issue and does Net Neutrality impact your solution?

Nikolay Rodionov:

Yes StreamRoot is a very good solution for this problem, as our system is relieving the congestions in the interconnection points between big video plaforms and ISPs. The end-users doesn’t need to fetch the data from the Netflix servers anymore, but can get it from the nearest peer, who can be his neighbor. And our solution benefits not only the video platform, but also the ISPs, because we optimize our peer network so the data travels less and stays in the same ISP network if possible.

If the FCC new propositions pass, bandwidth will become even more expensive, and the demand for a solution like ours will grow even more. I don’t think ISPs will be able to block all the WebRTC communications, so they will not be able to block peer-to-peer delivery, and that could be the solution for a lot of video websites who wouldn’t have the money to pay millions for a fast lane.

Are there any customers already using it? Can you name a few?

Nikolay Rodionov:

We did some great publicly demonstrated pilots with France Televisions in December and Level3 at the NAB show last month. We have several pilots running with big Live Streaming providers (main French TV Channels, as well as OTT services like PlayTV), and are in a pre-production phase with some large VOD platforms.

What’s next for your company?

Nikolay Rodionov:

Our next biggest focus is to expand internationally, and get even more clients and use cases to prove to the broadcasting world that this technology is ready for production.

Read more