While debugging issues reported by Michael Diordiev I noticed something about our usage of JIDs and COLIBRI endpoint IDs, which leads to problems if the JIDs are persistent (e.g. if after a page refresh the MUC JID does not change).
In our regular use-case (e.g. anonymous XMPP auth, vanilla jitsi-meet code, config.useNicks=false (whatever that is)) we get a randomly generated username from the XMPP server, and we use part of it as our MUC JID:
My Jabber ID: deadbeef-030a-4a9f-92a2-3d4847900a36@domain/whatever
Joined MUC as firstname.lastname@example.org/deadbeef
If the user refreshes the page, the server generates a new JID, this leads to a new MUC JID, and all is good. However if for some reason the client uses the same MUC JID (reuses "deadbeef") there are problems.
Jicofo uses the resource from the MUC JID ("deadbeef") in COLIBRI for endpoint-id and channel-bundle-id. In this case after a refresh jicofo will invite the participant as a new participant and (try to) allocate new COLIBRI channels using channel-bundle-id="deadbeef". If the "deadbeef" transport manager still exists in videobridge for some reason (as has been observed in log files), this causes a problem.
I don't know if the this happens when we use XMPP authentication (or other kinds of authentication). Pawel, what do you think?
In any case, I think we should address this. IIRC, endpoint-id's (and later channel-bundle-id's) we introduced as identifiers for, well, endpoints, and the (re-)use of the MUC JID resource was just for convenience. I suggest that we have jicofo generate a new unique identifier for each new participant and use it for endpoint-id and channel-bundle-id.