It’s not only a colon that is used, it is two carats followed by a colon to tell FS what delimiter to use: ^^: The example from the wiki page shows this: <action application="set" data="fail_on_single_reject=^^:CALL_REJECTED:NORMAL_CLEARING:USER_BUSY"/> But I defer to Brian since he knows the code much better than I. Bote From: Mi Ke Sent: Thursday, 19 February, 2015 15:35 Subject: Re: [Freeswitch-users] piped failover doesn't work in dialplan, but works from console Hello Brian, Thank you for your response. The idea was taken here: https://wiki.freeswitch.org/wiki/Variable_fail_on_single_reject Commas in the list are not working either, even in console (where colons do): freeswitch@internal> originate {fail_on_single_reject=CALL_REJECTED,NO_ANSWER}error/NO_ANSWER|error/USER_BUSY|error/CALL_REJECTED 999 <---- should be no_answer -ERR CALL_REJECTED 2015-02-19 20:29:34.377089 [DEBUG] switch_ivr_originate.c:2100 Parsing global variables 2015-02-19 20:29:34.377089 [DEBUG] switch_event.c:1688 Parsing variable [fail_on_single_reject]=[CALL_REJECTED] 2015-02-19 20:29:34.377089 [NOTICE] switch_ivr_originate.c:2732 Cannot create outgoing channel of type [error] cause: [NO_ANSWER] 2015-02-19 20:29:34.377089 [DEBUG] switch_ivr_originate.c:3720 Originate Resulted in Error Cause: 19 [NO_ANSWER] 2015-02-19 20:29:34.377089 [NOTICE] switch_ivr_originate.c:2732 Cannot create outgoing channel of type [error] cause: [USER_BUSY] 2015-02-19 20:29:34.377089 [DEBUG] switch_ivr_originate.c:3720 Originate Resulted in Error Cause: 17 [USER_BUSY] 2015-02-19 20:29:34.377089 [NOTICE] switch_ivr_originate.c:2732 Cannot create outgoing channel of type [error] cause: [CALL_REJECTED] Sent: Thursday, February 19, 2015 at 10:00 PM From: "Brian West" <brian@freeswitch.org> To: "FreeSWITCH Users Help" <freeswitch-users@lists.freeswitch.org> Subject: Re: [Freeswitch-users] piped failover doesn't work in dialplan, but works from console originate {fail_on_single_reject='CALL_REJECTED\,NO_ANSWER'}error/NO_ANSWER|error/USER_BUSY|error/CALL_REJECTED 999 Where are you getting the idea you can use a colon to separate the causes? /* When using the AND operator, the fail_on_single_reject flag may be set in order to indicate that a single rejections should terminate the attempt rather than a timeout, answer, or rejection by all. If the value is set to 'true' any fail cause will end the attempt otherwise it can contain a comma (,) separated list of cause names which should be considered fatal */ On Thu, Feb 19, 2015 at 10:38 AM, Mi Ke <mi.ke@null.net> wrote: Dear All, I'm experimenting with the piped failover on the latest master. I want a failover to stop gw hunting and return from bridge when B-leg receives a specific disconnect code e.g. USER_BUSY or NO_ANSWER, but while it works as expected with error channels in console i.e.: freeswitch@internal> originate {fail_on_single_reject=CALL_REJECTED:USER_BUSY}error/NO_ANSWER|error/USER_BUSY|error/CALL_REJECTED 999 -ERR USER_BUSY freeswitch@internal> originate {fail_on_single_reject=CALL_REJECTED:NO_ANSWER}error/NO_ANSWER|error/USER_BUSY|error/CALL_REJECTED 999 -ERR NO_ANSWER it does not work in dialplan: <extension name="outbound"> <condition field="destination_number" expression="^\d{7}$"> <action application="set" data="bridge_answer_timeout=120"/> <action application="set" data="continue_on_fail=NORMAL_TEMPORARY_FAILURE:NO_ROUTE_DESTINATION:CALL_REJECTED"/> <action application="set" data="fail_on_single_reject=USER_BUSY:NO_ANSWER:NO_USER_RESPONSE:RECOVERY_ON_TIMER_EXPIRE:ORIGINATOR_CANCEL"/> <action application="set" data="bridge_early_media=true"/> <action application="set" data="hangup_after_bridge=true"/> <action application="odbc_query" inline="true" data="route_out"/> <action application="bridge" data="${bridge_to}"/> <action application="hangup" data="${last_bridge_hangup_cause}"/> <anti-action application="hangup" data="INVALID_NUMBER_FORMAT"/> </condition> </extension> or when included in bridge dialstring: <action application="bridge" data="{fail_on_single_reject=USER_BUSY:NO_ANSWER}${bridge_to}"/> i.e. it tries *all* gateways in the dialstring and ignores returning codes completely. I tried the same test when remote gateways were just hanging up with USER_BUSY code on receiving calls, but it did not affect the same negative result - all remote peers were tried in order and return code were ignored. I had the same experience with ver 1.2, but that time set continue_on_single_reject=err1,err2,err3 in dialplan worked for me flawlessly. However the same approach does not work for 1.5 and 1.4. Has anyone succeded in getting it to work as expected? Thanks / Mike _________________________________________________________________________ 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-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 -- Brian West brian@freeswitch.org <http://billing.freeswitch.org/templates/default/img/whmcslogo.png> 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 _________________________________________________________________________ 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-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

So you get what I mean about a quoted list, Look below, its showing it its parsing variable [fail_on_single_reject]=[CALL_REJECTED] <-- Notice it says only CALL_REJECTED. These three are the same from FS_CLI: originate {fail_on_single_reject='CALL_REJECTED\,NO_ANSWER'}error/NO_ANSWER|error/USER_BUSY|error/CALL_REJECTED 999 originate {fail_on_single_reject='CALL_REJECTED,NO_ANSWER'}error/NO_ANSWER|error/USER_BUSY|error/CALL_REJECTED 999 originate {fail_on_single_reject=CALL_REJECTED\,NO_ANSWER}error/NO_ANSWER|error/USER_BUSY|error/CALL_REJECTED 999 this is not: originate {fail_on_single_reject=CALL_REJECTED,NO_ANSWER}error/NO_ANSWER|error/USER_BUSY|error/CALL_REJECTED 999 You also have to be VERY careful when using ESL with say perl for example, You may have to quad escape the commas or various other elements to get thru the entire gambit of processing to finally arrive at FreeSWITCH with the proper formatting. On Thu, Feb 19, 2015 at 2:35 PM, Mi Ke <mi.ke@null.net> wrote:

Hello Brian,

Thank you for your response.

The idea was taken here: https://wiki.freeswitch.org/wiki/Variable_fail_on_single_reject

Commas in the list are not working either, even in console (where colons do):

freeswitch@internal> originate {fail_on_single_reject=CALL_REJECTED,NO_ANSWER}error/NO_ANSWER|error/USER_BUSY|error/CALL_REJECTED 999 <---- should be no_answer -ERR CALL_REJECTED 2015-02-19 20:29:34.377089 [DEBUG] switch_ivr_originate.c:2100 Parsing global variables 2015-02-19 20:29:34.377089 [DEBUG] switch_event.c:1688 Parsing variable [fail_on_single_reject]=[CALL_REJECTED] 2015-02-19 20:29:34.377089 [NOTICE] switch_ivr_originate.c:2732 Cannot create outgoing channel of type [error] cause: [NO_ANSWER] 2015-02-19 20:29:34.377089 [DEBUG] switch_ivr_originate.c:3720 Originate Resulted in Error Cause: 19 [NO_ANSWER] 2015-02-19 20:29:34.377089 [NOTICE] switch_ivr_originate.c:2732 Cannot create outgoing channel of type [error] cause: [USER_BUSY] 2015-02-19 20:29:34.377089 [DEBUG] switch_ivr_originate.c:3720 Originate Resulted in Error Cause: 17 [USER_BUSY] 2015-02-19 20:29:34.377089 [NOTICE] switch_ivr_originate.c:2732 Cannot create outgoing channel of type [error] cause: [CALL_REJECTED]

