WebRTC. How to establish a p2p connection between browsers

Fig 1. Simultaneous work in the flowchart editor

WebRTC allows browsers to communicate directly without a server. You can transmit video, sound and data. You can establish a WebRTC connection in different ways. The article describes how a WebRTC connection is established between users of the dgrm.net flowchart editor.

In DGRM, clients do not connect “everyone to everyone”. Events are sent to clients by the browser of the meeting initiator

When a user adds a shape, changes colour, or moves the cursor, event data is sent via WebRTC to the browser of the meeting initiator. The initiator forwards the data to other users.

Fig 2. Clients are not connected “each to each”. Clients send events to the meeting initiator. The initiator forwards events to other clients.

To connect via WebRTC, browsers must exchange connection parameters

When a client connects to an initiator, it must inform the initiator of the connection parameters: connection requirements and its network addresses.

Example of connection requirements: should the connection support video, what codec to use, etc. DGRM only transfers JSON strings.

A client can have several network addresses. For example, one address is on the local network, the other is on the external network. If the client and the meeting initiator are on the same local network, the local network address will be used for the connection. The browser itself cannot find out the address on the external network. To obtain its external address, the browser makes a request to a special STUN server. The STUN server returns its external addresses to the browser. There are free STUN servers, for example from Google.

The connection parameters that the client passes when connecting are called SDPOffer. The meeting initiator generates SDPAnswer based on SDPOffer. And sends SDPAnswer to the client. SDPAnswer contains the network addresses of the initiator.

Fig 3. To connect via WebRTC, the client must pass the SDPOffer connection parameters to the meeting initiator. Based on the SDPOffer, the initiator generates an SDPAnswer and transmits it to the client. After this, the browsers recognize each other’s addresses and a WebRTC connection is established.

Exchange of WebRTC connection parameters via your server

You can exchange connection parameters in different ways. For example, manually via messenger. SDPOffer and SDPOffer are strings. Using JavaScript and the browser API, you can get SDPOffer/SDPAnswer, display it on the page, copy it and send it to the messenger.

v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0 8 97
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 51372 RTP/AVP 31 32
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000

Listing 1. SDPOffer example. SDPOffer and SDPAnswer are strings

DGRM uses its own server to exchange connection parameters.

Fig 4. Creating an online meeting in dgrm.net

When the meeting initiator clicks “Live collaboration”:

• The initiator’s browser sends a “create meeting” request with a random meeting id to the DGRM server.
• The server remembers the meeting id.
• The initiator sends a link with the meeting ID via messenger.
• The client follows the link.
• The client browser generates SDPOffer. Sends the meeting id, your client id and SDPOffer to the server.
• The server remembers SDPOffer.
• The initiator’s browser periodically queries the server “give SDPOffers for the meeting id.”
• The initiator’s browser, when receiving SDPOffer, generates SDPAnswer. Sends the meeting id, client id and SDPAnswer to the server.
• The server remembers SDPAnswer
• After a pause, the client browser requests SDPAnswer from the server.
• As soon as the client receives SDPAnswer, a WebRTC connection is established.

Fig 5. Scheme for exchanging WebRTC connection parameters via your server

Clarifications to the diagram

Why aren’t websockets used for SDPOffer/SDPAnswer exchange?

Here we use periodic server polls. WebRTC connection is established in a couple of seconds. If you use web sockets or server-events, the WebRTC connection will be established faster. But in this scheme there are fewer requirements for the server.

Why can’t the initiator send SDPAnswer to the client directly via WebRTC?

The initiator received SDPOffer. SDPOffer contains client addresses. Why not send SDPAnswer directly to the client? I don’t know. I could not get. I asked in WebRTC groups, they say this is not possible.

Why is SDPOffer made by the client and not the initiator?

The initiator can make one SDPOffer for all clients. Then the exchange scheme will be simplified. Why didn’t you do so? The initiator must have a WebRTC connection with each client. One SDPOffer cannot be used in multiple connections.

I don’t want to make my own implementation. Are there ready-made solutions?

There are services for developers that not only exchange SDPOffer/SDPAnswer, but also offer a TURN server. If the p2p connection cannot be established, data begins to be sent through the TURN server. TURN is a fallback option.