WebRTC from the Service Provider Prism

Webinar: WebRTC from the Service Provider Prism

Co-Presented as Upperside Webinar together with Victor Pascual Avila and Amir Zmora

Transcript

1. Webinar: WebRTC from the Service Provider Prism (October 2014) Victor Pascual Avila Victor.pascual@quobis.com @victorpascual Amir Zmora amzmora@gmail.com @AmirZmora Sebastian Schumann sebastian.schumann@telekom.sk @ @s_schumann
2. Upperside WebRTC Conference, Dec 16-18
3. blog.uppersideconferences.com
4. Telecom & Web, born for each other? tomcowin Hey Paul Studios
5. Approach #1 • Shape WebRTC to fit into the Telecom world
6. Approach #2 • Build the service around the Web, add telecom when relevant Southbank Center
7. Goal for today • Share 4 lessons learnt over 40+ field trials with service providers playing with WebRTC
8. #1 - Simplicity is a MUST Web developers don’t know much and in fact don’t care at all about RTC details SDP O/A BUNDLE SIP Trickle ICE SCTP DTLS-SRTP ...
9. Source: google images
10. Signaling Fragmentation #2 – Being signaling agnostic is a MUST
11. • WebRTC has no defined signaling method. • JavaScript app downloaded from web server. • Popular choices are SIP over WebSockets (RFC7118), REST APIs, JSON, or any other HTTP-based foobar • One also needs to decide how to implement things like BFCP, MSRP, etc. Each deployment/vendor is implementing its own proprietary signaling mechanism
13. #3 – Being Browser/device API agnostic is a MUST Standard API WebRTC 1.0 Competing APIs CU-RTC-Web ORTC WebRTC 1.1 & 2.0? The WebRTC API can have different flavors
16. Interworking Towards Legacy VoIP? • A browser-embedded media engine • Best-of-breed echo canceler • Video jitter buffer, image enhancer • Audio codecs – G.711, Opus are MTI • Video codecs – H.264 vs. VP8 (MTI TBD - IPR discussion) • Media codecs are negotiated with SDP (for now at least) • Requires Secure RTP (SRTP) – DTLS • Requires Peer-2-peer NAT traversal tools (STUN, TURN, ICE) – trickle ICE • Multiplexing: RTPs & RTP+RTCP • Yes, your favorite SIP client implementation is compatible with most of this. But, the vast majority of deployments • Use plain RTP (and SDES if encrypted at all) • Do not support STUN/TURN/ICE • Do not support multiplexing (ok, not really an issue) • Use different codecs that might not be supported on the WebRTC side
17. #4 – WebRTC signaling and media is NOT compatible with existing VoIP/IMS deployments – gateways are required to bridge the two worlds
18. WebRTC Access to IMS (r12)
19. Adding New Wheels to IMS with WebRTC
20. 3GPP TS 23.228 V12.5.0 (2014-06)
21. P C E F N A T I P - C A N WWSF W1 W2 UE WIC I / S - CSCF eIMS - AGW Iq Mw eP - CSCF H / V - PCRF Gx Rx W3 IMS - ALG WAF W4 W5 Reference Architecture
22. codec 1 SRTP IP IP UDP IP UDP UDP UDP IP UE eIMS - AGW peer SRTP RTP codec 1 codec 2 RTP codec 2 BFCP SCTP DTLS IP SCTP DTLS IP TCP IP UDP UDP BFCP TCP IP UE eIMS - AGW peer MSRP SCTP DTLS IP MSRP SCTP DTLS IP MSRP TCP IP UDP UDP MSRP TCP IP UE eIMS - AGW peer Interworking Towards Legacy IMS
23. • One needs to integrate the new WebRTC domain and services with whatever has already deployed in the network (OSS, BSS, AAA, HLR/HSS, AS’s, APIs, DBs, etc.) #4 – TRUE Integration with the core network goes beyond the gateway piece
24. Poll Question What should be service providers’ approach to WebRTC? • Extend IMS to WebRTC • Build Web services and extend to IMS if needed • They are 2 separate things, no need to interconnect • WebRTC doesn’t stand a chance without traditional telephony and IMS
25. THE OPERATOR PERSPECTIVE  My mission: WebRTC beyond telephony  … but that does not mean it is not important for the time being  It is important to understand our heritage and acknowledge who pays the bills for now  Modernization of current voice service important  This is a pretty straight forward path, many obstacles are being worked on (as Victor presented)  Most of the operator voice back-end is IP based now, but simply attaching “a WebRTC front-end” won’t do
26. WEBRTC “OPTIONS” WHAT CAN THE TECHNOLOGY BE USED FOR? IntegrationOptions Adding “RTC” to the “Web” Adding the “Web” to “RTC” WebRTC WebRTC ? ?
27. WEBRTC “OPTIONS” THE USE CASES IntegrationOptions Adding “RTC” to the “Web” Adding the “Web” to “RTC” WebRTC WebRTC ? ?
28. WEBRTC “OPTIONS” THE DILEMMA IntegrationOptions Adding the “Web” to “RTC” WebRTC WebRTC ? Adding the “Web” to “RTC” ?
29. EXTENDING LEGACY COMMUNICATIONS  IP technologies are not new, not even for operators  If back-end is IP, utilizing WebRTC to connect front-ends to back-ends is a logical conclusion  Legacy communications dealt with RTC, has just recently received a new polished infrastructure  “Adding” multiple new ways of accessing it is natural  Web gateway (utilizing WebRTC) as “IMS alternative access” is of course one use case  Should not be “WebRTC strategy”, but overhauling services. For far it is all about the technology.  Novelty in importance of great best-effort experience often trumping good legacy QoS  Service updates can include “modernized interfaces”, but need to go beyond  Adding “Web” to existing products means they are defined, and mostly limited  Integration where it makes sense is more important than a “pure web dialer” The WebRTC paradigm introduces a "way of thinking“ that has often not even started. The "front-end design/functions defines services now, the back-end is completely irrelevant. WebRTC
30. STEPS TAKEN FOCUS ON A MIX OF ALTERNATIVE ARCHITECTURES  Every service or integration going beyond telephony or not requiring the full subset of its features should have a prior discussion about proper architecture (back-end enabler)  Main criterions  Telephony: IMS/MMTel/VoLTE vs. lightweight open-source alternatives – almost exclusively SIP  Non-telephony: Own backend, libraries, protocol alternatives (XMPP, REST/JSON)  Pro’s and con’s for telephony need to be evaluated, no universal answer  Final architecture is a case-by-case decision, not just use because it is there (efficiency, suitability)  For everything that is not telephony, alternatives most likely much more suitable  The discussion about WebRTC & IMS should not be at the beginning, but the end of any consideration  Slovak Telekom followed these ideas for its internal PoC
31. FOCUSING ON SERVICE INNOVATION  Operators need to adapt a lot of their thinking  We do not build a “WebRTC service”/“cloud service”. We need to build services that solve problems  Once the service is defined, the technologies can be chosen based on many criterions  WebRTC can be one of the technologies to accelerate development and decrease costs, if operators want to build 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  It has to be elaborated per service how it should be exposed, delivered, and made accessible WebRTC
32. IN THE END IT IS ALL ABOUT THE MONEY  Business is king, not the architecture  To remain competitive, alternative approaches need to be embraced  Faster innovation, trial and error  Enable new business models with different cost models, new revenues!  Consider the web (also with regard to payment options, feature activation, etc.)  Integrate, but offer also means to be integrated (messaging, voice)  “WebRTC” is not one box/platform. It is not just some front-end to the IMS.  Gateway/open-source/partnering/in-house development/vendor acc. your need  For Legacy services its more important to improve the service than just “add WebRTC”  Focus on user’s needs & experience - tech driven services and features are wrong!
33. Conflict Between The 2 Approaches Alexander Baxevanis
34. Thank You for Attending Victor Pascual Avila Victor.pascual@quobis.com @victorpascual Amir Zmora amzmora@gmail.com @AmirZmora Sebastian Schumann sebastian.schumann@telekom.sk @ @s_schumann