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?
Lobby is already merged into master. We will update jigasi on next stable release.
There are already notifications played to users when they join and when someone else joins. But if you need more, the query you are about to do sounds reasonable.
You can update to latest jigasi from you unstable and try it out.
thanks, but we are already on the latest unstable.
the challenge here is that there is nobody in the conference yet, except for the person that is dailling in - there are no notifications or sounds to hear then.
Aaa there are sounds but those work only in translator mode when opus is used … yeah.
are you referring to these sounds: https://github.com/jitsi/jigasi/tree/master/src/main/resources/sounds?
Can you maybe elaborate on what “translator mode” implies?
I think the main issue that @echristiaans tries to explain is that a participant dialing in by phone is not informed that a conference is not yet started by the moderator.
When the participant dials in by phone, while the conference has not started yet the participant, will hear three “beeps” as if it is trying to connect and it is then completely silent. When the moderator starts the meeting after authentication the user is then added to the conference.
The same thing when a participant dialled in by phone is placed in the lobby. He/she will not receive a message that “you have to wait until you are allowed to enter”.
Summarized: is it possible to notify a user that they have been placed in a queue, either in the lobby or waiting until the meeting starts?
There would/should be three flows here:
Conference has started, lobby disabled; Participant dialed in by phone is immediately added in the conference
Conference has started, lobby enabled: Participant should hear something that he is waiting to be allowed in the conference. perhaps looping this message every 10 sec or with “beeps”.
Conference has not started: Participant should hear that the conference was not started yet and needs to wait again perhaps looping this message every 10 sec or with “beeps”.
So the lobby part is already implemented, but for now works only with translator mode. And some of the others too, maybe be without the loop.
The translator mode is where jigasi is like the bridge, does not do any encoding, decoding and mixing of streams but just forwards them to the server - act as a translator. The sip side need to support multi streaming and mixing to process it. This is a way to offload jigasi.
The sound notifications need to be tested in non translator mode and if needed to be improved. Any help is welcome …
@damencho are there plans to implement this in non-translator mode anytime soon? Also willing to help if I can.
Nope, we don’t have this in our roadmap. Any PRs are welcome.