In Part 1, we went over the installation of IncrediblePBX on the Raspberry Pi. In this post, we’ll get into the nitty-gritty and some much needed theory. We’ll also be getting our hands dirty with a complete walkthrough on how to setup IncrediblePBX for residential use.
Residential Setup
Extensions
If you remember in Part 1, we re-used an extension that already was created for us to register our softphone – the default 701 extension. Of course we need not be only restricted to the 701 extension, you easily can add as many as you like. If you haven’t figured out already, extensions are in essence a connection between Asterisk (the main software component that drives IncrediblePBX) and a phone, whether it be a plain old phone or softphone. Extensions are the foundation for any setup and that’s why we must deal with them first.
Voice Mail
Typically in an office environment, you would probably want to turn the voice mail on each extension because a worker is usually associated with their respective phone. But in our residential use case, it makes sense not to use voice mail on your actual phone extension, as we’ll use one for all configured extensions. This being the case, we’ll leave voice mail turned off on any physical phone extension for now (but we’ll come back to this shortly).
Since this guide is mainly for a residential setup with a single voice box, and since voice mail is handled similarly to an extension, we’ll create one extension now.
Create an extension, but instead of choosing “Generic CHAN SIP Device” (which is what is normally selected for a phone), choose “None (Virtual Exten)” for the type of extension. Like a real extension, you will need to choose a “User Extension” (i.e.: the extension number – choose something well outside your physical extension numbers – like 1000) and the “Display Name” (i.e.: a descriptive name for the extension – like “Home Voicemail”).
Accept the defaults and only change the status to Enabled, set a password and specify an email address that you’d like MP3 versions of the voice mails be sent to.
Rememeber: for sending of voice mails via email, you need to set up SendMail, see this if you haven’t already configured it.
Let’s revisit the 701 extension. Because we want to be able to access the voice mail from our softphone (currently using extension 701), we will need to modify the 701 extension settings and put the following in the Mailbox field. Extension@default. In our case it’s 1000 for the voice mail extension. Keep in mind you’ll need to do this with any other extension you will create.
Finally, you need to record your voice mail greetings for the system to work properly. To do this, dial your voice mail extension number from any extension on the system. The system will dump you into the voice mail system and start allowing you to record a message. We want to get into the Voicemail administration section and pressing “*” button and entering your password will get you into the admin section. Pressing “0” will get you to the greetings where you can record your “Busy” and “Unavailable” greetings as well as your name. Do all three to ensure the system works as expected.
Ring Groups
Normally, in a residential setting you’d probably have multiple extensions – perhaps situated in different rooms, or better yet, on different floors. Ring Groups provide a simple way to ring certain extensions together. The basic idea being that all incoming calls be directed to a specific ring group so that all the phones in the house will ring when a call comes in. To create a Ring Group go to Applications -> Ring Groups.
A couple things to notice here. First off, extensions you want to ring together are added to the Extension List (ignore the extension ****5678# as that’s a bit of a special case – I’ll get into that hopefully in Part 3). I then set Record Calls to Force, as I want all calls to be recorded by the system and finally if after 20 seconds (Ring Time), no one picks up, then the call gets directed to extension 1000, which is the voice mail we just set up previously (Destination if no answer).
Trunks
You need to communicate with the outside world, don’t you? Normally this is done in the form of a paid service to a VoIP provider of your choice. Trunks are that gateway to your provider made possible through a connection on internet rather than that phone wire running into your house from the outside.
Without a provider you are by no means restricted to an idle IncrediblePBX setup. You can always place extension to extension calls. But what’s the point of that your say? Well, extensions don’t have to be geographically located in the same place. Picture a VPN network with multiple extensions! Cool, no? In fact that’s how it’s done in most big businesses.
How you set up a trunk is very specific for the provider that you use, so unfortunately I can’t be of much help here. Luckily, most providers have very specific how to instructions available on their website and IncrediblePBX has some built in configurations ready to use out of the box as well. More so, if you followed the Google Voice setup, you should already have one trunk available to you, ready to go!
Routes
Routes were difficult to grasp for me. I didn’t quite understand the relevance until I got to implementing some.
An Outgoing Route for example, will decide what trunk to use for making calls based on how it is configured or more specifically, what number is dialed based on the Dial Plan (more on that later). Another good example is that your might want all calls to the US and Canada to go through Google Voice since it is free, instead of your paid provider. And an Incoming Route decides how to handle an incoming call based on how it is configured or more specifically, what incoming number is being dialed from the caller’s end.
For incoming routes, most homes will just have a single route that pretty much handles all calls. But if you have several phone numbers, or should I say, DID (Direct Inward Dialing Numbers, also known as DID or DDI) coming into your IncrediblePBX server, you can configure where you want calls to be routed to, ha! I get it now! Perhaps you have two DIDs, one for Voice and another for Fax data. In a business setting however, this could be highly relevant (perhaps one route for one side of the business, and another for say customer service, etc.), then you can have routes configured that specify that all the business calls go to the office extension only and customer service calls go to the customer service department and ring another ring group.
Another cool but more convoluted example; suppose you want to direct a specific calling number (say your friend George) to your custom IVR (IVR stands for Interactive Voice Response and I know I haven’t spoken about it but think of it as a menu system – what you normally encounter when you call a company’s customer service number) and that IVR enables the caller to press a button, enter a password, and dial out using your free Google Voice account! Then you would configure a route that matches Georges incoming number and then set the destination to the IVR. Nice!
Inbound Routes
The incoming or inbound route is easier because most people only need one route that handles all calls. So we’ll make this assumption in this example. Select Connectivity -> Inbound Routes.
Give the route a meaningful name. For a generic “catch all” route, leave the DID number and caller ID information blank – that could be one option. But to be more specific, put the DID number assigned to you by your provider (I’ve obviously obfuscated mine in the picture below as I rather not receive calls from you – no offense). The Caller ID number is the phone number of the person calling you, which we’ll leave blank for “all”.
Say you want all calls from your mother-in-law to go to a special destination, say Terminate Call/Hangup, you can put her phone number there. Okay, enough mother-in-law bashing.
Moving on, you can select CID lookups (which dictate how the caller name gets populated – check under Admin -> CID Superfecta) and finally select where you want calls to go in Set Destination. In this case they go to my “ring all extensions” ring group we created earlier.
Outbound Routes
Outbound routes are more difficult to configure and need to be done correctly. If you ever notice that some placed calls work any others don’t, more than likely there’s a problem here.
Select Connectivity -> Outbound Routes.
This is a screen grab of my Google Voice outbound route.
If blank, give the route a name, say “Google Voice” and it’s not necessary to enter a Route CID, although I did for some reason.
The most important and consequently most confusing thing about this setup, are the Dial Patterns. In the above example, I have two dial patterns set up. The “X”‘s match any number from 0-9 and “N”‘s match any number from 1-9. The first one is for any eleven digit number dialed (1+10 digit number), prefixed by a 2. The second pattern is for a 10 digit number dialed, again, prefixed by a 2.
The “2” in the prefix field allows me to selectively choose what outbound route the call should use when I pick up a phone. This digit is not dialed, that’s important to remember. Although not shown here, if a “2” is not prefixed before a number, the call gets routed through my paid VoIP provider and not Google Voice. This is how I have it set up. As a disclaimer, I’m not entirely sure whether this is the best way to go about choosing providers based on the the Dial Pattern, but is seems to work for me. So go with it, unless of course you have a better idea, if so, then post it to the comments section.
It’s also good practice to assume that your provider needs the preceding “1” to be dialed along with the normal 10 digit number. By placing a “1” in the prepend column, the system will add a “1” in front of any 10 digit number. Likewise, if people are used to dialing just seven digits for all local numbers, then you would create another dial pattern with 1+AreaCode in the prepend field and NXXXXXX in the match pattern field. However in my case, if you notice, any number dialed with just 7 digits would fail while long distance numbers would go through.
Finally, at the bottom, you select the trunk you want to use with any call that meets these dial patterns, in this case, the Google Voice Trunk. Because I’ve used the “X” and “N” wildcards, this route will send any call with 10 or 11 digits to the Google Voice trunk.
One last thing, an entry for 911 does not exist here. If this was the only outbound route I had, I would no be able to place emergency calls – which is generally not a good thing – unless you’re immortal. Google Voice does not handle 911 correctly, that’s why it’s not here. I do however implore you to verify this with your VoIP provider and configure the dial pattern appropriately to ensure you can place 911 calls correctly.
Well, that’s about it for this part and boy, was that long! Alas, your PBX should be able to place and accept calls and also handle voice mails. Where you go with it, is totally up to your imagination and needs. Next time, I’ll go over how I was able to get KODI notifications working for both incoming calls and voice mails. See you there!
Your tutorial (and all others on the ‘Net) doesn’t go into actual cabling topology for a PBX, only the setup of the software. Example question not addressed: Is it OK to hang the Raspberry Pi PBX off a Wi-Fi router via an Ethernet cable like any other peripheral and to have as extensions softphones installed on smartphones and connected to the router via Wi-Fi? With old Wi-Fi enabled smartphones going for $10 or $15 online, this could comprise a handy VoIP system. Would that topology work?
Don Alden