It’s been quite a week with the surprise acquisition of Digium® and Asterisk® by Sangoma®. It became official on Wednesday, September 5. You can read all about it here, and you can read our cautious optimism here. As with the recent Google Voice transformation, we hope it serves as a gentle reminder to the VoIP community not to put all your eggs in one basket. With the start of the new school year, we could think of no better time to explore an excellent alternative. And today we’re pleased to introduce FusionPBX™ for FreeSwitch™.

9/10 EDIT: We’ll be updating this article in coming days to add tutorials on additional features rather than releasing new articles that force you to jump around. So mark your place at the end of the article and come back soon to see the new additions.

FreeSWITCH is an open source softswitch that’s been around for over a decade. The lead designer is Anthony Minessale, who originally worked on the Asterisk project. FusionPBX is a GUI front end for FreeSWITCH that performs many of the same functions that FreePBX® performs for Asterisk. It’s the brainchild of Mark J. Crane. With that background, let’s dive right in.

Today we’ll get a functioning server set up with trunks and extensions so that you can begin making calls. We’ll also show you how to interconnect with an Incredible PBX server in the Cloud to add Google Voice GVSIP functionality for free calling in the U.S. and Canada. Once you get that far, we’d recommend you pick up a good book on FreeSWITCH, review the excellent FusionPBX documentation, and roll up your sleeves. There’s virtually nothing that FusionPBX and FreeSWITCH can’t do with a telephone.

Creating the Debian 8 Minimal Platform

We’ll be building FusionPBX atop a minimal install of Debian 8 (Jessie). If you’re creating your server in the Cloud with 1GB or less of RAM (such as the $3.50/month Vultr platform), we strongly recommend creation of a swap file after you set up the Debian 8 platform:

dd if=/dev/zero of=/swapfile bs=1024 count=1024k
chown root:root /swapfile
chmod 0600 /swapfile
mkswap /swapfile
swapon /swapfile
echo "/swapfile          swap            swap    defaults        0 0" >> /etc/fstab
sysctl vm.swappiness=10
echo vm.swappiness=10 >> /etc/sysctl.conf
free -h
cat /proc/sys/vm/swappiness

Next, create a very secure root password: passwd

Now put the missing pieces in place to support your FusionPBX install:

apt-get update
apt-get upgrade
apt-get install nano -y
apt-get install dialog -y
apt-get install ca-certificates -y
apt-get install systemd -y
apt-get install systemd-sysv -y
reboot

Installing FusionPBX and FreeSWITCH

Now we’re ready to install FusionPBX with FreeSWITCH. Issue the following command on a single line. Be advised that FusionPBX currently uses FreeSWITCH 1.6, not 1.8. If you buy a book about FreeSWITCH 1.8, just be aware that there may be some features that are not yet available with FusionPBX.

wget -O - https://raw.githubusercontent.com/fusionpbx/fusionpbx-install.sh/master/debian/pre-install.sh | sh; cd /usr/src/fusionpbx-install.sh/debian && ./install.sh

When the install completes, you’ll see a message that looks something like this:

Installation has completed.

   Use a web browser to login.
      domain name: https://45.76.249.125
      username: admin*
      password: D6pHudQGqeYsQUWK

   *The browser domain name is used as part of the authentication.

   If you need to login to a different domain then use username@domain.
      username: admin@45.76.249.125

   Official FusionPBX Training
      Fastest way to learn FusionPBX: https://www.fusionpbx.com.
      Available online and in person. Includes documentation and recording.

      Location:               Online
      Admin Training:          7 -  9 August 2018 (3 Days)
      Advanced Training:      21 - 22 August 2018 (2 Days)
      Continuing Education:        30 August 2018 (1 Day)
      Timezone:               https://www.timeanddate.com/weather/usa/boise

   Additional information.
      https://fusionpbx.com/training.php
      https://fusionpbx.com/support.php
      https://www.fusionpbx.com
      http://docs.fusionpbx.com

If you’re coming from the FreePBX world and you’re new to FusionPBX and FreeSWITCH, be advised that your browser login name is NOT admin. It’s admin@some-IP-address. The reason is because FreeSWITCH supports multiple domains, unlike FreePBX. The default domain will be the IP address from which you performed the installation. On a server in the cloud, it will be your public IP address. On a private LAN, it will be the localhost private IP address, e.g. 127.0.0.1 or 127.0.0.2.

Locking Down Your Server

FusionPBX includes a basic IPtables firewall setup. Those that have followed Nerd Vittles over the years know that we view a firewall whitelist (Travelin’ Man 3) as absolutely essential to avoid security problems down the road. In the case of FusionPBX, we recommend changing the SSH access port from 22 to a random number above 1000. Then it can remain exposed so long as you check regularly to make certain no one is attempting to access your server via SSH: cat /var/log/auth.log. We also recommend locking down HTTP and HTTPS to your whitelisted IP addresses rather than leaving those ports open to the world. Finally, we recommend closing off IPv6 access to your server except from localhost. Here’s how.

Let’s assume you want to change the SSH access port from 22 to 1789. Simply issue the following commands and restart SSH. WARNING: Be careful not to log out of your server until we update the firewall, or you will lock yourself out of your server!

sed -i 's|#Port 22|Port 22|'  /etc/ssh/sshd_config
sed -i 's|Port 22|Port 1789|' /etc/ssh/sshd_config
/etc/init.d/ssh restart

To reconfigure IPtables using a WhiteList of allowed IP addresses, you first need to decipher what those IP addresses actually are. You’ll need the public and private IP addresses of any PCs from which you wish to access FusionPBX. Depending upon your pain threshold and bank account, SIP access can remain open. However, you’ll still need the IP addresses of your hosting providers and the IP addresses of each of the locations where you plan to install a SIP phone for direct access to properly configure FusionPBX. Once you have those IP addresses in hand, it’s time to edit /etc/iptables/rules.v4. The filter section of the default install looks like:

*filter
:INPUT DROP [1:40]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [58:8069]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m udp --dport 5060:5091 -m string --string "friendly-scanner" --algo bm --to 65535 -j DROP
-A INPUT -p udp -m udp --dport 5060:5091 -m string --string "sipcli/" --algo bm --to 65535 -j DROP
-A INPUT -p udp -m udp --dport 5060:5091 -m string --string "VaxSIPUserAgent/" --algo bm --to 65535 -j DROP
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 7443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5060:5091 -j ACCEPT
-A INPUT -p udp -m udp --dport 5060:5091 -j ACCEPT
-A INPUT -p udp -m udp --dport 16384:32768 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
COMMIT

1. Modify the SSH rule (–dport 22) replacing 22 with your new SSH port number, e.g. 1789.

2. Using #, comment out the HTTP (–dport 80) and HTTPS (–dport 443) rules. There simply are too many zero day vulnerabilities with PHP and SQL injection to leave web ports exposed to the public.

3. Just above the COMMIT line, whitelist your private LAN IP addresses. Do NOT whitelist the 172 subnet if you’re deploying on Amazon! Amazon treats these as routable IP addresses on their network.

-A INPUT -s 127.0.0.0/8 -j ACCEPT
-A INPUT -s 10.0.0.0/8 -j ACCEPT
-A INPUT -s 172.16.0.0/12 -j ACCEPT
-A INPUT -s 192.168.0.0/16 -j ACCEPT

4. If you’re planning to use NeoRouter VPN, add the following above the COMMIT line:

-A INPUT -p tcp -m tcp --dport 32976 -j ACCEPT

5. Add rules above the COMMIT line for each IP address you wish to WhiteList, e.g.

-A INPUT -s 8.8.8.8 -j ACCEPT

6. Save the file.

7. Edit /etc/iptables/rules.v6 to look like this:

*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -s ::1 -j ACCEPT
COMMIT

8. Restart IPtables and Fail2Ban:

/etc/init.d/netfilter-persistent restart
/etc/init.d/fail2ban restart
iptables -nL
ip6tables -nL

9. If your server is on the public Internet and you’d like to add SSL security, which is required for WebRTC deployments, we’re adding a separate tutorial below as part of the WebRTC implementation to show you the easy way to do this. Keep reading.

Finally, a cautionary note. If you leave your SIP ports exposed to the Internet, then you’ll need to regularly monitor your FreeSWITCH log for attempted attacks. You can download the Incredible Utilities scripts including update-blacklist that we run regularly as a cron job to blacklist all of the most recent bad guys. Please note that IP addresses detected as "bad guys" with this script take precedence over whitelist entries you may have made in step #5 above so be sure to also add the IP addresses from step #5 to this script’s WHITELIST table before running the script, or you may inadvertently lock yourself out of your own server.

cd /
wget http://incrediblepbx.com/freeswitch/incredible-utils-FS.tar.gz
tar zxvf incredible-utils-FS.tar.gz
rm -f incredible-utils-FS.tar.gz

Getting Started with FusionPBX

Using the account credentials displayed after your installation completed, login to FusionPBX using your favorite browser. Don’t forget to include the IP address in the admin field:


Before you do anything else, navigate to Advanced -> Access Controls. Here you will want to whitelist all of the IP addresses of SIP service providers and other PBXs to which you want to interconnect. Simply add Allow entries in the Domains category for each IP address/CIDR entry. HINT: Single IP addresses have a CIDR entry of /32. WARNING: We don’t recommend using FQDN/Domain entries. Despite legitimate FQDNs, all of our entry attempts resulted in "cannot locate" alerts in the FreeSWITCH CLI (fs_cli). This means that future connection attempts from those providers would fail without any indication of what caused the failures. Also, do NOT add entries for IP addresses of phones/softphones that will register to extensions or calls to and from those extensions will fail. This is anything but intuitive but, trust us, you will save hours of hair-pulling.

Creating Extensions in FusionPBX

While you’re still logged into the FusionPBX GUI, let’s add an extension to demonstrate how easy it is. Choose Accounts -> Extensions and click on the + symbol to add a new extension. Here is a sample to get you started, but you really only need the extension number and voicemail PIN entries:



Unlike in FreePBX, the default extension password is not displayed on the template. Once you SAVE the extension, you then have to edit it and click on the Password field to display the default entry. This can be changed, if desired.

Configuring a Softphone for FusionPBX

You can connect virtually any kind of telephone to your new PBX, and FusionPBX includes terrific provisioning tools for dozens of SIP phones. We’ll start with a free SIP softphone today so you can begin making calls. You can find dozens of recommendations for hardware-based SIP phones both on Nerd Vittles and the PIAF Forum when you’re ready to get serious about VoIP telephony.

We recommend YateClient which is free. Download it from here. Run YateClient once you’ve installed it and enter the credentials for the extension you created above. You’ll need the IP address of your server plus your extension’s password. Fill in the Yate Client template using the IP address of your Server, the extension number for your Username, and whatever Password you assigned to the extension when you created it. Click OK to save your entries.

Once the Yate softphone shows that it has registered with FusionPBX, try a test call by dialing *9664 which should begin playing the default Music on Hold.

Creating Trunks/Providers/Gateways in FusionPBX

In FusionPBX and FreeSWITCH, what FreePBX and Asterisk users call Trunks are referred to as Providers or Gateways. These are commercial outfits that offer to interconnect your PBX with the rest of the telephones in the world using a SIP connection. The first step is to register with the providers of your choice and obtain your SIP credentials and the FQDN(s) of the provider’s servers to which you should register. Most allow authentication by either username/password or by IP address. If you have a static IP address for your server, that is the safer method since you don’t have to worry about someone guessing your password. The only difference in the setup is the Register field should be changed to False.

As luck would have it, there is thorough documentation on the FreeSWITCH site to configure literally hundreds of Providers. Here’s the link.

Before you actually set up your new Provider in FusionPBX, we first need to add the provider’s server to FusionPBX’s Access Control List (ACL). As noted, we’ve encountered problems attempting to register FQDNs in the ACL so we strongly recommend you ping the FQDN of your provider’s server and obtain its actual IP address. Once you have it, navigate to Advanced -> Access Controls -> domains. Click on the Pencil icon to edit the ACL list for domains. Next, click on the + icon at the top of the Nodes listing. Change Type to allow. Enter the IP address of your provider’s server in CIDR. Leave the Domain field blank. Enter your Provider in the Description field. Click the SAVE button.

Now we’re ready to add your Provider. Navigate to Accounts -> Gateways and click the + symbol to add a new one. Click on the Advanced button to expose all of the available fields. Now find your provider in the FreeSWITCH listing and copy the sample entries using your own credentials to the appropriate fields in the FusionPBX template. SAVE your settings when you’re finished. If you chose username/password authentication with Register=True, then your new gateway’s Status should display as Running with a State of REGED.

If you want to take advantage of free calling in the U.S. and Canada using Google Voice, then you’ll need to interconnect your FusionPBX server with an Incredible PBX GVSIP gateway as described in this Nerd Vittles article. On the FusionPBX side, the first step is to add the IP address of the Incredible PBX GVSIP gateway to the ACL (as described above). Next, assuming you followed the tutorial and created a trunk on the Incredible PBX server named FusionPBX in step #2, here’s what the corresponding Gateway should look like on the FusionPBX side:

Gateway: GVSIP-Host
Username: FusionPBX
Password: same as on GVSIP-Host
From User: FusionPBX
From Domain: FusionPBX
Realm: IP address of GVSIP-Host
Expire Seconds: 90
Register: True
Retry Seconds: 30
Auth Username (in Advanced): FusionPBX
Domain: default setting
Context: Public
Profile: external
Description: GVSIP-Host

Be advised that you still need to WhiteList the IP addresses of the two servers on the corresponding sites using IPtables. And you need to whitelist the public IP addresses even if you choose to register the trunk using private VPN addresses. The reason is because FreeSwitch uses the public IP addresses internally, and the registration will fail without the whitelist entries.

Creating Inbound Routes in FusionPBX

As with all PBXs, Inbound Routes define how incoming calls from Trunks/Gateways are routed to destinations on your PBX. Creating inbound routes in FusionPBX (Dialplan -> Inbound Routes) is much the same as the process with FreePBX except the search Conditions are considerably broader than merely a DID or CallerID match and may include Time Conditions to accommodate after-hours calling:



As with FreePBX, the Action can be any destination available on your PBX including an extension, voicemail, company directory, or an IVR:



Typically, inbound calls should be routed to the public Context. And, unlike FreePBX where the first matching inbound route wins, with FusionPBX, you can prioritize the routes numerically to assign a certain search Order.



Creating Outbound Routes in FusionPBX

Outbound Routes tell your PBX how to route calls to destinations outside your PBX using Trunks/Gateways available on your PBX. Creating outbound routes in FusionPBX (Dialplan -> Outbound Routes) is equally flexible offering virtually limitless combinations to assist PBX designers in setting up scenarios for processing outbound calls. As with inbound routes, outbound routes can be prioritized by assigning an Order. And each outbound route can include a primary Gateway as well as up to two Alternates for routing the calls.



Unlike FreePBX which used NXXNXXXXXX and similar combinations as Dialplan Expressions, FusionPBX uses more powerful RegEx coding with many predefined options:



Choosing Providers for FusionPBX

Here’s a shameless plug for our Platinum Sponsor, Vitelity, if you’re looking for an incredible deal on a DID with unlimited inbound calling. You’ll find the offer at the end of this article. If dirt-cheap outbound calls are of interest and Google Voice isn’t an option where you’re calling from or to, then you can’t beat Anveo Direct. The AnveoDirect provider setup for FusionPBX isn’t included in the link we posted above, but it couldn’t be simpler.



To make outbound calls with Anveo Direct, you dial a number with the country code preceded by a special 6-character code starting with 0 which you create on the Anveo Direct web site. You also must whitelist the IP address of your PBX as part of the setup on the Anveo side. Once configured, a call to a number in the U.S. would look like this: 04He9x18005551212@sbc.anveo.com. When creating the Outbound Route for 10-digit dialing using the tutorial above, the AnveoDirect setup would define the Dialplan Expression as 10-digit dialing with a Prefix of 04HE9x1 assuming your 6-character secret code was 04He9x. The trailing 1 in the Prefix converts the 10-digit dialed number to 11-digits as required by Anveo’s international dial code requirement. We think you’ll like their pricing:



Using Gmail as SMTP Smarthost with FusionPBX

Be sure to test sending an email to yourself from the command line to be sure Exim is working properly. Here’s how:

echo "test" | mail -s testmessage yourname@yourmailserver.com

If you don’t receive the email, be advised that many providers block downstream SMTP mail servers in which case you may want to use your Gmail account as an SMTP Smarthost with FusionPBX. Here’s how. Begin by reconfiguring Exim: dpkg-reconfigure exim4-config

  • Type Mail Server: Mail sent by smarthost using SMTP
  • System Mail Name: Your server’s FQDN (see /etc/hostname)
  • Allowed Senders: accept defaults
  • Other Destinations: accept default
  • Relay Mail: leave blank
  • Outgoing SmartHost: smtp.gmail.com::587 (note the double colons)
  • Hide local name: no
  • Keep DNS-queries minimal: no
  • Delivery method local mail: Maildir format in home directory
  • Split config into small files: no
  • Root and Postmaster recipient: root

After exim4 restarts, add the following entries to the end of /etc/exim4/passwd.client using your Gmail credentials:

gmail-smtp.l.google.com:YOUR-NAME@gmail.com:PASSWORD
*.google.com:YOUR-NAME@gmail.com:PASSWORD
smtp.gmail.com:YOUR-NAME@gmail.com:PASSWORD

Finally, issue the following commands to update exim4 and implement your changes:

update-exim4.conf
/etc/init.d/exim4 restart

Send yourself another test email to verify that everything is working properly.

Solving NAT and Audio Problems with FusionPBX

If you experience one-way audio, no audio, or calls that won’t disconnect when the called party hangs up, you’ve probably entered NAT Hell. First, make sure that SIP ALG is turned off on your router. If that doesn’t solve it, edit /etc/default/freeswitch from the Linux CLI and remove -nonat. Save the file and then systemctl daemon-reload. Switch to the FusionPBX GUI and navigate to Advanced -> SIP Profiles. Edit BOTH the internal and external profiles. Then modify BOTH the ext_rtp_ip AND ext_sip_ip entries and change them to autonat:XXX.XXX.XXX.XXX replacing XXX.XXX.XXX.XXX with your server’s public IP address. Then SAVE both profiles. Finally, return to the Linux CLI and restart FreeSWITCH: service freeswitch restart.

Congratulations! You now should have a working PBX. We’ll get deeper into the weeds down the road, but today’s tutorial coupled with the HTML FusionPBX Documentation or PDF version should be sufficient to get you started with a functioning PBX. Take some time to explore all of the Applications that are included in FusionPBX. Enjoy!



9/10 EDIT: New additions begin here…

Implementing WebRTC with FusionPBX

The first step in deploying WebRTC is to add SSL security to your server. The easiest way to do this is to take advantage of the free offering from LetsEncrypt. Begin by assigning a fully-qualified domain name (FQDN) to the public IP address of your server. Wait a few minutes for DNS propagation. Then you’re ready to install your LetsEncrypt certificate. Unlike many of the other LetsEncrypt implementations, the FusionPBX folks have made this a walk in the park. While logged into your server as root, issue the following commands:

cd /usr/src/fusionpbx-install.sh
cd debian/resources
./letsencrypt.sh
service freeswitch restart




Once the certificate is installed and you’ve restarted FreeSWITCH, close your browser and then restart it. Go to the FQDN of your server, and the lock should appear signifying that your site is now fully encrypted. Don’t proceed with the WebRTC steps until this is working.

To get a successful WebRTC implementation where you can make and receive phone calls from a browser, you’re going to need to use the Chrome or Firefox browser. We’ve also had success using the latest Safari browser.

For those that despise implementing complex procedures by viewing video tutorials, we offer the following regurgitation of the steps documented by Mark Crane in his ClueCon video below. This isn’t hard, but it is tedious so don’t skip any steps.



 

While you’re still logged into your server as root, let’s put the FusionPBX WebRTC client in place so you’ll have that option as one of several WebRTC clients to use down the road. The advantage of the FusionPBX WeRTC client is that it can handle your login automatically.

cd /usr/src
git clone https://github.com/fusionpbx/fusionpbx-apps
cd fusionpbx-apps
cp -R sipjs/ /var/www/fusionpbx/app/
chown -R www-data:www-data /var/www/fusionpbx/

Now let’s switch back to your browser and login to FusionPBX using your superadmin credentials. A word of caution… To get WebRTC working, your default Domain must be the FQDN of your server, not an IP address. Once you add this domain, you must switch to it and enter new extensions, trunks, and routes to that domain before proceeding. Begin by adding the domain: Advanced -> Domains -> Add (+). Switch to the domain in the upper right column that’s showing your current domain by clicking on it. It doubles as the Domain Selector.

First, let’s tell FreeSwitch to use your secure SSL setup. Navigate to Advanced -> Variables. Go to the SIP Profile: Internal section and change the false setting of internal_ssl_enable to true. Click SAVE. Go to the SIP Profile: External section and change the false setting of external_ssl_enable to true. Click SAVE. Navigate to Status -> SIP Status and click FLUSH CACHE. Switch back to your SSH session as root and restart FreeSWITCH: service freeswitch restart. Back in your browser, return to Status -> SIP Status, click REFRESH, and verify that both the Internal and External interfaces show TLS enabled.

Navigate to Advanced -> SIP Profiles -> Internal and set wss-binding to true. Switch back to your SSH session as root and restart FreeSWITCH: service freeswitch restart. Back in your browser, return to Status -> SIP Status, click FLUSH CACHE and then REFRESH. You now should see an internal entry for Secure Web Sockets (WSS) in your internal SIP Profile. Finally, to do video with WebRTC, navigate to Advanced -> Variables and add H264 to the list of supported codecs in both outbound_codec_prefs and global_codec_prefs: ULAW, ALAW, H264. Click SAVE. Navigate to Status -> SIP Status and click FLUSH CACHE then RESCAN the internal profile. Clicking on sofia status profile internal will let you verify that the H264 codec has been added successfully. That completes the required pieces to support WebRTC with FusionPBX.

To use the FusionPBX WebRTC client that we installed earlier, we first need to update the FusionPBX menus in the browser: Advanced -> Upgrade -> Menu Defaults and EXECUTE.

Now create an extension to use with WebRTC: Accounts -> Extensions -> Add (+). Once you’ve created the new Extension, drop down to the fourth item (Users) and click on the pull-down menu. Choose the Admin user and click the ADD button followed by SAVE. Next, log out and back into FusionPBX to associate the extension with your user account.

We’re now ready to try out the FusionPBX WebRTC client. Navigate to Apps -> SIPjs which will activate the WebRTC client with your extension credentials. In a separate window, you can verify that SIPjs is registered to your extension by navigating to Status -> Registrations. Verify that you can make a call by dialing *9664 for some nice Hold Music.

Adding Free IBM Voice Prompts to FusionPBX

One of the first things you’ll need with your new FusionPBX server is voice prompts for IVRs and custom applications. We’ve now added a tutorial which will walk you through setting up a platform to obtain free IBM voice prompts for your server. Here’s the link.

Blocking SIP Access by IP Address

If you’ve implemented SSL security with an FQDN as recommended above, then you’ll reduce the hammering your server takes from the bad guys by blocking those that attempt SIP registrations or calls using the IP address of your server. This, of course, means that all of your SIP registrations must be made using the FQDN of your server, not by IP address. For providers, you MUST whitelist their IP addresses in the ignoreip field of /etc/fail2ban/jail.conf and restart Fail2Ban, or they will be blocked when they attempt to send data by IP address. We’ve included a script in /root which will tell you which IP addresses currently are blocked: sip-attackers-blocked.

cd /
wget http://incrediblepbx.com/freeswitch/block-sip-by-ip.tar.gz
tar zxvf block-sip-by-ip.tar.gz
rm -f block-sip-by-ip.tar.gz
service fail2ban restart

Originally published: Monday, September 3, 2018  Updated: Friday, September 21, 2018


Support Issues. With any application as sophisticated as this one, you’re bound to have questions. Blog comments are a terrible place to handle support issues although we welcome general comments about our articles and software. If you have particular support issues, we encourage you to get actively involved in the PBX in a Flash Forums. It’s the best tech support site in the business, and it’s all free! Please have a look and post your support questions there. Unlike some forums, ours is extremely friendly and is supported by literally hundreds of gurus and thousands of users just like you. You won’t have to wait long for an answer to your question.



Need help with Asterisk? Visit the PBX in a Flash Forum.


 

Special Thanks to Our Generous Sponsors

FULL DISCLOSURE: RentPBX, Amazon, Vitelity, DigitalOcean, Vultr, Digium, Sangoma, 3CX, TelecomsXchange and others have provided financial support to Nerd Vittles and our open source projects through advertising, referral revenue, and/or merchandise. We’ve chosen these providers not the other way around. Our decisions are based upon their corporate reputation and the quality of their offerings and their pricing. Our recommendations regarding technology are reached without regard to financial compensation except in situations in which comparable products at comparable pricing are available from multiple sources. In this limited case, we support our sponsors because our sponsors support us.

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.


RentPBX, a long-time partner and supporter of PIAF project, is offering generous discounts for Nerd Vittles readers. For all of your Incredible PBX hosting needs, sign up at www.RentPBX.com and use code NOGOTCHAS to get the special pricing. The code will lower the price to $14.99/month, originally $24.99/month. It’s less than 50¢/day.


Some Recent Nerd Vittles Articles of Interest…

Print Friendly, PDF & Email

Be Sociable, Share!

Tags:

This article has 9 comments

  1. My perusal of the documentation leaves me with the impression that it has the same shortcoming as 3cx – no "Time Conditions" on outgoing calls meaning not possible to selectively route based on time or day.

    [WM: Take another look at the Inbound Routing Conditions. Time conditions are the last 10 options.]

  2. Take another look at my comment and pay attention to the word "outgoing".

  3. Will you be offering a version that supports 1.8 soon?

    [WM: Shouldn’t be too long. 🙂 ]

  4. Ward, great post!

    I’d be thrilled if you took a look at the freeswitch plugin we wrote for our device management platform!

    Would love the feedback!

    https://github.com/phonism-llc/freeswitch_agent

  5. I really appreciate your efforts to keep projects like this alive and keeping us abreast. I was wondering, would you use a Vultr low resource instance (with swap turned on) in production for FusionPBX or would you recommend higher resource allocation or reallocation once it went live?

    [WM: The size of the VPS depends to a large degree on the specifics of your implementation. Certainly, start small and see how it goes and determine whether FreeSWITCH meets your requirements.]

  6. Will Incredible PBX still be developed? Or are you switching to FreeSWITCH?

    [WM: Our current plan is to proceed ahead on both fronts to provide everyone with some options as we move forward.]

  7. "My perusal of the documentation leaves me with the impression that it has the same shortcoming as 3cx – no "Time Conditions" on outgoing calls meaning not possible to selectively route based on time or day."

    Just because the documentation doesn’t mention it doesn’t mean it can’t be done. Freeswitch is VERY flexible and a time condition to an outbound route is just another condition that can be easily implemented in diaplan manager once the outbound route is created.

  8. Like everyone else I’m just starting with this. One problem I can see with blocking port 80 apart from whitelisted i.p. addresses is that according to certbot documentation LetEncrypt does not specify a fixed address for certificate verification and presumably also for renewal. Keep up the great work. Thanks.

    [WM: Excellent point. We normally recommend shutting down IPtables while you’re upgrading certificates: /etc/init.d/netfilter-persistent stop. Once upgraded, issue iptables-restart to turn the firewall and Fail2Ban back on.]

Leave a comment

Your email address will not be published. Required fields are marked *

*