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@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@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]user/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@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@freeswitch.org
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.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

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

_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.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