FreePBX SIP Trunks (Powered by Schmooze Com Inc)

Easy Setup of Trunks

THIS DOCUMENT IS OUT OF DATE PLEASE VISIT THE WIKI FOR THE MOST UP TO DATE INFORMATION SIP trunks are easy to setup and 100% supported by FreePBX. You not only get the benefit of using one of the world's best VoIP backbone networks that has built up over the last decade, but you will be directly supporting the FreePBX project when using these trunks. Also, you will be using a trunking service that is designed to work with FreePBX and Asterisk, not an after thought.

If you have not already purchased service, you can do so by going to The Trunk Store and signing up for service. Your account and phone numbers will be activated instantly and then you can quickly configure and enable your account.

If you are running FreePBX, as most of you are, you can download the SIPSTATIONTM Module from the online repository to auto-configure your trunks. It should be available on versions 2.5 and beyond. It should also work on earlier versions. If you are running a recent version of trixbox you will not have access to our module from their repository. You can download the latest version from the FreePBX mirror site. You will want to navigate to the FreePBX version that you are using in the previous link and from there, download the latest version of the sipstation-2.X.X.X.tgz module where you can use the Module Admin upload feature to install it.

Once you have an account, configuration is straight forward. In your portal area you will find your SIP Username and SIP Password needed to configure your trunk. In the example next, the SIP Username is 0137fg92 and the SIP Password is fs%7fRtu8 to be used in our example.


FreePBX SIP Trunk Settings


Now we go into FreePBX and Setup a new SIP trunk. In this example we are assuming that one of our DIDs (account phone numbers in the portal) is 212-555-1234 and we want to setup dialing so that 7 digit dialing, if enabled in our routes, will be sent out from this trunk with the 212 area code automatically. The next screen shows how to do this. The other fields can remain blank. You do not need to set the Maximum Channels field in your trunks with FreePBX SIP Trunks. If you use more channels than you have purchased, the network will signal congestion properly allowing other fail over trunks to be engaged if you have configured them in your route.


FreePBX SIP Trunk Configuration


You will notice that we put the 2125551234 into the Outbound Caller ID field. This will be the default CallerID used when extensions do not have their own Outbound Caller ID configured.

Next we must configure the Outgoing Settings to talk to the service. There are two SIP Trunk Servers available on this service, and either of which, or both can be used for outbound calling. Although these can both be access by using the SRV DNS entry, Asterisk doesn't appear to handle SRV records correctly and you should use for FreePBX. Notice that we will ONLY configure the Outgoing Settings box and leave the Incoming Settings box blank. Using the credentials we showed above, the following settings will properly configure your Outgoing Settings with a trunk called freepbx-rocks:


FreePBX SIP Trunk Configuration


IMPORTANT: The above assumes you have default codecs configured which include ulaw. The service will work with ulaw and g729 if you have g729 licenses. If you have changed this in your global settings you should add: [code] disallow=all allow=ulaw [/code] and to include g729 as well: [code] disallow=all allow=ulaw&g729 [/code]

The setting of qualify=yes is technically not needed but allows you to monitor the health of the internet connection in Asterisk, and if not doing any port forwarding, keeps the NAT pinhole open. For those of you on the extremely techie side, the setting of insecure=very is correct inside FreePBX. FreePBX will automatically convert this to: insecure=port,invite on Asterisk 1.4 and higher versions. (But if you happen to be setting this up in a raw Asterisk install, then you will want the latter).

The last bit we need to configure is the registration string so that the servers know where to send your inbound calls. This is simply derived from you SIP Username and SIP Password. You should be registering to as currently registrations to will not function:


FreePBX SIP Trunk Configuration


Now you should be able to hit submit and your trunk should be able to connect and start making and receiving phone calls.

Asterisk: registerattempts

Asterisk has a configuration parameter of registerattempts which determines how many times it will retry a registration if it is not successful. The default value of 10 is typically inadequate. If you have a short network outage, this can result in your registration going away which will stop inbound calls from reaching your system.

We recommend this be set to 0 by editing you sip_general_custom.conf file and adding: [code] registerattempts=0 [/code] A value of 0 tells Asterisk to try forever until successful. You can also use the Asterisk SIP Settings module to configure this, currently available in FreePBX 2.6, and will be backported to 2.5 shortly (and works now if you want to grab the tarball and install it).

Inbound Route

Don't forget to configure an Inbound Route so your PBX knows where to send incoming calls! The most common cause of support calls that start with "I'm not receiving inbound calls" is either a missing or improperly formatted Registration String or NO Inbound Route. Assuming you have purchased DIDs, your calls will be transmitted as a 10 Digit DID and should be entered as such in your Inbound Route section (or using the shortcut "Add Inbound DID" on the Extension tab for each user. You can also create an Any/Any route which will terminate any DIDs you have not specifically assigned.

NAT Configuration

If your PBX is behind NAT and does not have a public IP address, you are going to have to do some additional configuration. This is required for any type of SIP Trunking service that you may have, or to connect remote SIP phones to your PBX. Although you may find that you are able to register without the subsequent instructions, you should always set these up to get proper and optimal service and not rely on features such as NAT Troubleshooting Mode which may get your service going but may result in non-optimal service and voice quality.

The setup is essentially identical as the first two sections of How to Setup a Remote SIP Extension. The information is summarized here:

Internal/External Network Information

You must edit or create the file sip_nat.conf typically found in your /etc/asterisk directory and make sure it is owned by asterisk. We will assume that you have an internal network of and that you have a static IP address of If you have a dynamic IP, see the notes that follow. In this situation, you need to create or edit the following entries in your sip_nat.conf file:

[code] externip= localnet= [/code]

This tells Asterisk what IP address range is internal vs. external so that it can rewrite the SIP headers appropriately. If you have a dynamic address instead of a static address then you need to modify the above. You will need to have a domain name for the host, let's assume you are using's free service and have chosen the name Then your sip_nat.conf file would look like the following:

[code] externrefresh=120 localnet= [/code]

Where externrefresh tells Asterisk to recheck the IP address every 120 seconds in this case. You should adjust this higher or lower based on the frequency that this changes.

Firewall/Router Configuration

The default installation of FreePBX is configured to use UDP port 5060 as the SIP signaling port and UDP ports 10001-20000 as the RTP Media ports. All these ports must be forwarded to your FreePBX System. How to do this varies widely depending on the firewall or equipment that you are using. It is commonly referred to as Port Forwarding or maybe Destination NAT (DNAT). However it is referred, if we assume in this example that your FreePBX system has an internal IP address of then you will want:

[code] UDP/5060 -> Forward to UDP/10001-20000 -> Forward to [/code]

That is all the setup that is required, you can now start making and receiving calls!


For added redundancy, there is a secondary server that can be used, in addition to the primary server It is recommended that you repeat all of the above settings for a second trunk and registration to with your same credentials. You MUST have registered to receive calls. The secondary server will only signal inbound calls if were not available.

Taxonomy upgrade extras: 


9000233309's picture

If you are using the SIPSTATION module you need to configure your UDP forwarding for 10000 thru 20000 or your run firewall test will fail. The "unused" port that the firewall test selects is 10000 resulting in the the test fail if that port isn't included.

p_lindheimer's picture

actually the 'unused' port that the firewall uses will be the lowest unused port based on the rtp.conf configuration. If you have 12000-16000 as your port range, and there is currently a call using 12000 for its media, then the firewall test would end up testing on 12002.

goblinbs's picture


i've put two different questions especially intended for you ! i'm sure that you are the right person. because i think that you are the programmer of page.routing.php ?! not right ?!

you can find them in the forum/developpement

just search for my nickname goblinbs

hope you'll find the time to take a look.


ColoradoRuss's picture

This does not seem to match the current setup system with the account key system.

p_lindheimer's picture

for manual setup it is accurate though the portal screenshot is the old layout (but the information is still the same).

If you are using the account key, there is really no instructions needed, just put the account key into the module and it will do everything for you.

vanhorn's picture

Using the SIPSTATION module, all I get is this:

noserver: This module can not reach the server to obtain your account information. If you can navigate to from a browser then there is an issue with your firewall or DNS resolution. If this is a first time install you might be able to reboot to rectify the issue. If you have an aggressive firewall with content filtering or equivalent, you may have to disable that feature for this server or white list the site if possible.

I was having problems getting a Vitelity trunk to connect, so when I saw the automatic setup for SIPStation I had to try it. Getting no response from support after an e-mail, I read this page and discovered that SIPStation wants 5060 and 10000 - 20000 open for UDP, I only had it open for TCP before.

Unlike the example above, when I signed up at I was given trunk1/ as the servers, but I am unable to ping those servers from anywhere. From all networks, the name resolves to a numeric address so there is no DNS issue.

My firewall does no content filtering.

Any suggestions while I wait for support to get back to me?


p_lindheimer's picture


if you are getting the noserver response then there is an issue one way or another with the firewall. The only other thing that makes that occur is an abnormally slow response to the ajax call that that is triggering the CURL operation which fetches the configuration and status information from the server.

