Jigasi with Lobby, Second Caller doesn't knock

I noticed that with the lobby feature the first phone caller into the bridge does knock and can be let in by the Moderator but every caller after that is allowed in without knocking. Tested on jigasi 1.1-134-gcb27476-1 and 1.1-137-g3294cc2-1. Anyone know if there is a way to resolve this? Using Asterisk with Jigasi connected to meet server running 2.0.5041-1 in a secured domain.

Hum, interesting observation. I will check it, I found a bug that may have been affecting that … but it is fixed in 1.1-137-g3294cc2.
Are you sure you are reproducing it with that?

Can you share your jigasi config after masking sensitive data.

I think I see the problem, but it would happen only if jigasi is authenticated using https://github.com/jitsi/jigasi/blob/master/jigasi-home/sip-communicator.properties#L92

I am authenticating with that method. What should I be using instead?

Is there a reason for the authentication? You should not authenticate.

This is how lobby works, if I’m user with username: a@domain.com and I authenticate and I’m allowed to join the room once, if I reload and have the same username I’m already allowed to join the room.

We are using secure domain so I followed the guide here: https://jitsi.github.io/handbook/docs/devops-guide/secure-domain which says to add the authentication parameters. We are now using JWT to authenticate so I am guessing I need to update the configuration to use JWT instead of user/pass but I am not sure how to go about doing that. As in what fields in the jigasi config need to be updated to utilize jwt tokens.

You need to enable it to connect through bosh and add the jwt in the bosh connection string.

Any pointers on doing that?

Adding &token=MyJWTToken to the end of org.jitsi.jigasi.xmpp.acc.BOSH_URL_PATTERN results in the below errors. What else needs to be configured to allow Jigasi to use BOSH? All of the forum post I can find are unresolved.

2020-11-02 17:58:11.827 SEVERE: [12] org.jitsi.impl.neomedia.device.DeviceConfiguration.log() Failed to register custom Renderer org.jitsi.impl.neomedia.jmfext.media.renderer.audio.PulseAudioRenderer with JMF.
2020-11-02 17:58:26.185 SEVERE: [59] impl.protocol.jabber.ProtocolProviderServiceJabberImpl.connectAndLogin().1003 Failed to connect to XMPP service
2020-11-02 17:58:26.188 SEVERE: [59] org.jitsi.jigasi.JvbConference.registrationStateChanged().645 [ctx=160433990605971695133] XMPP Connection failed.

Do you have a complete stack trace.

Here is the jigasi and prosody logs as well as the jigasi config from an attempted call. I keep getting no SASL errors but have confirmed that net.java.sip.communicator.service.gui.ALWAYS_TRUST_MODE_ENABLED=true is set.

sip-communicator.properties.txt (9.4 KB)
jigasi.log (41.9 KB) prosody.log (37.2 KB)

Do you see any errors in the webserver?

No sir. A couple warnings that appear irrelevant but no errors.

Are you using a self-signed certificate on your deployment?

No sir. Using Let’s Encrypt.

I’ve the same problem in a similar scenario (secure domain + lobby room + jigasi authenticated to handle only dial-in call). The only difference is that we check username/password credential via custom_http module.
@damencho, in a secure domain scenario, is there a configuration tip in jigasi/prosody without authentication or with a different form of it that we can test to solve the second caller’s knock problem?

I think the only option is to create a separate virtual host that will be used only for jigasi, use tokens for authentication there, and enable bosh (this will not work with slef-signed cert) passing the token in the bosh URL.

@damencho, thanks a lot for your support! I’ll try to implement your solution.

Do you have an example of doing this? What should the virtual host look like and what should the jigasi config look like by comparison?

In prosody:

VirtualHost "jigasi.jitmeet.example.com"
        authentication = "token"

In jigasi:


Not tested, so I’m not 100% sure about it. I can give it a try these days and see whether something more is needed.