Solved Answering a call makes the trunk unregister and register

[Mora]

I'm migrating from V18 to V20 - everything worked perfectly in V18. I had to delete and recreate my trunks.

In my test trunk, if I set the "Default route" to a user (me), then when I pick up the call and hang up, the call is not ended with the caller ... and around 10 seconds later, the trunk goes down and comes back up.

If I set the "Default route" to "Call Processing Script", then CFD answers the call and when I hang up, the trunk goes down and comes back up.

Firewall tests out fine.

I see only this error in the event log:
Registration at Test Trunk has failed. Destination (sip:178.21.248.30:5060;lr) is not reachable, DNS error resolving FQDN, or service is not available.
I have no problem pinging 178.21.248.30 and the error occurs when answering the call.

Here's a wireshark capture of the call (incomming call, after about 10 seconds client hangs up)...



Any suggestions?

 

[YiannisH_3CX]

Hi @Mora

From the screenshot it looks that your provider is not replying to the BYE message when you hang up the call making in unresponsive. Once a BYE is received the provider should reply with an 200 OK message for the call to be gracefully terminated which is not the case here.
This can be caused by a number of things but I would recommend starting by contacting your provider and showing them this screenshot or the whole pcap if you have it. They should be able to provide further insight as to why the BYE message is not answered.

 

[Mora]

Thanks.

I've been in contact with my SIP provider and he says that after they send 200 ACK, then everything they send on port 5060 times out. Here's a wireshark from their end....


V18 worked perfectly here and we have not changed anything in our Unify firewall.

When I call my test trunk, the first call (cfd) works fine, but following calls do not get through. Is it possible that there's a bug in 3CX that stops listening on port 5060 after the first call?

 

[YiannisH_3CX]

5060 is the default SIP port for most people so a bug like that is highly unlikely. I would recommend running a pcap simultaneously from your provider, your firewall and on the PBX machine and see if traffic reaches your machine. The pcap is done on the NIC of the machine so you should be able to see if the traffic reaches the machine before if hits 3CX. This will help you determine where the issue comes from.

 

[Mora]

Thanks

I found the problem - our firewall (Unifi) allowed some 5060 traffic and then blocked it for a while. After allowing the traffic in Unifi, everything worked fine.