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