Solved Cannot call out *sometimes* - Amazon Chime / 3CX On Prem / Fanvil X3U

[SalTel]

Hey all!

Relatively new to SIP and 3CX, I understand the basics but that's about it. I am having trouble with my calls going through my SIP trunk *sometimes*. One minute, it will work fine. The next? Nothing at all.

I am using 3CX version 18.0 Update 3 (Build 461) and a Fanvil X3U with the correct supported firmware for 3CX.

I followed the Amazon Chime Voice Connector guide here and firewall checker is passing, but still it's hit and miss.

My outbound rule is set so that anything with a 9 in front is forwarded to the outbound rule, stripping 1 digit (the 9) and adding a +1, making the phone number +19990009999.

I took PCAPs from the phone system and the screenshots from them are attached. Numbers 1 & 2 are failed calls, 3 is a successful call (not even 15 seconds after the 2nd failed call).

Please let me know if any of y'all have any idea what's causing this spontaneous behavior.

 

[YiannisH_3CX]

Hi @SalTel

From your screenshots it looks like the call is timing out but we cannot know for sure until we look inside the packets to see what is going on.
Did you try using a different device to see if you can replicate the issue?

 

[SalTel]

I tried my 3CX Soft Phone on my desktop with the same result... Is there anything else I could try?

 

[YiannisH_3CX]

Did you filter the packet capture in any way before taking the screenshots? Also did you run the firewall checker test? Does it pass? How often does this happen?

 

[SalTel]

Yes, I filtered before taking screenshots. There was a lot of TCP Application Data between the SIP packets.
As mentioned in the initial post, I run the firewall checker and all is good (yes it passes).
It's off and on. I'll check some nights and it won't work, then 10 minutes later it will - there is no pattern.

 

[YiannisH_3CX]

It would have been beneficial to see if a TCP connection could be established with the provider when the call was attempted. If a TCP connection could not be established then that would explain the gaps in the capture.

I will send you a p,m with something else to check to see if that improves the situation.

 

[YiannisH_3CX]

For anyone following the thread the issue was resolved by switching the trunk to UDP and reducing the time it takes for new DNS queries.