4 Facts You Need to Know about P2P in WebRTC

While WebRTC is said to be P2P, that might not be what you have expected. WebRTC is said to be a P2P protocol, and while it is, there are a lot of misconceptions about what that really means. Here are 4 truths that you should know about WebRTC before you use P2P as the reason for using it over other technologies.

1. WebRTC is the same as VoIP when it comes to P2P

This is the sad truth. WebRTC doesn't bring any real innovation over what goes in the network – it comes with a few evolutionary steps such as trickle ice, but at the end of the day, it bears a lot of resemblance to what came before it in VoIP. It is also why you can see so many vendors using it as a media engine for their SIP deployments. What does this mean? Media flows from one endpoint to the other in a kind of "best effort" mechanism. Whenever possible and assuming the service that integrated WebRTC built it with that intention that will be the case. And as stated, this is also the case with other VoIP protocols.

2. WebRTC is a unique P2P solution when you focus on web browsers

If there is one place where WebRTC brings some true revolution / shake up, it is in the web browser. The web browser paradigm was built around clients and servers, where communication is conducted from the web browser, acting as a client and connecting to a web server. Web servers usually don't have the ability to connect to the web browser at all, and to do that, techniques like Comet and BOSH have been devised. The end result? All communication goes via a server, which adds latency, an additional point of failure, puts a burden on the server in terms of computing and bandwidth; and generally, it can be a hassle. What WebRTC does is changes this paradigm – it enables web browsers to communicate directly with one another and send voice, video and any other message they see fit. This way, web developers can build web services that require less processing and bandwidth in their backend.

3. P2P still requires STUN and TURN

I did mention that WebRTC tries its best to send media directly between browsers. Well… sometimes it can't. the reason is NAT devices and firewalls around the internet in the path of the media. In such cases, STUN servers are required so each browser/endpoint can determine his own public address and TURN may be required to relay all media through an intermediary TURN server. So that P2P attribute can break depending on the location of the devices in question.

4. WebRTC still requires an external signaling protocol

It is also important to remember that WebRTC only deals with the media. Somehow, there should be signaling involved to be able to get the IP addresses of the browsers that are going to communicate directly. To that end, SIP, XMPP or any other form of signaling needs to be adopted, and these usually require servers.