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

Distro Discussion & Help
43

That is not what I responded. You asked me this over PM

I know you’re probably inundated with support requests in general given how lit up the forum seems to be lately but I think the bug users are experiencing with SIP over TLS in FreePBX is worth some significant attention.

Downgrading to and older version of asterisk or recompiling the current one seems to fix them problem. But i think recompiling asterisk in FreePBX distro will break some functionality?

To which I replied with this:

We are not looking into this. What do you mean recompiling? Do you mean a newer version? Or the exact version you are on?

To which you never responded. I actually asked you three questions. You never answered any of them. If you ask me for a fix or a timeline on something we aren’t working on am I suppose to lie to you? You even started the PM with “I know you’re probably inundated with support requests”. Which is a true statement. PMing me directly isn’t going to help the situation. Opening a ticket or discussing it on the forums will but it doesn’t matter because you didn’t actively try to engage with me.

I never once dismissed the issue. I told you were weren’t looking into it. Which was a true statement considering where we were at during the week. You are inferring way too much here…

That’s not a dismissal. That is helping you find the right place to report bugs. Asterisk bugs should be reported to Asterisk. Not a middle man like us. Then we are just relaying what the last guy said. Furthermore we were also testing and using Asterisk 13.11.2 at the time I sent that with no issues with TLS. In fact last week we were using TLS on the Astricon showroom floor with no issues, so when you PM’d me I had already (technically) looked into it. Then I used TLS in a demo on Thursday in front of an Audience of about 30 people. So when I am sending you to Asterisk it’s for a legitimate reason. I actually DID test this in the way that I was utilizing TLS where this thread said it was broken.

That’s unfortunate you say this. I’ve had our support team look into my comments on this thread and they found no ill will from what I’ve said. But I will keep this in mind moving forward.

I never said these words.

At one point you even went snarky with a joke tweet I posted that you seemed to not like. You must have been looking me up online at some point.

Look. I get what you are saying but my last comment to you before you lashed out at me was trying to be helpful. I said that we republished 13.11-2 WITH the patches. I said I think you were having the same issue. I feel that you’ve had an issue with me from the get go and that even now, if I try to be helpful, you can’t or won’t see it that way. I tried to helpfully suggest that it might fix the problem.

Finally I will say that no one at Sangoma ever looked into this. We simply merged a patch in that maybe has to do with this for something we are doing internally that was run into on Monday. 10 days after you first PMed me.

44

I would like to point out something I noticed in this thread, and elsewhere, which is rather troubling. Specifically, I’m talking about the attitude Sangoma seems to take towards issues which involve Asterisk.

Sangoma presents FreePBX Distro as a Linux distribution based on CentOS that provides a fully functional PBX. One critical element of this functionality is, obviously, Asterisk. Sangoma mandates that, for support, you have to use the FreePBX Distro, especially with their commercial modules. So far this all sounds FANTASTIC. Sangoma is providing a tested, controlled, environment and mandating this known environment be used so they can focus on actual issues instead of troubleshooting a million different underlying configuration options and develop value-added features and capabilities. They provide a linux distro under their control and then build commercial modules which utilize this open-source base to provide enhanced functionality over what is community developed. Awesome.

The worrying item is the attitude towards Asterisk. I understand that Asterisk is maintained by a 3rd party and I understand that Asterisk can be temperamental. However, given that Sangoma has published a distro that includes Asterisk and maintains repositories with Asterisk binaries (compiled by Sangoma) and includes updating Asterisk as part of a monolithic update strategy (read FreePBX Distro version numbers), they have taken defacto responsibility for all of the Asterisk builds they provide as part of the distribution.

If a bug exists in a build of Asterisk provided by Sangoma then it is a bug in the FreePBX Distro. period. It doesn’t matter that it is an up-stream issue. At the very least a ticket should be opened for it, it should be worked as if it was caused by the internal build process, and if the bug is discovered to originate in the Asterisk source code then they should open a bug in the Asterisk bug tracker and set the status of the FreePBX bug to “upstream issue” (or something similar) with a workaround for those affected. If truly needed they should author their own patches in the same manner the pfSense folks have patched the FreeBDS kernel in the past. The goal should be to provide the best PBX experience possible, even if it means a little extra work. Simply kicking the issue as “it’s an asterisk issue, file your bug with them” is completely unacceptable given the level of involvement Sangoma has in distributing Asterisk to the FreePBX userbase.

Many of us are more than capable of producing and supporting our own Linux installs and then bolting FreePBX onto them as a management framework. We use the FreePBX distro for the reasons listed above - tested environment, mandated for support of commercial modules, etc., and we rely on Sangoma to provide just that. When a major component has issues and Sangoma doesn’t take responsibility for the issue then the trust is eroded and the benefits of using FreePBX Distro start to be replaced with liabilities. The confidence of using a “supported” platform is replaced with the fear of relying on a black box where fixing one issue (or patching a security hole) may cause things to break. FreePBX Distro should be the gold standard install, not an exercise in compromise. I don’t want to go back to compiling Asterisk myself but at least when I did I knew exactly what was there and when I’d upgraded from one Asterisk build to the next.

