TIPS PIAF 1.7.5.5.4 install glitch

[Joe Mauk]

I am attempting to install PIAF 17554.iso and the "Gold" install. There is a error message about internet connectivity.

Internet connectivity has been verified.

The problem is that the script in PIAF 17554 used for downloading the PIAF files seems to have a problem.

The wget-log shows the iso seeking to obtain files from
http://pbxinaflash.com/1755/load/gold_load.tar.gz which resolves to ip 74.86.213.25:80
which produces a 404 Not Found.

The file is actually located at http://nerdvittles.dreamhosters.com/pbxinaflash/1755/load/gold_load.tar.gz

Please correct the problem.

Thanks, Joe Mauk

 

[wardmundy]

Joe Mauk: You're about 10 generations behind. Try one of the newer releases of PBX in a Flash or Incredible PBX here.

 

[Joe Mauk]

PIAF Gold is ultra stable and has proven to be very reliable. So, the fact that it is 10 generations behind is superfluous. So back to the open question. How do I get around the issue that the PIAF Gold has a broken link?

 

[wardmundy]

Joe Mauk: This 1755 code is over 2 years old and contains NO SECURITY PATCHES so I'm not sure it qualifies as "ultra stable" or "very reliable." In fact, it's quite the opposite at this juncture. If you are determined to use it anyway, try again. I moved a copy into place for you. BUT... we provide zero support. If there are other broken modules, you will need to address those yourself or seek commercial support.

 

[atsak]

Joe, Asterisk Green is ultra stable. Gold still suffers thread death sometimes. You want Green, really, unless you're running Unistim phones - and even then you want green with 11.9 . . .

 

[Joe Mauk]

First, major thanks to Ward for moving the files to a location that allows PIAF 1775 Gold to function. This action is very much appreciated. Thank you.

Now few remarks about reliability. Our company has Asterisk servers running the Gold payload that have been up and handing 5000 calls a minute for years. These server are tanks. They work. They are what attracged us to the Asterisk platform. We migrated to later PIAF builds with Asterisk 1.8 and have never really been satisfied.

Recently we moved to the PIAF 64bit Purple and have experienced numerous issues with large call volumes. Including, Asterisk restarts, memory leaks, sqlite slowing the machines down. FreePBX that won't properly configure FXO or E&M T1's. It is to the point that the newer versions are costing time and money. Both of which are limited commodities.

One of my coworkers has had conversations with author of what makes things like PRI's work with Asterisk. Asterisk 1.4.21.2, Asterisk Addons 1.4.13, Libpri 1.4.11.5, Zaptel 1.4.12.1 and FreePBX 2.6.0.6 make for a very stable combination.

Once more, many thanks to Ward for moving the files to allow PIAF 1775 Gold function.

Joe

 

[phonebuff]

Recently we moved to the PIAF 64bit Purple and have experienced numerous issues with large call volumes. Including, Asterisk restarts, memory leaks, sqlite slowing the machines down. FreePBX that won't properly configure FXO or E&M T1's. It is to the point that the newer versions are costing time and money. Both of which are limited commodities.

Sounds like a "Switch in a Flash" customer to me --

But on a side note this stability issue is why the Ham radio community is also still very much a 1.4.n user. In fact app_rpt for example, does not appear to run well in anything newer the 1.4.n An it does not appear to be the underlining OS 32Bit vs 64Bit of CentOS vs Ubunti vs Anything else.

It's Asterisk and / or Dahdi.

 

[JoeTalbot]

We have a bunch of 1.4 machines out there, running without incident for years, then over the past few months, I've started noticing nasty problems with the more recent releases. Lots of DAHDI related stuff. I know Jim Dixon of Zaptel fame and we talk regularly. When I quizzed him about this and we started going through the core dumps that the more recent PIAF systems were creating when they had issues, we found problems apparently related to SQLITE and the CDR. I asked him what he uses for his own projects and he told me that he still uses 1.4 and Zaptel, which are usually high volume/high reliability systems.

I've always been told to use 32 bit versions for production machines. Though recently, bugs started appearing in the 32 bit versions that weren't in the 64 bit versions. So, I thought, "Maybe they're not working on the 32 bit stuff anymore..." and moved to 64 bit. It seemed to work, but lately we've been finding showstopper bugs in almost everything that we use. It feels like there's a race to get cool new features out there, and stability isn't as much of a priority as it historically has been. This is just a feeling based on what I see.

We tend not to be on "the bleeding edge" because we can't accept too much bleeding. In the past, being out in front has been exciting and often dangerous. So we've stayed back a bit and tested advances as we could. It's a strategy that served us well for many years.

