On Mon, Jun 4, 2012 at 3:21 AM, Jose Fco. Irles Durá
<josefu@gmail.com> wrote:
I tried with "execute_on_originate" and with one "member" in the ring
group works, but when I have more than one member doesn't work.
This is a log with one memeber on the ring group (user 100), this works:
http://pastebin.com/9rdeQhDf
And this is with two members (user 100 and 171), don't work:
http://pastebin.com/aTdTTnnH
My bridge args is:
[execute_on_originate=limit hash callwaiting 100
1]user/100@128.23.0.1,[execute_on_originate=limit hash callwaiting 171
1]user/171@128.23.0.1 for the second case.
I'm thinking that I need some event processing for doing this.
2012/6/4 Michael Collins <msc@freeswitch.org>:
> Good point! Thanks for the tip.
> -MC
>
> On Sun, Jun 3, 2012 at 4:47 PM, Dave R. Kompel <drk@drkngs.net> wrote:
>>
>> Change that to "execute_on_originate". On answer will blow the call off if
>> it's over limits when the user answers.
>>
>> --Dave
>>
>> ________________________________
>> From: Michael Collins [mailto:msc@freeswitch.org]
>> To: FreeSWITCH Users Help [mailto:freeswitch-users@lists.freeswitch.org]
>> Sent: Sun, 03 Jun 2012 13:54:08 -0700
>> Subject: Re: [Freeswitch-users] limit app problem with loopback channels
>>
>> You can solve this issue by avoiding loopback. Don't use loopback unless
>> there is absolutely no other alternative. Try replacing the loopback calls
>> in the group definition to "user/xxx" instead:
>>
>> <extension name="group_dial_sales">
>> <condition field="destination_number" expression="^2000$">
>> <action application="bridge"
>> data="[execute_on_answer='limit hash callwaiting 1000 1']user/1000,
>> [execute_on_answer='limit hash callwaiting
>> 1001 1']user/1001"/>
>> </condition>
>> </extension>
>>
>> This is just off the top of my head, so please do the usual testing and
>> tinkering before you report back that it does not work. :)
>>
>> -MC
>>
>> On Sun, Jun 3, 2012 at 8:47 AM, Jose Fco. Irles Durá <josefu@gmail.com>
>> wrote:
>>>
>>> Hello,
>>>
>>> I'm trying to limit calls to one user with limit application, all
>>> works fine when a user dials to the number user (the caller is
>>> transfered to limit_exceeded extension)
>>>
>>> But when a caller dials to the 2000 extensions (a "ring group" to
>>> loopback channels) and one of the users (for example 1001) answer the
>>> call, the limit app removes the limit count for this channel when the
>>> loopback channel disappears (when the direct bridge occurs between the
>>> caller channel and callee channel).
>>>
>>> Where is the problem? How can I avoid that the limit app removes the
>>> limit for this loopback channel?
>>>
>>> There is the fragmet of my dialplan (is the vainilla dialplan from git
>>> with the limit action added)
>>> <context name="default">
>>> ...
>>> <extension name="Local_Extension">
>>> <condition field="destination_number" expression="^(10[01][0-9])$">
>>> <action application="export" data="dialed_extension=$1"/>
>>> <action application="set" data="ringback=${us-ring}"/>
>>> <action application="set"
>>> data="transfer_ringback=$${hold_music}"/>
>>> <action application="set" data="call_timeout=30"/>
>>> <action application="set" data="hangup_after_bridge=true"/>
>>> <action application="set" data="continue_on_fail=true"/>
>>> <action application="limit" data="hash callwaiting
>>> ${dialed_extension} 1"/>
>>> <action application="bridge"
>>> data="user/${dialed_extension}@${domain_name}"/>
>>> <action application="answer"/>
>>> <action application="sleep" data="1000"/>
>>> <action application="bridge"
>>> data="loopback/app=voicemail:default ${domain_name}
>>> ${dialed_extension}"/>
>>> </condition>
>>> </extension>
>>>
>>> <extension name="group_dial_sales">
>>> <condition field="destination_number" expression="^2000$">
>>> <action application="bridge"
>>> data="loopback/1000/default,loopback/1001/default"/>
>>> </condition>
>>> </extension>
>>>
>>> ...
>>> </context>
>>>
>>> --
>>> Jose Fco. Irles Durá
>>>
>>
>>
>>
>>
>> _________________________________________________________________________
>> 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
>
--
Jose Fco. Irles Durá
_________________________________________________________________________
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