WebRTC from the Service Provider Prism

Webinar: WebRTC from the Service

Provider Prism (October 2014)

Victor Pascual [email protected]

@victorpascual

Amir [email protected]

@AmirZmora

Sebastian [email protected]@ @s_schumann

mailto:[email protected]

Upperside WebRTCConference, 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 4 lessons learnt over 40+ field trials withservice 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/ABUNDLESIPTrickle ICESCTPDTLS-SRTP...

Source: google images

Signaling Fragmentation

#2 – Being signaling agnostic 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 isimplementing its own proprietarysignaling mechanism

#3 – Being Browser/device API agnostic is a MUST

Standard API

WebRTC 1.0

Competing APIs

CU-RTC-WebORTC

WebRTC 1.1 & 2.0?

The WebRTC API canhave 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 thenetwork (OSS, BSS, AAA, HLR/HSS, AS’s, APIs, DBs, etc.)

#4 – TRUE Integration with the corenetwork goes beyond the gatewaypiece

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

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

@victorpascual

Amir [email protected]

@AmirZmora

Sebastian [email protected]@ @s_schumann

mailto:[email protected]

WebRTC from the Service Provider Prism

Technology

Transcript of WebRTC from the Service Provider Prism