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.
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
May 10, 2016
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.
Nov 28, 2016
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.