Nothing work when click on "Add breakout room"

Yes and i can’t click on “Join meeting” button on the Home page

That admin line is only for the breakout rooms muc, just to be clear. What do you see in the console when you click on join?

Oh ok ! You told to change on conference component (Sorry, i didn’t understand)
I made this change and i can click on button.
But nothing is happening again … i don’t understand why no breakout room appear after clicking on “Add breakout room”.

FYI, I just tried both admins options at the breakout component as you said:

admins = { “focus@auth.meet.myurl.mytld” } => admins = { “focus@meet.myurl.mytld” }

@Saghul, is also possible to have both at the same time, isn’t it?

admins = { “focus@auth.meet.XXX”, “focus@meet.XXX” }

Unfortunately, none of these options worked for me using any browser (FF,Chrome…)

@Avanhove Can you use the App (Android?, iOS will work for sure :wink: ) to create a breakout room? If you succeed in create and use breakout-rooms properly through the app, your prosody config is fine. So, IMHO must be the something related with the UX/html browser code.

Thank you all!

Hi,

i tested on IOS and it doesn’t work.
The button is here, i can click but anything is done.
Here are logs in debug mode when i’m clicking on the “Add breakout room” button on IOS App

Dec 10 14:38:57 socket	debug	server.lua: accepted new client connection from 127.0.0.1:44934 to 5280
Dec 10 14:38:57 http.server	debug	Firing event: POST /http-bind
Dec 10 14:38:57 mod_bosh	debug	Handling new request table: 0x3eff140: <body rid="3397812832" sid="a41318c8-513d-442b-a1c7-d61ebcb1ec69" xmlns="http://jabber.org/protocol/httpbind"><message to="breakout.gofast-dev-comm-gf4.ceo-vision.com" xmlns="jabber:client"><breakout_rooms subject="Salle annexe #1" type="features/breakout-rooms/add"/></message></body>
----------
Dec 10 14:38:57 mod_bosh	debug	BOSH body open (sid: a41318c8-513d-442b-a1c7-d61ebcb1ec69)
Dec 10 14:38:57 bosha41318c8-513d-442b-a1c7-d61ebcb1ec69	debug	rid: 3397812832, sess: 3397812831, diff: 1
Dec 10 14:38:57 mod_bosh	debug	BOSH stanza received: <message to='breakout.gofast-dev-comm-gf4.ceo-vision.com'>

Dec 10 14:38:57 bosha41318c8-513d-442b-a1c7-d61ebcb1ec69	debug	Received[c2s]: <message to='breakout.gofast-dev-comm-gf4.ceo-vision.com'>
Dec 10 14:38:57 mod_bosh	debug	Session a41318c8-513d-442b-a1c7-d61ebcb1ec69 has 2 out of 1 requests open
Dec 10 14:38:57 mod_bosh	debug	and there are 0 things in the send_buffer:
Dec 10 14:38:57 mod_bosh	debug	We are holding too many requests, so...
Dec 10 14:38:57 mod_bosh	debug	...sending an empty response
Dec 10 14:38:57 mod_bosh	debug	We have an open request, so sending on that
Dec 10 14:38:57 mod_bosh	debug	Request destroyed: table: 0x40409b0
Dec 10 14:38:57 socket	debug	server.lua: closed client handler and removed socket from list
Dec 10 14:38:57 mod_bosh	debug	Have nothing to say, so leaving request unanswered for now
Dec 10 14:38:57 mod_bosh	debug	We have an open request, so sending on that
Dec 10 14:38:57 mod_bosh	debug	Request destroyed: table: 0x3eff540
Dec 10 14:38:57 bosha41318c8-513d-442b-a1c7-d61ebcb1ec69	debug	BOSH session marked as inactive (for 60s)
Dec 10 14:38:57 socket	debug	server.lua: closed client handler and removed socket from list
Dec 10 14:38:58 socket	debug	server.lua: accepted new client connection from 127.0.0.1:44936 to 5280
Dec 10 14:38:58 http.server	debug	Firing event: POST /http-bind
Dec 10 14:38:58 mod_bosh	debug	Handling new request table: 0x3fe0e60: <body rid="3397812833" sid="a41318c8-513d-442b-a1c7-d61ebcb1ec69" xmlns="http://jabber.org/protocol/httpbind"/>
----------
Dec 10 14:38:58 mod_bosh	debug	BOSH body open (sid: a41318c8-513d-442b-a1c7-d61ebcb1ec69)
Dec 10 14:38:58 bosha41318c8-513d-442b-a1c7-d61ebcb1ec69	debug	rid: 3397812833, sess: 3397812832, diff: 1
Dec 10 14:38:58 mod_bosh	debug	Session a41318c8-513d-442b-a1c7-d61ebcb1ec69 has 1 out of 1 requests open
Dec 10 14:38:58 mod_bosh	debug	and there are 0 things in the send_buffer:
Dec 10 14:38:58 mod_bosh	debug	Have nothing to say, so leaving request unanswered for now
Dec 10 14:38:58 socket	debug	server.lua: accepted new client connection from 127.0.0.1:44938 to 5280
Dec 10 14:38:58 http.server	debug	Firing event: POST /http-bind
Dec 10 14:38:58 mod_bosh	debug	Handling new request table: 0x4064290: <body rid="3397812834" sid="a41318c8-513d-442b-a1c7-d61ebcb1ec69" xmlns="http://jabber.org/protocol/httpbind"><iq id="5e9eef1c-b167-449f-a0a9-2eb47fc2cd37:sendIQ" to="gofast-dev-comm-gf4.ceo-vision.com" type="get" xmlns="jabber:client"><ping xmlns="urn:xmpp:ping"/></iq></body>
----------
Dec 10 14:38:58 mod_bosh	debug	BOSH body open (sid: a41318c8-513d-442b-a1c7-d61ebcb1ec69)
Dec 10 14:38:58 bosha41318c8-513d-442b-a1c7-d61ebcb1ec69	debug	rid: 3397812834, sess: 3397812833, diff: 1
Dec 10 14:38:58 mod_bosh	debug	BOSH stanza received: <iq id='5e9eef1c-b167-449f-a0a9-2eb47fc2cd37:sendIQ' type='get' to='gofast-dev-comm-gf4.ceo-vision.com'>

