SIP INVITE not received by 3CX

[MCNY]

Hosted 3CX in Azure for 18+ months.
Was slowly migrating to 3CX from an on-premise PBX that previously forwarded calls over to 3CX.
Calls now come directly from Twilio trunk to 3CX and some failed calls started occurring.

Sporadic 408 errors in the Twilio logs for a few calls directly from Twilio to 3CX.
Azure Network Security Group log show call traffic, but no record of call in activity log.
PCAP log shows 4 INVITE attempts within the call with no responses from 3CX server.

After the failure, Twilio appears to attempt a second call which usually, but not always, connects just fine and appears in the activity log as expected.
The second call is usually from a different Twilio IP, but not always.

Some times a successful call minutes before the issue comes from the exact same Twilio signaling IP as the failed call.
Other times a call a few minutes later from the same signaling IP connects properly.

I have:
1) Run the Firewall Check
2) Reviewed Azure Network Security Group logs
3) Verified that the Twilio IP ranges are in the Azure Network Security Group and 3CX IP Blacklist configurations
4) Replicated with multiple inbound phone numbers (DID)

Other than the Activity log, is there any other network activity log that should be reviewed?

I am using default Anti-Hacking settings. Are there any other settings to check that impact initial SIP connections?

Thank you in advance for your suggestions.

 

[TheodorosG_3CX]

What is your primary DNS?

 

[MCNY]

What is your primary DNS?

Azure DNS (168.63.129.16)

 

[TheodorosG_3CX]

Can you test while using 8.8.8.8 Google DNS as primary?

 

[MCNY]

Can you test while using 8.8.8.8 Google DNS as primary?

Thank you for the suggestion.
I have made the change and I will be monitoring today.

 

[MCNY]

Unfortunately, the 408 Request Timeout error just happened again. I confirmed that DNS is set to 8.8.8.8. Am I correct is stating that the only record for me to review in 3CX is the Verbose Activity Log?

 

[TheodorosG_3CX]

This might require a combination of wireshark and verbose logs.
I would suggest to contact with your partner or create support ticket.

 

[Lee Cramman]

Haven't Twilio had some recent IP addressing / range changes that necessitated updating firewall rules?

https://www.twilio.com/docs/voice/t...ary 2024 Twilio,a single global range; 168.86.

https://www.twilio.com/docs/sip-trunking/ip-addresses

 

[MCNY]

Thank you for your suggestion Lee. Yes, the appropriate firewall rules for Twilio are applied. 99% of our calls come from phone numbers that are working fine with Twilio. It seems the problem is only with a single toll free number and only some of the inbound calls.

We have worked with Twilio support and they believe the INVITEs are correct when they send them, but 3CX never sees these in the verbose logs. I was able to use wireshark to see that the INVITEs are truncated and missing the end of the request. I am figuring that this is why the verbose log doesn't show anything. 3CX may not be logging incomplete INVITE requests (there are likely great reasons for this). My work around was to reroute the toll free call on the Twilio side and make it call 3CX using a DID. It has worked for now, but I end up paying for the call twice (once to Twilio, and again from Twilio to 3CX). A small price to pay to receive the calls properly.

I am in the process of moving the toll free number from our primary SIP partner Twilio to a secondary 3CX support partner. It doesn't hurt for us to have it with our secondary provider.

I do wish I could figure out why a 3CX server deployed in Azure according to the 3CX documented process would have this potential truncation issue. If it were a simple firewall rule, the calls would always be blocked. Thank you for your suggestion about the firewall rules. Maybe someone else has experience something similar and will be able to solve this mystery for me.

 

[Charles_3CX]

Regarding your question, do your toll-free numbers match any of the existing extension numbers?

 

[MCNY]

Great question. The last 4 of the toll-free numbers do not match any of our extensions (which are 4 digits in length). I would love to know if this is something we should keep in mind for any of our DID numbers. The DIDs are setup in the format +19998881234. In this example, 1234 does not exist as an extension.
I also looked at the Inbound Rule and the 800 number has the same setup as the local number DID that is working correctly.
Thank you for the feedback.