So I have some questions about the Jigasi and how the SIP calls work. What would happen if we initialize multiple calls in one meeting room? How are the audios from multiple callees handled?
We have installed jigasi successfully but when in a meeting room, if the owner makes multiple calls out through jigasi, the audios are unbearable. I’m a bit lost & don’t know which component should be edited to solve this issue. Hope you guys can help.
Nope, it needs support for it on the sip side. I was asking cause enabling it, and not supported on the server will lead to garbled sound.
So you say that dialling out one participant is fine, but dialling out twice in the same conference is a problem? What happen if in two separate conferences do one dial out, do repro it, that way?
I have some more questions on this though. Currently, we have 1 instance of Jigasi running. Which mean that I can only register with 1 SIP account (or limited accounts) for the whole jitsi meeting system.
Is it possible for us to register multiple SIP accounts (by multiple I mean that one conference owner will have their own SIP account which means the number of SIP accounts would be significant)?
Is there a way for us to edit jigasi code in a way that it could handle multiple accounts in one instance and also register the SIP account when needed (when a call is made instead of when jigasi instance starts)?
We using a reservation system on Jicofo and cache the room name (id) to our db when it started. We wrap it with an API, so now if jigasi give it the room id, it would return the company id / owner sip account info.
I still stuck at when jigasi send the dial message to our sip server. Let’s say company A have an address of: companyA.sip.ourproduct.com. But company B have an address of companyB.sip.ourproduct.com. So when a dial event happend inside a conference, shouldn’t jigasi choose which address/account to send the message to ?
No jigasi uses just one sip user account to connect to sip pbx/service, where all the logic about IVR (incoming), or outgoing calls happens. Jigasi is just a simple component that connects xmpp/jingle to sip calls, without any custom or complex logic. The business logic is outside of it.
So the scheme you want is very easily achievable without any component code changes. So whenever there is an outgoing call the PBX, the PBX takes the sip header which is the room name for that call, queries your service to return the outgoing sip account to be used for that room name and uses that sip account.
So in the pbx you will have one user account for jigasi and several for all your sip trunks/accounts …
So we had successfully install & use jigasi to make calls. But I ran in the a problem when all users inside of a conference mute their mic (no active audio source in a room) make a outgoing call. The receipient’s voice can’t be heard until one of the users turn on their mic. Is this by design or I did something wrong?
This sounds like a problem with hole punch packets. Many sip servers do nat traversal by waiting the client to start sending audio (latching) in order to avoid this we send 3 dummy hole punch rtp packets in the beginning in order to force the sip side to start sending media, we haven’t seen a problem with this.
Maybe you can try force sending more hole punch packets by using this config property: net.java.sip.communicator.impl.protocol.HOLE_PUNCH_PKT_COUNT=10, can you try this and report is there any changer, there should be a log indicating this: Send NAT hole punch packets do you see this in jigasi logs?
There is no error expected … there can be two cases your sip side does not respect those packets we initially send or the 3 packets we send does not reach the sip side …
By increasing the number you will exclude the second case, if that is not the case than, not sure what we can do …
Do you know or control the sip side?
Last week I had added another logic like hole punch packets but it is not sending RTP with the same payload as the media, but of type 13, comfort noise, but there is no easy way to enable that in your case at the moment other than editing the code and recompiling …
I just increase the hole punch count to 10 as instructed and it seems to be okay for now. I’ll try messing around with the hole punch count value to see if it is what causing the issue.
Thank for your support