Dec 10 14:38:58 bosha41318c8-513d-442b-a1c7-d61ebcb1ec69	debug	Received[c2s]: <iq id='5e9eef1c-b167-449f-a0a9-2eb47fc2cd37:sendIQ' type='get' to='gofast-dev-comm-gf4.ceo-vision.com'>
Dec 10 14:38:58 mod_bosh	debug	We have an open request, so sending on that
Dec 10 14:38:58 mod_bosh	debug	Request destroyed: table: 0x3fe1780
Dec 10 14:38:58 socket	debug	server.lua: closed client handler and removed socket from list
Dec 10 14:38:58 mod_bosh	debug	Session a41318c8-513d-442b-a1c7-d61ebcb1ec69 has 1 out of 1 requests open
Dec 10 14:38:58 mod_bosh	debug	and there are 0 things in the send_buffer:
Dec 10 14:38:58 mod_bosh	debug	Have nothing to say, so leaving request unanswered for now
Dec 10 14:38:58 c2s3be6150	debug	Received[c2s]: <presence to='jvbbrewery@internal.auth.gofast-dev-comm-gf4.ceo-vision.com/videobridge'>
Dec 10 14:38:58 auth.gofast-dev-comm-gf4.ceo-vision.com:pep	debug	get_pep_service("videobridge")
Dec 10 14:38:58 internal.auth.gofast-dev-comm-gf4.ceo-vision.com:muc	debug	presence update for jvbbrewery@internal.auth.gofast-dev-comm-gf4.ceo-vision.com/videobridge from session videobridge@auth.gofast-dev-comm-gf4.ceo-vision.com/puI6emB6
Dec 10 14:38:58 c2s3be6150	debug	Sending[c2s]: <presence to='videobridge@auth.gofast-dev-comm-gf4.ceo-vision.com/puI6emB6' from='jvbbrewery@internal.auth.gofast-dev-comm-gf4.ceo-vision.com/videobridge'>

Regards,

Alexis

@avanhove Under latest iOS App, I can create 10 breakoutrooms successfully. Our log file seems like yours:

Dec 10 20:43:30 http.server debug Firing event: POST /http-bind
Dec 10 20:43:30 mod_bosh debug Handling new request table: 0x556fccf175d0: <body rid=“1085328086” sid=“39ee085f-e9c3-4b55-9f95-07eb51b283a6” xmlns=“http://jabber.org/protocol/httpbind”><breakout_rooms subject=“Breakout room #10” type=“features/breakout-rooms/add”/>

@saghul @avanhove I found something weird that explains our behaviour. Breakoutrooms works fine if using bosh (the iOS APP only uses always BOSH, isn’t it?) but no when websockets are enabled!!!.

If I disable the websocket part in our config.js, it works from every browser!!! :-?

bosh: ‘//XXXX/http-bind’, // FIXME: use xep-0156 for that
//websocket: ‘wss://XXXX/xmpp-websocket’,

This is the logged error, any ideas?

Dec 10 21:54:42 mod_websocket debug Websocket received frame: opcode=1, 157 bytes
Dec 10 21:54:42 c2s556fcbf4fdf0 debug Handled 197 incoming stanzas
Dec 10 21:54:42 c2s556fcbf4fdf0 debug Received[c2s]:
Dec 10 21:54:42 stanzarouter debug Unhandled c2s stanza: message; xmlns=jabber:client
Dec 10 21:54:42 c2s556fcbf4fdf0 debug Sending[c2s]: <message type=‘error’ from=‘breakout.XXXXX’ to=‘hteisqgjxcdsdp@tXXXXX/KQylyI4’>
Dec 10 21:54:42 c2s556fcbf4fdf0 debug Queuing <r> (in a moment) from outgoing_stanza_filter - #queue=1
Dec 10 21:54:42 c2s556fcbf4fdf0 debug Sending <r> (inside timer, before send) from outgoing_stanza_filter - #queue=1
Dec 10 21:54:42 c2s556fcbf4fdf0 debug Sending[c2s]: <r xmlns=‘urn:xmpp:sm:3’>

P.S: Our Websocket configuration has been tested and works fine with multiple users/sharing screen/videos… Even the browser built-in developer tools shows clearly how the tab is using WS…

Any suggestion will be highly appreciated.

THANK YOU for your patience :wink:

That’s odd, we use WS on meet.jit.si no problem. Yes, the mobile apps don’t use it yet.

@saghul THANK YOU for your time.

Just in case I miss something I just build today a new Jitsi instance in a clean VM in order to check if the button will work and provide you something you can check yourself:

References: Official install guide and Quick reference guide

Steps:

  1. New Jitsi installation in a "clean” VM using Ubuntu 20.04 and latest Jitsi stable release:
  • Add Jitsi stable repositories
  • apt-get -y install nginx jitsi-meet
  • /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh (create SSL certs for nginx)

breakoutrooms button works fine from any browser using bosch => default config.js

  1. Enabling websockets (reference Websocket Howto)
  • uncomment websocket access editing file /etc/jitsi/meet/XXXXX-config.js

    // Websocket URL
    websocket: 'wss://XXXX/xmpp-websocket’,

  • Add prosody support (/etc/prosody/conf.d/XXXXX.cfg.lua )

cross_domain_websocket = true;
consider_websocket_secure = true;

- And add in modules_enabled => "websocket”; “smacks”;

NO more changes, just default clean install that works using bosch:

Reboot system, just in case restarting services will not be enough :wink: and clear browser caches and cookies:

breakout button does not work anymore through any browser :-?

P.S: Of course, if only BOSH is used, the breakout button will work. wt…f
P.S2: FYI, all other functions (share screen/join more users…/even the “mute all button” in the same menu that “add breakout room”) works properly using WebSocket.
P.S3: using meet.jit.si the breakout button works fine like you said… but no in a clean install, AFAIK, as you can check/reproduce.

I really appreciate any help for this issue.

Websockets have been the default for new installations for a while now. You don’t have to configure anything. You can confirm websockets are working out of the box by checking the network tab on the browser.

@Freddie Thank you for your comments, but IMHO, maybe there are some issues about it (at least using the latest stable Jitsi repo for Ubuntu). I build today a new VM from scratch and fulfilled all the installation process.

(If it is possible for you/anyone, please validate my claims using a new installation)

AFAIK, If I am not mistaken, the auto installed generated YOUR_HOST-config.js has the websocket entry commented by default, thus browsers would use bosh always.

Enabling the websocket option was not enough after the default installation and I had to make some changes in the prosody configuration. If I looked properly, the “websocket” entry was not in the modules_enabled list.

Thank you for your time. Any help/enlightenment will be appreciated.

Again, websocket is enabled by default. In config.js, the flags commented out show the default behavior. So, if you don’t uncomment and change them, the default is what’s enforced. Your freshly installed Jitsi instance defaults to websocket, you don’t need to configure anything. And like I said earlier, if you’re in doubt, you can check the network tab when you run a meeting using the default configuration.

By default we configure and use websockets for the bridge connection.
The default install still uses bosh for the xmpp signalling.

@damencho Thank you for your time and explanation.

By default we configure and use websockets for the bridge connection.

@Freddie noticed that but I missed that point because I didn’t know the Jitsi internals and I assumed that the client selects only one protocol websocket/bosh for everything (client video/audio<=> videobridge and xmpp signaling).

So, a mixed configuration is handled by jitsi default setup, websocket for client video-audio<=> videobridge regardless it is enabled or not in the config.js and bosh for xmpp signaling.

The default install still uses bosh for the xmpp signalling.

When we use websocket for xmpp (wss enabled in config.js and configured in prosody) in a clean setup/installation as previously described, all other “buttons/actions” work fine (mute all, invite other people, search participants, chat, share screen…) but the “add breakout room” does not!

We saw these kind of messages when the “add breakout room” button is pressed in a browser (Android/iOS app works properly)

Dec 10 21:54:42 mod_websocket debug Websocket received frame: opcode=1, 157 bytes
Dec 10 21:54:42 c2s556fcbf4fdf0 debug Handled 197 incoming stanzas
Dec 10 21:54:42 c2s556fcbf4fdf0 debug Received[c2s]:
Dec 10 21:54:42 stanzarouter debug Unhandled c2s stanza: message; xmlns=jabber:client
Dec 10 21:54:42 c2s556fcbf4fdf0 debug Sending[c2s]: <message type=‘error’ from=‘breakout.XXXXX’ to=‘hteisqgjxcdsdp@tXXXXX/KQylyI4’>
Dec 10 21:54:42 c2s556fcbf4fdf0 debug Queuing (in a moment) from outgoing_stanza_filter - #queue=1

Do you think I miss something in the xmpp/wss configuration? It is “tricky” because all other options/buttons are fully functional…

ALL: Can anyone reproduce this behaviour in a clean installation?

P.S: Checking our wss clean setup through https://HOST_DOMAIN/xmpp-websocket, says it is fine:

It works! Now point your WebSocket client to this URL to connect to Prosody.

Thank you all for your patience :slight_smile:

I think you are missing the breakout component in prosody config

Perhaps I should ask: what exactly is your end goal here? Is it that you want to use websocket for xmpp signaling for some specific reason? Apparently, I kept missing your reference to xmpp because the OP was talking strictly about Breakout rooms with a default config.

If you’re just looking to enable Breakout rooms, again, the default config (websocket bridge, bosh for xmpp) works out of the box. You don’t need to make any changes.

@damencho In a “clean” Jitsi install with the WS-XMPP enabled as described above, the prosody XXXX.cfg.lua has:

modules_enabled = {
“bosh”;
“websocket”;
“smacks”;
“muc_breakout_rooms”;

}
c2s_require_encryption = false
lobby_muc = “lobby.test.XXXXX”
breakout_rooms_muc = “breakout.test.XXXXXX”
main_muc = “conference.test.XXXXX”

Component “breakout.test.XXXXXX” “muc”
restrict_room_creation = true
storage = “memory”
modules_enabled = {
“muc_meeting_id”;
“muc_domain_mapper”;
–“token_verification”;
“muc_rate_limit”;
}
admins = { “focus@auth.test.XXXX” }
muc_room_locking = false
muc_room_default_public_jids = true

Did I miss something?

Thank you very much!

Apparently, I kept missing your reference to xmpp because the OP was talking strictly about Breakout rooms with a default config.

@Freddie Our Jitsi instance, has been using the WS-XMPP configuration successfully over the months, but suddenly after the latest Jitsi update with the breakout-rooms feature, we discover that we cannot use the new “add breakout-room button” from any browser and we wonder why if all other functionality/buttons work flawlessly. So our point is to know why and discover/correct any misconfiguration.

This is why we made a “clean” Jitsi install, to ensure it was not “our” customizations.

On the other hand, if this behaviour is not “mine” and happens using an up-to-date clean Jitsi install, reporting the bug in order to improve this wonderful project.

if any of you (@Freddie/@damencho …) decide this is a particular issue and does not happen in a clean installation (so it is not a common issue for all Jitsi users), I will respect and follow your advice. I cannot claim to know better Jitsi than you :slight_smile:

@ All: Thank you for your time and patience :innocent:

Ah, okay… I think I understand your angle better now.
There’s been some conversation around moving xmpp to websocket as well and work is actively being done on that, if I’m not mistaken. However, because that’s not the default currently, I daresay it’s hard to tell what could go wrong or what bugs could arise with the switch. Perhaps the issue you’re experiencing with Breakout Rooms is one of such. For now, default installations configure the environment to use websocket for bridges and bosh for xmpp. And this works well for almost all use cases. I imagine when work is completed on using websocket for xmpp, installations will default to that as well.

@Freddie Our concern is that meet.jit.si has the WS-XMPP enabled in the config.js (like we have successfully all this time :wink: ) and the “add new breakout room” button works from any browser.

We can guess that meet.jit.si has a tuned code, so we don’t expect the same behaviour/performance always, but we wondered if it was our/a misconfiguration of the latest stable release.

if @damencho/anyone could not find any clue or it is not “commonly” reproducible we will just disable the WS-XMPP in our config.js. Anyway, suggestions are always welcome.

THANK YOU for your explanation and time.

When you did a clean install were breakout rooms working without touching anything?

I just did a clean install on a new VM and the only problem I saw is that I installed jdk-11 in advance and needed to restart jvb after the apt install jitsi-meet command, and breakout was working without a problem.