A few things:

A recent series of high profile fiascos have mainly been about a bug that causes Asterisk to restart when as few as 6 calls come in at exactly the same time. Our systems are used for live radio station contesting, mostly using PRI's. Radio call in lines are notorious for generating "spikey traffic". Our older PIAF systems would yawn and run for years. The more recent ones would die and restart, dropping all of the callers and the contest winner in the process. Since I'd never experienced behavior like this, I began looking into it. The core dumps pointed us to issues in Lua and SQLITE. Rolling these same systems back to 1.4/zaptel solved all of these problems and saved our reputation. It's not a solution that I'm happy with, but we need to get back to that level of stability.

I was so relieved to have the nice DAHDI configuration tool until I tried to use it for some E&M trunks to older PBX's (surprise! "You mean that a T-1 isn't the same as a PRI?") I set it up right, and started digging when it didn't work. The configs that it generated for the E&M were gibberish. Sigh. OK, I removed the tool and configured it all manually and it's been fine since. I also experienced similar fates when evaluating some analog cards.

It's easy to just come to forums and complain, so I haven't. I've been thrilled with PIAF for years and have sung its praises at conferences, or any opportunity that I get.
Now I'm concerned. How can I best help get these things fixed? What should I be doing here to help?

I will be setting up a call generator to bash the hell out of systems and see how they do. I really appreciate what this team has accomplished and what a game changer all of this is.

Thanks!

 

[wardmundy]

UPDATED...

JoeTalbot: Take a look at this thread and see if it doesn't resolve your SQLite problems. It's a known bug that has been documented but the fix has not yet been pushed out by darmock.

I'm not the right person to address the DAHDI issue since I don't use it. I'm sure others will chime in. Is the problem with the configuration tool or something else?? What version of Asterisk and FreePBX are we actually talking about?? Please correct me if I'm mistaken, but I get the impression you're talking about code that is no longer supported/maintained by the developers of PBX in a Flash, Asterisk (including Digium), and FreePBX. FYI: PIAF 1.7.5.5.4 was released in December, 2010 and was our production release for exactly 8 DAYS which speaks volumes about its overall stability.

Finally, to answer your question as to how you can help. By all means, beat the hell out of current releases of PIAF-Green 3.0 with CentOS 6.5, Asterisk 11, and FreePBX 2.11. We have thousands of heavy commercial users that have found it to be rock-solid reliable. By all means, let us know what's broken. Security issues aside (and they are numerous if we were to go back 3½ years), we simply don't have the resources to provide support for releases that are 20-30 versions out of date. Sorry.

 

[tm1000]

On that note we rewrote and completely fixed up the DAHDI configuration tool last year, before that it was pretty broken. It works with several cards that we test monthly.

http://wiki.freepbx.org/display/PC/Supported+DAHDI+Cards

Finally, to answer your question as to how you can help. By all means, beat the hell out of current releases of PIAF-Green 3.0 with FreePBX 2.11 and let us know what's broken. We simply don't have the resources to provide support for releases that are 20-30 versions out of date. Sorry.

 

[JoeTalbot]

UPDATED...

JoeTalbot: Take a look at this thread and see if it doesn't resolve your SQLite problems. It's a known bug that has been documented but the fix has not yet been pushed out by darmock.

I'm not the right person to address the DAHDI issue since I don't use it. I'm sure others will chime in. Is the problem with the configuration tool or something else??

The config tool had issues unless you were using a PRI (then it was excellent, except that the echo canceller is defaulted off). The problem showed itself like this:
Radio station has contest. Wants 51st caller. When they finally get the caller, all calls drop and Asterisk reloads, leaving a core dump behind. I was looking for D-channel issues, but it didn't appear to be that. I even bought an ISDN test set to collect unimpeachable data.

What version of Asterisk and FreePBX are we actually talking about??

We're talking about PURPLE.

Please correct me if I'm mistaken, but I get the impression you're talking about code that is no longer supported/maintained by the developers of PBX in a Flash, Asterisk (including Digium), and FreePBX. FYI: PIAF 1.7.5.5.4 was released in December, 2010 and was our production release for exactly 8 DAYS which speaks volumes about its overall stability.

I hear you, but we now have three stations running on it without any issues at all for a week.

Finally, to answer your question as to how you can help. By all means, beat the hell out of current releases of PIAF-Green 3.0 with CentOS 6.5, Asterisk 11, and FreePBX 2.11. We have thousands of heavy commercial users that have found it to be rock-solid reliable. By all means, let us know what's broken. Security issues aside (and they are numerous if we were to go back 3½ years), we simply don't have the resources to provide support for releases that are 20-30 versions out of date. Sorry.

