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

[Brian West]

You can also define what causes connstiute a failure:

failure_causes=USER_BUSY,CALL_REJECTED


On Thu, Sep 4, 2014 at 4:46 PM, Ken Rice <krice at freeswitch.org> wrote:

>  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]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 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.FreeSWITCH.org>
> http://www.ClueCon.com <http://www.ClueCon.com> http://www.OSTAG.org
> <http://www.OSTAG.org> *irc.freenode.net #freeswitch
> Twitter: @FreeSWITCH
>
>
> _________________________________________________________________________
> 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
>



-- 

*Brian West*
brian at freeswitch.org


*Twitter: @FreeSWITCH , @briankwest*
http://www.freeswitchbook.com
http://www.freeswitchcookbook.com

*T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378)
*iNUM:*+883 5100 1420 9001 | *ISN:*410*543 | *Skype:*briankwest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20140904/1ab80877/attachment-0001.html