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 > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
