Answered a similar question for another user here recently.
Basically your backend will manage a ledger of created rooms from talking to all the clients through socket connections. This is where you can manage who users connect with.
The main objective is to successfully get an IceCandidate with a session description protocol (sdp) object containing information about who they’re connecting to…to each of the clients in a room.
Believe it or not, the example project I made showcases all that ^ locally. I’m guessing that’s why it’s become so popular. Quite a bit easier to digest than a full stack example imo. Going from the local example to a networked one involves setting up a backend (like an nodejs + express + socketio server) and slightly changing the webRTC flow.
Locally it’s:
Nothing -> (press share video) -> Sharing local video -> (press start call) -> Call immediately negotiated and started
Networked it’s:
Nothing -> (press share video) -> Sharing local video -> (press start call) -> Server puts client in a socketio room and you broadcast you’re there and start negotiating calls if needed and wait for others to broadcast when they join
Here’s some of my code for how that negotiation works frontend