One trick I've noticed that nobody is doing for outbound limit, is using "execute_on_originate" to do the limit there on each channel. You can specify it in the local variables per channel.
The following would do it for each B-Leg, w/o messing associating the coun't to your a-leg session:
bridge:[execute_on_originate=limit hash foo gwa 10]sofia/gateway/gwa/$1|[execute_on_originate=limit hash foo gwb 10]sofia/gateway/gwb/$1 ... and so on...
I use this all the time in a more extended way. I use execute_on_originate to call my own dialplan app, but you could use it to invoke a lua script as well on the session of the B-Leg, before the call is originated. If you just return from your dialplan app, the b-leg will continue, but if you hangup the channel, then it will look like the b-leg failed with the hangup cause you specify, and will get passed back as if the far end returned that cause.
--Dave
From: Muhammad Naseer Bhatti [mailto:nbhatti@gmail.com]
To: FreeSWITCH Users Help [mailto:freeswitch-users@lists.freeswitch.org]
Sent: Tue, 29 May 2012 14:12:01 -0700
Subject: Re: [Freeswitch-users] Gateway failover with LUA
They are two different gateways with two different names, but the same
IP address yet the port is different. Possible that limit subsystem is
imposing the limit on the IP address itself and not able to
distinguish between the different ports.
On Tue, May 29, 2012 at 11:49 PM, Muhammad Naseer Bhatti
<nbhatti@gmail.com> wrote:
> Possible but here is the problem. When limit is set against two of the
> gateways,
>
> session:execute("limit", "hash gateway_channels v132_5000 10")
> session:execute("limit", "hash gateway_channels v132_5010 10")
>
> It sets limit of 10 channels for each gateway. But when the bridge is made,
>
> [gateway=v132_5010]sofia/gateway/v132_5010/9198|[gateway=v132_5000]sofia/gateway/v132_5000/9198
>
> The limit is imposed on both gateways.
>
> 2012-05-27 22:13:48.371539 [INFO] switch_limit.c:126 incr called:
> gateway_channels_v132_5000 max:10, interval:0
> 2012-05-27 22:13:48.371539 [INFO] mod_hash.c:202 Usage for
> gateway_channels_v132_5000 is now 3/10
> 2012-05-27 22:13:48.371539 [INFO] switch_limit.c:126 incr called:
> gateway_channels_v132_5010 max:10, interval:0
> 2012-05-27 22:13:48.371539 [INFO] mod_hash.c:202 Usage for
> gateway_channels_v132_5010 is now 3/10
>
> Is this is a bug or supposed to work like this? Though the call is
> connected to gateway name v132_5010 only.
>
>
> Thanks.
>
> On Mon, May 28, 2012 at 7:20 PM, Avi Marcus <avi@avimarcus.net> wrote:
>> How about a bridge2, bridge3, etc variable? Then your static dialplan can
>> see if those are set, and if so, use them.
>>
>> -Avi
>>
>>
>> On Mon, May 28, 2012 at 1:09 PM, Muhammad Naseer Bhatti <nbhatti@gmail.com>
>> wrote:
>>>
>>> Hi, I am trying to implement a gateway failover functionality with
>>> lua. Right now I am using limit and using hash backend to limit number
>>> of channels to each gateway. Since I am forwarding all calls with a
>>> default dialplan which is sending all calls to application lua and the
>>> bridge is done outside lua setting all the necessary vars.
>>> The idea is if all channels of first gateway are occupied, send the
>>> call to second gateway in the list and so on. Any idea how to
>>> implement this with lua? Can not seem to find the logic. If I query
>>> with limit_status it is going to be a query on every call. In a high
>>> call volume scenario, I don't think this would be really a good
>>> choice. Any ideas, thoughts?
>>>
>>> Thanks.
>>>
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting@freeswitch.org
>>> http://www.freeswitchsolutions.com
>>>
>>> FreeSWITCH-powered IP PBX: The CudaTel Communication Server
>>> http://www.cudatel.com
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://wiki.freeswitch.org
>>> http://www.cluecon.com
>>>
>>> Join Us At ClueCon - Aug 7-9, 2012
>>>
>>> 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
>>
>> FreeSWITCH-powered IP PBX: The CudaTel Communication Server
>> http://www.cudatel.com
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> Join Us At ClueCon - Aug 7-9, 2012
>>
>> 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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com
Join Us At ClueCon - Aug 7-9, 2012
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