I had Jibri (based on 2018-09-26 SNAPSHOT build) running and trying to reconnect to my XMPP server (Openfire) while the XMPP server and Jicofo were not started yet. As soon as the XMPP server was started, Jibri was able to reconnect and create the JibriBrewery MUC room. However, when I started Jicofo, the “focus” user failed to create or join JibriBrewery because Jibri was the owner of the room. And it was not obvious from the log. To workaround this issue, I had to make sure that Jicofo was started before Jibri. Does anyone encounter this issue? Should it be considered as a bug in Jibri that it didn’t wait until JibriBrewery was created by the “focus” user?
This should be a bug, but I would say it is a jicofo one, it should not panic if jibri is already in the muc.
@damencho I don’t have a strong feeling if this bug belongs to Jicofo. However, it may be more work for Jicofo to have “focus” to claim the ownership of JibriBrewery after “jibri” became the owner by mistake. Just my 2 cents.
Nope, I disagree, I don’t see why at all jicofo needs to be the owner of the room. It just needs to be able to join see participants (available jibris) and check their status (presence).
And the other thing is there is no way for jibri to wait for jicofo to join in the muc and then to join. In order to check whether jicofo had joined, jibri needs to join the muc.
Thanks for the report, we will look at it at some point.
Thank you for correct my misunderstanding of “focus” role in JibriBrewery.
It seems that jibri uses MucClient createOrJoin method for JibriBrewery, but it does not send a form to unlock the room after JibriBrewery was created. Can you confirm this?
In Jicofo, it also uses createOrJoin, but it always sends a configuration form which will automatically unlock the room.
Vincent Lau (Magnet Systems)
What do you mean by unlock the room?
According to the XMPP MUC specification, after an owner created a room, the room cannot be joined by other participants until the room is configured. It is what a “locked” room means. Typically the owner sends a configuration form to the MUC service and it will unlock the room. In Jicofo, it uses a form with one field name “muc#roomconfig_whois” and the value “anyone”.
Jibri probably can send a similar form to unlock the room. But I am not sure what error Jicofo may encounter if it tries to send the form when “focus” user is not an owner. That is why I was misled to think that “focus” had to be the owner of JibriBrewery.
Vincent Lau (Magnet Systems)
Just FYI. Here is the IQ request of the configuration form sent by JibriBrewery room owner:
<iq to=‘firstname.lastname@example.org’ id=‘5ICL0-49’ type=‘set’>
<x xmlns=‘jabber:x:data’ type=‘submit’>
<field var=‘muc#roomconfig_whois’ type=‘list-single’><value>anyone</value></field>
Hey @bbaldino, seems this is a bug in jicoco in MucClient. If it happens the client using MucClient to join first it doesn’t send the muc configuration form as required by XEP which will prevent anyone to join that muc. So if jibri/jvb enters that muc before jicofo, jicofo will not be allowed to join after that.
Thanks @Vincent_Lau for the debugging.
@damencho is this only for the first time the room is ‘created’ after prosody is started? I know I’ve (re)started Jibri before Jicofo plenty of times and it’s worked.
I suppose its the first time the room is created … That’s what I think @Vincent_Lau reported.