Unsupported provider issues

[ZoloN]

hi all,

I ran into troubles in last days when some people have complained, that my phone number via Telnyx isn't reachable - they got message: "the called number is temporarily not available".
funny story: outgoing calls were functioning fine as before, Trunk status was green, FW check - again all in green.

based on my investigation in the system log I've found error message:
11.07.2023 10:16:06:912 | 8 | Dev(1515654945):[sip:[email protected] / xxxxxxx (sip:[email protected]%20/%20xxxxxx)]: (!) No transport is found for destination: sip185.246.41.141:5060/UDP
leading me into wrong direction and I lost a day chasing ghosts (deleting trunk, re-creating using Telnyx template, re-creating using generic template,....)

After this I've started my investigation from a scratch, started with packet sniffing looking after the Telnyx-3CX communication and I've realized:

• Register - OK
• Invite at incoming call - unanswered (ignored) by 3CX

searching the Forum I've found following post: https://www.3cx.com/community/threads/telnyx-credential-authentication-not-accepting-invites.113253/ and I can confirm following:

• default Transport Protocol is (obviously) UDP
• the Invite UDP packed coming from Telnyx was spitted into two packets - which 3CX apparently cannot handle
• changing Transport Protocol from UDP to TCP has solved the issue an incoming calls are now working again

dear 3CX, can you please look into why is the fragmented UDP Invite packet ignored?

 

[YiannisH_3CX]

Hi @ZoloN

3CX can handle fragmented packets if they are delivered correctly to 3CX. I have seen multiple occasions when the packets are fragmented and 3CX deals with them correctly but the network/firewall etc. needs to deliver them correctly to the PBX.



Here is a fragmented Invite to the PBX which is way way above the MTU and its in UDP. The PBX receives it and replies with 200 OK correctly. I intentionally switched SRTP on and IPv6 to make the packet larger and exceed the MTU.
Of course that does not mean you should rely on this. If you can reduce the size of the packet that would be the best case scenario. See if you can remove codecs or SRTP if present from the providers side.