Handle incompatible signaling servers between federated servers

[danxuliu]

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.

---

From #12604

Differences between the signaling servers in federated environments should be gracefully handled:

• One Nextcloud server uses one signaling mode (external or internal) while the other Nextcloud server uses a different signaling mode
  • Between two Talk 20 servers the federation property in the signaling settings could be empty if both signaling modes are different, so clients would behave just like in Talk 19 (they will connect to the federated signaling server, and it would connect to the federated Nextcloud server, ignoring the remote one).
• Both Nextcloud servers use external signaling, but one uses a version without support for federation (for example, in Talk 19) while the other uses a version with support for federation

Should an additional configuration capability to know if both the remote and the federated servers are using the same signaling server mode (external or internal, as they are not compatible)? Or just rely on the signaling settings as described above? But even if a configuration capability can be used to know the signaling mode, how to handle different feature support between the external signaling servers?

[crowetic]

I have a similar issue I think...

I have two federated clouds, with configuration to allow both to communicate, and federated talk allowed, they initially allowed me to connect and add a federated user... However... one of the servers started having strange issues, so I re-installed the signaling server on another domain.

now the other federated server is looking for the previous domain for the signaling server on the other cloud.

I'll illustrate a little better...

c cloud - server with signaling on sig.c.com - signaling was changed to cs.c.com

q cloud - previously connected to c cloud and aware of signaling server on sig.c.com, but once c cloud changed to cs.c.com it is still looking for sig.c.com and failing to find it (because it isn't there anymore...) but it is giving a strange error related to SSL, saying the cert is invalid for that domain.

But it shouldn't be looking for the old sig.c.com anymore, it should be able to receive the updated cs.c.com signaling server, no?

[nickvergessen]

Can you try to restart both signaling servers? One might have wrongly cached data

[crowetic]

Can you try to restart both signaling servers? One might have wrongly cached data

Yes, I was planning on doing just that. I cannot restart one of them at the moment, as it is in use pretty heavily, but at first availability I will do so and reply with the results. Thank you for the reply!