What is the current service provider involvement with WebRTC?

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

Transcript

1. 10/8/2014 – strictly confidential, confidential, internal, public – 1 SERVICE PROVIDER INVOLVEMENT WITH WEBRTC 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, UK Sebastian Schumann: “Service Provider Involvement With WebRTC”, 3rd annual Telecom APIs 2 @s_schumann Feedback is welcome; get in touch during/after the event!
3. 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, UK Sebastian Schumann: “Service Provider Involvement With WebRTC”, 3rd annual Telecom APIs 3 Slovak Telekom Group is the telecoms market leader in Slovakia
4. 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 October 2014, London, UK Sebastian Schumann: “Service Provider Involvement With WebRTC”, 3rd annual Telecom APIs 4
5. 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 October 2014, London, UK Sebastian Schumann: “Service Provider Involvement With WebRTC”, 3rd annual Telecom APIs 5
6. WEBRTC “OPTIONS” WHAT CAN THE TECHNOLOGY BE USED FOR? October 2014, London, UK Sebastian 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. 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 October 2014, London, UK Sebastian Schumann: “Service Provider Involvement With WebRTC”, 3rd annual Telecom APIs 7 WebRTC
8. HOW DOES WEBRTC RELATE TO LEGACY COMM’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, UK Sebastian Schumann: “Service Provider Involvement With WebRTC”, 3rd annual Telecom APIs 8 Legacy Comm’s WebRTC
9. 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 October 2014, London, UK Sebastian Schumann: “Service Provider Involvement With WebRTC”, 3rd annual Telecom APIs 9 WebRTC
10. 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 October 2014, London, UK Sebastian Schumann: “Service Provider Involvement With WebRTC”, 3rd annual Telecom APIs 10 WebRTC
11. 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! October 2014, London, UK Sebastian Schumann: “Service Provider Involvement With WebRTC”, 3rd annual Telecom APIs 11 WebRTC
12. 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! October 2014, London, UK Sebastian 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, UK Sebastian Schumann: “Service Provider Involvement With WebRTC”, 3rd annual Telecom APIs 13 WebRTC
14. 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 October 2014, London, UK Sebastian 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, UK Sebastian 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. THANK YOU. Sebastian Schumann Application & Platform Innovation | Slovak Telekom, a.s.  Sebastian.Schumann@telekom.sk @s_schumann  +421 903 419 345