🌐 Federated calls 🤙 - Overview

[nickvergessen]

• #11274
• #11275
• nextcloud/talk-ios#1463
• nextcloud/talk-android#3530

[nickvergessen]

Federated Calls

Problems

• HPB Session ID vs. PHP Session ID (means the "oc_talk_sessions.session_id" from the database)
• End user only has PHP Session on own server

Attempts

1 - Many HPBs

• Everyone connects to host HPB
• Still connected to local HPB for conversation list update and other things?
• Facts:
  • Need to extend CSP
  • Might not scale forever or require page reloading before joining a call
  • Many changes in Web, Android and iOS
  • Little changes in the HPB

2 - own HPB only (external only)

• own HPB acts like a client towards the host HPB
• identifies via signaling ticket it gets from requesting remote capabilities
• can be authenticated then by the HPB to be a valid "client" (helloAuthParams)
  • Needs to include the "local PHP session" so the host can still provide a list of HPB session => PHP session ( + actor type + actor ID + server URL for uniqueness and to be able to map to an entry from the participant list to get the display name, generate avatar URLs, ...)
• Facts:
  • (Many) changes in the HPB authentication?
  • Requires new HPB capability
    • If not provided by either HPB, a fed. call is not possible
  • Very little client changes
  • Signaling API / capabilities needs to proxy the signaling tickets from the host API and the clients need to pass it to their own HPB
  • joining conversation and call needs to be locally and still proxied
  • oc_talk_sessions entry needs to be created locally and on host
  • session timeout should ignore federated participants? Or they need to be pinged/kept a live by the host HPB

Draft for approach 2

• Daniel checks if the HPBs could play together when they would know each others internal secrets (ETA first week of June)
• Afterwards the approach is tried to kick of together with @fancycode
• Need the working "auth" handling before clients can start testing/working
• Look into the HPB session ID to PHP session ID handling, whether the new approach can be used to simplify the current "messy" diverging behaviour for internal/external signaling

[fancycode]

Daniel checks if the HPBs could play together when they would know each others internal secrets (ETA first week of June)

Not sure what you want to try here. Even if the secrets are the same on different signaling servers, you can't access sessions of other servers (e.g. by resuming).

In general:
For strukturag/nextcloud-spreed-signaling#715 I already have some sort of "proxy mode" in the signaling server. Currently this uses GRPC for the clustered more, so we can't use the same for federation, but something similar could also be done with WebSockets here.

We could add a new client type "proxy" in the hello request that will internally connect to an external signaling server, do the normal client auth and proxy all messages. This would however still require another connection from the clients for federated calls - or is this ok?

Another possibility would be to extend the room request, so you could pass information on the federated room and the signaling server will then (for this room) establish a proxy connection to the remote host. This would be completely transparent to the user then and not require another signaling connection. Also probably would be the most complex implementation on the signaling server side ;-)