PIONEERS Incredible PBX Asterisk-GUI

[wardmundy]

If any of you are feeling that pioneering spirit, Beta 1 awaits. Our primary test bed has been Digital Ocean so we can't vouch for results elsewhere.

Tutorials:

1. See the Nerd Vittles articles: Chapter 1, Chapter 2, and Chapter 3
2. See also the Incredible PBX for Asterisk-GUI thread in Developers Forum

Testing Platform:

64-bit, CentOS 6.5 minimal install

Setup (15-20 min. on Digital Ocean):

1. Create a 512MB droplet with CentOS 6.5-64 bit OS on D.O. (NY3 works great and costs under 1¢ per hour)

cd /root
yum -y install wget
wget http://incrediblepbx.com/incrediblepbx11gui.tar.gz
tar zxvf incrediblepbx11gui.tar.gz
./create-swapfile-DO
./IncrediblePBX11-GUI.sh  # run it twice (first time updates CentOS 6.5 to 6.6 and reboots)

2. When install finishes, review passwords.FAQ and set Apache admin password
3. Use a browser to access the IP address of your server
4. Click on Users tab in the Incredible PBX menu
5. Click on Asterisk-GUI Configuration button
6. Log in as admin:password and IMMEDIATELY change your password
7. Add credentials for Google Voice and other providers in the Incredible PBX Apps tab
8. After you add Google Voice and SIP trunks, restart Asterisk: amportal restart (still works )
9. Other than password and host name mods, don't change default dialplan and trunk setups or you will break
10. Run Incredible Fax installer (incrediblefax11-GUI.sh) in /root, if desired. Accept ALL defaults. Tutorial here.
11. Add new stuff to your heart's delight using Asterisk-GUI

System Design Overview:

There's no longer an interdependence on MySQL. MySQL is only used for a few Incredible PBX apps, but those will be migrated to SQLite3 soon. /etc/asterisk still houses the Asterisk setup. Some of these files get overwritten, but Asterisk-GUI does a remarkable job not stepping on your existing settings. Still a good idea to make a backup of your /etc/asterisk files until more testing is done!! All credentials for default setup are in credentials*.conf. Some of the open source components of FreePBX have been ported over to extensions_additional.conf. All of the Incredible PBX apps have been ported over to extensions_custom.conf and /var/lib/asterisk/agi-bin. When you add new trunks, those will NOT be part of the (enhanced) Incredible PBX setup but they will still work.

SIP configuration is a bit different than traditional FreePBX setup. Anonymous SIP connections are disabled both in Asterisk and in IPtables. The one exception is where you have registered a trunk or extension from some other IP address, e.g. a remote phone connected to your D.O. server. In this case, if your phone is behind a NAT-based firewall, ALL users behind that firewall can make anonymous SIP connections to local (only) extensions on your PBX in the cloud. They cannot make anonymous SIP connections to dial out on one of your outbound trunks! If the contents of your wallet matter, you are well advised not to "improve" this setup. The original Asterisk-GUI setup was insecure in this regard.

WARNING: We have NOT tested anything with analog trunks and cards. Asterisk-GUI provides lots of possibilities here, but we cannot vouch for whether they are safe at this juncture. This was a huge problem on the Grandstream UCM PBX that employed Asterisk-GUI, and we have no way to tell whether they messed up the setup or whether it came that way in Asterisk-GUI. If you connect an analog line, make absolutely sure that you test anonymous SIP connections from a remote site and attempt to dial out through your analog line. If the call doesn't fail, PLEASE LET US ALL KNOW!!

Command Line Utilities:

1. See /root for lots of them
2. And there are some new ones in /usr/local/sbin:

asterisk-start
asterisk-stop
asterisk-restart
asterisk-reload
asterisk-cli

Security:

Incredible PBX for Asterisk-GUI is locked down with TM3 IPtables whitelist that includes:

IP address of your server
IP address of your desktop PC
LAN non-routable IP addresses
Trusted providers IP addresses

Add additional entries with add-ip, add-fqdn, or PortKnocker (see /root/knock.FAQ for credentials)

BUGS:

Please post bugs and suggestions for improvements in this thread.

 

[billsimon]

I got some AWS credit recently so let's see how it works on a t2.small. Launching now.

 

[billsimon]

Asterisk's static http server is slow. Since you're pulling in Apache anyway for display of other content, I configured it to serve Ast-GUI instead of Asterisk. Twice as fast! (maybe more)

Bonus - now we can use SSL too:



And you could undo those javascript redirects to port 80 on the Incredible PBX Additions page.

Here are the changes if interested:

(add to the end of /etc/httpd/conf/httpd.conf)

Alias /static /var/lib/asterisk/static-http
ProxyPass /rawman http://localhost:8088/rawman
ProxyPassReverse /rawman http://localhost:8088/rawman

(change in /etc/asterisk/http.conf)

enablestatic = no

Now that I'm done nitpicking on the serving of the content, I'll get down to actually testing the PBX

 

[wardmundy]

Thanks,billsimon. Great idea at least on normal hardware that has no memory constraints! It'll make me sleep better, too. Unlike Apache, Asterisk's http server hasn't gotten a lot of use/testing over the years.

Also need to run this command to clean up the Incredible PBX menu:

sed -i 's|8088|80/static/config/index.html|' /var/www/html/asterisk-gui.php

SSL is a little more coding but we'll add it to the list.

Can't wait for your SIP ideas.

 

[billsimon]

What sort of SIP ideas are you seeking?

The trunk-based inbound routing is a little different. I like having a single context for inbound calls that come in from known providers, and another context for calls that come from elsewhere. It looks like Ast-GUI strictly ties inbound routes and trunks together.

PS: SSL works for me out-of-the-box using Apache's self-signed cert except for the Incredible PBX Additions page.

 

[wardmundy]

What sort of SIP ideas are you seeking?

The trunk-based inbound routing is a little different. I like having a single context for inbound calls that come in from known providers, and another context for calls that come from elsewhere. It looks like Ast-GUI strictly ties inbound routes and trunks together.

PS: SSL works for me out-of-the-box using Apache's self-signed cert except for the Incredible PBX Additions page.

The Incredible PBX page is what needed cleaning up for SSL.

I think you're right on the trunks and inbound routes. Suggestions on peeling this apart would be most welcome.

 

[wardmundy]

You also were going to look at the CDRs. Not sure I don't like the CSV format. It's a lot easier to import and export. I'm also using it to find the last number called for blacklisting which was one line of bash code. That contrasts with a boatload of code and reading and writing to AstDB in FreePBX just to keep track of this.

 

[billsimon]

Actually I like the CSV CDR. It's working fine and I agree that the format is easier to work with. The only problem is if you use Apache to serve the content, the CDR module presents a pop-up about Asterisk http static not enabled. Comment out lines 316, 317, and 318 of /var/lib/asterisk/static-http/config/js/cdr.js to make the irrelevant warning go away.

 

[wardmundy]

Thanks, billsimon. I've got several flavors of the Incredible PBX Apps page finished. The problem is that one size doesn't fit all, and I want to keep all of the web server options on the table because of the small hardware like the Raspberry Pi and PogoPlug. Not having to run Apache would be a HUGE memory saver. If MySQL were out of the way, there wouldn't be any need for phpMyAdmin either.

The problem is there are things you can do in Apache (even with html) that just don't work right with the Asterisk http server. For example, it was easy enough to build most of the pages where they load in the existing web frame... but not phpMyAdmin, at least when using the Asterisk web server. Then there's the https protocol which is fully implemented in the Linux install but not supported by Asterisk's web server. And, to get it to work with Apache, you've got to imbed a different port if you use the Asterisk http version of the Apps web page.

