Hello, I have a strange problem I’ve been unable to solve for a few days now. The setup is I’m running the latest version of Ubuntu, installed Asterisk with the package manager, so it’s version 20.6 I believe. I have several soft phones that can dial into the conference bridge and work perfectly. However, I’m running into issue with hardware phones. The phones I’m using are Grandstream Phones, and a Comlabs EMPhone. These connect fine to the conference bridge, but the people will stop being able to hear the hardware phones. They are still connected, and when I do a packet capture, they are sending RTP audio to Asterisk. Problem is, Asterisk isn’t mixing that audio in and sending it out. It’s intermittent too. Sometimes audio will go out, sometimes it will come back. I haven’t been able to explain it, so any advice would be usefule.
Does it show in “rtp set debug on”?
Here is the output:
Got RTP packet from 71.42.32.42:40002 (type 00, seq 059415, ts 467828320, len 000160)
Got RTP packet from 10.10.7.93:50040 (type 00, seq 050068, ts 467953007, len 000160)
Got RTP packet from 71.42.32.42:5008 (type 00, seq 062266, ts 470222880, len 000160)
Sent RTP packet to 71.42.32.42:5006 (type 00, seq 063266, ts 467493280, len 000160)
Sent RTP packet to 71.42.32.42:5008 (type 00, seq 045979, ts 467437280, len 000160)
Sent RTP packet to 71.42.32.42:40002 (type 00, seq 063224, ts 467302080, len 000160)
Sent RTP packet to 10.10.7.69:4000 (type 00, seq 026398, ts 1646400, len 000170)
Got RTP packet from 71.42.32.42:5006 (type 00, seq 062647, ts 471193760, len 000160)
Sent RTP packet to 10.10.7.93:50040 (type 00, seq 045175, ts 467911360, len 000160)
Got RTP packet from 10.10.7.69:4000 (type 00, seq 026297, ts 1646560, len 000170)
Got RTP packet from 10.10.7.93:50040 (type 00, seq 050069, ts 467953167, len 000160)
Got RTP packet from 71.42.32.42:5008 (type 00, seq 062267, ts 470223040, len 000160)
Sent RTP packet to 10.10.7.69:4000 (type 00, seq 026399, ts 1646560, len 000170)
Sent RTP packet to 71.42.32.42:40002 (type 00, seq 063225, ts 467302240, len 000160)
Sent RTP packet to 71.42.32.42:5008 (type 00, seq 045980, ts 467437440, len 000160)
Sent RTP packet to 71.42.32.42:5006 (type 00, seq 063267, ts 467493440, len 000160)
Got RTP packet from 71.42.32.42:5006 (type 00, seq 062648, ts 471193920, len 000160)
Got RTP packet from 71.42.32.42:40002 (type 00, seq 059416, ts 467828480, len 000160)
Sent RTP packet to 10.10.7.93:50040 (type 00, seq 045176, ts 467911520, len 000160)
Got RTP packet from 10.10.7.69:4000 (type 00, seq 026298, ts 1646720, len 000170)
Got RTP packet from 10.10.7.93:50040 (type 00, seq 050070, ts 467953327, len 000160)
Got RTP packet from 71.42.32.42:5008 (type 00, seq 062268, ts 470223200, len 000160)
Sent RTP packet to 71.42.32.42:5006 (type 00, seq 063268, ts 467493600, len 000160)
Sent RTP packet to 71.42.32.42:5008 (type 00, seq 045981, ts 467437600, len 000160)
Sent RTP packet to 10.10.7.69:4000 (type 00, seq 026400, ts 1646720, len 000170)
Sent RTP packet to 71.42.32.42:40002 (type 00, seq 063226, ts 467302400, len 000160)
Got RTP packet from 71.42.32.42:5006 (type 00, seq 062649, ts 471194080, len 000160)
Got RTP packet from 71.42.32.42:40002 (type 00, seq 059417, ts 467828640, len 000160)
Got RTP packet from 71.42.32.42:40002 (type 00, seq 059418, ts 467828800, len 000160)
Sent RTP packet to 10.10.7.93:50040 (type 00, seq 045177, ts 467911680, len 000160)
Got RTP packet from 10.10.7.69:4000 (type 00, seq 026299, ts 1646880, len 000170)
Got RTP packet from 10.10.7.93:50040 (type 00, seq 050071, ts 467953487, len 000160)
Got RTP packet from 71.42.32.42:5008 (type 00, seq 062269, ts 470223360, len 000160)
Sent RTP packet to 10.10.7.69:4000 (type 00, seq 026401, ts 1646880, len 000170)
Sent RTP packet to 71.42.32.42:5008 (type 00, seq 045982, ts 467437760, len 000160)
Sent RTP packet to 71.42.32.42:5006 (type 00, seq 063269, ts 467493760, len 000160)
Sent RTP packet to 71.42.32.42:40002 (type 00, seq 063227, ts 467302560, len 000160)
The IP address 71.42.32.42 is the external address that three phones are sitting on (same thing does happen but with less frequency to phones on our interal side). The hardware phones are set to port 5006 and 5008.
So… do the expected packets show in there when the issue occurs? According to that output packets are coming in, packets are going out.
It’s impossible to tell. There is no timestamp on the dump in the console. However, when I do a TCP dump and load the packets in wireshark, the audio is there despite the fact that it’s not coming through to the other endpoints on the network.
Wireshark shows packets BEFORE any firewall rules. If they appear in wireshark but not in Asterisk, then that points to firewall rules - such as not allowing the full UDP port range through.
No, that doesn’t make any sense. We have many Asterisk servers on our network with the exact same ruleset. But it wouldn’t account for the intermittent behavior.
Ok, then you could try to get a debug log while the issue is occurring and see if anything of note comes up - but that’s all I’ve got for you. Noone else is reporting this issue currently, and past weird intermittent audio issues ended up being firewall in general.
Actually, you mentioned a package manager install - I do remember from Debian that they were including an outside patch which caused audio to stop working. Maybe the Ubuntu package has the same thing.
That could be my issue. The packet capture isn’t happening before the firewall rules are applied, the TCP dump is taking place on the server itself. So we know for a fact the packets are coming. The problem with using latest versions from source is I lose the ability to use the old SIP configuration. We have a lot of custom software that depends on that protocol.
Asterisk 20, which includes chan_sip, continues to be supported for bug fixes until October of next year[1].
I just installed Asterisk version 22 from source. Unfortunately it doesn’t include a chan_sip module, but oddly enough all the problems seem to have vanished. I have all phones connected to the conference and audio is loud and clear. Is there a third party chan_sip module available if I need to setup old sip?
I don’t know the URL for any third party. You could have also just installed Asterisk 20.
If it comes down to it, I’ll do that. But this seems to be cleared up after getting away from the Ubuntu managed version.
Thank you for your help!
tcpdump captures packets before the Linux firewall.
On Thursday 24 April 2025 at 17:11:47, david551 via Asterisk Community wrote:
tcpdump captures packets before the Linux firewall.
Or, to phrase it another way, packets are captured on the raw device, before
firewall rules decide whether to allow them through to applications or not.
Antony.
–
Wanted: telepath. You know where to apply.