Does jitsi (jigasi) support ICE in SIP?

Hi all,

I remember discussing this topic some years ago when jitsi (desktop at the time) only had support for ICE in xmpp but not in SIP. Not sure how it evolved over the years.

I’m having some occasional 1 way audio problems when trying to dial out through jitsi-meet (using jigasi with an account registered on the open source flexisip SIP server), and I believe it’s due to ICE not working.

What’s the current status of ICE in jigasi? How can I enable it?


ICE and sip is still not implemented, so there is no ICE in jigasi.

Oh ok. I figured it would have been implemented by now.

That would explain 1 way audio then.

Any ideas as to how to overcome this since most VoIP clients are sitting behind restrictive carrier grade NATs and therefore getting 2 way audio is a question of luck. More often than not we get only 1 way audio.


I’m a little bit confused here, are you talking about jigasi or Jitsi Desktop, as you mention


Jigasi is a server component and once it works with 2 way audio with your sip server, everything is fine and should not change.

Sorry I wasn’t very clear.

Here’s my setup in a nutshell.

Running jitsi-meet with jigasi on same host.
Jigasi is registered on my SIP server (flexisip) on another host

The issue is that when I try to make outbound SIP calls through jigasi I often get 1 way audio.

Since the sip device receiving the call is running linphone we can see there in the call info pane that there’s no ICE negotiation when the call comes from the jigasi account. If the SIP calls come from other linphone devices then ICE works as expected and there’s always 2 way audio.

The reason I mentioned Jitsi desktop is because I recall something along the lines of running that same SIP account through desktop first in order to get the correct to insert in jigasi.

I hope my confusing explanation makes some sense.


Is latching enabled on your sip server?

If by latching you mean media relay, then yes.

The sip server is flexisip and I have the default setting for force-relay-for-non-ice-targets set to True so media should always flow 2 ways.

Means that the server waits for the client to send media in order to start sending media to it, so it can reuse the port and address it sees for the received media.

Probably this force relay is the same, I don’t know.