My guess is: pbm = problem :) T.
Michael Jerris írta: > What is a pbm? > > On Mar 13, 2009, at 4:51 AM, rod <[email protected]> wrote: > > >> 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 >>>>> [email protected] >>>>> 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 >>>> [email protected] >>>> 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 >>> [email protected] >>> 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 >> [email protected] >> 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 > [email protected] > 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 [email protected] http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
