Asterisk 13 WARNING chan_sip.c: Hanging up call no reply to our critical packet

all of them have TLS enabled, some are using SRTP, some are not. Problem did not follow signalling method - I tried everything I could think of - udp, tls, tcp, nat, no nat, nothing made a difference. The systems were completely unusable with periodic “no response to critical error” messages. The problem went away when I switched to the asterisk 14 beta.

So I wanted to comment on this briefly. But there are over a hundred thousand different configuration scenarios in FreePBX/Asterisk. It would be hard for us to check a single subset of this. Especially when it comes to Asterisk bugs (Is this an Asterisk bug? seems like it) dealing with TLS.

I guess I am still not sure if this is FreePBX or Asterisk. There have been varying reports. hard to nail anything down in regards to fixing this or why it happened.

https://issues.asterisk.org/jira/browse/ASTERISK-19968

How about you install a fresh version when you post a new *.iso or *.img and give this wiki quick setup guide a quick try?

Or send us a copy of “FreePBX - Gold Edition”

This has nothing to do with new isos. Asterisk versions are updated separately from the iso. Your concerns seem to be soley with asterisk perhaps you should be brining this up to them?

FreePBX clearly links to a defective version of asterisk. Therefore, FreePBX should be taking steps to remedy this.

To put it another way, here’s some precedent for you if you follow the news at all. Takata made defective airbags. The car manufacturers who installed those airbags as part of their vehicles recalled the whole vehicle and replaced the defective airbag with a working one.

I only ask that you acknowledge the problem and takes steps to remedy it. For example, issue an update to downgrade the broken asterisk 13.x.x to a working 13.x.x.

Anyone is free to downgrade Asterisk 13 version on the Distro using either of the following:

yum downgrade asterisk*13.9.1
yum downgrade asterisk*13.10.0

and then:

fwconsole restart
2 Likes

Thanks for commenting. I fully understand the number of different scenarios and that bugs happen - I’ve written software so I fully appreciate the difficulties.
From my perspective on this issue, however, I got multiple client calling from cell phones this morning reporting that calls were disappearing when being transferred, hints weren’t working properly, and generally things were “broken”. The calls came from a variety of scenarios - phones connecting via tls with SRTP, phones connected through ipsec tunnels via udp, etc.
I’m in business with asterisk14 and so far so good. Some of the other issues I’d had with Asterisk13 have disappeared so it’s all good.
I apologize for coming down so hard. I hope you understand that this bug made yesterday quite rough. If you need any help testing things, don’t hesitate to reach out. I’ve been working with Asterisk for probably 15 years and I cut my teeth writing dialplans by hand so if I can be useful, please let me know.

I will give downgrading a try. However, I’m having trouble tracking down some form or version history or release notes for the minor updates to 13. I would like to downgrade methodically step by step until the problem goes away and then post the results. I currently don’t have a starting point for the first version to downgrade to. I’d be shooting blind with version numbers.

yum --showduplicates list asterisk13
1 Like

For anybody else reading this - I found a bug in the asterisk14 beta that was causing one system to crash when accessing the ucp (asterisk core-dump). Reverted to asterisk 13.9 and all is good.

This version has a queues bug which can potentially crash Asterisk. Be warned.

Thanks - I’ll use it only on systems not utilizing queues. Any known issues with 13.10? I’ve had some devices that didn’t want to stay registered with 13.10 which I assumed were network related until I tried the 14 beta and they stayed connected.

I initially ended up doing a fresh install of FreePBX 13 with asterisk 11 to get around the problem I was having before the asterisk 13 downgrade solution was proposed. However, when I find the version of asterisk 13 hthat works, do you see any issues upgrading my asterisk 11 system to 13.x? i.e. Does the FReePBX distro installer do much of anything different accept asterisk 11 or 13? Are there other modules I’ll need to prep or fix after the upgrade?

Major Asterisk versions can be changed on the Distro with zero effort without a reinstall:
http://wiki.freepbx.org/display/PPS/Changing+Major+Asterisk+Versions+on+the+Fly

On another fresh install of FreePBX 13.0.188.8 w/asterisk 13.11.2 on a demo machine, again I was able to replicate the error. However, I downgraded to asterisk 13.10.0 and the error was still present. Downgraded again to 13.9.1 and again, the error was still present.

@elijahmm you mention that in 13.9 you no longer have the critical packet error. What is strange is that I don’t see the error message in the log files anymore but I still have to dropped call symptoms. Are there any other parameters you modified to get it working? I created new extensions after the upgrade and they misbehaved too.

We’ve already fixed this on 13.11.2-2 (which has patches applied). We’ve tested these patches against the original issues and can confirm they work. @kolpinkb I think you are having a different issue.

Then it’s not the same issue.

There is a possibility it may in the end not be the exact same issue but, it is most definitely related. As soon as I upgrade back to 13.11.2 the problem still occurs but I at least get an error message timed exactly with the dropped call.

P.S. @tm1000 you should really work on your bedside manners. Maybe take some notes from @lgaetz

You should post the log so others can try to help you. Especially since you said the message is different. See here is the issue. We’ve applied patches that should work. If they aren’t working for you and you are getting a new error then we should report that error back to Asterisk, not FreePBX so that the issue was be resolved in 13.12.0 which is coming out in a month or so.

I am unsure what you mean by this statement. Could you clarify?

I just finished an “effective feedback for effective organizations” course and learned that, in general, publically criticizing the people that are trying to help you doesn’t usually elicit the change in behavior you might be looking for. Not saying anyone has done anything wrong, just thought I’d interject that here. :slight_smile:

2 Likes

Very early on in this discussion I pm’d you politely stating that i understand that your probably inundated with thousands of requests for help but, that this TLS/SRTP problem seems to be a rather important issue.

You responded by simply stating that you/Sangoma would not be looking into this and that you can’t reproduce the error.

Further, it wasn’t unitl multiple people starting chiming in with the same error and tearing a strip off Sangoma (hat tip @elijahmm) that you finally started asking questions instead of dismissing the issue.

I tried the troubleshooting on fresh installs as suggested by @lgaetz and reported my findings. And once again you simply dismiss it as my problem and passed the buck off to asterisk.

Even if in the end it is proven to be a bug with asterisk you offer no troubleshooting tips whatsoever.

I’ve dealt with many developers and network administrators over the years and I’m sorry to say your simply unpleasant to deal with.

To answer @cynjut I agree with his advise but the fact is I haven’t actually been helped by @tm1000 yet. I’ve simply been told “not my problem, call asterisk”