[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