Add some more detail on how focus/client impl could work

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: