Telnyx Credential Authentication not accepting invites

[maguirej]

We have numerous 3CX systems set to credential based authentication for several years now with no issues. Here recently, we have had two systems quit responding to invites from Telnyx. We have gone so far during troubleshooting to rebuild one pbx, and place a specific firewall rule allowing the sip.telny.com ip address as an explicit allow. One of the systems will still not respond to the invite the first time occasionally, and the other never responded to invites period. We will focus on the latter.

During troubleshooting, I created a new trunk with IP authentication. The DID's I placed on the IP based immediately began working.

Any idea on why all of a sudden multiple (current) systems would not respond to invites by sip credentials on the Telnyx trunk? Both systems have been running flawless for 12 months or greater. I would like to stick with credential based authentication for multiple reasons, but not if we continue with missing client calls.

 

[SweetAction]

You will likely need to do some packet captures to figure out what's broken. A capture on 3CX and a capture on the NAT device in front of 3CX. Simulate the issue, see if the invite makes it to the NAT device, see if it makes it to the PBX.
Once you know where it's breaking down you can then troubleshoot that area. In the event it never makes it to the NAT device you will likely need to engage the SIP provider support and ask them what they are seeing log wise.

 

[maguirej]

I have done pcap that confirms as described. Ticket filed with Telnyx, and they are passing the buck for a pbx configuration error. I see no such error and confirmed programming as instructed. By both Telnyx and 3cx.

If not was broken, it should fail for both credentials and ip based authentication.

I do think it is odd behavior as this configuration has been active for 12 months, and now it breaks.

 

[YiannisH_3CX]

Are you using UDP, TCP or TLS with Telnyx? Also I assume that at the time of the issue the trunks appear as registered in 3CX? Do outbound calls always work?

 

[maguirej]

Trunk always shows registered. I even disabled and re-enabled registration to confirm.

90%-100% of outbound calls are going through. We have not witnessed any, but customer did complain that a low percentage were not connecting.

I believe we are UDP, I think it is the default for Telnyx connection.

 

[YiannisH_3CX]

To be able to troubleshoot your issue you will need to run captures and go through the PBX logs to see if something is wrong on the PBX side. Since you are a 3CX partner and you are using a supported provider I would suggest creating a ticket with our support team so they can take a closer look at this.

 

[maguirej]

After considerable research, and multiple PBX's running into this issue, it appears that the call failures are relating to MTU size being too large. By Azure standards, fragmentation should occur after 1400b. Packets are larger than the 1400, but fragmentation is not occurring.

Still working the issue to see if we need to modify Azure settings. Currently four Azure hosted PBX's are effected. We have slimmed down the MTU by decreasing codec and compression, but still hovering in the 1300b mtu size.

 

[YiannisH_3CX]

You should be able to resolve your issue by switching to TCP or even TLS. That will negate the need for UDP fragmentation..

 

[maguirej]

How? I might be mistaken, but tcp is still limited by 1500b mtu size. I know it's more resilient, but fragmentation will occur due to increased overhead.

 

[YiannisH_3CX]

Just make sure that the option "Auto Discovery" is on next to the "Registrar/Server/Gateway Hostname or IP" and then navigate to the "Options" tab and switch the "Transport Protocol" to TCP.
3CX will deregister from UDP and reregister using TCP.

TCP is more resilient and other customers that reported the same issue managed to solve it by switch to TCP.
Try it and let us know