Mod_limit stuck when hitting limit value
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
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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
What is a pbm? On Mar 13, 2009, at 4:51 AM, rod <kawarod@laposte.net> 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 Freeswitch-users@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
My guess is: pbm = problem :) T. Michael Jerris írta:
What is a pbm?
On Mar 13, 2009, at 4:51 AM, rod <kawarod@laposte.net> 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 Freeswitch-users@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Hi, not too hard :p but it's just a bad habit when I write in my native language (french). I guess that this spelling is not too common for english speaker. I'll do my best next time to write it correctly. @tamas you are right, we could use limit_hash the same way as limit when not specifying the /rate @Mathieu did you suggest limit_hash is more scalable than limit? But I don't understand why limit_hash is not suitable for data replication (DB lookup for limit and memory for limit_hash??), even if I don't know how to do it with limit. regards. Raymond Chandler wrote:
Tamas wrote:
My guess is: pbm = problem :)
sure, but is it really that hard to spell all the way out?
-Ray
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
limit_hash uses a faster data structure then limit but works the same way for tne end-user. viens sur IRC si t'as des questions en francais =) Math On 17-Mar-09, at 3:06 AM, rod wrote:
Hi,
not too hard :p but it's just a bad habit when I write in my native language (french). I guess that this spelling is not too common for english speaker.
I'll do my best next time to write it correctly.
@tamas you are right, we could use limit_hash the same way as limit when not specifying the /rate
@Mathieu did you suggest limit_hash is more scalable than limit? But I don't understand why limit_hash is not suitable for data replication (DB lookup for limit and memory for limit_hash??), even if I don't know how to do it with limit.
regards.
Raymond Chandler wrote:
Tamas wrote:
My guess is: pbm = problem :)
sure, but is it really that hard to spell all the way out?
-Ray
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
thanks Mathieu. I setup an IRC account to give it a try. Comme ça je pourrais t'embeter avec mes "pbms" :p rod Mathieu Rene wrote:
limit_hash uses a faster data structure then limit but works the same way for tne end-user.
viens sur IRC si t'as des questions en francais =)
Math
On 17-Mar-09, at 3:06 AM, rod wrote:
Hi,
not too hard :p but it's just a bad habit when I write in my native language (french). I guess that this spelling is not too common for english speaker.
I'll do my best next time to write it correctly.
@tamas you are right, we could use limit_hash the same way as limit when not specifying the /rate
@Mathieu did you suggest limit_hash is more scalable than limit? But I don't understand why limit_hash is not suitable for data replication (DB lookup for limit and memory for limit_hash??), even if I don't know how to do it with limit.
regards.
Raymond Chandler wrote:
Tamas wrote:
My guess is: pbm = problem :)
sure, but is it really that hard to spell all the way out?
-Ray
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (6)
-
Mathieu Rene
-
Michael Jerris
-
Raymond Chandler
-
rod
-
Tamas
-
Tamas Cseke