what version of FreePBX are you on, and when you check for online updates in Module Admin, how quickly does it come back with the information. This uses similar (but not exactly) mechanisms. (The biggest difference being that Module Admin will fallback to wget() which sometimes rectifies some firewall issues where as the SIPSTATION module does a straight CURL operation to try the connection.

vanhorn's picture

I'm running FreePBX 2.8.1, Asterisk, CentOS 5.5

When I ask for a "Check for updates online" with "Extended Repository" selected it's just about a second before I get the page with the additional modules.

I don't think I needed it, but I just added firewall rules to specifically allow TCP/UDP outbound from that network (I believe any traffic originating there should go out, and any responses from outbound traffic should be returned) on 5060-5061 and 10000 to 20000, with no change.

And I still can't ping trunk/trunk1/, although I can ping and with decent (~80ms) response time.


p_lindheimer's picture

I don't think trunk1/ are setup to respond to pings.

The UDP 5060 and 10000-20000 have nothing to do with the SIPSTATION module. That is purely for the VoIP traffic (5060 for the signaling and 10000-20000 being the default range that Asterisk is configured for and will be requesting as media ports when calls are setup.

The Ajax timeout is set very hi, 20seconds, so it must be your firewall blocking the requests that are going from the server to the service to fetch the information.

I've seen the problem multiple times, it has always been firewall or DNS related (in this case it does not sound like DNS). In your amportal.conf, do you have a setting: MODULEADMINWGET and if so what is it set to?

vanhorn's picture

The MODULEADMINWGET setting was not declared, I enabled it and got the same response. (Then I restored it to the default.)

I don't doubt that this is a firewall configuration issue, the two networks behind the firewall contain my most valuable assets, so the configuration is pretty tight. But it's my firewall and I can open anything I choose. All I need to know is exactly what should be opened.

Just let me know what needs to be open and I can make it so. Also, if this is not needed on an ongoing basis I would like to close it afterward, but most specific pinholes are safe if they need to stay open.

BTW, I see I didn't post that I'm using sipstation-


vanhorn's picture

Firewall logs are tedious, but I determined that traffic to on port 443 was required for the SIPStation module to run. Given that this is secure HTTP I see no reason not to leave it permanently enabled for this host.


p_lindheimer's picture

well first off it looks like you solved the issue which is very helpful as it uncovers one mystery that may be sometimes happening to other people, which is the blocking of 443 traffic for outbound and why sometimes module admin works fine and not sipstation.

As far as MODULEADMINWGET, the only reason I was asking about that was to see if it was set true by default which could have explained why Module Admin worked right away. On problematic systems, if that is not set, you can encounter a long delay prior to the failed file_get_contents() timing out and then the system automatically falling back to a wget. (This is the issue with content filters typically…)

In either case, sipstation does it differently (and in theory 'better') in that it uses CURL to access the server vs. file_get_contents() but there is no fallback to wget. (And the reason why is that eventually it will be extended to push configuration information back to the server which can't exactly be done with a wget if you want to support RESTFUL states like PUT, POST, etc…

Anyhow, sounds like you are all good at this point. As a general rule, I would think you run into many more problems on your firewall if you are not allowing https sessions unless you had setup harsher rules on the PBX then most of your desktop clients in some DMZ or something. To be clear though, you only need to support https (443) sessions initiated from within the firewall to receive the responses back. You do NOT need to support uninitiated sessions inbound to 443.

vanhorn's picture

The DMZ is intended to be as tight as a drum. I have a public /28 and a private /24 behind the firewall, and I don't want anything moving between my public addresses and the outside world without a very good reason. On the other hand, I can't think of any good reason not to allow outbound HTTPS, other than by default I don't allow anything that I haven't thought hard about. I fixed the problem by allowing HTTPS only from the Asterisk box to the specific host, then decided it was reasonable to allow it outbound from any DMZ host to any outside host.

Historically, the scariest security lapses I've had have come from situations like this. Something doesn't work, the reasons aren't immediately clear, and all kinds of things get opened up trying to make it work. When it finally does work, we're eager to move forward and forget to close up all the extra things that were opened up while thrashing about.

Ergo, I would like to suggest that the error message be changed as follows:
noserver: This module can not reach the server to obtain your account information. HTTPS access (port 443) is required. Additionally, aggressive content filtering can block the transfer and you must have DNS working. (Ping to test.)

Perhaps the existing message about navigating to should have been suggestive, but I never even install a desktop, much less a browser, on servers.


ecase's picture

I just purchased a DID from freepbx to use the SipStation module.
When I try to load the SipStation Key via Freepbx server gui, I am greeted with:

noserver: This module can not reach the server to obtain your account information. If you can navigate to from a browser then there is an issue with your firewall or DNS resolution. If this is a first time install you might be able to reboot to rectify the issue. If you have an aggressive firewall with content filtering or equivalent, you may have to disable that feature for this server or white list the site if possible.

I have reviewed the conversation with Vanhorn and p_lindheimer to a great extent. I have even completely opened my firewall (temporarily) and I still cannot update the key. I have tried port forwarding, port triggering, (port 443, in/out) & dmz. I have disabled iptables. I have disabled content blocking along with domain name blocking. I am stuck. Please help.
I installed from PIAF purple - Asterisk Ver.; Freepbx Ver.; Centos Ver 5.6



florimont27's picture

I haven't been able to make outbound call for a month now. I took a wireshark capture on my pbx which is on a public IP. Support clearly agreed with me that there is no incoming RTP from the Sipstations IP. I was able to go around the problem by setting canreinvite to no. That doesn't work anymore. Is SIPSTATION having SBC or firewall issues. Am I the only one not able to make outbound call with sipstation sip trunk ? Once they did admit they had an issue I haven't heard back from them ? It's been 2 weeks.

qiubosu's picture

Hi Team,

I'm based in New Zealand and want to host an Asterisk PBX system in my office based in Auckland, New Zealand.

In this case, can I use the FreePBX SIP Trunk to fit my purpose?


garys_m_i_t_h's picture

Hi all,

I am looking for PBX with SIP trunk solutions for my business in the UK. This post on freePBX is alluring but, reading through the comments, I am afraid that it won't work well. I have found another solution that I might like:

Users, please answer: does freePBX work? I think I might choose the other one instead, I cannot afford a non-working communication system.