Hi all, I wanted to implement call rate limits using this Lua instruction: session:execute("limit", "hash " .. billedcaller .. " caps 10/1 !REQUESTED_CHAN_UNAVAIL") It is actually working, but the rest of the Lua dialplan is still processed, which is a problem in my case. I made a dirty but quick workaround, looking like this: rate_var = session:getVariable("limit_rate_" .. billedcaller .. "_caps") if not rate_var then logz("[Calls limit] CAPS limit reached for " .. billedcaller .. ", aborting the dialplan.") return end How can it be done properly? Is there a way to be able to get the result of the 'limit' app call? Or shall I check the status of the a-leg just after to decide to process the rest of the dialplan or not? I know that this issue doesn't occur in a 'pure' XML dialplan, but I'm trying to find a solution for my Lua-only dialplan. Thanks in advance if you have any idea. I'm willing to try any possible solution you would think about! Florent
Some context here would be helpful. Can you pastebin your Lua script, or at least the relevant lines that demonstrate what is happening? Also, when you say that the rest of the Lua dialplan is still processed, what does that mean? -MC From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Florent Krieg Sent: Thursday, March 12, 2015 11:43 AM To: FreeSWITCH Users Help Subject: [Freeswitch-users] Limit application usage in Lua Hi all, I wanted to implement call rate limits using this Lua instruction: session:execute("limit", "hash " .. billedcaller .. " caps 10/1 !REQUESTED_CHAN_UNAVAIL") It is actually working, but the rest of the Lua dialplan is still processed, which is a problem in my case. I made a dirty but quick workaround, looking like this: rate_var = session:getVariable("limit_rate_" .. billedcaller .. "_caps") if not rate_var then logz("[Calls limit] CAPS limit reached for " .. billedcaller .. ", aborting the dialplan.") return end How can it be done properly? Is there a way to be able to get the result of the 'limit' app call? Or shall I check the status of the a-leg just after to decide to process the rest of the dialplan or not? I know that this issue doesn't occur in a 'pure' XML dialplan, but I'm trying to find a solution for my Lua-only dialplan. Thanks in advance if you have any idea. I'm willing to try any possible solution you would think about! Florent
Hi Michael, Actually, here is what happens: Context: XML dialplan with the following extensions: <extension name="limit_exceeded"> <condition field="destination_number" expression="^limit_exceeded$"> <action application="respond" data="503"/> </condition> </extension> <extension name="outgoing_call"> <condition> <action application="lua" data="dialplans/caller_script.lua"/> </condition> </extension> 1/ a call is started, the second extension entry in the XML dialplan matches and the action starts the lua script 2/ after having set some (a lot actually) variables, here is the code part for checking call-rate limits: -- Security (to avoid outage): limit CAPS -- hash backend is needed when using interval -- 2 call attempts per 10 seconds here logz("[Calls limit] Checking caps for " .. billedcaller) session:execute("limit", "hash " .. billedcaller .. " caps 2/10 !REQUESTED_CHAN_UNAVAIL") rate_var = session:getVariable("limit_rate_" .. billedcaller .. "_caps") if not rate_var then logz("[Calls limit] CAPS limit reached for " .. billedcaller .. ", aborting the dialplan.") return end 3/ after this code part, a lot of processing is done (for instance checking call restrictions calling external web services and so on), it's like 600 lines of lua there 4/ in the end, the session:execute bridge app is run At 2/, when limit is exceeded, I see in the log: 2015-03-13 12:22:40.454660 [INFO] switch_cpp.cpp:1328 * (caller/0) # 7a16c525263a8bb740517f5a28552016@trunkinge.voip * [Calls limit] Checking caps for asteriskrd@trunkinge.voip EXECUTE sofia/internal_auth/asteriskrd@trunkinge.voip limit(hash asteriskrd@trunkinge.voip caps 2/10 !REQUESTED_CHAN_UNAVAIL) 2015-03-13 12:22:40.454660 [DEBUG] switch_limit.c:126 incr called: asteriskrd@trunkinge.voip_caps max:2, interval:10 2015-03-13 12:22:40.454660 [INFO] mod_hash.c:176 Usage for asteriskrd@trunkinge.voip_caps exceeds maximum rate of 2/10s, now at 3 2015-03-13 12:22:40.454660 [INFO] switch_cpp.cpp:1328 * (caller/0) # 7a16c525263a8bb740517f5a28552016@trunkinge.voip * [Calls limit] CAPS limit reached for asteriskrd@trunkinge.voip, aborting the dialplan. and the a-leg is successfully hangup. But here, 3/ and 4/ are aborting only because of that code part: rate_var = session:getVariable("limit_rate_" .. billedcaller .. "_caps") if not rate_var then logz("[Calls limit] CAPS limit reached for " .. billedcaller .. ", aborting the dialplan.") return end It works, but I'm pretty sure that it is not the proper way to do it. If I remove that code part, even though the a-leg is hangup because of the leg being transferred to 'limit_exceeded', the rest of the dialplan is still processed, even though the call is aborted. I'd like to be able to catch right after doing session:execute limit app, the return of the command. If the call is transferred to 'limit_exceeded', then I'd like to abort the rest of the dialplan execution. I have to admit I might be missing something here therefore if you can help me, that'd be amazing. Thanks in advance Florent 2015-03-12 21:28 GMT+01:00 Michael S Collins <msc@freeswitch.org>:
Some context here would be helpful. Can you pastebin your Lua script, or at least the relevant lines that demonstrate what is happening? Also, when you say that the rest of the Lua dialplan is still processed, what does that mean?
-MC
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *Florent Krieg *Sent:* Thursday, March 12, 2015 11:43 AM *To:* FreeSWITCH Users Help *Subject:* [Freeswitch-users] Limit application usage in Lua
Hi all,
I wanted to implement call rate limits using this Lua instruction: session:execute("limit", "hash " .. billedcaller .. " caps 10/1 !REQUESTED_CHAN_UNAVAIL")
It is actually working, but the rest of the Lua dialplan is still processed, which is a problem in my case.
I made a dirty but quick workaround, looking like this: rate_var = session:getVariable("limit_rate_" .. billedcaller .. "_caps") if not rate_var then logz("[Calls limit] CAPS limit reached for " .. billedcaller .. ", aborting the dialplan.") return end
How can it be done properly?
Is there a way to be able to get the result of the 'limit' app call?
Or shall I check the status of the a-leg just after to decide to process the rest of the dialplan or not?
I know that this issue doesn't occur in a 'pure' XML dialplan, but I'm trying to find a solution for my Lua-only dialplan.
Thanks in advance if you have any idea.
I'm willing to try any possible solution you would think about!
Florent
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
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
I think what you did is not a dirty hack but normal scripting. You cannot exit or stop in the middle of lua script. Just let it finish its job 13 марта 2015 г. 17:32 пользователь "Florent Krieg" <flokrrr@gmail.com> написал:
Hi Michael,
Actually, here is what happens:
Context: XML dialplan with the following extensions: <extension name="limit_exceeded"> <condition field="destination_number" expression="^limit_exceeded$"> <action application="respond" data="503"/> </condition> </extension> <extension name="outgoing_call"> <condition> <action application="lua" data="dialplans/caller_script.lua"/> </condition> </extension>
1/ a call is started, the second extension entry in the XML dialplan matches and the action starts the lua script 2/ after having set some (a lot actually) variables, here is the code part for checking call-rate limits: -- Security (to avoid outage): limit CAPS -- hash backend is needed when using interval -- 2 call attempts per 10 seconds here logz("[Calls limit] Checking caps for " .. billedcaller) session:execute("limit", "hash " .. billedcaller .. " caps 2/10 !REQUESTED_CHAN_UNAVAIL") rate_var = session:getVariable("limit_rate_" .. billedcaller .. "_caps") if not rate_var then logz("[Calls limit] CAPS limit reached for " .. billedcaller .. ", aborting the dialplan.") return end 3/ after this code part, a lot of processing is done (for instance checking call restrictions calling external web services and so on), it's like 600 lines of lua there 4/ in the end, the session:execute bridge app is run
At 2/, when limit is exceeded, I see in the log: 2015-03-13 12:22:40.454660 [INFO] switch_cpp.cpp:1328 * (caller/0) # 7a16c525263a8bb740517f5a28552016@trunkinge.voip * [Calls limit] Checking caps for asteriskrd@trunkinge.voip EXECUTE sofia/internal_auth/asteriskrd@trunkinge.voip limit(hash asteriskrd@trunkinge.voip caps 2/10 !REQUESTED_CHAN_UNAVAIL) 2015-03-13 12:22:40.454660 [DEBUG] switch_limit.c:126 incr called: asteriskrd@trunkinge.voip_caps max:2, interval:10 2015-03-13 12:22:40.454660 [INFO] mod_hash.c:176 Usage for asteriskrd@trunkinge.voip_caps exceeds maximum rate of 2/10s, now at 3 2015-03-13 12:22:40.454660 [INFO] switch_cpp.cpp:1328 * (caller/0) # 7a16c525263a8bb740517f5a28552016@trunkinge.voip * [Calls limit] CAPS limit reached for asteriskrd@trunkinge.voip, aborting the dialplan.
and the a-leg is successfully hangup.
But here, 3/ and 4/ are aborting only because of that code part: rate_var = session:getVariable("limit_rate_" .. billedcaller .. "_caps") if not rate_var then logz("[Calls limit] CAPS limit reached for " .. billedcaller .. ", aborting the dialplan.") return end
It works, but I'm pretty sure that it is not the proper way to do it.
If I remove that code part, even though the a-leg is hangup because of the leg being transferred to 'limit_exceeded', the rest of the dialplan is still processed, even though the call is aborted.
I'd like to be able to catch right after doing session:execute limit app, the return of the command. If the call is transferred to 'limit_exceeded', then I'd like to abort the rest of the dialplan execution.
I have to admit I might be missing something here therefore if you can help me, that'd be amazing. Thanks in advance Florent
2015-03-12 21:28 GMT+01:00 Michael S Collins <msc@freeswitch.org>:
Some context here would be helpful. Can you pastebin your Lua script, or at least the relevant lines that demonstrate what is happening? Also, when you say that the rest of the Lua dialplan is still processed, what does that mean?
-MC
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *Florent Krieg *Sent:* Thursday, March 12, 2015 11:43 AM *To:* FreeSWITCH Users Help *Subject:* [Freeswitch-users] Limit application usage in Lua
Hi all,
I wanted to implement call rate limits using this Lua instruction: session:execute("limit", "hash " .. billedcaller .. " caps 10/1 !REQUESTED_CHAN_UNAVAIL")
It is actually working, but the rest of the Lua dialplan is still processed, which is a problem in my case.
I made a dirty but quick workaround, looking like this: rate_var = session:getVariable("limit_rate_" .. billedcaller .. "_caps") if not rate_var then logz("[Calls limit] CAPS limit reached for " .. billedcaller .. ", aborting the dialplan.") return end
How can it be done properly?
Is there a way to be able to get the result of the 'limit' app call?
Or shall I check the status of the a-leg just after to decide to process the rest of the dialplan or not?
I know that this issue doesn't occur in a 'pure' XML dialplan, but I'm trying to find a solution for my Lua-only dialplan.
Thanks in advance if you have any idea.
I'm willing to try any possible solution you would think about!
Florent
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
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 (3)
-
Florent Krieg
-
Kamil Nigmatullin
-
Michael S Collins