Given the way Sangoma is currently tying more and more core functionality and development of FreePBX into their commercial offerings (sipstation being required for SMS messaging and killing off device and user mode in favor of commercial endpoint manager based hot-desking, to name a few) ANY instability in the core functioning of the distro should be unacceptable. When somebody pays for a commercial module they don’t care who’s fault it is that something broke, they care that the thing they purchased isn’t working as expected and advertised.

I fear that if this attitude toward Asterisk isn’t corrected it will diminish the credibility of FreePBX and Sangoma in the PBX market. At present, FreePBX Distro is the go-to solution for an open-source telephony solution but if problems and finger pointing continue then the space is ripe for a new offering.

That being said, FreePBX is still a wonderful project and I, and others, really appreciate all the work that goes into it.

1 Like
45

We’ve done this several times. When the issue is reproducible for us. As I mentioned a few times during Astricon we were demoing TLS throughout the week and had no issues. We won’t open tickets up for issues we can’t reproduce. Unfortunately I am almost hesitant to tell people we can’t reproduce issues moving forward and just not commenting because the backlash (not talking specifically about this thread) when my teams says they can’t reproduce an issue is usually pretty bad. I don’t know how to make this any better without putting emoticons on all responses.

It’s open source. Anyone can add another provider (in fact it’s written in such a way to support other providers). I know of someone who has added voip.ms support. Obviously those that work for Sangoma would maintain the SIPStation support.

Edit 2018, it’s not open source GPL, It is commercial licensed but free

We aren’t killing off device and user mode (it’s nearly impossible to do so) and stating so only causes FUD in the community. Please try to refrain from making these blanket statements.

Edit by xrobau: Removed nearly. It’s impossible to remove device and user mode.

46

This is the first I’ve heard about the SMS module being opensource - it is tagged as “commercial” and the license is NOT opensource. According to the license distributed with the sms module any alterations, modifications, adaptations, etc. are forbidden. Therefore adding another provider is actually a violation of the license. The same license is present in the SMS git repository at http://git.freepbx.org/projects/FREEPBX/repos/sms/browse/LICENSE?at=refs%2Fheads%2Fmaster&raw

I said killing off device and user mode because you ARE killing off device and user mode. I tried submitting a bug re: device and user mode and was told it was a configuration issue (which it isn’t) and the bug was closed. The fact that it was filed as “3rd party issue” while it’s a core feature of FreePBX leads me to believe that it is simply a matter of time before it’s removed. If it’s not supported, considered 3rd party, and bugs are considered “configuration issues” then I don’t know how it can survive! Killing it would be as simple as removing the toggle under advanced settings so you can’t turn it on unless you dive into the database directly.

I believe that not responding would be even worse in terms of damaging the reputation of FreePBX. Like it or not, if Asterisk embedded in FreePBX is having issues for somebody it’s going to be blamed on FreePBX and Sangoma, not Asterisk and Digium. Simply stating that “we can’t reproduce the bug but here’s how to get us the information we need to reproduce it” or even offering to take a look at the offending system to collect telemetry yourself would go a long way. Another strategy would be to establish a public syslog server and instructions on how to link a system to this public syslog server. Simply require the ticket to include the IP of the source machine and discard all logs received that aren’t associated to an open ticket. This is similar to how Ubiquity networks handles debugging of their equipment in the field. They’ll ask you to enable debug logging and provide them with the public IP the logs are coming from. This approach completely eliminates the frustration of having to rely on other people’s guesses and pre-conceived notions of where the bug may reside and gives you predictable, first-hand information. It also creates a great experience for the person with the bug. I suspect that you could work with Cyberlink networks to establish such a syslog infrastructure, especially since it would also assist in their FreePBX hosting support efforts.

47

No we’re not.

Which bug?

It probably was.

It IS a core feature. Which is why I say it can’t be removed. Not won’t, it can not be removed.

We good now?

We’re looking into SMS. I thought it should be GPLv3, and I’m slightly surprised that it’s not. I’m assuming there’s a reason, I just don’t know what that reason is 8)

1 Like
48

If I have a team of people look into an issue. Then that same team goes to a convention and uses the same technology that is stated as having issues but has no issues. Then am I also suppose to login to said users systems free of charge to help do support debugging (who is liable for system damage,who pays for this time)? That seems highly out of the ordinary. We would get hundreds of free support requests a day if this was the case. It would be an unsustainable business method.

We have a ticketing system. A ticket was opened. The ticket was not dismissed. A PM was partially dismissed but questions were still asked in that PM. No reply was sent back. The ticket was processed today. Not a track record for ticket processing but you caught us in the middle of two conventions that happen once a year. The ticketing system is free. Tickets are where we typically ask for more information. On top of that we ask for support packages to be generated all the time through the freely activated system admin. I am sorry we can’t instantly jump on top of an issue from a thread of 4 people and one PM. I stated why Sangoma was not “looking into the issue” at the time. I’ll say it again. At the time the PM was sent to me I had three people in my office. All right next to me. Using TLS/DTLS. It wasn’t until we got home and connected remotely two weeks later that we had any issues. I actually shared the PM with two coworkers when I got it. Should I have detailed these steps? In retrospect I guess so.

I’ve stated our stances on Asterisk, user and device and other items and it just doesn’t seem like what I’m saying is getting across. So I really can’t see the point in further continuing with this conversation. Rob has kindly reiterated what I said. If people want to keep believing we are taking the axe to user and device mode then that is their prerogative. However if anyone actually spends time in the code then she/he would actually seem how far from the truth that is. Aside from the massive conversions we’ve had about it not going away I find it extremely hard to see how the closure of one ticket about user and device mode means it’s dead or that we are killing it. I’ve asked the community for wiki guides on using user and device mode about two months ago. I am still waiting. If anyone wants to improve user and device mode or provide documentation on it I am completely willing. I’ll give you access right now. Sign a CLA and you can contribute today.

In the end this issue got fixed because we were able to finally reproduce it when we were remote. Locally we couldn’t. I am sorry it did not go the way some would have liked it to go. I really am.

It’s strange really because everything that’s been stated here that we should do we already do do. Just not for issues which we can’t reproduce. As I’ve exhaustively tried to explain in this thread. When issues are discovered to be bugs in asterisk we write up a ticket (or use a previous ticket) in freepbx. Then we report it to asterisk. Then we link the two. Then we watch the asterisk ticket for developments. We have a special bond with Digium. Yes. They instinctively trust our bug reports and therefore an issue has to be full reproducible by someone in our team otherwise we are just passing along what the last guy said. I can post tickets as proof or even blog posts written by the asterisk developers on digiums website about how our team has helped them and vice versa but It won’t help anything. Minds have been made up already. In the end however, we already do all of these things.

And finally remember a ticket was opened on the freepbx issues tracker for this. It was not dismissed (it’s closed now as I believe the original issue is fixed but if not then feel free to reopen it)

PS. We aren’t killing User and Device mode.

PPS. WE ARENT KILLING USER AND DEVICE MODE.

(How did this turn into a conversion about user and device mode. Yikes).

Can we can back to discussing other issues now?

1 Like
49

Just in case there’s still some confusion, as I believe @tm1000 did beat around the bush a bit, I’d just like to make it clear that we are not removing device and user mode. I apologise for his lack of clarity.

50

Wow that is 40 minutes of my life I wont get back anymore from reading all this and responding. Guys nobody is killing off D&U mode. This has been covered in 100 different threads and tickets. Not going to rehash all the reasons and what unsupported means.

As far as this issue and how we interact with Digium on Asterisk bugs. We open tickets with Digium on things when its reproducible and effecting core issues. We also patch things ourselves and give them back or pull back patches early. Prime example is the TLS error users were getting Digium has fixed in GIT but has not pushed a new release for so we back ported the fix for our users. This is something we do regularly.

What we will not do is every single minor Asterisk issue wont lead to us reporting it to Digium. You as users of this free software have to take responsibility also. We provide a easy installer for users and its the platform we test and build on but its still all open source software. If you truly want a end to end commercially supported platform then look at our PBXact Commercial product which was invented for this reason. If you prefer to use the Free stuff then understand you have risk and warranty on your shoulders and we will try and help where we can but asking for Free Support on a Free product would cause us to go under with the amount of tickets people would send our way.

51

Yes please. I’m only trying to help - not start a fight. Please understand my criticisms and suggestions are backed by the best intentions.
I don’t want you to do free support - that would be insane. I was simply looking for a way to streamline the verification of bugs so you could authoritatively say “this is a bug” or “this is a configuration issue - here’s the link to the wiki and here’s the url for paid support”.
I’d love to get involved more in the code side of things - I have some enhancements I’d like to implement on the device and user side of things which could be very powerful in a BYOD environment (self-service registration of new devices to a user! Hugely helpful when people are using softphones on multiple devices. Probably need dual-factor auth for security as well.)

(Yeah, my fault on the device and user mode detour. I should have realized it was a hot-button issue when I mentioned it. My apologies.)

52

Thanks for the clarifications and sorry about the 40 minutes! I’m glad to be a part of the community and I appreciate the time and attention.

53

Error message in log file and dropped call symptoms for all of my endpoints (both local and remote) now operate without issue after updating to asterisk 13.11.2-2.shmz65.1.140.

Thanks a bunch!

2 Likes