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:
- A standard specification with a default implementation in browsers
- 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:
- Signalling – how do you get the WebRTC clients connected in the first place?
- NAT traversal – STUN and TURN needs to be mediated
- 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.
Need to understand WebRTC and how to design and architect real world solutions with it? A first step is to understand the servers used to connect WebRTC.
Perhaps I’ve led a sheltered life, but I’ve never come across the mindset that WebRTC is only P2P. On the other hand, the notion that it’s limited to web browsers is indeed widespread, and folks really don’t understand the importance of building mobile apps that have a WebRTC media engine under the covers.
Definitely sheltered 🙂
Appropriateness is the name of the game. Choosing SIP, H.323, WebRTC or an installed client is a matter of your use case.
WebRTC connects just as well to software defined collaboration networks like Viewme. Wrap it up in some nice CSS for a ‘branded’ experience. For the infrequent or single use person this is a great alternative – while the regular user takes advantage of an installed ‘pro’ client.
Joe – thanks for sharing.
To me, the fact that you choose between WebRTC and SIP shows a problem 🙂
WebRTC can fit nicely into SIP use cases by being its media engine for example – might not work with legacy, but for other use cases? Be it frequent users, large teams, whatever…
Agree that it’s not all about p2p… although, having done a lot of trials, I’m still left under impression that rigorous telco standard compliance (e.g. SDP) is not of a paramount importance to, shall we say, whoever is running the show (since in p2p scenario Chrome is always going to understand Chrom etc…). It could be just my gut feeling though…
Dennis, rigorous telco standard compliance = webrtc in production some time in 2030. I, for one, can’t wait that long.
Makes sense. Telco community is falling behind with their traditional product life circle management.
Totally agree. webRTC is way more than P2P. One can even cherrypick. Its up to you what you do with it. Phone 2 videoconferencing? Fileshare? Broadcast? All possible and you do not require black boxes of software anymore to do so
Webrtc is fully P2P. Check out world’s best implementation of WebRTC for real time communication at https://www.letsbrik.co
Didn’t know if I want to mark this one as trash or spam so decided to approve it 🙂
Mike – you might want to add this service also to https://webrtcindex.com – that’s where all the world’s best implementations of WebRTC are listed.
Maybe I’m wrong, but calling WebRTC a p2p method to share stream is basically correct. The basic operation of WebRTC is connecting stream end to end, point to point, for any project you can imagine. To take your exemple of a project expecting a massive visio chat room, clients that will use WebRTC will publish their video stream X times depending how many users are connected in the same time, resulting high bw consumption and poor video quality. I mean WebRTC is actually not for all projects, and calling it p2p seems reflect how it works basically.
Didier,
Yes and no. It is P2P, but most think this means no servers needed, which is plain wrong.
For this, you use a signaling server : a server that can pass messages between WebRTC clients (peers). The actual messages are plain text: stringified JavaScript objects.