mod_limit does not reset count when call gets to voicemail?
Hello, We are using mod_limit in order to track user's state and know when to play busy/call-wait tone. We encountered two problems (which are probably related): - When the call gets to the voicemail the extension is still though as busy until the caller hangs. - If a call is picked-up using the intercept application the original destination is still thought as busy. When looking in the limit_data table the record of the call is indeed there until a final call hangup. According to the wiki we tried setting the variable limit_ignore_transfer to false both with set command before calling the limit application and also in limit.conf.xml. However, this does not change this behaviour. Is this the intended behaviour? Can it work as I want? (i.e. once the call arrived to voicemail or picked-up the original destination is marked as free). We are using 1.0.6; since this is a production system it is quite hard for me to test the latest git. Thanks! __Yehavi:
On Tue, Sep 28, 2010 at 3:26 AM, Yehavi Bourvine <yehavi.bourvine@gmail.com>wrote:
Hello,
We are using mod_limit in order to track user's state and know when to play busy/call-wait tone. We encountered two problems (which are probably related):
- When the call gets to the voicemail the extension is still though as busy until the caller hangs. - If a call is picked-up using the intercept application the original destination is still thought as busy.
When looking in the limit_data table the record of the call is indeed there until a final call hangup. According to the wiki we tried setting the variable limit_ignore_transfer to false both with set command before calling the limit application and also in limit.conf.xml. However, this does not change this behaviour.
Is this the intended behaviour? Can it work as I want? (i.e. once the call arrived to voicemail or picked-up the original destination is marked as free).
It is intended behavior. To handle voicemail, you could restructure your dialplan to: 1) set limit_ignore_transfer to false, then transfer to a VM handling extension. The act of transfering will reset the limit. 2) For intercept... you could use uuid_limit_release api. hmm.. This could also be used for 1. freeswitch@internal> uuid_limit_release USAGE: uuid_limit_release <uuid> <backend> [realm] [resource]
We are using 1.0.6; since this is a production system it is quite hard for me to test the latest git.
Thanks! __Yehavi:
_______________________________________________ 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
-- -Rupa
We are using 1.0.6; since this is a production system it is quite hard for me to test the latest git. FreeSwitch is pretty stable even with git releases. Give it a try and see what happens. You won't regret it ;)
On Tue, Sep 28, 2010 at 7:14 AM, Rupa Schomaker <rupa@rupa.com> wrote:
On Tue, Sep 28, 2010 at 3:26 AM, Yehavi Bourvine <yehavi.bourvine@gmail.com> wrote:
Hello,
We are using mod_limit in order to track user's state and know when to play busy/call-wait tone. We encountered two problems (which are probably related):
- When the call gets to the voicemail the extension is still though as busy until the caller hangs. - If a call is picked-up using the intercept application the original destination is still thought as busy.
When looking in the limit_data table the record of the call is indeed there until a final call hangup. According to the wiki we tried setting the variable limit_ignore_transfer to false both with set command before calling the limit application and also in limit.conf.xml. However, this does not change this behaviour.
Is this the intended behaviour? Can it work as I want? (i.e. once the call arrived to voicemail or picked-up the original destination is marked as free).
It is intended behavior. To handle voicemail, you could restructure your dialplan to: 1) set limit_ignore_transfer to false, then transfer to a VM handling extension. The act of transfering will reset the limit. 2) For intercept... you could use uuid_limit_release api. hmm.. This could also be used for 1. freeswitch@internal> uuid_limit_release USAGE: uuid_limit_release <uuid> <backend> [realm] [resource]
We are using 1.0.6; since this is a production system it is quite hard for me to test the latest git.
Thanks! __Yehavi:
_______________________________________________ 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
-- -Rupa
_______________________________________________ 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 Have you got the solution for this problem? It does not work for me too. -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/mod-limit-does-not-reset-count... Sent from the freeswitch-users mailing list archive at Nabble.com.
Could you explain a bit more about your scenario? -MC On Fri, Oct 15, 2010 at 10:28 AM, trob <trob@freemail.hu> wrote:
Hi
Have you got the solution for this problem? It does not work for me too. -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/mod-limit-does-not-reset-count... Sent from the freeswitch-users mailing list archive at Nabble.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 (5)
-
Jeffrey Leung
-
Michael Collins
-
Rupa Schomaker
-
trob
-
Yehavi Bourvine