I understand completely!

Thanks Ward! We had tried this last weekend:
noload => cdr_sqlite.so
noload => res_config_sqlite.so

And it seemed to run a little longer, but when it did crash, it would not restart automagically like before, putting us
in an even worse situation.

I don't make it a practice to run the oldest stuff out there, but you can imagine that after a while, customers expect
you to make something work, and we found that we couldn't experiment using them as guinea pigs any longer. The whole
episode cost us 5 figures and may have lost us further (more profitable) business, time will tell. We did pull out all
the stops to get something working for them, with your kind assistance, and that was recognized!

Any thoughts on 32 vs 64 bit? I'll admit that I'm still quite nervous about Dahdi.

I am loading your latest tonight, PIAF-Green 3.0 with CentOS 6.5, Asterisk 11, and FreePBX 2.11 and will start playing
with it while I set up my DAHDI basher scripts. I'll certainly share my experiences with you.

Many thanks!

Joe Talbot

 

[wardmundy]

We've always gone the 32-bit route because reportedly it got tested and supported better by Digium. I don't honestly know whether that's still true or not. Perhaps malcolmd will chime in.

I'm just wondering if some of this may be traceable to DAHDI issues. Both the cards and the software have undergone major plumbing changes since the Asterisk releases you're running. There's something to be said for separating your DAHDI hardware from your main server IMHO.

 

[phonebuff]

@Joe

I am curious I know why we still use DAHDI for some things but even there I am a long time Redfone fan, as the TDMoE in DADHI to the Redfone units made T1 and PRI interfaces so much easier and more stable then on board cards. (Unfortunately, Redfone has recently closed the doors).

But I would be interested to learn why you have stayed in the mode, verses the available ATAs like the Sangoma Vega and AudioCodes product lines to name two alternate solutions, that deliver SIP to Asterisk and can be failed over to alternate servers.

============

 

[JoeTalbot]

We've found that Zaptel and using cards is the most cost effective way to go and has historically offered the best reliability. I am aware of systems in San Diego 10 years ago running 4-4 port cards 24/7/365 without reboots for years, and as I mentioned earlier in the thread, Jim Dixon is a personal friend and kind of got this whole thing rolling. Zaptel made Asterisk viable in my opinion.

I've been suspicious of DAHDI since the beginning, and will investigate it further. When these problems came up, there were so many things to look at, and few clues.

It's my opinion that with a gateway device, costs are greater and you are at the mercy of the vendor. We've always preferred cards to gateway devices. (I have one of the first ISA Zaptel cards). Also, embedded devices seldom have enough CPU horsepower to run in the kind of situations and places where we use asterisk. Also, remember that until recently (the last couple of months), I never experienced issues at all. So all of this exploration and investigation that we've found ourselves doing has just recently become necessary. I'm glad that I know more about it all, but wish that it hadn't become necessary. Sorry to hear about Redfone. I have one of their units that will probably never go into service now.

Today, my goal is to create a test system that I can use to generate huge volumes of traffic that can be used to "break" the existing software (purple) and determine if the newer (to me anyway) version (Green) can survive the assault. The Green test system has been up since Saturday and is happily processing calls now.

 

[JoeTalbot]

I should also point out that the VOIP world is still the "Wild, Wild West" as it relates to providers. When it comes to selecting PRI vs SIP from a provider, we know that SIP should be fine, but the providers softswitches are not yet a known quantity when it comes to high volume performance. We know how PRI coming from 5ESS's, DMS-100's and the like behave. We have had issues with LEC SIP implementations (mainly them trying to jam G.729 down our throats and having no idea how to provision this stuff yet).

 

[phonebuff]

Well, I am in process of relocating an the number of ISA cards I came across an sent to recycling was to large to count. An that I see as one of the advantages to devices like the Redfone, AudioCodes and Sangoma boxes. They are dedicated to their tasks and only their tasks. So even when you need more horse power or just are forced to upgrade or have something die and can't find any ISA mother boards for example the appliances just keep chugging along. I have an CAC Adit 600 for example that does 48 Centrex to TDMoE via to T1 emulated spams and has been in service since Asterisk 1.4.n and maybe earlier even though the boxes that Asterisk runs on have ben updated / replaced a number of times due to "department" policy. (When the warranty expires the boxes are surplussed.)

Good luck on your testing, there is a tool around to help emulate loads, but I don't recall what it's called or where to find it off hand.

 

[JoeTalbot]

