Why Build on Anything Other Than WebRTC?

Building with WebRTC

I had several questions lately from vertical service providers contemplating about the technology to use for their video service.

They were hesitant if building with WebRTC is the right way to go.

Then I came across this presentation by Leo Papadopoulos, CTO & Co-founder of Cloud9 Technologies and decided to tie these two things together.

Cloud9 has made their technology choice in the early days of WebRTC and took a slightly different approach to using it, an approach that served their mission critical needs. His presentation explains why this was one of the best choices they have made.

Let’s review these points one by one.

Web App vs. PSTN App

It is all about your viewpoint. WebRTC takes the Web view approach, it is built for the Web and for Web developers.

Think of the rate in which your telephony application is updated, be it a server or an IP Phone and what it takes to actually make that upgrade.

Now think of making changes to a Web app, it is like updating a Web page. You submit the change and it’s there. To all.

Web apps move in the speed of light compared to telephony applications. That’s one of the reasons why traditional UC companies have a hard time catching up with the new comers such as Slack, WhatsApp, Facebook Workplace…

Web App Servers vs. SIP App Servers

I don’t know about the reliability part in Leo’s explanation (any application can be unreliable) but I can relate to the opportunities in Web app servers. The speed of developing and changing them based on existing frameworks.

As an example, we have built the signaling server of SwitchRTC based on node.js. I compare this to what it took to build a SIP Server back in my VoIP SDK days at Radvision, the size of the team and the speed in which it was built and reached maturity.

WebRTC Developers vs. SIP Developers

I would term this as Web Developers vs. VoIP Developers but there is more granularity to it than just this comparison.

WebRTC was built for the Web and for Web developers. When looking at the browser side and Web applications, Web developers (different from VoIP developers) swim like fish in water in this field and it is by far easier to find a Web developer than it is to find a VoIP developer.

The things a VoIP developer needs to get into when building a VoIP application are by far more complex than what is required to tackle when building a Web application on top of WebRTC. In the case of VoIP applications, you would typically need engineers of different disciplines to cover it all.

Problems reside mainly on the server side and in the areas that touch the media.

Even if you are building a WebRTC based service, if the server side needs to handle media related stuff (meaning it is not just a point to point signaling server type of application), things get more complex. That’s why many use API platforms (that offer the server side + client SDK) or a 3^rd party solution that will handle these complexities.

In SwitchRTC we’ve built our SFU media server model based on a modified version of WebRTC. This saved us a lot of time and effort and gives us interoperabity and feature advantages. It also makes our solution future proof as we “grow” with the new WebRTC releases.

Having said that, playing in the media field requires knowing about media, RTP and networking, something not so common among Web developers. To grasp what it takes to handle these stuff take a look at our hiring posting for a developer. Notice the skills we define as mandatory vs those that are an advantage.

All this is why vendors and service providers prefer to have these server components provided to them by 3^rd party companies vs. building it all by themselves.

WebRTC Stack vs. SIP Stack

These 2 are very different in nature, so different that they sometimes complement each other.

A SIP stack is an implementation of the SIP protocol which is a signaling protocol, it has nothing to do with the media itself, it does use SDP for describing the media.

WebRTC on the other hand is all about the media, it is a media engine. Similar to SIP it uses SDP (that is until ORTC kicks in) but it has nothing to do with signaling or how that SDP is passed between the clients. That’s why some implementations (mainly those that bridge WebRTC and telecom) use SIP over WebSockets for their WebRTC signaling.

Another important point is that WebRTC (through the W3C) defines the APIs so applications running in the browser are compatible. SIP on the other hand doesn’t define the APIs.

I summarize this topic in WebRTC presentations I give through this table.

What	VoIP	WebRTC
Signaling	SIP, H.323	Not defined
Media Offer/Answer	SDP	SDP (Future: ORTC)
Media	RTP/RTCP, SRTP (optional)	SRTP
NAT Traversal	ICE, STUN, TURN	ICE, STUN, TURN
Voice Codecs	G.7xx, AMR, Opus, Silk	G.711, Opus
Video Codecs	H.26x	VP8, H.264, VP9
API	Not defined	JS
Built For	Telecom	Web

Open Source vs. Proprietary Standards

Well, both SIP and WebRTC are standards. SIP is defined by the IETF and WebRTC is defined by both the IETF (all things that go over the wire such as media, security…) and W3C (API related stuff).

The thing is that WebRTC has a limited number of implementations. The well-known one is by Google, WebRTC.org; and the other one is by Ericsson, OpenWebRTC.org.

SIP on the other hand has many “private” or commercial implementations like the one offered by the BU I used to work for at Radvision which is now Spirent (one that I still believe is probably the best and most comprehensive SIP implementation out there). And there are of course open source options as well.

So I wouldn’t make the open source vs. proprietary comparison but rather say that the common implementation of WebRTC used by the industry is open source and developing a private implementation of WebRTC today would by a silly thing to do.

New Services vs. Mature and Fading

In this sense I would say that WebRTC is what powers most of the new services. This is correct for communications centric ones as well as other services that use communications as a feature in them.

Why this is important

Anyone building a new service that requires communications capabilities in it would need a good and special reason to decide to build his service on anything other than WebRTC.

Those who are worried about the stability/maturity or anything else around WebRTC can learn from this case study of Cloud9, a mission critical financial application and many others who are happy they made the right choice. Or they can see what SnapChat, Facebook Messenger, Slack and others are doing, they all based their communications service on WebRTC.