Kill refreshing of signaling settings?

[nickvergessen]

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

---

Steps to reproduce

1. Change from one room to another
2. Have the network tab open
3. See a request to GET /ocs/v2.php/apps/spreed/api/v3/signaling/settings?token=TOKEN

In case internal signaling is used or if external signaling is used with only 1 HPB configured, the request will always return the same signaling server, so we will always NOT hit:

spreed/src/utils/webrtc/index.js

Lines 91 to 104 in b753868

	if (signaling && signaling.settings.server !== settings.server) {
	if (webRtc) {
	webRtc.disconnect()
	webRtc = null
	}
	signaling.disconnect()
	signaling = null
	tokensInSignaling = {}
	}
	if (!signaling) {
	signaling = Signaling.createConnection(settings)
	}

So the signaling settings are always the same and unless you join the call it is not needed.
Only when you join the call a refresh of the TURN details would make sense to ensure that your TURN ticket is new enough, ref #6323

But since that ticket is still open we could also have a look at that after this change.

Thoughts? @fancycode @danxuliu

[nickvergessen]

If in the meantime a second server would have been added, or signaling mode changed, the talk hash would be dirty and clicking on another chat would reload the page preventing old usage anyway.

[nickvergessen]

I think the request is not very heavy, but for the company call scenario that is at:

      9 /2022:13:59
     27 /2022:14:00
     14 /2022:14:01
      8 /2022:14:02
      9 /2022:14:03

67 requests done or not

[fancycode]

Sounds good to me. Every request removed is a good thing ;-)

Once you join the call (or subscribe other peer connections), you could then check if you still have valid TURN credentials and if so, get rid of this request, too (#6323).

[danxuliu]

Yes, I think that refreshing the signaling settings can be removed if there is no external signaling server or if there is only one external signaling server.

However, refreshing the signaling settings when joining a conversation would be still needed if there is more than one external signaling server, so I guess that the signaling settings response should include something like totalServerCount: int, serverCanChange: boolean or something like that so the clients know if they need to refresh the settings when joining a conversation or not.

[nickvergessen]

I would just go with a new singaling mode string similarly to the conversation clustering one