[Freeswitch-users] ESL: No events fired when there is error on submitted API command, like originate sofia to non-existent gateway

[Anton VG]

Yes, it does :) And I can use it to test is gw is up or down.
But question digs slightly deeper, it looks a kind odd, that when I
issue the non-working 'originate' or 'bridge'  - there is no ERROR
event at least. So seems there is no way to determine in ESL, that
'originate' or other command have fauiled have failed. On successful
execution - there is "BACKGROUD_JOB" event. But no event on error.
Don't you think that errors should fire events either, to inform ESL
dialplan that issued command have failed?


2011/5/14 Anthony Minessale <anthony.minessale at gmail.com>:
> It works with mod sofia dialplan app to test if a gw is down.
> That's your hint ;)
>
> On May 14, 2011 1:19 PM, "Anton VG" <anton.vazir at gmail.com> wrote:
>> If I'm not wrong mod_distribute just provides a list for dialing the
>> set of gateways, but not generating events itself. So seems not for
>> the case anyway...
>>
>> 2011/5/14 Anton VG <anton.vazir at gmail.com>:
>>> That good one, but not for the my case.
>>>
>>> i use originate &park, and than bridge_uuid, when there is an
>>> early_media.
>>> I have a number of gateways, which support specific destinations each,
>>> so it's up to my billing to decide what gateway should be dialed and
>>> in which order. But I still need to determine if gateway could be
>>> reached or not, or if while calling, it gives an error, and which one.
>>>
>>> I see gwlist down could be used for bridge, but bridge does not give
>>> flexibility I try to achieve. Will see what it gives if used for
>>> originate...
>>>
>>> So, considering your brief reply, there just no support for the case I
>>> need, so will try to get inside sofia.c ...
>>>
>>> Regards,
>>> Anton.
>>>
>>> 2011/5/14 Anthony Minessale <anthony.minessale at gmail.com>:
>>>> Read up on mod distributor on the wiki.
>>>>
>>>> On May 14, 2011 12:12 PM, "Anton VG" <anton.vazir at gmail.com> wrote:
>>>>> You did not understand. I INTENTIONALLY dialing the bad gateway, and
>>>>> I'm looking for a proper way to determine that gateway is bad in my
>>>>> ESL dialplan, by catching the proper event/reply/whatever,
>>>>> And much preferably without tricks, like esl.api('sofia status gateway
>>>>> GatewayWhichIsDown')
>>>>>
>>>>> When in production, and there is more than a single route, there will
>>>>> be plenty of cases, when you dial a bad gateway, so there should be a
>>>>> way for ESL dialplan to determine that a gateway is not callable for a
>>>>> moment, the reason WHY and to retry with another one.
>>>>>
>>>>> The trick above is bad, since:
>>>>> 1. blocking api query, before evey single gateway call attempt.
>>>>> 2. Gateway maybe known in UP state, but the state is stale, in dial in
>>>>> fact will go to DOWN gateway. So, dialplan will screw
>>>>>
>>>>> Possibly I should ask in DEV list...
>>>>>
>>>>> 2011/5/14 Madovsky <infos at madovsky.org>:
>>>>>> maybe your gateway is blocking some numbers
>>>>>>
>>>>>> ----- Original Message -----
>>>>>> From: "Anton VG" <anton.vazir at gmail.com>
>>>>>> To: "FreeSWITCH Users Help" <freeswitch-users at lists.freeswitch.org>
>>>>>> Sent: Saturday, May 14, 2011 12:23 PM
>>>>>> Subject: Re: [Freeswitch-users] ESL: No events fired when there is
>>>>>> error
>>>>>> on
>>>>>> submitted API command, like originate sofia to non-existent gateway
>>>>>>
>>>>>>
>>>>>>> The same goes for gateway, which is just down. No events, signalling
>>>>>>> that call will not succeed. And no events fired.
>>>>>>>
>>>>>>> 2011-05-14 21:19:32.002929 [ERR] mod_sofia.c:4050 Gateway is down!
>>>>>>> 2011-05-14 21:19:32.002929 [ERR] switch_ivr_originate.c:2447 Cannot
>>>>>>> create outgoing channel of type [sofia] cause: [NETWORK_OUT_OF_ORDER]
>>>>>>>
>>>>>>> Am I missing the way to get info in the ESL about gateways, which are
>>>>>>> out of order, or there is simple no way, without hacking the code?
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> 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
>
>