BUG IncrediblePi 3.11.10 (06/20/14)

[RPi-Fan]

file : extensions_custom.conf

[pgv-out-common]
exten => _X.,1,NoOp(*1*)
exten => _X.,n,System(gvoice -b -e ${ACCTUSER} -p ${ACCTPASS} call ${EXTEN} ${RINGBACK} 1)
exten => _X.,n,NoOp(*2*)

The above snippet repeatedly fails when the system is first booted or following a reboot:

-- Executing [15622620000@pgv-out-common:1] NoOp("Local/15622620000@pgv-out-norwalk-00000000;2", "*1*") in new stack
-- Executing [15622620000@pgv-out-common:2] System("Local/15622620000@pgv-out-norwalk-00000000;2", "gvoice -b -e [email protected] -p password call 15622620000 16313809999 1") in new stack
== Spawn extension (pgv-out-common, 15622620000, 2) exited non-zero on 'Local/15622620000@pgv-out-norwalk-00000000;2'
== Everyone is busy/congested at this time (1:0/0/1)
-- Executing [s@macro-dialout-trunk:31] NoOp("SIP/10-00000000", "Dial failed for some reason with DIALSTATUS = CHANUNAVAIL and HANGUPCAUSE = 0") in new stack

Following an "amportal restart", the same snippet then reliably executes until the next boot/reboot:

-- Executing [15622620000@pgv-out-common:1] NoOp("Local/15622620000@pgv-out-norwalk-00000001;2", "*1*") in new stack
-- Executing [15622620000@pgv-out-common:2] System("Local/15622620000@pgv-out-norwalk-00000001;2", "gvoice -b -e [email protected] -p password call 15622620000 16313809999 1") in new stack
-- Executing [15622620000@pgv-out-common:3] NoOp("Local/15622620000@pgv-out-norwalk-00000001;2", "*2*") in new stack

I don't know if it's related, but there is also an anomaly with "amportal restart":

root@incrediblepbx:~# amportal restart
Please wait...

STOPPING ASTERISK
Waiting for Asterisk to Stop Gracefully...
Asterisk Stopped
SETTING FILE PERMISSIONS
Permissions OK
Removing any dangling symlinks
Dangling symlinks removed
STARTING ASTERISK
Unable to connect to remote asterisk (does /var/run/asterisk/asterisk.ctl exist?)
Asterisk Started
root@incrediblepbx:~#

The same snippet executes 100% reliably without requiring an "amportal restart" following a boot/reboot with RasPBX/IncrediblePBX 4.11.4.

There is also no "Unable to connect to remote asterisk (does /var/run/asterisk/asterisk.ctl exist?)" with RasPBX/IncrediblePBX 4.11.4.

 

[wardmundy]

If memory serves me correctly, I think we forced an amportal restart as part of the boot process in the earlier build. I probably forgot to add it this time around. The other message is harmless. I'll have a look next week when we return to home base.

 

[RPi-Fan]

If memory serves me correctly, I think we forced an amportal restart as part of the boot process in the earlier build. I probably forgot to add it this time around.

Ward,

Thank you for looking into this when you return. I'm curious as to why an amportal restart would be necessary on a freshly booted/rebooted system.

I've also run into another problem with this build. I have the CallerID Lookup module (2.11.1.10 / Schmooze Com Inc) enabled and have the CID Superfecta module (2.11.12 / POSSA) disabled. I get no CallerID lookups anywhere in my CDR Reports. I have OpenCNAM select as the CID Lookup Source in every possible location. The CallerID Lookup module (2.11.1.10 / Schmooze Com Inc) works fine with RasPBX/IncrediblePBX 4.11.4.

 

[wardmundy]

You'll need to contact Schmooze on their module. No idea. It looks like you have three different CallerID modules in play. Can't imagine that would ever work properly. Have you tried removing any two of them?

 

[RPi-Fan]

It looks like you have three different CallerID modules in play. Can't imagine that would ever work properly. Have you tried removing any two of them?

Ward,

The 06/20/14 IncrediblePi image you released has two CallerID modules installed and enabled:

CID Superfecta 2.11.12 POSSA

and

CallerID Lookup 2.11.1.10 Schmooze Com Inc

I disabled the CID Superfecta module, leaving the CallerID Lookup module as the only CallerID source. All Inbound Routes have OpenCNAM selected from the CallerID Lookup module.

Isn't that just a single CallerID module in play?

RasPBX/IncrediblePBX 4.11.4 had only the CallerID Lookup module installed and didn't have the CID Superfecta module installed. IncrediblePi 3.11.10 is configured 100% identically to my RasPBX/IncrediblePBX 4.11.4 installation. IncrediblePi 3.10.11 has no CallerID occurring in the CDR records, whereas RasPBX/IncrediblePBX 4.11.4 works perfectly.

 

