[Freeswitch-users] <application="set" data="call_timeout=5"/> VS {call_timeout=15}

[Ken Rice]

You should probably be doing this differently if this is calling out to
carriers...

I would do something more along this lines
<action application=²set²
data=²continue_on_fail=$${conditions_to_continue_on}²/>
<action application=²set² data=²hangup_after_bridge=true²/>
<action application="bridge" data="{leg_timeout=60}carrier1/1001²/>
<action application="bridge" data=" carrier2/1001"/>


This will prevent you from accidently ringing the called party twice, and it
will allow you to choose what conditions you actually want to fail over on,
not just try it, then try it again anyway...

See confluence for full continue_on_fail usage


On 9/4/14 4:38 PM, "Phillip Jones" <pjintheusa at gmail.com> wrote:

> Hi Brian,
> 
> I appreciate the response. The issue is, that in a carrier failover situation
> the user is called twice if I use {leg_timeout=60} in the dial string.
> 
> <action application="bridge"
> data="{leg_timeout=60}carrier1/1001|carrier2/1001"/> <------ rings 1001 using
> carrier 1 and carrier 2
> 
> The following however calls 1001 once. It works as expected and desired.
> 
> <action application="set" data="call_timeout=5"/> 
> <action application="bridge" data="carrier1/1001|carrier2/1001"/>  
> 
> Why would {leg_timeout=60} cause this?
> 
> 
> On Thu, Sep 4, 2014 at 5:03 PM, Brian West <brian at freeswitch.org> wrote:
>> Don't use call_timeout, use leg_timeout instead... like
>> [leg_timeout=5]user/1000,  You can also pair this with leg_delay_start to
>> have a single string that will just add additional calls to the current
>> bridge action as time goes on.
>> 
>> {leg_timeout=60}user/1015,[leg_delay_start=10]user/1016,[leg_delay_start=15]u
>> ser/1017,[leg_delay_start=20]user/1018
>> 
>> This will start ringing 1015 immediately, then start 1016 10 seconds in, 1017
>> 15 seconds in, 1018 20 seconds in.  While not dropping any of the calls that
>> are already ringing allowing you to escalate the call to additional people
>> the longer it sits.
>> 
>> 
>> On Thu, Sep 4, 2014 at 3:45 PM, Phillip Jones <pjintheusa at gmail.com> wrote:
>>> Hi there,
>>> 
>>> I am testing carrier failover via the dialplan. 
>>> 
>>> Can anyone tell why me the following two dial plans act differently? In my
>>> mind they are the same so I am flummoxed.
>>> 
>>>  
>>> <extension name="treatment_followme_route">
>>>      <condition field="${Treatment}" expression="^SEQUENTIAL$"/>
>>>  <condition field="${ForwardingNumber}" expression="^100">
>>> <action application="set" data="ignore_early_media=true"/>
>>> <action application="set" data="continue_on_fail=true"/>
>>> 
>>> <action application="set" data="call_timeout=5"/> 
>>> <action application="bridge" data="user/1001|user/1001"/>
>>> <action application="set" data="call_timeout=20"/> 
>>> <action application="bridge" data="user/1002|user/1002"/> 
>>> ...
>>>       </condition>
>>> </extension>
>>> 
>>> VERUS:
>>> 
>>> <extension name="treatment_followme_route">
>>>      <condition field="${Treatment}" expression="^SEQUENTIAL$"/>
>>>  <condition field="${ForwardingNumber}" expression="^100">
>>> <action application="set" data="ignore_early_media=true"/>
>>> <action application="set" data="continue_on_fail=true"/>
>>> 
>>> <action application="bridge" data="{call_timeout=5}user/1001|user/1001"/>
>>> <action application="bridge" data="{call_timeout=20}user/1002|user/1002"/> 
>>> ..
>>>       </condition>
>>>     </extension>
>>> 
>>> 
>>> First dial plan will dial user 1001 once followed by 1002 once - which is
>>> correct for my purposes
>>> 
>>> Second will dial user 1001 twice followed by 1002 twice
>>> 
>>> Why would {call_timeout=15} change the nature of that bridge and <action
>>> application="set" data="call_timeout=5"/> not?
>>> 
>>> 
>>> 
>>> 
>>> Thanks
>>> 
>>> 
>>> Phil
>>> 
>>> 
> 
> 
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at 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 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

-- 
Ken
http://www.FreeSWITCH.org
http://www.ClueCon.com
http://www.OSTAG.org
irc.freenode.net #freeswitch
Twitter: @FreeSWITCH


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20140904/8b9ec9c9/attachment.html