[Freeswitch-users] Concurrent RINGING calls limitation

[Markus Lindenberg]

Hi Kevin,

I'm using/abusing limit for limiting incoming calls *to* an extension,
although I've just discovered that I would have the same problem, in my
current implementation the limit for the callee is raised when the call is
bridged:

First I do a inline lookup from the user directory and populate ${user_id}
with the callee's id.

                <condition>
                        <action inline="true" application="log" data="INFO
Dialed number ${destination_number} is ${user_id}@${domain_name} in XML
User Directory."/>

                        <!-- Get current limit, if >0 then callee is in a
call -->
                        <action inline="true" application="set"
data="user_busy=${cond(${limit_usage(db ${domain_name} ${user_id})} > 0 ?
true : false)}"/>

                        <!-- Don't use limit if caller=callee! (handover to
own DECT etc.)-->
                        <action inline="true" application="set"
data="user_busy=${cond(&quot;${user_name}&quot; == &quot;${user_id}&quot; ?
false : ${user_busy})}"/>
                </condition>

                <condition field="${user_busy}" expression="false"
break="never">
                        <!-- On bridge increase Call-Limit for the callee
(B-Leg).
                             Limit for outgoing Calls will be increased in
 dialplan/default.xml
                             See http://wiki.freeswitch.org/wiki/Limit -->
                        <action application="set"
data="bridge_pre_execute_bleg_app=limit"/>
                        <action application="set"
data="bridge_pre_execute_bleg_data=db ${domain_name} ${user_id} 100
!USER_BUSY"/>

                        <action application="limit" data="db ${domain_name}
${user_id} 100 !USER_BUSY"/>

                        <action application="set"
data="fail_on_single_reject=USER_BUSY"/>
                        <action application="bridge" data="user/${user_id}@
${domain_name}"/>

                        <anti-action application="log" data="INFO
${user_id}@${domain_name} is busy, not bridging call!"/>
                </condition>

Now if I replace this:

                        <action application="set"
data="bridge_pre_execute_bleg_app=limit"/>
                        <action application="set"
data="bridge_pre_execute_bleg_data=db ${domain_name} ${user_id} 100
!USER_BUSY"/>

with that:

                        <action application="limit" data="db ${domain_name}
${user_id} 100 !USER_BUSY"/>

the callee is marked as busy directly before i try to bridge to the user.
as soon as the call ends, the limit is reset. I just did a quick test
though and didn't try all the corner cases.

best regards, markus



On Tue, Jun 10, 2014 at 12:11 PM, Avi Marcus <avi at avimarcus.net> wrote:

> Just thinking out loud: you can use limit and an execute on answer to
> decrease the count, and also make sure it decreases it it fails.
>
> I assume your ringing limit will be lower than channel limit? Otherwise
> the channel limit should suffice.
>
> -Avi
> On Jun 10, 2014 10:52 AM, "Kevin Mathy" <k.mathy at hexanet.fr> wrote:
>
>> Hi List,
>>
>> I'm trying to find something on freeswitch to make a "per-user"
>> limitation of concurrent "RINGING" calls (or more generally, calls in
>> PROCEEDING state).
>>
>> I've found the "max-proceeding" value I can set in switch.conf.xml, but
>> it's a system's wide parameter, and I'd like more granularity...
>>
>> So, after some time spent on the mailing list and with my friend Google,
>> it seems that someone asked for quite the same thing 2 years ago, but
>> didn't get any answer :
>> http://marc.info/?l=freeswitch-users&m=134375187528797
>>
>> So, today, is there anything to achieve this ? Maybe something based on
>> the "limit" module ?
>>
>> Thanks a lot,
>> Kevin
>>
>>
>>
>> *Bien cordialement, Best Regards, **Kevin MATHY* | Ingénieur VoIP
>>
>>
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> 
>> 
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at 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 at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20140610/d75b4ae1/attachment.html