[Freeswitch-users] piped failover doesn't work in dialplan, but works from console

[Michael Collins]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20150220/601d1f96/attachment.html