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 will WebRTC be deployed in the mobile world? Presented at IIR Telecom APIs 2014 in London, UK

1. 10/8/2014– strictly confidential, confidential, internal, public – 1
SERVICEPROVIDERINVOLVEMENTWITHWEBRTC
SEBASTIAN SCHUMANN, SLOVAK TELEKOM
9. October 2014. London, United Kingdom

2. 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!

3. 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)
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

4. 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
October 2014, London, UKSebastian Schumann: “Service Provider Involvement With WebRTC”, 3rd annual Telecom APIs 4

5. 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
October 2014, London, UKSebastian Schumann: “Service Provider Involvement With WebRTC”, 3rd annual Telecom APIs 5

6. WEBRTC“OPTIONS”
WHAT CAN THE TECHNOLOGY BE USED FOR?
October 2014, London, UKSebastian Schumann: “Service Provider Involvement With WebRTC”, 3rd annual Telecom APIs 6
IntegrationOptions
Adding “RTC” to the “Web”Adding the “Web” to “RTC”
WebRTC WebRTC
? ?

7. 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
October 2014, London, UKSebastian Schumann: “Service Provider Involvement With WebRTC”, 3rd annual Telecom APIs 7
WebRTC

8. 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”
October 2014, London, UKSebastian Schumann: “Service Provider Involvement With WebRTC”, 3rd annual Telecom APIs 8
Legacy
Comm’s
WebRTC

9. 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
October 2014, London, UKSebastian Schumann: “Service Provider Involvement With WebRTC”, 3rd annual Telecom APIs 9
WebRTC

10. 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
October 2014, London, UKSebastian Schumann: “Service Provider Involvement With WebRTC”, 3rd annual Telecom APIs 10
WebRTC

11. 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!
October 2014, London, UKSebastian Schumann: “Service Provider Involvement With WebRTC”, 3rd annual Telecom APIs 11
WebRTC

12. 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!
October 2014, London, UKSebastian Schumann: “Service Provider Involvement With WebRTC”, 3rd annual Telecom APIs 12
WebRTC

13. 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
October 2014, London, UKSebastian Schumann: “Service Provider Involvement With WebRTC”, 3rd annual Telecom APIs 13
WebRTC

14. 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
October 2014, London, UKSebastian Schumann: “Service Provider Involvement With WebRTC”, 3rd annual Telecom APIs 14

15. 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.
October 2014, London, UKSebastian Schumann: “Service Provider Involvement With WebRTC”, 3rd annual Telecom APIs 15
BUSINESS IS STILL KING! THAT MEANS HAVING TELEPHONY (AND ITS REVENUE) ON BOARD.

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