AH! The ISA cards were just mentioned to illustrate that "I go way back" on this stuff. The ISA Zaptel cards were mainly a proof of concept card and the ISA bus's bandwidth was completely consumed with a single card. In fact I've seen the prototype card. I've been using mainly 4 port PCI and PCIe cards without issue.

I appreciate your thoughts on all of this! Should you think of a tool that already exists or some information that you think would be helpful to the developers, please let me know and I'll do whatever I can to help!

 

[JoeTalbot]

Well. I flew up here to Vancouver to install Green... It's been behaving well at a couple of test sites. We had purple on here, and it had the deadly SQLITE bug, which I fixed by "noloading" it. But because of how the other sites behaved, I remain nervous and wanted to get the latest/most stable.

So, after getting it installed, I load the DAHDI config module... and find that it has yet another new bug. This time I'm greeted with "DAHDi Doesn't appear to be running. Click the 'Restart/Reload Dahdi Button' Below." and the /var/log/asterisk/full log shows me "[2014-06-17 13:38:44] ERROR[3383] chan_dahdi.c: Signalling requested on channel 24 is ISDN PRI but line is in Unknown signalling 896 signalling
[2014-06-17 13:38:44] ERROR[3383] chan_dahdi.c: Unable to register channel '1-25"

1-25??? Really? I can assure you that the GUI isn't showing 1-25.

I will likely have to install another ancient 1755 box, which I really don't wish to do. I'm happy to test this stuff if it's helpful. I'm getting the impression that nobody tests this stuff against real circuits?

Sorry, but I grow weary. I was so pleased when the DAHDI config tool came out, and then I discovered that it only worked for PRI's (Surprise! it munged up the configs for E&M circuits), but at least it was still useful for setting up PRI's, which is mostly what I do these days.

Please forgive me for being a jerk, but this is really frustrating. It's tough enough convincing corporate types of the value of Open Source Software, this makes it much, much harder. I'm willing to help!!! But somebody needs to be looking at this stuff, trying it out.

 

[james]

The bug was introduced while fixing the "PRI only" thing. In the link lgaetz posted above I mention it has been corrected and is in QA. There is no mandate to use the module, you can disable it and configure manually.

 

[tm1000]

Hi Joe,

The issue at hand should be resolved shortly and yes we do try to test everything as much as possible but I have over 50 hardware cards on hand. For every change we make it would be crazy to text over 50 of those cards, plus, while we have the cards we do not have PRIs, BRIs (cant get those in America) to actually test the actually dialing out. Like I said we test as much as we can. Unfortunately a bug slipped into the code recently, if you don't know we hired James from Rhino (maker of PBX Hardware products) and he's been working through bugs in the software as well. So it's headed in the right direction and if you want to help test then thats great.

Furthermore in FreePBX 12 we will have the ability to rollback modules up to 5 versions and switch each module to a beta mode so that people won't run into these issues, there will be a ton of fallback.

If you are truly willing to help then let me know how you would like to help. Reporting issues to PBX in a Flash, while useful, is not entirely helpful, especially since we have an official bug tracker at http://issues.freepbx.org and our own forums and while Ward and others will quite often let us know whats going on they can't always get to every thread.

Let me know what I can do!

Well. I flew up here to Vancouver to install Green... It's been behaving well at a couple of test sites. We had purple on here, and it had the deadly SQLITE bug, which I fixed by "noloading" it. But because of how the other sites behaved, I remain nervous and wanted to get the latest/most stable.

So, after getting it installed, I load the DAHDI config module... and find that it has yet another new bug. This time I'm greeted with "DAHDi Doesn't appear to be running. Click the 'Restart/Reload Dahdi Button' Below." and the /var/log/asterisk/full log shows me "[2014-06-17 13:38:44] ERROR[3383] chan_dahdi.c: Signalling requested on channel 24 is ISDN PRI but line is in Unknown signalling 896 signalling
[2014-06-17 13:38:44] ERROR[3383] chan_dahdi.c: Unable to register channel '1-25"

1-25??? Really? I can assure you that the GUI isn't showing 1-25.

I will likely have to install another ancient 1755 box, which I really don't wish to do. I'm happy to test this stuff if it's helpful. I'm getting the impression that nobody tests this stuff against real circuits?

Sorry, but I grow weary. I was so pleased when the DAHDI config tool came out, and then I discovered that it only worked for PRI's (Surprise! it munged up the configs for E&M circuits), but at least it was still useful for setting up PRI's, which is mostly what I do these days.

Please forgive me for being a jerk, but this is really frustrating. It's tough enough convincing corporate types of the value of Open Source Software, this makes it much, much harder. I'm willing to help!!! But somebody needs to be looking at this stuff, trying it out.