No focus/video unless using nicknames

Hi,

In order for the focus user to setup the XMPP room successfully and sit in it to enable video/audio, we need to use “Enable Nicknames”. If we don’t, the focus user does not setup the room correctly and meeting members do not have a focus user in the room to pass video/audio. Is this expected behavior? Does the extra pause caused by the nickname pop up window give the focus user more time to set things up properly? Does the focus user need to join first before the ofmeet client user?

I’m using ofmeet 0.3.23 but this issue was also present in 0.3.9. I have set the Focus JID to use “focus@domain” even though that user does not exist in LDAP - I have disabled the security on the user. I tried changing the user to an admin but it didn’t seem to help.

Without nicknames, jitsi tries a couple of times to join the channel but gives up after a couple of efforts.

Successful with nicknames:

2016.11.01 11:59:26 org.jitsi.jicofo.openfire.FocusComponent - Focus request for room: dairetest17@conference.dneg.com

2016.11.01 11:59:26 XMPPConnection - OpenfirePacketReader init

2016.11.01 11:59:26 XMPPConnection - OpenfirePacketReader startup

2016.11.01 11:59:26 XMPPConnection - OpenfirePacketWriter startKeepAliveProcess

2016.11.01 11:59:26 XMPPConnection - XMPPConnection login

I can see and hear the other users and the focus user also appears as a member on the filmstrip along the bottom.

Unsuccessful without nicknames:

2016.11.01 12:04:44 org.jitsi.jicofo.openfire.FocusComponent - Focus request for room: dairetest18@conference.dneg.com

2016.11.01 12:04:44 XMPPConnection - OpenfirePacketReader init

2016.11.01 12:04:44 XMPPConnection - OpenfirePacketReader startup

2016.11.01 12:04:44 XMPPConnection - OpenfirePacketWriter startKeepAliveProcess

2016.11.01 12:04:44 XMPPConnection - XMPPConnection login

2016.11.01 12:04:44 XMPPConnection - OpenfirePacketReader shutdown

2016.11.01 12:04:44 XMPPConnection - OpenfirePacketWriter cleanup

2016.11.01 12:04:44 XMPPConnection - OpenfirePacketReader cleanup

2016.11.01 12:04:44 XMPPConnection - SmackConnection - close

2016.11.01 12:04:44 XMPPConnection - OpenfirePacketReader shutdown

2016.11.01 12:04:44 XMPPConnection - OpenfirePacketReader cleanup

2016.11.01 12:04:45 org.jivesoftware.openfire.muc.spi.MultiUserChatServiceImpl - removing chat room:dairetest18|org.jivesoftware.openfire.muc.spi.LocalMUCRoom

2016.11.01 12:04:45 org.jitsi.videobridge.openfire.Config - Config servlet

2016.11.01 12:04:45 org.jitsi.jicofo.openfire.FocusComponent - handleIQSet

2016.11.01 12:04:45 org.jitsi.jicofo.openfire.FocusComponent - Focus request for room: dairetest18@conference.dneg.com

2016.11.01 12:04:45 XMPPConnection - OpenfirePacketReader init

2016.11.01 12:04:45 XMPPConnection - OpenfirePacketReader startup

2016.11.01 12:04:45 XMPPConnection - OpenfirePacketWriter startKeepAliveProcess

2016.11.01 12:04:45 XMPPConnection - XMPPConnection login

2016.11.01 12:04:45 org.jivesoftware.openfire.muc.spi.MultiUserChatServiceImpl - removing chat room:dairetest18|org.jivesoftware.openfire.muc.spi.LocalMUCRoom

2016.11.01 12:04:45 org.jitsi.videobridge.openfire.Config - Config servlet

2016.11.01 12:04:45 org.jitsi.jicofo.openfire.FocusComponent - handleIQSet

2016.11.01 12:04:45 org.jitsi.jicofo.openfire.FocusComponent - Focus request for room: dairetest18@conference.dneg.com

After this I can only see the user members of the room along the filmstrip and there is no video/audio - only the gravatars. The focus user is not present in the room.

1 Like

In order for the focus user to setup the XMPP room successfully and sit in it to enable video/audio, we need to use “Enable Nicknames”. If we don’t, the focus user does not setup the room correctly and meeting members do not have a focus user in the room to pass video/audio. Is this expected behavior? Does the extra pause caused by the nickname pop up window give the focus user more time to set things up properly? Does the focus user need to join first before the ofmeet client user?

I have not used that feature in a long time and cannot confirm if it even works anymore. It was a carry over from the original web client. Thanks for confirming it still works

The focus user MUST have permissions to join every meeting and yes, before the client users join. The way to do that is to add the focus user to the list of room administrators for the conference service. That way, the focus user does not show up on the UI. The plugin normally does it automatically, but fails with LDAP because the openfire user datastore is read only.

1 Like

Okay, thanks for the reply. So the focus user was an admin for the conference service but was not a user in LDAP. We have completely open permissions on room creation so any user can join any meeting. We also don’t check passwords so I think I just assumed that the LDAP entry wasn’t really needed.

I had also tried changing the focus user to be a real user in LDAP but for some reason it kept reverting to trying to use the focus user. Finally, I have just added the focus user to LDAP and now suddenly everything is working properly. The focus user correctly sets up the room with video regardless of the nickname setting and is also being removed/hidden from the filmstrip.

I guess I just didn’t realise the importance of having the focus user in LDAP because it was “kind of” working!

Thanks for encouraging me to actually do it properly…

Dele

Could you Clarify giving the focus user permissions to join every meeting? I have an LDAP openfire test server, and having this issue currently. Are you talking about the room administrators in LDAP or in Openfire?

Yes, the room administrators for the defauit “Conference” room service