Has anyone tried using an off the shelf PBX such as the Grandstream GS-UCM6104 on the Mesh? Our Emergency Manager is kind of leery of using a Raspberry PI and Asterisk and was looking for a more plug and play solution. We currently are using the Grandstream GXP-1625 phones and have had success dialing direct IP over a small 2 node network, but as the network increases in size then the IP will change dynamically. So we were looking into a PBX solution and none of us are experienced at all with Linux.
Thanks for the help,
Chris N4TNA
Thanks for the help,
Chris N4TNA
Rich
W6ABJ
Chris N4TNA
Chris N4TNA
In the Virginia Beach, VA, area, both KD6FIG and W4NMH run Linksys (Cisco) SPA-9000 pbx's feeding several Polycom phones. These Linksys boxes can be made to network with asterisk switches to form a voip network. However, it could be hard to take two of them and make them redundant to each other.
Don't discount an asterisk running on a raspberry pi, or its cousin, the BeagleBone Black. We ran two of them in a redundant mode at the New York City Marathon last fall and they worked very nicely. If you are thinking about voip networking, asterisk has many more options than a stand-alone appliance: trunk types, number manipulation, number of simultaneous calls, call logging, scripting ability...
If you are looking for voice mail, it is built into asterisk. I'm not sure how the various appliances (SPA-9000 included) support this feature. You may have to have a separate box just for the voice mail.
If you want your telephone pbx to also connect into a radio for remote control and access by telephones, then you want the AllStar asterisk load. It will run on the raspberry pi 2/3, BeagleBone Black, and x86 platforms.
73, Mark, N2MH
Thanks for the advice,
Chris N4TNA
If you want a lean system you can also install Asterisk on a node you use during “panic” situations. If the node has enough free memory it will run fine. Better would be a node with more memory on board like the Airrouter.
In the beginning days of BBHN I had Asterisk running on a WRT54GL for a year without a problem. It did run of a USB-flashdrive I soldered in to the GL. The Airrouter has a USB port build in already.
Only 5 phones connected, but still, it worked without getting even near the maximum CPU load or use up all memory. The UBT’s have newer, better and faster CPU’s so they should run fine.
If you pre-configure the node and use this configuration in emergency situations it saves you time setting all up in the field. Just power it up and your running. No mistakes possible, no problem of lost cables or PI’s and no extra power needed for the PI.
You would have all the benefits of the PBX like voicemail or group conference and all others functions Mark mentioned.
Saves you a PI and a lot of frustrations.
73, Ruud, WE1BTV
ARDEN doesn't put out software files for Asterisk on a Mesh Node so they will be a "compile/obtain yourself" project and move the node sharply into "Unsupported" territory (probably not something you want in this case)
In addition the statement that BBHN ran fine with asterisk on a WRT54* I find a bit imprecise considering in my position as the Lead BBHN Programmer I can state that WRT54's barely ran in their stock condition (the startup times for some of the services was abysmal, 30-60 seconds for the main routing daemon to start in some tests where we have it starting probably in 3-5 seconds). They worked, but the units were a lot closer to the cliff of collapsing than most people realize. Maybe they were not noticeably worse after loading Asterisk on them but they sure were not running fine. (I'll also note the version of Asterisk from BBHN builds was created so long ago that it doesn't have a significant amount of the features current Asterisk does so it consumes significantly less resources. While one might be inclined to run those older versions to save on resources, they have a number of known security vulnerabilities that can take down the Asterisk system making them non viable.
The reason why asterisk ran at all on a BBHN node probably has to do with the mode under which it was running.
In asterisk, you can have the voice payload (RTP) either go through the asterisk code itself or be switched to go directly between the endpoints once the call is set up and answered. If the RTP goes through the asterisk fabric, chances are very good that the BBHN node will run out of gas. If it goes directly between the phones themselves, then asterisk is almost back in its idling condition and will not require much processor.
However, all bets are off if the connection is between phones running two different codecs. The RTP MUST now go through the asterisk fabric for transcoding purposes. Depending on the transcoding effort involved, this may consume more processor resource than is available on the Linksys device. Thus, you have just fallen off the cliff just described by Conrad.
Running foreign code on any node, even AREDN nodes, can be risky. All foreign code takes processor resource away from the node's primary purpose: handling data packets. If you can't handle data packets, then the node is useless. Best to keep all such code on external devices and let the nodes do what they were designed to do.
73, Mark
http://dvswitch.org/files/DIAL/RAT_RC1.tar.gz
Remember their is NO FreePBX with AllStar.
Samethings you can do with ASL:
Full-Duplex
Frequency agile remote base HF/Vhf/Uhf
Echolink and a DMR Gateway
David
KE6UPI
ALS Nodes 2060, 2061, 2062, 2063, 2064, 2080, 2081, 2082, 2083, 2084, 90104
If you are looking for AllStar code that has been under development for several years for the rpi 2/3 and Beagle Bone Black and is stable, go to
http://www.hamvoip.com
There is also a forum on this website just for people running this code.
And, yes, as David alludes, there is no GUI for configuration. Everything is done via a text editor in linux.
However, what is not generally known is that any version of AllStar can also be configured as a pbx supporting phones and trunks. And, with the right configuration, you can cross over from the radio side to the pbx side and vice versa.
Mark
AllStar 40831
Chris N4TNA
Chris N4TNA
Thanks for the help,
Chris N4TNA
Dave and Chris,
That Grandstream box looks interesting. A lot of useful stuff built in already. Looking through the info on the Grandstream site only shows a lot of sip configuration. Looking at other sites on the web reveals that this pbx also supports IAX trunking.
I think you might be hard pressed to find a good radio interface for this system. The big stumbling block looks like it will be providing PTT to the radio and COR from the radio back to the system and putting that under control of a phone. Here's where AllStar will come in handy, especially on a raspberry pi.
Bring up AllStar and radio interface and make it play with your radio. Configure it to have an extension which talks to the radio. Then, build a trunk betwee the Grandstream device and the AllStar device. Let your Grandstream device handle all the telephone extensions and registrations. Inside Grandstream, set up some sort of extension that will automatically go over the trunk to the AllStar box. Once in the AllStar box, the call will then go to the extension that accesses the radio. In theory, this should allow access to the radio from any extension on the Grandstream pbx. A little more programming on AllStar can give your radio access back to the phone system.
What is nice about this approach is that the AllStar device talks to the radio and does only that. You only have to set it up once. After that, all the telephone work is done by Grandstream. A trunk between them ties them together. You could bundle your radio and the AllStar rpi together in a go-kit, link it back to the Grandstream device via Mesh, and have the two physically separated. There's really no need to keep them together.
And, with a little creativity, one can network this whole thing back to a larger voip network if needed.
Chris,
Most phones have a web interface for configuration purposes. They also remember their configuration between power cycles. Thus, the phones generally do not require reprogramming every time they are used. With this in mind, you configure your nodes for the best data network, then plug the phones into a node closest to where you need them. They will find the pbx, register themselves and be immediately available for service. In general, Cisco phones can be an exception to this scenario (maybe others as well). Upon bootup, they go out to a server and retrieve their configuration. Not so for Grandstream and other later generation phones.
73, Mark
So, our setup procedure is:
David
Chris N4TNA
I have just validated using a GrandStream GXP-1625 VOIP phone (about 30 bucks on ebay usd)
and the built-in 2 port ethernet switch that I can hook all three things together for a nice compact go-box
setup that can be setup in a matter of minutes - reference diagram:
The best part of this setup is the Phone can register to the GrandStream UCM for central call
control (perhaps to a well connected EOC/Base) and registration and get an "Extension" in/on the mesh for VOIP calls.
In addition the free GSWave app from GrandStream will allow your iPad/Android/iPhone to register to the same UCM with
the same extension - the neat thing is the GSWave app also does video so you can instantly have video calls
in/on the mesh from device to device. (the loco running AirOS/Part 15 in the above diagram handles all
that connectivity) I like the GXP-1625 since it is low cost AND is multi-line - each line can have an independent
SIP Account - so you could register the phone to another or backup Call control or just let it do IP voip dialing.
Also all firmware updates and "managment" are handled from the UCM so it will auto update and configure.
I have been experimenting with codecs for mesh efficient bit-rates and it seem iLBC is working well - the mesh seems to have a very high jitter
rate and not always the best bandwidth so 16K seems to make it most of the time. The UCM supports all those different codecs right out of the box.
regards,
-David kg5eiu
Chris
N4TNA