Service Provider Involvement with WebRTC

10/8/2014– strictly confidential, confidential, internal, public – 1
SERVICEPROVIDERINVOLVEMENTWITHWEBRTC
SEBASTIAN SCHUMANN, SLOVAK TELEKOM
9. 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!

SLOVAKTELEKOM
 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)
Slovak Telekom Group is the telecoms market leader in Slovakia

WHATISWEBRTC?
 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

SETTINGTHESTAGE
 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?
IntegrationOptions
Adding “RTC” to the “Web”Adding the “Web” to “RTC”
WebRTC WebRTC
? ?

HOWDOESWEBRTCFITWITH 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

HOWDOESWEBRTCRELATETOLEGACYCOMM’S?
 Legacy communications dealt with RTC, has just recently
received 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

MOBILEDEVELOPMENT
 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

DEVELOPINGOPERATORSTRATEGIES
 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

WHATTODOBEYONDTELEPHONY?
 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

CONSIDERATIONSFORINTERNALDISCUSSIONS
 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

PRACTICALBACKUP:WEAREDOOGFOODING
 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

SUMMARY
THE WEBIFICATION OF COMMUNICATION
 Less ubiquitous, but more targeted applications will replace telephony general purpose communications
use 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.

THANKYOU.
Sebastian Schumann
Application & Platform Innovation | Slovak Telekom, a.s.
 Sebastian.Schumann@telekom.sk
@s_schumann
 +421 903 419 345

Service Provider Involvement with WebRTC

More Related Content

What's hot

Viewers also liked

Similar to Service Provider Involvement with WebRTC

More from Sebastian Schumann

Recently uploaded

Service Provider Involvement with WebRTC