TURN wouldn't involve the signaltower if we were to leave it open unauthenticated. But that's not a good idea and it becomes easy to exploit our server resources. Thus, the signaltower needs to be able to communicate with a locally (or remotely?) installed turnserver (in most cases this will be coturn) to receive tokens that we can offer the clients when they ask for it (aka: STUN failed).
The client could ask via a new palava protocol message:
{event: "get_turn_credential"}
and receive it via:
{event: "turn_credential", credential: "..."}
It would be good to reply to maximum 1 of these requests per websocket connection. And maybe even wait for a few hundred milliseconds between handing out a credential to any connection (to prevent that somebody makes many connections to grad a lot of the tokens).
TURN wouldn't involve the signaltower if we were to leave it open unauthenticated. But that's not a good idea and it becomes easy to exploit our server resources. Thus, the signaltower needs to be able to communicate with a locally (or remotely?) installed turnserver (in most cases this will be coturn) to receive tokens that we can offer the clients when they ask for it (aka: STUN failed). The client could ask via a new palava protocol message:
{event: "get_turn_credential"}and receive it via:{event: "turn_credential", credential: "..."}It would be good to reply to maximum 1 of these requests per websocket connection. And maybe even wait for a few hundred milliseconds between handing out a credential to any connection (to prevent that somebody makes many connections to grad a lot of the tokens).Information regarding the TURN Rest API: