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