You mentioned that everything worked except the Incredible PBX Apps page. The reason is because it's the only page that relies on a separate web server on a different port to host all of its content (at least for now). The Asterisk-GUI pages all are manipulated with javascript. At least, that's where I think the problem lies.

Bottom Line: I can get a version of the Apps page that works with Asterisk http server and standard Apache http server. It was easier to create a separate html file to handle secure web access. All the other changes can be managed with sed.

Options: What I may do is put out an Apache version and separate Asterisk http server version for the full-blown machines with CentOS/Scientific Linux and Ubuntu 14.04. And then build a mini-version for the little machines with no Apache, no phpMyAdmin, and modified AsteriDex, ZIP code, and TM4 databases using SQLite3. We'll see how the testing goes.

 

[rossiv]

wardmundy Install completed here in 24 minutes from droplet creation time to the end of the script. Testing some calls and apps now. Will keep you posted.

Edits:

• /root/admin-pw-change doesn't appear to do anything. How do I change the PW for Asteridex, etc? I should read more. Specifically /root/passwords.FAQ.

This script changes your admin password for FreePBX 2.11 access.
 
Enter new admin password (MAKE IT SECURE!!): MyS00perS3cr3tPassw0rd
 
admin password will be changed to: MyS00perS3cr3tPassw0rd
Press ENTER key to continue or Ctrl-C to abort...
ERROR 1146 (42S02) at line 1: Table 'asterisk.ampusers' doesn't exist
 
Done. Use browser to access FreePBX at http://definitely.not.my.ip
 
[root@incred-test ~]#

• Somehow from the Incredible PBX Apps page, I managed to get to http://ip:8088/asteridex4 which 404'd. Can't reproduce it now of course. So on hovering on the links prior to clicking, they have :8088. If you hover, look at the link for about half a second, then click, you get the bad link. If you click without much hover, you get redirected properly.
• Add/Delete works fine as expected in Asteridex.
• OOOH those trunk wizards are fancy. If only they appeared in lightboxes. [VoIP.ms registration worked fine]
• After doing the trunk wizard and reloading, it registered fine. However, I can't see any of the details in the regular Trunks page except for the server hostname and CID number. Normal?
• Weather by City doesn't work. Loops at the "Say the city..after the tone" prompt. Haven't put my API key in yet so that's probably it

 

[wardmundy]

Incredible PBX Apps page is undergoing revision.

Weather by City, Voice Dialing (411), Wolfram Alpha (4747), etc. all require API key from Voice Recognition tutorial in Resources. No other setup is required. Just plug in your key. New tutorial on this will be out on Monday.

 

[rossiv]

Incredible PBX Apps page is undergoing revision.

Weather by City, Voice Dialing (411), Wolfram Alpha (4747), etc. all require API key from Voice Recognition tutorial in Resources. No other setup is required. Just plug in your key. New tutorial on this will be out on Monday.

Yup. I was thinking...wait... I haven't put in my API key yet.
I'm not able to call out through VoIPms, even if I force with the 9 prefix. It is registered fine, and incoming calls work fine.

  == Using SIP RTP CoS mark 5
    -- Executing [9843446xxxx@DLPN_DialPlanMain:1] Set("SIP/6001-00000011", "CALLERID(num)=843235xxxx") in new stack
    -- Executing [9843446xxxx@DLPN_DialPlanMain:2] Macro("SIP/6001-00000011", "trunkdial-failover-0.4,SIP/voipms/843446xxxx,,voipms,") in new stack
    -- Executing [[email protected]:1] Gosub("SIP/6001-00000011", "outgoing-sub,outgoing-sub_1,1()") in new stack
    -- Executing [outgoing-sub_1@outgoing-sub:1] NoOp("SIP/6001-00000011", "*** Calling: 9843446xxxx from "6001" <843235xxxx> ***") in new stack
    -- Executing [outgoing-sub_1@outgoing-sub:2] NoOp("SIP/6001-00000011", "SIPDOMAIN=104.236.x.x") in new stack
    -- Executing [outgoing-sub_1@outgoing-sub:3] Set("SIP/6001-00000011", "FROM_IP=104.236.x.x:5060") in new stack
    -- Executing [outgoing-sub_1@outgoing-sub:4] GotoIf("SIP/6001-00000011", "1?hangup,1") in new stack
    -- Goto (outgoing-sub,hangup,1)
    -- Executing [hangup@outgoing-sub:1] Hangup("SIP/6001-00000011", "") in new stack
  == Spawn extension (outgoing-sub, hangup, 1) exited non-zero on 'SIP/6001-00000011' in macro 'trunkdial-failover-0.4'
  == Spawn extension (outgoing-sub, hangup, 1) exited non-zero on 'SIP/6001-00000011'
