• V20: 3CX Re-engineered. Get V20 for increased security, better call management, a new admin console and Windows softphone. Learn More.

Solved Calls disconnected after around 30 seconds

Status
Not open for further replies.

CyberAndy

Joined
Apr 7, 2017
Messages
5
Reaction score
0
Dear all,

the system used to work fine, but recently I'm having problems with external incoming calls getting disconnected after around 30 seconds.
I have a ring group with three extensions, one extension (611) answers the call

Activity log below.
What looks suspicious to me is the entry:
06/06/2017 10:58:00 AM - [CM503021]: Call(C:7): ACK is not received from sip:XXXXXXX@XXXXXXX

Regards,
Andreas
 
Last edited by a moderator:
I have the same problem.
I have checked all sip alg, public IP, and NAT.

And the best is: with v15.0 it worked fine. The problem comes with v15.5

HELP!!!
 
  • Like
Reactions: Moawia Noor
Does the 3CX Firewall Test pass on all ports?
 
sure I did.
And got one step further.

We are using Sophos UTM9 Firewalls and I have created a multipath rule on my main firewall. Now the ACK is accepted and calls do not drop...
...in the main site.

We have other UTM firewalls in remote sites with IPSEC Tunnels. All traffic go thru the tunnels and there are no rules.
The phones in the remote sites still drop afer 32 seconds. no ack received...

ARGH!!
 
  • Like
Reactions: Moawia Noor
The phones in the remote sites still drop afer 32 seconds. no ack received...

Do you mean an extension call to the remote extension, or an incoming trunk call?
 
Incoming calls via trunk
 
So... incoming calls to extensions on the main site now work, but incoming calls over the same trunk group, to remote extensions, continue to drop? Extension calls from the main site, to the remote site do not drop. Is this correct?

After making some changes on your firewall, calls to the main extensions now work. I would suggest that there is still a problem with your Firewall, and that it requires some additional "rules".
 
I agree, but what could I change, when I have a full transparent tunnel with only one rule: allow all

Does someone know the dataflow of a call? I mean does someone have a flow-diagram? Where does the ACK request come from?
Why is the ACK necessary? I mean, the call is fine for 32 seconds. Why should an ACK be nessessary? Who has to receive the ACK? The PBX? or the client?
 
In very simple terms, ACK is a sip message that follows a 200 OK message to signify to the party that sends the 200 OK that this has been received. If there is no ACK received within 32 seconds then the call is dropped.
2017-09-18_14h23_03.png

This is a very basic call flow showing an incoming call to the PBX that is routed to an IP phone. As you can see after the initial Invites the call is answered by the IP phone and a 200 OK message is sent to the PBX. Then PBX then forwards the 200 OK message to the provider and sends an ACK to the phone. Once the provider receives the 200 OK from the PBX sends an ACK message to the PBX for confirmation.
This behaviour is specified in RFC3261.

You can run a capture and check where this is failing for you
 
  • Like
Reactions: virtual2
Thank You Yiannis,
this is very valuable for me. good explanation!
Is v15.5 able to capture by itself, or do I need wireshark?

And there is one more Question which makes me worry and confused:

With v15.0 if works fine.
With v15.5 I have those "ACK not received" problems.

What has been changed? RFC3261 should be valid for both...
 
the management console in Sp1 has the option to capture calls but for windows you need to install wireshark before using it. For linyx it will be installed for you once you upgrade to SP1.

The behaviour of the PBX should be the same for both version as the SIP engine of the PBX has not changed.
 
strange, eh?
 
btw: is there a list of fixed bugs for new releases?
 
Hey,

my provider is QSC. And the automatic config of the trunk uses "PBX delivers audio".
I unchecked (disabled) this option and voilà: It works!!!

What does that mean? Is it a disadvantage to disable that option?
 
What the hell...

after 1 day of stable operation I again had disconnects after 32 seconds
 
  • Like
Reactions: Moawia Noor
I don't think that it was the PBX delivers audio that temporarily solved the issue as the audio would still be routed through the PBX for local extensions. You mentioned that the issue is only with extensions in the other end of the VPN. To properly troubleshoot the issue you need to run a wireshark capture on the PBX and on the phone through the web interface of the device. Once you start both captures make a call and wait for it to drop. Save the captures and send them to me in a p.m so i can tale a look. This way we will be able to see what happens in both ends of the VPN and perhaps find the reason this happens. Before doing so please enable the PBX delivers audio option under the trunk settings.
 
  • Like
Reactions: virtual2
Hey Yiannis!
Thank You for the superior support. The issue is fixed now. It works like a charm!
You can close this.

In case someone will have the same problem in the future:
Reason for the disconnect after 32 seconds was an old template for my QSC trunks. The Trunk-Hostname was wrong.
It pointed to a host with TCP connection. Disconnection happened when ACK was not delivered.
With UDP there certainly is no such problem.
 
  • Like
Reactions: virtual2
Glad the issue is resolved and thank you for updating the post and sharing your solution
 
Status
Not open for further replies.
Get 3CX - Absolutely Free!

Link up your team and customers Phone System Live Chat Video Conferencing

Hosted or Self-managed. Up to 10 users free forever. No credit card. Try risk free.

3CX
A 3CX Account with that email already exists. You will be redirected to the Customer Portal to sign in or reset your password if you've forgotten it.