SlideShare a Scribd company logo

Upperside Webinar- WebRTC from the service provider prism-final

•
•
Amir Zmora
Amir Zmora

A Webinar I did with Victor Pascual Avila (Quobis) and Sebastian Schumann (Slovak Telekom) for Upperside Conferences. Webinar talks about the different approaches service providers can take with WebRTC, what developers need and some actual examples of things Slovak Telekom has done. Recording of this Webinar can be found here: https://attendee.gotowebinar.com/register/5051075414841550849

Related slideshows

Förbättra kassaflödet och minska faktureringskostnaderna med en smartare infr...
Förbättra kassaflödet och minska faktureringskostnaderna med en smartare infr...Förbättra kassaflödet och minska faktureringskostnaderna med en smartare infr...
Förbättra kassaflödet och minska faktureringskostnaderna med en smartare infr...
 
Universal Messaging: Transforming How Businesses Communicate
Universal Messaging: Transforming How Businesses CommunicateUniversal Messaging: Transforming How Businesses Communicate
Universal Messaging: Transforming How Businesses Communicate
 
What's new in Mitel MiVoice Business 7.1?
What's new in Mitel MiVoice Business 7.1?What's new in Mitel MiVoice Business 7.1?
What's new in Mitel MiVoice Business 7.1?
 
1 of 34
Webinar: WebRTC from the Service Provider Prism (October 2014) Victor Pascual Avila Victor.pascual@quobis.com @victorpascual Sebas:an Schumann sebas:an.schumann@telekom.sk @ @s_schumann Amir Zmora amzmora@gmail.com @AmirZmora
Upperside WebRTC Conference, Dec 16-18 hEp://www.uppersideconferences.com/webrtc Co-­‐located with Meetup: hEp://www.meetup.com/webrtc-­‐paris/ events/212929792/
blog.uppersideconferences.com
Telecom & Web, born for each other? tomcowin Hey Paul Studios
Approach #1 • Shape WebRTC to fit into the Telecom world
Approach #2 • Build the service around the Web, add telecom when relevant Southbank Center
Goal for today • Share 5 lessons learnt over 40+ field trials with service providers playing with WebRTC
#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 ...
Source: google images
#2 – Being signaling agnosEc is a MUST Signaling Fragmenta:on
• 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 implemen:ng its own proprietary signaling mechanism
Upperside Webinar- WebRTC from the service provider prism-final
#3 – Being Browser/device API agnosEc is a MUST Standard API WebRTC 1.0 Compe:ng APIs CU-­‐RTC-­‐Web ORTC WebRTC 1.1 & 2.0? The WebRTC API can have different flavors
Upperside Webinar- WebRTC from the service provider prism-final
Upperside Webinar- WebRTC from the service provider prism-final
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
#4 – WebRTC signaling and media is NOT compatible with existing VoIP/IMS deployments – gateways are required to bridge the two worlds
WebRTC Access to IMS (r12)
Adding New Wheels to IMS with WebRTC
3GPP TS 23.228 V12.5.0 (2014-06)
Reference Architecture P C E F N A T I P - C A N WWSF W1 W2 WIC UE I / S - CSCF W4 WAF W5 eP - CSCF Mw Iq eIMS - AGW H / V - PCRF Gx Rx W3 IMS - ALG
Interworking Towards Legacy IMS codec 1 SRTP codec 1 codec 2 SRTP RTP codec 2 RTP UDP UDP UDP IP IP UDP IP IP UE eIMS - AGW peer 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
#5 – TRUE IntegraEon with the core network goes beyond the gateway piece • 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.)
Poll QuesEon What should be the 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 tradi:onal telephony and IMS
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
WEBRTC “OPTIONS” WHAT CAN THE TECHNOLOGY BE USED FOR? Integration Options WebRTC WebRTC ? ? Adding Adding the “Web” to “RTC” “RTC” to the “Web”
WEBRTC “OPTIONS” THE USE CASES Integration Options WebRTC WebRTC Adding “RTC” to the “Web” Adding the “Web” to “RTC” ? ?
WEBRTC “OPTIONS” THE DILEMMA Integration Options WebRTC WebRTC ? Adding the “Web” to “RTC” Adding the “Web” to “RTC” ?
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
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
FOCUSING ON SERVICE INNOVATION WebRTC § 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
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!
Conflict Between The 2 Approaches Alexander Baxevanis
Thank You for Attending Victor Pascual Avila Victor.pascual@quobis.com @victorpascual Sebas:an Schumann sebas:an.schumann@telekom.sk @ @s_schumann Amir Zmora amzmora@gmail.com @AmirZmora

More Related Content

Upperside Webinar- WebRTC from the service provider prism-final

  • 1. Webinar: WebRTC from the Service Provider Prism (October 2014) Victor Pascual Avila Victor.pascual@quobis.com @victorpascual Sebas:an Schumann sebas:an.schumann@telekom.sk @ @s_schumann Amir Zmora amzmora@gmail.com @AmirZmora
  • 2. Upperside WebRTC Conference, Dec 16-18 hEp://www.uppersideconferences.com/webrtc Co-­‐located with Meetup: hEp://www.meetup.com/webrtc-­‐paris/ events/212929792/
  • 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 5 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 ...
  • 10. #2 – Being signaling agnosEc is a MUST Signaling Fragmenta:on
  • 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 implemen:ng its own proprietary signaling mechanism
  • 13. #3 – Being Browser/device API agnosEc is a MUST Standard API WebRTC 1.0 Compe:ng 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. Reference Architecture P C E F N A T I P - C A N WWSF W1 W2 WIC UE I / S - CSCF W4 WAF W5 eP - CSCF Mw Iq eIMS - AGW H / V - PCRF Gx Rx W3 IMS - ALG
  • 22. Interworking Towards Legacy IMS codec 1 SRTP codec 1 codec 2 SRTP RTP codec 2 RTP UDP UDP UDP IP IP UDP IP IP UE eIMS - AGW peer 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
  • 23. #5 – TRUE IntegraEon with the core network goes beyond the gateway piece • 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.)
  • 24. Poll QuesEon What should be the 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 tradi:onal 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? Integration Options WebRTC WebRTC ? ? Adding Adding the “Web” to “RTC” “RTC” to the “Web”
  • 27. WEBRTC “OPTIONS” THE USE CASES Integration Options WebRTC WebRTC Adding “RTC” to the “Web” Adding the “Web” to “RTC” ? ?
  • 28. WEBRTC “OPTIONS” THE DILEMMA Integration Options WebRTC WebRTC ? Adding the “Web” to “RTC” 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 WebRTC § 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
  • 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 Sebas:an Schumann sebas:an.schumann@telekom.sk @ @s_schumann Amir Zmora amzmora@gmail.com @AmirZmora