Service Provider Involvement with WebRTC

10/8/2014– strictly confidential, confidential, internal, public – 1

SERVICE PROVIDER INVOLVEMENT WITH WEBRTCSEBASTIAN SCHUMANN, SLOVAK TELEKOM9. October 2014. London, United Kingdom

SCOPE

What is the current service provider involvement with WebRTC?

What are the WebRTC options for Telco’s: Not just IMS

How does WebRTC fit with PSTN / IMS / RCS / VoLTE strategies?

Developing WebRTC + Telco-OTT initiatives

How can WebRTC be deployed in the mobile world?

October 2014, London, UKSebastian Schumann: “Service Provider Involvement With WebRTC”, 3rd annual Telecom APIs 2

@s_schumann

Feedback is welcome; get in touch during/after the event!

SLOVAK TELEKOM

Former fixed and mobile incumbent (merger in 2010), Zoznam, Posam

Diverse service portfolio (fixed/mobile network and communications services, Internet access + content, data services, CPE, ICT services (data center + cloud), radio/TV broadcasting, call center services, …)

The major shareholder is Deutsche Telekom AG.

Successful deployments in SEE as well as in DT group:

One of the biggest national-wide deployment of NGN technology in Europe in 2004, whole city migrated to all-IP NGN in 2007

Fixed network IMS migration to be finished in 2014

Leader in IPTV, offering hybrid sat TV (s. 2009) & OTT app (s. 2012)

Extensive FTTx deployments (360k households)

First nation-wide 4G/LTE network (s. 2013)October 2014, London, UKSebastian Schumann: “Service Provider Involvement With WebRTC”, 3rd annual Telecom APIs 3

Slovak Telekom Group is the telecoms market leader in Slovakia

WHAT IS WEBRTC?

It is implied that WebRTC = “communications”

Just look at the outline, nobody expects a talk about IPTV. And it is obvious. And correct.

WebRTC often mentioned on par with communications services, yet we have already in its early stages seen many different samples using the technology

Sharefest, Viblast, PeerJS/PeerCDN often unknown in operator discussion

For many, “adding WebRTC” means adding voice/video to a service and have this service in the browser

Due to Telecom’s business’ history “communications” = “telephony”

Is it important?

Yes, because it comes with certain presumptions for the service and also in discussions

It comes with less defined constraints than VoLTE/RCS, operators sometimes forget that!

When WebRTC is discussed within operator units, they are almost always discussed with legacy assumptions in mind


SETTING THE STAGE

Today’s aim is to shed light on a perspective about why many operators think about WebRTC the way they do

Based on this their involvement is discussed

Rational reasoning

The missing bits

Comparison with IMS/RCS/VoLTE/OTT also needs to answer to the question of what these actually are

Technologies, services, concepts, ways of thinking?

“VoLTE is just telephony” Telephony in the browser

This presentation is not about the data channel or non-RTC use cases to stay focused

“It’s a technology, not a service” often cited, deductions from that statement are in fact an iceberg


WEBRTC “OPTIONS”WHAT CAN THE TECHNOLOGY BE USED FOR?


Integration Options

Adding “RTC” to the “Web”Adding the “Web” to “RTC”

WebRTC WebRTC

? ?

HOW DOES WEBRTC FIT WITH PSTN/IMS/RCS/VOLTE?

IP technologies are not new, not even for operators. Novelty lies in importance of “soft UX” over “hard QA”

So far, major operator activities only in back-end, not customer facing part

Quote from my 2011 pres: marketing technology is “wrong communication with the customer”

Migration to IMS/VoLTE did not change the service at all

RCS is still based on legacy concepts

WebRTC does fit into All-IP strategy on paper

If back-end is IP, utilizing WebRTC to connect front-ends to back-ends is just logical conclusion

On paper? WebRTC is much more, because it is a new way of thinking and this has often not even started

Design of front-end defines service, back-end completely irrelevant

Many inherent “features” of IMS/VoLTE irrelevant, such as interconnect, “classic” federation

Value shifted from pure connectivity to application outcomes

May still include e.g. federation but more pragmatic w/ simple APIs benefiting all parties


WebRTC

HOW DOES WEBRTC RELATE TO LEGACY COMM’S?

Legacy communications dealt with RTC, has just recentlyreceived a new polished infrastructure

“Adding” multiple new ways of accessing it is natural

Should not be “WebRTC strategy”, but overhauling services now,so far only the technology has been updated

Only a very small part of what WebRTC enables us to do is (or should be) related to “legacy” telephony as a product

In the end, if operators chose to launch services (or partner) they may chose to add RTC to some of them, and may select WebRTC for a subset of those

Some may interwork with the PSTN, some may not

The operator may provide the solution for some, or identification/hosting/media handling… for others

Sometimes WebRTC will not be used, but maybe an API “that came along with its implementation”


Legacy

Comm’s

WebRTC

MOBILE DEVELOPMENT

Let’s look at VoLTE vs. WebRTC VoLTE vs. “VoIP telephony using/built with WebRTC most likely in a browser”

Service vs. technology comparison, does not often make sense

Either service characteristics are compared (e.g. legacy interworking, web/E.164 identity)

