4 Facts You Need to Know about P2P in WebRTC

September 30, 2013

While WebRTC is said to be P2P, that might not be what you have expected.4 facts

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.


You may also like

Comment​

Your email address will not be published. Required fields are marked

  1. So what are the alternatives for 4. without a server involved ?

    SMS/Texting ? DHT (like P2P filesharing), and exchanging with other people in the same room like: near sound data transfer and NFC ? Anything else I’m forgetting ?

    1. I don’t think there is, but frankly, I don’t think it is a real issue.

      Online services today (think Facebook) can hold millions of users at the same time and handle their signaling interactions quite well. WebRTC doesn’t live in its own bubble – it is designed to fit into existing ecosystems, where servers are going to be a part of the deal anyway.

      1. I don’t think it’s a problem either, just wondering what else is possible. And maybe someone will make some cool application with it. 🙂 What if you see someone you haven’t seen in a long time standing nearby at a packed concert but can’t reach them because you can hardly move ? Or at they are at the other side of a busy street or a kanal maybe ? You can use a QRCode to communicate your IP-address in an ad hoc fashion. Then you can call them. 🙂 Or maybe it will never happen or maybe others have already done that other systems than WebRTC.

        1. I guess you could also use it to change communication devices.

          What if you were in sales talking to a potential customer on a landline.

          But needed to show something on your screen.

          You can open a webrtc (web)app on your desktop/laptop machine and on your smartphone on both sides, use sound to exchange peer-information over the landline with between both parties. You can use use QRCodes to connect the desktop/laptop machine with the smartphone. Now you can talk to each other on the smartphone (without exchanging your personal phone-number) and see whatever is on the screen. You can also walk away from your desk to get something to drink while you are still talking on the phone. The non-DECT landline isn’t keeping you at your desk.

          Just some silly (?) ideas.

    2. Lennie, although not strictly server-less, leveraging someone else’s messaging backbone is a way of avoiding your own signaling servers and just relying on a cloud service, that you may pay for but may also meet other application needs. PubNub has shown (at WebRTCExpo Atlanta) how their global pub/sub network can easily do WebRTC signaling for you as well as other things, all with a simpleAPI, and there are quite a few other emerging real-time, MBaaS, and Google, Amazon, and other IaaS messaging buses emerging. I discuss some of this flexibility at http://bit.ly/1d8fw52

  2. On 1) and 3) I think webrtc has helped because you now have a very active open sourced stack (maybe two, I am unsure of how Firefox’s stack is actively developed) and hopefully that makes the overall STUN / TURN space better.

    Also, having P2P data capabilities that use SCTP is fairly unique and deserves attention.

      1. In this world with NSA snooping or just crappy WiFi encryption, always encrypted WebRTC is a very useful thing to have. Next step on the list is HTTP/2.0 (also always encrypted).

      1. But WebRTC is a new tech. Its specification is in flux. Its implementation in browsers is constantly changing. The information you find about WebRTC can often be outdated or incorrect.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}