“WARNING chan_sip.c: Hanging up call no reply to our critical packet”
We are running FreePBX 13.0.188.3 (latest version) with Asterisk 11.23.1 and everything works great. Recently we tried “Asterisk-version-switch” to change to Asterisk 13 and right away the problems started. The below error started when we switched to Asterisk 13 and went away the moment we switched back to Asterisk 11. It’s the ONLY change we did on the system. Does anyone have a solution? I also recall us having tried Asterisk 13 a couple of weeks earlier so maybe the issue is only in the most recent incarnation of 13.
I only posted the single line “error” message because there is no issue while on Asterisk 11. I am not changing the config, firewall or location of the server. The only change is asterisk-version-switch to Asterisk 13 so it’s odd that I would have a NAT problem in Asterisk 13 but not in Asterisk 11.
This could be simpler than that - did you look at the ports for your SIP connections? Version 13 introduced PJ-SIP, which (by default) uses 5060. Your old configuration is probably using Chan-SIP for everything, and the default port changed to either 5061 or 5160 (depending on which image you used).
May I ask what handsets you are using? We had a simular issue a while back, figured it was the age of the handset. Ended up replacing handset, but if I can still use them that be great.
You know I’m all about the obvious questions - “no reply to our critical packet” is usually a port problem, a firewall problem, or a NAT problem. Since he’s using Chan-SIP, it’s only prudent to check all of the ports. If that isn’t it, the usual culprits are the next things to check.
Thanks for all the comments. I’ll try to post a log shortly but I did not see anything when I checked the log the first time. Switched back to Asterisk 11 and everything runs great. Maybe I’ll wait for the next update to Asterisk 13 and try again.
I’m having a very similar problem. The weird part is my Polycom VVX300 handsets both local and remote work fine as well as the Granstream HT502s. The problem seems to be appearing for Zoiper users of android and iOS. Tried toggling the battery optimization settings as that has sometimes been an issue in the past but no luck this time. The symptom is that the user cannot actually answer the call. Pressing/sliding the answer button does nothing. There was a recent zoiper update, and android os update, and some freepbx updates happening all within the same week. The following appears in my log file:
[2016-09-18 11:29:28] VERBOSE[25888][C-00000014] app_stack.c: Spawn extension (from-internal, 1001, 1) exited non-zero on ‘SIP/1001-00000029’
[2016-09-18 11:29:28] VERBOSE[25888][C-00000014] app_stack.c: SIP/1001-00000029 Internal Gosub(func-apply-sipheaders,s,1) complete GOSUB_RETVAL=
[2016-09-18 11:29:28] VERBOSE[25888][C-00000014] app_dial.c: Called SIP/1001
[2016-09-18 11:29:28] VERBOSE[25888][C-00000014] app_dial.c: Connected line update to SIP/1005-00000028 prevented.
[2016-09-18
11:29:28] WARNING[1907] chan_sip.c: Retransmission timeout reached on
transmission [email protected]:5061 for
seqno 102 (Critical Request) – See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 99ms with no response
[2016-09-18
11:29:28] WARNING[1907] chan_sip.c: Hanging up call [email protected]:5061 - no reply to our
critical packet (see https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions).
[2016-09-18 11:29:28] VERBOSE[25888][C-00000014] app_dial.c: Everyone is busy/congested at this time (1:0/0/1)
So it turns out that this problem has also shown up on two completely different soft-phone apps (Zoiper and CSipSimple) as well. This app hasn’t been updated since 2015 and has worked for months without issue using TLS and SRTP. I just don’t use it that often so I didn’t know it was acting up too.
I’ve gone as far as starting with a fresh FreePBX installation and the issue is still present. The problem started around the second week of September 2016.
My router hasn’t had its software updated in months and I haven’t made any changes to the firewall settings either. I think there was a module update to the “Asterisk SIP Settings” around September 14th and I’m wondering if there is a header that some endpoints can deal with and others just simply wig out. I’ve had to move all the affected endpoints to UDP signalling to make them work.
I’m not trying to point the finger at FreePBX but I find the evidence interesting. Updates for Android 6.0.X came out around this time as well as iOS 9/10 so it could very well be a combination of an endpoint OS modifying the header and/or FreePBX not being able to interpret the return data.
Apologies in advance. Not trying to bump this thread.
I just received an update for the Zoiper soft-phone for android this morning. I’ve tested it on multiple devices and the issue has gone from 100% NOT working to around 75% NOT working. That percentage is referring to the frequency at which the call is dropped and the “critical packet” response appears in my log file in FreePBX.
Is it possible that the 99ms FreePBX is waiting for the critical packet(s) is not long enough? Other past posts have come up with similar error message with around 31999ms for a particular waiting period? Is is possible to change this settings somewhere in the advanced SIP settings in FreePBX?
I think this might be the reason this error appears on some endpoints and not others. Some devices (especially mobiles) due to their power saving features take over TCP connections from apps and and go into a doze state. When the packet is received the OS wakes up the app that TCP session is related to and then allows it to send a response. Whereas a device like a Polycom VVX300 phone never has any issues responding under 99ms due to its inherent optimizations.
Given the specific app update I received this morning it is not unreasonable to think that sometimes it responds in less than 99ms and the remaining times it takes longer. Qualify packets take a few hundred ms sometimes on mobile networks to respond so there must be a way to compensate for this critical packet somehow.
So I added one of my Windows 10 computers with its firewall completely disabled running a softphone endpoint (software version from 2015 that used to work fine with TLS and SRTP) to the same public subnet and physical dumb switch as the PBX and the problem still persists.
So I found another discussion forum where this problem has been observed. The forum is in Greek so I had to run it though google translate which you may find in the following link:
@tm1000 should be interested in hearing this. With the show going on right now, it’s probably “crickets” at FreePBX headquarters right now, but if this is the case, I’d expect you’ll want to add a ticket in “Issues” that documents your finding. @xrobau will probably also want to weigh in when he gets back from his family emergency.
At this time we can find no issues with asterisk. We are also not going to update asterisk until we have fully vetted 13.11.2. There is no need for a ticket against asterisk in our ticket system.
Just setup FreePBX 10.13.66 64-bit from the July 24th archive and the issues I and others have described are not present.
However, when I install the FreePBX 10.13.66 64-bit from the September 15th archive the problem is now present.
I used completely different hardware for the test setups. Mixture of Intel and AMD cpus and Intel and Realtek network cards.
I also blocked WAN access to the boxes during the installation procedures up until the activation stage to prevent updates.
I get the same error messages below:
[2016-09-29 14:28:09] VERBOSE[6934][C-00000001] app_dial.c: Called SIP/1001
[2016-09-29 14:28:09] VERBOSE[6934][C-00000001] app_dial.c: Connected line update to SIP/1013-00000002 prevented.
[2016-09-29
14:28:09] WARNING[2233] chan_sip.c: Retransmission timeout reached on
transmission [email protected]:5061 for
seqno 102 (Critical Request) – See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 99ms with no response
[2016-09-29
14:28:09] WARNING[2233] chan_sip.c: Hanging up call [email protected] - no reply to our
critical packet (see https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions).
[2016-09-29 14:28:09] VERBOSE[6934][C-00000001] app_dial.c: Everyone is busy/congested at this time (1:0/0/1)
Same problem here - I updated FreePBX distro over the weekend on multiple instances and ALL of them exhibited this issue as soon as people started using them this morning - made for a very very bad day for me. Many of my installs are using asterisk13 features so versionswitch to 11 is not an option. I crash-upgraded to the asterisk14 beta which solved the problem in the short-term. How did this happen?! It’s really not acceptable and it’s going to force me into internally testing every FreePBX update prior to releasing them for installation onto client systems.