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