SIP Trunk Disconnects After 10 minutes

[CalvinK]

Hi all. We have 3CX V20 hosted in Azure (Linux VM in Azure - in a VNET, public IP on VM, no firewall in front of the VM). We are re-using our existing SIP trunk - Telstra SIP Connect (We're in AU).

We used the supported SIP trunk template AU > Telstra - SIP Trunk. The SIP trunk registers and connects but after 10 mins, it unregisters.
Event log errors:
Registration at Telstra SIP Connect Generic has failed. Destination (sip:x.x.x.x:5060;transport=TCP;lr) is not reachable, DNS error resolving FQDN, or service is not available.
Trunk L:10000(Telstra SIP Connect Generic) has changed status to unregistered. This means that no more calls will pass via this trunk. Please check your network connection and the voip provider or other SIP PBX

Firewall check in the 3CX admin console passed all checks. Packet captures in the 3CX admin console and in Azure VM are showing outgoing TCP traffic, but getting no response when the SIP trunk fails to register. I've lodged a case with the SIP provider and the packet capture from their end is not seeing any incoming TCP post the initial register that was successful in the first minute. See attached.

SIP provider is pointing to TCP packets dropped in Azure, possible on the public IP interface, because the packet capture in Azure VM shows the VM's private IP. Seems weird that we have over half dozen 3CX servers hosted in Azure but never come across this.

As a temporary workaround, we have resorted to re-creating the SIP trunk as generic and changing the transport protocol to UDP. This registers and connects the SIP trunk indefinitely, but introduces other issues, like calls randomly dropping due to UDP fragmentation.

Just wondering anyone has experienced similar issues with the SIP trunk unregistering after 10 mins, or is using the same SIP trunk and could offer some insights. Thank you.

 

[leejor]

DNS error resolving FQDN, or service is not available.

What DNS server are you using?

 

[CalvinK]

What DNS server are you using?

The 3CX VM is using the default Azure DNS.

FYI we've followed this guide but the SIP provider has verified that the guide is for TIPT (Telstra IP Telephony) SIP Connect over MPLS. For TIPT over WAN, there is no network, DNS or route requirement. Outbound proxy resolves over public Internet, which we've verified.

 

[YiannisH_3CX]

Hi @CalvinK

It does look like a firewall TCP timeout which drops the connection after some time of inactivity. Try registering the trunk with TCP and make a call every 2 minutes or so to see if the trunk stays registered past the 10 minutes. If it does then it's most probably a firewall issue cutting off the TCP connection. Calls should help keep the connection active.

FYI the firewall checker is only testing UDP so not a great test in your scenario.

 

[CalvinK]

Hi @CalvinK

It does look like a firewall TCP timeout which drops the connection after some time of inactivity.

Yeah. That's what we're seeing based on the packet captures.
Interestingly we don't have a firewall, or WAF, or LB, or any other resources that filter or routes traffic in our Azure.
There's only a NSG and I can't think of what would be intercepting or dropping traffic.
The mystery of a firewall that "doesn't exist"? Could it be on the SIP provider's end?

I did find a configuration in the Azure public IP address called idle timeout, which was default to 4 minutes and I've maxed it to 30 mins. That didn't make a difference.
I'm assuming there are many people who host their 3CX in Azure. Surely the "vanilla" setup in Azure shouldn't be an issue?

Try registering the trunk with TCP and make a call every 2 minutes or so to see if the trunk stays registered past the 10 minutes. If it does then it's most probably a firewall issue cutting off the TCP connection. Calls should help keep the connection active.

Just tested this and the SIP trunk does stay up over 10 mins when a call is active, but as soon as the call hangs up (over 10 mins), the SIP trunk disconnects.

Is the 10 mins behaviour controlled in a parameter or SIP trunk configuration in 3CX?
Is there a parameter or SIP trunk configuration in 3CX that I can try changing to that the 3CX keeps sending new TCP requests?

 

[YiannisH_3CX]

I'm assuming there are many people who host their 3CX in Azure. Surely the "vanilla" setup in Azure shouldn't be an issue?

It's not as far as I know so it must be something specific to you. Also 90% of SIP trunks are using UDP so that might also be a factor.

Is the 10 mins behaviour controlled in a parameter or SIP trunk configuration in 3CX?

The 10 minutes are the re-registration timeout agreed upon the PBX and the SIP trunk provider. Upon registration the PBX will send a proposed timeout to the SIP Trunk provider which for Telstra is 600 seconds. It's the provider that sets the value though in their reply to the registration. So you can send 60 seconds but if the provider replies with 600 then it will still be 600.
You are seeing the trunk deregistering after 10 minutes because that is when the registration expires. In fact the TCP connection might have dropped earlier.

The best way to troubleshoot this is to run a pcap on the PBX and wait for the trunk to deregister. Check if after 9 minutes the PBX will send a new registration to the provider to try to renew the registration. Perhaps you could ask Telstra to run a pcap on their end as well for this duration. Check the pcaps after. If the PBX is sending the registration and Telstra is not receiving of if the do receive it and reply but the reply does not reach the PBX then the issue is somewhere in the middle.
After that you should research your hosted environment.

 

[emcastro]

I'm experiencing exactly the same issue after the upgrade to V20. (On Windows on Prem Installation)
All is working fine on V18.
Is this something like a software issue within 3CX on V20?
Is there not a temporary fix for this at least?

 

[emcastro]

I'm experiencing exactly the same issue after the upgrade to V20. (On Windows on Prem Installation)
All is working fine on V18.
Is this something like a software issue within 3CX on V20?
Is there not a temporary fix for this at least?

 

[emcastro]

Can someone share some thoughts if experiencing the same.
The customer is using Australian Phone Company as their SIP Provider.