Hi everyone,
I would like to ask all of you if it is possible to use ratelimit module to
limit cps per account/group (i.e.: account A has limit of 10 cps, account
B's is 20 cps, etc.)? Is it even possible to implement this set-up on
opensips?
Thanks for any kind of help.
Regards,
Ronald
Yes, you can do this with opensips. Just assign a pipe number to an
account and use that pipe to limit traffic for that account:
http://www.opensips.org/html/docs/modules/devel/ratelimit.html#id250282
For now, there is a limit of 16 pipes:
http://www.opensips.org/html/docs/modules/devel/ratelimit
Ronald,
I got into this very same question:
http://www.openser.org/pipermail/users/2009-November/009405.html
Despite my apparent enthusiasm at the time I never did implement anything
useful.
- Jeff
On 2/22/11 12:27 PM, "Ovidiu Sas" wrote:
>Yes, you can do this with opensips. Just assig
The ratelimit module was designed to deal with SIP trunks and not with
subscriber traffic.
Under normal circumstances, the subscriber traffic does not need to be
ratelimit-ed.
The pike module can be used to identify DoS traffic from a particular
subscriber and then take appropriate action.
Regards
Ovidiu,
With stolen account credentials one can cause major frauds during a single
weekend without looking like a DOS attack. Rate limiting of normal SIP accounts
to a few simultaneous calls or whatever is normal usage is the best defensive
strategy. Pike is not useful for non-DOS situations li
Indeed. We've had to resort to combing the accounting database after the
fact, and when certain minute volumes or calls-per-minute thresholds have
been exceeded, disable the trunk. This has saved us on more than a few
occasions.
Outside of fraudulant or DoS activities, it would be very useful to
On Tue, Feb 22, 2011 at 3:28 PM, Adrian Georgescu wrote:
> Ovidiu,
>
> With stolen account credentials one can cause major frauds during a single
> weekend without looking like a DOS attack.
That is correct, but I don't really see how ratelimitation would help
here for regular accounts.
A regula
On Tue, Feb 22, 2011 at 3:32 PM, Jeff Pyle wrote:
> Indeed. We've had to resort to combing the accounting database after the
> fact, and when certain minute volumes or calls-per-minute thresholds have
> been exceeded, disable the trunk. This has saved us on more than a few
> occasions.
>
> Outsi
On 2/22/11 11:10 PM, Ovidiu Sas wrote:
> If a virtual PRI is set up (23 channels for NA or 30 channels for
> Europe), again the cps doesn't really count. As soon as the virtual
> PRI is maxed out (in terms of channels) all subsequent calls will be
> rejected (and the cps will be 0).
I'd suggest n
On Wed, Feb 23, 2011 at 6:10 AM, Ovidiu Sas wrote:
>
> If a virtual PRI is set up (23 channels for NA or 30 channels for
> Europe), again the cps doesn't really count. As soon as the virtual
> PRI is maxed out (in terms of channels) all subsequent calls will be
> rejected (and the cps will be 0)
There are two different things:
a. channel limitation or concurrent call limit;
b. ratelimit or cps limitation (cps = cals per second).
With the dialog module, you limit _only_ the number of concurrent
calls (a). How fast will a SIP trunk be saturated is up to the cps.
If you have a limit of 30
Hi Ovidiu,
actually we were flirting for some time with extending the ratelimit
module to allow dynamic creation of pipes - this will give you more
flexibility in scripting and scenarios (like dynamic number of trunke,
DB provisioning, etc).But this was a bit postponed as there are
other
Hello Bogdan,
Just for the record, I am not against having more flexibility in
building scripts and new features (like dynamic creation of pipes) are
more then welcome. In my previous replies I was just pointing out
that ratelimit-ing basic accounts and small trunks doesn't add more
protection fo
Hi Ovidiu,
Some of my subscribers use dialers which has an average cps of 100. In this
case, does it still make sense to limit the rate of each subscriber? If it
is, is there a way to implement it, considering there are limited number of
pipes that can be used with opensips?
Thanks!
Regards,
Ron
That was the reason (back in the days for porting the ratelimit to
openser): dialers.
Dialers are capable of generating a high cps rate. In my case, I
needed to distribute the calls over several GWs, each GW having a
limit on cps and channel limit. When a GW trunk was saturated (in
terms of cps o
Hi Ovidiu,
I got your point - I was making a comment to complete your statement.
I agree that rate limit and concurrent call limit are 2 protection
mechanism that normally are more suitable in different scenarios.
But more or less, this is up to the admin to decide :) (which to use and
in wh
Hi Ovidiu and Bogdan,
I see your point. Thanks for clearing my thoughts about this issue!
Regards,
Ronald
On Sun, Feb 27, 2011 at 5:53 PM, Bogdan-Andrei Iancu wrote:
> Hi Ovidiu,
>
> I got your point - I was making a comment to complete your statement.
>
> I agree that rate limit and concurrent
17 matches
Mail list logo