[RPi-Fan]

Re: CallerID, did you enable lookups in the Inbound Route?

Yes, OpenCNAM is selected in every Inbound Route.

I have two Raspberry Pi's. I literally copy/pasted EVERY setting from my RasPBX/IncrediblePBX 4.11.4 system to my IncrediblePi 3.10.11 system.

 

[RPi-Fan]

Post the sanitized asterisk full log entries during a failed opencnam lookup.

That will take me a little while since the IncrediblePi 3.10.11 image posted on 06/20/14 does not have the Asterisk Logfiles module installed. Consequently, there are no logs to post at the moment.

 

[RPi-Fan]

After installing the Asterisk Logfiles module, CallerID info began showing up in the CDR's. After disabling and/or uninstalling the Asterisk Logfiles module, CallerID info continues to be displayed in the CDR's. ???

 

[wardmundy]

Well, that was easy.

Maybe it's just me but I sense a bit of frustration with the feature set in some of the posts. Keep in mind that we're attempting to run a full-featured PBX on a dinky SD card with a minimal computing platform to put it charitably. If we turned logs on, for example, your SD card would be toast in no time, either from overuse or from just filling up.

If what you're really after is a full-featured PBX, you'll reduce your frustration level considerably by buying an Atom-based PC or running Incredible PBX in the cloud.

We'll apply some of the fixes documented in this thread next week when we return from our hurricane adventure.

 

[RPi-Fan]

Actually, I find the feature set excellent on the Raspberry Pi. I've been running RasPBX/IncrediblePBX 4.11.4 since January and have been extremely pleased with it. FWIW, 4.11.4 was released last December with the Asterisk Logfiles module installed and enabled. It's been running that way for six months now and the 16 GB SD card has never gotten more than 15% full (an 8GB card runs about 40% full). I actually agree that logging should not be installed by default. Being able to distribute and initially boot from a 4 GB image is a highly desirable goal, but it's unreasonable to consider running an operational IncrediblePi on anything less than an 8 GB card.

I have found it cumbersome trying to move from 4.11.4 to 3.11.10. I had hoped that configuration backups from 4.11.4 could simply be restored to 3.11.10, but that's apparently not possible (the Backup/Restore module in 3.11.10 refuses to restore backup files created by 4.11.4). I have a very elaborate configuration (LOTS of trunks and routes) and it takes a huge amount of time to manually configure it from the ground up.

 

[wardmundy]

It's not just a size issue. It's the constant read/write activity that will lead to problems.

 

[Tiger_Paws]

I have a small notebook hdd mounted /home and /var
to reduce things being written to the chip.
I wish I could find a version of centos that runs
on the Odroid, odroid is faster than the pi.

 

[RPi-Fan]

If memory serves me correctly, I think we forced an amportal restart as part of the boot process in the earlier build. I probably forgot to add it this time around. The other message is harmless. I'll have a look next week when we return to home base.

Ward,

Have you had a chance to look into this?

Thanks

 

[RPi-Fan]

Ward,

Have you had a chance to look into this?

Thanks

Bump

 

[RPi-Fan]

Ward,

I just received update24, but the problem is unchanged and not resolved. Please see the original post.

Thanks.

 

[wardmundy]

You reported that a restart after the initial boot solved the problem. This patch implemented that if you are using one of the last two releases of Incredible PBX for the Raspberry Pi. /etc/pbx/.version will tell you which release you are using. The number of users that have reported this problem is exactly ONE. In the scheme of things, bugs like this take a back seat to lots of other issues... almost all other issues, frankly.

If this is mission critical to you, then the alternative is to hire someone to solve the problem. This is a free product with free support, but that doesn't extend to unlimited problem solving. Sorry.

 

[RPi-Fan]

After IncrediblePi 3.11.10 or 3.11.11 is started (via a cold boot or a shutdown -r now), an amportal restart must be manually issued via an SSH session or the error described in the original post occurs. The error continues to occur until the ampotal restart is issued via an SSH session, at which point everything is solid until the next system boot/reboot. This is still the case after update24 is installed.

The exact same configuration executes without error without an amportal restart after startup with RasPBX/IncrediblePBX 4.11.4. As such, it doesn't seem like this is configuration error on my part.

 

[wardmundy]

If everything works on the RasPBX platform, why move??

 

[RPi-Fan]

If everything works on the RasPBX platform, why move??

http://nerdvittles.com/?p=9702

