Get Over it: WebRTC isn’t Peer-to-Peer

It is. But it really isn't. Confused?

There's so much misunderstanding about WebRTC that it is funny at times. People throw into a conversation sentences like "WebRTC is just peer-to-peer - it can't do a large conference service like you can with [PLACE-YOUR-COMPANY-NAME-HERE]". As with anything else in life, such comparisons are plain wrong. As I always say: WebRTC is just a technology. It is up to you to develop your service on top of it. If that service happens to be a large conferencing service, then why not? WebRTC being P2P is just as P2P as SIP is. Or H.323. The only difference is that you get to choose your own signaling and your own client. For the first time in history, you get to choose how the topology of your solution will look like from a media and signaling perspective while using a standard specification - and not be bogged down by how people decided to define SIP. Or XMPP. Or whatever. I had a call with a customer recently. A question that was asked during that call is do I see anyone using WebRTC in mobile just because of cost inefficiencies - not because there's a browser requirement hiding somewhere in there. The immediate answer I gave was "definitely". Followed with a few examples to show the point. WebRTC is P2P? WebRTC is for browsers only? WebRTC only works in Chrome and Firefox? There are two ways to think of WebRTC:

1. A standard specification with a default implementation in browsers
2. An open source media engine

If you miss that second option of open source media engine then you are missing out on a lot of the use cases out there that are based on WebRTC. The same applies for server implementations. There are 3 main components to a WebRTC deployment on the server side:

1. Signalling - how do you get the WebRTC clients connected in the first place?
2. NAT traversal - STUN and TURN needs to be mediated
3. Media processing

The first two are mandatory. You'll have them in all production services with WebRTC no matter what. The media processing one is a bit less obvious, but it is necessary in many use cases. I've touched this briefly recently on a post on Dialogic's blog - oftentimes, you'll need a server. Be it for recording, multiparty or something else. When that time comes - it isn't that WebRTC doesn't cut it for the job because it is P2P - it is that you'll need to search beyond Google for a solution. And when you search beyond Google, there are tons of different alternatives:

• DIY from Google's WebRTC open source stack (or by other means)
• Open source frameworks and SDKs, with and without paid support options
• Commercial products, hardware and software based
• Commercial SaaS offerings for specific media components
• Commercial SaaS offerings for the whole shebang
• You can build/integrate it with your own developers or use outsourced developers or software houses

Next time someone dismisses WebRTC for his project because it is only peer-to-peer - tell them to check his initial hypothesis so he won't miss out on some of the options he has available to him.