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

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/

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