[Freeswitch-users] piped failover doesn't work in dialplan, but works from console
Brian West
brian at freeswitch.org
Fri Feb 20 23:40:29 MSK 2015
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 at 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 at 1.1.1.1
> |sofia/external/2222 at 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 at 1.1.1.1|sofia/external/2222 at 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 at freeswitch.org>
> *To:* "FreeSWITCH Users Help" <freeswitch-users at 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 at 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 at 1.1.1.1 [45088610-b896-11e4-99d1-858de6bd5367]
>> 2015-02-20 00:20:27.057113 [DEBUG] mod_sofia.c:4701 (sofia/external/
>> 5555 at 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 at 1.1.1.1 entering state [terminated][486]
>> 2015-02-20 00:20:27.117077 [NOTICE] sofia.c:7533 Hangup sofia/external/
>> 5555 at 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 at 1.1.1.1 [KILL]
>>
>> 2015-02-20 00:20:27.117077 [DEBUG] switch_core_state_machine.c:823
>> (sofia/external/5555 at 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 at 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 at 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 at 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 at 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 at 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 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
>
> _________________________________________________________________________
> 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/20150220/95b5c2ed/attachment-0001.html
Join us at ClueCon 2016 Aug 8-12, 2016
More information about the FreeSWITCH-users
mailing list