SIP Trunk erratic inbound behavior

Hello all. This one has me puzzled. I would say around 2 weeks ago I started getting complaints trickling in about inbound calls on a few of my hosted FPBX instances dropping audio almost instantly on inbound calls. These systems have been up for years now and the only thing that changes is the auto system updates weekly. Specs on system…

PBX Version:
PBX Distro: 12.7.8-2203-2.sng7
Asterisk Version: 18.14.0

So after testing and wiresharking it seems to be an that is affecting inbound DIDs when its set to ring groups or direct extension inbound. If you are using IVR its not an issue. Its also not there when you call extension to extension or dial anything outbound. It also doesn’t happen on every call but I would say about 40%. When it happens you pick up the call, hear a short burst then nothing. The call doesn’t drop and the SIP signaling seems to act normal meaning when you hang up the call is gone but it shows you connected the whole time. I did hours of testing and learned that if I add a 2 second silent announcement before initiating the RG the calls stopped failing. I attached a packet capture from the FPBX interface. If you all could take a look at it and offer suggestions that would be great. Thanks.

Is the PBX natted or do you have a public IP?

Public IP and using the built in Firewall.

I also rebooted the system and it didn’t change.

It looks like it trys the LAN IP of the phone right before the audio fails? But then otherwise sends it to the correct WAN IP after…

Have you told Asterisk the public IP?

After packet 2873, RTP from the trunk stopped coming to Asterisk, though RTP from the extension kept being properly relayed to the trunk. There is no obviously related SIP or other traffic near that time.

Possibilities include RTP being blocked by a firewall or other network element (a trace at the provider would show that they were still sending it), the provider stopped sending because they detected an error (their logs should show that), or they started sending to a different address or port as a result of bogus RTP they received.

This may or may not be related, but I noticed that you are sending progress in-band. See whether turning that off makes a difference.

I assume that you routed to ext. 1000 for testing, but the production system has a ring group. A possible workaround is to set Play Music On Hold for the RG, using a media file that is just ringback tone.

Affirm. System has been up for 3 years and rarely has config changes or issues. It’s also happening to 3 of my VPSs so there are 2 common things. SIP providers and System/Module/Asterisk versions.

Thanks for your time Stewart. I will try your inband suggestion right now and an announcement ahead of the RGs has help reduce the failures. I have been testing a lot more this morning and one thing I noticed is that it seems to be failing on certain DID’s and others not as all even though I’m calling through the same VPS to the same extension which makes me thing provider now.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.