Some outgoing calls drop at the 15 minute mark... Logging question!

[jcayer]

Hi everyone,

Like the title says: I'm having issues with some ONLY outgoing calls dropping right past the 15-minute mark.

System details:

Linux V18 U4 (Build 965) hosted at Vultr
Local SBC V18.1.36
Grandstream GXP-2170 handsets with approved firmware and the default template

Additional details on what's happening: The customer says that it's random which calls die, but at least once the person they called heard a "high pitched noise" and then the call was lost. I have documented a list of numbers that they have called and the call was lost. These have all been outgoing calls and to a mix of cell phones and land lines. I'm at a loss as we support 10 different clients on the same system, host and hardware and haven't had this issue anywhere else. Their Internet connection seems to be good and the fact that it's only after 15 minutes (when the majority of calls are shorter) would seem to indicate the Internet isn't a problem.

I had asked about this in the past and was directed to turn logging onto "Verbose, save 1 day" and did so.

Call dropped again in the exact same manner today, so I downloaded the support info package and started to look over the logs. I am failing at even finding the issue. (I'm also not sure WHICH log file would be my best bet) Does anyone have any suggestions?

 

[uptime1]

Are you able to sniff packets and see the BYE packet that indicates who hung up?
Sort of smells like a firewall timeout issue.

 

[Naveen | Cal4care]

Hello jcayer,

Does the 3CX firewall checker run successfully?

Could be SIP ALG is active on your firewall. If so, please disable the SIP ALG, then test the calls.

https://www.3cx.com/docs/manual/firewall-router-configuration/

 

[BrenttG]

i second the firewall suspicions, very likely there is a firewall issue. But you did not provide nearly enough details.

1. Is 3CX onsite, hosted, offsite, where? and is it connecting to the phones via SBC, VPN, Direct Sip, smoke signals? I suspect you might be using direct sip.
2. What firewalls are in play, both onsite and if applicable where 3CX is? Make sure to include make and model.
3. Do calls extension to extension also drop at 15 minutes, or does it only affect calls to or from external trunks?
4. Anything else that based on the above questions you think might be pertinent detail wise.

 

[YiannisH_3CX]

Calls dropping at the 15 minute mark is usually the work of session timers. You will need a packet trace to determine the if there is a session timer negotiated and if there is who should be refreshing the session. Then you can see which side is dropping the call.

 

[jcayer]

Are you able to sniff packets and see the BYE packet that indicates who hung up?
Sort of smells like a firewall timeout issue.

Thanks, I am unfamiliar with sniffing packets. I thought the logs (once set to "verbose") were similar to this. If not, is there an on-system "wireshark" function, or will I need to mirror a port and setup an external system, etc?

 

[jcayer]

Hello jcayer,

Does the 3CX firewall checker run successfully?

Yes, no problems. Have multiple other systems running on the exact same firewall setup with all passing the tests as well. Do appreciate the thought and suggestion though!

 

[jcayer]

i second the firewall suspicions, very likely there is a firewall issue. But you did not provide nearly enough details.

1. Is 3CX onsite, hosted, offsite, where? and is it connecting to the phones via SBC, VPN, Direct Sip, smoke signals? I suspect you might be using direct sip.
2. What firewalls are in play, both onsite and if applicable where 3CX is? Make sure to include make and model.
3. Do calls extension to extension also drop at 15 minutes, or does it only affect calls to or from external trunks?
4. Anything else that based on the above questions you think might be pertinent detail wise.

1) Hosted with Vultr (Listed in the 1st post) Phones connected via SBC (listed in the 1st post)
2) Remote end is the Vultr virtualized software firewall. Local end is a Ubiquiti USG Pro-4.
3) Only calls going OUT of the system. (Listed in the 1st post)
4) For ancillary pertinent items: I have similar SBCs behind Ubiquiti firewalls at at least 5 other locations that also use Vultr hosting (with the exact same virtualized firewall and rules) and no issues.. I'm personally leaning towards a SIP trunk issue, or possibly a bad install of 3CX?

Thanks for your thoughts, I hope the additional info leads us further!

 

[jcayer]

Calls dropping at the 15 minute mark is usually the work of session timers. You will need a packet trace to determine the if there is a session timer negotiated and if there is who should be refreshing the session. Then you can see which side is dropping the call.

Thanks YiannisH_3CX. Is there a function within 3CX to do a packet trace, or am I looking at a replicated port with a wireshark system? I'm not very familiar with that, but need to learn it seems.

 

[BrenttG]

we use vultr as well, i bet you i can get you sorted out with a little bit of poking, PM me if you would like some assistance.

 

[SweetAction]

Thanks YiannisH_3CX. Is there a function within 3CX to do a packet trace, or am I looking at a replicated port with a wireshark system? I'm not very familiar with that, but need to learn it seems.

You can do a capture directly from the PBX from the activity log page with the capture button:

Activity log though should tell you what ended the call

 

[YiannisH_3CX]

Also which provider are you using? Are you using a 3CX supported provider?

 

[jcayer]

Also which provider are you using? Are you using a 3CX supported provider

Yes, Wiretap Telecom. They have been good for us so far. Thanks!

 

[Cody Schilke]

Hi jcayer,

I hope you're doing well. We can certainly help troubleshoot this issue. Ping us via our helpdesk and we'll get started!

 

[YiannisH_3CX]

I hope you're doing well. We can certainly help troubleshoot this issue. Ping us via our helpdesk and we'll get started!

Please let me know if you need any assistance from our end as well.

 

[jcayer]

Sent a request over. I was actually able to reproduce the issue while running a 3CX capture! Yay?!

 

[MCCDCHS]

Any updates on this?

 

[jcayer]

Any updates on this?

Yes! I worked with Wiretap on the issue and we weren't able to find a 'smoking gun' that caused the problem. However, the issue seems to have stopped when we set the IP of one of their switches in the 'trunks' setup rather than their failover setup. I'm not completely sure WHY this would cause or rectify the issue, but it's been good at the moment.

 

[MCCDCHS]

I noticed you use "Ubiquiti firewalls" We were having the same issue, even though the SBC ports were allowed.

We even went and set the Firewall to OFF.. and still the issue happened... Then I setup a Allow - All Rule in the firewall that's is supposed to be OFF, and magic they started working... and yes we have a SBC. So, either a Port for the SBC isn't listed and is needing to be open or Ubiquiti is causing issues.

So, If you have the same issue again try adding an ANY-ANY / Allow Rule in the Ubiquiti Firewall and see if the issues magically disappear. I'm going to be shopping around of use a pfsence firewall instead.

Hopfully this helps someone else if they have a ubiquiti firewall.