Is there a limitation on the amount of SIP Trunks one can load on FreePBX 14

We need to register in excess of 600 VOIP SIP Trunks and will grow to around 2000 Trunks in the next few years? Will FreePBX allow for this?

Can it handle it? I doubt it, but maybe. Should it handle it? I don’t think so.

That’s not really something FreePBX is designed to handle. There are other technologies (some from Sangoma) that are better suited to this type of trunk aggregation. FreePBX is a public branch exchange replacement, so it’s not really intended to do something that requires this kind of trunk registration.

In a sense, yes but you need to clarify a few things. When you are referring to “trunks” are you referring to connections between the PBX and an upstream provider (like VoIP Innovations) or are you referring to actual phones/users?

Lets cover the latter and say this is a PBX going in for a company that has 600 employees and needs to be the company PBX. Yes, this can be done. You would need to allocate some CPU / RAM to the system (if a VM) that can grow as you scale your employees.

Now if this is the former, then that begets the question: How many end users/phones will there be? As well as if this is some sort of provider aspiration, I’m going to tell you right now from experience. FreePBX is not an ITSP/VoIP provider solution unless you are giving individual customers their own PBX instances.

Otherwise the amount of work needed to make FreePBX do what you are going to want it to do for an ITSP/VoIP provider, it’s going to require a lot of work and not something that should be done with a single FreePBX box.

I really beg to differ. I have a PBX system for a 5 location company that is running 650+ Chan_SIP endpoints and a dozen PJSIP endpoints along with 6 provider trunks. The system, built for this size of use, is purring along just fine and could support 100’s more right now.

This is not really a FreePBX limit. This is ultimately a resource question.

  1. What will these trunks be doing?
  2. Is the system proxying audio?
  3. Transcoding?
  4. Call recording?
  5. What codecs?
  6. How many active?

In a generic theoretical world my raspberry pi can have 250,000 trunks.


Thank you for the feedback Dave. Can you provide some detail on what other solutions you would recommend here? Maybe a SBC?

This sounds like a terrific application for an SBC.

Personally, I’d call Sangoma Sales and talk to them (now that they’re all back from vacation in Orlando). I’m sure they can offer several solutions that will meet your specific requirements. In addition to FreePBX - I’ve been working with them since their early days working with IBM HDLC interfaces, and they offer a deep catalog of solutions.

Hi Tom, ok let me clarify:

When you are referring to “trunks” are you referring to connections between the PBX and an upstream provider (like VoIP Innovations) or are you referring to actual phones/users?

Yes, I’m referring to connections between the PBX and an Upstream provider. No phones/extensions

Now if this is the former, then that begets the question: How many end users/phones will there be? As well as if this is some sort of provider aspiration, I’m going to tell you right now from experience. FreePBX is not an ITSP/VoIP provider solution unless you are giving individual customers their own PBX instances.

There’s only 10 Extensions in use (Receptionists). The company looking for this solution provides a Virtual Office service which means that they answer phones for 100’s of business - this is where the requirement for the 100’s of SIP trunks are coming in.

  1. What will these trunks be doing? They will handle incoming calls which are then transferred to cellhphones/mobile phones
  2. Is the system proxying audio? Not sure
  3. Transcoding? Not sure, the calls come in via VOIP trunk but then gets transferred to a cellphone/mobile phone on a GSM network.
  4. Call recording? Yes
  5. What codecs? G729
  6. How many active? Concurrency I don’t think will ever exceed 15

There is no need/point to have 100’s of sip trunks.
It adssunnecessary administrative effort and registration traffc
A single sip trunk can handle 1000s of did numbers, split among concurent channels.
If you have 10 receptionists, you can be well off with 20 concurrent channels.
Talk to your sip provider. They should be able to both allocate you with ranges of numbers (to be further assigned to customers) and manage number portability of existing customers to your trunk.

And yes, freepbx and asterisk is well suited for this task.

Hi Stom, thank you for your reply. I considered the option of having one SIP trunk with hundreds of DID’s but the problem here is that each client needs to be billed for their usage (transfers to mobile phone) and although it would probably be possible it would be a nightmare to administrate on the billing side. So we are back at setting up 100’s of trunks. I noticed elsewhere that someone mentioned it would only be able to handle 999 trunks to due the number/id scheme (it might have been old reply on a previous version of FreePBX though).

Well, since you are building a service, you also have to administer and charge secreterial services, mails, and such.
It’s definitely not a nightmare to do billing.
Select a voice provider that can supply detailed cdr’s with cost.
With a litte carefull design summing up the outbound telephone cost for each client is straight forward report
Even if you opt for 100’s of trunks, then you also have to pay for each one, sum, and pass over the cost to the customer.
And I doubt you will ever get a single report for hundreds of trunks.
For sure, administering 100’s of trunks is a definitive nightmare too.

Most probably you don’t need an sbc for this situation and since the number of calls is low, everything else is irrelevant.
I can’t say if there is a hard limit on the number of trunks, but it is still a nightmare.


Not an advertisement, but from experience, I know that Voip Innovations will let you download a CSV that you can then import into almost any billing package. This is exactly how I handle my “local calls are free from prison” service. I download the CSV by DID and load it into a connector I wrote for QuickBooks.

So does almost everyone like Vitelity, Flowroute, Twilio, etc, etc, etc.

I don’t use any of the others - that’s why I said

I use this feature at VI to do what the OP wants to do. If other providers support DID-level downloads, then other providers can do this.

Yup, that’s why I offered up additional lists of providers in conjunction with yours. It’s pretty much a standard feature.

Thanx for the replies guys, my VOIP provider off course offers CDR records but we have a system where we put a limit on each customers account which is crucial for us and I won’t be able to do this when using 1 SIP Trunk.

This is where a SIP Proxy/SBC is needed. I do thousands of calls for 100’s of customers over “a single trunk” and i can control their channels, what they can dial and i can bill them without issue.

This goes back to my previous statement. You cant provide this type of service with just FreePBX.

I get the feeling we’re not going low enough.

A SIP Trunk connects an instance of FreePBX to an ITSP’s server (using Chan-SIP) or to a network of provider servers (using PJ-SIP). The trunk is the conduit by which calls are delivered to your server. It isn’t associated with a single number, or single account - it’s just the connection to the server.

In an automotive example, the trunk is the highway that connects one city to another. You wouldn’t set up an autobahn from Mannheim to Miesau for every resident of Miesau, you’d have everyone in Miesau use the A6 until they get into their neighborhood. After that, you’d route them to the specific house they are looking for.

In the ISO Network model, PBX trunks correspond loosely to layers 2 or 3. The inbound route and outbound route use those established connections to send phone calls to the ITSP. This looks a little like ISO layer 4 and 5. Asterisk will send the call over whichever trunk is first (alphabetically) in the acceptable sequence. Same with the inbound calls - if the call is coming from your ITSP, the likelihood is that all of your calls from that provider (regardless of the DID) will come in through that single trunk.

I wouldn’t even do this with SIP trunks, personally… I’d probably drop in a T1 (or two) and port the numbers to it…

Sorry, if you need “dial tone reliability”, copper is the only way that I would guarantee that.

1 Like

I think at the end of the day the issue here is that the voice part isn’t the real issue that has to be resolved. Let’s look at the logic behind the need for 600-2000 trunks, accounting. Having a trunk per account/DID allows the accounting to be simple and easy.

Let’s be honest, it doesn’t matter if this is delivered over 600 trunks, 1 trunk or 20 PRI’s the actual voice part of routing the calls, setting up the extensions, queues, etc, etc is the easy part. The bump in the road here is a business need issue not really a technical one because they still need to be able to bill those calls so the call delivery method isn’t a problem per se. On top of that there are CDRs generated that could be used to parse calls based on DIDs.

Part of “1:1” logic being used by the OP is that the billing is also simplified because most of the work is done by the provider. Provider present a bill that is 100% related to the user’s trunk, 1:1, based on that bill you know exactly what to charge that user. When you introduce using CDR based billing (multiple DIDs over a single trunk) or Asterisk CDRs you are turning it into a Many:Many solution where the CDRs now need to be matched to an end user and generated into one invoice for said end user.

@stom was pretty on point here. This is a service being built where FreePBX is a tool/piece needed for the service to be performed/delivered. There are numerous other aspects here that are variables in the data needed to provide a even near accurate or viable solution/advice for the OP.