RTCWEB / WebRTC is designed to let two or more browser-enabled devices communicate P2P (peer-to-peer) with audio, video or data. But there’s a big catch. The browsers can’t communicate out of the box unless some undefined “external process” gathers information about each browser and hands the information to the other browser.

This mystical external process is known as “on the wire signaling”. Gathering information from a browser/peer needed to communicate isn’t incredibly difficult for a moderately talented programmer, nor is exchanging the required information. All that would be required is some kind of go-between web server and a socket or two. This solution is relatively simple and there are other companies setting themselves up to provide that kind of service offering.

But that kind of signaling will quickly becomes unwieldy to manage in the real world and misses many critical use cases and components in much larger deployments. The overriding presumption in such a model assumes both ends want to communicate and does not define how they want to communicate, let alone addressing very complex security issues.

So what does make up a robust and complete P2P communication solution?

A well thought out P2P solution should addresses these concerns:

1. Initiation of communication between peers that are not actively expecting communication
2. Exchanging the types of communication desired (audio/video/text/etc.)
3. Allow peers the option to allow or disallow communication
4. Allow peer to disengage communication at any time gracefully
5. Changing the nature of the communication at any time (adding or removing media types like audio/video/text, media on hold, transferring sessions to other participants, etc.)
6. Handle users’ identities so that users on independent systems can interoperate (and identify themselves when communicating)
7. Handle users logged into multiple locations as the same user
8. Find users to communicate with by their known identities (social, generic, 3rd party, etc)
9. Validate the identity of the user you think you are connecting with
10. Secure communication channels in a way that even servers involved in the “communication setup” are not able to decrypt information exchanged between peers
11. Handle group conversations amongst peers without needing servers to relay the data
12. Handle communication to applications outside to the browser (e.g. interoperate with mobile apps)

A well designed P2P platform should be designed to enable users on various websites to talk beyond each respective web silo. Users of one website can find and communicate with users on another website and even to users on mobile devices.

It should work with your existing identity model. Alice and Bob on your website are still known as Alice and Bob in the P2P network. You don’t need to administer and map a separate database of usernames and password that would be required with other legacy signaling protocols.

The network should allow users to locate other users by their social IDs, phone numbers, email addresses or by using your own custom defined identities – social or otherwise. It should be built with strong security in mind. Each user has their own private and public key, which when tied with an identity model yield strong proof of identity with completely private communications between peers.

A developer should be able to take the open source libraries and rapidly build and deploy powerful client applications with all of these features built-in and deploy without the headache of managing a communications network. No web developer I have ever met volunteered to be the one trying to figure out the complex ins-and-outs of everything that a good P2P design will resolve. So, I ask you, do you as a developer really want to be stuck in a little silo of communication, maintaining your own custom communication signalling protocol?

If you are looking to leverage WebRTC in a browser or if you just want to build a powerful communications feature into an app, you owe it to yourself to do the research. Before you get headlong into your project and find out the tech you chose was not up to the challenge, take a look around. Libraries like the one found in the Open Peer project could very well fit the bill.

—

Authored by Robin Raymond, edited by Erik Lagerway