incred-test*CLI>

 

[wardmundy]

rossiv: Are the SIPDOMAIN and FROM_IP addresses the same when you attempt the outbound call?? If so, it looks like I need to trim the FROM_IP entry of :5060 so they match. Otherwise, the calls will be blocked. The required match is to prevent anonymous SIP attempts using your server to make "free" calls.

UPDATE: That WAS the problem. Here's the fix. Search for SIP_HEADER (several places) in extensions_custom.conf and replace Set code with this entry. Then reload dialplan.

Set(FROM_IP=${CUT(CUT(CUT(SIP_HEADER(From),>,1),@,2),:,1)})

This will NOT fix all of the places it appears, but it will get you going with the default trunks. Just don't add any that aren't in the Incredible 9 without downloading a newer build after 7:30 a.m. EST today. admin-pw-change also has been updated in new build. More to do. Back into the weeds we go...

 

[wardmundy]

We've successfully exported the ZIP Codes database from MySQL to SQLite3. Database includes city, county, and state info as well as latitude and longitude data. I thought this might be useful for some of you on other projects as well. A sample query is included in the ZIP Codes tarball. To use the database and run queries, your server obviously has to have SQLite3 installed as all PIAF and Incredible PBX servers do.

Dialing Z-I-P on phones with a new build from 12-14-14 after 3 pm EST uses the SQLite3 ZIP code database instead of MySQL. It's as fast or faster than MySQL.

Other helpful SQLite3 commands to get you started:

sqlite3 zipcodes.sqlite3 '.tables'
sqlite3 zipcodes.sqlite3 '.schema zipcodes'
sqlite3 -separator ' ' zipcodes.sqlite3 'SELECT city,fullstate,zip FROM zipcodes where zip=90210'
sqlite3 -separator ' ' zipcodes.sqlite3 'SELECT city,fullstate,zip,latitude,longitude FROM zipcodes where zip=90210'
sqlite3 -separator ' ' zipcodes.sqlite3 'SELECT city,fullstate,zip,latitude,longitude,county FROM zipcodes where zip=30327'

And here's the full schema:

CREATE TABLE "zipcodes" (
  "id" mediumint(6) NOT NULL ,
  "zip" varchar(5) NOT NULL DEFAULT '',
  "latitude" varchar(11) NOT NULL DEFAULT '',
  "longitude" varchar(11) NOT NULL DEFAULT '',
  "city" varchar(40) NOT NULL DEFAULT '',
  "state" char(2) NOT NULL DEFAULT '',
  "fullstate" varchar(30) NOT NULL DEFAULT '',
  "county" varchar(40) NOT NULL DEFAULT '',
  "zipclass" varchar(20) NOT NULL DEFAULT '',
  PRIMARY KEY ("id")
);
CREATE INDEX "zipcodes_city" ON "zipcodes" ("city","state");
CREATE INDEX "zipcodes_state" ON "zipcodes" ("state","city");
CREATE INDEX "zipcodes_zip" ON "zipcodes" ("zip");

p.s. zipclass tells you if a ZIP code is UNIQUE (as opposed to STANDARD), meaning you don't need a street address for delivery.

 

