From 457578a26a77651f87f92119b33262acd4eec5bc Mon Sep 17 00:00:00 2001 From: David Baker Date: Fri, 3 Mar 2023 16:48:56 +0000 Subject: [PATCH] Add some more detail on how focus/client impl could work --- doc/mid-based-signalling.md | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/doc/mid-based-signalling.md b/doc/mid-based-signalling.md index 2c95b6250..d18df7b35 100644 --- a/doc/mid-based-signalling.md +++ b/doc/mid-based-signalling.md @@ -148,6 +148,28 @@ XXX: How flat vs deep do we want the structure to be here? I've done it quite de organised by user ID / device ID / media group UUID, but they could also just be a flat list of tracks. It would be more duplication but maybe less effort to read. +The expected behaviour here would be for foci to essentially maintain a structure with all +tracks being pushed to it. This structure would probably have call IDs as a top level index, +then look very similar to the structure of the `m.call.advertise` event. It could either keep +a reference to the transceiver it was receiving media on in the structure itself alongside +the media UUID, or maintain a separate map of media UUID to transceiver / peer connection such +that the first structure could be marshalled to JSON and sent to clients as-is. + +On the client side, the client will essentially take the `m.call.advertise` data and save it +almost as-is. It would probably cross-reference it against the call member state events to +ensure that it wasn't showing feeds for any users that did not have state events indicating +that they were in the call, although if we trust the focus and assume that conf IDs are unique +enough to be unguessable, this may be unnecessary. + +In the simplest case, the client will simply iterate through this structure and add every +media UUID it finds to an `m.call.subscribe` message. + +The most complex part is that when the `m.call.describe` message arrives back from the focus, +it will have to search through the data from the `m.call.advertise` message to map the tracks +it is now receving to the right user IDs (XXX: it could build them into a map to make this lookup +efficient, although if we make the advertise message indexed by media UUID then it already has +a map indexed by the correct thing...) + The `select_answer` is also tweaked to be more extensible-event like although is essentially the same: