I’m having an issue that is a bit of a continuation of a topic brought up here but cannot find the answers that I need without getting a little confused. How do I restrict the amount of calls coming into a certain DID on a T1 PRI trunk?
A little bit more about the setup… This is for four radio stations with two, T1 PRI connections with 4 DIDs on a hunt style trunk into our FreePBX 14 (Asterisk 13) server, giving us a total of 46 available lines for listener call-ins.
Each radio station control room only has 10 lines to answer via SIP. This week, one of the stations is doing a giveaway that has surprisingly overloaded the system. All 10 lines into that control room fill up but the entire trunk of 46 lines between the two PRI’s jam up with callers and drive the CPU usage of the asterisk service on the server to 115%, causing stuttering and choppy audio of the phone calls across the entire plant. So I need to figure out how to handle spikes of call loads like this. We’ve been running this setup for several months, but this has suddenly popped up with this giveaway.
What I want to do is limit the number of calls per the four DIDs that are on that trunk to 10 channels. I see a couple of options but am not sure which is the best course of action.
First, restrict the “Maximum Channels” in the trunk settings to 10, but that only limits the outbound channels. Outbound calls are actually routed back out through our business Nortel PBX via a PRI on the first span of the four port Digium PRI card, so I’m not sure this would work because the tool tip says “Inbound calls are not counted against the maximum”.
Another way is to find a way to restrict the number of inbound channels per DID to 10 on the trunk, but I cannot find where this would be setup. Ideally, when call 11 comes in to that DID, it would be dropped. Is that even possible in this version of asterisk 13?
And then based on what I’ve seen recommended elsewhere, using a queue would do this as well, but does anyone have any insight on how I would set this up to work efficiently as possibly? By that, I mean certain settings to make sure this works how these calls flow now but without anything that would drive the server into the ground trying to process the queues because I’d have to enable this for all four radio stations. I have to pass the queue of calls into the control room and then dump anything beyond the first 10 callers as the rest of them come in.
The first, and most obvious, is to ask your service provider to limit each trunk to a dozen or so calls. If they hunt across the T1s, though, they’ll just fail over to the next trunk, which fails your system again.
A second, and more controllable, is to write a special inbound context that looks at the number of calls in progress to a particular DID and just dump the overflow into a hang-up destination. This will keep your PBX clearer by reducing the call load, theoretically. Note that you will still get all your channels filled up, but it’s going to be with lots of really short calls.
For my radio station our SIP/PRI provider was able to do this in their CCP programing. They set the maximum number of concurrent call paths per DID and dropped the rest. It took finding a provider who was able to work with us. We started with the LEC and during big promotions we would cause the entire town to have delayed dial tone.
Ok, I’m starting the chase with our provider to see about limiting the inbound calls coming in on those DIDs. This is a rabbit hole I wanted to bypass if I could, but that makes the most sense. We don’t need all of those calls coming in anyway!
One solution is to filter the calls through a toll-free number where you can negotiate the number of concurrent calls forwarded to your did. Some telcos get very grumpy and shut your circuit down if you don’t previously arrange for very high volume at for example game show call ins or even publication of job opening opportunities
So, why not put them into a call queue, or have a “Sorry, you’re caller number 1”, “Sorry, yo’ure caller number 2” sort of script that I"ve seen on this site before?
It seems to me that was @munozj that posted that script. While I’m all about sharing information and improving the system through community involvement, this really sounds like a case where @munozj and @johnbollwitt should connect as a little sub community. They are in the same industry and have similar issues. I’m not saying “take this conversation out of here”, but they speak the same language and have similar goals.
We’re still here for the rest of the questions, but these two can probably go a long way together.
Thanks, @dicko. We’ve had these PRI lines for nearly five years now, and they’ve always been problematic. We always thought it was the the network, but it keeps coming back to this server being the main culprit. I did an install of a v14 system back in the spring and was impressed with it way more than the v12 we were running that I implemented v14 back in our location, and it’s worked outstandingly for almost four months until just recently. People just really like free stuff, especially when it’s a trip to the tropics.
I actually implemented what @gbaughma kind of suggested and setup queues that dumps any calls outside of the 10 lines to each control room. It’s working as it should, but I still don’t know if that handles the load issue just yet. If anything, it’s clearing the channels faster than it takes for a caller to hang up a busy line. The feature @lgaetz pointed out would certainly help!
As @munozj and @cynjut suggested, I’m also chasing down the telco provider on this and seeing about limiting the amount of concurrent calls to those DIDs to 12 at most, but that’s like moving mountains.
A full PRI (in the US) can maintain 23 calls , all calls are processed in the d-channel, but the treatment of any prioritization is only available to the povider, and they really don’t want to do that, further, if their equipment is overloaded by 1000 calls at 8:01am it impacts the way their equipment handles both your calls and your peers calls, they are obliged to return to the caller a response and are generally not particullary caring todo your prioritizations on an ad-hoc fashion defined by you. the toll-free solution moves the onus to the “resp-org” and the contract they have with you, toll-free numbers are “virtual” they can only be forwarded to a PSTN number for termination, and yes it is possible they are the provider of the PSTN number also, That is why the cost more and are better for broadcast situations that as you see can be very “spiky”