Previous article: FusionPBX Basic Configuration: Introduction and Creating an Extension
The intent of these articles are to show you how to do a few basic things in FusionPBX and to give you a little bit of the “flavor” of it. Both FusionPBX itself and this article are works in progress, and particularly if you are reading this within the first week or so after I post it (or even the first YEAR in this case), you might want to check back later since there is a high likelihood I will have made edits and corrections. If you haven’t yet installed FusionPBX, see Installing FusionPBX successfully — Part 1: Installing Debian Linux and Installing FusionPBX successfully — Part 2: Installing FusionPBX for information on that.
The first thing I want to show how to do in this article is create a gateway to an Asterisk server in FusionPBX. A “gateway” in FusionPBX is the equivalent of a “trunk” in Asterisk (it’s called a Gateway in the FreeSWITCH .xml file, and FusionPBX tends to follow FreeSWITCH naming conventions), and I’ll be showing how to pass traffic between a FusionPBX gateway and an Asterisk trunk. The reason I am starting here, rather than with a commercial VoIP provider, is because many of you who will be setting up one of these systems will be in the same position I am, where you already have a functional Asterisk box and you just want to dip your toe in the water by passing traffic between the boxes. At some point I may attempt to connect to a commercial provider, but even if I did, it probably wouldn’t be the same one you use.
However, I will note here that the FreeSWITCH Wiki has a page of SIP Provider Examples that might be useful if you are trying to connect to a commercial provider. Note, however, that such examples might not be directly applicable to FusionPBX without a bit of tweaking, and also some of them may be out of date. Keep in mind that I’m just starting out with FusionPBX, so I’m taking one thing at a time.
To start with, go to Accounts|Gateways from the main menu, and on the next page click on the Add icon. It will bring up a window similar to this:
Note that I am not registering with the Asterisk server because there is no need to do so in this case. As much as some of you may think I am an expert in this stuff, I’m not, and it mystifies me why sometimes registration is required and sometimes it isn’t, but in this case it isn’t. Also, when I took the above screenshot I neglected to fill in a Gateway Description, but if you plan to have more than one or two gateways you will probably want to make sure you put something in that field to help you pick the correct one from the list of gateways that you see when accessing Accounts|Gateways.
Note that what you pick as a username here will be used as the trunk name on the Asterisk server, so keep that in mind when choosing a username. Conversely, I made the Gateway name the same as the username on the Asterisk trunk. I don’t know if that’s required in FusionPBX or not, but it help keep things simple in any case. The password here will match the secret in the Asterisk trunk configuration.
Now let’s look at the Asterisk side of things. Using “The Software I Have Come To Hate” (and one of the motivations for me taking another look at FusionPBX), I set up a new trunk and gave it the trunk name newfusion (which needs to be put in both “Trunk Name” fields). The ONLY other thing I filled in was the PEER details, which look like this. I am not saying these settings are 100 percent correct or that all are necessary, but they worked for me:
Just so you know, I gave munged the network addresses in these examples, so even though they appear to be on the same network, in reality they were on two different networks. The main things to keep in mind are:
The host address and the first part of the permit address must be the same. The permit and deny fields are a security measure that can be used as long as the FusionPBX server is on a static IP address. I only allow ulaw connections between the servers but obviously you can allow other codecs if you like. I set the context to from-internal because I wanted the two servers to be able to pass calls between extensions as if they were on the same server, but if the connection is from an “outside” server that’s not part of your organization then you should use from-trunk instead, particularly if you have any concerns about the other server attempting to pass unwanted traffic through your Asterisk server (remember, using “from-internal” basically grants all the calling privileges that a user on the Asterisk server would have).
A note about the trustrpid=yes and sendrpid=yes lines. FreeSWITCH sends SIP INVITE packets using a slightly different format than Asterisk expects, and therefore, whenever you get an incoming call, Asterisk will use the trunk NAME (actually the Username from the FusionPBX gateway) as the CallerID NUMBER. So you might get incoming calls with a Caller ID Name that is correct, but with the trunk name where the calling number should be. This is obviously not desirable, and adding the trustrpid=yes and sendrpid=yes fixes that issue, but begs the question of what happens if you only have control of the FusionPBX side and not the Asterisk side? At this point, I don’t know the answer to that, but if someone can give me a definitive answer, I will add it here. I spent a considerable amount of time on the #fusionpbx IRC channel with the FusionPBX author (mcrane) trying to figure this out, and although he and I tried several things to overcome this apparent incompatibility, so far this was the best solution I could come up with.
For those of you that may want or need to pursue this further, here are some links from the FreeSWITCH Wiki. Keep in mind that a better solution may have been staring us in the face, but at 1 A.M. the mind tends to get hazy, so don’t assume that I have already tried everything possible. However, I DID try setting the “Caller ID in from” value to “True” (you need to click the “Advanced” button on the FusionPBX Gateway edit page to see that setting), as suggested on some of these pages and in various other places, and that did not seem to help:
That last link might be useful in any case if you are having issues setting up a gateway. Again, if you find a better solution that can be implemented entirely in FusionPBX and does not require adding the trustrpid and sendrpid lines on the Asterisk side, please leave a comment!
Now, if you have gotten this far, you will discover that although you can make calls from FreeSWITCH to the Asterisk box (once you create an Outbound Route, which will be covered below, you won’t be able to receive calls from the Asterisk server, even if you go ahead and create an Inbound Route (the subject of the next article). The reason is that by default, FreeSWITCH wants to talk to external servers on port 5080, and Asterisk wants to talk on port 5060, though you could force it to use port 5080 by adding a port=5080 statement to the trunk configuration. There may be some advantages to using port 5080, in that it’s not a port that most hackers would expect you to be using for sip, and it’s not a port that a repressive government or ISP would be as likely to block or degrade. Bust since most Asterisk servers and most VoIP providers expect you to be on port 5060, you probably want to know how to make FreeSWITCH communicate on that port.
The FusionPBX author explained to me in IRC (edited for clarity):
FreeSWITCH works a little differently than Asterisk. 5080 is the external sip profile that doesn’t require registration. If using port 5080 is not an option, you can set an ACL entry to allow the Asterisk server (or carrier if applicable) to use port 5060.
The ACL entry is set in Advanced|XML editor:
Expand the autoload_configs folder, and edit acl.conf.xml:
Add the line highlighted in blue at the place shown above. replacing 192.168.0.234 with the actual IP address of the Asterisk server, or server that you want to allow. The line in text form (so you can cut and paste it) is:
<node type=”allow” cidr=”192.168.0.234/32″/>
It goes in the section “<list name=”domains” default=”deny”>, just before the final </list> tag.
Then go to Status| SIP Status and click on the Reload ACL button:
The FusionPBX author also noted that it’s also possible to add a “dummy” extension that’s not actually used, and click the Advanced button to expose the CIDR field, and set that to 0.0.0.0/32 with 0.0.0.0 replaced by the IP address of the remote server, and also set the User Context to public. This is just another way of authorizing the IP address of a remote server so it doesn’t have to register — it’s an alternative method to adding a line to acl.conf.xml, but this method allows you control of the context, although most of the time you would want to set it to public. You wouldn’t use that extension to register to it and you wouldn’t be sending calls to it; it is more of a dummy extension that authorizes the IP/IP range, and that IP inherits things from that extension such as the context. Port 5060 requires registration of an extension normally, but here you are just authorizing an IP address with the CIDR on the extension, creating an IP address or range of IP addresses that don’t have to authenticate and that inherit variables and parameters of the extension. If that confuses you, just stick to the first method as explained in the previous paragraphs.
One thing that the FusionPBX author advises against — apparently some people come to FreeSWITCH and see the internal profile requiring registration on 5060, so their solution has been to change the internal profile to 5080 and external profile to 5060. He believes this approach is a mistake, and has fixed several systems were the previous admin used that approach. He considers that approach bad practice, because then all your phones have to register on port 5080, which is inconvenient, but also the approach can cause other issues that make life harder and more confusing. And, it’s really stupid when all you need to do is just create a simple one line ACL entry in acl.conf.xml.
In order to test the connection to the Asterisk server, you can quickly create an Outbound Route. Many outbound routes are predefined. For example, if you wanted to create a route for outgoing Toll Free numbers in the U.S. or Canada, you could go to Dialplan|Outbound Routes, and on the next screen click the icon to add a route. You might then set up a route that looks like this:
All you really need to do to create the first Outbound Route is to use the Gateway dropdown to pick the correct gateway (in this case we are sending the calls to the Asterisk server, but you could create a new gateway that sends toll-free calls direct to a provider that will accept them), and then use the dropdown in the Dialplan Expression section to pick the toll free option. Optionally, you can enter a description of the route at the bottom of the page. Then click Save, and that’s all there is to it!
Note that if you want to place calls to extensions on the Asterisk server, you could do the same thing, but select one of the other options from the dropdown, such as 3, 4, or 5 digits. But also note that you can modify the regular expression to suit your needs. For example, let’s say you want to send 4 digit extension numbers, but all the extensions on the Asterisk box start with the digits 11, while the extensions on your FusionPBX box will start with 10. In order to avoid confusion, you could pick 2 digits from the dropdown, which would give you this pattern:
Then simply add the “11″ digits in the appropriate place:
And then save the modified pattern.
In case you are not that familiar with regular expressions, here is a page from the FreeSWITCH Wiki that might be of some assistance:
Another great site for learning about Regular Expressions is Regular-Expressions.info, where they have a tutorial and a number of other resources.
If you make any discoveries with regard to creating Gateways or Outbound Routes in FusionPBX, or can help clarify anything in this article, PLEASE leave a comment. Again, remember that I’m very inexperienced with FusionPBX as I write this, so there may well be better ways to do certain things!
Next article: FusionPBX Basic Configuration: Creating an Inbound Route
- FusionPBX Basic Configuration: Introduction and Creating an Extension (michigantelephone.wordpress.com)
- Installing FusionPBX successfully – Part 1: Installing Debian Linux (michigantelephone.wordpress.com)
- Installing FusionPBX successfully – Part 2: Installing FusionPBX (michigantelephone.wordpress.com)
- My attempt to install FusionPBX on a VMware server (michigantelephone.wordpress.com)
- Screenshot comparison of four Linux-based PBX GUI’s – Extension options (michigantelephone.wordpress.com)