We provide the possibility to schedule meetings, when the meeting is scheduled the conference mapper is updated with the appropriate details allowing people to dial-in to the conference.
We also use JWT authentication, which is required to actually start the meeting as the organizer.
SIP dial-in works fine, we use Asterisk as IVR and a self hosted conference mapper that is queried by Asterisk to find the correct conference ID.
What happens when the person dialling in to the conference is the first one there, the phone rings 3 times, it connects and then there is silence. Under the hood Jigasi has allowed the caller into the conference, but because there is nobody else in the meeting the person dialling in does not hear anything. The flow appears to be the same (from SIP debug) as when someone dials in to a conference that is already started.
Once the organizer has started the meeting, the person dialling in is automatically added to the conference.
What we would like to do is somehow let the person dialling in know that he is the first one in the conference and has to wait to be “let in”. The same applies to when the lobby is enabled, the person dialling in needs to be notified when he has to wait before being allowed into the conference.
The way I see this to be solved is in 2 ways:
- Let Jigasi handle the “waiting to be allowed in” by either playing a message / waiting music / notification until the conference is “opened”.
- Let Asterisk handle the waiting by providing an endpoint that can be queried to see if the number of participants > 0.
We are looking at modifying mod_muc_size to look at the second scenario, but am posting here to see if there are maybe other solutions as preferably this should handled by Jitsi without external dependencies like Asterisk.
We are using Jigasi 1.1-151-gea12fce-1, is there a timeline when the lobby feature will be merged into the Jigasi stable branch?