[billsimon]

rossiv: Are the SIPDOMAIN and FROM_IP addresses the same when you attempt the outbound call?? If so, it looks like I need to trim the FROM_IP entry of :5060 so they match. Otherwise, the calls will be blocked. The required match is to prevent anonymous SIP attempts using your server to make "free" calls.

I'm unclear on how the system would be exploited given the way contexts are set up (separate inbound and outbound calling contexts) and requiring endpoints to authenticate. Could you further explain your findings?

 

[rossiv]

rossiv: Are the SIPDOMAIN and FROM_IP addresses the same when you attempt the outbound call?? If so, it looks like I need to trim the FROM_IP entry of :5060 so they match. Otherwise, the calls will be blocked. The required match is to prevent anonymous SIP attempts using your server to make "free" calls.

UPDATE: That WAS the problem. Here's the fix. Search for SIP_HEADER (several places) in extensions_custom.conf and replace Set code with this entry. Then reload dialplan.

Set(FROM_IP=${CUT(CUT(CUT(SIP_HEADER(From),>,1),@,2),:,1)})

This will NOT fix all of the places it appears, but it will get you going with the default trunks. Just don't add any that aren't in the Incredible 9 without downloading a newer build after 7:30 a.m. EST today. admin-pw-change also has been updated in new build. More to do. Back into the weeds we go...

I see you figured it out now, but yes the SIPDOMAIN and FROM_IP were both the IP of the DigitalOcean droplet, not my local public IP though which is interesting. Your change worked though.

 

[wardmundy]

rossiv: It's just a simple string comparison for a match and one had :5060 on the end of it so there was no match. Hence, no call.

billsimon: In our testing, what we observed went like this. Server hosted in the cloud. Softphone registered to extension from behind a NAT-based router on the other side of the country. That registration reflects the public IP address of the NAT-based router which would be correct. From another machine on the same private LAN, I could successfully make a SIP call in the form SIP/8435551212@serverIP. It would hit the server, and Asterisk would process the call using the default trunk matching NXXNXXXXXX for outbound calls. It didn't consider it an anonymous call because an extension was registered to that IP address. Once I disconnected/unregistered the softphone, the calls failed.

This was similar to a pattern I observed on the Grandstream PBX (which uses Asterisk-GUI with mods). Their situation was worse (and I recently got another report of the same thing) because an anonymous SIP call could be sent to the PBX from any IP address, and it would route it out through one of the analog trunks matching the dial string in the anonymous SIP packet. That really was a nightmare!

 

[billsimon]

Here is the reason:

By setting insecure = very (or port,invite which is how it appears in the users.conf file) you are instructing Asterisk not to authenticate calls from this user. So when it sees invites from the registered IP address (no matter what source port it comes from or whether an auth string is sent), it accepts them.

Setting insecure=port,invite is helpful on trunks because the providers don't authenticate back to our PBX (usually--maybe there are some that do, but I have not worked with them). But for an endpoint this should NEVER be set!

 

[wardmundy]

WOW. Thanks, billsimon. Fixed! Must've been a late night. I think I'd built all those trunks and had a little brain gas when I got to the extensions. Glad you found it. I think I'll leave the error checking in place just to catch someone (like me) that checks the box for fun.

 

[wardmundy]

A side benefit of leaving the error checking in place is that we could actually put this to good use. Consider the situation where there's a cloud-based server and several branch offices. By connecting the branch offices to the server with any extension using the insecure=very setting, it would now allow everybody in those branch offices to make anonymous SIP calls to everybody else inside the company. While we allow dialing of local extensions via anonymous SIP, we block anonymous calls to numbers outside the PBX. This could be programmed into many "public" SIP phones that support SIP URI dialing without actually having to register these extensions to the PBX at all. In other words, users of these phones could call pre-programmed extensions within the company without actually allowing the phones to receive incoming calls.