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 what scenarios).
Regards,
Bogdan
Ovidiu Sas wrote:
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 for the server itself or better subscriber management.
Setting a ratelimit for a SIP account that has a channel limit of two
is an overkill, IMHO.
Ratelimit-ing really makes sense for large SIP trunks and whole SIP
traffic (server protection).
Regards,
Ovidiu Sas
On Fri, Feb 25, 2011 at 11:59 AM, Bogdan-Andrei Iancu
<[email protected]> wrote:
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 more important
things to do and resources are limited ;)
Regards,
Bogdan
Ovidiu Sas wrote:
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 calls and the calls are coming in at a rate
of 1 cps, in 30s you will reach your limit. If the calls are coming
in at a rate of 15 cps, you will reach the limit in 2s.
With the ratelimit module, you limit _only_ the number of calls per
second that are processed.
If you set a cps limit of 5 cps and your incoming traffic is 100cps,
then every second the first 5 calls will go through and the next 95
will be rejected (based on TAILDROP algorithm). If the traffic is
steady for 10s, then you will have 10x5=50 active calls and 10x95=950
rejected calls due to cps limitation.
Now, if you combine both (30 channels max and 5cps limit for incoming
traffic at 100 cps), during the first 6s you will saturate the trunk
(by accepting the first 5 calls and rejecting the other 95 every
second) and all calls after that will be rejected.
Hope this helps.
Regards,
Ovidiu Sas
On Wed, Feb 23, 2011 at 12:51 PM, Ronald Cepres <[email protected]>
wrote:
On Wed, Feb 23, 2011 at 6:10 AM, Ovidiu Sas <[email protected]>
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).
Hi Ovidiu,
Does that mean that if i have a concurrent call limit of 30 for a user
and
he bursts 500 cps, he still wouldn't exceed 30 cps?
By the way, I use a method similar to the one posted in the tutorials to
limit concurrent calls
(link: http://www.opensips.org/Resources/DocsTutConcurrentCalls)
Thanks!
Regards,
Ronald
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 28th February 2011
OpenSIPS solutions and "know-how"
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 28th February 2011
OpenSIPS solutions and "know-how"
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
