We’ve spent the last couple months perfecting Incredible PBX™ as a full-featured VoIP platform for deployment on the $35 Raspberry Pi®. And, with the recent addition of 512MB RAM on the main system board, the Raspberry Pi not only is a great platform for home or SOHO use, but now it’s an ideal server for remote deployment in organizations with small satellite offices scattered around the countryside or for those with a loved one stationed in a faraway place. It’s especially important for those that want to take advantage of free interoffice communications or perhaps low-cost communications facilities that are only available through the main office headquarters. Our project for today is to show you how easy it is to interconnect these satellite offices, traveling salesmen, and troops stationed on the other side of the globe to provide system-wide, transparent Asterisk® communications at no cost. Using Raspberry Pi devices for the remote office or employee, you can set this up with FreePBX® in less than 5 minutes per site! Once configured, everyone in the organization can call everyone else by simply dialing their extension or a prefix with the local extension number. And finally we’ll show you how to securely share communications trunks at one site with your other locations.

There’s a little advance planning that needs to take place before you actually deploy today’s setup. First, you’ll need to adjust your hardware-based firewalls at each location to allow communications between the various sites. You’ll also need to authorize SIP access for each site in the Linux iptables firewalls. If some or all of the remote sites have dynamic IP addresses, then you’ll either need to deploy a PPTP VPN for your servers or use a service such as DynDNS.com to create fully-qualified domain names for each site. Dynamic IP addresses can be kept current at each site using a dynamic update app such as ddclient. And ipchecker can be run periodically to update IP address changes in iptables. Both apps are available for Incredible PBX on the Raspberry Pi. Finally, some thought needs to go into the extension numbering scheme at each site. The simplest way to is reserve extensions in the 1000 range for the home office, 2000-2999 for office #2, etc. If your organization already has an existing numbering system, then Plan B is to devise a dialing prefix that can be used to access extensions at various sites. For example, you might dial 1-2345 to reach extension 2345 in the main office or 2-2345 to reach extension 2345 in office 2 and so on. Either way works, and Asterisk with FreePBX supports both dialing schemes.

Hardware-Based Firewall Setup. For each site to which you wish to interconnect, you’ll need to add an entry to your hardware-based firewall using the FQDN or IP address of the site with the following ports mapped to your Asterisk server at that site: UDP 5060 and UDP 10000-20000.

IPtables Configuration and Dynamic IP Address Setup. If you have one or more sites whose servers have dynamic IP addresses, then you’ll need fully-qualified domain names for those sites that can be kept current using ddclient on the remote server and ipchecker on the main server. For background, start by reading the Nerd Vittles article on Travelin’ Man 3. You’ll need to deploy this on your main server. It’s already incorporated into the Incredible PBX builds for PBX in a Flash and the Raspberry Pi.

You’ll first need a DynDNS account. For $20 a year, you can set up 30 FQDNs and keep the IP addresses for these hostnames current 24-7. For $30 a year, you can manage 75 hostnames using your own domain and execute up to 600,000 queries a month. That’s more than ample for almost any small business but, if you need more horsepower, DynDNS.com can handle it.

Our Travelin’ Man 3 article will walk you through the steps in setting up iptables entries for your new FQDNs on your main server. On the Raspberry Pi devices, you’ll need to install ddclient: apt-get install ddclient. The installer will walk you through the setup process to keep your dynamic IP addresses synced with your FQDN. You’ll also need to add iptables entries for your main site and any other sites to which you wish to directly connect. In the /root folder, you’ll find scripts to add-fqdn or add-ip entries to iptables. The setup is covered in detail in the Travelin’ Man 3 article so we won’t repeat it here.

Interconnecting Servers with SIP Trunks. For our example today, we’re going to simplify things a bit and show how to interconnect a Main server and a Remote server where both servers are on the same private LAN. The only difference from real life is that you typically would use the public IP addresses of both servers when they are housed in different locations and accessible via the Internet. To avoid the hassle of wrestling with dynamic IP addresses and for added security and encrypted communications, you can interconnect your servers using a PPTP VPN. It’s included in Incredible PBX on all platforms. In configuring your SIP trunks, just substitute the PPTP IP addresses of each server in lieu of public IP addresses. Then you don’t have to worry about dynamic IP addressing issues. And, to add support for additional remote servers, just create separate SIP trunk pairs at the Main and Remote sites with a naming scheme like this: Main1 and Remote1 for adding the first remote site, Main2 and Remote2 for adding the second one, and so on.

Adding a Remote SIP Trunk on Your Main Server. Let’s begin by adding a SIP trunk to your Main Server to support the Remote Raspberry Pi device. We’ll refer to the Remote SIP trunk as remote for our example. Using FreePBX 2.10, choose Connectivity -> Trunks -> Add SIP Trunk. Make up a very secure password to interconnect your two servers. We’ll use it as the secret at both ends. Then fill out the template using the example below. In the Registration String, use the actual IP address or FQDN of your remote server:

Adding the Main SIP Trunk to Your Remote Server. On your Remote Server using FreePBX 2.10, choose Connectivity -> Trunks -> Add SIP Trunk. Use the same password as the secret you set up on the main server. Then fill out the template using the example below. In the Registration String, use the IP address or FQDN of your main server:

Adding an Outbound Route from Remote Server to Main Server. To allow calls from the Remote Server to your Main Server, we’ll create an Outbound Route on the Remote Server: main-out. In FreePBX 2.10, choose Connectivity -> Outbound Routes -> Add Route. For our example, let’s assume that we want Remote users to dial 9 as a prefix to connect back to extensions on the Main server. And let’s also assume that all extensions on the Main server are either three or four digits long. Just fill out the template using the example below and, for Trunk Sequence 0, choose main from the pull-down list. If you wanted to allow Remote users to place calls using the Outbound U.S./Canada trunks available on the Main server, just add an additional Dial Pattern with 9 as the prefix and NXXNXXXXXX as the Match.

Adding an Outbound Route from Main Server to Remote Server. To set up something similar on the Main Server to allow users to make calls to the Remote Server, you’d create an Outbound Route similar to the one above. Call it remote-out. Use whatever dial prefix you’d like and make the rest of the Dial Pattern match the length of the extension numbers at the Remote site. Then choose remote as Trunk Sequence 0 from the pull-down list.

Congratulations! You now have unlimited free calling between all of the extensions registered to your two servers, regardless of where those servers happen to be located. You can follow your nose to add as many additional servers as you like. So long as there is a reliable Internet connection, your total, non-recurring cost to add each additional site is a $35 Raspberry Pi and a few accessories. Got a family member stationed in Afghanistan? Send them a Raspberry Pi with Incredible PBX for Christmas. They not only can call you, but they can make calls to anyone else using your outbound trunks without incurring any toll charges for the communications link between Afghanistan and your server. Enjoy!

Security ALERT! For those running Incredible PBX on the Raspberry Pi, there have been some security patches released in the last few days. First, be sure you’re running Incredible PBX 3.5. Second, log into your server as root and issue the following command: /root/update-my-pi. Done.

whos.amung.us If you’re wondering what your fellow man is reading on Nerd Vittles these days, wonder no more. Visit our new whos.amung.us statistical web site and check out what’s happening. It’s a terrific resource both for us and for you.
Awesome Vitelity Special. Vitelity has generously offered a terrific discount for Nerd Vittles readers. You now can get an almost half-price DID from our special Vitelity sign-up link. If you’re seeking the best flexibility in choosing an area code and phone number plus the lowest entry level pricing plus high quality calls, then Vitelity is the hands-down winner. Vitelity provides Tier A DID inbound service in over 3,000 rate centers throughout the US and Canada. When you use our special link to sign up, Nerd Vittles gets a few shekels down the road to support our open source development efforts while you get an incredible signup deal as well. The going rate for Vitelity’s DID service is $7.95 a month which includes up to 4,000 incoming minutes on two simultaneous channels with terminations priced at 1.45¢ per minute. Not any more! For our users, here’s a deal you can’t (and shouldn’t) refuse! Sign up now, and you can purchase a Tier A DID with unlimited incoming calls and four simultaneous channels for just $3.99 a month. To check availability of local numbers and tiers of service from Vitelity, click here. NOTE: You can only use the Nerd Vittles sign-up link to order your DIDs, or you won’t get the special pricing! Vitelity’s rate is just 1.44¢ per minute for outbound calls in the U.S. There is a $35 prepay when you sign up. This covers future usage. Any balance is refundable if you decide to discontinue service with Vitelity.

​​3CX is a software PBX that’s easy to install & manage. It includes integrated softphones, WebRTC conferencing and essential add-ons out of the box, at no additional cost. Try the free edition at www.3cx.com. Better yet, download the PIAF5 ISO powered by 3CX. Free version includes support for 8 simultaneous calls with a SIP trunk.

This article has 8 comments

What is the case for doing this rather than having sip phones in the remote office register directly with the main office PBX? Especially if we’re speaking of a home office of a single telecommuter?

I can think of a few things. Better use of bandwidth, with calls within each location not using the internet connection. Better fault tolerance, with a main office outage leaving remote offices still up. Smaller burden on main office PBX. Remote office PBX can choose nearest sip trunk provider for outside calls rather than an extra hop through main office pbx.

Forgive me if this is a newbie question but is there a reason not to interconnect both with Hamachi or Neorouter and register remote phones via the server they are on a LAN with (due to no mobile client on Hamachi for instance) ?

Like Grey One above, I also would like to know why in the Pi article regarding the VPN setup you talk about PPTP VPN and not NeoRouter VPN which I understand had been added to PIAF installs?

I was away from PIAF scene for the last year so I am not sure if in the meantime the NeoRouter VPN fell into disfavor like Hamachi did previously?

Can anyone comment?

[WM: We still love NeoRouter. They were just late to the Raspberry Pi party. The PIAF Forum has lots of information about the Raspberry Pi implementation, and we intend to cover it in a future article.]

What is this the best way to setup two servers when you need to share the Digium contacts? I did this and now have a “main” & “remote” server setup so that I can register a SIP trunk through Callcentric at my remote site (to improve call quality there) but in doing that users from the “main” site do not see the Digium contacts at the “remote” and users at the “remote” site can’t see contacts at the “main” site. Is there a configuration example or tutorial for sharing contacts or directories between servers when they are connected this way?