What’s New in Incredible PBX 3.11.10? Well, just about everything is either new or upgraded. For those of you already running a previous version, here’s a quick thumbnail of the 3.11.10 feature set. As in the past, we’ve tried to mimic as much of the previous build functionality as possible while providing new firmware support for the very latest Raspberry Pi boards. So you still get simple utilities to configure 1GHz overclocking and automatic expansion of the 3.11 image to run on any size SDHC card. You also get Asterisk’s latest long-term support release, Asterisk 11, which provides an incredibly stable VoIP platform. There also have been some major plumbing enhancements in FreePBX 2.11 to improve its stability and to enhance security. Although we can’t promise it will last forever, you also still get Google Voice support with free calling in the U.S. and Canada as well as free faxing and SMS messaging plus most of the Incredible PBX feature set. We’ve also added optional voice transcription and email delivery of MP3 voicemails to smooth the migration to unified messaging.

There’s more good news. Networking is much more stable; however, we’ve dropped support for the TP-Link WiFi adapters. If you still have one of these adapters, see this thread on the PIAF Forum for setup instructions. Otherwise you’ll need the recommended AirLink 101 N-150 if you want WiFi capability. In the 3.11.10 release, your server will automatically attempt to connect to any open WiFi network that it can find. We’ve also added two scripts in /root to let you restart either your wired or wireless network and designate it as the primary network: restart-eth0 and restart-wlan0. Time zone management was also a bit of mess with multiple file settings required to support both Linux and PHP. In this release, you’ll be prompted to select your timezone when you first log in as root. The setup script will automatically apply your entry in all the right places. We’ve also replaced SendMail with Exim to simplify the process of using an SMTP mail gateway such as Gmail.

=====

FWIW, here is the entire piece of code that is failing under 3.11.10 and 3.11.11 until an amportal restart is issued:

extensions_custom.conf

[pgv-out-norwalk]
exten => _X.,1,Set([email protected])
exten => _X.,n,Set(ACCTPASS=secret)
exten => _X.,n,Set(RINGBACK=16315551212)
exten => _X.,n,Set(CALLPARK=78)
exten => _X.,n,Goto(pgv-out-common,${EXTEN},1)

[pgv-out-fairmont]
exten => _X.,1,Set([email protected])
exten => _X.,n,Set(ACCTPASS=secret)
exten => _X.,n,Set(RINGBACK=14245551212)
exten => _X.,n,Set(CALLPARK=77)
exten => _X.,n,Goto(pgv-out-common,${EXTEN},1)

[pgv-out-little-rock]
exten => _X.,1,Set([email protected])
exten => _X.,n,Set(ACCTPASS=secret)
exten => _X.,n,Set(RINGBACK=16465551212)
exten => _X.,n,Set(CALLPARK=76)
exten => _X.,n,Goto(pgv-out-common,${EXTEN},1)

[pgv-out-common]
exten => _X.,1,NoOp(*1*)
exten => _X.,n,System(gvoice -b -e ${ACCTUSER} -p ${ACCTPASS} call ${EXTEN} ${RINGBACK} 1)
exten => _X.,n,NoOp(*2*)
exten => _X.,n,Set(PARKINGEXTEN=${CALLPARK})
exten => _X.,n,Park(15000,pgv-error,s,1,rs)

[pgv-error]
exten => s,1,Playback(silence/1&cannot-complete-as-dialed)
exten => s,n,Wait(1)
exten => s,n,Playtones(congestion)
exten => s,n,Wait(10)
exten => s,n,StopPlaytones
exten => s,n,Hangup()

[pgv-in-norwalk]
exten => s,1,Set(CALLNMBR=15625551212)
exten => s,n,Set(CALLPARK=78)
exten => s,n,Set(EXTENDID=pgv-norwalk)
exten => s,n,Goto(pgv-in-common,s,1)

[pgv-in-fairmont]
exten => s,1,Set(CALLNMBR=6815551212)
exten => s,n,Set(CALLPARK=77)
exten => s,n,Set(EXTENDID=pgv-fairmont)
exten => s,n,Goto(pgv-in-common,s,1)

[pgv-in-little-rock]
exten => s,1,Set(CALLNMBR=15015551212)
exten => s,n,Set(CALLPARK=76)
exten => s,n,Set(EXTENDID=pgv-little-rock)
exten => s,n,Goto(pgv-in-common,s,1)

[pgv-in-common]
exten => s,1,GotoIf($["${CALLERID(number)}"="${CALLNMBR}"]?cb:ic)
exten => s,n(cb),ParkedCall(${CALLPARK})
exten => s,n(ic),Answer()
exten => s,n,Goto(from-trunk,${EXTENDID},1)

I don't believe there's anything controversial there and it's a mystery to me why it functions 100% reliably as long as an amportal restart is issued after the system should already be up and running.

 

[wardmundy]

Wish I knew the answer. Sorry. Could be a newer quirk in a later release of Asterisk or it could be a bug that's crept into FreeePBX or it could be something we've "improved." Who knows??

Remember we're building reliable phone systems so priority #1 should be finding a platform that is reliable AND meets your requirements. If one doesn't work and another one does, that's a no-brainer.