[VoiceOps] Call Rate Limiting / Blocking (AcmePacket + Broadsoft NS)
Ryan Delgrosso
ryandelgrosso at gmail.com
Mon Feb 20 16:09:09 EST 2012
IANAL but I think the behavior you are seeking is essentially a choke
trunk, and so is perfectly legal.
In the acme there are session constraints that can be applied at a
per-agent and per-realm level, but I am not aware of any functionality
to apply session limiting by originating or terminating number.
Some strategies you might try using session constraints:
If the traffic can be isolated to be coming from a specific session
agent, you can apply constraints there, limiting calls per second (with
burst capacity). When that call per second rate is exceeded, the SD will
send back 503's to the agent in response to all new requests until the
rate across the tolerance window falls.
If the traffic comes from a wide range of agents, applying it at the
agent level still leaves an aggregate throughput high enough to choke
you, so you might consider putting those agents into their own realm and
applying it at the realm level (or sub-realm if you dont want to give it
its own media resources). Be aware when the constraints are hit in this
case the SD rejects anything in that realm until it falls sufficiently.
If all your inbound comes from a common provider so you cant just pick
it out by session agent, then a third option would be to ensure your
origination and termination traverse different core-side realms and
apply your rate limiting there, so even in a flood scenario where your
inbound is being flooded, and the SD is doing damage control on your
origination trunk by rate limiting to the switch at the egress realm
level, you would still have unimpeded termination. Below is a quick
Provider ---> SBC ---> Core-origination realm (constraints here) --->
Softswitch
Provider <--- SBC <---- Core-Termination realm
<------------------------- Softswitch
In the scenario above it is important to break it out like this even
though the SD does have different inbound and outbound constraint
settings since the realm/agent will be taken out of service when the
constraint it hit.
On 02/20/2012 07:52 AM, Keith Croxford wrote:
>
> I'm looking for input from other voice providers:
>
> We have an off-net number that periodically floods our network with
> inbound calls. When this happens our NS ( Broadsoft) often reaches or
> exceeds the number of available licenses. The end result is that new
> call requests fail until the call volume decreases. This usually last
> for 5-10 seconds.
>
> We have a cluster of AcmePacket SBCs in front of Broadworks. Does
> anyone know if it is possible to limit the calls per second on a
> dynamic originating number? I say this as the originating caller might
> be 555-555-1111 for 10 minutes, then another flood of calls originates
> from 444-444-2222 a few hours later. We believe these to be from the
> same caller due to the IVR message presented.
>
> If it is possible would the AcmePacket SBC perform this as an HMR in
> software, or would the SBC hardware handle this? If the SBC cannot
> do this, is it possible to perform some sort of dynamic rate limiting
> on a Broadsoft NS and send a failure response code w/a reason code
> after a metric is breached? Any other suggestions would be great.
>
> The last question involves legal implication of blocking a number.
> Assume that we blocked all calls from 555-555-1111 at our SBC. Two
> weeks from now Customer A opens a trouble ticket that their customer
> cannot call them. Of course the company's main line happens to be
> 555-555-1111. Is there any FCC rule or regulation that would limit
> this. I'm trying to find something in Title 47 of the Code of Federal
> Regulations...
>
> Thanks!
>
> Keith
>
>
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20120220/dd835e02/attachment.html>
More information about the VoiceOps
mailing list