Fig 1. Live collaboration in the diagram editor using WebRTC

WebRTC allows browsers to communicate directly without a server. You can transmit video, sound and data.

To connect, browsers must exchange connection parameters: SDP and ICECandidates

SDP describes the connection requirements: what video/audio/text will be transmitted, what codecs are supported. ICECandidat are addresses where to send packets.

For WebRTC connection you need:

• Exchange connection requirements.
• Exchange addresses

Fig 2. Setting up a WebRTC connection, ICECandidates are sent separately. Open the diagram.

The exchange of connection parameters is called Signaling

You can exchange parameters manually via messenger or create a signal server.

There is no connection between browsers yet, but you need to exchange initial parameters – see Fig. 2.

Parameters are presented as strings. They can be sent to each other manually, for example via messenger.

Can be automated. Make a signaling server that will send parameters between clients.

Exchange of connection requirements: SDPOffer, SDPAnswer

Connection requirements depend on the application. For example, for video communication, browsers must choose a codec that both support. Browsers have an API that generates SDP.

See Figure 2. “Session descriptors exchange”.

• Alice generates an SDPOffer indicating the supported codecs. Sends to Bob.
• Bob receives SDPOffer and, based on it, creates SDPAnswer: selects the codec that he has and is presented in SDPOffer. Note – you cannot generate SDPAnswer without SDPOffer. Bob sends SDPAnswer to Alice.
• Alice installs SDPAnswer: the codec from SDPAnswer will be used for broadcasting.

Exchange of addresses: ICECandidates

There can be several ICECandidates. For example, one address is on the local network, another on the external network. To find out your address, STUN server is used.

See Figure 2. “Address exchange”.

Alice finds out her addresses at which she can receive packages. And sends them to Bob. Bob selects from the candidate addresses received.

Alice can have several addresses. For example, one address is on the local network, another on the external network. If Bob is on the same local network, Alice and Bob connect at the local address.

The browser does not know its address. To find out your address, the browser makes a request to a special STUN server. The STUN server tells the browser its (the browser's) external address. There are public STUN servers, for example Google.

You can receive all your ICECandidates and send them all as part of SDP

In this case, Bob immediately receives all the necessary parameters for the connection. But, for some reason, even knowing all of Alice’s ICECandidates, he cannot respond via WebRTC – you still need to send SDPAnswer via signaling.

Fig 3. Setting up a WebRTC connection, ICECandidates are sent as part of SDP

Please note: Bob cannot send SDPAnswer over WebRTC. Until Alice installs SDPAnswer, WebRTC will not happen. Why this is so is not clear.