Jigasi no dial in audio if other participants muted on connection (already upped hole punches)

We’ve got an install of the latest jigasi / meet / jvb2. If a caller dials in to a conference in which all of the
other participants are muted, the dial in does not send any audio until one person unmutes.

We’ve tried upping the hole punches, we’ve moved our networking around to avoid NAT entirely, we’ve tried sending dialtones from the meet/api on participant join to try to simulate some activity. Does anyone have any pointers on what else to try?

Perhaps related, perhaps not: If two dial in users join a conference by themselves, they get no audio. If meet users join, they can’t talk to the dial in users (regardless of mute status).

Thanks for any help.

I suspect your sip side is not doing latching and expects correct address and port in the ssrc.
You need to enable latching for those accounts. On asterisk you need nat=force_rport,comedia.

Thanks for the quick response Damian,

We’re using pjsip. Our equivalent settings are:

rtp_symmetric=yes
rewrite_contact=yes
force_rport=yes

We’ve tried every variation of these settings and direct_media as well. Is pjsip known to handle the hole punching for latching? We can try switching to chan_sip, but were hoping to avoid it as it is legacy at this point.

Regards,
Michael

Yeah pjsip should support that …

Personally I have not tested it with pjsip. We are using voximplant and I know they stack is based on pj stuff … but not sure at all whether that part is the same.
But when we started using them we needed to modify the hole punch packets to match payload type as it was not working … it is possible something similar is going on … the pj stack is dropping the hole punch packets for unknown reason … if you can turn on some debugging on the sip side and see is that the case and whether there is a hint what’s wrong we can try fixing it together.

Hey Damian,
This is what we’re seeing when we debug on asterisk:

[2020-07-16 13:52:12] DEBUG[20783][C-0000001c] res_rtp_asterisk.c: Got RTCP report of 12 bytes from 34.201.9.165:10002
[2020-07-16 13:52:12] DEBUG[20783][C-0000001c] res_rtp_asterisk.c: 0x7f93240286e0 – RTCP from 34.201.9.165:10002: Failed first packet validity check

But these are rtcp … and hole punch should be only rtp …

My mistake, here’s the continuing sequence:

[2020-07-16 16:42:52] DEBUG[30688][C-0000001d] res_rtp_asterisk.c: Got RTCP report of 12 bytes from 34.201.9.165:10005
[2020-07-16 16:42:52] DEBUG[30688][C-0000001d] res_rtp_asterisk.c: 0x7f9324016160 – RTCP from 34.201.9.165:10005: Failed first packet validity check
[2020-07-16 16:42:52] DEBUG[30688][C-0000001d] res_rtp_asterisk.c: 0x7f9324016160 – Received RTP packet from 34.201.9.165:10004, dropping due to strict RTP protection. Qualifying new stream.
[2020-07-16 16:42:52] DEBUG[30688][C-0000001d] res_rtp_asterisk.c: 0x7f9324016160 – Received RTP packet from 34.201.9.165:10004, dropping due to strict RTP protection. Will switch to it in 3 packets.
(repeats 18 times, i send 20 punches)

Turning off strict solves the problem. So it’s something to do with the route those packets are taking? The pbx is behind a NAT, and Jigasi is behind a separate one at AWS, but I’m avoiding them using:

net.java.sip.communicator.impl.protocol.sip.acc1403273890647.ACCOUNT_UID=SIP:665@172.31.92.41
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.SERVER_ADDRESS=172.31.92.41
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.USER_ID=665@172.31.92.41

Further up in asterisk, I’ve got this, which matches with the expected ips.

[2020-07-16 16:42:52] DEBUG[27081] res_rtp_asterisk.c: Setup RTCP on RTP instance ‘0x7f9324011150’
[2020-07-16 16:42:52] DEBUG[27081] acl.c: For destination ‘172.31.76.166’, our source address is ‘172.31.92.41’.

So I’m missing something that is accidentally telling Jigasi to hit the pbx’s external NAT address in that phase?

Can you send me a pcap from jigasi log folder.
That is enabled with https://github.com/jitsi/jigasi/blob/6df3db2c63ccae1ac89d0591e6fe9005603c8a62/jigasi-home/sip-communicator.properties#L18

I’ll see if I can get approval to post it or send it to you directly.

Basic rundown of what I see in wireshark: all udp and sip messages are going from jigasi <-> pbx via the 172 addresses. The rtp and rtcp messages are going to and from the nat addresses.

The first RTCP message is jigasi 172 -> pbx nat.
Then I ummute there are RTPs jigasi 172 -> pbx nat and pbx nat -> 182 jigasi.
then rtcp pbx nat -> jigasi 172.

If I get approved to post the pcap, I’ll put it up.