Twilio vs. other elastic(paygo) SIP trunks?

This question is directed to those who have used both Twilio and other elastic SIP trunk providers within the last year:

I switched some analog POTS lines away from my RBOC to Twilio about 3 months ago because of the huge cost savings in my own use case. Setting it up for outbound calls was extremely easy, and incoming calls seemed easy as well. However, I noticed as many as 40% of incoming calls were 401 unauthorized on the first attempt, but on the second the call was connected with no problems. After going round and round with support from both the Twilio and FPBX communities, I think I’ve eliminated the majority of the inbound call failures. It’s too early to tell if all have been eliminated, but it appears that the percentage has dropped significantly.

I have other lines at other sites that I want to move as well, each with their own FPBX installation. However, the issues with Twilio have made me nervous about moving to them, and I’m wondering if you would recommend a different provider like Telnyx or due to the reasons cited above.

For the record, I think that if I created a fresh FPBX installation and added Twilio as my only trunks that it might not have been so bad, but reconfiguring an installation that was configured with other trunks previously may have been a large part of the problem.

“Elastic SIP trunk” is pretty much a Twilio term. Could you be more specific about what you are looking for? I have used Twilio, Plivo, Signalwire, and Telnyx all very recently, and these all feature the “elasticity” of API configuration, flexible call routing, and so on. I’m not sure why you had such trouble with Twilio. In the Twilio controls, you can specify a region from which you will accept inbound calls (e.g. US east) and there will be a set of IP addresses associated with that region, which you can put in a PJSIP trunk “Match” field as well as open your firewall if you have it locked down.

Of the aforementioned, I would not recommend Plivo.

Were you able to determine the cause of the 401? Possibly a misconfigured firewall or misconfigured trunk? If you know the cause, you can determine the fix and provide an actual answer to the question as posed.

@billsimon I think Twilio may have pioneered the term “elastic” but it’s used by other carriers as well. Telnyx is the other provider I’ve heard good things about and their pricing looks to be the same for their elastic trunks.

If what I did actually fixed the problems, this is what happened:
When I signed up with Twilio - in March of this year - their “welcome” documentation actually pointed to the 2015 FreePBX setup guide, not their 2018 guide. As such, I setup the trunk originally as a SIP trunk, not PJSIP which apparently works better for them. Anyway, I ultimately had to delete all previous trunks, including my other SIP and DAHDI trunks, before the Twilio PJSIP worked. Once I deleted everything else, I added back the only other SIP trunk that is used and they both seem to work properly.

Otherwise, no, nothing was misconfigured on either the Twilio or the FPBX ends. Like I said, it’s a little early to be 100% sure (it’s only been 2 days) but I haven’t had any call failures yet. It just seems that those little quirks in FPBX were the issue.

@billsimon I’m looking for a trunk where I’m paying for the DID’s and the actual usage, not a static fee just for having access to the trunk every month. Some months I might have only 10 total minutes of usage by 2 people and others I might have 8000 minutes across 10 users simultaneously. I need a trunk flexible enough to accommodate both without paying extra just for the standby.

There are many such providers and you would do well with those already mentioned here. “Pay as you go” is the term I am more familiar with for that kind of service.

Use PJSIP if you can at this point, even if the provider only has instructions for chan_sip. You should be able to translate the instructions from a chan_sip setup into the fields you fill in for a PJSIP trunk.

there will be a set of IP addresses associated with that region, which you can put in a PJSIP trunk “Match” field

I just went through all of the Twilio/FreePBX documentation on the trunk setup again, and I don’t see anything about adding addresses to the “PJSIP>Advanced>Match (Permit)” field. Is this what you’re referring to, or is that setting somewhere else? If this is what you are referring to, then you’re saying that I need to populate this with their address list?

Hey Matt,

This is the section I was talking about – using the “region” parameter to specify that you want your incoming calls to come from a more limited set of IP addresses from Twilio. That is mentioned briefly in their FreePBX configuration guide steps 21 to 23.

Actually if you follow their guide and both specify an inbound region and use the SIP Server address like “,” then Asterisk should figure out the IP addresses to match by default, because they are all in DNS:


If that doesn’t work automatically, then you can use the lists specified here to fill in the Match (Permit) field (use the Signaling IPs list for your region).

Is it possible this was failing for you some of the time before because you didn’t specify the region parameter and calls might come in from various Twilio datacenters?

@billsimon Sorry for the delay. Twilio says that this is a legacy configuration and they generally don’t recommend this for American accounts unless your testing shows a high latency. They default to the Virginia data center only unless you specifically request both or just the Washington data center. I also presented the possibility of data being rerouted after the trigger, but they claim it isn’t possible.

As far as the other IP’s from the list you mentioned, I had previously added them to my firewall. Since their FPBX config guide doesn’t mention anything about the PJSIP>Match field, I never added anything to it. However, I’m not averse to adding that long IP list if it did solve something.

After examining my call logs today, I have not had any call failures in the last 7 days. Therefore, I think that it was the FreePBX quirks I mentioned already that led to this being resolved rather than with Twilio being difficult to configure. Since I already have accounts established with Twilio, I’m ready to move forward with them on another FPBX installation.

I appreciate your efforts, and insight with the other carriers as well!

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.