Or technologies are compared (e.g. Web sockets vs. SIP, EasyRTC vs. IMS)

Browsers will be starting point for PoCs, native still preferred for commercial deployments for now

Native requires different resources than just a few JavaScript programmers (for now)

Lower barrier that WebRTC brings to general RTC app development also true for mobile

Probably if we would see serious products with budget it will be native

Whether operators will have native apps soon or just approach mobile by hopefully at least building responsive web sites is open

Own trials/PoC and focus group targeting products most likely just browser


WebRTC

DEVELOPING OPERATOR STRATEGIES

WebRTC can be one of the technologies to accelerate development and decrease costs, if operators want to build “OTT services” services that are:

Access independent/network independent/location independent

Use a software front-end (app/web)

Are completely new in how they deliver voice in the application

A separate “OTT strategy” does not make sense

Is has to be elaborated per service how it should be exposed, delivered, and made accessible

Acknowledge that Telco technologists visions over-ran by actual user demands, shift in industry to actually listen to what customers want and value

Other businesses also affected by “telephony-trumping” use cases, for example


WebRTC

WHAT TO DO BEYOND TELEPHONY?

For “new services” comparison between new services to “Telco services” needed

Current “new” operator services such as VoLTE and RCS are “old Telco services ”

Stand-alone services, no initial and easy integration considered

QoS over QoE, etc.

Important to affect current planning and new services. Do not think about new communications services, but

Evolve existing communications services and innovate on UX/QoE

Embed features in new services (own, partnering)

Software expands to have messaging/voice as features

Integrate “WebRTC support” into other business areas (e.g. hosting, TURN server, integration)

We may not be the best partner for building service, but trusted in providing execution environment

Accelerate also development APIs that can be used!

New thinking needs to come with it, not yet clear everywhere!


WebRTC

CONSIDERATIONS FOR INTERNAL DISCUSSIONS

Stop seeing WebRTC as “one thing to have”

You won’t have “one system” that does WebRTC and you add it everywhere

Choose a platform depending on what you want to do

Get a gateway if legacy is important (incl. identity, integration etc.), if not chose depending on your resources

Choose your vendor wisely, WebRTC often comes with the IMS and that will have impact on your creativity

Good open-source products available, client-side JavaScript knowledge often enough to get started!

IMS is representative for several characteristics around telephony/aggregated communications

Interconnect (w/ other services), interoperability (between services, e.g. video), identification (E.164, identified operator relation)

Question if your new comm’s service needs it, assume your new not telephony focused services mostly doesn’t

While we are at it, consider to evolve existing services before building a new comm’s service!


WebRTC

CHALLENGES

Overcome misbelief that “we now have WebRTC”

Strategically important: It’s not one box or one service platform. It is not just some front-end to the IMS.

Proposition-wise important: We have to define the service now (at least more than before)

Operators should focus on a mix of architectural strategies

Can include IMS, but should contain also low-cost alternative for innovation

Requires a mix of enablers for delivering features for future services

Aggregation of architecture has limits, scalability and easy connection of enablers via APIs more important

Yet another organizational change is to happen

Change of fixed vs. mobile companies/units/team backgrounds often not 100% finished

The same aggregation will (and should?) happen for IT/NT


WebRTC

PRACTICAL BACKUP: WE ARE DOOGFOODING

Slovak Telekom has implemented a PoC not connected to legacy telephony, actively used by employees

A WebRTC gateway RfQ on IMS and show telephony would be easy, but doesn’t have much value yet

We developed a (simple but yet) contextual web application

Sent E-mails contain signature to web portal (address built using E-mail as identifier), contact employees

People can be contacted and also notified out-of-band using various channels, owner/guest not equal

No telephony dial-out: Faster, easy b/c no legacy boundaries such as billing, integration, approval

No complex account setup: Address confirmation using received hash/token for mapping

No one-size-fits-all: Many features consciously omitted (directory, collaboration, conferencing)

One application doing one thing well and which contains only those features required

Been there, done that!

We’ve done VoIP OTT commercially since 2008 and “web telephony” since 2009

Lessons learned from that are tremendously important for next products


SUMMARYTHE WEBIFICATION OF COMMUNICATION

Less ubiquitous, but more targeted applications will replace telephony general purpose communicationsuse case by use case

Think “web”, but know your playground

Standardized core technologies (HTML/CSS/JS, Objective-C, Java), but not services

Standardized interfaces (REST API w/ doc/SDK is enough) trumps complex E2E scenarios

Revenue “hand over” needs to fit operator business model, find good compromise

We have to “eat our own dog food” to learn and understand

It is imperative that any new service is considered both from technology and service evolution perspectives

Understand and acknowledge the tremendous change to our core business

WebRTC can be part of the solution, an ingredient. It is not THE solution, or A solution for that matter.


BUSINESS IS STILL KING! THAT MEANS HAVING TELEPHONY (AND ITS REVENUE) ON BOARD.

THANK YOU.Sebastian Schumann

Application & Platform Innovation | Slovak Telekom, a.s.

[email protected]

@s_schumann

+421 903 419 345

Technology

Service Provider Involvement with WebRTC