_________________________________________________________________________ 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-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

-- *Brian West* brian@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

On Thu, Feb 19, 2015 at 4:58 PM, Mi Ke <mi.ke@null.net> wrote:

Dear Brian,

I have tuned escaping as per your advise and variable parsing looks OK now:

2015-02-20 00:20:27.057113 [DEBUG] switch_ivr_originate.c:2100 Parsing global variables 2015-02-20 00:20:27.057113 [DEBUG] switch_event.c:1688 Parsing variable [fail_on_single_reject]=[USER_BUSY,NO_ANSWER,NO_USER_RESPONSE,RECOVERY_ON_TIMER_EXPIRE,ORIGINATOR_CANCEL] <---properly escaped now 2015-02-20 00:20:27.057113 [DEBUG] switch_ivr_originate.c:2550 Parsing session specific variables 2015-02-20 00:20:27.057113 [DEBUG] switch_event.c:1688 Parsing variable [rtp_secure_media]=[true] 2015-02-20 00:20:27.057113 [DEBUG] switch_event.c:1688 Parsing variable [sdp_secure_savp_only]=[true] 2015-02-20 00:20:27.057113 [DEBUG] switch_event.c:1688 Parsing variable [origination_caller_id_number]=[1111] 2015-02-20 00:20:27.057113 [DEBUG] switch_event.c:1688 Parsing variable [origination_caller_id_name]=[aaaa]

However a failover's behaviour in console and in dialplan is still different:

2015-02-20 00:20:27.057113 [NOTICE] switch_channel.c:1055 New Channel sofia/external/5555@1.1.1.1 [45088610-b896-11e4-99d1-858de6bd5367] 2015-02-20 00:20:27.057113 [DEBUG] mod_sofia.c:4701 (sofia/external/ 5555@1.1.1.1) State Change CS_NEW -> CS_INIT

call originates and hit 1.1.1.1

2015-02-20 00:20:27.117077 [DEBUG] sofia.c:5845 Remote Reason: 17 2015-02-20 00:20:27.117077 [DEBUG] sofia.c:6617 Channel sofia/external/ 5555@1.1.1.1 entering state [terminated][486] 2015-02-20 00:20:27.117077 [NOTICE] sofia.c:7533 Hangup sofia/external/ 5555@1.1.1.1 [CS_CONSUME_MEDIA] [USER_BUSY] 2015-02-20 00:20:27.117077 [DEBUG] switch_channel.c:3222 Send signal sofia/external/5555@1.1.1.1 [KILL]

2015-02-20 00:20:27.117077 [DEBUG] switch_core_state_machine.c:823 (sofia/external/5555@1.1.1.1) State REPORTING 2015-02-20 00:20:27.117077 [DEBUG] switch_ivr_originate.c:3720 Originate Resulted in Error Cause: 17 [USER_BUSY]

it should stop here since USER_BUSY is in fail_on_single_reject list, but hunting continues:

2015-02-20 00:20:27.117077 [DEBUG] switch_ivr_originate.c:2550 Parsing session specific variables 2015-02-20 00:20:27.117077 [DEBUG] switch_event.c:1688 Parsing variable [rtp_secure_media]=[true] 2015-02-20 00:20:27.117077 [DEBUG] switch_event.c:1688 Parsing variable [sdp_secure_savp_only]=[true] 2015-02-20 00:20:27.117077 [DEBUG] switch_event.c:1688 Parsing variable [origination_caller_id_number]=[2222] 2015-02-20 00:20:27.117077 [DEBUG] switch_event.c:1688 Parsing variable [origination_caller_id_name]=[bbbb]

and the same continues for gw 2.2.2.2

Meanwhile from console everything is OK:

freeswitch@internal> originate {fail_on_single_reject=CALL_REJECTED\,USER_BUSY\,NO_ANSWER}error/NO_ANSWER|error/USER_BUSY|error/CALL_REJECTED 999 -ERR NO_ANSWER 2015-02-20 00:35:15.057125 [DEBUG] switch_ivr_originate.c:2100 Parsing global variables 2015-02-20 00:35:15.057125 [DEBUG] switch_event.c:1688 Parsing variable [fail_on_single_reject]=[CALL_REJECTED,USER_BUSY,NO_ANSWER] 2015-02-20 00:35:15.057125 [NOTICE] switch_ivr_originate.c:2732 Cannot create outgoing channel of type [error] cause: [NO_ANSWER]

My dialplan is:

<extension name="outbound"> <condition field="destination_number" expression="^\d{4}$"> <action application="set" data="bridge_answer_timeout=120"/> <action application="set" data="bridge_early_media=true"/> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="sip_jitter_buffer_during_bridge=true"/> <action application="odbc_query" inline="true" data="route_out"/> <action application="bridge" data="${bridge_to}"/> <action application="hangup" data="${last_bridge_hangup_cause}"/> <anti-action application="hangup" data="INVALID_NUMBER_FORMAT"/> </condition> </extension>

bridge data var as returned from the db backend is:

{fail_on_single_reject=USER_BUSY\,NO_ANSWER\,NO_USER_RESPONSE\,RECOVERY_ON_TIMER_EXPIRE\,ORIGINATOR_CANCEL}[rtp_secure_media=true,sdp_secure_savp_only=true,origination_caller_id_number=1111,origination_caller_id_name=aaaa,called_id=5555]sofia/external/ 5555@1.1.1.1 ;transport=tls|[rtp_secure_media=true,sdp_secure_savp_only=true,origination_caller_id_number=2222,origination_caller_id_name=bbbb,called_id=5555]sofia/external/ 5555@2.2.2.2;transport=tls

a testing sites at 1.1.1.1 and 2.2.2.2 are doing nothing but hangup incoming calls with code 17

Any ideas?

Thanks / Mike

One thing I think you should try is to use the set application instead of using the curly brackets in the bridge line. I strongly recommend that you get it working manually with hard-coded values and then add the database lookup after that. I'd create a separate extension and test it. Something like this: <extension name="outbound"> <condition field="destination_number" expression="^\d{4}$"> <action application="set" data="bridge_answer_timeout=120"/> <action application="set" data="bridge_early_media=true"/> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="sip_jitter_buffer_ during_bridge=true"/> <action application="set" data="fail_on_single_reject=USER_ BUSY,NO_ANSWER,NO_USER_RESPONSE,RECOVERY_ON_TIMER_EXPIRE,ORIGINATOR_CANCEL"/> <action application="bridge" data="[ rtp_secure_media=true,sdp_secure_savp_only=true,origination_caller_id_number=1111,origination_caller_id_name=aaaa,called_id=5555]sofia/external/ 5555@1.1.1.1 ;transport=tls|[rtp_secure_media=true,sdp_secure_savp_only=true,origination_caller_id_number=2222,origination_caller_id_name=bbbb,called_id=5555]sofia/external/ 5555@2.2.2.2;transport=tls"/> <action application="hangup" data="${last_bridge_hangup_cause}"/> <anti-action application="hangup" data="INVALID_NUMBER_FORMAT"/> </condition> </extension> I have a hunch that once you get it working with predictable, hard-coded values that the rest of it will fall into place. -MC

Did you happen to update your FreeSWITCH code to something more recent? On Fri, Feb 20, 2015 at 1:21 PM, Mi Ke <mi.ke@null.net> wrote:

Dear Michael,

Thank you for your response. I liked your idea so I have removed all channel vars I was assigning before bridge, removed tls and left only USER_BUSY in the single reject list. Still no luck neither from console nor from dialplan:

originate {fail_on_single_reject=USER_BUSY}sofia/external/1111@1.1.1.1 |sofia/external/2222@1.1.1.1 999

tries both 1111 and 2222 in order, the same result is with simplified DP:

<extension name="outbound"> <condition field="destination_number" expression="\d+"> <action application="set" data="bridge_answer_timeout=120"/> <action application="set" data="verbose_sdp=true"/> <action application="set" data="bridge_early_media=true"/> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="sip_jitter_buffer_during_bridge=true"/> <action application="set" data="fail_on_single_reject=USER_BUSY"/> <action application="info"/> <action application="bridge" data="sofia/external/ 1111@1.1.1.1|sofia/external/2222@1.1.1.1"/> <action application="hangup" data="${last_bridge_hangup_cause}"/> <anti-action application="hangup" data="SERVICE_UNAVAILABLE"/> </condition> </extension>

quote from info output just before bridge:

variable_bridge_answer_timeout: [120] variable_verbose_sdp: [true] variable_bridge_early_media: [true] variable_hangup_after_bridge: [true] variable_sip_jitter_buffer_during_bridge: [true] variable_fail_on_single_reject: [USER_BUSY] variable_current_application: [info]

I also tried different escapings in {} as per Brian's advise, but all of them produced the same (correct) output in info and did not affect the end result. Any thoughts on where else I could dig?

Thanks / Mike

*Sent:* Friday, February 20, 2015 at 6:47 PM *From:* "Michael Collins" <msc@freeswitch.org> *To:* "FreeSWITCH Users Help" <freeswitch-users@lists.freeswitch.org> *Subject:* Re: [Freeswitch-users] piped failover doesn't work in dialplan, but works from console

On Thu, Feb 19, 2015 at 4:58 PM, Mi Ke <mi.ke@null.net> wrote:

...

Dear Brian,

I have tuned escaping as per your advise and variable parsing looks OK now:

2015-02-20 00:20:27.057113 [DEBUG] switch_ivr_originate.c:2100 Parsing global variables 2015-02-20 00:20:27.057113 [DEBUG] switch_event.c:1688 Parsing variable [fail_on_single_reject]=[USER_BUSY,NO_ANSWER,NO_USER_RESPONSE,RECOVERY_ON_TIMER_EXPIRE,ORIGINATOR_CANCEL] <---properly escaped now 2015-02-20 00:20:27.057113 [DEBUG] switch_ivr_originate.c:2550 Parsing session specific variables 2015-02-20 00:20:27.057113 [DEBUG] switch_event.c:1688 Parsing variable [rtp_secure_media]=[true] 2015-02-20 00:20:27.057113 [DEBUG] switch_event.c:1688 Parsing variable [sdp_secure_savp_only]=[true] 2015-02-20 00:20:27.057113 [DEBUG] switch_event.c:1688 Parsing variable [origination_caller_id_number]=[1111] 2015-02-20 00:20:27.057113 [DEBUG] switch_event.c:1688 Parsing variable [origination_caller_id_name]=[aaaa]

However a failover's behaviour in console and in dialplan is still different:

2015-02-20 00:20:27.057113 [NOTICE] switch_channel.c:1055 New Channel sofia/external/5555@1.1.1.1 [45088610-b896-11e4-99d1-858de6bd5367] 2015-02-20 00:20:27.057113 [DEBUG] mod_sofia.c:4701 (sofia/external/ 5555@1.1.1.1) State Change CS_NEW -> CS_INIT

call originates and hit 1.1.1.1

2015-02-20 00:20:27.117077 [DEBUG] sofia.c:5845 Remote Reason: 17 2015-02-20 00:20:27.117077 [DEBUG] sofia.c:6617 Channel sofia/external/ 5555@1.1.1.1 entering state [terminated][486] 2015-02-20 00:20:27.117077 [NOTICE] sofia.c:7533 Hangup sofia/external/ 5555@1.1.1.1 [CS_CONSUME_MEDIA] [USER_BUSY] 2015-02-20 00:20:27.117077 [DEBUG] switch_channel.c:3222 Send signal sofia/external/5555@1.1.1.1 [KILL]

2015-02-20 00:20:27.117077 [DEBUG] switch_core_state_machine.c:823 (sofia/external/5555@1.1.1.1) State REPORTING 2015-02-20 00:20:27.117077 [DEBUG] switch_ivr_originate.c:3720 Originate Resulted in Error Cause: 17 [USER_BUSY]

it should stop here since USER_BUSY is in fail_on_single_reject list, but hunting continues:

2015-02-20 00:20:27.117077 [DEBUG] switch_ivr_originate.c:2550 Parsing session specific variables 2015-02-20 00:20:27.117077 [DEBUG] switch_event.c:1688 Parsing variable [rtp_secure_media]=[true] 2015-02-20 00:20:27.117077 [DEBUG] switch_event.c:1688 Parsing variable [sdp_secure_savp_only]=[true] 2015-02-20 00:20:27.117077 [DEBUG] switch_event.c:1688 Parsing variable [origination_caller_id_number]=[2222] 2015-02-20 00:20:27.117077 [DEBUG] switch_event.c:1688 Parsing variable [origination_caller_id_name]=[bbbb]

and the same continues for gw 2.2.2.2

Meanwhile from console everything is OK:

freeswitch@internal> originate {fail_on_single_reject=CALL_REJECTED\,USER_BUSY\,NO_ANSWER}error/NO_ANSWER|error/USER_BUSY|error/CALL_REJECTED 999 -ERR NO_ANSWER 2015-02-20 00:35:15.057125 [DEBUG] switch_ivr_originate.c:2100 Parsing global variables 2015-02-20 00:35:15.057125 [DEBUG] switch_event.c:1688 Parsing variable [fail_on_single_reject]=[CALL_REJECTED,USER_BUSY,NO_ANSWER] 2015-02-20 00:35:15.057125 [NOTICE] switch_ivr_originate.c:2732 Cannot create outgoing channel of type [error] cause: [NO_ANSWER]

My dialplan is:

<extension name="outbound"> <condition field="destination_number" expression="^\d{4}$"> <action application="set" data="bridge_answer_timeout=120"/> <action application="set" data="bridge_early_media=true"/> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="sip_jitter_buffer_during_bridge=true"/> <action application="odbc_query" inline="true" data="route_out"/> <action application="bridge" data="${bridge_to}"/> <action application="hangup" data="${last_bridge_hangup_cause}"/> <anti-action application="hangup" data="INVALID_NUMBER_FORMAT"/> </condition> </extension>

bridge data var as returned from the db backend is:

{fail_on_single_reject=USER_BUSY\,NO_ANSWER\,NO_USER_RESPONSE\,RECOVERY_ON_TIMER_EXPIRE\,ORIGINATOR_CANCEL}[rtp_secure_media=true,sdp_secure_savp_only=true,origination_caller_id_number=1111,origination_caller_id_name=aaaa,called_id=5555]sofia/external/ 5555@1.1.1.1 ;transport=tls|[rtp_secure_media=true,sdp_secure_savp_only=true,origination_caller_id_number=2222,origination_caller_id_name=bbbb,called_id=5555]sofia/external/ 5555@2.2.2.2;transport=tls

a testing sites at 1.1.1.1 and 2.2.2.2 are doing nothing but hangup incoming calls with code 17

Any ideas?

Thanks / Mike

