[Freeswitch-users] Mod_limit stuck when hitting limit value

Mathieu Rene mrene_lists at avgs.ca
Fri Mar 13 09:26:05 PDT 2009 

Yeah, you should be using limit_hash unless you need data replication  
on multiple FS boxes since its a lot faster.

You can also do <action application="limit_hash realm id max/rate ! 
bearercapability_notavail" />
On another note, normal_circuit_congestion looks like a more  
appropriate cause.

If you have problems, please open a jira including logs and a detailed  
description of the required steps to reproduce the problem.

Math

On 13-Mar-09, at 12:19 PM, Tamas Cseke wrote:

> Hello,
>
> Thank you for your help.
>
> limit,Limit,<realm> <id> [<max> [number [dialplan [context]]]]
> limit_hash,Limit (hash),<realm> <id> [<max>[/interval]] [number
> [dialplan [context]]]
>
> I diged into mod_limit deeplier and as far as I understand, limit and
> limit_hash can be used for the same thing:
> limiting concurrent calls. please correct me, if I'm wrong...
>
> but limit_hash has another feature /interval this is that make the  
> rate
> limitation you mentioned.
>
> Our dialplan is good that is out of question. I see hangup in console.
> we do <action application="hangup" data="BEARERCAPABILITY_NOTAVAIL"/>
>
> I tested both of them with sipp and I wasn't able to reproduce the  
> problem
>
> r12581 did fix the case when limit is called more times, right?
>
> Thanks,
> Tamas
>
>
> rod írta:
>> Hello,
>>
>> I'm now running r12590, the pbm was still there, but this was  
>> because of
>> a broken dialplan.
>>
>> I'm using this for exceeded limit:
>> <extension name="TOO_MANY_CALLS">
>>        <condition field="destination_number"  
>> expression="^limit_exceeded$">
>>          <action application="respond" data="503"/>
>>          <action application="hangup"/>
>>        </condition>
>>    </extension>
>>
>> but this extension was at the end of my dialplan and I matched an  
>> other
>> extension before reaching the limit extension.
>> What was odd was that in ngrep I saw FS sending a 503, I will
>> investigate on this.
>>
>> I will rerun long term test and let you know if all is ok, so I  
>> have to
>> do for a previous mail related to ghost sessions in CLI.
>>
>> @Tamas:
>> I just give a try to limit_hash, and didn't make many tests with it.
>> It's on my todo list. Limit_hash is not a better choice than limit,
>> their usage are different:
>>    - limit_hash is a good way to rate limit a specific gateway for
>> example so that your switch won't be flooded by a misconfigured  
>> peer gw
>>    - limit is for limiting concurrent call to an extension/gateway,  
>> eg
>> you have a peer that provides you with 30channels and you want to  
>> allow
>> 15 channels for mobile (PLMN) and 15 for PSTN without relying
>>
>> If you still have pbm with limit and svn, pay attention to you  
>> dialplan :p
>>
>> @Mathieu
>> I hope you didn't work on a virtual pbm, cause it seems to be a  
>> dialplan
>> misconfiguration. I'll let you know if I still have pbm. Thanks for  
>> your
>> help.
>>
>> regards.
>> rod
>>
>> Tamas Cseke wrote:
>>
>>> Hello,
>>>
>>> we had the same problem. we couldn't test r12581 for sure yet, but  
>>> we will.
>>> This fix is only for the limit (db version), right?
>>> Would be limit_hash a better choice to increase performance anyway?
>>> Rod, do yoo have maybe experiences with limit_hash with your sipp?
>>>
>>> Thanks in advance,
>>> Tamas
>>>
>>>
>>> Mathieu Rene írta:
>>>
>>>
>>>> Were you doing transfers (action="transfer" in the dialplan) ?
>>>>
>>>> If yes, retry with revision 12581, and open a JIRA if it still is  
>>>> an
>>>> issue (also include a full debug log (delete your freeswitch.log  
>>>> file
>>>> before doing your test and attach it after) in your JIRA)
>>>>
>>>> Math
>>>>
>>>> On 12-Mar-09, at 10:12 AM, rod wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> Hi list,
>>>>>
>>>>> I'm testing mod_limit like this:
>>>>>       <action application="set" data="max_calls=60"/>
>>>>>       <action application="set" data="GW_IP=10.10.20.100"/>
>>>>>       <action application="limit" data="${AREA} ${GW_IP} $
>>>>> {max_calls}"/>
>>>>>
>>>>> where AREA could be any value like: US/EUROPE/AFRICA... that has  
>>>>> been
>>>>> set for the call
>>>>>
>>>>> then I use sipp for load testing with 4 cps and max 65 calls so  
>>>>> that I
>>>>> will be limited by the limit of 60 in the dialplan.
>>>>>
>>>>> I use "limit_usage EUROPE 10.10.20.100" in cli and I see the limit
>>>>> value
>>>>> growing up to 60.
>>>>>
>>>>> Sipp still tries to establish new call (up to 65 calls) at 4cps  
>>>>> and
>>>>> for
>>>>> each new cps in excess, FS sends a 503.
>>>>> I wait for 10 seconds and stop sipp, but the limit value is never
>>>>> decreasing even when there is no more channels used (show  
>>>>> channels),
>>>>> the
>>>>> limit value is stuck to 60.
>>>>>
>>>>>
>>>>> If I limit Sipp to 55 calls (below the limit value), the limit  
>>>>> value
>>>>> increase and decrease depending on load, and the pbm doesn't  
>>>>> appear.
>>>>>
>>>>> Does anybody is using mod_limit and have encountered the same pbm.
>>>>>
>>>>> I'm using latest svn: 12580.
>>>>>
>>>>> regards,
>>>>> rod
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Freeswitch-users mailing list
>>>>> Freeswitch-users at lists.freeswitch.org
>>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>>>> http://www.freeswitch.org
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Freeswitch-users mailing list
>>>> Freeswitch-users at lists.freeswitch.org
>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>>> http://www.freeswitch.org
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Freeswitch-users mailing list
>>> Freeswitch-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> Freeswitch-users mailing list
>> Freeswitch-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>>
>
>
> _______________________________________________
> Freeswitch-users mailing list
> Freeswitch-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org

More information about the FreeSWITCH-users mailing list