WebRTC from the service provider prism

Webinar: WebRTC from the Service Provider Prism (October 2014)

Victor Pascual Avila [email protected] @victorpascual

Amir Zmora [email protected] @AmirZmora

Sebas:an Schumann sebas:[email protected] @ @s_schumann

Upperside WebRTC Conference, Dec 16-18

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

Signaling Fragmenta:on

#2 – Being signaling agnosEc is a MUST

•  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

#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

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)

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

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

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

#5 – TRUE IntegraEon with the core network goes beyond the gateway piece

Poll QuesEon

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

Adding “RTC” to the “Web” Adding the “Web” to “RTC”

WebRTC WebRTC

? ?

WEBRTC “OPTIONS” THE USE CASES

Integration Options

Adding “RTC” to the “Web” Adding the “Web” to “RTC”

WebRTC WebRTC

?

?

WEBRTC “OPTIONS” THE DILEMMA

Integration Options

Adding the “Web” to “RTC”

WebRTC WebRTC

? 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

§  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

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 [email protected] @victorpascual

Amir Zmora [email protected] @AmirZmora

Sebas:an Schumann sebas:[email protected] @ @s_schumann

Internet

WebRTC from the service provider prism