Add WebRTC Signalling server logic

[cwisniew]

Is your feature request related to a problem? Please describe.
Add signalling server logic to the server registry to support RPTools/maptool#2876

Describe the solution you'd like
When the pilot/beta phase of the WebRTC connection for MapTool is completed the signalling server logic will need to be rolled into the registry.

[thelsing]

I think we should also store a server type in the server registry. The player connecting to a server shouldn't have to know if he has to use WebRTC or not. This information should come from the registry. Anticipating more server types in the future it should be an enum an not a IsWebRTC bool IMO.

[cwisniew]

I think we should also store a server type in the server registry. The player connecting to a server shouldn't have to know if he has to use WebRTC or not. This information should come from the registry. Anticipating more server types in the future it should be an enum an not a IsWebRTC bool IMO.

I agree, at the moment the server registry is completely unaware this is going on but when when we add the WebRTC signalling support to it then we can remove the use WebRTC checkbox from the connect to server dialog and have the client retrieve that information from the registry.

[thelsing]

We probably also need a TURN server for webRTC. TURN-servers require authentication. I think it would be a bad idea to put credentials for our TURN server in the source code because other people will probably use up our traffic.

coturn can be configured to use a mysql backend. How about we add the coturn tables to our db and add secrets an allowed ips for users during the signaling process.

So it would work like:

[fishface60]

We probably also need a TURN server for webRTC. TURN-servers require authentication. I think it would be a bad idea to put credentials for our TURN server in the source code because other people will probably use up our traffic.

Another option would be that clients do UPnP-IGD/Port Forwarding too so that WebRTC reverse connections can work, for if players are more reachable than the server.

After doing that MapTool clients could try to start a TURN server themselves (the jitsi one might be easier to integrate) and the server could send a client's TURN server to new peers.

The improvement over the status-quo is that you only need one player to have accessible internet rather than the GM has to, but not enough for making it usable when every player has awkward ISP/Routers.

Allowing clients to opt into relaying for other users would solve the credentials problem since they'll be short-lived and the registry could limit how many clients are referred to a client's hosted TURN server to reduce the harm if the MapTool API is being abused to expose people's TURN servers.

It also has the problem of requiring a host to leave their TURN server running while their TURN server is being used, so I'd probably just go with adding some UI to MapTool settings to allow players to configure a TURN server and community members in support channels who are hosting one could DM credentials for theirs if they want to help.