WebRTC from the service provider prism

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

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

9. Source:
google
images

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