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