ACK is not received Error.

[wzaatar]

Hello, everyone.

I currently have a 3CX setup involving a couple internal and external extensions and am experiencing the following issue, dunno if some of you ran into this:

When an internal extension calls an external extension, the call goes perfectly well.
When an external extension calls an internal extension, the calls goes perfectly well... For 30 seconds only when it breaks. I pulled out a trace from the log and you can notice a message after 30+ seconds as per the below at 22:52:32.568:

22:52:32.578 Call::Terminate [CM503008]: Call(27): Call is terminated 
22:52:32.578 Call::Terminate [CM503008]: Call(27): Call is terminated 
22:52:32.568 Call::Terminate [CM503008]: Call(27): Call is terminated 
22:52:32.568 InviteADS::onAckNotReceived [CM503019]: Call(27): ACK is not received
22:52:00.482 CallCtrl::onLegConnected [CM503007]: Call(27): Device joined: sip:[email protected]:5060 
22:52:00.482 CallCtrl::onLegConnected [CM503007]: Call(27): Device joined: sip:105@XXXXERASEDXXXX;transport=UDP 
22:51:53.372 CallCtrl::onSelectRouteReq [CM503004]: Call(27): Calling: RingAll100:101Ext.101102Ext.102103Ext.103104Ext.104@[Dev:sip:[email protected]:5060, Dev:sip:102@XXXXERASEDXXXX:5060;transport=UDP, Dev:sip:[email protected]:5060, Dev:sip:[email protected]:12338] 
22:51:53.362 CallCtrl::onIncomingCall [CM503001]: Call(27): Incoming call from Ext.105 to [sip:100@XXXXERASEDXXXX;user=phone]

A weird 'ACK is not received' message is appearing and the call is terminated. Any way to fix this?

Any help would be appreciated,

Thanks.

W.

 

[jelliott52]

I recently had a similar issue at my house. Is this happening across all phones or just some extension? It could be a couple of things, switch going bad or a port is going bad. Do a ping test with the -t command and let it run for 10 minutes and then see if you are dropping packets. If you are using a linux computer do a a ping -f this will tell you real fast if you are dropping packets.


I had to replace 2 - Linksys 8 port gig switches, they where only 6 months old. So I went back to my tried and true HP Procurves.

Jay

 

[DXS_Matt]

We were having the exact same issue, and it ended up being a bug in the 3CX system.
We are using Broadvox as our trunk provider and 3CX ended up issuing us a patch for the problem.

I'm now afraid to update to the latest version of the phone system because nowhere in the changelog does it mention if this issue / patch is actually included.

We were also told that a conference "hold loop" was fixed in a trouble ticket, but that isn't in the changelog either.

Matt

 

[wzaatar]

We were having the exact same issue, and it ended up being a bug in the 3CX system.
We are using Broadvox as our trunk provider and 3CX ended up issuing us a patch for the problem.

I'm now afraid to update to the latest version of the phone system because nowhere in the changelog does it mention if this issue / patch is actually included.

We were also told that a conference "hold loop" was fixed in a trouble ticket, but that isn't in the changelog either.

Matt

Thanks for the feedback, Matt.

Which version of 3cx were you running?

 

[mbulles]

Hi,

I have the same error, upgraded v7.1 to 8, before never had this issue.

See my post for logs:

http://www.3cx.com/forums/call-get-disconnected-ack-error-after-upgrade-to-v8-13389.html#p68800

I think i will switch back to 7.1 as long as the problem persist.

 

[bluefox8080]

We were having the exact same issue, and it ended up being a bug in the 3CX system.
We are using Broadvox as our trunk provider and 3CX ended up issuing us a patch for the problem.

Hi Matt, can you maybe please send me the patch as well?
We have the same problem for one of our clients

Regards

 

[sdavies68]

I am having the same problem.

I have a normal sip line which is working fine, but this problem is only occuring on the SIP trunk

Looking at the wireshark traces the problem seems to be the SIP Ringing message is incorrectly send with the internal IP rather than the External IP. This seems to cause the hickup with the Service provider.

It also creates a wierd loop with Queues, where they keep ringing once answered.

I am running 8.0.10824.716.

Could I also get this patch. Obvious its a serious problem which 3CX needs to address ASAP.

 

[mbulles]

Hi,

I installed the patch found in the thread (Patch_Endpoint.rar) and under settings/network/stun I disabled the stun server and since then my ACK error is gone.

Hope this helps...

 

[sdavies68]

I cannot find the patch - Patch_Endpoint.rar - in the thread. Where is it located?

Where is it located? What version of 3CX did you allow the patch to?

Any response from 3CX as to an offical location of the patch would help.

 

[nb]

Ack is not received can occur for a HUGE number of reasons.

If the patch is no longer available, this means that the latest version has it included.

We need to see logs.

you can try disabling stun for example. This is one of the reasons why ack could not be received.

sdavies - Were you working with this provider before? When did this issue occur?

Thanks

 

[sdavies68]

STUN is disabled and the contact field is set with my external IP address.

Please dont tell me its fixed, because it is not. I have run a wireshark trace on the communication and can see that on an inbound call all the SIP messages are fine up to the point of the ringing message.

The contact field in the Ringing message is incorrectly using the internal IP address, rather than the external IP address as set in my configuration. All other Contact fields in the SIP messages are correctly using the external IP address.

As such the SIP registar does not think the line is ringing and ignores all SIP/SDP messages there after.

This problem has only occurred since upgrading to version 8 from version 7.1

 

[sdavies68]

Content of the SIP Ringing Message sent from my 3CX server to the SIP provider.

Contact: <sip:[email protected];user=phone>

It should be

Contact: <sip:[email protected];user=phone>

Which is the External IP address I have set under network settings.

After the ringing and when I pickup the call the 3CX sends several SIP/SDP every 4 seconds (with the correct contact) but there is no response from the registrar as the Ringing message was incorrectly formatted.

I would add, I am using a SIP trunk and the provider does not require a registration, it uses Contact fields, Proxy destination and other values to authenticate the call.

 

[nb]

You have an option -= Which IP to use in Contact field for registration.

Select Specified IP and put the public ip address.

Did you do this? If you did this and you still see local ip, wireshark and I will investigate.

 

[sdavies68]

I have set it manually in the network settings with stun disabled. I have also set it manually in the provider link setting.

 

[nb]

Can you make a capture with wireshark? The logs you posted are not enough to see what is happening.

Also since the VoIP Provider is unsupported, it could be that the generic template is not valid for this configuration. A capture will be very useful.

Thanks

 

[dominicbatty]

Hi Guys, I have recently moved from v7 onto the latest v8 platform and immediately hit this error.

What I am finding is that the portion of the "Contact" message back to my SIP provider after the "@" symbol should be set to STUN resolved public IP address and port.

Instead of this it is always set to whatever value has been left in the Settings > Network > STUN Server > Public IP to specify in Contact and SDP" field.

i.e. I turned off STUN (ticked box) so I could get to this field, set it to 1.1.1.1, turned STUN back on again (unticked box) and then made a call. The contact field was @1.1.1.1:5060 on the end instead of the public resolved STUN address.

It looks like their logic is always making the contact field @.... this field without taking into account whether the STUN box is ticked.

I have logs, wireshark traces and everything to prove this. I have them from both v7 and v8 installed on the same box and platform proving it used to work ok and now does not.

This is all logged with 3CX under our support account and is being worked upon.

I will keep you updated.

Regards, Dominic Batty

 

[LeonidasG_3CX]

Hi Guys, I have recently moved from v7 onto the latest v8 platform and immediately hit this error.

What I am finding is that the portion of the "Contact" message back to my SIP provider after the "@" symbol should be set to STUN resolved public IP address and port.

Instead of this it is always set to whatever value has been left in the Settings > Network > STUN Server > Public IP to specify in Contact and SDP" field.

i.e. I turned off STUN (ticked box) so I could get to this field, set it to 1.1.1.1, turned STUN back on again (unticked box) and then made a call. The contact field was @1.1.1.1:5060 on the end instead of the public resolved STUN address.

It looks like their logic is always making the contact field @.... this field without taking into account whether the STUN box is ticked.

I have logs, wireshark traces and everything to prove this. I have them from both v7 and v8 installed on the same box and platform proving it used to work ok and now does not.

This is all logged with 3CX under our support account and is being worked upon.

I will keep you updated.

Regards, Dominic Batty

Hi,

Right after making such changes in the PBX, it s required to restart the phonesystem / tunneling services for the new settings to take effect.
Can you try the above and see if the problem persists?

 

[dominicbatty]

Yes, I did this and it was still a problem.

 

[nb]

Is this still a problem at the moment? Or it was a problem and you are concerned it might happen again?

Ack is not received happens for a lot of reasons - could be stun related, network topology related etc etc

Capture logs and current status of your situation is important

 

[dominicbatty]

Hi Nicky, I have a log open with support that proves this issue really clearly. If you want, I can send you a copy of the log and the wireshark trace that explains this. My only concern is I don't want everyone working on it and you duplicating efforts. I cannot attach the wireshark log to this as it will contain my SIP passwords etc but if you wanted me to email it direct then please drop me an email on [email protected]. Regards, Dominic.