Each WebRTC deployment is implementing its own proprietary signaling mechanism. WebRTC signaling and media is incompatible with existing VoIP deployments, requiring gateways to bridge the two. The WebRTC API specification is still evolving and may take different forms across implementations. Standards bodies are working to define signaling interoperability and bridge WebRTC with existing networks like SIP, IMS and videoconferencing systems.

1. WebRTC: Standards Update – Where are we?

2. About QUOBIS
Quobis is a leading european company in the delivery of
carrier-class unified communication solutions with a
special focus on security, interconnection and identity
management for service providers and enterprises.
Seven years working on VoIP projects.
Three years developing own products.

3. About Me (victor.pascual@quobis.com)
Victor Pascual – Chief Strategy Officer (CSO) at Quobis
Main focus: help make WebRTC happen – involved in WebRTC
standardization, development and first industry deployments (on-going RFX's,
PoC's and field trials)
Side activities:
- IETF contributor (SIP, Diameter and WebRTC areas)
- IETF STRAW WG co-chair
- SIP Forum WebRTC Task Group co-chair
- WebRTCHacks.com co-founder and blogger
- Independent Expert at European Commission
@victorpascual

6. Technology Angle
A browser-embedded media engine
“No need to install upgrade/configure software”

7. Business Angle
Is WebRTC something disruptive or simply yet
another access framework? BOTH!
RTC → Web
Web → RTC
- global business – browsers are
connected to the Internet → it's time to
go OTT
Pure Web vs Interworked
Not only Web browsers but also native
support via apps or OS
(e.g. set-top boxes, FirefoxOS)
- expand footprint – extend existing
services to new subscribers
- decrease churn – enhance current
services to existing subscribers
- new service revenues – create new
services and subscribers

8. WebRTC standards
(Signaling)
(Signaling)
“Set or RTC APIs
for Web Browsers”
(Media)
“New protocol
profile”
Some discussion on the topic:
http://webrtchacks.com/a-hitchhikers-guide-to-webrtc-standardization/

9. RTCWeb WG (and others)
- Audio codecs – G.711, Opus
- Video codecs – H.264 vs. VP8
- Media codecs are negotiated with SDP (for now at least)
- Requires Secure RTP (SRTP) – DTLS-SRTP (SDES is prohibited)
- Requires Peer-2-peer NAT traversal tools (STUN, TURN, ICE) – trickle ICE
- Multiplexing: RTPs & RTP+RTCP
- Tools for firewall traversal
- DataChannel
- Etc.
NEW PROTOCOL PROFILE FOR MEDIA

10. WebRTC does not define signaling
Don’t panic, it’s not a bad thing!

11. Signaling plane
WebRTC has no defined signaling method. JavaScript app downloaded
from web server. Popular choices are:
●
SIP over Websockets
–
–
Extend SIP directly into the browser by embedding a SIP stack directly into the
webpage – typically based on JavaScript
–
WebSocket create a full-duplex channel right from the web browser
–
●
Standard mechanism (draft-ietf-sipcore-sip-websocket) – soon to be RFC
Popular examples are jsSIP, sip-js,
QoffeeSIP, or sipML5
Call Control API
–
–
•
proprietary signaling scheme based on
more traditional web tools and techniques
GSMA/OMA extending RCS “standard” API to include WebRTC support
Other alternatives based on XMPP, JSON or foobar
Some discussion on the topic: http://webrtchacks.com/signalling-options-for-webrtcapplications/

12. (1/3)
each deployment/vendor is implementing
its own proprietary signaling mechanism

13. Interworking?
●
●
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

14. (2/3)
WebRTC signaling and media is NOT
compatible with existing VoIP deployments
– gateways are required to bridge the two
worlds

15. The video codec battle
Some discussion on the topic: http://webrtchacks.com/cisco-openh264/

17. Result of the
discussion?
Room participants: 30/50 in favor of H.264
Remote participants (minority): 75/25 in favor of VP8
→ No clear consensus

18. No decision
Some discussion on the topic: http://webrtchacks.com/ietf-finally-made-decisionmandatory-implement-mti-video-codec-webrtc/

19. WebRTC WG
“The mission of the W3C WebRTC WG is to define client-side APIs to enable Real-Time Communications in
Web-browsers. These APIs should enable building applications that can be run inside a browser, requiring no
extra downloads or plugins, that allow communication between parties using audio, video and supplementary
real-time communication, without having to use intervening servers (unless needed for firewall traversal).”
Obtain local
media
Setup Peer
Connection
Attach media
or Data
Close
Connection
← getUserMedia(),
etc.
← RTCPeerConnection(),
etc.
← addStream(),
createOffer(),
etc.
Discussion: provides the current API in its
form (e.g. based on SDP O/A) the
flexibility Web developers need?
Answer: well, not really but it's good
enough for most of the use cases we have
today
Competing proposals: Microsoft's CURTC-WEB (Aug'12), WebRTC Object API
(ORTC) (Aug'13)
Next step: “Done is better than perfect”,
Let's finish WebRTC 1.0, Let the industry
adopt it
Future work: “fix/improve things in
WebRTC 2.0”, Backward interoperability?

20. How do applications access the media engine?
●
W3C API
– Currently working on 1.0
2.0: Backward compatibility?
Competing API: CU-RTC-Web (Microsoft)
Competing API: ORTC (Microsoft and others)
Apple?
Since last week Opera
includes some support
–
●
●
●
●
Some discussion on the topic:
http://webrtchacks.com/why-the-webrtc-apihas-it-wrong-interview-with-webrtc-object-apiortc-co-author-inaki-baz-3-2/
iswebrtcreadyyet.com

21. (3/3)
the WebRTC API can have different
flavors

22. WebRTC Access to IMS (r12)

23. SA1 (requirements): reusing IMS client security credentials and/or
public identities/credentials; how IMS clients communicate with
WebRTC clients connected to IMS; IMS services to the WebRTC
client; regulatory functions and charging; offer IMS services to users interacting with
a 3rd party website, etc.
SA2 (architecture): expand the IMS architecture and stage 2 procedures as required
by the support of WebRTC clients access to IMS; media plane aspects; PBX
emulation; signalling; only UNI covered, NNI out of scope.
SA3 (security): WebRTC client authentication mechanisms, media plane security

24. SIP Forum WebRTC Task Group
“the initial focus of the Task Group is to determine what
the needs are for successful interoperability of WebRTCto-SIP deployments” covering both Enterprises and
Service Providers
“recommendations, Reference Architecture Documents,
Certifications, and/or White Papers”

25. GSMA

26. Alliance for Telecom Solutions
”Device Solutions Initiative (DSI), an initiative that will host a range of projects to
develop network- and protocol-agnostic, client-side bindings that will make real-time
communications more accessible to web developers”
“The tools being created by the Initiative will offer developers a code-once, run
anywhere approach, replacing the need for carrier-specific coding to add functions such
as basic call signaling and network control to applications. DSI will focus initially on call
signaling but is expected to advance from there to address other network-specific
functions”
“The DSI’s formation and launch was led by Alcatel-Lucent, AT&T, CenturyLink,
Ericsson, Sprint and Verizon”
“The first project under the DSI has already started. In July, ATIS launched ORCA,
which stands for Open Real-Time Communications APIs, an open source project that
will mask the complexity of end-to-end signaling for real-time communication, allowing
developers to focus on embedding innovative new functionality to their applications,
such as high-quality voice and/or video calls. ORCA has successfully developed initial
client-side software called orca.js, with the “.js” denoting creation of a JavaScript library.
The client-side binding is network- and protocol- independent, linking to supporting
implementation libraries to allow developers consistent access to the robust services
provided by IMS networks”

27. WebRTC interop Activity Group
“focuses on interoperability issues relating to the use of WebRTC”
“the group is focused on enterprise WebRTC , interworking of
WebRTC and other carrier technologies, and other existing
videoconferencing systems”
“develop an interoperability test framework and prepare for IOT
events”

28. Summary
●
●
●
each deployment/vendor is implementing its own
proprietary signaling mechanism
WebRTC signaling and media is incompatible with
existing VoIP deployments – gateways are required
to bridge the two worlds
the WebRTC API can have different flavors

29. MORE
INFORMATION
VICTOR PASCUAL
Chief Strategy Officer
victor.pascual@quobis.com
Twitter: @victorpascual

30. MORE
INFORMATION
BACKUP SLIDES

31. WebRTC client app: SIPPO from Quobis
Corporate endpoint fully-interoperable with
SIP networks and 3rd party WebRTC gateways
Main features:
- Audio/video
- Interactive chat
- Presence
- Contact list
- File transfer
- Screen sharing
- Dialpad
- etc.
Signaling agnostic - Browser agnostic - API to build your own apps.

32. How to make things work?

33. Reference Architecture
SIPPO: Client + Server component

34. 3GPP architecture (under discussion)
SIPPO Server = WebRTC Portal + more things
Third Party WebRTC-SIP gateway

35. SIPPO Server: Control, provision, configure and
customize your WebRTC Clients
● RESTful APIs for management of users and web
clients
● Seven modules: Authentication, Authorization,
Accounting, Contact mgmt, Branding, File
sharing, Statistics.
● Connection to LDAP/AD for Authentication,
Authorization and Contact Management.
● Integration with Facebook, Gmail, etc.
● Support for identity federation
● Diameter for integration with backend.
● Etc.