One thing I think you should try is to use the set application instead of using the curly brackets in the bridge line. I strongly recommend that you get it working manually with hard-coded values and then add the database lookup after that. I'd create a separate extension and test it. Something like this:

<extension name="outbound"> <condition field="destination_number" expression="^\d{4}$"> <action application="set" data="bridge_answer_timeout=120"/> <action application="set" data="bridge_early_media=true"/> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="sip_jitter_buffer_ during_bridge=true"/> <action application="set" data=" fail_on_single_reject=USER_

BUSY,NO_ANSWER,NO_USER_RESPONSE,RECOVERY_ON_TIMER_EXPIRE,ORIGINATOR_CANCEL"/> <action application="bridge" data="[ rtp_secure_media=true,sdp_secure_savp_only=true,origination_caller_id_number=1111,origination_caller_id_name=aaaa,called_id=5555]sofia/external/ 5555@1.1.1.1 ;transport=tls|[rtp_secure_media=true,sdp_secure_savp_only=true,origination_caller_id_number=2222,origination_caller_id_name=bbbb,called_id=5555]sofia/external/ 5555@2.2.2.2;transport=tls"/> <action application="hangup" data="${last_bridge_hangup_cause}"/> <anti-action application="hangup" data="INVALID_NUMBER_FORMAT"/> </condition> </extension> I have a hunch that once you get it working with predictable, hard-coded values that the rest of it will fall into place.

-MC

_________________________________________________________________________ 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-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

Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.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

-- *Brian West* brian@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

From Confluence:

https://freeswitch.org/confluence/display/FREESWITCH/Variables “fail_on_single_reject This is useful when using the "," AND operator in the DATA field of a bridge” You are using the pipe | operator to perform sequential hunting, not the comma to perform simultaneous calling. My guess is that fail_on_single_reject only works on simultaneous calls with the “bridge” app as indicated by the docs. I have not looked at the code, however. Bote From: Mi Ke Sent: Friday, 20 February, 2015 17:06 Subject: Re: [Freeswitch-users] piped failover doesn't work in dialplan, but works from console freeswitch@internal> version FreeSWITCH Version 1.5.15b+git~20150220T192157Z~9a6c29f8f7~64bit (git 9a6c29f 2015-02-20 19:21:57Z 64bit) freeswitch@internal> originate {fail_on_single_reject=USER_BUSY}error/NO_ANSWER|error/NO_ROUTE_DESTINATION|error/USER_BUSY|error/SERVICE_UNAVAILABLE 999 -ERR USER_BUSY is OK now trying on real channels: freeswitch@internal> originate {fail_on_single_reject=USER_BUSY}sofia/external/1111@1.1.1.1|sofia/external/2222@2.2.2.2 <mailto:%7bfail_on_single_reject=USER_BUSY%7dsofia/external/1111@1.1.1.1|sofia/external/2222@2.2.2.2> 999 -ERR USER_BUSY 2015-02-20 21:47:19.584431 [DEBUG] switch_ivr_originate.c:3720 Originate Resulted in Error Cause: 17 [USER_BUSY] 2015-02-20 21:47:19.584431 [NOTICE] switch_channel.c:1055 New Channel sofia/external/2222@2.2.2.2 [0b472918-b94a-11e4-b8f3-2ddfb755c79b] Thanks / Mike Sent: Friday, February 20, 2015 at 10:40 PM From: "Brian West" <brian@freeswitch.org> Subject: Re: [Freeswitch-users] piped failover doesn't work in dialplan, but works from console Did you happen to update your FreeSWITCH code to something more recent? On Fri, Feb 20, 2015 at 1:21 PM, Mi Ke <mi.ke@null.net> wrote: Dear Michael, Thank you for your response. I liked your idea so I have removed all channel vars I was assigning before bridge, removed tls and left only USER_BUSY in the single reject list. Still no luck neither from console nor from dialplan: