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?