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 or channel limit), the next GW was used. Hope this helps.
Regards, Ovidiu Sas On Fri, Feb 25, 2011 at 12:51 PM, Ronald Cepres <[email protected]> wrote: > 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, > Ronald > > On Sat, Feb 26, 2011 at 1:09 AM, Ovidiu Sas <[email protected]> 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 >> > >> >> _______________________________________________ >> 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 > > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
