There are mechanisms for limiting outbound calls based on concurrent channel counts, and there are (clumsy?) ways of including inbound channels in the count for limiting outbound calls, but there is no stock FreePBX feature that allows inbound calls to be blocked based on total inbound channel count. But it can be done with the Dynamic Routes module.
See this post for background: Checking Queue Caller Count with Dynamic Routes
Suppose you have a tiny office of a few people which very rarely gets a surge of inbound calls. You don’t want to go thru the complexity of setting up a queue but would prefer to just always send surplus calls direct to voicemail. Or perhaps you want to just immediately terminate all surplus inbound calls by giving them a busy signal.
Config dynroute #1 with Asterisk Variable selected for source type and the asterisk expression:
${SET(GROUP()=inbound)}
All calls going thru this dynroute destination will be tagged as being part of the ‘inbound’ group.We don’t branch the call at this point, callers all go to dynroute #2 with the default destination.
Create dynroute #2 using Asterisk Variable source type, disable substitution and use this expression:
$[${GROUP_COUNT(inbound)} > 4]
The above expression will get the total number of active channels in the inbound group and return 1 if that count is greater than 4. Otherwise it returns 0. You can then config dynroute destinations for 0 and 1 with how you want to route calls. In the GUI it would look something like this:
Inbound calls go to a ring group until the max number of concurrent inbound channels hits 5 and then it just sends the caller to busy. It could easily go to VM or whatever other destination you prefer.
Pro Tip - Instead of using dynroute #1 to tag the inbound channel, you could use a user defined context for the trunk so that all inbound calls on the trunk are tagged. Could be useful in cases where you needed to tag calls over multiple inbound routes.
NOTE - If you’re attempting to set up inbound concurrency limits to mitigate a DOS attack or a huge influx of calls that might exhaust resources, this may work a bit, but would still result in
system resources for each call. Better to limit concurrent calls at the provider level for that use case.